Mostanában elég sok játékfejlesztős videót nézek, és szinte mindegyik előbb-utóbb eljut ugyanahhoz a tanácshoz: csökkentsd a scope-ot. Ne akarj túl nagy játékot készíteni, főleg elsőre. Vágj ki feature-öket, ne építs fölösleges rendszereket, és inkább legyen egy kisebb, de befejezett játékod.
Ezzel nehéz vitatkozni. Én is pontosan ezt próbálom csinálni a saját projektemnél, a Rozsda és Dicsőségnél. Több ötletet elengedtem, rendszereket egyszerűsítettem, és tudatosan meghúztam egy határt arra, hogy mi fér bele az első játszható verzióba. Mégis rendszeresen azt érzem, hogy lassan haladok, és a játék továbbra is túl nagy falat.
Egy idő után kezdett leesni, hogy valószínűleg nem csak a feature-ök száma határozza meg egy játék valódi scope-ját.
Solo fejlesztőként ugyanis egy feature szinte soha nem csak annyit jelent, hogy le kell programozni. Kell hozzá UI, ki kell találni a használatának UX-ét, szükség lehet grafikára, ikonra, animációra, hangra, szövegre, majd az egészet tesztelni és finomhangolni kell. Ha közben változik a mechanika, könnyen lehet, hogy ezek közül többhöz újra hozzá kell nyúlni.
Egy egyszerűnek tűnő feladat így nagyon gyorsan szétterül több különböző területre.
Nálam erre jó példa volt a játék térképe. Elsőre csak egy térképnek tűnt, amin területeket és helyszíneket lehet kiválasztani. Aztán rögtön jöttek a kérdések: hogyan navigál rajta a játékos, hogyan jelenjenek meg a helyszínek, hány kattintásból lehessen eljutni valahova, milyen állapotai legyenek a felületnek, milyen visszajelzést kapjon a játékos, hogyan nézzen ki az egész.
Végül leegyszerűsítettem az egészet egy sima területválasztós felületre.
Ez első ránézésre csak egy UX-döntésnek tűnik, valójában viszont egyszerre csökkentette a UI-, UX-, grafikai és programozási munkát is. Vagyis nem egyszerűen egy feature-ből vágtam le valamennyit, hanem több munkaterület terhelését csökkentettem egyszerre.
Innen nézve egy feature valódi költségét talán nem is az alapján érdemes becsülni, hogy mennyi idő lekódolni. Sokkal jobb kérdés lehet az, hogy hány különböző területet érint.
Egy kétórás programozási feladat könnyen lehet drágább, mint egy többnapos belső refaktor, ha az előbbihez új UI, grafika, szöveg, hang és tesztelés is kell. A játékfejlesztésben ezek a dolgok nem elszigetelten léteznek. Egy változtatás gyakran hullámot indít el az egész projekten.
Talán ezért érződhet még egy viszonylag jól scope-olt játék is nagynak.
Lehet kevés pályád, kevés karaktered és kevés mechanikád, de attól még ugyanúgy kell valamilyen UI, UX, grafika, hang, animáció, szöveg és működő kód. A játék méretével ezek mennyisége csökkenthető, teljesen eltüntetni viszont őket nem igazán lehet.
És solo fejlesztőként mindez ugyanannak az embernek a fejében találkozik.
Ezért most már kicsit máshogy gondolok a scope csökkentésére is. Nem csak azt érdemes megkérdezni, hogy egy feature kell-e a játékba, hanem azt is, hogy mi annak a legegyszerűbb változata, ami már betölti a szerepét.
Nem feltétlenül kell kidobni a térképet. Lehet, hogy elég egy területválasztó képernyő. Nem feltétlenül kell elhagyni egy fontos mechanikát. Lehet, hogy az első verzióban elég hozzá egy egyszerűbb UI és minimális animáció.
Ettől még a játék nem lesz kis projekt. Csak kontrollálhatóbb.
És talán ez az, amit a „csökkentsd a scope-ot” tanácsból könnyű félreérteni. A jó scope nem feltétlenül azt jelenti, hogy a projekt egyszer csak könnyűnek fog érződni. Inkább azt, hogy a rengeteg különböző feladat ellenére van esély arra, hogy egyszer tényleg a végére érj.