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?
java
game-development
Anto
fuente
fuente
Respuestas:
Muchas rasones:
Java se usa principalmente en juegos de Android en estos días, simplemente porque es el idioma principal de esa plataforma.
fuente
malloconew, así que si eso es una preocupación, implementará la agrupación sin importar qué. Sin relación con ese punto, un gran problema con Java es que no admite tipos de valor, a diferencia de C #.Razones técnicas:
Razones no técnicas:
Curiosamente, también hay algunas buenas razones por las cuales los desarrolladores de juegos deberían considerar Java:
fuente
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ó.
fuente
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:
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
fuente
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.
fuente
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.
fuente
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).
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente