Az előző bejegyzést ott hagytam abba, hogy a Rozsda és Dicsőség első böngészős prototípusa néhány nap alatt meglepően sokat fejlődött. Elkészült egy kezdetleges versenyrendszer, bekerültek az autók, az alkatrészek, a fejlesztések és több olyan mechanika is, amelyek alapján már láthatóvá vált, milyen játék lehetne ebből az egészből. A prototípus teljesítette a legfontosabb feladatát: bebizonyította, hogy az alapötlet működhet.
Ezzel együtt egyre erősebben éreztem, hogy a böngészős változat hosszú távon nem feltétlenül a megfelelő alap. Nem azért, mert technikailag ne lehetett volna tovább építeni, és nem is azért, mert a webes technológiák alkalmatlanok lennének játékfejlesztésre. Sokkal inkább azért, mert a projekt minden új felülettel és rendszerrel egyre inkább egy különös webalkalmazásra kezdett hasonlítani, miközben én egy valódi játékot szerettem volna készíteni.
Volt menü, volt garázs, lehetett alkatrészeket vásárolni, és el lehetett indítani a versenyeket, de az egyes képernyők még nem álltak össze egységes világgá. A garázs inkább egy alkatrészkezelő felület volt, a bolt egy terméklista, a verseny pedig egy különálló minijáték. Minden működött, mégis azt éreztem, hogy a játékos nem egy rozsdás autókkal, kétes szerelőkkel és lepukkant helyszínekkel teli világban mozog, hanem különböző funkciókat nyitogat egymás után.
Ezért végül úgy döntöttem, hogy a böngészős prototípust nem foltozom tovább, hanem újrakezdem a projektet Godotban.
Nem egyszerű technológiacsere
Elsőre a váltás logikus és viszonylag egyszerű lépésnek tűnt. A játék működésének jelentős részét már átgondoltam, a prototípusban pedig több rendszer használható formában létezett. Úgy képzeltem, hogy az eddigi tapasztalatokat átviszem egy valódi játékmotorba, majd fokozatosan újraépítem az egészet egy rendezettebb és hosszabb távon is fenntarthatóbb formában.
A gyakorlatban azonban hamar kiderült, hogy nem pusztán ugyanazt a játékot készítem el egy másik technológiával. A Godotba költözés közben az egész projektről másként kellett elkezdenem gondolkodni.
Webfejlesztőként számomra természetes, hogy egy alkalmazás különálló oldalakból, komponensekből és adatfolyamokból épül fel. Ha szükség van egy új listára, panelre vagy modális ablakra, általában pontosan tudom, hogyan álljak neki. Egy játék felületénél azonban nem elég, hogy minden elem logikusan elhelyezkedik és megfelelő adatot jelenít meg. A képernyőnek hangulatot kell teremtenie, reagálnia kell a játékosra, és vizuálisan is ugyanahhoz a világhoz kell tartoznia, mint az autók, a karakterek és a helyszínek.
A különbség sokszor apróságokban jelentkezett. Egy gomb nem egyszerűen kattintható elem, hanem van alapállapota, kiemelt állapota, rámutatási és lenyomási állapota. Hangja, animációja vagy akár apró mozgása is lehet. Egy panel nem csak egy világos vagy sötét téglalap, hanem része a kompozíciónak. Egy háttér nem pusztán kitölti a rendelkezésre álló helyet, hanem meg kell hagynia azokat a területeket, ahová később olvasható kezelőfelület kerülhet.
A webes prototípusban egy működő gomb már nagyjából késznek érződött. Godotban hamar világossá vált, hogy a működés csak a munka egyik fele.
A kezelőfelület, amelyről azt hittem, könnyű lesz
A fejlesztés kezdetén abban bíztam, hogy a kezelőfelület lesz az egyik leggyorsabban elkészíthető része. Elvégre évek óta felületekkel foglalkozom, ismerem a reszponzív elrendezéseket, a komponenseket, az állapotkezelést és a különféle UI-mintákat. Konténerek, panelek, listák, kártyák és gombok Godotban is vannak, ezért arra számítottam, hogy legfeljebb a motor sajátosságait kell megtanulnom.
Ehhez képest a UI okozta az első igazán komoly reality checket.
A technikai elrendezések viszonylag gyorsan elkészültek, de a végeredmény sokáig túlságosan weboldalszerűnek hatott. Egymás mellé és egymás alá rendezett panelek jelentek meg, dobozok kerültek dobozokba, a képernyő pedig egyre inkább egy adminisztrációs felületre hasonlított. Papíron minden a megfelelő helyen volt, mégsem éreztem azt, hogy egy garázst, boltot vagy szerelőműhelyt nézek.
Ez vezetett ahhoz a felismeréshez, hogy a Rozsda és Dicsőség felületeit nem hagyományos menükként kell kezelnem. A helyszíneknek önmagukban is jeleneteknek kell lenniük. A garázsnak akkor is garázsnak kell érződnie, ha éppen alkatrészt cserélünk benne. A szerelőműhely ne csak egy más elrendezésű alkatrészlista legyen, hanem Sanyi bá műhelye, saját háttérrel, karakterrel és apró megjegyzésekkel. A roncstelep ne egy zsákmánytáblázatként jelenjen meg, hanem egy olyan helyszínként, ahol Kareszt kell lefizetni, hogy egyáltalán beengedjen a jobb kupacok közé.
Ettől kezdve a helyszínek készítése nem egyszerűen abból állt, hogy elkészült egy új képernyő. Előbb meg kellett találnom a jelenet vizuális fókuszát, majd úgy kellett köré építeni a kezelőfelületet, hogy az ne takarja ki a fontos részeket, de közben használható és olvasható maradjon.
Meglepően sokat számítottak egészen apró technikai részletek is. Egy rosszul beállított textúraszűrés miatt a képek életlennek és olcsónak hatottak, majd egyetlen beállítás módosításával hirtelen sokkal tisztább lett az egész felület. Máskor egy autó és egy garázsháttér külön-külön jól nézett ki, együtt azonban egyáltalán nem működtek, mert eltért a perspektívájuk, a méretarányuk vagy a megvilágításuk.
Ezek tipikusan olyan problémák, amelyeket egy önálló látványkép nézegetésekor könnyű figyelmen kívül hagyni, egy működő játékban viszont azonnal feltűnnek.
A képgenerálás nem egyenlő a kész játékassetekkel
A projekt indulásakor az egyik legnagyobb segítséget a képgenerálás jelentette. Nélküle valószínűleg el sem kezdtem volna ilyen vizuális irányban gondolkodni, mert sem az időm, sem a képzettségem nincs meg ahhoz, hogy ennyi hátteret, karaktert, autót és ikont saját kezűleg elkészítsek.
Az első eredmények ráadásul nagyon meggyőzőek voltak. Néhány próbálkozás után már létezett egy garázs, különböző autók, egy bolt és több olyan helyszín, amelyekből kezdett kirajzolódni a játék saját világa. Könnyű volt azt hinni, hogy innentől csak megfelelő promptokat kell írni, majd a kész képeket beilleszteni a projektbe.
A valóság természetesen ennél bonyolultabb lett.
Egy kép lehet látványos és hangulatos, miközben játékon belül szinte használhatatlan. Előfordulhat, hogy a kompozíció közepére kerül minden fontos részlet, pontosan oda, ahová később a kezelőfelületet szeretném tenni. Máskor a generált autó perspektívája csak néhány fokkal tér el a garázsétól, mégis úgy néz ki, mintha lebegne vagy ferdén állna a talajon. Az áttetsző háttér sem mindig valóban áttetsző: az ablakokon vagy a tükröződő felületeken megmaradhat az eredeti háttér zöldes vagy szürkés színe.
A konzisztencia még nagyobb kihívást jelent. Egyetlen jó autót viszonylag könnyű generálni. Ugyanezt az autót azonban már nehezebb három különböző állapotban, azonos nézetből, azonos méretarányban és felismerhetően ugyanazzal a karosszériával elkészíteni. A Rozsda és Dicsőségben minden autónak legalább roncs, gyári és rally változata van, ráadásul a különböző felületekhez több nézetre is szükség lehet.
Ha a roncs változat ötajtós, a gyári hirtelen háromajtós lesz, a rally verziónak pedig teljesen átalakul az orra és az ablaksora, akkor a képek önmagukban lehetnek szépek, játék közben mégsem érződnek ugyanannak az autónak.
Egyre világosabbá vált, hogy a képgenerálás nem helyettesíti az art directiont, hanem még fontosabbá teszi. Pontosan meg kell határozni a nézetet, a méretarányt, a fényeket, a körvonalakat, az elhelyezést és azt is, hogy mely részek maradjanak szabadon a kezelőfelület számára. A generált képek után gyakran szükség van vágásra, átméretezésre, háttéreltávolításra, javításra vagy újragenerálásra is.
Az AI tehát rengeteg munkát vesz le rólam, de nem úgy működik, mint egy automata, amelynek egyik oldalán beadom a játékötletet, a másikon pedig kiesik egy kész assetcsomag. Inkább egy rendkívül gyors, de folyamatos irányítást igénylő grafikai munkatárshoz hasonlít.
Újrakezdés, de nem a nulláról
Bár a Godot-projektet technikailag újrakezdtem, a böngészős változat munkája nem veszett kárba. Éppen ellenkezőleg: nélküle valószínűleg sokkal több rossz irányba indultam volna el.
A prototípus segített felismerni, mely rendszerek érdekesek valóban, és melyek azok, amelyek csak egy tervezési dokumentumban hangzanak jól. Kiderült például, hogy az autó fejlesztése, az alkatrészek cseréje és a különböző állapotú járművek közötti fejlődés erős alapot jelent. Ugyanakkor több olyan rendszer is bekerült, amely elsőre mélységet adott a játéknak, valójában azonban inkább csak újabb számokat és kötelező adminisztrációt hozott.
Az XP-rendszer végül kikerült, mert nem adott hozzá elég érdekes döntést. Az üzemanyag kezelése szintén felesleges tehernek érződött a jelenlegi formájában. Papíron logikusnak tűnt, hogy egy autós játékban tankolni kell, játék közben azonban ez többnyire csak azt jelentette volna, hogy időnként meg kell nyomni egy gombot, különben nem lehet tovább játszani.
A kocsma végül megmaradt, mert a benzinkút az üzemanyag-rendszer elhagyásával kikerült a játékból. Így a kocsma nemcsak hangulati elemként, hanem önálló helyszínként is visszanyerte a szerepét, és továbbra is fontos része maradt a világnak.
Ezek a vágások elsőre fájdalmasnak tűnhetnek, valójában azonban egyre tisztábbá teszik, hogy miről szól a játék. Nem minden realisztikus vagy tematikusan illeszkedő rendszerből lesz automatikusan jó játékmechanika.
A vertical slice felismerése
A böngészős prototípus fejlesztése során hajlamos voltam funkciókban gondolkodni. Legyen bolt, legyen roncstelep, legyen energiarendszer, legyen több versenytípus, legyen időjárás, legyen szerencsejáték, legyen műszaki vizsga. Minden új rendszerrel gazdagabbnak tűnt a játék, közben azonban egyre távolabb kerültem attól, hogy legyen egy rövid, elejétől a végéig végigjátszható része.
A Godotba költözés után ezért a fejlesztés egyik legfontosabb célja a vertical slice elkészítése lett.
A vertical slice ebben az esetben nem egy tartalmilag nagy demót jelent, és nem is a teljes játék kicsinyített másolatát. Sokkal inkább egy olyan rövid játékrészletet, amelyben a legfontosabb rendszerek már összekapcsolódnak egymással. A játékos megkapja a rossz állapotú autóját, eljut a garázsba, alkatrészt szerezhet vagy vásárolhat, felszerelheti, elindulhat egy versenyen, majd az eredmény után visszatérhet a következő döntéshez.
Ez elsőre nem hangzik különösebben nagynak, mégis szinte minden fontos kérdést érint. Érthető-e, mit kell csinálni a garázsban? Érezhető-e a különbség két alkatrész között? Van-e értelme pénzt költeni a fejlesztésekre? Szórakoztató-e maga a verseny? Érdekes-e visszatérni a futam után, és elkölteni a megszerzett jutalmat?
Amíg ezekre nincs válasz, kevés értelme van tíz különböző területet, több tucat autót vagy bonyolult történeti rendszert készíteni.
A jelenlegi terv ezért egy szándékosan korlátozott első verzió. Három terület, három fő ellenfél, néhány helyszín, korlátozott számú autó és alkatrész, valamint annyi verseny, amennyi már megmutatja a fejlődési ciklust. A cél nem az, hogy tartalommal töltsük meg az egész világot, hanem hogy kiderüljön, önmagában működik-e a játék alapja.
Ez számomra különösen fontos tanulság. Korábbi játékötleteknél gyakran az történt, hogy rengeteg rendszer, történet és lehetőség készült el papíron, de maga a játék sosem jutott el egy valóban játszható állapotig. Most szeretném megfordítani ezt a folyamatot. Előbb legyen egy kicsi, de működő játék, és csak utána kezdjen el növekedni.
Az AI felgyorsítja a fejlesztést, de a döntéseket nem hozza meg helyettem
A Godot-váltásban az AI kódolóasszisztensek is komoly szerepet kaptak. Segítségükkel sokkal gyorsabban készülnek el az alapvető jelenetek, kezelőfelületek és rendszerek, mint ahogyan egyedül, egy számomra új játékmotorban haladni tudnék. Egy-egy ötletből rövid idő alatt működő prototípus lehet, amit azonnal ki tudok próbálni.
Ez azonban új problémákat is hoz. Mivel technikailag szinte bármit gyorsan el lehet készíteni, sokkal könnyebb túl hamar túl sok funkciót beépíteni. Korábban egy bonyolult rendszer megvalósításának időigénye természetes féket jelentett. Most ez a fék jóval gyengébb, ezért nekem kell tudatosan eldöntenem, hogy mi az, amire valóban szükség van.
Az AI abban nagyon jó, hogy egy pontosan meghatározott feladatot végrehajtson, de azt nem tudja eldönteni helyettem, hogy az adott feladatot egyáltalán érdemes-e megcsinálni. Meg tud írni egy üzemanyagrendszert, de nem fogja megérezni, hogy az játék közben csak felesleges adminisztráció. El tud készíteni egy új helyszínt, de attól az még nem biztos, hogy erősíti a játék alapciklusát.
A fejlesztés így érdekes módon nem feltétlenül lett egyszerűbb. A kódolás gyorsabb lett, de a tervezési döntések súlya megnőtt.
Mi készült el eddig?
A Godot-verzióban mostanra elkészült a főmenü, a garázs alapfelülete, az autóválasztás, az alkatrészek kezelése, a bolt, a raktár, a szerelőműhely és a roncstelep első változata. A különböző helyszíneken már karakterek jelennek meg, akik rövid szövegbuborékokban megjegyzéseket tesznek, így a képernyők lassan nemcsak funkcióként, hanem a világ részeként is működni kezdenek.
Bekerült több versenytípus kezdeti változata, elkészültek az időjárás alapjai, és már a vizuális effektekkel is elkezdtem kísérletezni. A főmenü alatt zene szól, a háttérben részecskeeffektek jelennek meg, a lámpák pedig shadert kaptak. Ezek önmagukban apróságok, mégis sokat segítenek abban, hogy a projekt kevésbé technikai prototípusnak és egyre inkább játéknak érződjön.
Közben természetesen rengeteg olyan részlet is előkerült, amelyet újra kellett gondolni. Az autók mérete és perspektívája nem minden felületen működött, egyes ikonokat többször újra kellett készíteni, a panelek pedig sokáig túlságosan egymásra pakolt dobozoknak tűntek. A fejlesztés jelentős része jelenleg nem új funkciók hozzáadásából áll, hanem abból, hogy a meglévő elemek végre egységes egésszé álljanak össze.
A prototípus és a játék közötti távolság
A böngészős változat bebizonyította, hogy a Rozsda és Dicsőség alapötlete működhet. A Godotba költözés viszont azt is megmutatta, hogy egy működő prototípus és egy valódi játék között jóval nagyobb a távolság, mint elsőre gondoltam.
A prototípusnál elég, ha egy rendszer választ ad arra a kérdésre, hogy megvalósítható-e az ötlet. Egy játéknál azonban annak is számítania kell, hogyan néz ki, milyen érzés használni, mennyire érthető, hogyan kapcsolódik a többi rendszerhez, és van-e kedve a játékosnak újra megnyomni azt a bizonyos gombot.
Most ezért nem az a célom, hogy minél több új mechanikát készítsek, hanem hogy elkészüljön egyetlen rövid, de végigjátszható szelet. Egy autó, néhány helyszín, egy működő fejlődési ciklus és annyi verseny, amennyi már megmutatja, hogy érdemes-e tovább építeni erre az alapra.
A következő nagy kérdés maga a versenyzés lesz. A jelenlegi rendszer működik, de a tesztek során világossá vált, hogy még nem elég taktikus, és nem ad annyi érdekes döntést, amennyit a játék központi mechanikájától várok. Emiatt már elkezdődött egy új, pályaszakaszokra, tempóra, motorhőre és a lapok tudatos beosztására épülő változat prototipizálása.
Erről azonban majd egy következő bejegyzésben írok részletesebben, amikor már nemcsak néhány lelkesítő tesztfutam, hanem valamivel több tapasztalat is lesz mögötte.