Válasz
Igen, ellenőrizze ezt a listát . Ezek közül néhány játék Java-val készült a The Lightweight Java Game Library (LWJGL) segítségével. Alacsony szintű keretrendszer, amely OpenGL-t biztosít a kiváló minőségű grafikához és OpenAL a hangokhoz. Ezenkívül bemeneti API-t is biztosít. Ezekkel könnyedén belekezdhet a komoly játékfejlesztésbe a Java-ban.
Jelenleg a második 3D-s játékomat írom hobbi projektként a Java-ban, és nagyon szeretem. Korábban a C ++ – val írtam a játékaimat, de miután Java-ra váltottam, nincs visszaút. Több operációs rendszer támogatása a Java-val nagyon egyszerű lehet, például az előző Java-játékom, amelyet egy éven át fejlesztettem a Windows-ban, azonnal Linux-ban és OS X-ben dolgoztam, egyetlen hibával, anélkül, hogy bármit is össze kellett volna fordítani ezeken a platformokon.
Másrészt a Java-val pár problémád van.
- Szemétgyűjtő. Amint mások elmondták, a nem determinisztikus memóriakezelés problémát jelent, és ezt szem előtt kell tartania.
- Harmadik fél könyvtárainak hiánya. Az elérhető könyvtárak többsége nem támogatja a Java-t. Másrészt mindig lehetősége van ezeknek a natív könyvtáraknak a Java-ból történő meghívására is, de ennek nagyobb munkája van. Vannak Java portok vagy kész csomagolók is a népszerű könyvtárak számára, például I div id = “5f0427bdcb”>
JBullet – a Bullet Physics Library Java portja . Másrészt a Java hatalmas osztálykönyvtárral rendelkezik, amely csökkenti a külső játékkönyvtárak iránti igényt. A könyvtárak hiánya számomra nem jelentett problémát, de el tudom képzelni, hogy mások számára is.
Válasz
Nem igazán. Itt “a lényeg – egyrészt a Java meglévő könyvtárai tekintetében nagyon kevés van, összehasonlítva a gyakorlatilag mindennel hez, ami a C ++ programhoz tartozik.
Másodszor, a Java mint nyelv egyszerűen nem alkalmas játékfejlesztésre – úgy értem, hogy például ha GPU pufferekkel foglalkozol, akkor a Java nem nyújt olyan nyelvi funkciót, amely segíteni fog abban, hogy megfelelően zárolódjanak, feloldódjanak vagy ártalmatlanuljanak, amit C ++ Ráadásul ott van a teljesítményprobléma – és a GC nem determinisztikus, ami nagyon rossz egy játék esetében.
Még soha nem figyeltem meg egy nem indie játékot, amely jelentős időt töltött volna egy játékban. a nyelv, amelyet a végrehajtás előtt nem fordítottak le natív kódra, sőt az ezt indie játékok is ritkaságnak számítanak.Tehát jelenleg az a meggyőződésem, hogy egyszerűen nem lehet megcsinálni.
Továbbá, ha továbbra is tanulom és fejlesztem a Java-t, és kiderül, hogy később Meg kell tanulnom a C ++ nyelvet, megnehezíti-e a váltást?
Igen, abszolút meglesz. A Java és a C ++ nagyban különbözik től, annak felületi szintaktikai hasonlósága ellenére. A Java-gyakorlat gyakorlatilag semmit sem számít a C ++ elsajátításakor.
A grafikus játékkal való játék egy életképes választás, és ezt láthatja olyan játékok sikerében is, mint a Terarria és a Minecraft. De ha srs grafikát kíván létrehozni, akkor ez nem lesz megvalósítható a Java-ban.
Megjegyzések
- +1, mivel nehéz grafika, gyors játék késés nélkül.
- Java ' az aláíratlan adattípusok hiánya is ellene áll. Igen, megkerülheti, de ' nem ideális, és ' olyan kódot használ, amely nem ' tükrözi az alapul szolgáló adatok helyesen.
- @deadmg lezárt és feloldott esetek, utalsz valamilyen DirectX api funkcióra? & mondd meg, mi ' olyan rossz, ha nem determinisztikus GC-vel rendelkezel.
- A nem-determinisztikus GC egyenlő a keretek eldobásával, ha rossz megállót kapsz A világ szünetel, és hosszabb ideig zárolja a dolgokat, mint amennyi a keret megjelenítéséhez szükséges. A gyakorlatban ez nem történik meg gyakran / soha, ha megtervezi a memóriáját. use, a JVM ' s gyűjtők alacsony szünetre konfigurálhatók (jóval a biztonságos határok között a keret elejtéséhez). Ennek ellenére ' nem szórakoztató dolog, amellyel foglalkoznia kell. Végül jelentős összegeket kell visszaadnia a C ++ elhagyásakor megszerzett termelékenységből.
- A kezdet ' teljesen újra kell írnia.
Válasz
Tehát nagyon komolyan gondolom játékfejlesztés, a Java még mindig életképes választás? Többször próbáltam megtanulni a C ++ nyelvet, de nem igazán szeretem a nyelvet. Nem igazán tudom, miért, de általában, amikor megpróbálok tanulni, soha nem tudom megérteni a témákat.
Ha a Java választásának oka az, hogy nem tudta megérteni a C ++ nyelvet, akkor a Java programjai nem lesznek elég gyorsak a kiváló minőségű grafikákhoz. A magasabb szintű nyelv használatának azért kell lennie, mert ez produktívabbá teszi Önt, nem pedig azért, mert az alacsonyabb szintű nyelvet nem érthette.
Nem gondolom, hogy teljesen rossz ötlet játékot írni Java, különösen, ha a játék egyszerű, de ha a mankóként használja, azonnal problémákat fog tapasztalni a Java-ban.
Tehát röviden: komolyan vehető-e a Java komoly játékfejlesztéshez. Ez magában foglalja a nehéz grafikákat, a gyors játékot késés nélkül, és esetleg a konzolokra való egyszerű átállást?
-
Nehéz grafika: Lehetséges, de ugyanazt fogod csinálni a Java / LWJGL-ben, mint a C ++ / GL-ben: bájtokat írsz a GPU pufferekbe és / vagy a elavult megjelenítési listák, mint a Minecraft. Ha nem érti a memóriakezelést, akkor ezt sem fogja helyesen megtenni.
-
Gyors játék késés nélkül: Nem könnyű feladat bármilyen nyelven, és nagyobb az esély arra, hogy mindkét irányba belelövi magát anélkül, hogy belegondolna.
-
Nem, a Java nem lesz elérhető a konzolokon.
Megjegyzések
- Mellékkérdésként, mi helyettesítette a megjelenítési listákat, amikor elavultak?
- @Suds: Úgy gondolom, hogy programozható folyamat.
- ha! már lefedte. VBO-k : gamedev.stackexchange.com/questions/22170/…
- Mobil platformok konzolok. Tudomásul veszem, hogy valószínűleg a nagy háromról beszélt, de az Android Java-t használ, és rengeteg játék készül hozzá.
- @ Amplify91 igen, néhány játék java-ban van írva androidra. De a legtöbb jó játékok és valószínűleg minden grafikus intenzív vagy több platformos játék C ++ nyelven íródott az Android NDK használatával.
Válasz
Egy kísérlet A programozott programozó általában sok programozási nyelvet ismer – az extra programozási nyelvek megtanulása nem túl nehéz, ha jól ismer egyet. Mindazonáltal erősen ajánlom, hogy a C ++ ne legyen az első, és valószínűleg a második sem.
Ez azért van, mert a C ++ nagy hatékonyságot kap, ha nem hajt végre jelentős futásidejű hibákat. Például egy Java tömb végén kívüli elem elérése mindig kivételt eredményez, és pontosan megmondja a programozónak, hogy mi a baj.A C ++ rendszerben szerencsés lehet, és azonnal összeomlik, de nagyon gyakran csendben szemetet helyez más adatokba, és a hiba nem jelenik meg sokkal később .
Azt javasolnám, hogy most ragaszkodjon a Java-hoz (vagy váltson C # -ra, ha ezt szeretné). Ez lehetővé teszi a dolgok gyorsabb elvégzését, mint a C ++ használata, és a PC-n történő teljesítmény nem lehet kérdés.
Gondoljon a C ++ megtanulására, miután befejezett néhány projektet biztonságosabb nyelveken. A legtöbb professzionális játékfejlesztő munkára a C ++ szükséges.
Ne feledje, hogy a C # / XNA kivételével a konzolra írt játék minimálisan megköveteli, hogy céget hozzon létre, irodával rendelkezik, és nagy költségkerettel rendelkezik hardveres fejlesztési és egyéb kiadásokra.
Megjegyzések
- Ez azért is kivételesen igaz, mert a C ++ -on kívül más nyelvek is teljesítményérzetet ad. A C ++ több száz órát is igénybe vehet, ami semmit sem érezhet. Más nyelvek megtanulása először beáztatja a lábát.
- A hibakezelés hiányával kapcsolatos megjegyzéseid valóban a C-ről (és az úgynevezett C ++ kódról, amely valójában C). A C ++ szabványos könyvtárakkal (és szabványos sablonkönyvtárakkal) rendelkezik, amelyek sokkal jobb hibakezeléssel rendelkeznek, mint amit leír. tisztességes hibakezelés.
Válasz
Jogi nyilatkozat: Ez nem felel meg pontosan a kérdésére. Megpróbáltam azonban (röviden) megemlíteni néhány olyan pontot, amely érdekes lehet számodra.
Azért lát annyit a C ++ -ról, hogy a C ++ továbbra is az ipari szabvány – a konzolok stb. leggyakoribb nyelve.
A Java-t nem használják gyakran. A Minecraft egy elég népszerű játék, amely nagyra tette a Java-val; de grafikailag nem olyan nagy. A Spiral Knights nem rossz – szintén Java-ban készült, jelentős grafikával.
Ha szereted a Java-t, a C # szintaxisában nagyon hasonló, azzal az előnnyel, hogy képes egyeztessen a C ++ -al – így szükség esetén alacsony szintű dolgok is elvégezhetők a C ++ nyelven. Az Unity a C # -ot használhatja szkriptek készítéséhez, az XNA pedig kiváló választás.
Ismételten a Java-t nem használják széles körben. a stílus és a szintaxis, azt hiszem, a C # -ot nagyon hasonló, nagyon kellemes kódolási élménynek fogja találni.
Remélem, hogy az álmaid sikerülnek, ez nagyon szórakoztató az út mentén:)
Megjegyzések
- Sok-sok pontatlanság ebben a bejegyzésben. Minecraft " rossz " grafika nem (erősen) kapcsolódik a nyelvhez. Az MC rossz teljesítménye közvetlenül összefügg azzal, hogy a Java rossz játéknyelv, mert HATALMAS teljesítményproblémák, és az LWJGL ugyanezen okból alkalmatlan könyvtár nagy kódolási projektekhez De a legnagyobb tényező Notch
hibás kódolása és megvalósítása, amelyet javítanak … lassan. A C # a kezelt memória összes részét megadja a Java teljesítményproblémák nagy része nélkül. Hátránya, hogy a C # mind a játékok, mind az alkalmazások terén nagymértékben a Microsoft-központú.
- @EfEs: Utálom neked átadni, de a kezelt memória szörnyű a játékok számára, és azoknak, akik XNA-ban kódolják a játékokat, több időt kell eltölteniük a memória kezelésével, mint azoknak, akik C ++ nyelven kódolnak. A GC nem determinisztikus jellege azt jelenti, hogy gyakorlatilag mindent össze kell gyűjteni, és el kell kerülni a kiosztást, mint a pestis – nem a nyelv használatának módját.
- Ez a válasz nem 100% -ban pontos volt. ; Csak olyan példákat hoztam fel, amelyekről homályosan tudok. Nyugodtan használja a DV-t.
- @DeadMG tudom, hogy a C ++ az út, csak azt próbáltam elmagyarázni, hogy a C # jobb, mint a Java a játékokhoz.
- Hosszú idő C # fejlesztő (nem játékfejlesztői gondolat) Úgy gondolom, hogy a pooling és a memóriakezelés minden rosszul megtervezett rendszer számára nagy kérdés. Azok a személyek, akiknek C / C ++ gondolkodásmódjuk és fejlődési módjaik vannak, alig ismerem a kezelt memóriát, a tervezési és az építészeti mintákat, amelyeket fel kell használni, és kihasználják ezeket egy olyan nyelven, mint a Java / C #. Azt akarom mondani, hogy nem a C / C ++ technikák vagy termékek rosszak, hanem az, hogy még ha szintaxis szempontjából is egyszerűbb nyelveket használ (például a Java és a C #), akkor is sok tapasztalatra van szüksége a játék megfelelő megtervezéséhez módon.
Válasz
Nézd haver, az egyszerű válasz a “Van Java életképes játék dev számára “nyilvánvaló igen. Bármely programozási nyelvet használhat játékok készítéséhez. Ez nem azt jelenti, hogy kellene.
Valószínűleg éppen azok, amelyek kikapcsolnak a C ++ ( alacsony szintű memóriakezelés, nincs szemétgyűjtő, figyelni kell a mutatókra, a struktúrákra, mint tömbökre stb.) az a dolog, amit meg kell tanulnia, ha ki akarja használni a számítógépet erőforrások a leghatékonyabban .A játékaid akkor működnek a legjobban, ha a számítógép erőforrásait használod a leghatékonyabban.
A Java olyan dolgokat hajt végre (például tömbhatárok ellenőrzése), amelyek csak lassabbá teszik a futást. <
ezt a optimalizált Java Perlin zaj példakódot, a szerző megjegyezte: “(a tömb elérése sokkal lassabb, mint a tagok hozzáférése)”. Ez a fajta dolog meglehetősen ellentmondásos, C ++ háttérből származik. De Java, ilyenek.
Azt mondom, ne állj meg a golyó elől, tanuld meg a C ++ -t, és használd.
Válasz
Ez nem válaszol a kérdésére; úgy tűnik, hogy a grafikus és konzolos kérdések nagyon meg kell fontolnia. A GC szintén befolyásolja a teljesítményt. De miről írok:
Ha nagy, összetett, OO programokat írsz, akkor ötször gyorsabban fogod írni őket Java-ban, mint a C ++. Emellett a karbantartás is sokkal könnyebb lesz. Váltottam (igaz, nem játék szoftverek esetében), és a termelékenységem az egekbe ugrott. A C #, egy másik jó alternatíva, nehezebb megtanulni, mint a Java, mert “sokkal több van belőle. Amikor tudod, még gyorsabban is írhatsz kódot, mint a Java-ban; sok trükköt kínál neked. Megtalálom azonban ezeket a trükköket megnehezítheti a karbantartást. És akkor ott van egy Java doc, amely segít a Sun könyvtárakban és a saját régi kódodban. A C # -nek nincs semmi hasonló.
Nagy szőrös játékot csináltam Java-ban, és tökéletesnek találtam a nyelvet, de a grafikám elemi volt, és nem volt olyan lövöldözős játék, ahol a tizedmásodperc örökkévalóság volt a játékosok. Ezenkívül azt remélem, hogy később sokat hozzá fogok tenni, miközben azt gondolom, hogy az emberek többsége csak vadonatúj játékot ír.
Válasz
Tedd azt a nyelven, amelyet a legjobban tudsz, amíg meg nem engedheted magadnak a számítástechnika formális oktatását (Bachelor of Science?), hangsúlyozva a játéktervezést . Esetleg felhasználhatja a játékát ösztöndíj megszerzésére, különösen, ha azt tudja mondani, hogy “Ezt minden hivatalos formai Java-képzés nélkül csináltam”.
Modern JVM-ek, még az Oracle-től is, sok-sok funkcióval rendelkezik az emberek által itt felvetett aggodalmak kezelésére. Különböző hulladékgyűjtőkkel meghatározhatóbb szemétgyűjtő viselkedéshez juthat. Nincs széleskörű tapasztalatom a 3D könyvtárakkal kapcsolatban – csak egy kicsit a Java3D-vel -, de úgy tűnik, itt senki sem panaszkodott rájuk. A menekülési elemzés most lehetővé teszi a zár elízióját és a nagyon rövid életű objektumok sokkal gyorsabb / elhanyagolhatóbb elosztását.
A probléma az, hogy a C ++ Java-t választja-e, meg kell tanulnia, hogyan kell helyesen használni az egyidejűséget, és jól meg kell ismernie a memóriakezelést. Végül is ugyanolyan egyszerűen csavarhatja a malloc t, mint a new. Nem tudom, milyenek az eszközök a C ++ számára, de a Java profilkészítő eszközei meglehetősen egyszerűen használhatók, ingyenesek és integrálhatók az IDE-hez. Használhatja őket a teljesítményproblémák felkutatására és tanulás .
megjegyzések
- A formális oktatás CS-ben megéri a szart a tényleges programozási képességekért bármilyen tudományterületen. Tudnám, én ' m harmadik évemben.
- Határozottan nem értek egyet a DeadMG-vel. Miután elvégeztem és kiválasztottam a számomra tetsző tanfolyamokat, a CS 10% -ról 100% -ra emelte játékfejlesztési képességeimet. Nem div id = “6cdc09e59a”>
nem tanít nekem felhasználói felületet, ikonográfiát stb., hanem tényleges, valós kódolást.