hechos - Motores de juegos de Java
motores graficos 2d (7)
He estado investigando el desarrollo de juegos recientemente y mi primer lenguaje de programación es Java. Después de jugar muchos juegos impresionantes desarrollados en c ++, me pregunté por qué Java no se usa mucho en la industria de los juegos. Miré jMonkeyEngine 3 y algunos otros entornos de motor de juego, pero las capturas de pantalla que vi son mucho menos impresionantes. Los títulos como Need for Speed Hot Persuit de EA y Assassins Creed de ubisoft transmiten tal realismo. ¿Por qué Java no puede producir tales juegos de la industria? ¿Es la obra de arte?
Java y C # tiene recolección automática de basura y c ++ no. El programador debe prestar más atención al uso de la memoria para evitar los punteros colgantes, etc.
Gracias chicos.
Java y C # tiene recolección automática de basura y c ++ no. El programador debe prestar más atención al uso de la memoria para evitar los 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 realizar optimizaciones muy agresivas que superan las que se pueden realizar durante el análisis estático; La recolección de basura puede hacer que los cuadros se caigan en el peor momento.
Además, para tareas de 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 los punteros de conversión para reinterpretar los datos).
Otro asunto importante es el know how ya establecido en la industria. La inercia de C ++ en la industria de los juegos es enorme. Todos los desarrolladores de juegos hoy en día conocen C y C ++. Tener un gran grupo de desarrolladores para contratar disminuye uno de los riesgos de la administración que son las personas clave 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 presenta gráficos de vanguardia, ya que el énfasis se pone más en la naturaleza dinámica del entorno virtual.
Y muchos otros juegos y motores tienen un tiempo de ejecución que soporta un lenguaje de scripts administrado (asignación y memoria automática segura) construido sobre una plataforma de alto rendimiento de rendimiento y redes (escrita en C / C ++), como Unreal Engine, por ejemplo.
En general, todo lo que se dice aquí fue una razón para no portar a Java para el desarrollo de juegos; era La industria del juego está actualmente en un cambio de paradigma . Tres cosas han cambiado o están cambiando actualmente la industria del juego:
- Piratería
- Modelos de programa cliente-servidor.
- Modelos de programas de redes modulares.
Un juego ya no depende completamente de sí mismo. Las ventajas clave que existían en los primeros (lenguajes de bajo nivel) están disminuyendo, ya que no se sopesan con las ventajas que existen dentro de lenguajes como C # y Java (lenguajes de alto nivel). Dos ejemplos crudos pero innegables son los juegos que funcionan en Facebook y los medios remotos como teléfonos, tabletas, etc.
Es importante indicar que en los dos escenarios, las tres preocupaciones enumeradas anteriormente se disuelven. Un juego que no puede funcionar sin un servidor no tiene que preocuparse de que se copie la copia (no se incluye el hosting privado a través de ingeniería inversa). La demanda de juegos dependientes de la red requiere un lenguaje que pueda equilibrar el rendimiento del sistema con el rendimiento de la red (generalmente un punto muerto entre Java y C / C ++, favoreciendo C / C ++ estrictamente debido a la abundancia de bibliotecas preexistentes). Sin embargo, un juego diseñado en un módulo de programa de redes modulares no sería práctico para desarrollarlo 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 redes modulares tendría que crear una máquina virtual totalmente dedicada a ese juego, o reprogramar / recompilar el juego varias veces demasiado loco para pensar. OMI, aunque puede ser demasiado pronto para decir qué idioma es el preferido, estoy apostando por Java por tres razones clave.
1) La JVM permite que las aplicaciones basadas en Java se ejecuten virtualmente en cualquier plataforma, ya sea derivada de Apple, Android, Windows 8 o Linux / UNIX (también de soporte en cualquier plataforma de hardware).
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, solo tiene un retroceso. Prácticamente todos los sistemas operativos que pueden ejecutar juegos podrán reproducirse en OpenGL y el diseño modular está impulsando esto como nunca antes. (Tenga en cuenta que Microsoft está tratando de desviar este problema al monopolizar 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, esta es una desventaja para todos los demás idiomas (especialmente los desarrollados para teléfonos).
Si bien la JVM plantea un problema de latencia, se debe tener en cuenta que dichas preocupaciones podrían eliminarse mediante el subprocesamiento. Tampoco estaría demasiado preocupado por Windows 8 y el empuje de Microsoft. Google tiene una participación de $ 720 por acción, Apple tiene $ 526 por acción y 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 #, por otro lado, es probable que Google se beneficie de él. Microsoft nunca ha tenido mucha suerte al competir contra Google y Google / Android usa mucho Java. Angry Birds se diseñó originalmente en Java FYI y se cargó a C # para el iPhone. Si Google / Android impone la estandarización, Microsoft caerá como una mosca, llevando a Apple con ellos.
Fortran y James ya lo cubrieron bastante bien, pero hay otra cosa que me gustaría mencionar, que Fortran aludió al hablar de inercia, es el gigantesco conjunto de bibliotecas disponibles en C ++. Tener varias bibliotecas de C ++ para casi cualquier cosa que puedas imaginar es una razón enorme para no cambiar a Java. Eso no quiere decir que no haya bibliotecas para Java en este momento, pero las de C ++ ya están maduras y tienen grandes comunidades de desarrolladores con experiencia. No tener que volver a escribir lo mismo que has hecho 1000x antes es un gran ahorro de tiempo.
La respuesta a su pregunta es arte y recursos financieros. Y originalmente Minecreft fue desarrollado por una persona en Java. Mientras que los títulos como AC o NFS se desarrollan a partir de equipos de miles de personas. Compara los recursos. Además, Ubisoft utiliza el motor de juego custrom. Si usted es el único desarrollador, debe centrarse en la idea debido a la falta de recursos. Y si tienes una idea, el coleccionista de garbege no se puede ver en los juegos normales de desarrolladores únicos. Y como desarrollador único, debe elegir la tecnología de desarrollo más rápida.
No es del todo cierto que la recolección de basura no se utilice en la industria del juego. Unreal Engine 3 ha implementado la recolección de basura para las clases ''Script''. Para ellos, el rendimiento es aceptable cuando se usa a la ligera; el trabajo pesado se realiza mediante el código C / C ++ que administra su propia memoria.
Como dijo Fortran, Java no se usa realmente en la industria de los juegos debido a preocupaciones sobre la velocidad (Java ejecuta código en una máquina virtual, no de forma nativa ... la mayoría de las veces) y porque ya hay una gran cantidad de programadores de juegos con talento que tienen Escrito mucho código frecuentemente usado en C y C ++. Eso no quiere decir que no pueda usar Java para hacer un juego, porque hay algunos juegos de Java por ahí, pero la industria de los juegos ''mainstream'' ha invertido mucho en un back-end C / C ++.
Puedes encontrar juegos escritos en java (motor jmonkey escrito totalmente en java).
Aquí -> " http://www.indiedb.com/engines/jmonkeyengine/games ".
1. mundo en ascenso.
2.minecraft.
3.mynthurana.
Todo en motor jmonkey. La calidad de sus gráficos es intensa y los desafíos son buenos.
Quería abordar solo un tema secundario de esta pregunta, pero la recolección de basura no es necesaria para crear los aspectos críticos de bajo nivel de un motor de juego de tipo AAA. De hecho, es útil evitar ese tipo de sistema de referencia y colección para objetos. Usted quiere que incluso los tipos definidos por el usuario sean contiguos en la memoria y que se ajusten a los objetos adyacentes en el caché, etc.
Aparte de los problemas de rendimiento de la recolección de basura a intervalos periódicos y de la dispersión de los objetos en la memoria, los juegos no pueden permitirse perder con sus recursos más voluminosos, y el recolector de basura dificulta las cosas allí. Sí, acabo de decir que el GC dificulta la capacidad de evitar fugas .
La recolección de basura no es una bala de plata contra las fugas de recursos.
Por contra-intuitivo que parezca, mire las aplicaciones más importantes que existen hoy en día: aquellas en las que cuanto más las use, más y más seguirá aumentando el uso de la memoria. Normalmente no son aplicaciones C o C ++. Las aplicaciones C / C ++ pueden ser conocidas por fallar, pero no tanto por fugas. Los que tienen fugas son mucho más programados en idiomas con recolección de basura.
Por ejemplo, tomar juegos flash. Hay muchos por ahí, y no solo un software amateur completo, que usa más y más recursos y se vuelve más lento y lento a medida que juegas, lo que te obliga a reiniciar tu navegador para obtener el juego rápido otra vez. Sin embargo, están codificados en ActionScript, un lenguaje que tiene recolección de basura.
En teoría, la recolección de basura debe reducir las fugas. En la práctica, a menudo elimina las fugas físicas más baratas y más fáciles de reparar y detectar (whoops, olvidé eliminar esta cadena) a cambio de las fugas lógicas mucho más caras y difíciles de aislar (whoops, la lógica de el sistema hace que los recursos voluminosos permanezcan hasta que se cierre todo el juego).
Esto se debe a que, en un lenguaje de GC, si desea crear la propiedad compartida de un nuevo recurso, R , todo lo que tiene que hacer es almacenar un identificador / referencia en otro objeto, A B y C también pueden almacenar un identificador en R , y ahora R tiene tres propietarios y solo se liberará si los tres propietarios liberan la referencia. El usuario solo ve y trabaja con lo que A almacena, por lo que la lógica del juego consiste en eliminar R de A periódicamente, pero las referencias a él permanecen en B y C silencio, lo que el código olvidó liberar. En C / C ++, el puntero colgante aquí en B y C puede ser realmente preferible, ya que conduciría a un problema inmediatamente detectable y corregible durante las pruebas 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 bloquea, puede comenzar a filtrarse a lo grande.
Así que GC definitivamente evita los punteros colgantes, pero si algo hubiera estado colgando en C / C ++ y no colgaría en un lenguaje GC, entonces es una fuga de recursos lógicos en un lenguaje GC y una falla de seguridad en C / C ++. Dicho de otra manera, GC intercambia punteros colgantes por recursos colgantes que perduran por siempre. Intercambia lo que sería un choque evidente en una fuga silenciosa que puede ser una pesadilla de depuración por descubrir (e incluso puede pasar desapercibida mucho después de lanzar el producto). Así que para algo como un juego que está creando mundos masivos y dinámicos, objetos gráficos y físicos, etc., y posiblemente en cada marco, las fugas de recursos lógicos son una gran cosa.
La recolección de basura es mejor cuando las filtraciones 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 cada programador no es muy cauteloso con los escollos de la recolección de basura y la fuerte necesidad de referencias débiles. Por lo tanto, GC no es necesariamente algo que citar como una ventaja para hacer juegos, a menos que solo esté hablando sobre el tipo más alto de lógica humana. La lógica del sistema delicado de nivel inferior que tiene que crear y acceder a los recursos constantemente y destruirlos generalmente tendrá mejores resultados, incluso en términos de evitar fugas, sin ellos.