Perché Java non è più ampiamente utilizzato per lo sviluppo di giochi? [chiuso]

Non sono uno sviluppatore di giochi o altro, ma so che Java non è molto utilizzato per lo sviluppo di giochi. Java dovrebbe essere abbastanza veloce per la maggior parte dei giochi, quindi dov'è il problema? Posso pensare ad alcuni motivi:

• Mancanza di sviluppatori di giochi con esperienza in Java
• Mancanza di buone strutture di sviluppo del gioco
• I programmatori non vogliono accettare Java come linguaggio di programmazione dei giochi. La maggior parte accetta solo C ++ come quello?
• Nessun supporto per console di gioco (anche se il mercato dei PC esiste ancora)

Ovviamente potrebbe essere qualcos'altro. Qualcuno che conosce il business meglio di me potrebbe spiegare perché Java non sta ottenendo slancio quando si tratta di sviluppo di giochi?

Diverse ragioni:

• Ai vecchi tempi, era necessario un "accesso diretto" per le prestazioni e l'interfaccia utente. Questo precede i linguaggi VM come Java e C #.
• La maggior parte delle console (ad esempio 360, PS3) non dispongono di una JVM, quindi non è possibile riutilizzare il codice dalla versione PC. È molto più semplice compilare il codice C ++ per supportare vari dispositivi.
• La maggior parte dei motori di gioco tradizionali (ad es. Unreal) hanno attacchi C ++. Ci sono alcuni connettori Java (ad esempio, per OpenGL) ma niente di simile.
• Per i giochi per PC, DirectX non ha davvero un forte supporto Java (se non del tutto).
• I giochi basati sul Web funzionano in JavaScript o Flash. Potresti scriverli in Java anche usando cose come GWT.
• L'iPhone esegue una variante Objective-C.

Oggigiorno Java viene utilizzato principalmente nei giochi Android, semplicemente perché è la lingua principale per quella piattaforma.

Motivi tecnici:

• La maggior parte dei migliori motori di gioco 3D sono scritti in C / C ++. Questo è un grosso problema, dal momento che la maggior parte degli sviluppatori di giochi non vuole scendere a compromessi sul proprio motore 3D, ma non vuole nemmeno scriverne uno da zero. Java ha jMonkeyEngine che è open source e in realtà davvero buono ma non può ancora competere con Unreal Engine .
• Per alcune situazioni molto rare, ci sono vantaggi nell'avvicinarsi al "metallo" in linguaggio C o assembly, in particolare per l'accesso a funzioni hardware speciali. Questo non è così importante al giorno d'oggi, ma agli sviluppatori di giochi professionali piace ancora avere l'opzione .....
• Java ha una garbage collection , runtime gestito. Il 99% delle volte questo è un enorme vantaggio, rende sicuramente la codifica più semplice e meno soggetta a errori ed è uno dei grandi motivi per cui Java è così popolare. Tuttavia, provoca un problema di latenza occasionale per i giochi poiché i cicli di raccolta dei rifiuti possono causare pause evidenti. Questo sta diventando un problema minore con le nuove JVM a bassa latenza, ma è ancora un problema per i giochi graficamente intensivi in ​​cui è fondamentale mantenere un FPS elevato.

Motivi non tecnici:

• Le case di sviluppo di giochi professionali sono fortemente investite in competenze e tecnologie C / C ++. Questo crea un'enorme quantità di inerzia .
• La percezione in gran parte irrazionale che Java sia lento. Forse vero negli anni '90, sicuramente non vero ora - puoi sicuramente scrivere un gioco 3D commerciale redditizio con Java ( Runescape qualcuno? O che ne dici di Minecraft ?)
• Una percezione abbastanza equa che Java sia più focalizzato sulle applicazioni aziendali e sul Web piuttosto che sui giochi. Ciò potrebbe cambiare con la crescita di Mobile e la necessità di un maggiore sviluppo multipiattaforma, ma al momento è certamente vero.

È interessante notare che ci sono anche alcuni buoni motivi per cui gli sviluppatori di giochi dovrebbero considerare Java:

• Portabilità : con il proliferare del numero di piattaforme target, Java diventa sempre più attraente con la sua capacità praticamente senza pari di creare binari realmente multipiattaforma
• Ecosistema di librerie - con l'eccezione molto importante dei motori di gioco 3D, Java ha la migliore gamma di librerie in assoluto di qualsiasi piattaforma. Networking, audio, intelligenza artificiale, elaborazione delle immagini, archivi di dati chiave / valore, assegni un nome all'argomento e probabilmente c'è una libreria Java open source per questo.
• Sviluppo lato server - Java è una grande lingua / piattaforma per il server e poiché più giochi incorporano massicciamente elementi multi-player, il lato server diventerà sempre più importante. Java su Linux sembra piuttosto avvincente qui come piattaforma.
• La JVM - è probabilmente il miglior ambiente di esecuzione di VM progettato al mondo, con una fantastica garbage collection, compilatore JIT, supporto per la concorrenza ecc. Andrà solo meglio, e man mano che gli sviluppatori di giochi iniziano sempre più a usare linguaggi dinamici all'interno dei loro giochi, vorranno il miglior ambiente di runtime possibile.
• Altri linguaggi JVM : Java è un solido cavallo di battaglia, ma la vera innovazione sta avvenendo con i nuovi linguaggi JVM (Scala, Clojure in particolare). Questi linguaggi ottengono tutti i vantaggi della piattaforma Java / JVM, inoltre sono linguaggi moderni estremamente potenti.

Va bene, c'è molta disinformazione in questo thread.

Conosco molto bene il business dei videogiochi , da 25 anni. Conosco Java molto bene nei giochi, essendo stato l'evangelista tecnico di Sun Java Game ed essendo stato esperto di programmazione delle prestazioni Java.

In termini di velocità computazionale, Java batte oggi il C ++ in molti benchmark di calcolo scientifico. Puoi scrivere un codice patologico in entrambe le lingue che funziona male se vuoi, ma soprattutto, sono alla pari e lo sono da molto tempo.

In termini di utilizzo della memoria, Java ha alcune spese generali. HelloWorld è un programma 4K in Java. Ma quel sovraccarico è piuttosto insignificante nei sistemi multi GB di oggi. Infine, Java ha più tempo di avvio. Non consiglierei di usare Java per utility di runtime di breve durata come i comandi da riga di comando Unix. In questi casi, l'avvio avrà la meglio sulle tue prestazioni. In un gioco, tuttavia, è abbastanza insignificante.

Il codice di gioco Java correttamente scritto non subisce pause GC. Proprio come il codice C / C ++, richiede una gestione della memoria attiva ma non al livello C / C ++. Fintanto che si mantiene l'utilizzo della memoria su oggetti di lunga durata (persistere per un intero livello o gioco) e oggetti di durata molto breve (vettori e simili, passati in giro e rapidamente distrutti dopo il calcolo) gc non dovrebbe essere un problema visibile.

In termini di accesso diretto alla memoria, Java lo ha da molto tempo; da Java 1.4 sotto forma di buffer di byte diretti nativi. La manipolazione dei bit in Java può essere leggermente fastidiosa a causa della mancanza di tipi interi senza segno, ma i round di lavoro sono tutti ben noti e non terribilmente onerosi.

Mentre il suo vero Java non ha mai avuto un binding Direct3D, ciò è dovuto al fatto che le tecnologie Java puntano alla portabilità. Ha DUE collegamenti OpenGL (JOGL e LWJGL) e OpenAL (JOAL) e un collegamento di input portatile (JInput) che si lega sotto il cofano a DirectInput su Windows, HID Manager su OSX e un collegamento Linux (dimentico quale).

È vero che nessun motore di gioco completo ha descritto Java come, ad esempio, Unity, ha caratterizzato C # e questo è un punto debole nello spazio indipendente. D'altra parte, c'erano due buoni APIS a livello di Scenegraph che erano totalmente portatili su piattaforma Windows, OSX e Linux. Entrambi scritti da Josh Slack, il primo si chiamava motore JMonkey e il secondo Ardor3D.

Il poster in alto ha ragione che le due cose più importanti che hanno trattenuto Java nello sviluppo del gioco sono il pregiudizio e la portabilità. Quest'ultimo è stato il problema più grande. Sebbene tu possa scrivere un gioco Java e spedirlo su Windows, OSX e Linux, non c'è mai stata una console virtuale. Ciò era dovuto alla totale inettitudine nella gestione intermedia di Sun. Pochi di noi che lavorano su Java nei giochi in realtà hanno avuto accordi con Sony non meno di 3 volte per ottenere una VM su una Playstation e tutte e 3 le volte la gestione intermedia di Sun l'ha uccisa.

Mentre Sun flirtava con le tecnologie client, il fatto è che la gestione Sun non ha mai ottenuto prodotti di consumo. Ecco perché Java come linguaggio client di Sun non è mai riuscito in nessuna forma e perché ci sono voluti Google e Dalvik (la macchina virtuale simile a Java Android) per rendere Java un successo piattaforma ovunque.

Ed è per questo che oggi codifico i giochi in C #. Perché Mono è andato dove la direzione di Sun si è rifiutata.

Java è ottimo per la logica aziendale, i server e il codice indipendente dalla piattaforma che deve essere eseguito in modo affidabile. Esistono diversi fattori per cui Java non viene spesso utilizzato nei giochi:

• controllo dei limiti e altri meccanismi di sicurezza (differenza di prestazione marginale in questi giorni)
• dover convertire tra strutture di dati C ++ e strutture di dati Java (non si può semplicemente copiare la memoria tra i buffer)
• molti libri e tutorial seguono la folla, quindi è difficile trovare informazioni sugli sviluppatori di giochi non C ++
• le librerie grafiche di base (DirectX e OpenGL) e molti motori standard sono basati su C / C ++
• molti giochi provano a funzionare il più velocemente possibile in modo da poter aggiungere funzionalità visivamente più interessanti

Non è facile lavorare con le librerie C ++ da linguaggi bytecode come Java (scrivendo un livello JNI) e .net (molti marshalling / unmarshalling, attributi api / struttura). Quindi aggiunge un bel po 'di lavoro per pochi benefici.

Una nota a margine: alcuni server di gioco utilizzano Java.

Post simile qui : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java non è abbastanza veloce per la maggior parte dello sviluppo di giochi. È molto più lento rispetto all'uso di C ++ / Assembly, che è lo standard. È la stessa ragione per cui lo sviluppo di un altro gioco non viene eseguito usando C # o VB. Gli sviluppatori di giochi hanno bisogno e pianificano ogni ultimo ciclo di clock su cui possono mettere le mani per cose come i calcoli della fisica, la logica dell'intelligenza artificiale e le interazioni ambientali.

Per i giochi più semplici, Java potrebbe essere usato in modo abbastanza efficace. Se si desidera creare un clone di Tetris o Bejeweled o qualcos'altro di quel livello di dettaglio, Java funzionerebbe perfettamente. Ma Java non può assolutamente creare giochi come Halo, Medal of Honor, Command & Conquer e così via e renderlo giocabile. Almeno come esiste oggi.

E anche i motivi che elenchi nella tua domanda sono validi. Tranne, credo, per la mancanza di sviluppatori di giochi con esperienza Java. Molti giochi su telefoni e altri dispositivi portatili sono scritti in Java (inclusa la maggior parte dei giochi Android) e alcuni giochi sono piuttosto eccellenti. Quindi penso che ci sia una base decente e in crescita di sviluppatori di giochi con conoscenza Java.

Il pensiero sta cambiando la capacità di usare questi linguaggi di livello superiore per alcuni dei giochi più avanzati. Ad esempio, uno dei miei giochi preferiti, Auran's Train Simulator, è scritto con grandi porzioni in C # e funziona abbastanza bene. Quindi la base sta crescendo e continuerà ad evolversi.

I giochi moderni hanno a che fare con la grafica 3D che si svolge in hardware per scopi speciali.

Già nel 2002, Jacob Marner ha scoperto nel suo rapporto "Valutazione di Java per lo sviluppo di giochi" che Java era abbastanza utilizzabile per i giochi, ad eccezione delle parti maggiormente dipendenti dalle prestazioni, e a causa della solidità del linguaggio e della JVM sottostante che era più economico per farlo in questo modo.

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

È mia opinione personale che con i progressi che sono avvenuti da allora, specialmente nella grafica 3D, e con gli eccellenti legami con OpenGL e altri, questo svantaggio è molto meno pronunciato in questi giorni.

Quindi il problema deve essere altrove. Un probabile motivo è la dimensione del runtime Java (che è molto meno un problema in questi giorni con i giochi multi-DVD), e un altro l'inerzia del codice esistente. È notoriamente fragile iniziare a lavorare con il codice nativo in Java. Un terzo motivo è ciò che gli sviluppatori stellari che fanno i giochi hanno familiarità. Un quarto è se Java è disponibile sulla piattaforma.

Una cosa è certa, però: la maggior parte dei giochi sta diventando scriptabile invece di avere tutto masterizzato in codice C dall'inizio, e vuoi il miglior runtime sotto il tuo linguaggio di scripting. Oggigiorno ciò significa essenzialmente o CLR o JVM.

Agli sviluppatori di giochi piace essere vicini al metal e spesso scriveranno i loro anelli interni stretti in assemblea. Java non offre lo stesso livello di prestazioni possibili, sia in termini di velocità costante che di utilizzo della memoria (l'esecuzione di un JIT ne risente).

Penso che il fattore limitante per la maggior parte delle persone sia la (mancanza di) disponibilità di buoni motori di gioco. Per andare molto lontano, dobbiamo vedere perché quelli non sono disponibili.

Lo guarderei dall'altra direzione per un momento. Lo sviluppo di un motore di gioco (ad esempio) richiede molto lavoro. Chi trarrebbe beneficio abbastanza dallo sviluppo di uno per investire il tempo e gli sforzi per farlo?

La maggior parte dei candidati ovvi per lo sviluppo simile a un framework in / per Java (ad es. IBM, Oracle) sembra non avere alcun interesse per i giochi. I candidati ovvi per lo sviluppo del gioco (ad esempio, Id, EA) sembrano avere quasi altrettanto poco interesse per Java.

Quasi l' unico candidato a cui riesco a pensare che sembra assolutamente ragionevole sarebbe Google. Il linguaggio di sviluppo principale per Android è Java e l'incoraggiamento dello sviluppo di giochi per Android potrebbe offrire un vero vantaggio per la piattaforma.

Per quanto ne so, non l'hanno fatto (ancora?), Il che lascia alcuni limiti piuttosto severi per quasi tutti gli altri. Senza i mezzi moderni, i motori di gioco ad alte prestazioni per utilizzare lo sviluppo su Java significano un bel po 'di lavoro extra, con (quello che mi sembra) poche prospettive per produrre molti benefici in cambio di quel lavoro extra.

La domanda è alla pari di chiedere qualcosa del tipo:

Cosa c'è di meglio per alimentare la tua auto, un motore per barche o un motore a reazione.

Si tratta di scalabilità, prevenzione degli errori, velocità, firma di memoria, modularità e tutta una serie di cose. La domanda non dovrebbe riguardare ciò che è meglio come standard del settore, la domanda dovrebbe essere "ciò che è meglio per me" come in ciò che sai o quanto bene lo sai. Se fa il lavoro, allora fa il lavoro, se puoi effettivamente vendere l'idea, allora funziona e chissà che potresti anche piegare alcuni cucchiai.

Java non è stato creato pensando allo sviluppo del gioco, Java è stato creato per essere un linguaggio "per il web".

Per quanto riguarda lo sviluppo del gioco, Sun non supportava Java come linguaggio di sviluppo del gioco poiché Microsoft supportava C #.

Penso che la mancanza di avvincenti framework di sviluppo del gioco sia ciò che ha davvero ucciso Java in questo aspetto.

È più facile incollare C direttamente sui nuovi hardware e driver non convenzionali. Quanto prima e più un programmatore di giochi può accedere all'hardware, tanto meglio può superare i giochi concorrenti. I programmatori di giochi successivi si limitano a seguire la stessa metodologia e gli stessi strumenti dei precedenti giochi collaudati.

Per i giochi in cui l'ottimizzazione per l'hardware più recente è meno importante, come i giochi per telefoni cellulari casuali, l'utilizzo di C in questo modo è meno importante della maggiore portabilità di Java.

Per alcune persone la ragione non ha nulla a che fare con la velocità, le librerie o la disponibilità. È semplicemente a causa della lingua stessa. Ad alcune persone semplicemente non piace Java la lingua. Altre persone preferiscono usare il loro linguaggio di programmazione preferito invece di usare Java per creare giochi.

Ovviamente potrebbe essere qualcos'altro. Qualcuno che conosce il business meglio di me potrebbe spiegare perché Java non sta ottenendo slancio quando si tratta di sviluppo di giochi?

È un linguaggio interpretativo, cioè lento. Hai a che fare con una scheda grafica e grafica che è hardware. Qual è un buon linguaggio per gestire l'hardware? Bene C ++, è piuttosto basso, e hai a che fare con puntatori e quant'altro.

Se vuoi pompare una grafica folle come Crysis e qualunque cosa tu non abbia intenzione di fare Java per questo.

Non solo, Oracle possiede Java, il pensiero che un'azienda possa farti causa non va bene in grassetto. Soprattutto quando vuoi creare il tuo interprete personale per JAVA per indirizzare i giochi senza essere denunciato a causa della frammentazione del FUD.