Perché solo pochi videogiochi sono scritti in Java? [chiuso]

Perché molti videogiochi 3D commerciali (non quelli 2D open source casuali) sono scritti in Java? In teoria, ha molto senso: ottieni un aumento della produttività e un'applicazione multipiattaforma quasi gratis, tra le altre cose, come la grande quantità di librerie Java e la garbage collection integrata (anche se lo ammetto, " non sono sicuro che quest'ultimo sia una buona cosa). Quindi perché viene usato raramente? Posso solo pensare a un paio di giochi commerciali popolari scritti per la piattaforma Java.

È a causa delle prestazioni? In tal caso, la maggior parte dei lavori pesanti non verrebbero comunque eseguiti dalla GPU?

Il mondo di sviluppo del gioco è divertente: da un lato, spesso accettano rapidamente nuove idee, dall'altro sono ancora nell'età della pietra.

La verità è che raramente ci sono molti incentivi nel passaggio a .NET / Java / qualsiasi cosa diversa da C / C ++.

La maggior parte delle società di gioco concede in licenza parti del motore di gioco da altre società. Queste parti sono scritte in C ++ e sebbene sia possibile avere accesso al sorgente in modo da poterlo portare, ciò richiede molto sforzo (e, naturalmente, la licenza deve consentirlo).

Inoltre, esiste già molto codice legacy in C ++. Se il codice di progetti precedenti può essere riutilizzato (diciamo, se stai scrivendo un sequel), ciò conta ancora di più a favore di rimanere nella stessa lingua, invece di riscriverlo in una nuova lingua (più perché probabilmente dovrai reintrodurre un sacco di bug di cui avrai bisogno per passare il tempo a stirare.

Infine, è raro che i giochi siano scritti in C ++ al 100% - molto è fatto usando linguaggi di script, sia personalizzati che semplicemente integrando un linguaggio esistente (Lua è uno dei più popolari in questi giorni).

Per quanto riguarda la garbage collection, questo può essere un po 'un problema. Il problema non è tanto che esiste, ma è piuttosto come funziona: il Garbage Collector DEVE essere non bloccante (o almeno essere garantito per bloccare solo brevemente), dal momento che è semplicemente inaccettabile che il gioco si blocchi per 10 secondi mentre esegue la scansione di tutta la memoria allocata per vedere cosa può essere liberato. So che Java tende a soffocare un po 'in GC quando sta per esaurire la memoria (e per alcuni giochi là fuori, lo farà).

Sei anche un po 'più limitato in ciò che puoi fare: non puoi sfruttare completamente l'hardware a causa del sovraccarico del runtime. Immagina che Crysis sia scritto in Java ... anche se questa è l'unica differenza visibile, non sarebbe la stessa (sono anche abbastanza sicuro che avresti bisogno di un Core i7 per eseguirlo.).

Questo non significa che questi linguaggi non abbiano il loro posto nello sviluppo del gioco e no, non mi riferisco solo alla programmazione degli strumenti. Per la maggior parte dei giochi, non hai bisogno di quel po 'di prestazioni extra che ottieni dal C ++, inclusi i giochi 3D, e se stai scrivendo tutto da zero, può avere perfettamente senso usare qualcosa come XNA - in effetti, c'è un buone probabilità che lo farà.

Per quanto riguarda i giochi commerciali, conta RuneScape ? Potrebbe essere il gioco Java di maggior successo là fuori.

Penso che John Carmack lo abbia detto meglio con:

Il problema più grande è che Java è molto lento. A livello di pura CPU / memoria / display / comunicazione, la maggior parte dei telefoni cellulari moderni dovrebbe essere una piattaforma di gioco notevolmente migliore rispetto a un Game Boy Advanced. Con Java, sulla maggior parte dei telefoni ti rimane circa la potenza della CPU di un PC IBM 4.77 mhz originale e un controllo pessimo su tutto. [... snip ...] Scrivi-run-once-ovunque. Ha. Ha ha ha ha ha. Al momento stiamo testando solo su quattro piattaforme e non una sola coppia ha le stesse stranezze. Tutti i giochi commerciali sono ottimizzati e compilati individualmente per ogni piattaforma (spesso 100+). La portabilità non è una giustificazione per la terribile performance.

( fonte )

Certo, stava parlando di piattaforme mobili, ma ho riscontrato problemi simili con Java nel suo insieme proveniente da un background C ++. Mi manca la possibilità di allocare memoria sullo Stack / Heap alle mie condizioni.

Per prima cosa, la mancanza di sovraccarico dell'operatore da parte di Java rende tutta la matematica che devi affrontare per ottenere una pipeline grafica funzionante molto, molto fastidiosa e difficile da leggere.

Tutte le moltiplicazioni di matrice e i vettori affini che devi affrontare sono molto più facili da seguire se si trovano in espressioni matematiche ben formate piuttosto che in espressioni orientate agli oggetti come

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

È semplicemente terribile. La matematica non dovrebbe apparire così.

Penso che .NET abbia (ha) molti degli stessi problemi percepiti che ha Java. Microsoft ha appena fatto un lavoro migliore nel marketing per gli sviluppatori con XNA :-)

Prima i punti minori:

• qualsiasi aumento di produttività da Java è ipotetico. La sintassi è quasi identica al C ++, quindi stai davvero solo risparmiando sulla gestione della memoria e sulle librerie standard. Le librerie hanno poco da offrire agli sviluppatori di giochi e la gestione della memoria è un problema controverso a causa della garbage collection.

• multipiattaforma "gratis" non è buono come pensi perché pochi sviluppatori vogliono usare OpenGL e molte piattaforme chiave probabilmente non hanno una buona implementazione Java o wrapper per le loro librerie native, sia per grafica, audio, networking, ecc.

Ma soprattutto, il problema è la compatibilità con le versioni precedenti. Gli sviluppatori di giochi sono passati al C ++ da C a C dall'assembly puramente perché il percorso di migrazione era fluido. Ciascuno interagisce strettamente con il precedente e tutto il loro codice precedente era utilizzabile nella nuova lingua, spesso tramite un singolo compilatore. Pertanto, la migrazione è stata lenta o veloce come desiderato. Ad esempio, alcune delle nostre vecchie intestazioni in uso oggi hanno ancora #ifdef WATCOMCin, e non credo che nessuno abbia usato il compilatore Watcom qui in un decennio o più. C'è un investimento enorme nel vecchio codice e ogni bit viene sostituito solo se necessario. Questo processo di sostituzione e aggiornamento di pezzi da un gioco all'altro non è affatto pratico se si passa a una lingua che non interagisce nativamente con il codice esistente. Sì, l'interoperabilità C ++ / Java è possibile, ma molto poco pratica rispetto al semplice scrivere "C con un po 'di C ++" o incorporare blocchi asm in C.

Per sostituire correttamente C ++ come linguaggio di scelta degli sviluppatori di giochi, è necessario eseguire una delle due operazioni seguenti:

1. Essere facilmente interoperabili con il codice legacy esistente, preservando così gli investimenti e mantenendo l'accesso alle librerie e agli strumenti esistenti, OPPURE
2. Dimostrare in modo abbastanza evidente un aumento della produttività che il costo di riscrivere tutto il proprio codice (o rielaborare le interfacce in componenti riutilizzabili che possono essere utilizzati da quella lingua) è più che coperto.

Soggettivamente, non penso che Java soddisfi nessuno dei due. Un linguaggio di livello superiore potrebbe incontrare il secondo, se qualcuno è abbastanza coraggioso da essere il pioniere. (EVE Online è probabilmente il miglior esempio che abbiamo di Python utilizzabile, ma che utilizza un fork del linguaggio Python principale, molti componenti C ++ per le prestazioni, e anche quello è per un gioco abbastanza poco impegnativo in termini moderni.)

Sto giocando a The Sims 3 e ho fatto un po 'di scherzi. Il motore grafico è C ++, mentre il motore di scripting e comportamento è C # / Mono. Quindi, mentre C ++ è lì per bit critici nel tempo, altre cose come .interazione, logica di gioco, AI è in un linguaggio gestito orientato agli oggetti.

• Esistono porte valide per i motori / le librerie di gioco?
• Molti sviluppatori C / C ++, in particolare quelli su Windows (dove sono scritti la maggior parte dei giochi commerciali), hanno familiarità con Visual Studio. Non c'è confronto negli IDE.
• In generale, Java è stato venduto alle aziende a causa della sua tipizzazione solida e ha la percezione di non avere problemi di gestione della memoria.
• E sì, Java soffre ancora della percezione che sia lento, e che la sua gestione della memoria sia scarsa e, per i giochi, probabilmente non è adatta al compito. Come affermato in alcune delle altre risposte, la garbage collection non riuscirà a tagliarla quando si ha a che fare con requisiti ad alte prestazioni in tempo reale. I videogiochi spingono CPU e GPU al limite.

Uno dei motivi principali per cui Java e altri linguaggi di macchine virtuali non vengono utilizzati per i giochi è dovuto alla Garbage Collection. Lo stesso vale per .NET. La raccolta dei rifiuti ha fatto molta strada e funziona alla grande nella maggior parte dei tipi di applicazioni. Per eseguire la garbage collection, tuttavia, è necessario mettere in pausa e interrompere l'applicazione per raccogliere il cestino. Ciò può causare ritardi periodici quando si verifica la raccolta.

Java ha lo stesso problema per le applicazioni in tempo reale. Quando le attività devono essere eseguite in un momento specifico, è difficile che un'attività automatizzata come la garbage collection lo rispetti.

Java non è lento. Java non è bravo a gestire le attività in tempo reale.

Un grande motivo è che i videogiochi richiedono una conoscenza diretta dell'hardware sottostante, spesso volte, e in realtà non esiste una grande implementazione per molte architetture. È la conoscenza dell'architettura hardware sottostante che consente agli sviluppatori di spremere ogni grammo di prestazioni da un sistema di gioco. Perché dovresti dedicare del tempo per portare Java su una piattaforma di gioco e poi scrivere un gioco sopra quella porta quando potresti semplicemente scrivere il gioco?

modifica: questo vuol dire che è più che un problema di "velocità" o "non avere le librerie giuste". Queste due cose vanno di pari passo con questo, ma è più una questione di "come faccio a fare in modo che un sistema come la cella esegua il mio codice java? Non ci sono davvero buoni compilatori java in grado di gestire pipeline e vettori come se avessi bisogno di ... "

Il problema delle prestazioni è il primo motivo. Quando vedi il tipo di codice C ++ iper ottimizzato presente nei motori di Quake ( http://www.codemaestro.com/reviews/9 ), sai che non perderanno il loro tempo con una macchina virtuale.

Sicuramente ci potrebbero essere alcuni giochi .NET (quali? Mi interessano. Ce ne sono alcuni ad alta intensità di CPU / GPU?), Ma immagino sia più perché molte persone sono esperte nelle tecnologie MS e hanno seguito Microsoft quando hanno lanciato la loro nuova tecnologia.

Oh, e multipiattaforma non è nella mente delle società di videogiochi. Linux rappresenta solo l'1% circa del mercato, Mac OS un po 'più in più. Pensano sicuramente che non valga la pena scaricare tecnologie solo per Windows e librerie come DirectX.

Puoi chiedere perché anche le applicazioni web non sono scritte in C o C ++. Il potere di Java risiede nel suo stack di rete e nel design orientato agli oggetti. Naturalmente anche C e C ++ hanno questo. Ma su un'astrazione più bassa. Non è niente di negativo, ma non vuoi reinventare la ruota ogni volta, vero?

Inoltre, Java non ha accesso diretto all'hardware, il che significa che sei bloccato con l'API di qualsiasi framework.

Le mie idee sbagliate sulle prestazioni e le scarse ottimizzazioni JVM sarebbero le mie. Dico idee sbagliate sulle prestazioni perché ci sono alcune porte Java dei giochi C ++ che funzionano più velocemente delle loro controparti C ++ (vedi Jake 2). Il vero problema, IMHO, è che molti programmatori Java non sono così concentrati sulle prestazioni al limite perché sono facili da usare e comprensibilità / manutenibilità del codice. Dal punto di vista C / C ++, stai essenzialmente scrivendo un linguaggio assembly di livello leggermente più alto, più o meno vicino all'hardware che puoi ottenere senza scrivere nel codice assembly o straight machine.

Elenco dei motori di gioco su Wikipedia elenca molti motori di gioco insieme al linguaggio di programmazione in cui sono scritti.

Sono elencati diversi motori di gioco Java.

Facendo clic su alcuni dei collegamenti si aprono esempi di giochi e demo scritti in Java. Eccone un paio:

• Ardor3D
• Software bytonico

Per alcuni giochi e situazioni, i compromessi di Java potrebbero essere accettabili.

.NET ha sicuramente alcuni degli stessi problemi che Java ha quando si tratta di prestazioni 3D intense. Microsoft ha anche investito molto più tempo e denaro nello sviluppo delle librerie quando si tratta di lavorare con operazioni pesanti in 3D.

(... personalmente, penso anche che abbiano avuto un vantaggio quando si tratta della magia tra DirectX e .NET)

1. Java è lento, la maggior parte del sollevamento pesante non è gestita dalla GPU. C'è ancora animazione, fisica e intelligenza artificiale che colpiscono la CPU, il che richiede molto tempo.

2. Java non esiste su console e le console sono un obiettivo importante per i giochi commerciali. Se si utilizza Java su PC, si sta eliminando la possibilità di effettuare il porting su console in tempi e budget ragionevoli.

3. Molti dei programmatori più esperti nel settore dei giochi hanno usato C e C ++ molto prima che Java diventasse popolare. I due punti sopra possono contribuire a questo, ma mi aspetto che molti programmatori di giochi professionisti non conoscano Java così bene.

4. Il punto di qualcun altro sul middleware sopra era buono, quindi lo sto aggiungendo alla mia risposta. C'è un sacco di codice e middleware legacy scritti appositamente per collegarsi con C / C ++, e per ultimo ho verificato che Java non ha una buona interoperabilità. L'uso di Java per la maggior parte delle aziende comporterebbe il lancio di molto codice, in gran parte pagato in un modo o nell'altro.

In realtà, è molto possibile che il codice gestito esegua giochi 3d, il problema sono i motori posteriori. Con .Net, per un breve periodo, Microsoft ha gestito un wrapper DirectX gestito per DirectX 9. Questo era prima dell'astrazione che ora è XNA.

Dato l'accesso totale alle API di DirectX, i giochi .Net funzionano a meraviglia. Il miglior esempio che conosco è www.entombed.co.uk, che è scritto in VB.Net.

Sfortunatamente, dal lato Java, è gravemente carente - principalmente per il motivo che DirectX non è disponibile per Java e i programmatori di giochi conoscono e comprendono l'API DirectX - perché imparare ancora un altro api quando tornerai a DirectX?

Il marketing di gioco è un processo commerciale; gli editori vogliono rendimenti quantificabili a basso rischio sul proprio investimento. Di conseguenza, l'attenzione si concentra di solito su espedienti tecnologici (con eccezioni) che i consumatori compreranno per produrre rendimenti affidabili - questi tendono ad essere effetti visivi superficiali come l'abbagliamento delle lenti o una risoluzione più elevata. Questi effetti sono affidabili perché usano semplicemente aumenti della potenza di elaborazione - sfruttano gli aumenti dell'hardware / della legge di Moore. questo implica l'uso di C / C ++: java è di solito troppo astratto dall'hardware per sfruttare questi vantaggi.

Immagino che la velocità sia ancora il problema. La multipiattaforma sarà un problema, non è vero dal momento che non sai quale scheda 3d è disponibile quando scrivi il codice? Java ha qualcosa per supportare il rilevamento automatico delle funzionalità 3D? E immagino che ci siano strumenti per facilitare il porting di un gioco tra wii, xbox e ps3, ma scommetto costoso.

La ps3 ha Java, tramite il supporto Blue Ray. Controlla il sito bd-j.

Anche i giochi scritti sulla piattaforma .Net sono spesso altamente ottimizzati per la velocità come l'accesso diretto alla memoria e al bus. .Net consente di utilizzare C / C ++ e di mescolarlo con linguaggi di livello superiore come C #.

Gli studi di sviluppo di giochi spesso lavorano a stretto contatto con i fornitori di hardware, che forniscono accesso a interfacce di basso livello dei loro prodotti. Questo è un mondo in cui devi usare ASM e C per la comunicazione del dispositivo. Un ambiente virtuale rallenterebbe queste parti del programma.

In ogni caso, i moderni giochi 3D utilizzano infatti linguaggi di livello superiore. Spesso troverai la logica del gioco scritta in lingue come Lua o Python. Ma il nucleo (I / O, thread, pianificazione delle attività) del tipico gioco 3D sarà scritto in lingue di basso livello per i prossimi 25 anni o poiché i dispositivi lunghi non consentiranno l'astrazione e la virtualizzazione da soli (che arriverà).

Sono d'accordo con gli altri post su come sfruttare elementi di una base di codice preesistente / concessa in licenza, prestazioni, ecc.

Una cosa che vorrei aggiungere è che è difficile fare brutti scherzi DRM attraverso una macchina virtuale.

Inoltre penso che ci sia una componente di hubris in cui i project manager pensano di poter creare un codice stabile / affidabile con C ++ con tutti i vantaggi come avere il controllo assoluto sui loro strumenti e risorse, MA senza tutti gli aspetti negativi che complicano e impantanano la concorrenza perché "noi" più intelligenti di quanto non siano ".

Runescape di Jagex è scritto in Java, il tag "videogioco" potrebbe non applicarlo specificatamente essendo un gioco online, ma ha un seguito decente.

Ne abbiamo già parlato molto, puoi trovare anche su Wiki le ragioni ...

• C / C ++ per il motore di gioco e tutte le cose intense.
• Lua o Python per gli script nel gioco.
• Java: prestazioni pessime, grande utilizzo della memoria + non è disponibile su console di gioco (viene utilizzato per alcuni giochi molto semplici (Sì, Runescape conta qui, non è Battlefield o Crysis o cos'altro c'è) solo perché ci sono molti programmatori che conoscono questo linguaggio di programmazione).
• C # - grande utilizzo della memoria (viene utilizzato per alcuni giochi molto semplici solo perché ci sono praticamente programmatori che conoscono questo linguaggio di programmazione).

E sento sempre più programmatori Java che cercano di convincere la gente che Java non è lento, non è lento per disegnare un widget sullo schermo e disegnare alcuni caratteri ASCII sul widget, per ricevere e inviare dati attraverso la rete (Ed è consigliato di usarlo in questi casi (manipolazione dei dati di rete) invece di C / C ++) ... Ma è dannatamente lento quando si tratta di cose serie come calcoli matematici, allocazione / manipolazione della memoria e molte altre cose buone.

Ricordo un articolo sul sito del MIT in cui mostrano cosa può fare C / C ++ se si usano le funzioni di linguaggio e compilatore: un moltiplicatore di matrici (2 matrici), 1 implementazione in Java e 1 implementazione in C / C ++, con funzionalità C / C ++ e le opportune ottimizzazioni del compilatore attivate, l'implementazione C / C ++ era ~ 296 260 volte più veloce dell'implementazione Java.

Spero che tu capisca ora perché le persone usano C / C ++ invece di Java nei giochi, immagina Crysis in Java, non ci sarebbe nessun computer al mondo in grado di gestirlo ... + Garbage Collection funziona bene per i Widget che hanno appena distrutto un'immagine ma è ancora memorizzato nella cache e deve essere pulito, ma non per i giochi, sicuramente avrai ancora più ritardi ad ogni attivazione della garbage collection.

Modifica : Perché qualcuno ha chiesto l'articolo, qui, ho cercato nell'archivio web per ottenerlo, spero che tu sia soddisfatto ... Caso di studio del MIT

E aggiungere, no, Java per i giochi è ancora una pessima idea. Solo pochi giorni fa una grande azienda che non nominerò ha iniziato a riscrivere il proprio client di gioco da Java a C ++ perché un gioco molto semplice (in termini di grafica) stava rallentando e riscaldando laptop i7 con potenti schede video nVidia GT 5xx e 6xx di generazione ( non solo nVidia, il punto qui è che queste potenti carte sono in grado di gestire le impostazioni Max della maggior parte dei nuovi giochi e non possono gestire questo gioco) e il consumo di memoria è stato di ~ 2,5 - 2,6 GB di RAM. Per una grafica così semplice ha bisogno di una bestia di una macchina.