A GDD rövidítés az angol Game Design Document – magyarul talán: játéktervezet-dokumentáció, vagy egyszerűbben játék specifikáció – kifejezést takarja, és nem más, mint egy szöveg, egy egyszerű dokumentum.
Minden játék, vagy egyéb projekt fejlesztésének előfeltétele.
Őszintén mondom, hogy közepes és nagyobb projektek esetében elég nehéz megszülni ezt a doksit, ugyanakkor elkerülhetetlen. Egyedül talán a nagyon mini projektet esetében lehet megúszni, ahol a teljes működést két mondatban össze lehet foglalni.
Ez a közös nevező, a kapocs az ügyfél elgonodolása és a játékfejlesztő munkája között.
Amit az ügyfél általában hoz a fejében, még jól gondolkodó, precíz emberek esetében is csak vázlatosnak mondható a valósághoz képest. És ez nem is lehet másképp.
Az ember agya nagyon ügyesen kezeli a “valami valahogy lesz” fogalmát egy összetett terv esetében is, de a számítógép erre képtelen (egyelőre), és így a programozás sem lehetséges.
A GDD-nek mindent – ezt úgy értem, hogy mindent! – tartalmaznia kell, ami csak a játékmenet során előfordul, vagy előfordulhat.
Fontos megérteni, hogy nem tartalmazhat vakfoltokat a játékmechanikában, hiszen minden létező eshetőséget kezelnünk kell, és úgy nem programozható egy folyamat, hogy bizonyos részeit a szélre bízzuk.
Minden részt körül kell járni, ami csak előfordulhat.
Már csak ebből a törvényszerűségből adódóan is szükséges leírt formába önteni minden információt, ami rendelkezésre áll. A maradékot pedig ki kell találni, míg eléggé ki nem kristályosodnak a gondolatok.
GDD a gyakorlatban
A gyakorlatban semmi ördöngősségre nem kell gondolni, mint egy terebélyes google doc-ra, amit együtt megírunk az ügyféllel. A felmerülő kérdésekre kommentek használatával keresünk megoldást, majd ezt felvezetjük a dokumentumba.
Ha elfogytak a kérdések, és minden logikai lyuk befoltozásra került, jöhet a kalkuláció.
A kalkulációs tábláról majd egy másik posztban írok, de röviden annyit róla, hogy nagy pontosságal tartalmazza a projekt részeire szükséges fejlesztési időt és így költségeket. Elkészítéséhez már nem kell az ügyfél, ő végre megpihenhet átmenetileg.
A kalkulációs tábla a meglepetések kizárására szolgál.
Na de mi is szerepel ebben a GDD-ben, azon belül, hogy minden?
- Játék neve, ismertető
- Célközönség, célkitűzések
- Célzott platformok
- Célnyelvek, ha többnyelvű lesz
- Monetizációs politika, elvárások – tehát pl. freemium modell, jutalmazott reklámok használatával
- Célzott grafikai stílus, referenciák, élő példák, hasonló játékrendszerek
- Scene-ek – magyarul talán “felvonásnak” lehetne fordítani. Pl egy scene-nek számít a főmenü, egy másiknak a térkép nézet, egy harmadiknak a csata jelenet, stb…
- Választási lehetőségek – pl játék indítása előtti opciók, beállítások, stb…
- Játékmechanika
- Célok
- Jutalmak
- Game Over feltételek
- Fejlődési lehetőségek
- Pályák
- Multiplayer – ez egy külön fejezetet érdemelne
- Mentési lehetőségek – ha vannak
- Később várható fejlesztések – későbbi updatekben várható elképzelések
A részleteket természetesen a játék típusa válogatja, de szerintem így érthető a cél.
Mennyire kőbe vésett a GDD tartalma?
Eléggé. Ugyanakkor ez nem jelenti azt, hogy nincs lehetőség módosításra, vagy kiegészítésre. Persze, hogy van! Hiszen ez egy több hónapos – akár éves – kaland, senki sem láthat előre minden részletet. Ésszerű(!) határokon belül nagyon is bővíthetőek/módosíthatóak az elképzelések, máshogy nem is lehetne.
A GDD-nek amennyire lehet ugyan egzaktnak kell lennie, ugyanakkor vegyük észre a mögötte rejlő rugalmasságot is!
Amelyik részlet nem meghatározott, de a fejlesztő számára elég információt tartalmaz, azt a fejlesztő legjobb tudása, illetve bevett eljárások alapján valósítja meg.
Egyszerűbben: pl a dokumentumban nem kell szerepelnie annak, hogy milyen színű legyen egy gomb, ezt a készítő “automatikusan” a stílus irányelveket figyelembe véve legjobb belátása szerint készíti el jól.
Amelyik részlet nem meghatározott, de a fejlesztő számára elég információt tartalmaz, azt a fejlesztő legjobb tudása, illetve bevett eljárások alapján valósítja meg.
Egyszerűbben: pl a dokumentumban nem kell szerepelnie annak, hogy milyen színű legyen egy gomb, ezt a készítő “automatikusan” a stílus irányelveket figyelembe véve legjobb belátása szerint készíti el jól.
GDD jelentése
A GDD nem csak a kreatív folyamatot szolgálja, hanem nagyobb, “hivatalosabb” projektek esetén a vállalási szerződés sarokköve is.
A vállalási szerződés, pont úgy, mint bármely más iparban, itt is védi a megrendelő érdekeit.
Meglepő módon azonban nem csak az ügyfelet védi, hanem a fejlesztőt is. Nehéz lehet ezt elsőre elképzelni, de nagyon is jellemző, hogy a megrendelő a fejlesztési idő alatt rengeteg új ötlettel jelentkezik (“feature creep”). Normál esetben ezzel semmi gond nincs, hiszen senki sem jövőbelátó, sok lehetőség csak később fedi fel magát.
Ugyanakkor az is előfordulhat, hogy a fejlesztőnek későbbi időpontban le vannak már kötve a kapacitásai, ezért nem tud helyet szorítani az újonnan felmerülő fejlesztéseknek és a terebélyesedő munkaóra-igénynek.
Ilyenkor lehet a GDD-ben leírtakra szorítkozni, és az új igényeket későbbi frissítésekbe csoportosítani.
Összefoglalva az egész egyszerűen:
A GDD szükséges velejárója minden játékprojektnek. Ez az első, és nem túlzok, ha azt mondom, hogy az egyik legfontosabb lépése a készülődő projekt életének, mert a megvalósítás végig, a sok-sok hónapos fejlesztés során is ezen támaszkodik.
Várlak titeket további játékfejlesztéssel kapcsolatos cikkekkel hamarosan.
