Ez is egy régi játék (1997) számomra majdhogynem az akció TPS műfaj etalonja többek között pörgő játékmenete, változatos helyszínei, könnyű irányíthatósága miatt. Első találkozás után rajongója lettem így érthető volt, hogy programozói szemszögből is szerettem volna a játékot megismerni vagyis leginkább a kontentjét. Ezzel csak az volt a gond, hogy sehol nem találtam leírást/segítséget (állítólag az eredeti forráskód és kontent is elveszett) ennek kinyerésére ezért egyedül vágtam bele az adatbányászatba.
Megpróbáltam renderelési adatokból kiindulni vagyis elkapni a GPU-nak elküldött információkat és abból visszaállítani a jelenetet. Ezt legegyszerűbben a játék által a 3D API-nak kiadott hívások vizsgálatával lehet elérni. Biztató jel volt, hogy a játék már támogatott 3D API-kat, amelyek közül a két legismertebb jött most szóba: D3D a Microsoft-tól ill. Glide a 3dfx-től. Az előbbinek sajnos a 3.0 változatát használta a játék így nem tudtam felhasználni erre a célra viszont a Glide ígéretesnek tűnt, mert létezik nyílt forráskódú Glide - OpenGL wrapper. Így először megnéztem GLIntercept-tel hogy mi is történik rendereléskor aztán beleástam magam az OpenGLide forráskódjába hogy lementsem a kívánt adatokat. Ekkor jött az első meglepetés és az első találkozásom a Glide API-val.
Kis kitérő: a Glide API
Sokban hasonlít a klasszikus OpenGL-re viszont egyik szembetűnő különbség a mátrixok kezelésének hiánya (legalábbis én nem találtam nyomát). Ekkor jutott eszembe az a fogalom, hogy transform & lighting (T&L). Ez valójában három olyan dolgot takar, amik szükségesek a (kényelmes) 3D rendereléshez.
- transzformálás, amikor a vertexekkel mindenféle műveleteket végzük, amikből a legfontosabb a (3D -> 2D) vetítés.
- vágás vagyis a képből kilógó háromszögek kilógó részeinek eltávolítása és az így képződő poligonokból új háromszögek generálása.
- árnyalás
Ma már természetesnek vesszük, hogy ezeket a GPU végzi el (sőt shadereket használunk), de ekkoriban ezeket még a CPU-n kellett számolni (a hardveres támogatásig a D3D 7.0-ig kellett várni).
Ennek az a következménye az adatbányászat szempontjából, hogy a háromszögeket már levetítve (2D képernyőtérben) és megvágva kapom meg vagyis nem tudom felhasználni a céljaimra. Azonban észrevettem, hogy az elküldött háromszögek z-komponenseiben van adat (annak ellenére, hogy nem használ z-buffert) vagyis érdekességként le lehet menteni belőle 3D tartalmat:
A képen látható, hogy pl. a cull face-t is a CPU végzi.
Második menet
Megpróbáltam a kirenderelt adatban keresni egyedi és felismerhető adatokat, mint pl. textúra koordináta vagy színek és azokat megkeresni a bináris kontentben. Ez lehet, hogy működött volna, de mint később kiderült rossz file-ban keresgéltem.
Harmadik menet
Hook API. Megpróbáltam a file betöltést figyelni, hogy azokból megtudjam milyen adatot mire használ fel. Sajnos kernel módú függvényeket használ file kezelésre így ez az ötlet kiesett.
Negyedik menet
Feltételeztem, hogy a vertexek float adatként vannak tárolva így belenézve a bináris file-okba szemmel kerestem ilyen adatra emlékeztető mintákat. Miután megvolt a feltételezett file brute force elkezdtem "értelmes" float hármasokat kinyerni abból majd az adatokat megjelenítettem és nézegettem, hogy látok-e ismerős térbeli formákat. És szerencsém volt, mert láttam - felfedezni véltem egy folyosót, aminek a vélt keresztmetszete árulkodó volt:
Azt feljegyeztem, hogy ezekhez a pontokhoz tartozó adat a fileban hol található.
Ötödik menet
Megpróbáltam az adott file-ban headert felismerni majd miután ez megvolt viszonylag hamar rátaláltam a mesh (topológia, geometria stb) adatokra. Ehhez fel kellett ismerni hogy pontosan hányféle és mekkora méretű struktúrákat használ és azokban milyen adat található. Ezeket próbálgatásokkal derítettem ki ezenkívül az is segített, hogy a beolvasásnál ahhoz a file offszethez értem el, ahol az előző próbálkozásomnál a ponthalmazt találtam. Így végül sikerült kiolvasnom ezt:
Ezek után a többi mesh-t is beolvastam ezenkívül egy másik fileban is találtam mesh adatokat. Végül az összes betöltött mesh kiadta az egész pályát:
Meglepő volt, hogy végül olyan file-okban is találtam mesh adatot, amelyek neve és látszólagos tartalma teljesen mást sugallt, mint pl. zene ill. képek.
Itt pedig egy videó a betöltött első pályáról:
A játék technikai szemszögből
- Térfelosztás nem lehet túl bonyolult talán konvex térrészek halmaza. A pálya kétféle típusú elemből áll: aréna és folyosó. Occlusion cull-ra valószínűleg PVS-t használ, amit talán kézzel is szabályoztak, mert sokszor vannak egymást átfedő pályarészek, de in-game az átfedés nem látható. Ehhez hasonló "in-game nem látható átfedésre" a korai Tomb Raider sorozatban is láttunk példát. Két elem között lévő ajtó képes a kamera túloldalán lévő elem renderelését tiltani/engedélyezni. Ilyen működést pedig a Q3-ban is láthatunk.
- Mivel ebben az időben az átlagos rendszermemória kevés volt nem fért be az egész pálya egyszerre a memóriába. Ezt úgy hidalták át, hogy mai megoldáshoz hasonlóan streamelték az adatokat. Amikor a játékos folyosóban haladt előre akkor párhuzamos töltötte be a következő pályarészt. Valószínűleg ezért is vannak az folyosók külön file-ban.
- A Doom és Super Mario hibridjeként is szokták emlegetni. A pályadesign nagyon jól kihasználja a vertikális kiterjedést is és sokszor épít a pontosan időzített ugrásokra. De nem annyira erősen, mint a Tomb Raider ahol gyakorlatilag az ugrási távolságok ki voltak centizve. Az idő többi részében pedig lőni (és néha célozni is) kell.
- Force Feedback támogatással bír Windows alatt.
- Többféle játékmódot is beleraktak a játékba. A legnevezetesebb a sniper mód (tudomásom szerint ebben a játékban volt először ilyen). Ezenkívül helyett kapott még repülés, ejtőernyőzés, szörfdeszkázás, csúszdázás, bombázás és néhány logikai feladat is. De alapvetően az ugráláson és a lövöldözésen van a hangsúly. És volt benne headshot is.
- Rengeteg agyament humort zsúfoltak a játékba.
- Egyik kedvenc zenei betétem erősen hasonlít az Emlékmás c. film egyik zenéjére. Véletlen vagy sem a zenei betét neve RECALLQ.wav. De van James Bond filmekre emlékeztető zenei betét is, mint pl. a BOND:wav.
- Nagyon tetszett az a megoldás, hogy ha már a shift billentyű jelenti a futást, akkor a caps lock bekapcsolt állapota mellett a futás lesz az alapértelmezett haladási forma.
- A főszereplő jobbára egy (nagy felbontású tehát jó minőségű) 2D sprite. A többi modell javarészt 3D.
- Csak állóhelyzetben lehetett fel- és lefelé nézelődni. Talán a renderelő nem volt erre felkészítve sebesség növelése miatt? Pl a hátteret (a felbontása 1804x360!) 2D képként másolja rá a képernyőre így perspektív torzulást nehéz lenne eszközölni rajta. De a főszereplő 2D sprite mivolta miatt is lehet hiszen akkor nagyon sok sprite animációt kellett volna tárolni.
- A kamera mozgása azonban visz kis mértékű billenést ill. csavarást a nézetbe - nagyon tetszik, még jobban kihangsúlyozza a főhős mozgását: forgásnál kicsit elforog az előre tengely körül (csavarás) míg futáskor a felfelé vektor alkalmazkodik annak a felületnek a normáljához amin a főhős fut (billenés). Ejtőernyőzéskor is tapasztalható billenés.
- A saját lövedékünket TPS nézetben nem látjuk, az azonnal becsapódik míg az ellenfelek lövedéke sokkal lassabban mozog és látható.
- A mi lövedékük becsapódása tetrahedron záport okozott, amik láthatóan fizikailag ütköztek a statikus pályaelemekkel.
- Az még nagyon tetszik, hogy a 150% élet valójában egy szereplő, ami elfut előled.
- Sokféle ellenfél van - van köztük pl. kamikáze is (ilyesmire a Serious Sam-ből emlékszem még), de van ami viccelődik velünk a hátsó felét mutogatva vagy alszik és közben horkol.
- Játékmentés elég sok fejfájást okoz ugyanis a játék bizonyos verzióiban csak a pályák végén lehet menteni.
- A renderelés olyan extrákat tud, mint pl. egyszerűsített tükröződés ill. átlátszóság.
- A lightmapet egybeégették a color textúrával.
- Fizikai szimulációnak nincs nyoma.
- A játék ajánlott gépigénye legalább Pentium 90 MHz.
