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

Varios motivos:

• En los viejos tiempos, necesitaba "acceso directo" para el rendimiento y la interfaz de usuario. Esto precede a los lenguajes virtuales 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 el código C ++ para admitir varios dispositivos.
• La mayoría de los motores de juegos principales (por ejemplo, Unreal) tienen enlaces C ++. Hay algunos conectores Java (por ejemplo, para OpenGL) pero no hay nada como esto.
• Para los juegos de PC, DirectX no tiene un soporte de Java sólido (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 de 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 en 3D están escritos en C / C ++. Este 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 en realidad realmente pero aún no puede competir con Unreal Engine .
• Para una situación muy rara, hay ventajas en el hecho de que esté "cerca del metal" en C o en lenguaje ensamblador, específicamente para acceder a funciones especiales de hardware. Esto no es tan importante hoy en día, pero a los desarrolladores de juegos profesionales 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, ciertamente hace que la codificación sea más fácil y menos propensa a errores, y es una de las grandes razones por las que Java es tan popular. Sin embargo, causa 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 JVM más recientes de baja latencia, pero sigue siendo un problema para los juegos con uso intensivo de gráficos donde es fundamental mantener un alto FPS.

Razones no técnicas:

• Las casas de desarrollo de juegos profesionales se invierten en las habilidades y tecnologías de C / C ++. Esto crea una gran cantidad de inercia .
• La gran percepción irracional de que Java es lento. Posiblemente cierto en los años 90, definitivamente no lo es ahora; ciertamente puedes escribir un juego 3D comercial rentable con Java ( Runescape ¿alguien? ¿O cómo?) sobre Minecraft ?)
• Una bonita percepción justa de que Java está más centrado en las aplicaciones empresariales 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.

Es interesante que también hay algunas buenas razones por las que los desarrolladores de juegos deberían considerar Java:

• Portabilidad : a medida que crece la cantidad de plataformas de destino, Java se vuelve más y más atractivo, ya que tiene una capacidad casi inigualable para crear archivos binarios auténticamente multiplataforma
• Ecosistema de bibliotecas : con la importante excepción de los motores de juegos en 3D, Java tiene la mejor gama de bibliotecas en general de cualquier plataforma. Redes, sonido, inteligencia artificial, procesamiento de imágenes, almacenes de datos clave / valor, le asignas un nombre al tema y probablemente haya una biblioteca de código abierto de Java 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 atractivo aquí como plataforma.
• JVM : es probablemente el entorno de ejecución de VM mejor diseñado del mundo, con una fantástica recolección de basura, compilador JIT, soporte de concurrencia, etc. Solo va a mejorar, y como los desarrolladores de juegos empiezan a usar dinámicamente En los idiomas de sus juegos, querrán el mejor entorno de ejecución posible.
• Otros lenguajes JVM : Java es un caballo de batalla sólido y sólido, pero la verdadera innovación está ocurriendo con los nuevos lenguajes JVM (Scala, Clojure en particular). Estos lenguajes obtienen todas las ventajas de la plataforma Java / JVM, plus son lenguajes modernos extremadamente poderosos.

Está bien, hay mucha información errónea en este hilo.

Sé que el negocio de los videojuegos es extremadamente bueno , después de haber estado en él durante 25 años. También conozco Java en juegos extremadamente bien, ya que he sido evangelista técnico del Juego Java de Sun y profesor de programación de rendimiento en 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 tenga un mal desempeño si lo desea, pero en general, están a la par y lo han estado durante mucho tiempo.

En términos de uso de memoria, Java tiene algo de cabeza. HelloWorld es un programa 4K en java. Pero esa sobrecarga no tiene ningún significado en los sistemas multi GB de hoy en día. Finalmente, Java tiene más de un tiempo de inicio. No recomendaría usar Java para utilidades de tiempo de ejecución cortas como los comandos de la línea de comandos de Unix. En esos casos el inicio dominará tu rendimiento. Sin embargo, en un juego es bastante insiginante.

El código del juego Java escrito correctamente no sufre pausas de GC. Al igual que el código C / C ++, requiere cierta administración de memoria activa pero no al nivel C / C ++. Siempre y cuando mantengas el uso de la memoria en objetos de larga duración (persistir durante todo un nivel o juego) y en objetos de muy corta duración (vectores y similares, pasados y destruidos rápidamente 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 durante mucho tiempo; desde Java 1.4 en la forma de buffers de bytes directos nativos. Los giros de bits en Java pueden ser un poco molestos debido a la falta de tipos de enteros sin signo, pero las rondas de trabajo son bien conocidas y no terriblemente onerosas.

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

Es cierto que ningún motor de juego completo ha presentado a Java de la manera que, digamos Unity, ha presentado C # y eso es una debilidad en el espacio independiente. Por otro lado, había dos buenos APIS a nivel de Scenegraph que eran totalmente portátiles desde Windows, OSX y Linux. Ambos escritos por Josh Slack, el primero se llamó motor JMonkey y el segundo Ardor3D.

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

Si bien Sun coqueteaba 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 en ninguna forma, y por qué Google y Dalvik (la máquina virtual con Android, como Java) hicieron de Java una plataforma exitosa en cualquier parte.

Y por eso codifico los juegos en C # hoy. Porque Mono fue donde la administración de Sun se negó a hacerlo.

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

• comprobación de límites & 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 se puede copiar la memoria entre buffers)
• muchos de los libros y tutoriales siguen a la multitud, por lo que es difícil encontrar información sobre desarrolladores de juegos que no sean de 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 más características visualmente atractivas

No es fácil trabajar con bibliotecas de C ++ desde lenguajes de bytecode como Java (escribir una capa JNI) y .net (muchos atributos de clasificación / desaprobación, api / estructura). Así que agrega bastante trabajo por poco beneficio.

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

Publicación similar aquí : enlace

Java no es lo suficientemente rápido para la mayoría de los juegos de desarrollo. Es mucho más lento que usar C ++ / Assembly, que es el estándar. Es por la misma razón que no se hace más desarrollo de juegos usando C # o VB. Los desarrolladores de juegos necesitan y planifican hasta el último ciclo de reloj que pueden obtener para cosas como cálculos físicos, lógica de inteligencia artificial e interacciones con el 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, entonces Java funcionará bien. Pero Java no puede crear juegos como Halo, Medal of Honor, Command & Conquista, y así sucesivamente y hazlo 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 (incluyendo la mayoría de los juegos de Android), y algunos de ellos son excelentes. Así que creo que hay una base decente y creciente de desarrolladores de juegos con conocimientos de Java.

La idea está cambiando sobre la capacidad de usar estos idiomas 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. Así que la base está creciendo y seguirá evolucionando.

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

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

enlace

Es mi opinión personal que con el progreso que ha ocurrido 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 DVD múltiple) 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 los desarrolladores estrella que hacen los juegos están familiarizados. 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 scripts en lugar de tenerlos todos grabados en código C desde el principio, y desea el mejor tiempo de ejecución debajo de su lenguaje de scripting. En estos días, esto significa esencialmente el CLR o la JVM.

A los desarrolladores de juegos les gusta estar cerca del metal y, a menudo, escriben sus loops internos ajustados 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 analizar por qué no están disponibles.

Miraría eso desde la otra dirección por un momento. Desarrollar un motor de juego (por ejemplo) es un lote de 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 tipo framework en / para Java (por ejemplo, IBM, Oracle) parecen tener un interés cero 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 candidato único que se me ocurre que parece razonable sería Google. El lenguaje de desarrollo principal para Android es Java, y el desarrollo de juegos alentador para Android podría proporcionar una verdadera ventaja para la plataforma.

Por lo que sé, no lo han hecho (¿aún?), lo que deja algunos límites muy severos para casi cualquier otra persona. Sin poco en la forma en que los motores de juegos modernos y de alto rendimiento para usar el desarrollo en Java significa un poco de trabajo extra, con (lo que a mi me parece) pocas posibilidades de producir muchos beneficios a cambio de ese trabajo extra. / p>     

La pregunta está a la par de preguntar algo en la línea de:

¿Qué es mejor para alimentar su automóvil, un motor de barco o un motor a reacción?

Se trata de escalabilidad, prevención de errores, velocidad, firma de memoria, modularidad y toda una serie de cosas. La pregunta no debe ser acerca de qué es mejor como un estándar de la industria, la pregunta debería 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 puedes vender la idea, entonces funciona y quién sabe, incluso podría doblar unas cuantas cucharadas.

Java no se hizo pensando en el desarrollo del juego, Java fue creado para ser un lenguaje "para la web".

En cuanto al desarrollo de juegos, Sun realmente no admite Java como lenguaje de desarrollo de juegos como C # respaldado por Microsoft.

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 a hardware y controladores no convencionales completamente nuevos. Cuanto antes y más cerca esté el programador de un juego para acceder al hardware, mejor podrán superar los juegos de la competencia. Los programadores de juegos posteriores solo siguen la misma metodología y herramientas que los juegos probados anteriormente.

Para los juegos donde la optimización al último hardware 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á adquiriendo impulso cuando se trata del desarrollo de juegos?

  

Es un lenguaje de interpretación, es decir, lento. Se trata de una tarjeta gráfica y gráfica que es hardware. ¿Cuál es un buen lenguaje para tratar con hardware? Bueno, C ++, es bastante bajo, y tratas con punteros y lo que sea.

Si quieres bombear gráficos locos como crysis y lo que sea, no vas a hacer Java para ello.

No solo eso, Oracle posee Java, la idea de que una empresa puede demandarlo no es audaz. Especialmente cuando quieres construir tu propio interpretador para JAVA para apuntar a los juegos sin tener que demandar debido a la fragmentación de FUD.