Fogalmam sincs hogy sikerült előbb megírnom a prototípus és iterálás részt, de nem baj, most bepótolom a hiányosságokat és gyorsan kitérek az ötletelésre és a fejlesztéssel kapcsolatos dokumentumokra. 

Ez az írás arról fog szólni, hogy miből áll a pre-produkciós fázis a fejlesztés alatt. Mivel érdemes kezdeni, hogyan érdemes felkészülni a gyártásra? 

Azt azonban előrevetítem már most, hogy én indie fejlesztő vagyok, így az összes eddigi játékfejlesztéssel foglalkozó írásom - a mostani is - ebből a szemszögből íródott. Nehéz nekem ettől elvonatkoztatni, mert ezt ismerem, ebben vagyok járatos. Ez annyit jelent, hogy a cikkek általában kis projektek gyakorlatát írják le, nagyobb játékok és cégek esetén a leírtakhoz képest eltérő a helyzet. Ha valaki 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 implementálni 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. 

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. 

Ez lett volna a mai rész, ha valaki szeretne többet olvasni a játékfejlesztésről, itt találja a kapcsolódó írásokat, illetve ha tetszett a cikk, keressétek fel Facebook oldalamat is, hogy ne maradjatok le semmiről! :)