¿Se reemplaza C ++ por C # en los juegos de la industria?

En juegos de la industria me refiero a Quake, CoD, etc.

En cierto sentido, C ++ realmente está siendo reemplazado, no solo por C #, sino por una gran cantidad de otros lenguajes. Pero si preguntas, ¿será reemplazado por completo ? Entonces la respuesta es definitivamente no .

Esto se debe a que C ++ se usa tradicionalmente en dos capacidades. Primero, para crear el motor del juego : los componentes de bajo nivel que cargan recursos, empujan polígonos a la pantalla y rompen números en simulaciones físicas. En segundo lugar, codificar la lógica del juego : las reglas reales que hacen el juego.

Esta segunda capacidad no requiere los puntos fuertes de C ++ (como el control completo sobre los detalles de bajo nivel), pero sufre de sus debilidades (como la gestión de memoria codificada a mano propensa a errores). Y en esta segunda capacidad, C ++ está siendo reemplazado por diferentes lenguajes de script. Muchos desarrolladores usan Lua; algunos usan Python. Pero si hay una plataforma CLI disponible, en forma de .NET o Mono, presenta un gran candidato para el host de scripting. Estas plataformas son bastante rápidas, confiables, ofrecen un lenguaje ampliamente conocido (C #) y una biblioteca de clase base completa. No olvidemos las herramientas: MS Visual Studio y SharpDevelop / MonoDevelop podrían no ser los mejores IDE del mundo, pero son bastante buenos.

Dicho esto, el motor del juego no se escribirá en C # (o Lua, o Python para el caso). ¿Por qué? Porque simplemente no son lo suficientemente rápidos.

Contrariamente a muchas creencias populares, el mayor éxito de rendimiento actual se debe a la latencia de la memoria . Esto significa que acceder a la memoria es un asunto serio. Y los lenguajes administrados no permiten al usuario controlar el acceso a la memoria, precisamente por eso están "administrados" en primer lugar. Por lo tanto, ningún lenguaje administrado permitirá escribir un motor de juego realmente rápido. En realidad, todos los grandes motores "C #" en los que puedo pensar - XNA, MOGRE, Unity - están basados ​​en código nativo C ++; pero permite escribir la lógica del juego en C #.

Para resumir : C # se usará en lugar de C ++ u otros lenguajes. Pero nunca reemplazará a C ++, al menos hasta que alguien invente una memoria de acceso instantáneo sin latencia.

La elección del idioma depende en gran medida de la plataforma. En este momento parece muy poco probable que cualquier cosa, excepto una plataforma de Microsoft, realmente requiera .NET como implementación.

La sabiduría convencional diría que una pequeña plataforma necesitaría estar cerca del metal para ser eficiente, pero por otro lado, las plataformas administradas son más seguras . Esa es probablemente la razón por la que Windows Phone 7 te obliga a usar .NET.

Sin duda sería interesante si la nueva Xbox requiere una plataforma administrada. Si el hardware de un teléfono puede manejarlo (y lo hace), ciertamente podría verlos usándolo en una consola de tamaño completo. Agitaría bastante el ecosistema de la consola, ya que sería más difícil escribir juegos multiplataforma sin escribir todo el código del juego en un lenguaje de script. Si ese es el caso, entonces C # no reemplazaría a C ++, pero iría de la mano.

En este momento, podría usar Mono como un back-end de secuencias de comandos (similar a lo que hace Unity), pero me imagino que la mayoría de los fabricantes de motores querrían rodar los suyos, o usar algo más compacto como Lua o Python que C #.

De cualquier manera, se trata de la herramienta adecuada para el trabajo correcto. De todos modos, realmente debería aprender ambos idiomas, ya que C # hace que sea más fácil hacer ciertas cosas (desarrollo de herramientas, desarrollo del servidor probablemente, etc.), y en algunos casos no puede usar nada más que C ++.

No es probable C ++ tiene la ventaja de ser de bajo nivel para que los desarrolladores puedan modificar los detalles más pequeños para obtener el mejor rendimiento posible.

Con C # y .NET tiene una recolección de basura que es muy útil, pero cuando trabaja con plataformas con memoria y recursos limitados (consolas portátiles y hasta cierto punto consolas domésticas) necesita tener el mayor control posible sobre la memoria para hacer el mejor uso de los recursos. Permitir que los idiomas administrados asignen y liberen memoria para usted probablemente le causará muchos problemas.

La velocidad también es un problema (aunque probablemente menos). Con el tiempo, estoy seguro de que los lenguajes administrados podrían funcionar de manera comparable a los compiladores de C ++.

En general, en mi experiencia de todos modos, los desarrolladores de juegos tienden a ser fanáticos del control cuando se trata de memoria, tiempos de CPU y recursos (para exprimir tanto rendimiento como sea posible), razón por la cual C / C ++ son los lenguajes utilizados principalmente.

AFAIK .NET GC todavía sufre de detener el algoritmo de estilo mundial . Si bien esto puede ser apropiado para una amplia variedad de aplicaciones, es inaceptable para aplicaciones en tiempo real como los juegos.

De hecho, es muy difícil usar lenguajes administrados de manera efectiva para programas en tiempo real hasta que tengamos algunos avances en GC.

No. Dependiendo de .NET implicaría reescrituras masivas para plataformas sin Framework disponible, como la PS3, y las desventajas de rendimiento pueden ser perfectamente aceptables en la PC o en los juegos Live Arcade, pero los juegos más grandes necesitarán cada fragmento de rendimiento desde sus consolas para correr lo suficientemente rápido. Más que eso, hay enormes bases de código existentes en C ++ que nadie podría permitirse actualizar, incluso si quisieran. C ++ está en la industria del juego y permanecerá allí por mucho tiempo.

En los momentos en que la energía de la computadora escaseaba, todo debía programarse en C o C ++, simplemente porque los lenguajes recolectados de basura quitan el control de la memoria al programador y, por lo tanto, el rendimiento puede disminuir.

Hoy en día, las computadoras son más rápidas, pero como dice Knuth y para abreviar, la optimización puede ser mala:

• Es obvio que las funcionalidades centrales de bajo nivel necesitan ser optimizadas, porque la computación de geometría 3D, física, colisiones, iluminación, puede inflar rápidamente el mejor procesador disponible. Se puede ver fácilmente que el aumento de la calidad visual en una máquina casi siempre mata significativamente el rendimiento.

• Ahora, hay otras funcionalidades, como estados de juego, IA, sonido, entrada, red, que siguen siendo importantes en un juego, pero que casi nunca requerirán tantos recursos informáticos. Esas funcionalidades, la mayoría de las veces, no tienen que ser optimizadas. Ese es el objetivo del lenguaje de secuencias de comandos y los idiomas recolectados de basura: no tiene que pensar en la coherencia de su memoria y en la organización de su aplicación, porque el código que escribirá con estos idiomas, si no está codificando cosas de bajo nivel, nunca será un embotellamiento.

Ejemplo con 2 casos

• Envíe 500 kg de muebles con un camión.
• Envíe 30 toneladas de material con un bote.

ambos están a 500 kms de distancia.

En ambos casos, ¿importa que el proceso de carga / descarga sea más rápido para que todo el tiempo de transporte sea más pequeño, sabiendo que NO PUEDES hacer que el bote ni el camión se muevan más rápido?

La respuesta es: importaba con el camión, pero ya no con el bote, porque ya hiciste mucho moviendo el stock con el bote.

No sé si entiendes esta metáfora, pero de alguna manera, puede hacerte imaginar el problema matemático, que es más importante que entender la respuesta.

Los lenguajes de secuencias de comandos permiten que los juegos sean más rápidos si ya tiene un motor programado en C / C ++: el motor 3D resuelve los problemas de bajo nivel, ahora tiene que hacer el juego con sus secuencias de comandos.

Pero recuerde: nunca podrá reemplazar el lenguaje compilado de bajo nivel, NUNCA. Los lenguajes compilados de tipo estático son el núcleo del rendimiento y NO PUEDE descartarlos, ya sea un núcleo, un motor 3D o un controlador de tarjeta gráfica.

Pero, por supuesto, si su juego es gráficamente simple y no requiere muchos cálculos vectoriales, puede enfocarse en el juego y olvidarse de la optimización, porque en este caso nunca tendrá que lidiar con la optimización ya que su máquina es realmente rápida para eso

Excepto si planea portar ir al DS. Pero me detendré allí.

Mira, sé que esto es una queja, pero no solo estoy dividiendo pelos. Siento que la mayoría de los programadores realmente no componen esto. Un lenguaje en sí no tiene nada que ver con la velocidad / rendimiento de la carrera. Es el compilador / framework. Podría argumentar mejor gcc contra cl (compilador de microsoft anterior a 2010) o msbuild (compilador actual de c ++ para 2010). Cada versión de estos compiladores mejora, por lo que también debe compararlos con versiones anteriores de ellos mismos. Estoy muy impresionado con .net y funciona bien, pero incluso si tuvo un rendimiento ligeramente mejor, no veo que se haga cargo, una razón: la portabilidad.

Los juegos AAA quieren estar en Windows, Linux, Mac, XBox, PS3, Nintendo, etc.