¿Por qué solo unos pocos videojuegos están escritos en Java? [cerrado]

¿Por qué no hay muchos videojuegos comerciales en 3D (no aleatorios de código abierto en 2D) escritos en Java? En teoría, tiene mucho sentido: obtienes un impulso de productividad y una aplicación multiplataforma casi gratis, entre otras cosas, como la gran cantidad de bibliotecas Java y la recolección de basura incorporada (aunque admito que ' No estoy seguro de si esto último es algo bueno). Entonces, ¿por qué rara vez se usa? Solo puedo pensar en un par de juegos comerciales populares escritos para la plataforma Java.

¿Es por el rendimiento? Si es así, ¿la GPU no haría la mayor parte del trabajo pesado?

El mundo del desarrollo del juego es divertido: por un lado, a menudo aceptan rápidamente nuevas ideas, por otro lado, todavía están en la edad de piedra.

La verdad es que rara vez hay tantos incentivos para cambiar a .NET / Java / algo que no sea C / C ++.

La mayoría de las compañías de juegos licencian partes del motor de juego de otras compañías. Estas partes están escritas en C ++, y aunque es posible que tenga acceso a la fuente para poder portarlo, eso requiere mucho esfuerzo (y, por supuesto, la licencia debe permitirlo).

Además, ya existe una gran cantidad de código heredado en C ++. Si el código de proyectos anteriores se puede reutilizar (por ejemplo, si está escribiendo una secuela), eso cuenta aún más a favor de quedarse con el mismo idioma, en lugar de reescribirlo en un nuevo idioma (más aún, ya que es probable que reintroduzca una tonelada de errores que necesitarás para pasar el tiempo arreglando.

Finalmente, de todos modos, es raro que los juegos se escriban en 100% C ++: se hace mucho usando lenguajes de script, ya sea personalizados o simplemente integrando idiomas existentes (Lua es uno de los más populares en estos días).

En lo que respecta a la recolección de basura, eso puede ser un pequeño problema. El problema no es tanto que exista, sino más bien cómo funciona: el recolector de basura NO DEBE ser bloqueante (o al menos se garantiza que solo se bloqueará brevemente), ya que es simplemente inaceptable que el juego se congele durante 10 segundos escanea toda la memoria asignada para ver qué se puede liberar. Sé que Java tiende a ahogarse un poco en GC'ing cuando está cerca de quedarse sin memoria (y para algunos juegos, lo hará).

También está un poco más restringido en lo que puede hacer: no puede explotar completamente el hardware debido a la sobrecarga del tiempo de ejecución. Imagina que Crysis está escrito en Java ... incluso si esa es la única diferencia visible, simplemente no sería la misma (también estoy bastante seguro de que necesitarías un Core i7 para ejecutarlo).

Esto no significa que estos lenguajes no tengan su lugar en el desarrollo de juegos, y no, no solo me refiero a la programación de herramientas. Para la mayoría de los juegos, no necesita ese rendimiento adicional que obtiene de C ++, incluidos los juegos en 3D, y si está escribiendo todo desde cero, puede tener mucho sentido usar algo como XNA; de hecho, hay un buena oportunidad lo hará.

En cuanto a los juegos comerciales, ¿ cuenta RuneScape ? Ese podría ser el juego Java más exitoso que existe.

Creo que John Carmack lo dijo mejor con:

El mayor problema es que Java es realmente lento. En un nivel de CPU / memoria / pantalla / comunicaciones puro, la mayoría de los teléfonos celulares modernos deberían ser plataformas de juego considerablemente mejores que un Game Boy Advanced. Con Java, en la mayoría de los teléfonos le queda la potencia de CPU de una PC IBM original de 4.77 mhz y un control pésimo sobre todo. [... recorte ...] Escribir-una vez-ejecutar-en cualquier lugar. Decir ah. Jajajajaja En este momento solo estamos probando en cuatro plataformas, y ni un solo par tiene exactamente las mismas peculiaridades. Todos los juegos comerciales se modifican y compilan individualmente para cada plataforma (a menudo más de 100). La portabilidad no es una justificación para el horrible desempeño.

( fuente )

Por supuesto, estaba hablando de plataformas móviles, pero he encontrado problemas similares con Java en su conjunto provenientes de un entorno C ++. Echo de menos poder asignar memoria en el Stack / Heap en mis propios términos.

Por un lado, la falta de sobrecarga del operador de Java hace que todas las matemáticas con las que tiene que lidiar para obtener una tubería de gráficos que funcionen sean muy, muy molestas y difíciles de leer.

Todos los vectores afines y de multiplicación de matrices con los que necesita tratar son mucho más fáciles de seguir si están en expresiones matemáticas bien formadas en lugar de expresiones orientadas a objetos como

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

Eso es simplemente terrible. Las matemáticas no deberían verse así.

Creo que .NET tuvo (tiene) muchos de los mismos problemas percibidos que tiene Java. Microsoft acaba de hacer un mejor trabajo en marketing para desarrolladores con XNA :-)

Puntos menores primero:

• Cualquier aumento de la productividad de Java es hipotético. La sintaxis es casi idéntica a C ++, por lo que realmente solo cuenta con los ahorros de la administración de memoria y las bibliotecas estándar. Las bibliotecas tienen poco que ofrecer a los desarrolladores de juegos y la administración de memoria es un tema polémico debido a la recolección de basura.

• multiplataforma "gratis" no es tan bueno como cree porque pocos desarrolladores quieren usar OpenGL y varias plataformas clave probablemente carecen de una buena implementación de Java o envoltorios para sus bibliotecas nativas, ya sea para gráficos, audio, redes, etc.

Pero principalmente, el problema es la compatibilidad con versiones anteriores. Los desarrolladores de juegos se trasladaron a C ++ desde C y hacia C desde el ensamblaje simplemente porque la ruta de migración era fluida. Cada uno interactúa estrechamente con el anterior, y todo su código anterior era utilizable en el nuevo lenguaje, a menudo a través de un único compilador. Por lo tanto, la migración fue tan lenta o tan rápida como quisiera. Por ejemplo, algunos de nuestros encabezados antiguos en uso todavía tienen #ifdef WATCOMCy no creo que nadie haya usado el compilador de Watcom aquí en una década o más. Hay una inversión masiva en código antiguo y cada bit solo se reemplaza según sea necesario. Ese proceso de reemplazar y actualizar partes y piezas de un juego a otro no es tan práctico si cambias a un idioma que no interopera de forma nativa con tu código existente. Sí, la interoperabilidad de C ++ / Java es posible, pero muy poco práctica en comparación con simplemente escribir "C con un poco de C ++" o incrustar bloques asm en C.

Para reemplazar correctamente C ++ como el lenguaje de elección de los desarrolladores de juegos, debe hacer una de dos cosas:

1. Sea fácilmente interoperable con el código heredado existente, preservando así la inversión y manteniendo el acceso a las bibliotecas y herramientas existentes, O
2. Demostrativamente muestra un aumento de productividad lo suficientemente adelantado como para que el costo de reescribir todo su propio código (o reelaborar las interfaces en componentes reutilizables que puedan usarse desde ese idioma) esté más que cubierto.

Subjetivamente, no creo que Java cumpla con ninguno de esos. Un lenguaje de nivel superior podría cumplir con el segundo, si alguien es lo suficientemente valiente como para ser el pionero. (EVE Online es probablemente el mejor ejemplo que tenemos de Python siendo utilizable, pero que utiliza una bifurcación del lenguaje principal de Python, muchos componentes C ++ para el rendimiento, e incluso eso es para un juego bastante poco exigente en términos modernos).

Estoy jugando a Los Sims 3, e hice algunas hurgadas. El motor de gráficos es C ++, mientras que el motor de secuencias de comandos y comportamiento es C # / Mono. Entonces, aunque C ++ está allí para bits críticos de tiempo, otras cosas como interacción, lógica de juego, AI está en un lenguaje administrado orientado a objetos.

• ¿Hay algún buen puerto de motores de juego / bibliotecas?
• Muchos desarrolladores de C / C ++, particularmente los de Windows (donde se escriben la mayoría de los juegos comerciales) están familiarizados con Visual Studio. No hay comparación en IDEs.
• En general, Java se ha vendido a las empresas debido a su tipografía sólida y tiene la percepción de no tener problemas de administración de memoria.
• Y sí, Java aún sufre la percepción de que es lenta, y su administración de memoria es deficiente, y para los juegos, probablemente no sea adecuada para la tarea. Como se indicó en algunas de las otras respuestas, la recolección de basura simplemente no va a ser suficiente cuando se trata de requisitos de alto rendimiento en tiempo real. Los videojuegos llevan las CPU y GPU a sus límites.

Una de las principales razones por las que Java y otros lenguajes de máquinas virtuales no se utilizan para los juegos se debe a Garbage Collection. Lo mismo ocurre con .NET. La recolección de basura ha recorrido un largo camino y funciona muy bien en la mayoría de los tipos de aplicaciones. Sin embargo, para realizar la recolección de basura, debe pausar e interrumpir la aplicación para recolectar la basura. Esto puede causar un retraso periódico cuando ocurre la recolección.

Java tiene el mismo problema para las aplicaciones en tiempo real. Cuando las tareas deben ejecutarse en un momento específico, es difícil que una tarea automatizada como la recolección de basura lo respete.

No es que Java sea lento. Es que Java no es bueno para manejar tareas en tiempo real.

Una razón importante es que los videojuegos requieren un conocimiento directo del hardware que se encuentra debajo, a menudo, y realmente no hay una gran implementación para muchas arquitecturas. Es el conocimiento de la arquitectura de hardware subyacente lo que permite a los desarrolladores exprimir cada onza de rendimiento de un sistema de juego. ¿Por qué tomaría el tiempo de transferir Java a una plataforma de juego y luego escribir un juego sobre ese puerto cuando podría simplemente escribir el juego?

editar: esto quiere decir que es más que un problema de "velocidad" o "no tengo las bibliotecas correctas". Esas dos cosas van de la mano con esto, pero es más una cuestión de "¿cómo hago para que un sistema como la celda ejecute mi código Java? Realmente no hay ningún buen compilador de Java que pueda administrar las tuberías y los vectores como necesito .. "

El problema de rendimiento es la primera razón. Cuando vea el tipo de código C ++ hiper optimizado que hay en los motores Quake ( http://www.codemaestro.com/reviews/9 ), sabrá que no perderán su tiempo con una máquina virtual.

Claro que puede haber algunos juegos .NET (¿cuáles? Me interesa. ¿Hay algunos realmente intensivos en CPU / GPU?), Pero supongo que es más porque mucha gente es experta en tecnologías de MS y siguió a Microsoft cuando lanzaron Su nueva tecnología.

Ah, y multiplataforma simplemente no está en la mente de las compañías de videojuegos. Linux es solo alrededor del 1% del mercado, Mac OS un poco más. Definitivamente piensan que no vale la pena deshacerse de las tecnologías y bibliotecas exclusivas de Windows como DirectX.

También puede preguntar por qué las aplicaciones web no están escritas en C o C ++. El poder de Java reside en su pila de red y diseño orientado a objetos. Por supuesto, C y C ++ también tienen eso. Pero en una abstracción más baja. Eso no es nada negativo, pero no quieres reinventar la rueda cada vez, ¿verdad?

Java tampoco tiene acceso directo al hardware, lo que significa que está atascado con la API de cualquier marco.

Mis ideas erróneas sobre el rendimiento y las optimizaciones de JVM pobres serían mi suposición. Digo conceptos erróneos sobre el rendimiento porque hay algunos puertos Java de juegos C ++ que funcionan más rápido que sus contrapartes C ++ (ver Jake 2). El verdadero problema, en mi humilde opinión, es que muchos programadores de Java no se centran tanto en el rendimiento de vanguardia como lo son con la facilidad de uso y la comprensión / mantenibilidad del código. En el lado C / C ++ de las cosas, básicamente está codificando en un lenguaje ensamblador de nivel ligeramente más alto y está lo más cerca posible del hardware sin escribir en ensamblador o código máquina directo.

La lista de motores de juegos en Wikipedia enumera muchos motores de juegos junto con el lenguaje de programación en el que están escritos.

Hay varios motores de juegos Java listados.

Al hacer clic en algunos de los enlaces, encontrará ejemplos de juegos y demostraciones escritos en Java. Aquí hay una pareja:

• Ardor3D
• Software Bytonic

Para ciertos juegos y situaciones, las compensaciones de Java pueden ser aceptables.

.NET definitivamente tiene algunos de los mismos problemas que Java cuando se trata de un rendimiento 3D intenso. Microsoft también ha invertido mucho más tiempo y dinero en el desarrollo de las bibliotecas a la hora de trabajar con operaciones pesadas en 3D.

(... personalmente, también creo que tenían una ventaja cuando se trata de la magia entre DirectX y .NET)

1. Java es lento, la GPU no maneja la mayor parte del trabajo pesado. Todavía hay animación, física e IA en la CPU, todo lo cual consume mucho tiempo.

2. Java no existe en las consolas, y las consolas son un objetivo importante para los juegos comerciales. Si usa Java en la PC, está eliminando su capacidad de portar a consolas dentro de un tiempo y presupuesto razonables.

3. Muchos de los codificadores más experimentados en la industria del juego han estado usando C y C ++ mucho antes de que Java se hiciera popular. Los dos puntos anteriores pueden contribuir a esto, pero espero que muchos programadores profesionales de juegos simplemente no conozcan Java tan bien.

4. El punto de otra persona sobre el middleware anterior fue bueno, así que lo estoy agregando a mi respuesta. Hay mucho código heredado y middleware escrito específicamente para vincular con C / C ++, y la última vez que verifiqué que Java no tiene una buena interoperabilidad. El uso de Java para la mayoría de las empresas implicaría tirar una gran cantidad de código, gran parte del cual se ha pagado de una forma u otra.

En realidad, es muy posible que el código administrado haga juegos en 3D, el problema son los motores traseros. Con .Net, durante un breve período, hubo un contenedor DirectX administrado para DirectX 9 de Microsoft. Esto fue antes de la abstracción que ahora es XNA.

Al tener acceso total a la API de DirectX, los juegos .Net funcionan de maravilla. El mejor ejemplo que conozco es www.entombed.co.uk, que está escrito en VB.Net.

Desafortunadamente, en el lado de Java, carece seriamente, principalmente por la razón de que DirectX no está disponible para Java, y los programadores de juegos conocen y entienden la API de DirectX, ¿por qué aprender otra API cuando regrese a DirectX?

El marketing de juegos es un proceso comercial; Los editores quieren retornos cuantificables de bajo riesgo sobre su inversión. Como consecuencia, el enfoque generalmente está en trucos tecnológicos (con excepciones) que los consumidores comprarán para producir un rendimiento confiable; estos tienden a ser efectos visuales superficiales como el deslumbramiento de lentes o una resolución más alta. Estos efectos son confiables porque simplemente usan aumentos en la potencia de procesamiento: explotan los aumentos de hardware / ley de Moore. Esto implica el uso de C / C ++: Java generalmente está demasiado abstraído del hardware para explotar estos beneficios.

Supongo que la velocidad sigue siendo el problema. La multiplataforma será un problema, ¿no es así, ya que no sabes qué tarjeta 3D está disponible cuando escribes el código? ¿Tiene Java algo para admitir el descubrimiento automático de capacidades 3D? Y supongo que hay herramientas para facilitar la transferencia de un juego entre wii, xbox y ps3, pero apuesto que es costoso.

La ps3 tiene java, a través del soporte de blue ray. Consulte el sitio bd-j.

Incluso los juegos escritos en la plataforma .Net a menudo están altamente optimizados para la velocidad, como el acceso directo a la memoria y el bus. .Net permite usar C / C ++ y mezclarlo con lenguajes de nivel superior como C #.

Los estudios de desarrollo de juegos a menudo trabajan en estrecha colaboración con los proveedores de hardware, que proporcionan acceso a interfaces de bajo nivel de sus productos. Este es un mundo en el que debe usar ASM y C para la comunicación del dispositivo. Un entorno virtual ralentizaría estas partes del programa.

De todos modos, los juegos 3D modernos de hecho usan lenguajes de nivel superior. A menudo, encontrarás la lógica del juego escrita en lenguajes como Lua o Python. Pero el núcleo (E / S, subprocesos, programación de tareas) del típico juego 3D se escribirá en idiomas de bajo nivel durante los próximos 25 años o mientras los dispositivos largos no permitan la abstracción y la virtualización por sí mismos (lo que vendrá).

Estoy de acuerdo con las otras publicaciones sobre el aprovechamiento de elementos de una base de código preexistente / con licencia, rendimiento, etc.

Una cosa que me gustaría agregar es que es difícil sacar trucos desagradables de DRM a través de una máquina virtual.

También creo que hay un componente de arrogancia en el que los gerentes de proyecto creen que pueden crear código estable / confiable con C ++ con todas las ventajas, como tener un control absoluto sobre sus herramientas y recursos, PERO sin todos los aspectos negativos que complican y empantanan a su competencia porque "nosotros" son más inteligentes de lo que son ".

Runescape by Jagex está escrito en Java, la etiqueta de "videojuego" podría no aplicarse específicamente como un juego en línea, pero tiene un seguimiento decente.

Ya se habló mucho de eso, incluso puedes encontrar en Wiki las razones ...

• C / C ++ para el motor del juego y todas las cosas intensivas.
• Lua o Python para las secuencias de comandos en el juego.
• Java: muy, muy mal rendimiento, gran uso de memoria + no está disponible en consolas de juegos (se usa para algunos juegos muy simples (Sí, Runescape cuenta aquí, no es Battlefield o Crysis o qué más hay) simplemente porque hay muchos programadores que conocen este lenguaje de programación).
• C #: gran uso de memoria (se usa para algunos juegos muy simples solo porque hay prácticamente programadores que conocen este lenguaje de programación).

Y escucho a más y más programadores de Java que intentan convencer a las personas de que Java no es lento, no es lento para dibujar un widget en la pantalla y dibujar algunos caracteres ASCII en el widget, para recibir y enviar datos a través de la red (y es se recomienda usarlo en estos casos (manipulación de datos de red) en lugar de C / C ++) ... Pero es muy lento cuando se trata de cosas serias como cálculos matemáticos, asignación / manipulación de memoria y muchas de estas cosas buenas.

Recuerdo un artículo en el sitio del MIT donde muestran lo que C / C ++ puede hacer si usa las características del lenguaje y del compilador: un multiplicador matricial (2 matrices), 1 implementación en Java y 1 implementación en C / C ++, con características C / C ++ y activadas las optimizaciones del compilador apropiadas, la implementación de C / C ++ fue ~ 296 260 veces más rápida que la implementación de Java.

Espero que entiendas ahora por qué las personas usan C / C ++ en lugar de Java en los juegos, imagina Crysis en Java, no habría ninguna computadora en este mundo que pudiera manejar eso ... + La recolección de basura funciona bien para Widgets que acaban de destruir una imagen pero todavía está almacenado en caché allí y necesita ser limpiado, pero no para juegos, seguro, tendrás aún más retrasos en cada activación de recolección de basura.

Editar : Debido a que alguien solicitó el artículo, aquí, busqué en el archivo web para obtenerlo, espero que esté satisfecho ... Estudio de caso del MIT

Y para agregar, no, Java para juegos sigue siendo una idea horrible. Hace solo unos días, una gran empresa que no nombraré comenzó a reescribir su cliente de juegos de Java a C ++ porque un juego muy simple (en términos de gráficos) estaba retrasado y calentaba las computadoras portátiles i7 con potentes tarjetas de video nVidia GT 5xx y 6xx generación ( no solo nVidia, el punto aquí es que estas poderosas tarjetas que pueden manejar la configuración Max de la mayoría de los juegos nuevos y no pueden manejar este juego) y el consumo de memoria fue ~ 2.5 - 2.6 GB de RAM. Para gráficos tan simples necesita una bestia de máquina.