Nagyon sok szónoki beszédett hallhattunk már arról, hogy Pascal nyelven nem lehet játékot készíteni, nem arra való. Az elmúlt 16 év alatt nekem ezt az állítást nem sikerült belátnom sőt... Nem egy játék született magyar műhelyekben, amelyek igen is Pascal nyelven íródtak, és megállták helyüket a játékpiacon, és nem csak a hazain, de világviszonylatban is ismerté váltak.
Már gyerek korom óta foglalkoztat a kérdés, hogyan lehet játékprogramot készíteni, olyat amely másokat is szórakoztat?
1995 táján találkoztam először ezzel a fogalommal "Engine". Manapság folyamatosan hallani a legkülönbözőbb Engine-ekről, amelyek a legmodernebb technikákat alkalmazzák, de a szó jelentése én úgy gondolom sokak számára ugyan olyan homályos, mint nekem volt 95'-ben. Ez természetes azt hiszem azok részéről akik játszák a játékot, viszont annál problémásabb, ha valaki olyan nem jön tisztába a fogalom jelentésével aki készíti azt. Bár én nem tudom van-e valami elfogadott, teljeskörű leírása annak mit nevezünk Engine-nek (innentől kezdve magyarul - motornak), mert mindenhol csak homályos utalásokat találni róla.
Lehet, hogy nem is lehet konkrétan, néhány mondatban megfogni a dolgot és leírni? Biztos hogy nem.
A laikus olvasóim kedvéért leszögezném: egyik motor sem program. Tehát magát a motort nem lehet elindítani, mint egy hagyományos akármilyen alkalmazást, mert nem az! De akkor mi az?
Ahhoz, hogy megértsük mit jelent a szoftver motor fogalma (esetünkben játékmotorra gondolok), azt kell megvizsgálnunk milyen részekből épül fel a legegyszerűbb játék is. Bármilyen típusról is legyen szó, alapvetően 2 érzékünkre remélhetőleg hat. A hallás és látás. Továbbá valamilyen módon a játéknak is, mint minden más programnak vezérelhetőnek kell lennie a játékos által. Ez azonnal három olyan dolog, amely nélkül nehezen volna elképzelhető bármilyen számítógépes játék. Tehát a legprimitívebb motornak is feladata ezt a három eszközt a felhasználó számára biztosítani.
Vannak olyan API gyűjtemények, amelyek ezeket a területeket a leghatékonyabban igyekszene kiszolgálni. Megjelenítés terén a legnépszerűbb manapság a Direct X és OpenGl grafikus könyvtárak, függvény gyűjtemények. Ezek működésébe nem mélyednék most bele. A lényeg, hogy az általunk kívánt grafikát tetszőleges módon megjelenítetthetjük a segítségükkel. Felmerülhet a kérdés, hogy ezek akkor motorok-e? A válasz a fentiek alapján egyértelműen nem. (A Direct X egésze természetesen már közel áll a fent definiált alapmotor fogalmához, hiszen függvénykészlete minden lehetőséget biztosít a számunkra, de most tekintsünk el ettől).
Példának véve az OpenGL-t (Open Graphic Library - nyíltforrású grafikai függvénygyűjtemény) lehetőségünk van 3D primitívek és 2D grafika megjelenítésére, de csak ezek felhasználásával aligha képzelhető el egy játék. Tehát szükségünk van még hang és periféria kezelésre. Az OpenGL-hez csatlakozva, hang hatások terén vegyük hozzá API készletünkhöz az OpenAL-t (Open Audio Library - nyíltforrású audio függvénygyűjtemény). Periféria kezelésre használjuk a Windows platform API-ját. Most már mind három terület kezelésére lehetőségünk nyílik. Ezek az API-k együttese már vajon motor? A válasz ismét nem. Természetesen elkezdhetünk egy játékszoftvert írni ezek felhasználásával, de azonnal beleütközünk egy sor hiányosságba. Tételezzük fel, hogy valamilyen ablakszerű grafika megjelenítésére van szükségünk, például az opciók, vagy főmenü számára. Az OpenGl, amely a megjelenítésért felel, nem képes ilyen jellegű dolgot létrehozni, pláne nem funkcionálisan. Tehát írnunk kell egy ablakkezelőt, vagy bővebben véve GUI-t (Graphic User Interface - grafikus felhasználói felület). Máris túlléptünk a fent csokorba fogott API-k lehetőségein és belefolytunk egy motor alapjainak elkészítésébe. De számtalan más problémát is meg kell oldanunk. Az OpenGl (ha már ezt vettem példának) nem rendelkezik un. kamerával, saját magunknak kell létrehoznunk azt az osztályt, amelyik ezért lesz felelős. Nincs lehetőségünk különböző 3D modelleket tároló fájltípusok felhasználására, ugyan így képek, textúrák közvetlen megjelenítésére sem alkalmas és még sorolhatnám a ránk váró feladatok és teszem hozzá, még csak a megjelenítést hoztam szóba.
De a lényeget leszűrve fordítsuk meg a fentieket. Egy motornak lehetőséget kell biztosítani arra, hogy a felhasználó közvetlenül tudja elérni a játék során használni kívánt erőforrásokat, periférikus eszközöket. (Természetesen ha például a motor nincs felkészítve hálózatkezelésre, nem tudunk hálózaton keresztül játszható játékot írni. De ez már egy olyan funkciója az adott motornak, amely nem nélkülözhetetlen a játék készítésben).
És akkor most már - a hosszab bevezető után - rátérnék a cím megválaszolására.
A DSX egy Delphi és Lazarus - FreePascal fejlesztőkörnyezetre szánt, játékszoftver motor, melyet igyekszem úgy felépíteni, hogy bárki által könnyen átlátható, és elsajátítható legyen a használata. A motor átültetését Lazarus-ra a blog megnyitásával egyidőben kezdtem meg.
A fent leírtakban természetesen nem véletlenül vettem alapul a nyílt forrású API-kat, hiszen a motor megjelenítéséért az OpenGL, hangjában az OpenAL és természetesen a perifériák kezelésében a Windows függvénykészletét hívtam segítségül. Fizikai API-nak a legelső nekifutástól fogva a Newton Game Dynamics API-ját használtam és használom, de amint időmből és energiámból telik, vagy saját fizikát kap a motor vagy a Physx méltán népszerű SDK-ját írom át Pascal-ra (jó sok idő és munka, ha egyáltalán lehetséges), de ez még mind a jövő titka, egyelőre marad a Newton.
Aki fejlesztett már motort az tudja, hogy elsőre aligha sikerül egy jól használható példányt összehozni, sőt... A sokadik átirata, a jelenleg 0.8.2 verziószámú állapot. Azért 0.8 mert visszamenőleg a 8. újraírástól számolom a verziót :) 1.0-ás formáját akkor éri majd el a dolog, ha végre eljutok addig, hogy minden tervezett rész jól müködik, mondhatni össze áll a teljes kép. Remélhetőleg belefér a maradék 2 alverzióba.
Hogy még néhány jellemzőről nagyvonalakban írjak.
Ami legújabb eredményem, az egy könnyen használható GUI, tetszés és izlés szerint átalakítható kinézettel (Skin-nel). (Erről is, mint mindenről bővebben is írok majd).
Az egyik legfontosabb szempont volt amikor elkezdtem a motor megírását, hogy valamilyen eszközkörnyezet használatához tartsam magam. Így a legelső támogatott 3D modell fájl formátum a 3D Studio Max ASE formátuma lett. (Azért nem a 3DS mert könnyebb volt a legelső verziókban nyomon követnem a feldolgozandó információkat, mint egy zártabb formátum esetén). 3D Animációs formátumnak az MD5 formátumot válaszottam, szintén azért mert MAX-ból könnyen elérhető és ingyenes. (Apropó. Természetesen ez is egy lényeges szempont a fejlesztés során, hogy ingyenesen felhasználható alapokra építsek). Textúra kezelés terén a BMP,JPG,TGA, és DDS formátumok elérhetőek. PNG formátumra még egy kicsit várni kell :). Számomra a legelőnyösebb a DDS használata, így arra is van kiélezve a dolog.
Hang formátumok megszólaltatásában a WAV,MP3 és OGG-t támogat majd. (Azért írom, hogy "majd", mert az egyes osztályokat újra kell írnom, hogy a motor ezen része ismét használható legyen, Lazarus környezetben is).
A motort használatát egy fejlesztő eszköz is segíti, amely Studio X névre hallgat és még nagyon az alapoknál tartok (verzió 0.2). (Tekintve, hogy az eddig készenlévő programot Lazarusra írom át. Terveim szerint ez a program leginkább egy fejlesztőkörnyezethez lesz hasonlatos, amely lehetővé teszi egy teljes játék felépítését a helyszínektől az eseményvezérlésig.
És végül néhány pontban összefoglalva az ami már készvan (volt) a DSX 0.8.2-ben:
- Helyszín és Kamerakezelés (menthető Scene)
- Modell kezelés (ASE, 3DS és saját SXM formátumok)
- Textúra és Matériál kezelés (Textúra formátumok: DDS,BMP,JPG,TGA)
- 3D Animációk kezelése (Transform Mesh, Vertex és Csontanimációk)
- Fizikai motor (Newton Game Dynamics használata, integrált eszközként)
- Részecske rendszerek (Tűz és robbanás effekt, egyelőre...)
- 2D Grafika
- GUI (Ablakozó rendszer és komponensek)
- 3D Hang kezelés (Wav, Mp3, Ogg)
- Periféria kezelés (Billentyű és Egér jelenleg)
- Hálózat kezelés
Hát egyelőre aszem ennyi. Természetesen folyamatosan fejlesztem és még közel sem vagyok készen, de igyekszem :).
