Évek óta érlelem magamban a gondolatot, hogy készíteni kellene valamilyen játékot. Sokszor és soknak nekiveselkedtem már, de végül egyszer sem jutottam el odáig, hogy teljesen be is fejezzek valamelyiket.
Ötletekből sosem volt hiány. Inkább időből, kitartásból és megfelelő tervezésből. A kezdeti lelkesedés jól átgondolt dokumentáció, konkrét célok és mérföldkövek nélkül általában hamar alábbhagyott.
A mesterséges intelligencia megjelenésével azonban újra reális lehetőségnek kezdett tűnni, hogy végigvigyek egy nagyobb saját projektet. Az AI segítségével részletesebben kidolgozhatom az ötleteket, végiggondolhatom a játék rendszereit, megvitathatom a különböző megoldások előnyeit és hátrányait, miközben az AI-alapú kódolóeszközök a megvalósításban is rengeteget segítenek.
A képgenerálók miatt pedig úgy tűnt, hogy még a minimálisan szükséges UI-elemek és grafikai assetek elkészítése sem jelenthet áthidalhatatlan akadályt.
Legalábbis kezdetben így gondoltam.
Vissza az autós neveldékhez
Nem olyan régen elkezdtem dolgozni az egyik régóta dédelgetett játékötletem megvalósításán.
Eredetileg egy teljesen böngészőből játszható, webes technológiákra – PHP-ra, Vue.js-re, MySQL-re és Tailwind CSS-re – épülő, alapvetően szöveges autós játékot képzeltem el.
Az ötlethez a régi autós neveldék, például a Trabinevelde, a Polskinevelde, a Ladanevelde és társaik adták az inspirációt.
Régebben csodálva néztem ezeket az oldalakat. Programozóként azonban már nem tűnnek akkora mágiának, mint annak idején, és az is világosan látszik, hogy a mechanikáik jelentős része a mai játékosok számára nehezen lenne értelmezhető vagy élvezhető.
Gyakran csak napi egy-két érdemi tevékenységet lehetett elvégezni. A versenyek lényegében egyetlen gombnyomás után lefutó szimulációk voltak, számos művelet eredményére pedig valós időben kellett várni. Elindítottunk például egy munkát, majd órákkal később visszatérhettünk megnézni, hogy véget ért-e.
Ezek a rendszerek egykor működtek, de én nem csupán egy modernebb és szebb felületet akartam ráhúzni egy régi vázra.
Leginkább az zavart, hogy maga a versenyzés egyetlen gombnyomásból állt. Megnyomtuk az indítás gombot, a háttérben lefutott néhány számítás, majd megkaptuk az eredményt.
Elkezdtem azon gondolkodni, hogyan lehetne ezt a fájdalompontot megszüntetni. Mivel lehetne feldobni a versenyeket egy webes, alapvetően szöveges játékban úgy, hogy ne kelljen valódi autóvezetést vagy összetett fizikát szimulálni?
Képességekből kártyák
Az első elképzelés egy aszinkron PvP-re épülő versenyrendszer volt, amelyben a játékos különböző képességeket használhat az ellenfele ellen.
Ebből hamar kialakult egy kártyás rendszer.
A versenypályákat különálló szakaszokra osztottam. A játékos minden szakasznál választ egyet a kezében lévő lapok közül, ez jelenti az adott akcióját. Ezután az ellenfél is szimulál egy kártyakijátszást, majd a rendszer kiszámítja, hogy az adott pályarészen melyik versenyző teljesített jobban.
Egy kanyargós szakaszon például az szerez előnyt, aki nagyobb kezelhetőségértékű lapot játszik ki. Egy hosszú egyenesben inkább a sebesség számít, míg más helyzetekben a gyorsulás vagy a fékezés lehet fontos.
Ezzel megszületett a Rozsda és Dicsőség versenymotorjának alapja.
A játékos már nem csak megnyomott egy gombot, majd várta az eredményt. Minden szakasznál döntést kellett hoznia, közben pedig figyelembe vehette az autó tulajdonságait, a pálya jellegét és a rendelkezésére álló lapokat.
Ezután természetesen rögtön elkezdtem tovább bonyolítani az egészet.
Megjelent az időjárás mint módosító tényező. Esőben például nehezebben irányítható az autó, így felértékelődnek a kezelhetőséget javító lapok és alkatrészek.
Bekerült a motorhőfok is. A kártyák kijátszása növeli a motor terhelését, ezért nem lehet folyamatosan a legerősebb lapokat használni. A játékosnak a hűtésre is figyelnie kell, különben egy túl agresszív versenyzési stratégia végén könnyen búcsút inthet a motornak.
Elkészítettem a kártyázás első prototípusát, és meglepően hamar azt éreztem, hogy az alapmechanika valóban működhet.
A prototípustól a tervezési dokumentumig
A működő versenyprototípus után következhetett az ötletek részletesebb kidolgozása és a game design document létrehozása.
A dokumentumban nemcsak az új elképzeléseket gyűjtöttem össze, hanem a megvalósított fejlesztéseket is nyomon követtem. Ez sokat segített abban, hogy a projekt ne pusztán egymásra dobált ötletekből álljon, hanem legalább valamennyire követhető irányba haladjon.
A webes keretrendszerek nagyon jól aládolgoztak az AI-alapú fejlesztésnek. A Vue komponensalapú működése, a Laravel rendezett szerkezete és a már jól ismert webes megoldások miatt gyorsan lehetett új funkciókat létrehozni.
Ehhez persze az is kellett, hogy pontos követelményeket és szabályokat adjak az AI-nak, majd következetesen számon is kérjem ezek betartását. Minél részletesebben volt megtervezve egy rendszer, annál jobb eredményt lehetett elérni a megvalósítás során.
Nagyon hamar megszülettek az első nagyobb modulok.
Elkészült a garázs, az alkatrészrendszer, a szerelőműhely, a kocsma, a benzinkút és számtalan egyéb funkció, illetve alrendszer. Egy idő után már külön lehetett kezelni többek között a motort, a váltót, a futóművet, a féket, a gumikat, a kipufogót és a karosszéria különböző elemeit.
Megjelent az alkatrészek állapota, a javítás, a ki- és beszerelés, valamint a saját kezű barkácsolás kockázata is. A játékos eldöntheti, hogy fizet egy rendes szerelőnek, vagy megpróbálja olcsóbban, a saját garázsában megoldani a problémát – vállalva annak esélyét, hogy végül többet árt, mint használ.
Később bekerültek a mókolások és kókányolások tervei is: különféle alapanyagokból készíthető, kockázatos módosítások, amelyek új tulajdonságokkal ruházzák fel az autót vagy annak alkatrészeit.
Egy játékban nincs igazán kis rendszer
Ezekre a funkciókra külön-külön könnyű azt mondani, hogy csak apróságok. A gyakorlatban azonban szinte mindegyik komoly előkészítést, tervezést és több körös finomítást igényelt.
Jó példa erre a kocsmában található nyerőgép vagy a benzinkúton vásárolható kaparós sorsjegy.
Elsőre egyik sem tűnik különösen összetettnek. A játékos fizet, majd vagy nyer, vagy nem.
Rögtön felmerül azonban egy sor kérdés.
Mekkora legyen a nyerési esély? Mennyit érjen a jutalom? Milyen gyakran lehessen játszani? Mikor válik a rendszer unalmassá, vagy éppen kötelező pénztermelő feladattá? Hogyan akadályozzuk meg, hogy a játékos végtelen mennyiségű pénzt szerezzen vele? Legyen napi limit? Kell hozzá animáció? Mennyire legyen átlátható az esélyek működése?
Egy látszólag jelentéktelen mellékfunkció is hatással lehet a játék teljes gazdaságára.
Sok iteráción és finomításon keresztül lehetett csak elérni egy körülbelül jónak érződő eredményt. A fejlesztés egyik legfontosabb tanulsága számomra az lett, hogy egy játékban szinte nincs valóban kis rendszer.
Minden mindennel összefügg.
Kell egy történet
Idővel az is felmerült, hogy a kártyás versenyzést nagyon hamar meg kellene mutatni a játékosnak. Ez a játék legfontosabb és egyben legszokatlanabb mechanikája, így nem lenne szerencsés, ha az első órában csak menük között kellene kattintgatni, mielőtt végre kipróbálhatná.
A megoldás hamar megszületett: kell egy bevezető futam.
Ha viszont van bevezető futam, akkor valamilyen indok is kell arra, hogy a játékos miért vesz részt rajta. Ha már van indok, szükség van néhány szereplőre. Ha pedig vannak szereplők, akkor érdemes valamiféle történetet és világot is építeni köréjük.
Így kezdett kialakulni a Rozsda és Dicsőség története.
A főszereplő az apjától örökölt autóval indul, amelyet egy utcai társaság provokációja miatt túlhajt és tönkretesz. Nemcsak az autót kell helyreállítania, hanem a bátyja elveszített bizalmát is vissza kell szereznie. Ebben segít neki Niki, becenevén Kisróka, aki kölcsönautót biztosít az első futamokhoz.
Közben feltűnnek a környék kisebb-nagyobb figurái: sufniszerelők, nepperek, illegális versenyzők, helyi legendák és olyan emberek, akik valószínűleg már azelőtt megsértették a műszaki előírásokat, hogy azok egyáltalán megszülettek volna.
Nem egy realisztikus versenyszimulátort szeretnék készíteni. Inkább egy kissé eltúlzott, humoros, de remélhetőleg szerethető világot, amelyben az autók, a barkácsolás és a kelet-európai autós kultúra keveredik egy könnyedebb történettel.
Az eredeti koncepció átalakulása
A történet megjelenése közben az eredeti játékkoncepció is fokozatosan átalakult.
Kezdetben az aszinkron PvP lett volna a játék fő fókusza. A játékosok egymás korábban rögzített teljesítménye, egyfajta „szelleme” ellen versenyeztek volna, így nem lett volna szükség arra, hogy egyszerre legyenek jelen.
A kártyás versenyrendszer jó kompromisszumnak tűnt. Nem igényelt valós idejű multiplayer-infrastruktúrát, bonyolult fizikát vagy részletes autómodellezést, mégis jóval interaktívabb volt, mint az egyetlen gombnyomással lefutó versenyek.
Ahogy azonban egyre több karakter, helyszín és történeti esemény született, az aszinkron PvP fokozatosan háttérbe szorult.
A Rozsda és Dicsőség egyre inkább egy történetközpontú, egyjátékos autós menedzser- és kártyajátékká vált.
Ez nem véletlenül történt, de ennek okairól majd egy másik bejegyzésben írok részletesebben.
Egy játék helyett öt-hat játéknyi rendszer
Ahogy haladt a fejlesztés, egyre világosabbá vált, hogy a Rozsda és Dicsőség már régen nem egy egyszerű autós kártyajáték.
Van benne pakliépítés, autómenedzsment, alkatrészrendszer, gazdaság, barkácsolás, karakterfejlődés, többféle versenytípus, történet és egy részben szabadon bejárható világ terve.
A sprint mellé bekerült a körverseny, az elimináció, a drift, a gyorsulási verseny és a szektor-dominancia is. Elkészült az első boss-verseny, a kártyák rendszere és számos olyan gazdasági vagy háttérrendszer, amelynek létezését a játékos talán észre sem veszi majd – csak azt, ha rosszul működik.
Néha úgy érzem, hogy ebben az egy projektben öt-hat kisebb játék rendszerei próbálnak egyszerre megszületni.
Ez természetesen veszélyes is.
Nagyon könnyű újabb ötleteket hozzáadni, miközben a játék legfontosabb részei még nincsenek teljesen készen. Az új mechanikák tervezése ráadásul sokkal szórakoztatóbb, mint a meglévők véglegesítése, kiegyensúlyozása és alapos tesztelése.
A webes prototípus azonban elérte a célját. Bebizonyította, hogy a kártyás versenyrendszer működhet, és hogy én is szívesen foglalkozom ezzel a világgal hosszabb távon.
Közben viszont a webes megvalósítás korlátait is egyre jobban megmutatta.
Túlnőtt a böngészőn
Egy idő után egyre inkább úgy éreztem, hogy ez a játék túlnőtt az eredeti webes kereteken.
Hiába készült el több versenytípus, az első boss-harc, a garázs, az alkatrészrendszer és számos egyéb funkció, a felület még mindig inkább egy játékos elemekkel feldíszített webalkalmazásnak érződött, mint valódi játéknak.
Menük, panelek, gombok, listák és modális ablakok követték egymást. Funkcionálisan működött, de hiányzott belőle a mozgás, a ritmus, a hang, az animáció és az a fajta vizuális visszajelzés, amitől egy rendszer nemcsak használhatóvá, hanem élvezhetővé is válik.
Ezzel párhuzamosan a történetközpontú egyjátékos irány egyre hangsúlyosabbá vált. Ehhez már karakterekre, dialógusokra, átmenetekre, látványosabb versenyekre és egységesebb audiovizuális megjelenésre volt szükség.
Úgy éreztem, hogy ehhez már valódi játékmotor kell.
Így nemrég lezártam a webes projekt fejlesztését, és belevágtam a teljes játék Godotba történő átültetésébe.
Ekkor még azt gondoltam, hogy a meglévő rendszereket viszonylag egyszerűen újraépítem, készítek néhány grafikai elemet, és hamarosan ott folytathatom, ahol a webes változatban abbahagytam.
Természetesen nem egészen így történt.
A Godotra váltásról, az új fejlesztési folyamatról, a kezelőfelület okozta meglepetésekről és a képgenerálással kapcsolatos reality checkről a Rozsda és Dicsőség devblog következő részében írok.
Pár kép a webes verzióról:
És a Godot verzió főmenüje:
