Waarom worden niet veel commerciële 3D-videogames (geen willekeurige open source 2D-games) in Java geschreven? In theorie is het heel logisch: je krijgt een productiviteitsboost en een platformonafhankelijke applicatie bijna gratis, onder andere, zoals de enorme hoeveelheid Java-bibliotheken en ingebouwde garbagecollection (hoewel ik toegeef dat ik ‘ ik weet niet zeker of dat laatste een goede zaak is). Dus waarom wordt het zelden gebruikt? Ik kan maar een paar populaire commerciële games bedenken die voor het Java-platform zijn geschreven.
Is het vanwege de prestaties? Zo ja, zou het grootste deel van het zware werk dan toch niet door de GPU worden gedaan?
Antwoord 1, autoriteit 100%
De game-ontwikkelingswereld is grappig: aan de ene kant accepteren ze nieuwe ideeën vaak snel, aan de andere kant bevinden ze zich nog in het stenen tijdperk.
De waarheid is dat er zelden zoveel motivatie is om over te schakelen naar .NET/Java/iets anders dan C/C++.
De meeste gamebedrijven geven licenties voor onderdelen van de game-engine van andere bedrijven. Deze delen zijn geschreven in C++, en hoewel je misschien toegang hebt tot de bron om het te kunnen porten, kost dat veel moeite (en natuurlijk moet de licentie het toestaan).
Bovendien bestaat er al veel oude code in C++. Als code van eerdere projecten kan worden hergebruikt (bijvoorbeeld als je een vervolg schrijft), is dat nog belangrijker om bij dezelfde taal te blijven, in plaats van het in een nieuwe taal te herschrijven (temeer omdat je waarschijnlijk opnieuw zult introduceren een heleboel bugs die je tijd moet besteden aan het gladstrijken.
Ten slotte komt het zelden voor dat games in 100% C++ worden geschreven – veel wordt gedaan met behulp van scripttalen, of ze nu aangepast zijn of gewoon een bestaande taal integreren (Lua is tegenwoordig een van de meest populaire talen).
Wat het ophalen van afval betreft, kan dat een beetje een probleem zijn. Het probleem is niet zozeer dat het bestaat, het is meer hoe het werkt – de vuilnisophaler MOET niet-blokkerend zijn (of op zijn minst gegarandeerd slechts heel kort blokkeren), aangezien het gewoon onaanvaardbaar is om het spel 10 seconden te laten bevriezen terwijl het scant al het toegewezen geheugen om te zien wat kan worden vrijgemaakt. Ik weet dat Java nogal eens de neiging heeft om te stikken in GC’ing als het bijna vol is met geheugen (en voor sommige games die er zijn, zal dat ook zo zijn).
Je bent ook wat beperkter in wat je kunt doen: je kunt de hardware niet volledig benutten vanwege de overhead van de runtime. Stel je voor dat Crysis in Java is geschreven… zelfs als dat het enige zichtbare verschil is, zou het gewoon niet hetzelfde zijn (ik ben er ook vrij zeker van dat je een Core i7 nodig hebt om het uit te voeren.).
Dit betekent niet dat deze talen geen plaats hebben in de ontwikkeling van games – en nee, ik heb het niet alleen over het programmeren van tools. Voor de meeste games heb je dat extra beetje prestatie dat je krijgt van C++ niet nodig, inclusief 3D-games, en als je het helemaal opnieuw schrijft, kan het volkomen logisch zijn om zoiets als XNA te gebruiken – in feite is er een grote kans van wel.
Wat commerciële games betreft: telt RuneScape? Dat is misschien wel het meest succesvolle Java-spel dat er is.
Antwoord 2, autoriteit 60%
Ik denk dat John Carmack het het beste zei met:
Het grootste probleem is dat Java erg traag is. Op een puur cpu / geheugen / display / communicatieniveau zouden de meeste moderne mobiele telefoons aanzienlijk betere spelplatforms moeten zijn dan een Game Boy Advanced. Met Java heb je op de meeste telefoons ongeveer de CPU-kracht van een originele 4,77-MHz IBM-pc en een slechte controle over alles.
[…knip…]
Schrijf-eenmaal-run-anywhere. Ha. Hahahaha. We testen momenteel slechts op vier platforms en geen enkel paar heeft exact dezelfde eigenaardigheden. Alle commerciële games worden voor elk (vaak 100+) platform afzonderlijk aangepast en samengesteld. Draagbaarheid is geen rechtvaardiging voor de vreselijke prestaties.
(bron)
Toegegeven, hij had het over mobiele platforms, maar ik heb soortgelijke problemen met Java als geheel gezien vanuit een C++-achtergrond.
Ik mis het om op mijn eigen voorwaarden geheugen op de Stack/Heap te kunnen toewijzen.
Antwoord 3, autoriteit 34%
Om te beginnen maakt Java’s gebrek aan overbelasting door operators alle wiskunde waarmee je te maken krijgt om een werkende grafische pijplijn te krijgen erg, erg vervelend en moeilijk te lezen.
Alle matrixvermenigvuldiging en affiene vectoren waarmee u te maken hebt, zijn een stuk gemakkelijker te volgen als ze in goed gevormde wiskundige uitdrukkingen zijn in plaats van objectgeoriënteerde uitdrukkingen zoals
product = vector.multiply(projectionMatrix).dotProduct(otherVector);
Dat is gewoon verschrikkelijk. Wiskunde hoort er niet zo uit te zien.
Antwoord 4, autoriteit 16%
Ik denk dat .NET veel van dezelfde waargenomen problemen had (heeft) als Java. Microsoft heeft zojuist beter werk geleverd op het gebied van marketing naar ontwikkelaars met XNA 🙂
Antwoord 5, autoriteit 11%
Mindere punten eerst:
-
elke productiviteitsverhoging van Java is
hypothetisch. De syntaxis is bijna
identiek aan C++ dus je bent echt
gewoon bankieren op besparingen uit het geheugen
beheer en standaardbibliotheken.
De bibliotheken hebben weinig te bieden
spelontwikkelaars en geheugen
management is een controversiële kwestie vanwege
naar huisvuilophaling. -
platformoverschrijdend “gratis” is niet zo
goed als je denkt, want weinig
ontwikkelaars willen OpenGL gebruiken en
verschillende belangrijke platforms missen waarschijnlijk een
goede Java-implementatie of wrappers
voor hun eigen bibliotheken, of
voor afbeeldingen, audio, netwerken, enz.
Maar het probleem is vooral achterwaartse compatibiliteit. Spelontwikkelaars zijn overgestapt van C naar C++ en van assembly naar C, puur omdat de migratieroute soepel verliep. Elk werkt nauw samen met het vorige, en al hun vorige code was bruikbaar in de nieuwe taal, vaak via een enkele compiler. Daarom ging de migratie zo langzaam of zo snel als je wilde. Sommige van onze oude headers die tegenwoordig worden gebruikt, hebben bijvoorbeeld nog steeds #ifdef WATCOMCin, en ik denk niet dat iemand de Watcom-compiler hier in een decennium of langer heeft gebruikt. Er is een enorme investering in oude code en elk bit wordt alleen vervangen als dat nodig is. Dat proces van het vervangen en upgraden van stukjes en beetjes van het ene spel naar het andere is lang niet zo praktisch als je bent overgestapt op een taal die niet standaard samenwerkt met je bestaande code. Ja, C++/Java-interoperabiliteit is mogelijk, maar erg onpraktisch in vergelijking met het simpelweg schrijven van “C met een beetje C++” of het insluiten van asm-blokken in C.
Om C++ op de juiste manier te vervangen als de taal van de game-ontwikkelaars, moet het een van de volgende twee dingen doen:
- Wees gemakkelijk interoperabel met
bestaande legacy code, dus
investeringen behouden en
toegang houden tot bestaande
bibliotheken en tools, OF - Aantoonbaar
toon van tevoren genoeg van een
productiviteitsverhoging die de kosten van
al je eigen code herschrijven (of
het herwerken van de interfaces in
herbruikbare componenten die kunnen worden gebruikt
uit die taal) is meer dan
gedekt.
Subjectief denk ik dat Java aan geen van beide voldoet. Een taal op een hoger niveau kan de 2e ontmoeten, als iemand dapper genoeg is om de pionier te zijn. (EVE Online is waarschijnlijk het beste voorbeeld dat we hebben van Python die bruikbaar is, maar die een vork van de belangrijkste Python-taal gebruikt, veel C++-componenten voor prestaties, en zelfs dat is voor een vrij weinig veeleisende game in moderne termen.)
Antwoord 6, autoriteit 8%
Ik speel de Sims 3 en ik heb wat rondgekeken.
De grafische engine is C++, terwijl de scripting- en gedragsengine C#/Mono is.
Dus terwijl C++ er is voor tijdkritische bits, andere dingen zoals .interactie, gamelogica, is AI in een objectgeoriënteerde beheerde taal.
Antwoord 7, autoriteit 8%
- Zijn er goede poorten voor gaming-engines/bibliotheken?
- Veel C/C++-ontwikkelaars, vooral die op Windows (waar de meeste commerciële games worden geschreven) zijn bekend met Visual Studio. Er is geen vergelijking in IDE’s.
- Over het algemeen is Java verkocht aan bedrijven vanwege het solide typen en de perceptie dat het geen problemen heeft met geheugenbeheer.
- En ja, Java heeft nog steeds de indruk dat het traag is en dat het geheugenbeheer slecht is, en voor games is het waarschijnlijk niet geschikt voor de taak. Zoals vermeld in sommige van de andere antwoorden, zal het verzamelen van afval het gewoon niet redden als je te maken hebt met realtime high-performance vereisten. Videogames duwen CPU’s en GPU’s tot het uiterste.
Antwoord 8, autoriteit 6%
Een van de grootste redenen waarom Java en andere talen voor virtuele machines niet worden gebruikt voor games, is de Garbage Collection. Hetzelfde geldt voor .NET. Het verzamelen van afval heeft een lange weg afgelegd en werkt uitstekend in de meeste soorten toepassingen. Om de prullenbak te kunnen verzamelen, moet u de toepassing echter pauzeren en onderbreken om de prullenbak te verzamelen. Dit kan een periodieke vertraging veroorzaken bij het verzamelen.
Java heeft hetzelfde probleem voor realtime toepassingen. Wanneer taken op een specifiek tijdstip moeten worden uitgevoerd, is het moeilijk om een geautomatiseerde taak zoals het ophalen van afval dat te laten respecteren.
Het is niet zo dat Java traag is. Java is niet goed in het afhandelen van realtime taken.
Antwoord 9, autoriteit 5%
Een belangrijke reden is dat videogames vaak directe kennis van de onderliggende hardware vereisen, en er is echt geen goede implementatie voor veel architecturen. Het is de kennis van de onderliggende hardware-architectuur die ontwikkelaars in staat stelt om elk grammetje prestatie uit een spelsysteem te persen. Waarom zou je de tijd nemen om Java naar een gameplatform te porten en vervolgens een game op die poort te schrijven, terwijl je de game ook gewoon zou kunnen schrijven?
edit: dit wil zeggen dat het meer is dan een kwestie van “snelheid” of “niet over de juiste bibliotheken beschikken”. Die twee dingen gaan hiermee hand in hand, maar het is meer een kwestie van “hoe laat ik een systeem als de cel mijn java-code uitvoeren? er zijn niet echt goede java-compilers die de pijplijnen en vectoren kunnen beheren zoals ik nodig heb..”
Antwoord 10, autoriteit 4%
Prestatieprobleem is de eerste reden. Als je het soort hypergeoptimaliseerde C++-code ziet die in de Quake-engines zit ( http://www.codemaestro. com/reviews/9), weet je dat ze hun tijd niet gaan verspillen met een virtuele machine.
Natuurlijk zijn er enkele .NET-games (welke? Ik ben geïnteresseerd. Zijn er enkele echt CPU/GPU-intensieve games?), maar ik denk dat het meer komt omdat veel mensen experts zijn in MS-technologieën en Microsoft volgden toen ze hun nieuwe technologie lanceerden.
O, en platformonafhankelijk is gewoon niet in de geest van videogamebedrijven. Linux is slechts ongeveer 1% van de markt, Mac OS een paar procent meer. Ze denken absoluut dat het niet de moeite waard is om alleen Windows-technologieën en bibliotheken zoals DirectX te dumpen.
Antwoord 11, autoriteit 3%
Je kunt je afvragen waarom webapplicaties niet ook in C of C++ zijn geschreven. De kracht van Java ligt in de netwerkstack en het objectgeoriënteerde ontwerp. Natuurlijk hebben C en C++ dat ook. Maar dan op een lagere abstractie. Dat is niets negatiefs, maar je wilt toch niet elke keer het wiel opnieuw uitvinden?
Java heeft ook geen directe hardwaretoegang, wat betekent dat je vastzit aan de API van alle frameworks.
Antwoord 12, autoriteit 3%
Misvattingen over prestaties en slechte JVM-optimalisaties zijn mijn gok. Ik zeg misvattingen over prestaties omdat er sommige Java-poorten van C++-games zijn die sneller presteren dan hun C++-tegenhangers (zie Jake 2). Het echte probleem, IMHO, is dat veel Java-programmeurs niet zozeer gefocust zijn op geavanceerde prestaties als wel op gebruiksgemak en begrijpelijkheid/onderhoudbaarheid van code. Aan de kant van C/C++ codeer je in wezen in een assembleertaal van iets hoger niveau en het komt ongeveer zo dicht bij de hardware als je kunt krijgen zonder in assembly of gewone machinecode te schrijven.
Antwoord 13, autoriteit 3%
Lijst van game-enginesop Wikipedia vermeldt veel game-engines samen met de programmeertaal die ze zijn geschreven in.
Er zijn verschillende Java-game-engines vermeld.
Als u op enkele van de links klikt, komt u bij voorbeelden van games en demo’s die in Java zijn geschreven. Hier is een paar:
Voor bepaalde spellen en situaties kunnen Java’s compromissen acceptabel zijn.
Antwoord 14, autoriteit 2%
.NET heeft zeker een aantal van dezelfde problemen die Java heeft als het gaat om intense 3D-prestaties. Microsoft heeft ook veel meer tijd en geld geïnvesteerd in de ontwikkeling van de bibliotheken als het gaat om het werken met zware 3D-bewerkingen.
(…persoonlijk denk ik ook dat ze een voorsprong hadden als het gaat om de magie tussen DirectX en .NET)
Antwoord 15
-
Java is traag, het meeste zware werk wordt niet gedaan door de GPU. Er is nog steeds animatie, fysica en AI die de CPU raken, die allemaal erg tijdrovend zijn.
-
Java bestaat niet op consoles en consoles zijn een belangrijk doelwit voor commerciële games. Als u Java op pc gebruikt, elimineert u uw mogelijkheid om binnen een redelijke tijd en binnen een redelijk budget over te zetten naar consoles.
-
Veel van de meer ervaren programmeurs in de game-industrie gebruikten C en C++ al lang voordat Java populair werd. De twee bovenstaande punten kunnen hieraan bijdragen, maar ik verwacht dat veel professionele spelprogrammeurs Java gewoon niet zo goed kennen.
-
Het punt van iemand anders over middleware hierboven was een goede, dus ik voeg het toe aan mijn antwoord. Er is veel oude code en middleware die speciaal is geschreven om te linken met C/C++, en de laatste keer dat ik controleerde dat Java geen goede interoperabiliteit heeft. Het gebruik van Java voor de meeste bedrijven zou betekenen dat er veel code wordt weggegooid, waarvan een groot deel op de een of andere manier is betaald.
Antwoord 16
Eigenlijk is het heel goed mogelijk voor beheerde code om 3D-games te doen, het probleem zijn de back-engines. Met .Net was er voor een korte periode een Managed DirectX-wrapper voor DirectX 9 door Microsoft. Dit was vóór de abstractie die nu XNA is.
Omdat ze volledige toegang krijgen tot DirectX api’s, werken .Net-games een plezier. Het beste voorbeeld dat ik ken is www.entombed.co.uk, dat is geschreven in VB.Net.
Helaas ontbreekt het aan Java-kant ernstig – voornamelijk omdat DirectX niet beschikbaar is voor Java en gameprogrammeurs de DirectX-api kennen en begrijpen – waarom nog een andere api leren als je terugkeert naar DirectX ?
Antwoord 17
Gamemarketing is een commercieel proces; uitgevers willen een kwantificeerbaar rendement op hun investering met een laag risico.
Als gevolg hiervan ligt de nadruk meestal op technologische gimmicks (met uitzonderingen) die consumenten zullen kopen om een betrouwbaar rendement te behalen – dit zijn meestal oppervlakkige visuele effecten zoals lensverblinding of een hogere resolutie.
Deze effecten zijn betrouwbaar omdat ze gewoon gebruik maken van een toename van de verwerkingskracht – ze maken gebruik van de hardware/de wet van Moore.
dit impliceert het gebruik van C/C++ – java is meestal te geabstraheerd van de hardware om deze voordelen te benutten.
Antwoord 18
Ik denk dat die snelheid nog steeds het probleem is. Cross-platform wordt een probleem, nietwaar, omdat je niet weet welke 3D-kaart beschikbaar is wanneer je de code schrijft? Heeft Java iets ter ondersteuning van automatische detectie van 3D-mogelijkheden? En ik vermoed dat er tools zijn om het overzetten van een game tussen de wii, xbox en ps3 te vergemakkelijken, maar ik wed dat het duur is.
De ps3 heeft java, via de blue ray-ondersteuning. Check de bd-j site.
Antwoord 19
Zelfs games die op het .Net-platform zijn geschreven, zijn vaak sterk geoptimaliseerd voor snelheid, zoals directe toegang tot geheugen en bus. .Net maakt het mogelijk om C / C++ te gebruiken en te mixen met talen van een hoger niveau, zoals C#.
Game-ontwikkelingsstudio’s werken vaak nauw samen met hardwareleveranciers, die wel toegang bieden tot low-level interfaces van hun producten. Dit is een wereld waarin je ASM en C moet gebruiken voor apparaatcommunicatie. Een virtuele omgeving zou deze programmaonderdelen vertragen.
Hoe dan ook, moderne 3D-games gebruiken in feite talen van een hoger niveau. Vaak vind je de spellogica geschreven in talen als Lua of Python. Maar de kern (I/O, threads, taakplanning) van het typische 3D-spel zal de komende 25 jaar in lage talen worden geschreven of zolang apparaten zelf geen abstractie en virtualisatie toestaan (wat zal komen).
Antwoord 20
Ik ben het eens met de andere berichten over het gebruik van elementen van een reeds bestaande/gelicentieerde codebase, prestaties, enz.
Eén ding dat ik wil toevoegen, is dat het moeilijk is om vervelende DRM-trucs door een virtuele machine te halen.
Ik denk ook dat er een hybriscomponent is waar projectmanagers denken dat ze stabiele/betrouwbare code kunnen maken met C++ met alle voordelen zoals absolute controle over hun tools en middelen, MAAR zonder alle negatieven die hun concurrentie compliceren en verzwakken omdat “we zijn slimmer dan zij”.
Antwoord 21
Runescape van Jagex is geschreven in Java, de “videogame”-tag is misschien niet specifiek van toepassing op het feit dat het een online game is, maar het heeft wel een behoorlijke aanhang.
Antwoord 22
Er is al veel over gesproken, je kunt zelfs op Wiki de redenen vinden…
- C/C++ voor de game-engine en alle intensieve dingen.
- Lua of Python voor scripting in de game.
- Java – zeer-zeer slechte prestaties, groot geheugengebruik + het is niet beschikbaar op gameconsoles (het wordt gebruikt voor een aantal zeer eenvoudige games (ja, Runescape telt hier mee, het is niet Battlefield of Crysis of wat er nog meer is) omdat er veel programmeurs zijn die deze programmeertaal kennen).
- C# – groot geheugengebruik (het wordt gebruikt voor een aantal zeer eenvoudige spellen, alleen omdat er vrij veel programmeurs zijn die deze programmeertaal kennen).
En ik hoor steeds meer Java-programmeurs die mensen proberen te overtuigen dat Java niet traag is, het is niet traag om een widget op het scherm te tekenen en een aantal ASCII-tekens op de widget te tekenen, om gegevens te ontvangen en te verzenden via het netwerk( En het wordt aanbevolen om het in deze gevallen te gebruiken (manipulatie van netwerkgegevens) in plaats van C/C++)… Maar het is verdomd traag als het gaat om serieuze dingen zoals wiskundige berekeningen, geheugentoewijzing/-manipulatie en veel van deze goede dingen .
Ik herinner me een artikel op de MIT-site waar ze laten zien wat C/C++ kan doen als je de taal- en compilerfuncties gebruikt: Een matrixvermenigvuldiger (2 matrices), 1 implementatie in Java en 1 implementatie in C/C++, met C /C++-functies en geschikte compiler-optimalisaties geactiveerd, was de C/C++-implementatie ~296.260 keer sneller dan de Java-implementatie.
Ik hoop dat je nu begrijpt waarom mensen C/C++ gebruiken in plaats van Java in games, stel je Crysis voor in Java, er zou geen computer in deze wereld zijn die dat aan zou kunnen… + Garbage collection werkt goed voor Widgets die alleen heeft een afbeelding vernietigd, maar het is daar nog steeds in de cache opgeslagen en moet worden opgeschoond, maar niet voor games, je zult zeker nog meer vertragingen hebben bij elke activering van de garbagecollection.
Bewerken: omdat iemand hier om het artikel vroeg, heb ik in het webarchief gezocht om dat te krijgen, ik hoop dat je tevreden bent…MIT Case Study
En om toe te voegen, nee, Java voor gaming is nog steeds een vreselijk idee. Slechts een paar dagen geleden begon een groot bedrijf dat ik niet zal noemen, hun game clientte herschrijven van Java naar C++ omdat een heel eenvoudig spel (in termen van grafische weergave) achterbleef en i7-laptops verwarmde met krachtige nVidia GT Videokaarten van de 5xx- en 6xx-generatie (niet alleen nVidia, het punt hier is dat deze krachtige kaarten de meeste nieuwe games op Max-instellingen aankunnen en deze game niet aankunnen) en het geheugenverbruik was ~2,5 – 2,6 GB Ram. Voor zulke simpele graphics heeft het een beest van een machine nodig.