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

Diversi motivi:

• In passato, serviva 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 ha una JVM, quindi non è possibile riutilizzare il codice dalla versione PC. È molto più facile compilare codice C ++ per supportare vari dispositivi.
• La maggior parte dei motori di gioco tradizionali (ad es. Unreal) hanno associazioni C ++. Ci sono alcuni connettori Java (ad es. Per OpenGL) ma niente di simile.
• Per i giochi su PC, DirectX non ha davvero un supporto Java (se non del tutto).
• I giochi basati sul Web funzionano in JavaScript o Flash. Potresti scrivere in Java usando però cose come GWT.
• L'iPhone esegue una variante Objective-C.

Java è utilizzato principalmente nei giochi Android in questi giorni, 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 molti sviluppatori di giochi non vogliono compromettere il loro motore 3D, ma nemmeno vogliono scriverne uno da zero. Java ha jMonkeyEngine che è open source e in realtà veramente buono ma non può ancora competere con Unreal Engine .
• Per alcune situazioni molto rare, ci sono dei vantaggi nell'ottenere "vicino al metallo" in linguaggio C o assembly, in particolare per l'accesso a funzioni hardware speciali. Al giorno d'oggi non è così importante, ma agli sviluppatori di giochi professionisti piace ancora avere l'opzione .....
• Java ha un 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 motivi principali per cui Java è così popolare. Tuttavia, causa un problema di latenza occasionale per i giochi poiché i cicli di raccolta dei dati inutili 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 il mantenimento di FPS elevati è fondamentale.

Motivi non tecnici:

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

È interessante notare che ci sono anche alcune buone ragioni per cui gli sviluppatori di giochi dovrebbero prendere in considerazione Java:

• Portabilità - con il proliferare del numero di piattaforme di destinazione, Java diventa sempre più attraente con la sua capacità praticamente senza precedenti di creare binari autenticamente multipiattaforma
• Ecosistema di libreria - con l'eccezione molto importante dei motori di gioco 3D, Java ha la migliore gamma di librerie complessiva di qualsiasi piattaforma. Networking, audio, intelligenza artificiale, elaborazione di immagini, archivi di dati chiave / valore, il nome dell'argomento e probabilmente una libreria Java open source per esso.
• Sviluppo lato server - Java è una grande piattaforma / langauge per il server e, poiché più giochi incorporano elementi multi-player in modo massivo, il lato server diventerà sempre più importante. Java su Linux sembra piuttosto interessante qui come piattaforma.
• JVM - è probabilmente il miglior ambiente di esecuzione VM progettato nel mondo, con una fantastica raccolta dei rifiuti, compilatore JIT, supporto della concorrenza, ecc. Migliorerà solo, e gli sviluppatori di giochi inizieranno a utilizzare in modo sempre più dinamico le lingue all'interno dei loro giochi vorranno il miglior ambiente runtime possibile.
• Altre lingue JVM - Java è un solido cavallo di battaglia, ma la vera innovazione sta accadendo con le nuove langues JVM (Scala, Clojure in particolare). Questi linguaggi hanno tutti i vantaggi della piattaforma Java / JVM, più sono linguaggi moderni estremamente potenti.

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

Conosco bene il settore del gioco estremamente , dopo aver lavorato per 25 anni. Conosco anche Java nei giochi estremamente bene essendo stato l'evangelista tecnico del Java Game di Sun e facendo la predica all'esperto di programmazione delle prestazioni Java.

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

In termini di utilizzo della memoria, Java ha un po 'di overhead. HelloWorld è un programma 4K in java. Ma quel sovraccarico è abbastanza privo di significato nei sistemi multi GB di oggi. Infine, Java ha più tempo di avvio. Non raccomanderei l'uso di Java per le utilità a breve durata come i comandi della riga di comando Unix. In quei casi l'avvio dominerà la tua performance. In una partita, tuttavia, è piuttosto insignificante.

Il codice di gioco Java scritto correttamente non soffre le pause GC. Proprio come il codice C / C ++, richiede una gestione attiva della memoria, ma non al livello C / C ++. Fintanto che mantieni l'utilizzo della memoria su oggetti longevi (persistono per un intero livello o gioco) e oggetti molto corti (vettori e simili, passati intorno e rapidamente distrutti dopo il calcolo) gc non dovrebbe essere un problema visibile.

In termini di accesso diretto alla memoria, Java lo ha avuto per un periodo di tempo prolungato; da Java 1.4 sotto forma di buffer byte nativi diretti. I bit che girano in Java possono essere leggermente fastidiosi a causa della mancanza di tipi di interi non firmati, ma i round di lavoro sono tutti ben noti e non eccessivamente onerosi.

Sebbene il suo vero Java non abbia mai avuto un binding Direct3D, questo perché le tecnologie Java puntano alla portabilità. Ha DUE binding OpenGL (JOGL e LWJGL) e OpenAL binding (JOAL) e un binding di input portatile (JInput) che lega sotto il cappuccio a DirectInput su Windows, HID Manager su OSX e un binding Linux (non ricordo quale).

È vero che nessun motore di gioco completo ha caratterizzato Java come dire, Unity, ha caratterizzato C # e questa è una debolezza nello spazio indipendente. D'altra parte, c'erano due buoni APIS di livello Scenario che erano totalmente portatili su piattaforma Windows, OSX e Linux. Entrambi scritti da Josh Slack, il primo è stato chiamato motore JMonkey e il secondo Ardor3D.

Il poster principale è corretto sul fatto che le due cose più importanti che hanno reso Java lo sviluppo del gioco sono state il pregiudizio e la portabilità. Quest'ultimo è stato il più grande problema. Sebbene tu possa scrivere un gioco Java e inviarlo su Windows, OSX e Linux, non c'è mai stata una console VM. Ciò era dovuto alla totale inettitudine del middle management di Sun. I pochi di noi che lavorano su Java nei giochi hanno effettivamente avuto accordi con Sony non meno di 3 volte per ottenere una VM su una Playstation e tutte e 3 le volte che il middle management di Sun l'ha ucciso.

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

E questo è il motivo per cui gioco a codice in C # oggi. Perché Mono è andato dove la gestione del Sole si è rifiutata di farlo.

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

• limiti di controllo e amp; altri meccanismi di sicurezza (differenza di prestazioni marginali al giorno d'oggi)
• dovendo convertire tra strutture dati C ++ e strutture dati Java (non è sufficiente 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 core (DirectX e OpenGL) e molti motori disponibili in commercio sono basati su C / C ++
• molti giochi cercano di essere eseguiti il più velocemente possibile in modo che possano aggiungere altre caratteristiche visivamente accattivanti

Non è facile lavorare con le librerie C ++ dai linguaggi bytecode come Java (scrivendo un layer JNI) e .net (molti attributi marshalling / unmarshalling, api / structure). Quindi aggiunge un bel po 'di lavoro per poco beneficio.

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

Post simile qui : link

Java non è abbastanza veloce per la maggior parte dello sviluppo del gioco. È molto più lento dell'uso di C ++ / Assembly, che è lo standard. È lo stesso motivo per cui lo sviluppo di un gioco non viene fatto usando C # o VB. Gli sviluppatori di giochi hanno bisogno e pianificano ogni ciclo di clock a cui possono mettere le mani per cose come calcoli fisici, logica IA e interazioni ambientali.

Per giochi più semplici, Java potrebbe essere usato abbastanza efficacemente. Se vuoi creare un clone di Tetris o Bejeweled, o qualcos'altro di quel livello di dettaglio, allora Java funzionerebbe correttamente. Ma Java non può creare giochi come Halo, Medal of Honor, Command & Conquer, e così via e renderlo giocabile. Almeno come esiste al giorno d'oggi.

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

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

I giochi moderni riguardano la grafica 3D che si verifica nell'hardware per scopi speciali.

Già nel 2002, Jacob Marner trovò nel suo rapporto "Valutare Java per lo sviluppo di giochi" che Java era abbastanza utilizzabile per i giochi, eccetto per le parti più performanti, e per la robustezza del linguaggio e della JVM sottostante che era più economico farlo in questo modo.

link

È mia opinione personale che con il progresso che è successo da allora, specialmente nella grafica 3D, e con gli ottimi legami con OpenGL et al, questo svantaggio sia 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 al giorno d'oggi con giochi multi-DVD), e un altro l'inerzia del codice esistente. È notoriamente fragile iniziare a lavorare con codice nativo in Java. Un terzo motivo è quello che gli sviluppatori di stelle che fanno i giochi hanno familiarità con. Un quarto è se Java è disponibile sulla piattaforma.

Una cosa è certa: la maggior parte dei giochi si sta trasformando in script, invece di averli tutti masterizzati in codice C dall'inizio, e si desidera il miglior runtime sotto il linguaggio di scripting. In questi giorni questo essenzialmente significa o il CLR o la JVM.

Gli sviluppatori di giochi amano essere vicini al metallo e spesso scriveranno i loro stretti anelli interni 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 una JIT richiede il suo pedaggio).

Penso che il fattore limitante per la maggior parte delle persone sia la (mancanza di) disponibilità di buoni motori di gioco. Per arrivare molto lontano, dobbiamo cercare perché 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 da svilupparne uno per investire il tempo e gli sforzi per farlo?

La maggior parte dei candidati ovvi per lo sviluppo framework-like in / per Java (ad es. IBM, Oracle) sembrano avere zero interesse per i giochi. I candidati ovvi per lo sviluppo del gioco (ad esempio, ID, EA) sembrano avere quasi altrettanto poco interesse in Java.

Quasi il candidato solo a cui posso pensare sembra ragionevole, Google. Il linguaggio di sviluppo principale per Android è Java e incoraggiare lo sviluppo di giochi per Android potrebbe fornire un vantaggio reale per la piattaforma.

Per quanto ne so, non lo hanno ancora fatto (ancora?), il che lascia dei limiti piuttosto severi per quasi tutti gli altri. Senza un minimo di moderni motori di gioco ad alte prestazioni per utilizzare lo sviluppo su Java, si intende un bel po 'di lavoro extra, con (a mio parere) poche prospettive per produrre molti benefici in cambio di quel lavoro extra.

La domanda è alla pari a chiedere qualcosa sulla falsariga di:

Che cosa è meglio per alimentare la tua auto, un motore per barche o un motore a reazione.

Si tratta di scalabilità, eliminazione degli errori, velocità, firma della memoria, modularità e una miriade 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 quello che sai o quanto bene lo sai. Se fa il lavoro, allora fa il lavoro, se in effetti puoi vendere l'idea allora funziona e chissà che potresti persino piegare qualche cucchiaio.

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 realmente Java come linguaggio di sviluppo del gioco, dato che Microsoft supportava C #.

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

È più facile incollare C più direttamente a hardware e driver non convenzionali. Quanto prima un programmatore di giochi può arrivare all'hardware, tanto meglio possono sfidare i giochi in competizione. In seguito i programmatori di giochi si limitano a utilizzare la stessa metodologia e gli stessi strumenti dei precedenti giochi.

Per i giochi in cui l'ottimizzazione dell'hardware più recente è meno importante, come i giochi di cellulari occasionali, l'uso 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 del linguaggio stesso. Ad alcune persone semplicemente non piace la lingua Java. Altre persone preferiscono usare il loro linguaggio di programmazione preferito invece di usare Java per creare giochi.

It could of course be something else. Could someone who knows the business better than me explain why Java isn't getting momentum when it comes to game development?

È un linguaggio interpretato, cioè lento. Hai a che fare con schede grafiche e grafiche che sono hardware. Qual è un buon linguaggio per gestire l'hardware? Bene, C ++, è piuttosto basso, e tu gestisci i puntatori e qualsiasi altra cosa.

Se vuoi estrarre grafica pazzesca 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 denunciarti non è audace. Soprattutto quando si vuole costruire il proprio interprete per JAVA per indirizzare i giochi senza ottenere causa a causa della frammentazione FUD.