it-swarm.it

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

Non sono uno sviluppatore di giochi o altro, ma so che Java non è molto usato per lo sviluppo di giochi. Java dovrebbe essere abbastanza veloce per la maggior parte dei giochi , quindi dov'è il trucco? 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 del gioco?

81
Anto

Diverse ragioni:

  • Ai vecchi tempi, era necessario un "accesso diretto" per le prestazioni e l'interfaccia utente. Questo precede VM linguaggi 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 Java (ad es. Per OpenGL) ma nulla di simile.
  • Per i giochi per PC, DirectX non ha davvero Java (se non del tutto).
  • I giochi basati sul Web funzionano in JavaScript o Flash. Puoi scriverli in Java usando però cose come GWT.
  • L'iPhone esegue una variante Objective-C.

Java viene utilizzato principalmente in Android in questi giorni, semplicemente perché è la lingua principale per quella piattaforma.

95
Uri

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 nreal Engine .
  • Per alcune situazioni molto rare, ci sono vantaggi nell'ottenere "vicino 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 un runtime gestito garbage collection 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 una latenza occasionale problema per i giochi come cicli di raccolta dei rifiuti possibile causare pause evidenti. Questo sta diventando meno problematico 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 ampiamente irrazionale che Java è lenta. Forse vera negli anni '90, sicuramente non vera ora - puoi certamente scrivere un gioco 3D commerciale redditizio con Java ( Runescape chiunque? O che ne dici di Minecraft ?)
  • Una bella percezione equa che Java è più focalizzata sulle applicazioni aziendali e sul web piuttosto che sui giochi. Questo 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 considerano Java:

  • Portabilità - con il proliferare del numero di piattaforme target, Java diventa sempre più attraente con la sua capacità praticamente ineguagliabile di creare binari realmente multipiattaforma
  • Ecosistema di libreria - con l'eccezione molto importante dei motori di gioco 3D, Java ha la migliore gamma di librerie nel complesso di qualsiasi piattaforma di rete, audio, intelligenza artificiale, elaborazione di immagini, archivi di dati chiave/valore, si nomina l'argomento e probabilmente c'è una libreria open-source Java per questo.
  • Sviluppo lato server - Java è una grande lingua/piattaforma per il server e poiché più giochi incorporano massicciamente multi- elementi del giocatore il lato server diventerà sempre più importante. Java su Linux sembra piuttosto avvincente qui come piattaforma.
  • Il JVM - è probabilmente il migliore ingegnerizzato VM nel mondo, con una fantastica garbage collection, compilatore JIT, supporto per la concorrenza, ecc. Migliorerà solo, e poiché gli sviluppatori di giochi iniziano sempre più a usare linguaggi dinamici all'interno dei loro giochi, vorranno il miglior ambiente di runtime possibile.
  • Altre lingue JVM - Java è un solido od cavallo di battaglia, ma il vero l'innovazione sta avvenendo con i nuovi linguaggi JVM (Scala, Clojure in particolare). Questi linguaggi ottengono tutti i vantaggi della piattaforma Java/JVM, plus sono linguaggi moderni estremamente potenti.
81
mikera

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

Conosco il business del gioco estremamente bene, essendo stato in esso per 25 anni. Conosco anche Java nei giochi estremamente bene essendo stato Sun Java Evangelista tecnico del gioco e lezioni Java esperto di programmazione delle prestazioni.

In termini di velocità computazionale, Java batte oggi C++ in molti benchmark scientifici informatici. Puoi scrivere 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 un certo sovraccarico. HelloWorld è un programma 4K in Java. Ma tale sovraccarico è piuttosto insignificante nei sistemi multi GB di oggi. Infine, Java ha più di un tempo di avvio. Non consiglierei di usare Java per utilità di runtime di breve durata come i comandi della riga di comando Unix. In questi casi l'avvio dominerà le tue prestazioni. In un gioco tuttavia, è abbastanza insignificante.

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

In termini di accesso diretto alla memoria, Java ha avuto questo per molto tempo; poiché Java 1.4 sotto forma di buffer di byte diretti nativi. Bit twiddling in = Java può essere leggermente fastidioso 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, è perché Java mirano alla portabilità. Ha DUE binding OpenGL (JOGL e LWJGL) e OpenAL (JOAL) e un'associazione di input portatile (JInput) che si lega a DirectInput su Windows, HID Manager su OSX e un'associazione Linux (dimentico quale).

È vero che nessun motore di gioco completo ha caratterizzato Java il modo, diciamo 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 piattaforme 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 contenevano Java nello sviluppo del gioco erano pregiudizio e portabilità. Quest'ultimo era il problema più grande. Sebbene tu potessi scrivere un Java gioco e spedirlo su Windows, OSX e Linux, non c'era mai una console VM. Ciò era dovuto alla totale inettitudine nella gestione centrale di Sun. Pochi di noi lavorano su Java nei giochi in realtà ha avuto a che fare con Sony non meno di 3 volte per ottenere un VM su una PlayStation e tutte e 3 le volte la gestione intermedia di Sun l'ha ucciso.

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

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

29
user430788

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 le strutture di dati C++ e Java strutture di dati (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 un 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

9
Graeme Wicksted

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 vuoi creare un clone di Tetris o Bejeweled, o qualcos'altro di quel livello di dettaglio, allora Java funzionerebbe bene. 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 di 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.

5
BBlake

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 "Evaluating Java per lo sviluppo di giochi" che Java era abbastanza utilizzabile per i giochi, ad eccezione della maggior parte delle prestazioni parti, e grazie alla robustezza del linguaggio e alla JVM sottostante che era più economico 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 funzionare con codice nativo in Java. Un terzo motivo è ciò con cui gli sviluppatori stellari che fanno i giochi hanno familiarità. Un quarto è se Java è affatto disponibile sulla piattaforma.

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

5
user1249

Agli sviluppatori di giochi piace essere vicini al metal e spesso scriveranno i loro stretti loop interni in Assembly. 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).

4
dan_waterworth

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) è un lotto di 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/for Java (ad esempio, IBM, Oracle) sembrano avere zero interesse per i giochi. I candidati ovvi per lo sviluppo di giochi (ad esempio, Id, EA ) sembrano avere quasi altrettanto scarso interesse per Java.

Quasi il candidato solo che mi viene in mente sembra ragionevole a Google. Il linguaggio di sviluppo principale per Android è Java e lo sviluppo del gioco incoraggiante per Android potrebbe fornisce un reale 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 che i moderni motori di gioco ad alte prestazioni utilizzino lo sviluppo su Java significa un po 'di lavoro extra, con (quello che mi sembra) poche prospettive per produrre un sacco di beneficio in cambio di quel lavoro extra.

4
Jerry Coffin

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.

1
Meh

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 davvero Java come linguaggio di sviluppo del gioco come Microsoft supportato da C #.

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

0
Mahmoud Hossam