Múlt héten rendeztük meg először a Kreatív Gamer Tábort a Nemesys irodában. 

A tábor 10-14 éves gyerekeknek szólt, akik szeretnek játszani, és meg akarnak ismerkedni egy játékfejlesztő cég mindennapjaival. Persze a húzóerő a sok jófej Youtube hős volt, vendégünk volt ugyanis Paplovag, Sirius és Bturbo is. 

A fiatalok sokféle program közül választhattak: első nap jómagam tartottam egy kis fejlesztő szakkört, ahol először bemutattam a játékfejlesztés folyamatát, majd megismerkedtünk a CodeCombat és a programozás rejtelmeivel.

Én nagyon bírom a CodeCombat-ot, mert játékos, RPG környezetben tanít programozni, és mindig azonnal lehet látni, amit csináltunk. Így sok benne a pozitív visszacsatolás, nem beszélve arról, amikor sikerül minden gonosz ogréval elbánni egy pályán, a csodálatos kódunknak köszönhetően. Természetesen az egész nagyon le van egyszerűsítve és maga a program is rengeteg segítséget ad, ha tudjuk, hol kell utána nézni. Ráadásul ingyenesen használható, és magyarul is elérhető, úgyhogy tényleg mindenkinek csak ajánlani tudom! 

Nekem nagyon jó élmény volt, mert szuper volt látni ahogy a srácok teljesen belemerülnek a munkába, kérdezgetik egymást, és együtt oldanak meg nehezebb pályákat. 

Miután meguntuk a CodeCombatot (és sokkal több pályát csináltunk meg, mint amire eredetileg számítottam), átnyargaltunk egy valódi játékfejlesztő szoftverre, a Construct 2-re. Ez nagyon egyszerű, ingyenes program, amiben jó sok előre legyártott egyszerű kis játéksablon megnyitható. Így a srácok ki tudták választani a számukra legszimpatikusabb játékot (autós, lövöldözős, flappy bird, platformer, stb.). Aztán pedig elkezdtük kicserélgetni a játékos karaktert, hátteret és játékelemeket: megtanultunk új asseteket integrálni és a régiek grafikáit lecserélni. Sok nagyon mókás játék született így, utólag már sajnálom, hogy nem csináltam róluk videót, de még lehet, hogy bepótolom! :) 

Aztán persze volt Overwatch orrvérzésig, ps4-ezés, kreatív Minecraft-olás, és még kincskeresés és focizás is az Orczy téren! 

Ha mindez nem lett volna elég, a gyerekek kipróbálhatták a HTC Vive-ot az InGame-ben. Szerintem ez egy nagyon nagy élmény, főleg hogyha valaki először próbálja - és természetesen a rengeteg játék közül most is mindenki megtalálta a kedvencét.

Úgyhogy szerintem jól telt ez az egy hét, és remélem az augusztusi turnus is hasonlóan jó élmény lesz nekünk is, és a gyerekeknek is! :) Ne felejtsétek, augusztus 21-25 jön a következő kör! 

Ha tetszett a cikk, olvasd el a többi témába vágó írást is, és keress fel Facebook-on, hogy ne maradj le semmiről! 

Úgy döntöttem, hogy nyitok egy olyan szekciót a blogon belül, ahol mindenféle játékfejlesztőknek meghirdetett pályázati- és megjelenési lehetőségeket mutatok be. 

Az első, ami pont mostanában jött velem szembe, a Microsoft indie fejlesztői pályázata, a Build.Dream.Play. 

Szabályok

A pályázatra bárki adhat be játékot, összesen négy kategóriában. Helyileg sincs megkötés, bármelyik országból érkezhet a projekt, azonban 7-nél több fő nem dolgozhat rajta (és mindenkinek nagykorúnak kell lenni). A pályázatokat év végéig lehet beadni. 

Kategóriák

Az első kategória, amit a legszívesebben látnak, az a felhő alapú játékok kategóriája. Itt akár 100.000 dollárnyi támogatást is lehet kapni, ami aztán jó sok pénz. Ezen kívül lehet beadni PC vagy konzol játékot, ami most már szinte hagyományosnak számít, ezeknél a kategóriáknál pedig 50.0000 illetve 25.0000 dollárnyi támogatást lehet bezsebelni. 

Az utolsó kategória a mixed reality játékoknak van fenntartva, nyilván azért, mert a Microsoft szeretne jó sok alkalmazást látni a saját Windows Mixed Reality-jén. 

A regisztráció június 27-én kezdődött, és 2018 március 20-án lesz eredményhirdetés. 

Mindenkinek jó versenyzést kívánok! 

Ha tetszett a cikk, olvasd el a többi témába vágó írást is, és keress fel Facebook-on, hogy ne maradj le semmiről! 

Mostanában azon pörgök, hogyan lehet igazán izgalmas puzzle játékot csinálni, aminek van témája, és mégis jól körülhatárolható mechanikákat használ fel. 

Hát mit mondjak, annyi game jam van mostanság, hogy nincs is időm megírni a beszámolót a régebbi jamekről! Nem gond, most végre billentyűhöz jutottam, úgyhogy gondoltam bemutatom, mit sikerült alkotni a Construct jamre, és mit tanultam belőle. 

Ugye, két hét volt a játékok elkészítésére. Igen ám, de ez egy bűvös időintervallum: soknak tűnik, az ember halogatja az egészet, dizájnolgat. Aztán a második hét kezdetén már érezni a szorongást, hát azért nekikezdünk már mégis. Rájövünk, hogy amit kitaláltunk az

• rettenetes
• nem tudjuk megcsinálni
• egy MMORPG. 

Hát, ez nálunk is kb. így nézett ki. Úgyhogy négy nappal a leadás előtt újradizájnoltuk az egészet, átgondoltuk - rengeteg veszekedés és orditozás közepette - hogy mi az, amit meg tudunk csinálni, van értelme foglalkozni vele, és kerek egész dolgot kaphatunk a végére. Így született meg a Beardy Adventures, aminek a veszekedés után már minden percét imádtam. Nagyon ritkán van olyan, hogy ennyire bele tudok mélyedni valamibe, hogy cseppet sem érzem munkának, és szinte pihenek, miközben dolgozom rajta. 

Azért is különleges projekt, mert a pályatervet, a game design-t és a programozást is én csináltam, és először volt olyan, hogy ennyi minden az én felelősségem egy projekten. Ezen kívül bevállaltam még az effektek és a hangok összerakását, mert eléggé graphic heavy lett az ötlet, így Petinek minden idejére szüksége volt. Emellett, én nem is tudom, hogy csinálta, de körülbelül három óra leforgása alatt két zenét írt a játékhoz, így lett külön menü- és játékzenénk is. Szerintem nagyon menő. 

A játék elkészítéséhez a Construct 3-at használtuk, ami tényleg nagyon hasznos cucc, de nem tud sokkal többet, mint az előző változata. Kényelmesebb, gyorsabb, de kb. ennyi. Ráadásul évi 30.000 Ft-ért akarják vesztegetni (a kettest csak egyszer kell megvenni), amit kicsit azért soknak tartok, de persze ki tudja. 

Az egész jamre amúgy borzasztó király játékok születtek, úgy látom volt, aki tényleg kihasználta a két hetet... de mindegy is, én már annak is örülök, hogy kész lettünk! A határidő előtt 20 perccel persze kiderült, hogy nem regisztráltunk még az oldalra, ami a fenének se akarta elküldeni a regisztrációhoz szükséges visszaigazoló e-mailt, úgyhogy pánikba estünk ahogy kell, de végül felkerült a projekt. 

Azt tapasztaltam, hogy bármennyire kevés az idő, érdemes elszöszölni egy kicsit az apróságokkal, legyen az egy particle effekt, vagy a hangok polisholása. Nagyon sokat hozzá tud adni az élményhez, és ebből látszik igazán, hogy az ember beleteszi az időt és energiát.

Legközelebb azért kisebbet álmodunk, és remélhetően több pályára marad majd időnk, de szerintem azért így is eléggé jót futottunk, és szuper büszke vagyok a Beardy Adventures-re! :)

Itt tudjátok kipróbálni, webes alkalmazásként, szóval még csak le sem kell tölteni ;)

Egy teljesen rendhagyó Game Jam zajlik. 

A Scirra stúdió, ami a Construct játékmotort készíti, jelenleg nagy átalakuláson megy át. Most nemrég jelent meg ugyanis a Construct 3, ami a motor legújabb változata. Éppen béta tesztelés alatt áll, ezért is döntöttek úgy, hogy meghirdetnek egy game jam-et, hogy minél többen kipróbálhassák ingyenesen az új verziót. A szoftvert még nem is lehet megvenni, úgyhogy tényleg igazi újdonságnak számít.

Pár információ a Construct 3-ról

A Construct szerintem az egyik legjobb játékmotor kezdőknek. Egyszerű, mert nem kell scriptelni hozzá, hanem előre legyártott kódblokkokból tudjuk összerakni a játék logikáját. Ezen kívül, mivel 2D-s motor, és rengeteg jó videó és dokumentáció van hozzá, ideális alap a játékfejlesztés iránt érdeklődőknek. Már sokszor említettem, hogy nekem is a Construct biztosította az első lépéseket, és ebben csináltam meg az első saját játékomat is. 

Talán a legnagyobb változás a kettes rész óta, hogy most már browser alapú lett a motor. Elég kényelmes használni, a legtöbb funkció ugyan úgy érhető el, mint a kettesben, viszont könnyebb kezelni a fájlokat és egyből lehet menteni Dropboxra. Ez megkönnyíti a munkát, főleg az ilyen kis projektek esetében, mint egy jam. Később, ha már volt időm mindent kitapasztalni, lehet írok egy részletesebb beszámolót is. 

A Game Jam-ről, röviden

Maga a jam 2 héten keresztül zajlik, most hétfőn kezdődött, és jövőhét végéig tart (május 15-28). Ezalatt a csapatoknak be kell fejezniük egy projektet. A téma pedig: a jó dolgok hármasával jönnek. Ezen kívül semmi megkötés nincs, az egyetlen lényeges dolog, hogy Construct 3-at kell használni az élkészítéséhez. A jam végén a Scirra kiválasztja a legjobb három csapatot, akik egy éven keresztül ingyen használhatják a Construct 3-at.

Természetesen, mint aktív Construct felhasználók, azonnal belevetettük magunkat a jamelésbe. Kitaláltunk egy kis point-and-click ötletet, aminek az első 1-3 pályáját szeretnénk megcsinálni, időnktől függően. Kíváncsi vagyok, mit tudunk kihozni a dologból, főleg azért, mert csak ketten csináljuk. Szerencsére a design már kész, és a prototípus is elég jól halad. A jövőhét az assetgyártás jegyében fog telni, szurkoljatok, hogy elkészüljünk vele! :) 

Majd mutatok in-progress képeket és videókat, remélem a kész játékot is meg tudom majd mutatni! Ha valakinek van kedve és egy kis ötlete, még bőven csatlakozhat. Hajrá mindenki! :)

Ha tetszett a cikk, olvasd el hasonló írást is, és kövess a Facebook-on, hogy ne maradj le semmiről! :) 

Mostanában sokat játszunk itthon platformer játékokkal, így egyre többet gondolkoztam azon, hogy egyes puzzle-ök, illetve pályák esetén mi a jó hozzáállás game design tekintetében. Érdemes úgy nehezíteni a feladványokat, hogy ne csak bonyolultabb, de időben is jóval hosszabbak legyenek? Mi a titka annak, hogy olyan feladatokat találjunk ki, amik egyre nehezednek, de még bele esnek a flow érzésbe, és a játékosok nem vágják földhöz a kontrollert és hagyják ott a játékot örökre? Hol van az a pont, ahol még szívesen bevállaljuk a nehezebb feladatokat, és hol van az, ahol már igazságtalanul nehéznek tartunk valamit? 

Igazából az Unravel kapcsán fogalmazódtak meg ezek a kérdések bennem, mert a játék végig nagyon vékony jégen táncolt nálam. Sokszor nem éreztem fairnek, hogy állandóan meghalok, sokszor a béna irányítás miatt eléggé frusztrált voltam, de mégis tovább akartam menni, mert volt az egészben valami flow érzés. 

Sok játék úgy próbálja meg nehezíteni a pályáit, hogy feleslegesen szívatja a játékost. Nyilván nehezebb lesz továbbjutni, de senki nem érzi igazságosnak, és ha sikerült is megoldani valamit, nem érezzük jobbnak magunkat tőle. Mi a titka azoknak a játékoknak amik ezt a problémát jól meg tudják oldani? 

Azt gondolom, hogy a titok abban rejlik, hogy a játékosnak aktív részesnek kell éreznie magát a feladványok megoldásában. Én akkor érzem magam frusztráltnak, ha úgy érzem, a játék dönti el helyettem, hogy mi legyen. Hogyha úgy gondolom, hogy nekem ki kéne találnom, hogy a szerintem rengeteg jónak tűnő megoldás közül mi az az egy, amire a designer éppen azt mondta otthon a pizsamájában, hogy oké. Ettől dühös és elégedetlen leszek, mert azt gondolom, hogy hiába gondolkozok különböző megoldásokon, ha nem vagyok gondolatolvasó, akkor nem fogok tudni továbbjutni. Így általában marad a vak találgatás, hátha egyszer csak megtalálom a megoldást. Nem azért, mert közöm van hozzá és kitalálom, hanem mert beleteszem azt a sok hosszú percet, hogy véletlenül rátaláljak a "helyes" megoldásra. 

Persze tudom, mennyire mókásnak tűnik, hogyha egy játékos felháborodik azon, hogy a játék dönt el helyette dolgokat. De ez így van. Designerként szerintem a legnagyobb feladat az, hogy jól hazudjunk, és el tudjuk hitetni a játékossal, hogy van döntési lehetősége, hogy amit ő szeretne, az igenis lehetséges és számít a játék keretein belül. Ehhez persze kell egy kis jóstehetség, aminek a titka az, hogy elérjük, hogy a játékos azt akarja csinálni, amit mi előre elterveztük neki. Akkor siklik félre minden, amikor a designer nem játékosként gondolkodik, mert ilyenkor az lesz a végeredmény, hogy a játékos nem tud olyan dolgokat csinálni amiket igazán szeretne, és úgy érzi, semmi köze ahhoz, hogy mi történik a játékban. Ami gyakorlatilag, csúnyán mondva, igaz is, de ezt jtáékosként sosem szabadna megérezni. 

Én személyesen nem játszottam vele, de sokáig néztem, ahogy a férjem küszködik a Little Nightmares című játékkal. Az például tökéletes példája a rossz design-nak. A feladványok többsége egyáltalán nem nagy kihívás, ha csak azt nem vesszük, hogy a 3D platformer elképzelés miatt sokszor egyáltalán nem látni a síkokat, így nem lehet tudni, hogy miközben simán előre megyünk, nem esünk-e le valahonnan. Nem látszik, hogy van vége egy platformnak, és hol kezdődik a következő, vagy hogy két dolog síkban van-e vagy térben el van tolva egymástól. Ez a 3D platformereknél sokszor előfordul, így a Little Nightmares készítőinek legnagyobb hibája, hogy ennek ellenére ügyességi játékot csináltak belőle, és figyelembe sem vették a játékos fursztrációját, amikor saját hibáján kívül állandóan meg kell halnia. Így aztán végeredményképpen a játék feladványai egyáltalán nem gondolkodósak, hanem próbálgatósak - mintha nem is rajtunk múlna, hogy sikerül-e vagy sem. 

Ezzel szemben a jó design szerintem az, amikor a játékos tanulni tud a hibáiból, rá tud jönni arra, hogy mi az ami működik az adott játék keretein belül. Lehet hogy sokszor elrontja, akár meg is hal, de minden kudarc után tudja, mit kell jobban csinálnia legközelebb. 

Nagyon kíváncsi vagyok, hogy ki mit gondol erről, főleg mostanában, hogy a nagyon nehéz játékok, mint pl. a Bloodborne, ennyire sikeresek. Szerintetek mi a titkuk? 

Ha tetszett a cikk, olvasd el a többi játékfejlesztésről szóló írásomat is, és kövess Facebook-on, hogy ne maradj le semmiről! :) 

Kedden látogatóink érkeztek a Nemesys irodába: eljött hozzánk néhány lelkes diák, hogy a játékfejlesztésről tanuljanak, a megszerzett tudást pedig egy Erasmus projekt keretein belül fogják felhasználni. 

Nekem most éppen nagyon aktuális ez a kérdés, és a tanulási lehetőségek kapcsán úgy gondoltam, hasznos lenne egy teljes írást szentelni az online kurzusoknak. 

Korábban már írtam róluk, de csak nagyon érintőlegesen. Azóta azonban már elvégeztem egy game design kurzust, és most éppen egy programozóit csinálok. Úgyhogy arra gondoltam, hogy kicsit bővebben is mesélek errről, hátha valaki másnak is megjön a kedve. 

Szóval a helyzet az, hogy Magyarországon borzasztó kevés a tanulási lehetőség játékfejlesztéssel kapcsolatban. Van ugyan egy-két képzés, de specifikus, gyakorlati tudást nagyon kevés helyen lehet szerezni. Éppen ezért van hatalmas szerepe az online tanulásnak. Én sokáig csak tutorial-okat néztem, azonban egy pár hónapja felfedeztem a udemy-t és azóta teljesen rá vagyok kattanva. Mikor először szóltak róla, hogy akciósan vannak fent kurzusok, kicsit szkeptikus voltam, azóta azonban bevásároltam vagy hatot. Mindenképp érdemes néha rápillantani, mert a nagyobb játékfejlesztős kurzusok normál áron kb. 200 dollárba kerülnek, de vannak folyamatos leárazások. Én mindegyiket 15 dollárért vettem, és némelyik több mint 70 óra videóanyagot tartalmaz. Most éppen Unity-ben tanulok programozni, és nagyon tetszik a kurzus. Érthető, gyakorlati tudást ad, és 6 pici játék elkészítése alatt lehet megtanulni a C#-ot. Persze bevásároltam egy Unreal kurzust, egy 3D-set és még találtam egy ingyenes Photoshop-ról szólót is. Úgyhogy most már csak a legnehezebb van hátra: meg kell őket csinálni! :) És nyilván ez a legnehezebb része, és a legnagyobb buktatója is az online kurzusoknak. Hogy mindig magunknak kell időt találni rá, kitartani, megcsinálni őket. Szerencsére a játékfejlesztésben az önnáló tanulás és problémamegoldás elengedhetetlen követelmény, így kicsit talán könnyebb rávenni magunkat a tanulásra. 

Ha valakit esetleg érdekel, az ingyenes udemy kurzusok listáját itt átböngészheti. 

Én eddig csak egy kurzust fejeztem be, a game design kurzust, amit az edx-en csináltam. Az fixen öt hétig tartott, minden héten voltak olvasmányok, videók és tesztek. Érdekes volt a udemy-hez képest, mert sokkal inkább elméleti, akadémikus tudást adott. Nem voltak gyakorlati feladatok vagy a jól megszokott házi feladatok, hanem átfogó szemléletet próbált átadni. Mondjuk az előadót néha megcsapkodtam volna valamivel, mert elég unalmasan beszélt, de legalább érdekes dolgokat mondott. Az is nagyon jól jött, hogy hetekre le volt osztva a tananyag. Sokkal jobban lehet haladni, mint a teljesen saját időbeosztással. Így ugyanis tudom, hogy x mennyiségű munkát minden héten bele kell tennem. Ha hétközben nem csináltam meg, akkor ugrott a vasárnap esti mozi! A Udemy-n nincs ilyen, ott mindenki a saját tempójával halad, ami nálam azt jelenti, hogy néha ellustulom a tanulást.

Az edx-en egyébként ingyenesek a kurzusok, csak akkor kell fizetni, hogyha valaki hivatalosan is igazolni szeretné, hogy elvégezte. Én szerettem volna támogatni az oldalt, így kifizettem a kurzust, de ez nem kötelező. 

Miért szeretem ennyire az online kurzusokat? Ugyanezeket az információkat ingyenes tutorial-okból is meg tudnám szerezni. De sokszor az ember nem tudja, mi az, amit tudnia kellene. Jó az, hogyha valaki felülről átlátja a folyamatokat, és úgy tudja átadni a tudást, hogy minden fontos dolgot megemlít közben. Arról nem is beszélve, hogy egy kurzus megvétele nekem elképesztő motivációt ad. Igaz, hogy nem költöttem rá sokat, de ha már kifizettem, meg kell, hogy csináljam! Ráadásul mindig látom, hogy épp hol tartok, mennyi van hátra, és a tesztek alatt is előjön a versenyszellem, hogy minél jobban teljesítsek. 

Ha befejeztem a C# kurzust, majd kiteszem a csodálatos játékokat, amiket csináltam közben. Egyelőre 35%-nál járok, úgyhogy azért erre még várni kell... de addig is mindenkinek ajánlom, hogy körbenézzen, és kedvére válogasson a kurzusok között! A legtöbbhöz semmilyen alaptudás nem szükséges, úgyhogy bátran elkezdheti bárki :) 

Ha tetszett az írás, nézz szét a többi, tanulásról szóló írásom között is, és keress fel Facebookon, hogy sose maradj le semmiről! 

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! :)