2024. március 29., péntek

Gyorskeresés

Útvonal

Cikkek » Játékok rovat

Saját játékom: PR00FPS

  • (f)
  • (p)
Írta: |

Egy néhány éve írt, saját kis FPS játékomat szeretném bemutatni.

[ ÚJ TESZT ]

Bevezetés

Üdv!

Kezdjük rögtön a névválasztással. Miért PR00FPS? Nos, az én nicknevem általában proof88 vagy PR00F. És mivel FPS-játékról van szó, így lett a saját FPS-em neve: PR00F + FPS = PR00FPS!

2006-ban kezdtem el foglalkozni OpenGL-lel. Ez egy grafikus API, a grafikus driverek implementálják és ez azért jó, mert hardveresen gyorsított grafikánk lesz, olyasmi mint a Direct3D.

A neten olvasgattam és próbáltam megérteni a tutorialokat. Érdekelt mindig is a játékfejlesztés. Érettségi után OKJ-képzésre mentem és már az elején eldöntöttem, hogy én valamilyen játékot fogok írni szakdolgozatként.

Eredetileg valami egyszerű, billentyűzettel irányítható lövöldözős játékot szerettem volna írni, olyasmit, mint régen a Wolfenstein. De hamar rájöttem, hogy nem nagy kaland berakni az egérrel való nézelődést, meg akkor már olyan alap dolgok is legyenek benne, mint pl az ugrás.

Azt hiszem, 2002-ben kezdtem el foglalkozni a Counter-Strike-kal, rövid ideig 1.5-tel, később éveken keresztül az 1.6-tal. De egy idő után már elég volt belőle és a Quake 3-at toltam.
Igazából életem során folyamatosan váltották egymást a CS-s és Q3-as időszakok. Néhány hónapig előbbire, aztán néhány hónapig az utóbbira vágytam és ez így ismétlődött. Az OKJ-képzés alatt a Q3-as időszakomat éltem, ezért inkább valami ehhez hasonló játékot szerettem volna csinálni.

A játék technikai felépítése röviden

Sosem írtam még igazi grafikus motort és ez mind a mai napig igaz. Egy grafikus motornak rengeteg dolgot tudnia kell. Én inkább grafikus könyvtárnak hívom azt, amit anno a játékhoz írtam.

Ez egy dll volt, sokféle függvénnyel, pl.: textúra betöltés, modell betöltés stb. Tehát, ez a grafikus könyvtár tartalmazta azokat a dolgokat, amik a megjelenítésért felelősek. OpenGL-re épül és Delphi-ben írtam, ahogy magát a játékot is. Azért Delphi, mert akkoriban abban éreztem magam a legrutinosabbnak.

A játék tehát ezt a dll-t használja a megjelenítéshez. Ennek a felépítésnek az az előnye, hogy a játék újrafordítása nélkül módosíthatom a grafikus könyvtárat, illetve ez utóbbi újrafordítása nélkül módosíthatom a játékot, és persze más projektjeimben is felhasználhatom ezt a dll-t.

Néha megkérdezik tőlem, hogy hogyan kell elkezdeni egy engine-t, azaz motort írni, pl egy grafikus motort. Nehezen tudok rá választ adni. Én középsuli elején megismerkedtem a DarkBASIC-kel, ami egy BASIC nyelven alapuló játékfejlesztő program.
Rengeteg hasznos függvényt tartalmaz, ami egy játékhoz kell: grafikai, hanggal és zenével, hálózatkezeléssel, fájlkezeléssel és egyéb dolgokkal kapcsolatos függvények. Írtam benne egy játékot, elég láma lett, de tőlem akkor az volt a legtöbb.
Túrakocsikázás volt a címe. Akit érdekel, innen letöltheti, bár manapság nem biztos, hogy elindul.


Pillanatkép a Túrakocsikázásból

A modelleket is én csináltam bele többnyire. Tudom, hogy némely gyerek már 8 évesen C++-t tanult, de én nem az a gyerek voltam. :)

Szóval, visszatérve a motorra: tisztában voltam azzal, hogy körülbelül milyen függvényekre lenne szükségem ahhoz, hogy játékot írjak - olyan függvényekre, amiket anno DB-ben is használtam! Meg ugye a tutorialok is rávilágítottak arra, hogy milyen dolgokat érdemes kiemelni függvényekbe.
Nyilván eltelt némi idő, amíg kísérletezgettem ilyen apróbb OpenGL-es programokkal, de aztán összeállt a kép, és 2006 ősz végére már nagyjából használható volt a grafikus könyvtáram. Persze hibajavítások és extra funkciók kerültek bele a későbbi hónapok során, de a lényeg már látszott.

Delphiben van objektumorientáltság, én viszont nem használtam azt ki. Igazából az egész játék úgy nézett ki, hogy volt a főprogram, az behívott egy csomó alegységet (unit), külön unit-ja volt minden egyes ablaknak (form), az ütközés detektáló függvényeknek, a pálya kezelő függvényeknek stb.
De sehol nem volt egy deka osztály sem, csak típusdefiníciók: pl.: olyan, hogy pálya osztály, nem volt, helyette TMap rekord volt, ami tartalmazta a pályával kapcsolatos dolgokat, és minden pályával kapcsolatos függvény a map prefixet kapta, pl: mapLoadMap() töltötte be az adott pályát, mapFlush() meg kitörölte a memóriából.

Gyakorlatilag függvényekkel és rekordokkal írtam meg az egész játékot, ami hát elég érdekesen néz ki, de akkor ennyit tudtam. Azért most egy kicsit csúsztattam, mert mégiscsak voltak osztályok: maguk az ablakok, hiszen azok egyéni osztályok voltak a TForm osztályból származtatva, de hát össz-vissz ennyi. :)

A grafikus könyvtár nem tartalmaz túl sok optimalizációt a rajzolás kapcsán. Ezért mondhatni lassú a játék, persze annyira nem tűnik fel, mert kevés a poligonszám, kicsik a pályák is. Nem dönti el, hogy mit kéne kirajzolni és mit nem, mindent kirajzol: azt is ami mögötted van, és azt is, ami fal mögött van.

Többek között ezért is kicsik a pályák. Viszont így is tűrhetően futottak a benti sulis gépeken. A textúratömörítés sokat számított. Ez azt jelenti, hogy ha a hardver támogatja a tömörített textúrákat, akkor tömörítve lesznek tárolva a videomemóriában. Ez nagyon meg tudja dobni a teljesítményt az integrált kártyáknál is.

A végén rájöttem, hogy hangok is kellenek bele. Ehhez az FMOD könyvtárat használtam. Sajnos nagyon kevés időm volt már rá tavasszal, ezért éppen hogy csak bekerültek a hangok, készen kellett lennie a játéknak. Nem is vagyok vele megelégedve, néha fura is 1-2 hang, néha érezhetően balról vagy jobbról jön aminek mindkét oldalról kéne jönnie, és persze a hangok minősége is olyan amilyen.
Ehhez kapcsolódóan megjegyezném, hogy a magyar verzióban van egy-két Quake 3-as hang, akkoriban jópofának tartottam belerakni. Azóta az angol verzióban már lecseréltem hangokat, a vicc az, hogy szerintem így jobb lett. :)

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.