2009-04-30 26 views

Respuesta

10

La velocidad de los lenguajes de nivel superior generalmente los mantiene fuera del desarrollo de juegos "serios", donde reina C y C++. Sin embargo, cada vez más juegos exponen la lógica del juego a lenguajes de scripting como Lua y Python.

He oído hablar de los juegos independientes que se están desarrollando en VB, por ejemplo, la serie Zombie Smashers fue desarrollada en VB por James Silva, quien recientemente hizo el juego Dishwasher Dead Samurai en C# .net.

Es posible que desee ver en el marco de Xbox Live Arcade (XNA) Microsoft apagó. Puedes usar eso en VB o C#.

+1

Como advertencia al respecto, no puede usar VB.NET para desarrollar juegos para Xbox 360 utilizando XNA. Solo C# 3.0 es compatible. http://creators.xna.com/en-us/xnags_islive –

+0

No sabía que Ed, pero puede hacer juegos de PC en ambos. Esta puede ser la razón por la que Silva cambió a C# para Dishwasher, se vio forzado a salir de VB. –

3

No es VB.NET ese es el problema principal, es .NET Framework.

Específicamente, el desarrollo de juegos generalmente se realiza en C/C++ donde se puede obtener cada onza de rendimiento. El framework .NET no se presta a esto.

Dicho esto hay juegos que se han desarrollado en .NET

+0

subido por la verdad. Aunque amo el framework .NET, la mayoría de los desarrolladores más importantes han dejado constancia de que si quieres involucrarte en el desarrollo de juegos, conoce bien C++ y tus estructuras de datos/algos son aún mejores (Blizzard). – bdd

+1

Correcto, pero ¿realmente vas a competir con Blizzard si eres el único programador que trabaja en un juego de hobby? –

0

VB.NET no es diferente de cualquier otro lenguaje .NET.

La percepción de que VB es lento ya no es el caso.

Aquí hay un list of tutorials para VB.NET con XNA (juego de herramientas de desarrollo).

1

Parte de esto es el estigma todavía asociado a vb en general de ser un lenguaje lento. (Que no es tan cierto como solía ser debido a lo común del framework .net)

Para ser sincero, aunque depende de qué tipo de juego desarrolles, si estás haciendo una alta velocidad de cuadros, alta Gráficos de nivel 3-D, juego de vanguardia, estás atrapado escribiéndolo en C o C++ para obtener el rendimiento necesario. Pero si estás haciendo algo más parecido a lo que ves hoy en muchos juegos basados ​​en flash, o incluso cosas que podrías ver en juegos anteriores, en mi humilde opinión, podrías hacerlo en casi cualquier idioma.

+0

Sí, realmente depende del alcance de su proyecto. Use la herramienta correcta para lo que quiere lograr. –

8

Tardó mucho tiempo para que los programadores de juegos incluso aceptaran C++ sobre C debido a que es "lento". Creo que muy pronto la era multinúcleo hará que esto se desvanezca lentamente porque correr en paralelo será mucho más importante que ejecutar un solo hilo lo más rápido posible.

Tenga en cuenta también que actualmente se realiza un gran procesamiento en la GPU con sombreadores de píxel/vértice/geometría. Así que estamos viendo algunos juegos bastante avanzados escritos en lo que podrían considerarse idiomas "lentos".

Por último, .NET no es lento. Lo que lo hace problemático para el desarrollo del juego es la imprevisibilidad del recolector de basura (GC se activa durante una gran pelea entre jefes y causa retraso, no tan bueno) y cualquier clasificación que se produce entre C# y el código nativo.

Afortunadamente, con una comprensión profunda de cómo funciona .NET, incluido el GC y los tiempos de ejecución, ambos obstáculos se pueden superar.

En todo caso, sería muy recomendable crear un prototipo de un juego en un lenguaje administrado, ya sea VB.NET, C#, python, ruby, etc. ... y luego, si se descubre que es demasiado lento, puede partes de ella a C++.

.NET ha administrado C++, lo que hace que la interoperabilidad entre el código nativo y el administrado sea bastante fluida. Esto permite que las partes realmente críticas se escriban de forma nativa si es necesario. Pero dudo que este sea el caso. Las optimizaciones más importantes al principio vendrán de estructuras de datos, algoritmos y arquitectura general.

0

Como otros han señalado, .Net no es lento, pero hay algunas cosas que se destacan en contra de ella para el desarrollo del juego:

  1. no determinismo de la recolección de basura
  2. bajo la portabilidad (en comparación con C)
  3. La falta de herramientas/dev bibliotecas juego maduro/marcos

cuanto al uso de VB.Net específicamente. Querido señor, ¿por qué? :-)

0

Puede usar Microsoft XNA Framework para gráficos y una aplicación regualr WinForms para contener todo su código. Simplemente instale XNA Framework y agregue una referencia desde su aplicación VB WinForms.

Si desea aprovechar todas las características que XNA tiene para ofrecer, deberá usar C# con el que XNA se integra muy bien.

1

En cuanto a la parte de velocidad, los motores como el Visual3D.NET basado en XNA me han convencido de que no es imposible obtener un buen rendimiento de un motor de juego administrado. Más importante aún, la CPU no parece ser un cuello de botella en ninguna de las demostraciones, que es la única parte en la que el uso de C# tiene algún efecto. E incluso cuando su CPU está limitada, solo está presionando un 50-60% ya que el motor aún tiene un solo subproceso, por lo que hay mucho margen de mejora en las CPU actuales de doble y cuádruple núcleo, y en los núcleos octo y hexadeca de mañana. Creo que la optimización de los algoritmos para escalar bien en la era de muchos núcleos será más importante que el lenguaje utilizado.

Y lo bueno de utilizar un lenguaje administrado para todo el motor es que es fácil usar el mismo lenguaje de alto nivel para la lógica/IA del juego, mientras que los motores nativos pueden usar lenguajes de scripting mucho más lentos para esto.

El uso de un lenguaje administrado como C#/VB.NET puede ser limitante para cosas basadas en la CPU como la física, pero estoy impresionado por la biblioteca de física totalmente administrada JigLibX para XNA.

Esto es todo C#, pero supongo que se aplica a VB.NET también, ya que están compilados en la misma IL al final, a menos que haya algunas limitaciones en el compilador de VB que desconozco.

Cuestiones relacionadas