Nemrég belefutottam egy videóba, amely egy magyar fejlesztésű, posztapokaliptikus zombis játékot kritizált. Nem egy higgadt, távolságtartó elemzés volt: a videós meglehetősen nyersen fogalmazott, sokszor szándékosan túlozva és poénkodva mutatta be a játék hibáit. Nem minden megjegyzésével értettem egyet, a kritika lényegét mégis jogosnak éreztem. A játék első pillantásra kifejezetten ambiciózusnak tűnik: nagyobb bejárható területek, túlélési rendszerek, fejlődés, küldetések, lootolás, közelharc, lőfegyverek, mászás, magyar szinkron és egy posztapokaliptikus történet került bele. Mindezt állítólag mindössze három ember készítette el, ami önmagában tiszteletre méltó teljesítmény.
Csakhogy a játékos nem egy fejlesztési naplót vásárol meg. Nem a befektetett munkaórák számáért fizet, hanem azért az élményért, amely végül a képernyőjén megjelenik. Ez a kettő pedig sajnos nem mindig arányos egymással.
„Csinálj jobbat, aztán kritizálj!”
A videó alatt természetesen hamar megjelent a jól ismert védekező reakció: hogyan lehet ilyen keményen kritizálni egy játékot, amelyen csupán három ember dolgozott? Miért nem készít a videós előbb ő maga valami hasonlót? Miért vár el bárki GTA 6-szintű minőséget egy apró magyar csapattól?
Ez az érvelés elsőre érthetőnek tűnik, de valójában félreviszi a beszélgetést. Senki nem vár GTA 6-ot három embertől. A kritika nem arról szólt, hogy miért nincs a játékban több száz animáció, filmszerű történetvezetés, hatalmas, élő világ vagy több millió eurós látvány. Sokkal alapvetőbb problémákról volt szó: rossz teljesítményről, bugokról, logikátlan pályatervezésről, sekélyes küldetésekről, egymáshoz lazán kapcsolódó mechanikákról és a készültségi szinthez képest magas árról.
A befektetett munka magyarázhatja ezeket a hiányosságokat, de nem tünteti el őket. Egy termék kritikájához pedig nem szükséges előbb ugyanazt a terméket jobban elkészíteni. Nem kell szakácsnak lennünk ahhoz, hogy felismerjük, ha odaégett az étel, és játékfejlesztőnek sem kell lennünk ahhoz, hogy érezzük, amikor egy játék következetlen, frusztráló vagy félkész. Én történetesen fejlesztek játékot – igaz, nagyságrendekkel kisebbet, Godotban –, ezért pontosan látom, mekkora munka van már egy elsőre jelentéktelennek tűnő funkció mögött is. Mégis úgy gondolom, hogy a fejlesztés nehézsége nem lehet felmentés a végeredmény értékelése alól.
A busz, amelyen át kell mászni
A videó egyik legtöbbet emlegetett jelenetében a játék tutorialja azt akarja megtanítani a játékosnak, hogy bizonyos akadályokon át lehet mászni. Az útban áll egy busz, amelynek az ajtaja el van torlaszolva, ezért a játék arra utasít, hogy másszunk fel a tetejére, majd jussunk át rajta. Csakhogy a busz ablakai nyitva vagy kitörve vannak. Vizuálisan semmi nem indokolja, hogy a karakter miért ne mászhatna be egyszerűen az egyik ablakon. A játékos tehát azt látja, hogy létezik egy magától értetődő útvonal, a játék szabályai azonban önkényesen megtiltják annak használatát.
Ez apróságnak tűnhet, valójában azonban tökéletes példája annak, hogyan törik meg az immerzió. Ráadásul nem egy ritka, eldugott hibáról van szó, amelyet csak néhány különösen kíváncsi játékos talál meg. Ez a tutorial része, vagyis minden játékos találkozik vele, méghozzá a játék elején, amikor még éppen kialakítja az első benyomását a világról és annak szabályairól.
A megoldás nem igényelt volna többmilliós költségvetést. Be lehetett volna deszkázni az ablakokat, lehetett volna a busz annyira összeroncsolódva, hogy ne lehessen bemászni, vagy választhattak volna teljesen más akadályt. Ha pedig a vaulting mechanika és a pályahatárok nem működtek minden helyzetben megbízhatóan, akkor szűkíteni kellett volna a használatukat. A probléma itt nem a technológiai korlát vagy a fejlesztőcsapat mérete, hanem az, hogy a játék egyik legelső, tudatosan megtervezett jelenete nem következetes.
Amikor mindenből kerül egy kevés a játékba
A kritizált játékban van éhség, szomjúság, lootolás, fejlődési rendszer, skillfa, küldetések és történet is. A videós szerint azonban ezek közül több csak azért került bele, hogy el lehessen mondani: ilyen rendszer is van a játékban. Az éhség és a szomjúság nem teremt érdekes túlélési döntéseket, inkább csak további adminisztrációt jelent. A skillfa a legalapvetőbb fejlődési megoldásokat használja, a küldetések gyakran egyszerű „menj oda, vedd fel, hozd vissza” feladatok, a történet pedig nem ad elég erős keretet ahhoz, hogy összefogja ezeket a mechanikákat.
Ez számomra különösen érdekes tanulság volt, mert a saját játékom fejlesztése során én is könnyen belecsúszom ugyanezen gondolkodásba. Van egy működő alapötlet, majd rögtön eszembe jut még egy rendszer. Aztán még egy. Lehetne benne időjárás, alkatrészállapot, barkácsolás, sofőrképességek, üzemanyag, szerencsejáték, műszaki vizsga, rendőrségi kockázat, különböző munkák, több terület, több versenytípus, több szereplő és több történeti szál.
Webes környezetben különösen könnyű volt ebbe beleszaladnom. Egy új rendszer elsőre csak néhány adatbázismezőnek, egy új modalnak és pár gombnak tűnt. Technikailag gyorsan létre lehetett hozni valamit, ami működött. De attól, hogy egy rendszer működik, még nem biztos, hogy jobb lesz tőle a játék.
Godotban ez sokkal hamarabb fájdalmassá válik. Egy új funkcióhoz már nem elég létrehozni a mögöttes logikát. Felületet kell tervezni hozzá, grafikát kell készíteni, állapotokat kell kezelni, animációt, visszajelzéseket és hangokat kell hozzáadni. Be kell illeszteni a játék ritmusába, és meg kell tanítani a használatát a játékosnak. Ilyenkor elkerülhetetlenül felmerül a kérdés: valóban megér ennyi munkát ez a funkció?
Nem az számít, hogy érdekes-e róla tervezési dokumentumot írni. Az számít, hogy milyen döntést ad a játékosnak. Az üzemanyag például lehet érdekes erőforrás, ha útvonalak, pénzügyi kockázatok és versenyek között kell gazdálkodni vele. Ha azonban csak annyit jelent, hogy időnként meg kell nyomni a „Tankolás” gombot, akkor nem mélységet ad, hanem újabb kötelező kattintást. Ugyanez minden rendszerre igaz: ha nem hoz létre érdekes választást, következményt vagy érzelmet, akkor könnyen lehet, hogy nincs helye a játékban.
A scope nemcsak a játék méretét jelenti
Sokáig úgy gondoltam a scope-vágásra, mint egyszerű mennyiségi csökkentésre: kevesebb pálya, kevesebb ellenfél, kevesebb autó és kevesebb történet. Mostanra egyre inkább azt látom, hogy ennél többről van szó. A scope-vágás annak eldöntése is, hogy mely mechanikáknak kell valóban kidolgozottnak lenniük, és melyeket kell teljesen elengedni. Sok esetben ugyanis nem az a baj, hogy egy játékban kevés rendszer van, hanem az, hogy túl sok rendszer kapott túl kevés figyelmet.
A kritizált játék láthatóan sok mindent megpróbált egyszerre felépíteni: nagyobb világot, túlélést, RPG-elemeket, narratívát, harcot, küldetéseket és mozgási rendszereket. A végeredmény azonban a videó alapján nem állt össze egységes élménnyé. Egyenként talán mindegyik rendszer működik valamilyen szinten, együtt viszont inkább technikai funkciók gyűjteményének érződnek, mint egy világos alkotói víziót szolgáló játéknak.
Pontosan ezt szeretném elkerülni a saját projektemben. A játékom eredetileg sokkal nagyobbnak indult: tíz boss, rengeteg terület, teljes történet, számos melléktevékenység és egymásra épülő rendszer szerepelt a tervben. Mostanra ott tartok, hogy ennek jelentős részét későbbi verziókra tolom. Az első kiadás három bossra fog koncentrálni, nem azért, mert a többi ötletről lemondtam, hanem mert előbb szeretném bizonyítani, hogy az alapjáték valóban működik.
Élvezetes-e a kártyaalapú versenyzés? Érdekes-e az autó fejlesztése? Kötődnek-e a játékosok a szereplőkhöz? Van-e kedvük folytatni a harmadik boss legyőzése után? Ha ötven valódi játékos végigjátssza, és elmondja, mi működött, mi volt unalmas, hol akadt el, illetve szeretne-e folytatást, akkor már sokkal többet fogok tudni, mint amennyit újabb két évnyi tervezésből megtudhatnék.
A játékos nem látja a munka nagy részét
A játékfejlesztés egyik legkegyetlenebb tulajdonsága, hogy a befektetett munka jelentős része láthatatlan. A játékos nem látja, hányszor kellett átírni a mentési rendszert. Nem tudja, mennyi idő volt az ellenfelek viselkedését összehangolni, és nem érdekli, hogy egy menü mögött hány adatstruktúra, állapotkezelő vagy hibajavítás dolgozik. Azt látja, hogy megnyomott egy gombot, és nem történt semmi. Azt érzi, hogy túl lassú a fejlődés. Azt veszi észre, hogy az NPC ugyanott áll, ugyanazt a két mondatot ismétli, miközben körülötte elvileg összeomlott a világ.
A kritizált játékban a videós külön kiemelte, hogy az NPC-k sokszor csak egy helyben állnak, a küldetések néhány mondatból állnak, és a világ nem reagál meggyőzően a jelenlétükre. Emiatt hiába léteznek technikailag karakterek és feladatok, nem érződnek egy élő világ részének.
Fejlesztőként könnyű azt mondani: „De hát ez is működik.” A játékos számára azonban a működés csak a belépőszint. Egy párbeszédrendszer attól még nem jó, hogy megjeleníti a szöveget. Egy fejlődési rendszer attól még nem érdekes, hogy növekednek benne a számok. Egy gazdaság attól még nem mély, hogy sokféle pénzforrás és kiadás található benne. Az számít, milyen élményt hoznak létre együtt.
A csiszolást nem lehet megúszni
Kis túlzással gyakran az utolsó tíz százaléknyi munka adja a játékos által érzékelt élmény kilencven százalékát. Ez persze matematikailag nem mérhető állítás, fejlesztőként azonban egyre inkább értem, mit jelent. Az utolsó szakaszban már ritkán kerülnek be látványos új funkciók. Inkább a gombok reakcióidejét javítjuk, animációkat rövidítünk, magyarázó szövegeket írunk át, hibás állapotokat kezelünk, az első fél órát teszteljük újra és újra, illetve kidobjuk azokat a dolgokat, amelyek külön-külön jó ötletnek tűntek, együtt viszont már csak zavarják a játékot.
Ez hálátlan munka. Egy új skillfa vagy minijáték sokkal izgalmasabb fejlesztői feladatnak tűnik, mint száz apró vizuális és használhatósági hiba kijavítása. A játékos számára mégis az utóbbi lesz fontosabb. Nem az fogja lenyűgözni, hogy tizenöt rendszer található a játékban, hanem az fogja meghatározni az élményét, hogy ezek közül mennyi működik következetesen, érthetően és megfelelő ritmusban.
Mikor prototípus, és mikor termék?
A kritika egyik legerősebb pontja az árra és a pozicionálásra vonatkozott. A játék húsz euróért, kész 1.0-s megjelenésként került fel a Steamre. A videós szerint ugyanebben az állapotban ingyenes demóként vagy korai hozzáférésű projektként jóval elnézőbben lehetett volna értékelni. Egy teljes értékű terméknél azonban más elvárások lépnek életbe.
Nem azért probléma a húsz euró, mert egy kis csapat játéka nem kerülhet ennyibe. Egy különleges, jól felépített és csiszolt indie játék nyugodtan érhet húsz eurót, vagy akár többet is. A kérdés az, hogy mit ígér a termék. Ha valami kísérlet, prototípus vagy fejlesztés alatt álló projekt, akkor ezt őszintén kell kommunikálni. Ha viszont kész, kereskedelmi játékként jelenik meg, akkor a játékos joggal várja el, hogy az alapvető mechanikák, a teljesítmény, a pályatervezés és a történeti prezentáció már ne csak demonstrációs szinten működjön.
Ez volt számomra az egyik legfontosabb felismerés. Fejlesztőként őszintének kell lennünk nemcsak a közönségünkkel, hanem saját magunkkal is. Mit készítünk valójában? Egy technikai tanulmányt, egy portfólióprojektet, egy korai prototípust, amelyen visszajelzéseket szeretnénk gyűjteni, vagy egy kész terméket, amelyért pénzt kérünk? Mindegyik teljesen legitim cél, de más készültségi szintet, kommunikációt és árazást igényel.
A saját játékom első, három bossig tartó változatát ezért ingyenesen szeretném elérhetővé tenni az itch.io-n. Nem akarok úgy tenni, mintha már elkészült volna a teljes vízió. Azt szeretném megtudni, hogy érdemes-e tovább építeni. Ha a játékosok azt mondják, hogy kérik a folytatást, akkor lesz értelme elkészíteni a további bossokat, területeket és történeti szálakat. Ha pedig nem, akkor ezt jobb három boss után megtudni, mint tíz boss és többévnyi munka után.
Nem a munka hiányzott
A videó egyik túlzó megfogalmazása szerint a készítők „nulla effortot” tettek a játékba. Ezzel nem értek egyet. Már abból is látszik a befektetett munka, hogy a játék egyáltalán elkészült. Három ember összehozott egy bejárható 3D világot, harcrendszert, küldetéseket, fejlődést, túlélési mechanikákat és teljes magyar szinkront. A videós is elismerte, hogy a szinkron jó minőségű és igényesen készült.
A probléma nem az erőfeszítés teljes hiánya. Talán éppen ellenkezőleg: rengeteg energiát fektettek túl sok különböző területbe, és nem maradt elegendő idő arra, hogy ezekből koherens, végigcsiszolt játék szülessen. Ez tragikusabb és tanulságosabb annál, mint hogy egyszerűen lusták lettek volna.
Egy rossz vagy érdektelen projektet könnyű elengedni. Sokkal nehezebb kidobni egy olyan mechanikát, amelybe már heteket vagy hónapokat fektettünk. Ilyenkor a fejlesztő könnyen úgy érzi, hogy a munka kárba veszne. Pedig néha éppen attól lesz jobb a játék, hogy a munka egy része nem kerül bele.
Néha hátra kell lépni kettőt
Játékfejlesztőként nehéz beismerni, hogy túl sokat akarunk. Minden új rendszer izgalmasnak tűnik, minden karakterben van lehetőség, minden terület új játékmenetet ígér. Folyamatosan látjuk magunk előtt azt a teljes, hatalmas játékot, amely egyszer majd talán összeáll. Közben viszont könnyű megfeledkezni arról, hogy a játékos nem ezt a fejünkben létező végső változatot fogja látni, hanem azt, amit ténylegesen sikerült befejeznünk.
Ezért néha nem előre kell lépni még egy funkcióval, hanem hátra kettőt. Megnézni, mi a játék valódi magja, kidobni azt, ami csak azért szerepel benne, mert már elkezdtünk dolgozni rajta, és elhalasztani azt, ami később is megvalósítható. A felszabaduló időt pedig arra fordítani, hogy ami bent maradt, az valóban jól működjön.
Nem kell GTA 6-ot készítenünk. De bármekkora játékot is vállalunk, azt be kell tudnunk fejezni.