Ez az írás arról fog szólni, hogy miből áll a pre-produkciós fázis egy fejlesztés esetében. Mivel érdemes kezdeni, hogyan érdemes felkészülni a gyártásra? A cikk kisebb projektek gyakorlatát írja le, de azért elég nagy az átfedés nagyobb játékok és cégek esetén is. Ha valaki kifejezetten a nagyobb cégek gyakorlatára kíváncsi, akkor ez a könyv nagyon hasznos lehet a számára.

Általában egy fejlesztés azzal indul, hogy valakinek támad valamilyen ötlete. Ez sokszor egy nagyon általános, vagy éppen kifejezetten különleges ötlet, ami azonban, bárhonnan is nézzük, csak egy ötlet. Egy olyan ötlet, amiben benne van a lehetőség, hogy a világ legjobb játéka legyen, de még nem az. Sok kommunikációra, és a többiek ötleteire is szükség van ahhoz, hogy a játék kiforrja magát, és felszínre kerüljön az igazi kreatív potenciálja. Éppen ezért szokták azt mondtani, hogy egy ötlet önmagában nem ér sokat, a hangsúly azon van, hogyan szeretné a csapat megvalósítani, átadni azt. A pre-produkciós fázis nagy része arról szól, hogy a csapat még a gyártás elkezdése előtt kidolgozza a játék minden részletét és letisztázza a pontos működéseket.

Brainstorm

A brainstorm egy nagyon hasznos módja annak – főleg a fejlesztés kezdeti időszakában -, hogy nagy mennyiségű ötlet összegyűljön. Ezek nem mindig lesznek hasznos ötletek, de segíthetnek megtalálni a hiányzó láncszemet a design-ban, vagy jó nevet találni a játékhoz.

A brainstorm lényege az, hogy a csapat tagjai nem egyedül, hanem együtt ötletelve keresnek megoldást valamilyen problémára. Egy jó brainstorm során szükség van mindenki egyéni tudására, a csapattagok kombinatív képességeire és kreativitására. Azonban ennek is vannak szabályai, amiket érdemes megfogadni, hogy a legjobb eredményt érjük el.

A brainstorm módszerét akkor érdemes alkalmazni, hogyha sokféle, és sok számú válaszlehetőséget keresünk. Fontos, hogy mindegyik ötletet felírjuk, és ne kritizáljunk az ötletelés közben. Ez segíti azt, hogy minden “hülye” ötlet felkerüljön a táblára, mert ki tudja? Lehet az fogja majd meghozni végül a megoldást. Érdemes kinevezni egy moderátort, aki biztosítja az ötletek felírását és a vita elkerülését, valamint jó előre letisztázni a témát, és felvázolni a célt, amit el szeretnénk érni a brainstorm-mal. Pl. “Szeretnék nevet találni az új játéknak, és mindenki ötletét szívesen látom. Ha összegyűlt negyven ötlet, szavazzunk meg közülük hármat!” vagy “Játéktesztelés során kiderült, hogy a játékosok unalmasnak találják a crafting rendszert. Hogyan lehetne megváltoztatni, mivel lehetne feldobni?”

Érdemes utána az eredményeket elmenteni, mert lehet, hogy a későbbiekben még szükség lesz az ötletekre.

Research

Ha megvan a játékötlet, és már nagyvonalakban tudjuk, mit akarunk, meg kell határozni miben lesz hasonló más játékokhoz, és miben fog különbözni tőlük. Ezzel együtt meghatározzuk a zsánert, témát, stílust is. Ez segíteni fog abban, hogy mindenki ugyan arról a játékról gondolkozzon a csapatban, és ne térjenek el nagyon az elképzelések.

Ez abban is segíteni fog, hogy meghatározzuk a piacon lévő, hasonló játékok listáját. Ebben legyen nagyon sikeres, és kevésbé sikeres is – hiszen mindenből tanulhatunk. A lényeg az lesz, hogy meghatározzuk a benchmarkokat, és próbáljuk megérteni, miért működnek egyes játékok, és miért nem működnek más játékok. Ez segíthet meghatározni azt, hogy mit szeret a játékunk potenciális közössége, mik azok a mechanikák amiket jó lenne megtartani – hiszen industry standardnak számítanak, és a játékosok elvárják őket -, és mik azok, ahol ráférne a zsánerre egy kis újdonság.

Érdemes körülnézni a Steam statisztikákban – itt részletes számokat kaphatunk játékokról, most már azzal együtt, hogy mikor voltak akciózva, és mennyi bevételt hoztak. Ez adhat egy reális képet arról, hogy mekkora bevételre számíthatunk a jelenlegi piacon, mik a legjobb szcenáriók, és mi a reális verzió.

Megéri utána nézni annak is, hogy ezek a játékok milyen marketing stratégiát alkalmaztak, mikor, milyen bundle-ket árultak, stb. Ez segíthet megérteni a piaci lehetőségeket, a marketingünk potenciális költségeit, és mérlegelni, hogy egyáltalán megéri-e a projektbe belekezdeni. A szomorú valóság ugyanis, hogy a világ legjobb játékát készíthetjük el, ha senkit nem érdekel, akkor ugyanúgy sikertelen lesz a projekt. Így érdemes felmérni, hogy ami nekünk tetszik, annak van-e esélye a piac vadnyugatán.

Design dokumentum

A design dokumentumot már a fejlesztés legelső fázisában hasznos elkezdeni, hiszen ez a dokumentum foglalja össze a játékkal kapcsolatos összes információt. Fontos, hogy az általános információk mellett (pl. zsáner, célközönség, rövid összefoglaló) a specifikációk is le legyenek írva. Hogyan működik pontosan egy-egy mechanika? Milyen játékos cselekedetek vannak az egyes játékfázisokban?

A dokumentumot általában a game designer írja, és az ő feladata, hogy folyamatosan naprakész információk legyenek benne. Vezetése két okból is lényeges lehet, egyrészről biztosítja, hogy mindenki pontosan tudja mi lesz benne a játékban, másrészről pedig a design doksi segítségével nyomon lehet követni az aktuális változtatásokat – például hogyha játéktesztelés során kiderül, hogy egy feature javításra szorul.

A design dokumentum nem csak azért hasznos, mert leírja a játékról az összes információt, hanem azért is, mert segít rávilágítani az esetleges ellentmondásokra, illetve arra készteti a designert, hogy a játék minden aspektusát alaposan átgondolja és kidolgozza. Persze nem feltételezem, hogy egy designer ellustulná a feature-ök átgondolását, egyszerűen csak könnyen előfordulhat, hogy elsiklik valami fölött, esetleg számára egyértelmű egy működés, míg mások nem tudják hogyan kéne implementálni egy-egy mechanikát. Sok vitát és félreértést el lehet kerülni azzal, hogyha a csapat jól használja a design dokumentumot.

Ez már sugallja, hogy a design dokumentum nem egy könnyű esti olvasmány. Még a legkisebb projektnél is kb. tíz oldalra bővül a projekt vége felé, ezért a designernek érdemes arra törekednie, hogy mindenki könnyen megtalálja a számára hasznos információt. Érdemes könyvjelzőket és tartalomjegyzéket beilleszteni, illetve strukturálni az információt, még akkor is, hogyha ez a már leírt dolgok megismétléséhez vezet. Inkább legyen benne kétszer egy információ, hogyha az programozóknak és grafikusoknak is hasznos, mint hogy valaki ne találjon rá. Bonyolultabb rendszereknél jól jöhet a képes vagy grafikonos ábrázolás – sokszor egy ábra többet ér, mint egy fél oldalas leírás.

Érdemes röviden, tömören és érthetően fogalmazni, mert a lényeg a gyorsaság és átláthatóság. Senki nem akar hosszú perceken keresztül olvasgatni, hogyha épp keres egy adott információt. Gyorsan meg akarja találni az ember a választ, és kész. Emellett általában a csapat hajlamos elfeledkezni a design dokumentumról, emiatt hasznos lehet körbeírni a tagoknak, hogyha bővült, vagy megváltozott egy-egy rész.