Tech, szoftvertervezés és programozás

Szoftverfejlesztés, Shaderprogramozás, DirectX

  • A betűméret növelése
  • Alapértelmezett betűméret
  • A betűméret csökkentése
Címlap Játékfejlesztés Saját számítógépes játék írása (és buktatói)

Saját számítógépes játék írása (és buktatói)

E-mail Nyomtatás PDF
Olvasóink értékelése: / 8
ElégtelenKitűnő 
Egy saját játék elkészítésének a gondolata évek óta a tudattalattimban leledzik, és az utóbbi időben egyre sűrűbben tör elő onnan. Amióta befejeztem a könyvem, nem tudom kiélni a kreativitásomat, így aztán kapóra jött ez a viszonylag régi ötlet. Első lépésként elkezdem az információgyűjtést, és csak utána kezdek gondolkodni azon, hogy konkrétan mit is szeretnék létrehozni. A harmadik szakasz a tervezés, ezt követi majd az implementálás és a grafikák elkészítése. Az információgyűjtés azért fontos, hogy felmérjem a lehetőségeket, pontosabban, hogy mire vagyok képes, illetve minek reális a megvalósíthatósága. Hiszen hozzáfoghatnék olyan játék készítéséhez, melyben több ezer karakter szerepel, és egy összetett, majdhogynem valós világot próbalok modellezni, de be kell látni: egyszemélyes project esetében ennek megvalósítása szinte lehetetlen.
Nate Miller "Building a game on your own" cikke - http://www.flipcode.com/articles/article_buildinggame.shtml - nagyon jól összefoglalja a játékkészítéssel kapcsolatos tudnivalókat, azokat a szempontokat, amelyeket érdemes szem előtt tartani, ha valaki egyszemélyes játékprojectbe kezd. A következőkben az általa felsoroltak és saját véleményem, tapasztalataim ötvözetét olvashatjátok.

Az első komolyabb program - nem feltétlenül játék - elkészítése mindenképp hasznos, mert ezáltal nagyon sokat lehet tanulni. Az ember észre sem veszi, és a munka előrehaladtával újabb és újabb ismereteket szerez. A prog-ramozó problémákba ütközik, és jó esetben megoldja őket. Ha a problémák túlhaladnak minket, akkor megvan a gond: túl nagy fába vágtuk a fejszénket! És itt jön az első jótanács:

Olyasmibe kezdj, amit képes vagy befejezni!


Ugyanis mindegy, mennyire bravúros megoldásokat, forradalmi újításokat tartalmaz a forrásod, ha soha nem fejezed be. Egy félkész program akkor is félkész, ha amúgy briliáns a kód.
Ehhez persze az kell, hogy bármennyire is jónak tűnik egy-egy ötlet, ne sajnáljuk elvetni, ha valóban azt akarjuk, hogy játékunk elkészüljön. A játékkészítők hajlamosak arra, hogy a fellegekben járjanak: ragyogó fények, színorgia, reallisztikus mozgás, a felhasználónál jóval értelmesebb mesterséges intelligencia (ez sem mindig jó, hiszen ki szereti, ha soha nem képes legyőzni a gépet?), millió ötlet, de ki fogja ezt lekódolni? Szóval legyünk szerények - különben hamar rájövünk arra, hogy egyedül nem vagyunk képesek arra, amire egy csapatnak is több évre lenne szüksége. Sajnálatos módon mennek tönkre amúgy ígéretes kezdeményezések, garázsprojectek (lásd pl. www.bark.hu ), csak azért, mert túl magasra helyezik a lécet.
A legjobb, ha olyan célokat tűzünk magunk elé, amit 6 hónapos vagy annál rövidebb határidő alatt meg tudunk valósítani. Ha nem így teszünk, nagy valószínűséggel lankadni fog lelkesedésünk, és előbb-utóbb abbahagyjuk az egészet.

A következő, fontos szempont:

Ne találjuk fel újra a spanyolviaszt!

Érthető, hogy az ember örül, ha a semmiből hoz létre valamit, de most az a lényeg, hogy belátható időn belül fel tudjunk mutatni valami eredményt. Természetesen nem arról van szó, hogy valahonnan letöltsük egy játék forrá-sát, és aztán pár spriteot kicserélve úgy állítsuk be, mintha saját fejlesztés lenne! Ez lopás, ami a mi szakmánk-ban a legnagyobb bűn. Arra céloztam, hogy nyugodtan körülnézhetünk a neten, és átvehetjük programozótársaink vívmányait anélkül, hogy újra feltalálnánk Bresenham vonalrajzoló algoritmusát, vagy komplex matematikai függvénygyűjtemények létrehozásával bíbelődnénk. Ilyesmiket nyugodtan vegyünk kölcsön, persze nem árt, ha átlátjuk működésüket, ugyanis ha nem így lenne, valószínüleg úgyis képtelenek lennénk használni. Az átvett kódot ajánlott előbb kisebb próbaprojectben tesztelni, mielőtt saját, gondosan felépített programunkba illesztenénk. Ez mindenképp bölcs döntés, ugyanis senki sem garantálja, hogy a kód valóban jól működik, és az sem biztos, hogy minden szolgáltatására szükségünk van. Megjegyzem, érdemes megvizsgálni, hogy az adott forrás valóban szabadon felhasználható illetve módosítható, továbbá illik valahol megemlíteni a szerző nevét (pl. a forrásban, köszönetnyilvánító részben, help-ben, stb.).

Ne pazaroljuk időnket saját motor készítésére!

Amikor játékprogramozásról esik szó, sokan hajlamosak 3D-, felület-generáló, stb. motorokra asszociálni. Egy kisebb project esetében értelmetlen ilyesmibe fogni, hiszen valószínűleg úgysem használnánk újra sziszifuszi munkával létrehozott motorjainkat. Sőt, ez akkor is igaz, ha valóban az újrafelhasználhatóság a cél - ehhez nem kell feltétlenül saját engine, hiszen ötletes megoldásainkat átvehetjük forrás szinten vagy függvénykönyvtárak formájában is. A motoroknak igazából csak nagyobb cégek esetében van értelme, hiszen ők több játékba is beleépítik a már elkészült és jól szuperáló ketyeréket. Természetesen senkit sem akarok lebeszélni saját motor írásáról, ha azért fogna hozzá, mert meg szeretne ismerkedni a tervezésének és kivitelezésének szakaszaival, implementációjával.

A következő csapda, amit érdemes elkerülni:

Ne pazaroljunk túl sok időt különleges grafikai megoldásokra!

Bármennyire fájó, szembe kell nézni a valósággal: különleges megoldások terén nem tudjuk felvenni a versenyt az id Software méretű cégekkel. Célunk, hogy egy jól játszható, jópofa játékot hozzunk össze, nem pedig az, hogy megfőzzük a legújabb videokártyák processzorát! Ha mégsem így lenne, akkor játék helyett kezdjünk inkább demóírásba. Összpontosítsunk inkább a játékmenetre, kezelhetőségre, és törekedjünk arra, hogy a játékosoknak kellemes perceket szerezzünk. Számtalan olyan számítógépes játék létezik, aminek csodálatos grafikája van, de egyszerűen játszhatatlan vagy lapos a játékmenet - rossz esetben mindkettő együtt.

Nyisztor Károly