Luego de mucho luchar hemos encontrado la respuesta de este apuro que muchos de nuestros usuarios de nuestro espacio tienen. Si tienes algo que compartir puedes compartir tu conocimiento.
Java y C # tienen recolección automática de basura y C ++ no. El programador debe prestar más atención al uso de la memoria para evitar punteros colgantes, etc.
Usted mismo ha respondido a su pregunta.
En la programación de juegos, la recolección de basura no es una ventaja. Incluso si el rendimiento de Java está más o menos a la par con C ++ para la mayoría de las tareas, y el JIT puede incluso hacer optimizaciones muy agresivas que superan a las que se pueden hacer durante la static análisis; la recolección de basura puede hacer que las tasas de fotogramas caigan en el peor momento.
Además, para tareas con uso intensivo de gráficos, Java no es muy apropiado, ya que hay muchas cosas que el tiempo de ejecución considera inseguras y, por lo tanto, están prohibidas (como lanzar punteros para reinterpretar datos).
Otro asunto importante es el know-how ya asentado en la industria. La inercia de C ++ en la industria de los juegos es enorme. Todos los desarrolladores de juegos de hoy conocen C y C ++. Tener un gran grupo de desarrolladores para contratar reduce uno de los riesgos de gestión que es key personas que abandonan la empresa.
Pero a pesar de eso, ha habido algunos juegos exitosos con algunas partes escritas en Java, como Vampire: The Masquerade – Redemption.
Un juego más reciente como Minecraft está escrito completamente en Java; pero no cuenta con gráficos de última generación, ya que se pone más énfasis en la naturaleza dinámica del entorno virtual.
Y muchos otros juegos y motores tienen un tiempo de ejecución que admite un lenguaje de scripting administrado (asignación y recopilación de memoria automática segura) construido sobre una plataforma de renderizado y redes de alto rendimiento (escrito en C / C ++), como Unreal Engine, por ejemplo.
En general, todo lo que se dijo aquí fue una razón para no migrar a Java para el desarrollo de juegos; era. La industria del juego se encuentra actualmente en un cambio de paradigma. Tres cosas han cambiado o están cambiando actualmente la industria del juego:
- Piratería
- Modelos de programas cliente-servidor
- Modelos de programas de redes modulares
Un juego ya no depende completamente de sí mismo. los key Las ventajas que existían en los primeros (lenguajes de bajo nivel) se ralentizan siendo superadas por las ventajas que existen dentro de lenguajes como C # y Java (lenguajes de alto nivel). Dos ejemplos toscos pero innegables son los juegos que funcionan en Facebook, y medios remotos como teléfonos, tabletas, etc..
Es importante señalar que en los dos escenarios, las tres preocupaciones enumeradas anteriormente se disuelven. Un juego que no puede funcionar sin un servidor no necesita preocuparse por una infracción de copia (alojamiento privado a través de ingeniería inversa no incluido). La demanda de juegos que dependen de la red requiere un lenguaje que pueda equilibrar el rendimiento del sistema con el rendimiento de la red (generalmente un estancamiento entre Java y C / C ++, favoreciendo C / C ++ estrictamente debido a la abundancia de bibliotecas preexistentes). Sin embargo, no sería práctico desarrollar un juego diseñado en un módulo de programa de red modular en lenguajes de bajo nivel como C / C ++. Una empresa que estaría interesada en diseñar un juego en C / C ++ para un modelo de programa de red modular tendría que crear una máquina virtual completamente dedicada a ese juego, o reprogramar / recompilar el juego varias veces demasiado loco para pensar. En mi opinión, aunque puede que sea demasiado pronto para indicar qué idioma es el preferido, estoy apostando por Java durante tres key razones.
-
1) La JVM permite que las aplicaciones basadas en Java se ejecuten virtualmente en cualquier plataforma, ya sea Apple, Android, Windows 8 o derivada de Linux / UNIX (virtualmente compatible con cualquier plataforma de hardware también).
-
2) Java usa OpenJL (el derivado de OpenGL, que se ejecutará en OpenGL como cliente; jMonkey es un motor diseñado en OpenJL). Es importante tener en cuenta que solo Microsoft Windows usa DirectX, por muy bueno que sea, tiene un inconveniente. Prácticamente todos los sistemas operativos que pueden ejecutar juegos serán capaces de renderizar en OpenGL y el diseño modular está impulsando esto como nunca antes. (Tenga en cuenta que Microsoft está tratando de desviar este problema monopolizando la distribución de Windows 8).
-
3) Java admite subprocesos internamente dentro de la JVM, lo que le permite aprovechar al máximo los procesadores de múltiples núcleos sin el uso de ninguna biblioteca de terceros. Actualmente, esto es una desventaja para todos los demás idiomas (especialmente los desarrollados para teléfonos).
Si bien la JVM plantea un problema de latencia, debe tenerse en cuenta que tales problemas podrían eliminarse mediante subprocesos. Tampoco estaría demasiado preocupado por Windows 8 y el impulso de Microsoft. Google tiene una participación accionaria de $ 720 / acción, Apple tiene $ 526 / acción, Microsoft tiene $ 27 hasta la fecha. Si bien es probable que Apple se vea afectado por el impulso de Microsoft principalmente debido al uso de C #, es probable que Google, por otro lado, se beneficie de ello. Microsoft nunca ha tenido mucha suerte al competir con Google y Google / Android usa mucho Java. Angry Birds se diseñó originalmente en Java FYI y se portó a C # para iPhone. Si Google / Android refuerza la estandarización, Microsoft caerá como una mosca, llevándose a Apple con ellos.
Quería abordar solo un tema secundario de esta pregunta, pero la recolección de basura no es necesariamente útil para crear los aspectos críticos de rendimiento de bajo nivel de un motor de juego de tipo AAA. De hecho, es útil evitar ese tipo de sistema de referencia y recopilación de objetos. Desea que incluso los tipos definidos por el usuario sean contiguos en la memoria y se ajusten a los objetos adyacentes en la caché, etc.
Aparte de los problemas de rendimiento de recolectar basura a intervalos periódicos y de dispersar objetos en la memoria, los juegos no pueden permitirse el lujo de tener fugas con sus recursos más voluminosos, y el recolector de basura obstaculiza las cosas allí. Si, acabo de decir eso GC dificulta la capacidad de evitar fugas.
La recolección de basura no es una solución milagrosa contra las fugas de recursos.
Por contraintuitivo que parezca, observe las aplicaciones con más fugas que existen en la actualidad: aquellas en las que cuanto más las usa, más y más el uso de la memoria sigue aumentando. Por lo general, no son aplicaciones C o C ++. Las aplicaciones C / C ++ pueden ser conocidas por fallar, pero no tanto por tener fugas. Los que tienen fugas se programan con mucha más frecuencia en lenguajes con recolección de basura.
Por ejemplo, tomemos los juegos Flash. Hay muchos, y no solo software completo para aficionados, que usan cada vez más recursos y se vuelven más y más lentos cuanto más tiempo juegas, lo que te obliga a reiniciar tu navegador a veces para que el juego vuelva a ser rápido. Sin embargo, están codificados en ActionScript, un lenguaje que tiene recolección de basura.
En teoría, la recolección de basura debería reducir las fugas. En la práctica, a menudo elimina las fugas físicas más baratas y fáciles de reparar y detectar (¡vaya! Olvidé eliminar esto string) a cambio de las fugas lógicas mucho más caras y difíciles de aislar (vaya, la lógica del sistema hace que los recursos voluminosos permanezcan hasta que se apaga todo el juego).
Esto se debe a que en un lenguaje GC, si desea crear propiedad compartida de un nuevo recurso, R, todo lo que tiene que hacer es almacenar un identificador / referencia a él en otro objeto, A. B y C también podría almacenar un asa para R, y ahora R tiene tres propietarios y solo se liberará si los tres propietarios publican la referencia. El usuario solo ve y trabaja con lo que A tiendas, por lo que la lógica del juego implica eliminar R de A periódicamente, pero las referencias a él persisten en B y C silenciosamente que el código se olvidó de liberar. En C / C ++, el puntero colgante aquí en B y C en realidad, puede ser preferible, ya que conduciría a un problema inmediatamente detectable y corregible durante la prueba de juego, donde el desarrollador que ejecuta un depurador detectará y solucionará el problema muy rápidamente. En un lenguaje GC, es extremadamente difícil de detectar y, si bien el programa no se bloqueará, puede comenzar a filtrarse a lo grande.
Entonces GC definitivamente evita punteros colgantes, pero si algo hubiera estado colgando en C / C ++ y no estaría colgando en un lenguaje GC, entonces es una fuga de recursos lógicos en un lenguaje GC y una falla de segmentación en C / C ++. Dicho de otra manera, GC intercambia punteros colgantes por recursos colgantes que perduran para siempre. Intercambia lo que sería un choque deslumbrante en una fuga silenciosa que puede ser una pesadilla de depuración para descubrir (e incluso puede pasar desapercibida mucho después de lanzar el producto). Entonces, para algo como un juego que está creando mundos masivos y dinámicos, gráficos y objetos físicos y así sucesivamente y posiblemente en cada cuadro, las fugas de recursos lógicos son un gran problema.
La recolección de basura es mejor cuando las fugas de recursos no son un gran problema.
Desafortunadamente, este escenario anterior es demasiado común en un entorno de equipo a gran escala que usa GC, especialmente si todos los programadores no son muy cautelosos con los peligros de la recolección de basura y la gran necesidad de referencias débiles. Entonces, GC no es necesariamente algo para citar como una ventaja para hacer juegos, a menos que solo estés hablando del tipo de lógica humana de más alto nivel. La delicada lógica del sistema de nivel inferior que tiene que crear y acceder y destruir recursos constantemente, en general, obtendrá mejores resultados, incluso en términos de evitar fugas, sin ella.