játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5448
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2520

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
John Hattan: Melyik nyelvet válasszam? 2005.05.05 07:40


Ez egy olyan kérdés, ami minden játékfejlesztéssel kapcsolatos FAQ-ban elõkerül, és a fórumokon hetente többször is megkérdezik. Jó kérdés, de a válasz rá nem egyszerû. Vannak programozási nyelvek, amik bizonyos feladatok elvégzésére alkalmasabbak másoknál. Ez a cikk tulajdonképpen egy lista a fontosabb programozási nyelvekrõl, amiket játékírásra használnak, leírással, elõnyökkel és hátrányokkal. Remélem, segítségedre lesz a jó döntés meghozásában.

C
Ha a FORTRAN és a COBOL voltak az elsõ magasszintû fordított nyelvek, akkor a C az unokájuk. Dennis Ritchie alkotta meg a 70-es években, mint az ALGOL egy kötöttebb és kifejezõbb utódját. (Az ALGOL a strukturált leszármazottja a COBOL és FORTRAN nyelveknek.) A C-t arra tervezték, hogy kisebb és egyszerûbb legyen, mint a fölmenõi, és egyszerû legyen benne rendszerszintû programokat, pl. operációs rendszereket írni. Azelõtt az ezeket „kézzel” írták Assemblyben és nem voltak hordozhatóak. A C volt az elsõ programozási nyelv, aminek segítségével a hardverközeli programok hordozhatókká váltak.
A C egy, a strukturált programozást támogató nyelv. Így akár azt is mondhatjuk, hogy a C programok függvényhívások sorozatai, amik föntrõl lefelé futnak, szemben a monolitikus kódblokkokkal, amikben a vezérlésátadás GOTO utasításokkal történik. Ezért általában a C programok könnyebben érthetõek, mint a monolitikus FORTRAN vagy COBOL „spagettikódja”. (Ennek ellenére a C-ben megtalálható a GOTO utasítás, de használata nagyban korlátozott és csak akkor javasolt, amikor a strukturált megoldás sokkal bonyolultabb lenne.)
A rendszerprogramozási gyökereknek köszönhetõen elég egyszerû a C-t az Assembly nyelvekkel együtt használni. A függvényhívás módja nem komplikált, és az ASM utasításokat akár közvetlenül a C kódba is beágyazhatjuk, így nincs szükség arra, hogy külön fordított Assembly modulokat kapcsoljunk a programunkhoz.
Elõnyök: Alkalmas kicsi és gyors programok írására. Könnyen kapcsolható Assembly nyelvekhez. Jól szabványosított, így a különbözõ platformokon futó verziói hasonlóak.
Hátrányok: Az objektum-orientált programozást csak nagyon nehézkesen támogatja. A szintaxis bonyolult lehet, és szinte adja magát, hogy visszaéljünk vele.
Hordozhatóság: A nyelv magja és az ANSI függvényhívások nagyon jól hordozhatóak, a vezérlésátadásra, memóriakezelésre és egyszerû filemûveletekre vonatkoznak. Minden más platform-specifikus. Pl. egy Mac és Windows között hordozható program megírása azt jelenti, hogy a felhasználói felület részeinek rendszer-specifikus hívásokat kell használni, azaz gyakorlatilag az ilyen részeket kétszer kell megírni, bár vannak könyvtárak, amik ezt a folyamatot leegyszerûsítik.
C-ben írt játékok: rengeteg.
Források: A C klasszikus alapkönyve „A C programozási nyelv”. Az elsõ kiadás óta többször átdolgozták és mára már háromszor akkora, mint eredetileg volt, de máig jó alapot nyújt a nyelv tanulásához. (Továbbá: „The Waite Gruop’s C Primer Plus”)

C++
A C++ a C objektum-orientált utódja. Az objektum-orientált (OO) programok a következõ lépést jelentik a strukturált programozás után. Az OO programok objektumokból állnak, amik adatok és függvények „egybecsomagolt”, szeparált egységei. Sok olyan objektumkönyvtár létezik, amik a programozást annyira leegyszerûsítik, hogy csak egyszerûen egymáshoz kell kapcsolni az objektumokat (legalábbis elvileg). Pl. rengeteg GUI- és adatbázis-könyvtár létezik, amik ilyen módon vannak megvalósítva.
A C++ vita tárgyát képezi, fõleg a játékfejlesztõk között. A C++-nak vannak olyan lehetõségei, mint pl. a virtuális függvények, amik újabb döntéseket követelnek meg a függvényhívásokon felül a programtervezés során, és a kritikusok gyorsan rámutathatnak, hogy a C++-ban írt programok nagyobbak és lassabbak lehetnek, mint a C-ben írt párjaik. A C++ szószólói pedig arra, hogy egy virtuális függvény lekódolása C-ben sokkal nagyobb többletterhet jelent. Ez a vita messzire vezet, és nem lesz egyhamar eldöntve.
Az én véleményem szerint a C++ által jelentett többletmunka egyszerûen az az ár, amit a jobb nyelvért fizetsz. Ugyanez a vita lejátszódott, amikor a 60-as években a magas szintû nyelvek (FORTRAN, COBOL) kezdték kiszorítani a „kézzel” kódolt Assembly programokat. A kritizálók helyesen jegyezték meg, hogy a magasszintû nyelvekben írt programok lassabbak. És ezt viszont ellensúlyozza az, hogy a FORTRAN és COBOL kódot könnyebb karbantartani és fejleszteni.
Elõnyök: Nagy programok tervezéséhez sokkal alkalmasabb, mint a C. Támogatja az objektum-orientált programozást. Általános adatszerkezeteket (mint a láncolt listák és a növelhetõ tömbök) tartalmazó könyvtára (STL) a programozási „rabszolgamunka” jó részét megszünteti.
Hátrányok: Nagyon nagy és komplikált. A C-hez hasonlóan a szintaktikája bonyolult és könnyû vele „visszaélni”. Lassabb, mint a C. Kevés fordító támogatja helyesen az egész nyelvet.
Hordozhatóság: Jobb, mint a C, de még mindig nem a csúcs. A legtöbb GUI library C++ objektumok csoportjaként van megvalósítva.
C++-ban írt játékok: rengeteg. Majdnem minden kereskedelmi játék C-ben vagy C++-ban íródott.
Források: „A C++ programozási nyelv” utolsó kiadása kitûnõ. Az anyagok alapvetõen két táborra bonthatóak, az egyik feltételezi a C nyelv ismeretét, a másik nem. Az alapoktól kezdõk közül messze a legjobb a „Who’s Afraid of C++” és a „Who’s Afraid of More C++”. Ha már ismered a C-t, próbáld ki a „Teach Yourself C++” c. könyvet.

C vagy C++, ez itt a kérdés
A második leggyakrabb kérdés (az elsõ természetesen a „melyik nyelvet válasszam?”), hogy „kell-e C-t tanulni a C++ elõtt”, szintén sok helyen fordul elõ.
Sajnos a válasz nem egyértelmû itt sem. Sok idõt megtakaríthatsz, ha C-t tanulsz, és abban kezdesz alkalmazásokat írni, de ennek két hátránya is van:
Nem fogod megismerni az adatok modellezésének ezt a nagyon hatékony módját, aminek a programok írásakor és tervezésekor kárát fogod látni.
Mivel nem tanulsz OOP-t, olyan „rossz” (strukturált) programozási szokásokat fogsz erõltetni, amik hátráltatnak a munkában, és amiket késõbb már nehéz lesz elhagyni.
A nagy kereskedelmi játékok közül sok köszöni szépen, nagyon jól elvan C++ nélkül. Ennek ellenére ezeknek a programoknak a szerzõi használnak OO technikákat, bár sima C-ben programoznak. Ha úgy döntesz, hogy csak C-t fogsz tanulni, azért foglalkozz az OOP módszereivel is. Az OO megközelítés tökéletes a szimulációs programokhoz (ejtsd: játékok), és valószínûleg a nehezebb utat választod, ha ezeket kihagyod az eszköztáradból.

Assembly
Tulajdonképpen az Assembly volt az elsõ programozási nyelv. Gyakorlatilag nem más, mint a gépi kódú utasítások némileg érthetõbb megjelenítése. Ez azt jelenti, hogy a használt processzor alacsonyszintû jellemzõivel kell dolgoznod, mint pl. regiszterek és a verem. Ha egy könnyen érthetõ, relatíve öndokumentáló programozási nyelvet keresel, ez nem az.
Bármit, amit megtehetsz más nyelvekkel, megteheted Assemblyben is, legfeljebb nem olyan könnyen. Hogy érthetõbb legyen, ez ugyanaz, mint: bárhová, ahova eljuthatsz autóval, eljuthatsz gyalog is. Legfeljebb nem olyan könnyen… Bár az állítás igaz marad, az újabb és újabb technikák sokkal egyszerûbbé teszik a dolgokat.
Általában az Assemblyt nem használják játékok írására. Amelyek mégis, azok is csak egyes sebességkritikus részletekhez. Pl., a DOOM-ot C-ben írták, csak néhány rajzoló rutint kódoltak le Assemblyben. Ezek a programrészek másodpercenként több ezerszer hívódnak meg, ezért ezeknek a sebessége kulcsfontosságú az egész program teljesítményének a szempontjából. Mivel elég könnyû C programból Assembly betéteket hívni, a két nyelv együttes használata nem okozott problémát.
Megjegyzés: A nyelv neve az, hogy Assembly. Az az eszköz, ami az assembly programokat gépi kóddá alakítja, az assembler. Általános hiba, hogy a nyelvet magát hívják assemblernek. Mi azért maradjunk meg a helyes elnevezésnél.
Elõnyök: Az Assembly, mivel az, ami, a legkisebb és leggyorsabb nyelv. Egy tehetséges ASM programozó gyorsabb programokat tud írni, mint bármilyen más nyelven lehetséges. Elsõként használhatod ki az új processzorok adta lehetõségetek, mert közvetlenül kezeled õket.
Hátrányok: Nehéz megtanulni, titkosírásszerû programkód, nem könnyû hatékonyan programozni benne, és sokkal több kódolással lehet csak bármit is megcsinálni.
Hordozhatóság: Nuku. Mivel a nyelv egy egyedi processzorhoz (vagy processzorcsaládhoz) tartozik, abszolút nem hordozható. Ha egy processzor speciális lehetõségeit kihasználó kódot írsz, még az azonos családba tartozó más processzorokon sem lehet majd használni. (Pl. az AMD 3DNOW utasításai nem használhatóak Pentium processzorokon.)
Assemblyben írt játékok: nem tudok egy olyan játékról sem, amit teljesen Assemblyben írtak volna. De néhány játék sebesség szempontjából legkritikusabb részei ebben készülnek.
Források: Egy Assembly nyelv dokumentációja tulajdonképpen az adott processzor dokumentációjához köthetõ. Így a gyártók honlapján lehet információt találni (Intel, AMD, Motorola). Ha könyvet keresel, az „Assembly lépésrõl-lépésre” lesz a jó választás.

Pascal
A Pascal nyelvet Nicolas Wirth tervezte a 70-es évek elején, mert megdöbbenve tapasztalta, hogy a FORTRAN és a COBOL nem kényszerítette a tanulókat a strukturált programozás helyes használatára. A „spagettikód” elfogadottá vált és a nyelvek abban az idõben ezt szinte „legalizálták”. A Pascalt az alapoktól kezdve úgy tervezték, hogy a strukturált programozás használatát kikényszerítse. Bár a Pascalt eredetileg csak tanításra szánták, elég elõnye volt ahhoz hogy a kereskedelmi programozásban is szerephez jusson. Akkor kezdõdött az igazi fénykora, amikor a Borland kiadta a Turbo Pascal nevû fordítóját IBM PC-re. A beépített szerkesztõ, a villámgyors fordító és az alacsony ár kombinációja ellenállhatatlannak bizonyult, és hamarosan a Pascal lett az elsõdlegesen használt nyelv kisebb DOS programok írására.
De ez nem tartott sokáig. A C fordítók hamarosan gyorsabbá váltak, megjelentek a beépített szerkesztõk és debuggerek. Majdnem az utolsó szög került a Pascal koporsójába a 90-es évek elején, amikor megjelent a Windows és a Borland a C-t és a C++-t tette a Windows-programozás elsõdleges nyelvévé. De a Turbo Pascalt nem lehetett elfelejteni.
Végül 1996-ban a Borland piacra dobta a „Visual Basic gyilkos”-nak is becézett Delphit. A Delphi egy gyors Pascal fordító volt, egy nagyszerû kezelõfelülettel párosítva. Minden furcsasága (és a buldózerként elõretörõ Visual Basic) ellenére sok rajongóra tett szert. [A Delphi késõbbi verziói már az ObjectPascal révén az OOP-t is támogatják, ill. manapság a Windowsos programok jó része ebben készül. – a ford.]
Összességében a Pascal egyszerûbb, mint a C. A szintaxisa hasonló, de hiányzik belõle rengeteg rövidítés, amik pedig a C-ben benne vannak. Ez egyszerre jó és rossz is. Nehezebb áttekinthetetlen kódot írni, ugyanakkor az olyan alacsonyszintû dolgok, mint pl. a bitmûveletek nehezebben valósíthatóak meg.
Elõnyök: Könnyen tanulható. Egyes implementációi (Delphi [ill. a Linuxos Kylix – a ford.]) nagyon barátságosak.
Hátrányok: Az objektum-orientált leszármazottai (Modula, Oberon) nem lettek sikeresek. [De ld. a megjegyzést fent. – a ford.] A nyelvi szabványokat a fordítók készítõi nem tartják be. Hordozhatóság: kevés. A nyelv lehetõségei rendszerrõl-rendszerre változnak és nincsenek könyvtárak, amik leegyszerûsítik a folyamatot.
Pascalban írt játékok: Néhány. A Delphi alá készült DirectX komponens egy kicsit megdobta a Pascalban írt játékok számát. [Megint csak ld. a fenti megjegyzést. – a ford.]
Források: A Delphirõl az Inprise Delphi Page-en olvashatsz.

Visual Basic
Áh, a jó öreg BASIC. A 80-as években ez volt az elsõ nyelv, amiben az amatõrök is tudtak programokat írni. Az elsõ BASIC-változatokat könnyû volt elsajátítani, de rettenetesen rendezetlen, GOTO-kkal teletûzdelt „spagettikód” lett az eredménye, ha valaki ezekben írt programot. Azt hiszem, nem sokat sírják vissza a sorszámozást vagy a GOSUB utasítást.
Most pedig ugorjunk át a 90-es évek elejére. A HyperCard nem az a szörny lett, aminek az Apple szánta, hanem egy gyönyörû kis programozási környezet, aminek nem volt párja széles e Windows-világon. A Windows-alapú HyperCard klónok, mint a ToolBook, lassúak voltak és drágák. Hogy ne maradjon le a versenyben, a Microsoft megvett egy csinos kis eszközt, a Thunder-t, és Visual Basic 1.0-ként adta ki. A felhasználói felület abban az idõben rendkívül eredetinek és jónak látszott, a nyelv pedig, amit még mindig Basic-nek hívtak (de immár nem csupa nagybetûvel) sokkal rendezettebb. A sorszámozást eltüntették. Az eredmény inkább hasonlított a Pascal-ra BASIC-stílusú kulcsszavakkal, mint az eredeti ROM-BASIC-re, amit anno a TRS-80, Apple ][ és az Atari tartalmazott.
Hat verzióval késõbb a Visual Basic nagyon elegáns lett. A kezelõfelületen egy keveset változtattak, de még mindig õrzi a „kapcsoljuk azt a kevés kódot a felület elemeihez” stílust. Ez, kombinálva a gyors fordítóval, félelmetesen jó eszközzé teszi a gyors programozásban.
Elõnyök: A nagyszerû IDE. Könnyû megtanulni. Gyors fordítás. Rengeteg elérhetõ kiegészítés. A DirectX 7 alapból fogja támogatni a Visual Basic-et, a korábbi verziókhoz pedig elérhetõek külön komponensek.
Hátrányok: az elkészült alkalmazások nagyok, és sok nagy futásidejû DLL-re van szükség. Könnyen készíthetõ form-alapú felület, de a jó grafika megvalósítása annál nehezebb. A Windows API használata nehézkes, mivel a VB adatstruktúrái nem illeszkednek szépen a C-hez. Vannak OO lehetõségei, de nem teljesen objektum-orientált.
Hordozhatóság: a kevésnél is kevesebb. Mivel a Visual Basic a Microsoft tulajdonában van, nagyban le van korlátozva a támogatott platformok köre. Ez azt jelenti, hogy választhatsz a Windows, a Windows és a Windows között. Azonban van pár eszköz, amelyek segítségével a Visual Basic kódot Java-ra lehet konvertálni.
Visual Basic-ben írt játékok: egy néhány van. Sok shareware játék, és kevés üzleti.
Források: a Microsoft VB oldalai.

Java
A Java-t a Sun eredetileg arra tervezte, hogy egy „kisebb C++” legyen, amit jól lehet használni beágyazott alkalmazásokhoz. A weboldalakban elhelyezett programok ötlete gyorsan megragadta az emberek képzeletét, így a nyelv gyorsan terjedt. Kiderült, hogy a Java nem csak animált bannerek készítésére alkalmas, hanem egyenesen remek alkalmazás-programozáshoz is. A virtuális gép természete, az automatikus szemétgyûjtés és a pointerek hiánya egyszerûvé tették a hibamentes(ebb) programok készítését, amik nem omlanak össze és nincs bennük erõforrás-elszivárgás.
Bár hivatalosan nem a C++ „folyománya”, a Java nagyban a C++ szintaktikájára épül. A készítõk a bonyolultabb C++ funkciók közül többet kihagytak, hogy egy kisebb és könnyebben tanulható nyelvet kapjanak. A C++-szal ellentétben a Java erõs kézzel kényszeríti ki az objektum-orientáltságot. Nem-OO programot írni Java-ban olyan nehéz, mint „spagettikódot” Pascalban.
Elõnyök: a binárisok más platformokra átvihetõek. Az elkészült alkalmazásokat weboldalakba ágyazva lehet futtatni. A bennfoglalt osztálykönyvtár erõsen szabványosított és rendkívül kiterjedt. Az automatikus memóriafoglalásnak és szemétgyûjtésnek köszönhetõen majdhogynem elfelejthetjük a memória-elszivárgást. Példák millióit találhatjuk az Interneten.
Hátrányok: virtuális gépet használ a hordozható bytecode futtatásához, így az elkészült programok nagyobbak és lassabban futnak, mint egy valódi fordított nyelv esetén. (Bár vannak eszközök, pl. a JIT [just in time, csak futásidõben] fordítók, amik a sebességet növelni tudják.) Olyan korai funkciók, mint az Abstact Windowing Toolkit, nem voltak igazán jól átgondolva, és mivel hivatalosan elhagyták, használhatóságuk a kétes lefelé kompatibilitáson múlik. Nagyon magas szintû, ezért minden alacsonyszintû extrát el lehet felejteni. A Sun nagyon lassan ad hozzá új elemeket a nyelvhez.
Hordozhatóság: mind közül a legjobb, de még nem az igazi. A kód maga hordozható, de a felhasználói felület (UI) dolgai és az újabb funkciók nem minden platformon érhetõk el.
Java-ban írt játékok: sok kis applet a weboldalakon, de csak kevés üzleti próbálkozás. Sok játék használja a Java-t belsõ szkriptnyelvként.
Források: a Sun hivatalos Java weboldalán majdnem minden elérhetõ. Jó Java lapja van még az IBM-nek is. A JavaLobby-n mindig a legfrissebb híreket olvashatod.

Egyéb eszközök (game-makerek)
A fenti nyelveken íródott majdnem minden „hivatalos” játék. Egy kivétel van, de az akkora, hogy muszáj róla említést tenni.
Myst. Igen, a világ egyik legsikeresebb játékát nem ezeken a nyelveken írták. Persze erre azt lehet mondani, hogy a Myst 99%-a 3D modellezõkben készült, ám az alatta lévõ program HyperCard-ban.
A legtöbb játékkészítõ eszköz egy kicsit olyan, mint a Visual Basic, csak sokkal magasabb szinten dolgoznak. Ezek valamiféle diagrammot használnak a vezérlésátadás modellezésére, és sok tartalmaz beépített nyelveket, de ezek nem olyan sokoldalúak és robosztusak, mint a fentiek.
Elõnyök: gyors fejlesztés, ha a tervezett játék megfelel az eszköz „szabályainak”, valószínûleg hamarabb játszhatsz az elkészült mûve, mint bármely más nyelv esetén. Sok esetben az egész programot „megírhatod” anélkül, hogy egy sor kódot is kellene gépelned.
Hátrányok: a választott eszköz nagyon megköti a kezed. Lehet, hogy elsõre úgy tûnik, hogy ezekkel bármit meg lehet tenni, de vannak dolgok, amikre ezek a programok egyszerûen nem képesek. Gyakran ez eredményül kapott program ijesztõen nagy méretû.
Hordozhatóság: Ez is azon múlik, hogy az adott eszköz gyártója mit nyújt. Vannak olyanok, mint pl. a Director, amik több platformon futtathatóak és játszhatóak, olyanok, amiket csak egy rendszeren lehet futtatni, de többön is játszani, és végül olyanok, amiknek minden funkciója egy platformhoz van kötve.
Játékok, amik ezekkel készültek: Myst, és még néhány kísérletezõ kedvû cég alkotásai. A Shockwave játékok a weben.
Források: Director, HyperCard, SuperCard, IconAuthor, Authorware [DarkBasic, GameMaker – a ford.].

Konklúzió
Lehet, hogy azt vártad, hogy ez a cikk egyértelmû választ ad a „melyiket használjam” dilemmára. Sajnos, nincs olyan megoldás, ami minden területen megfelelõ lenne. C-ben kicsi és gyors programokat lehet írni, de nem támogatja jól az OOP-t. A C++ erõs ezen a téren, de ijesztõen bonyolult. A Visual Basic-et és a Delphit könnyû megtanulni, de nem hordozhatóak. A Java-ban rengeteg ügyes lehetõség van, de lassú. A game-makerekkel gyorsan lehet fejleszteni, de felhasználási területük korlátozott. A legjobb, amit tehetsz, hogy eldöntöd, hogy milyen játékot akarsz írni, és kiválasztod azt a nyelvet, amelyik a kívánt típust leginkább támogatja. Még jó, hogy a 30 napos próbaverzió gyakorlata egyre jobban terjed :-)

A szerzõ: John Hattan a „The Code Zone”, a legnagyobb wataugai (Texas, USA) szoftvergyártó cég tulajdonosa. Ha megjegyzésed van a cikkel kapcsolatban: [email]johnh@gamedev.net[/email]

Értékelés: 0

Új hozzászólás
Nincs megjegyzés