¿Por qué Java no se usa más ampliamente para el desarrollo de juegos? [cerrado]

No soy desarrollador de juegos ni nada, pero sé que Java no se usa mucho para el desarrollo de juegos. Java debería ser lo suficientemente rápido para la mayoría de los juegos, entonces, ¿dónde está la trampa? Se me ocurren algunas razones:

• Falta de desarrolladores de juegos con experiencia en Java
• Falta de buenos marcos de desarrollo de juegos
• Los programadores no quieren aceptar Java como lenguaje de programación de juegos. ¿La mayoría solo acepta C ++ como eso?
• No hay soporte para consolas de juegos (aunque el mercado de PC todavía existe)

Por supuesto, podría ser otra cosa. ¿Podría alguien que conoce el negocio mejor que yo explicar por qué Java no está ganando impulso en lo que respecta al desarrollo de juegos?

Muchas rasones:

• En los viejos tiempos, necesitabas "acceso directo" para el rendimiento y la interfaz de usuario. Esto es anterior a los lenguajes VM como Java y C #.
• La mayoría de las consolas (por ejemplo, 360, PS3) no tienen una JVM, por lo que no puede reutilizar el código de la versión para PC. Es mucho más fácil compilar código C ++ para admitir varios dispositivos.
• La mayoría de los motores de juego convencionales (p. Ej., Unreal) tienen enlaces C ++. Hay algunos conectores Java (por ejemplo, para OpenGL) pero nada parecido.
• Para juegos de PC, DirectX realmente no tiene un fuerte soporte de Java (si es que lo tiene).
• Los juegos basados ​​en web se ejecutan en JavaScript o Flash. Podrías escribirlos en Java usando cosas como GWT.
• El iPhone ejecuta una variante Objective-C.

Java se usa principalmente en juegos de Android en estos días, simplemente porque es el idioma principal de esa plataforma.

Razones técnicas:

• La mayoría de los mejores motores de juegos 3D están escritos en C / C ++. Esto es un gran problema, ya que la mayoría de los desarrolladores de juegos no quieren comprometer su motor 3D, pero tampoco quieren escribir uno desde cero. Java tiene jMonkeyEngine, que es de código abierto y realmente bueno, pero aún no puede competir con el motor Unreal .
• Para una situación muy rara, hay ventajas en acercarse al metal en lenguaje C o ensamblador, específicamente para acceder a funciones especiales de hardware. Esto no es tan importante hoy en día, pero a los desarrolladores profesionales de juegos todavía les gusta tener la opción .....
• Java tiene una basura recolectada , tiempo de ejecución administrado. El 99% de las veces, esta es una gran ventaja, sin duda hace que la codificación sea más fácil y menos propensa a errores y es una de las principales razones por las que Java es tan popular. Sin embargo, ocasiona un problema de latencia ocasional para los juegos, ya que los ciclos de recolección de basura pueden causar pausas notables. Esto se está convirtiendo en un problema menor con las nuevas JVM de baja latencia, pero sigue siendo un problema para los juegos con gran cantidad de gráficos donde mantener un alto FPS es crítico.

Razones no técnicas:

• Las casas de desarrollo de juegos profesionales están fuertemente invertidas en habilidades y tecnologías C / C ++. Esto crea una gran cantidad de inercia .
• La percepción en gran medida irracional de que Java es lento. Posiblemente cierto en los años 90, definitivamente no es cierto ahora: ciertamente puede escribir un juego 3D comercial rentable con Java (¿ Runescape cualquiera? ¿O qué tal Minecraft ?)
• Una percepción bastante justa de que Java se centra más en las aplicaciones comerciales y en la web que en los juegos. Esto podría cambiar con el crecimiento de Mobile y la necesidad de un mayor desarrollo multiplataforma, pero ciertamente es cierto en la actualidad.

Curiosamente, también hay algunas buenas razones por las cuales los desarrolladores de juegos deberían considerar Java:

• Portabilidad : a medida que prolifera la cantidad de plataformas objetivo, Java se vuelve cada vez más atractivo con su capacidad prácticamente incomparable para crear binarios genuinamente multiplataforma
• Ecosistema de bibliotecas : con la excepción muy importante de los motores de juegos en 3D, Java tiene la mejor gama de bibliotecas en general de cualquier plataforma. Redes, sonido, IA, procesamiento de imágenes, almacenes de datos de clave / valor, usted nombra el tema y probablemente haya una biblioteca Java de código abierto para ello.
• Desarrollo del lado del servidor : Java es un gran lenguaje / plataforma para el servidor, y a medida que más juegos incorporen elementos multijugador masivos, el lado del servidor será cada vez más importante. Java en Linux se ve bastante convincente aquí como plataforma.
• El JVM es probablemente el entorno de ejecución de VM mejor diseñado del mundo, con una fantástica recolección de basura, un compilador JIT, soporte de concurrencia, etc. El mejor entorno de tiempo de ejecución posible.
• Otros lenguajes JVM : Java es un caballo de batalla sólido, pero la verdadera innovación está ocurriendo con los nuevos idiomas JVM (Scala, Clojure en particular). Estos lenguajes obtienen todas las ventajas de la plataforma Java / JVM, además de ser lenguajes modernos extremadamente poderosos.

De acuerdo, hay mucha información errónea en este hilo.

Conozco muy bien el negocio del juego , después de haber estado en él durante 25 años. También conozco Java en juegos extremadamente bien después de haber sido el evangelista técnico de Sun Java Game y ser experto en programación de rendimiento de Java.

En términos de velocidad computacional, Java supera a C ++ en muchos puntos de referencia de computación científica en la actualidad. Puede escribir código patológico en cualquier idioma que funcione mal si lo desea, pero sobre todo, están a la par y lo han estado durante mucho tiempo.

En términos de uso de memoria, Java tiene algunos gastos generales. HelloWorld es un programa 4K en Java. Pero esa sobrecarga no tiene sentido en los sistemas multi GB de hoy. Finalmente, Java tiene más tiempo de inicio. No recomendaría usar Java para utilidades de tiempo de ejecución corto como los comandos de línea de comandos de Unix. En esos casos, el inicio dominará su rendimiento. Sin embargo, en un juego, es bastante insignificante.

El código de juego Java escrito correctamente no sufre pausas de GC. Al igual que el código C / C ++, requiere una gestión de memoria activa pero no al nivel que C / C ++ requiere. Mientras mantenga su uso de memoria en objetos de larga vida (persisten durante un nivel o juego completo) y en objetos de vida muy corta (vectores y demás, pasados ​​y rápidamente destruidos después del cálculo) gc no debería ser un problema visible.

En términos de acceso directo a la memoria, Java lo ha tenido por MUCHO tiempo; desde Java 1.4 en forma de Buffers de bytes directos nativos. El giro de bits en Java puede ser un poco molesto debido a la falta de tipos enteros sin signo, pero las rondas de trabajo son bien conocidas y no son terriblemente onerosas.

Si bien su verdadero Java nunca ha tenido un enlace Direct3D, eso se debe a que las tecnologías Java se esfuerzan por la portabilidad. Tiene DOS enlaces OpenGL (JOGL y LWJGL) y enlace OpenAL (JOAL) y un enlace de entrada portátil (JInput) que se une bajo el capó a DirectInput en Windows, HID Manager en OSX y un enlace Linux (se me olvida cuál).

Es cierto que ningún motor de juego completo ha presentado Java como, por ejemplo, Unity, ha presentado C # y eso es una debilidad en el espacio independiente. Por otro lado, había dos buenos APIS de nivel de Scenegraph que eran totalmente compatibles con plataformas en Windows, OSX y Linux. Ambos escritos por Josh Slack, el primero se llamaba motor JMonkey y el segundo Ardor3D.

El cartel superior es correcto en cuanto a que las dos cosas más importantes que retrasaron a Java en el desarrollo del juego fueron los prejuicios y la portabilidad. Este último fue el mayor problema. Aunque podía escribir un juego Java y enviarlo en Windows, OSX y Linux, nunca hubo una consola VM. Esto se debió a la ineptitud total en la administración intermedia de Sun. Los pocos de nosotros que trabajamos en Java en juegos en realidad tuvimos acuerdos con Sony no menos de 3 veces para obtener una VM en una Playstation y las 3 veces que la gerencia media de Sun la mató.

Si bien Sun coqueteó con las tecnologías de los clientes, el hecho es que la administración de Sun nunca obtuvo productos de consumo. Es por eso que Java como lenguaje de cliente de Sun nunca tuvo éxito de ninguna forma, y ​​por qué tomó Google y Dalvik (la VM de Java similar a Android) para hacer de Java una plataforma exitosa en cualquier lugar.

Y es por eso que codifico juegos en C # hoy. Porque Mono fue a donde la dirección de Sun se negó.

Java es ideal para la lógica empresarial, los servidores y el código independiente de la plataforma que tiene que ejecutarse de manera confiable. Hay varios factores por los que Java no se usa con frecuencia en los juegos:

• comprobación de límites y otros mecanismos de seguridad (diferencia de rendimiento marginal en estos días)
• tener que convertir entre estructuras de datos C ++ y estructuras de datos Java (no puede simplemente copiar memoria entre buffers)
• muchos de los libros y tutoriales siguen a la multitud, por lo que es difícil encontrar información de desarrollo de juegos que no sea C ++
• Las bibliotecas de gráficos principales (DirectX y OpenGL) y muchos motores estándar están basados ​​en C / C ++
• muchos juegos intentan ejecutarse lo más rápido posible para que puedan agregar funciones visualmente más atractivas

No es fácil trabajar con bibliotecas C ++ a partir de lenguajes de código de bytes como Java (escribir una capa JNI) y .net (muchos atributos de clasificación / descomposición, api / estructura). Por lo tanto, agrega bastante trabajo por poco beneficio.

Una nota al margen: algunos servidores de juegos usan Java.

Publicación similar aquí : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java no es lo suficientemente rápido para la mayoría del desarrollo de juegos. Es mucho más lento que usar C ++ / Assembly, que es el estándar. Es la misma razón por la que no se realiza más desarrollo de juegos usando C # o VB. Los desarrolladores de juegos necesitan y planean cada último ciclo de reloj en el que puedan tener acceso para cosas como cálculos de física, lógica de IA e interacciones del entorno.

Para juegos más simples, Java podría usarse con bastante eficacia. Si desea crear un clon de Tetris o Bejeweled, o algo más de ese nivel de detalle, Java funcionaría bien. Pero Java no puede crear juegos como Halo, Medal of Honor, Command & Conquer, etc., y hacerlo jugable. Al menos como existe hoy en día.

Y las razones que enumeras en tu pregunta también son válidas. Excepto, creo, por la falta de desarrolladores de juegos con experiencia en Java. Muchos juegos en teléfonos y otros dispositivos portátiles están escritos en Java (incluida la mayoría de los juegos de Android), y algunos de los juegos son bastante excelentes. Así que creo que hay una base decente y creciente de desarrolladores de juegos con conocimiento de Java.

La idea está cambiando sobre la capacidad de usar estos lenguajes de nivel superior para algunos de los juegos más avanzados. Por ejemplo, uno de mis juegos favoritos, Auran's Train Simulator, está escrito con grandes porciones en C #, y funciona bastante bien. Entonces la base está creciendo y continuará evolucionando.

Los juegos modernos tienen que ver con gráficos 3D que suceden en hardware de propósito especial.

Incluso en 2002, Jacob Marner descubrió en su informe "Evaluación de Java para el desarrollo de juegos" que Java era bastante utilizable para los juegos, excepto para las partes más dependientes del rendimiento, y debido a la robustez del lenguaje y la JVM subyacente que era más barato para hacerlo de esta manera.

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

Es mi opinión personal que con el progreso que ha sucedido desde entonces, especialmente en gráficos 3D, y con los excelentes enlaces a OpenGL et al, que esta desventaja es mucho menos pronunciada en estos días.

Por lo tanto, el problema debe estar en otra parte. Una razón probable es el tamaño del tiempo de ejecución de Java (que es mucho menos un problema en estos días con los juegos de varios DVD), y otra la inercia del código existente. Es notoriamente frágil comenzar a trabajar con código nativo en Java. Una tercera razón es con lo que están familiarizados los desarrolladores estrella que hacen los juegos. Un cuarto es si Java está disponible en la plataforma.

Sin embargo, una cosa es cierta: la mayoría de los juegos se están convirtiendo en scriptables en lugar de quemarlos en código C desde el principio, y desea el mejor tiempo de ejecución debajo de su lenguaje de scripts. En estos días esto esencialmente significa CLR o JVM.

A los desarrolladores de juegos les gusta estar cerca del metal y a menudo escriben sus apretados bucles internos en el ensamblaje. Java no ofrece el mismo nivel de rendimiento posible, tanto en términos de velocidad constante como de uso de memoria (ejecutar un JIT tiene su costo).

Creo que el factor limitante para la mayoría de las personas es la (falta de) disponibilidad de buenos motores de juego. Para llegar muy lejos, debemos ver por qué no están disponibles.

Lo miraría desde la otra dirección por un momento. Desarrollar un motor de juego (por ejemplo) es mucho trabajo. ¿Quién se beneficiaría lo suficiente de desarrollar uno para invertir el tiempo y el esfuerzo para hacerlo?

La mayoría de los candidatos obvios para el desarrollo similar al framework en / para Java (por ejemplo, IBM, Oracle) parecen tener cero interés en los juegos. Los candidatos obvios para el desarrollo de juegos (por ejemplo, Id, EA) parecen tener un interés casi igual en Java.

Casi el único candidato que se me ocurre que parece razonable sería Google. El lenguaje de desarrollo principal para Android es Java, y fomentar el desarrollo de juegos para Android podría proporcionar una ventaja real para la plataforma.

Hasta donde sé, no lo han hecho (¿todavía?), Lo que deja algunos límites bastante severos para casi cualquier otra persona. Sin poco en el camino de los motores de juegos modernos y de alto rendimiento para usar el desarrollo en Java, significa bastante trabajo extra, con (lo que me parece) pocas posibilidades de producir muchos beneficios a cambio de ese trabajo extra.

La pregunta está a la altura de preguntar algo en las líneas de:

Lo que es mejor para impulsar su automóvil, un motor de barco o un motor a reacción.

Se trata de escalabilidad, evitación de errores, velocidad, firma de memoria, modularidad y una gran cantidad de cosas. La pregunta no debe ser sobre qué es mejor como estándar de la industria, la pregunta debe ser "qué es mejor para mí", como lo que sabes o qué tan bien lo sabes. Si hace el trabajo, entonces hace el trabajo, si realmente puede vender la idea, entonces funciona y quién sabe, incluso podría doblar unas cucharas.

Java no se creó teniendo en cuenta el desarrollo de juegos, sino que se creó para ser un lenguaje "para la web".

En cuanto al desarrollo de juegos, Sun realmente no era compatible con Java como lenguaje de desarrollo de juegos, ya que Microsoft respaldaba C #.

Creo que la falta de marcos de desarrollo de juegos convincentes es lo que realmente mató a Java en este aspecto.

Es más fácil pegar C más directamente al nuevo hardware y controladores no convencionales. Cuanto antes y más cerca pueda un programador de juegos del hardware, mejor podrán superar a los juegos de la competencia. Los programadores de juegos posteriores solo siguen la misma metodología y herramientas que los juegos probados anteriores.

Para juegos donde la optimización para el hardware más reciente es menos importante, como los juegos casuales de teléfonos celulares, usar C de esta manera es menos importante que la mayor portabilidad de Java.

Para algunas personas, la razón no tiene nada que ver con la velocidad, las bibliotecas o la disponibilidad. Es simplemente por el lenguaje en sí. A algunas personas simplemente no les gusta el lenguaje Java. Otras personas prefieren usar su lenguaje de programación favorito en lugar de usar Java para hacer juegos.

Por supuesto, podría ser otra cosa. ¿Podría alguien que conoce el negocio mejor que yo explicar por qué Java no está ganando impulso en lo que respecta al desarrollo de juegos?

Es un lenguaje de interpretación, es decir, lento. Estás tratando con tarjetas gráficas y gráficas que son hardware. ¿Qué es un buen lenguaje para lidiar con el hardware? Bueno, C ++, es bastante bajo, y lidias con punteros y lo que sea.

Si desea generar gráficos locos como crysis y lo que sea, no va a hacer Java para ello.

No solo eso, Oracle es dueño de Java, la idea de que una compañía puede demandarlo no se atreve bien. Especialmente cuando desea construir su propio intérprete para JAVA para apuntar a los juegos sin ser demandado debido a la fragmentación del FUD.