Sería útil si explicara brevemente qué le dio la idea, ya que es una idea muy extraña, por decir lo menos.
Konrad Rudolph
2
Teniendo en cuenta Quake se hace en C .. ;-)
The Communist Duck
¡Solo me preguntaba esta pregunta!
Jeff
2
Parece que por "juegos de la industria" te refieres a lo que generalmente se llama "títulos AAA".
caos
Respuestas:
53
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.
+1 Visual Studio es un muy buen IDE. Incluso si es el lado oscuro ...
Michael Coleman
1
Bah, en mi experiencia, C # tampoco es lo suficientemente rápido para la simulación, pero eso no impide que las personas lo intenten.
BigSandwich
@Nevermind ¿Qué es "idiomas administrados"?
Quazi Irfan
3
@iamcreasy En sentido amplio, por "lenguajes administrados" me refiero a los lenguajes que se ejecutan en una máquina virtual que incluye alguna forma de recolección de basura y / o administración de memoria. Más estrictamente, los idiomas administrados son idiomas que se dirigen a (alguna implementación de) Common Language Runtime, pero mi respuesta se aplica no solo a ellos.
importa
En su opinión, ¿los esquemas GC contados por referencia entran en esta categoría a la Vala?
weberc2
6
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 ++.
A partir de ahora, 3 años después, el estado de C # para el desarrollo de juegos está mucho más evolucionado. Mono-Project recogió XNA Game Studio y lo renombró como MonoGame. SharpDX, SlimDX y OpenTK son envoltorios opengl / directx muy decentes. Incluso han surgido algunos motores de física en C #. Mono / MonoGame te permite crear un juego una vez y portarlo automáticamente a Android, Linux, Mac OS, iOS, Xbox 360, PS3, PS4 y Wii.
Ryan Mann
3
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.
Si bien existe inercia, las bases de código de C ++ no son tan antiguas, tal vez 10 años como máximo. Casi todo el código en ellos ha sido reemplazado durante ese período, para aceleradores 3D, tuberías programables, arquitecturas basadas en datos y soporte de secuencias de comandos. Si un desarrollador de AAA quisiera hacer una migración completa a C #, probablemente podría lograrlo por un costo mínimo en el espacio de tres juegos: primero úselo como herramienta y host de secuencias de comandos, luego mueva las capas lógicas del juego y el tercer puerto el procesador para usar un contenedor DX / GL administrado.
1
Mono tiene una solución comercial .NET para PS3.
Dan Olson
En segundo lugar, si construyes tu juego en c # contra mono o con monogame (reemplazo de xna), puedes portarlo a ps3 / ps4, wii, xbox 360, android, max os, etc. integrado.
Ryan Mann
0
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í.
"La optimización puede ser malvada" es, con mucho, la versión mutada más inútil de su declaración que he leído.
bueno, lo estoy explicando, por eso me pareció inútil citar toda su declaración, que es una oración bastante larga y no se explica realmente ... Además de eso, estamos hablando de juegos, que no es lo mismo software más amplio del que quería hablar Knuth.
jokoon
Usted menciona que la entrada casi nunca ocupa muchos recursos informáticos. Me gustaría señalar que a medida que el jugador se conecta más físicamente al juego, esto se vuelve menos cierto. Por ejemplo, el kinect. Es una forma de entrada, pero requiere muchos recursos informáticos para usar.
Ponkadoodle
0
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.
Ciertamente, la implementación del compilador juega un papel importante, pero diferentes lenguajes proporcionan diferentes posibilidades para la optimización basada en el compilador, y diferentes posibilidades para que los programadores eludan las reglas de lenguaje habituales y hablen directamente con el hardware. El idioma y el objetivo per se tienen mucho que ver con el rendimiento.
Un lenguaje puede tener mucho que ver con la velocidad / rendimiento de ejecución porque la sintaxis y las bibliotecas estándar favorecerán diferentes enfoques. Por ejemplo, un lenguaje en el que es difícil usar matrices de memoria contigua debido a que todos sus objetos son punteros tenderá a agotar el caché mucho más que uno en el que pueda usar matrices o vectores de manera efectiva.
Kylotan
+1 muy buen punto, que podrías haber hecho sin insultar a las personas estúpidas, no saben quiénes son.
Fire Crow
Excepto que, a partir de hoy, puede compilar contra mono y tiene puertos para casi todo. Por ejemplo, ahora es muy portátil.
Respuestas:
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.
fuente
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 ++.
fuente
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.
fuente
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.
fuente
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.
fuente
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
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í.
fuente
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.
fuente