Anna jelenleg concept artist-ként dolgozik egy játékfejlesztő cégnél. Már jópár éve van a szakmában, és lelkesen készít saját projekteket is. Minden érdekli, nem csak a grafika területei, és most mesél is nekünk karrierje alakulásáró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! :) 

Egyre jobban szeretem a prototípusokat. Azért, mert mindig segítenek átgondolni, mi fér bele egy projektbe, mi az ami működik a gyakorlatban is, és melyik az a része a design-nak, ami javításra szorul. 

Nem lehet eleget hangsúlyozni mennyire fontos, hogy minél hamarabb ki tudjuk próbálni a játékunkat. Első pillantásra úgy lenne logikus a folyamat, hogy az ember kitalálja mit szeretne, megtervezi, aztán elkészíti. A legtöbb iparágban így is történik a dolog, de a játékfejlesztés nem ilyen. Ezért is szentelnék egy egész bejegyzést a prototípusok és az iterálás fontosságának. 

A játékfejlesztésben a viszonylag hosszú tervezési folyamat alatt a designer pontosan megtervez mindent: mechanikát, interakciót, játékélményt. Ami azonban elméletben működik, a gyakorlatban sokszor egyáltalán nem. Erre pedig nem érdemes akkor rájönni, mikor már rengeteg erőforrást beleöltünk a projektbe, ezért arra érdemes törekedni, hogy már jó előre ki tudjuk próbálni, működni fog-e az elképzelésünk. Ez plusz munkának, így plusz ráfordított időnek tűnik, és valóban az is, viszont nagyon megéri. Már csak azért is, mert először ki tudjuk próbálni az alapmechanikákat, ami alapján rengeteg új, akár sokkal jobban passzoló ötlet is eszünkbe juthat. 

Mi a prototípus, és mikor érdemes először nekivágni? 

A prototípus a játék valamelyik alap működési rendszerét tartalmazza, általában tesztelés céljából készül, és sokszor inkább a mechanikákra koncentrál. Rengeteg féle prototípus létezik, ezeket csak az különbözteti meg, hogy milyen célból készülnek. Azonban egy biztos: minden prototípust érdemes másokkal is leteszteltetni. Az, hogy a készítőnek mennyire jó élmény játszani a saját játékával, kevésbé reprezentatív. Hogyha azonban megkérjük közeli ismerőseinket akár, ők már friss szemmel tudnak ránézni az elkészült játékra, így sokkal több hasznos információt kaphatunk. 

A prototípus készítés optimálisan így épül fel: 

Először kitaláljuk, mit is szeretnénk látni a játékban. Ezt lebontjuk külön egységekre, amiket könnyen tesztelni tudunk. Tesztelés után átgondoljuk, melyik volt a legerősebb, és leggyengébb része a játékunknak. Mi az, ami kilógott a különböző egységek közötti interakcióból? Mi az, amit a legkevésbé élveztek a teszterek? 

A fejlesztés korai fázisában érdemes az alapmechanikákat minél hamarabb tesztelni, erre pedig remek módszer a prototípus, melyben a grafikai elemekkel egyáltalán nem kell törődni. Itt ki lehet próbálni a játék alap elgondolásait - játékos cselekedeteket, az egyes rendszerek működését, illetve interakcióját. 

Sokszor csak egyetlen, kérdéses működést emelnek ki a fejlesztők a játékkörnyezetből, és azt próbálják ki, hogy mit lehet belőle kihozni. Erre is remek eszköz lehet a prototípus, hiszen nem kell az egész játékba belenyúlni azért, hogy egyetlen mechanikát kipróbáljunk. 

Hogyan csináljuk? 

Most éppen benne vagyok egy game design kurzusban, és a mostani hét anyaga a prototípus volt. Sokat olvastam arról, hogy miért érdemes papír alapú prototípusokat csinálni. Megmondom őszintén, hogy az elején egy kicsit tartózkodtam az ötlettől, mert esetlennek, feleslegesnek találtam. De aztán sokat gondolkoztam, és a tények meggyőztek. 

A papír alapú prototípus esetében ugyanis teljesen el kell vonatkoztatni a videojátékok nyújtotta romantikus elképzeléstől. Ilyenkor teljesen lecsupaszítva látjuk magunk előtt a játékot, a maga egyszerű interakcióival, mindenféle sallang nélkül. Ez nehéz, mert ilyenkor olyan kis egyszerűnek tűnik. De ha pár papírdarabbal, kockával és bábuval meg tudjuk oldani, hogy fun legyen játszani a játékkal, akkor olyan pontra értünk el, ahonnan már nincs lehetetlen. 

A papír másik nagy előnye, hogy gyorsan és olcsón tudunk vele dolgozni. Nem kell hozzá programozónak lenni, nem kell placeholder grafikákat keresgélni. Egyszerűen csak le kell ülni, át kell gondolni mit is szeretnénk, és meg kell csinálni. 

Persze nem minden játékot lehet kipróbálni papír alapon, úgyhogy érdemes átgondolni, mi a legmegfelelőbb módszer. 

Egy ponton mindenképp át kell térni a digitális prototípusra. Újabb fájó pont, és sokáig nem is akartam megfogadni, hogy az első digitális prototípust nem szabad megtartani. Az egy külön projekt, amiből aztán semmi nem kerül át a végleges játékba. Ez azért nagyon fontos, mert így a prototípus készítése során nem kell előre gondolkozni a kódstruktúrán, nem kell elegáns dolgokat létrehozni. Be kell dobálni mindent, hogy az alap mechanikákat ki tudjuk próbálni. Ha ezek működnek, akkor bizony újra kell kezdeni az egészet, immár odafigyelve a részletekre, és nem toldozva-foldozva építkezni egy régi prototípus alapjaiból kiindulva. 

Miért jó ez? 

A prototípus fő erénye, hogy gyors és hogy képesek vagyunk iterálni. Mivel ez egy egyszerű, nem végleges dolog, a változtatások kis költséggel megoldhatók. 

A változtatás mindig fájdalmas, de nélkülözhetetlen a játékfejlesztésben. Az iterálás néha szitokszóvá válik a fejlesztés alatt, hiszen senki sem szereti kidobni, vagy tizedszer megváltoztatni azt, amit már elkészített. De muszáj. Akkor lesz jó valami, ha folyamatosan teszteljük, és folyamatosan alakítgatunk rajta, amíg tökéletesen együtt nem működik a játék többi elemével. Lehet valami önállóan tökéletes, hogyha nem ad hozzá a játék egészéhez, vagy nem épül bele szervesen a struktúrájába, akkor bizony mennie kell. A prototípus erre is nagyon hasznos: meg tudjuk nézni, mi az ami működni fog, és emiatt érdemes több energiát szánni a tökéletesítésére. Így nem megy el felesleges energia olyan dolgokra, amiket a végén csak azért tartunk meg, mert rengeteget dolgoztunk vele. 

A végére pedig: 

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

Ha valaki eldöntötte, hogy játékot szeretne csinálni, nincs is más dolga, mint leülni, és elkezdeni. Ez milyen egyszerűen hangzik, nem igaz? 

Azonban a döntéshozatal után sokszor nem tudjuk, mi legyen a következő lépés. Ez az írás segítséget szeretne adni ahhoz, hogy valaki nulláról elkezdjen egy játékfejlesztési projektet. Sorra fogom venni a fejlesztés stádiumait, és kiemelem mindegyiknél a lényeges pontokat. 

1. Tervezési fázis

Ahhoz, hogy elinduljon egy fejlesztés, a legfontosabb alapkő az ötlet. Az ötletelés általában azzal kezdődik, hogy a csapat nagyon szeretne valamilyen játékot csinálni (például így: "miért nem csinálunk egy platform játékot, olyat mint a Spelunky, csak nem nagyorrú emberrel vagyunk hanem egy csibével, akinek a szeméből lézer jön ki?"). Ezután következik, hogy az alapötletet kicsit kibontja a csapat, és elhatározza, hogy a platform játéknak noir-hangulatú grafikát szeretne és Steam-re fogják kiadni. Ez már egy elég erős alap arra, hogy elkezdődjön a konkrétabb ötletelés, a brainstorming (amiről majd a következő részben sokkal részletesebben fogok írni). 

A fenti példában feltételeztem, hogy a csapat adott, de ez sokszor nincs így. A tervezési fázis arról is szól az ötlet kitalálása mellett, hogy a projekthez szükséges csapat összeálljon. Ez a projekt méretétől is függ, de hozzávetőlegesen minimum 5 fővel kell számolni (programozó, grafikus, designer, hang/zene tervező és animátor). Általában azért ennél több ember vesz részt egy fejlesztésben, és ezeket mind meg kell győzni, hogy részesei legyenek a csapatnak. Nem árt, hogyha valaki ért a marketinghez és a kommunikációhoz, hiszen a játék elkészítése után ezek nagyon fontos szempontok lesznek, de erről majd később. 

Ha kialakult az ötlet, és megvan a csapat, akkor jöhet egy projektterv, amelyben már részletesebben ki kell fejteni, hogy milyen mechanikák lesznek a játékban, ehhez milyen erőforrások kellenek, és mennyi idő lesz elkészíteni.

Érdemes írni egy pitch-et is, amire főleg akkor van szükség, hogyha befektetőt, vagy kiadót keres a csapat. A pitch egy nagyon rövid összefoglaló arról, hogy miről szól a játék, milyen egyedi mechanikák vannak benne, kinek szól, és milyen más, már megjelent játékokkal fog majd versenyezni a piacon. Ezekről a dokumentumokról is írni fogok bővebben a következő részben. 

A tervezési fázis alatt figyelembe kell venni, hogy milyen platformra készül a játék, hiszen ez nemcsak a bevételeket, de magát a design-t is nagyban befolyásolni fogja. 

2. Pre-produkciós fázis

 Ennek a fázisnak a legfontosabb célja, hogy kiderítse a csapat, tényleg működik-e amit kitaláltak. Ehhez minél hamarabb érdemes elkezdeni prototípusokat gyártani, amiben ki lehet próbálni az alapmechanikákat. Azt szokták mondani, hogyha szürke dobozokkal, és csak az alap működésekkel jól el lehet játszani, akkor már nem lehet baj. Szóval ennek a fázisnak a célja, hogy kialakuljon a végső design, meglegyenek a játékos cselekedetek (player actions), és az alapvető játékszabályok. 

Itt már érdemes készíteni egy részletes design dokumentumot, amiben az egész játékmenet le van írva, és amit folyamatosan lehet bővíteni és változtatni a prototípusok készítése során. Ebben a fázisban az alapvető, nagy változtatásoknak meg kell történnie - tehát addig kell tesztelni, amíg ki nem alakulnak a keretek. 

Hogyha a kiadó vagy befektető igényli, ebben a fázisban el kell készíteni egy úgynevezett vertical slice-t is, ami annyit tesz, hogy ki kell választani egy pályát amiben már nagyjából minden feature benne van, és el kell készíteni végleges grafikával. Ez segít a döntéshozóknak abban, hogy lássák milyen lesz a játékélmény, és hogyan fog kinézni a végleges termék. A vertical slice sokszor a csapatnak is segítség, hiszen alaposan át kell gondolni a design döntéseket az elkészítéséhez. 

Nem szabad elfelejteni, hogy a befektető nem játékfejlesztő, tehát nehezen tud elvonatkoztatni, mikor találkozik egy prototípussal. A vertical slice pedig nagy segítség, mert így a befektetőnek nem szürke dobozok alapján kell megítélnie egy játékot, hanem látja annak végleges grafikáját és hangulatát. Ez a csapatnak is segítség lehet, hogyha el akarnak adni egy projektet. 

3. Gyártás

Ez a fázis a leghosszabb, és akkor indul el, amikor már a nagy döntések megszülettek, és mindenki tudja mit kell csinálnia, mennyi idő alatt. Itt már nem történnek nagyobb változtatások, hiszen ki van próbálva minden mechanika.

A gyártási fázis elején elkészülnek a részletes conceptek, ami alapján a grafikusok legyártják a szükséges asseteket, a programozók pedig ezzel párhuzamosan életre hívják a játékmenetet. Szép lassan elkészül a játék, bekerülnek a hangok és a menü.

Azt gondolom, hogy erről a fázisról lehetne a legtöbbet beszélni, de ez a leginkább kézzelfogható, és erről található a legtöbb információ a könyvekben és az interneten is. 

4. Karbantartás

Amikor pedig minden készen áll, jöhet a kiadás! 

Persze itt koránt sem ért véget a dolog. A kiadás maga is lehet hosszabb folyamat, mint például konzolos játékok esetén (főleg első alkalommal), de ezután sem érdemes elengedni a játékot. Attól ugyanis, hogy kint van egy játék a piacon, még nem biztos, hogy megtalálják a játékosok. 

Sok kisebb csapat ezért szokott kiadót vagy befektetőt keresni, mert így biztosítva van a marketingje a játéknak. Ez persze nem szükségszerű, hogyha van egy ember a csapatban, aki ért ehhez. Azonban a marketing mellett szükség lesz majd grafikai assetekre a megjelenési felületekhez, valamint folyamatosan új tartalomra, hogy fent lehessen tartani a potenciális érdeklődők figyelmét, és be lehessen kerülni különböző időszakos ajánlatokba. 

Ehhez a fázishoz nem értek igazán, és csak azért említettem meg, mert úgy gondolom, hogy legtöbbször a fejlesztők csak a játék elkészítéséig terveznek. Ennek ellenére egyre inkább azt látom, és a konferenciás előadások is ezt támasztják alá, hogy a játék elkészülte után is komoly munkába kerül, hogy a projekt utóélete sikeres maradjon, úgyhogy minden platformon érdemes utánanézni a lehetőségeknek.

+1 Tesztelés, tesztelés, tesztelés!

Ezt hagytam a legvégére, mert rájöttem, hogy nem tudom berangsorolni, mert a fejlesztés minden pontján elengedhetetlen.

Már a legelső prototípust is érdemes tesztelni, hiszen sok értékes feedback jöhet, és itt még a változtatás ára viszonylag kicsi. Sokszor maguk a fejlesztők nem látnak rá friss szemmel a projektre, talán nem is tűnnek fel számukra olyan dolgok, amik kívülállóknak egyből szemet szúrnak.

Persze a fejlesztés első fázisaiban nehéz a tesztelés, mert sokan nem tudnak elvonatkoztatni a szürke dobozoktól és a hiányzó mechanikáktól. Ezért is nagyon hasznosak a meetup-ok és game jam-ek, mert ilyenkor meg lehet keresni játékfejlesztő kollegákat, és meg lehet kérni őket, hogy teszteljék a játékot. Ők már biztosan hozzá vannak szokva a dologhoz, és el tudnak tekinteni a játék kezdetleges stádiumától. 

Viszont nem szabad elfeledkezni a játékosokról sem, akik a végső felhasználói lesznek a játéknak. Ahogy halad előre a projekt, egyre nagyobb szerepet kap a play testing. A játékosok reakciói rengeteg minden elárulnak a fejlesztőknek, ezért nagyon fontos, hogy jelen legyen a csapat legalább egy tagja a tesztelés alatt. Érdemes jegyzeteket készíteni, és kérdéseket feltenni a tesztalkalom végén. Fontos, hogy a készítők ne vegyék magukra a kritikákat, ez a fázis arról szól, hogy megfontolhassák, átgondolhassák a tesztelők véleményét. Nyilván lesz olyan tanács, amit nem fogad meg a csapat, de valószínűleg sokkal több olyan javaslat lesz, amitől szignifikánsan javul majd a játékélmény. 

Nagyjából így épül fel egy fejlesztés, persze minden csapat és munkahely kicsit másképp fejleszt, így univerzális igazságok (sajnos) ebben a témába sincsenek. Azonban hogyha valaki saját magától szeretne nekilátni egy játéknak, akkor a fenti struktúra úgy gondolom segítség lehet, kiindulási alapot nyújthat. 

A következő részben a brainstormról és a különböző tervezési dokumentumokról fogok bővebben írni. 

Hogyha tetszett a cikk, olvasd el a többi, fejlesztésről szóló írásomat, és keresd fel Facebook oldalam, ahol folyamatosan friss információk és érdekességek várnak! 

Szorosan a tanuláshoz és fejlődéshez kapcsolódik, ezért a gamejam és meetup témakörével folytatom a sorozatot.

Azt gondolom, hogy aki játékfejlesztő (vagy az szeretne lenni), nem hagyhatja ki egyiket sem. Amellett, hogy szakmailag rengeteget lehet fejlődni ezeken az eseményeken, alkalmasak arra is, hogy megismerjük egymást, segítsünk egymásnak, és persze hogy jól érezzük magunkat.

Mi az a meetup? 

A meetup nagyon egyszerűen csak annyit jelent, hogy időről időre összeülünk mi, játékfejlesztők. Általában van egy-két előadás is, ami mindig egy adott téma köré épül. Ezután kötetlen beszélgetés veszi kezdetét, és aki szeretné, megmutathatja a projektet, amin éppen dolgozik. Ez általában garázsprojekteket jelent, de vannak olyan találkozók, amikor céges játékokat is hoznak. Ilyenkor akinek van kedve, ki tudja próbálni a projektet, és el tudja mondani a véleményét. Ez nagy segítség a fejlesztőknek, hiszen hasznos szakmai inputot kapnak a projektről, amit később be tudnak építeni a fejlesztésbe. De hasznos a tesztereknek is, mert sok jó megoldással találkozhatnak, és képbe kerülhetnek azzal kapcsolatban, hogy milyen projekteken dolgoznak a többiek.

A meetup arra is nagyon jó, hogy nyomon tudjuk követni az iparban résztvevők fejlődését, meg tudjuk ismeri azokat, akik még játékfejlesztésben dolgoznak. Szerencsére egyre több tematikus meetup van, vegyük példának a VR / AR meetupot, ami nemrég indult, de egy szuper kezdeményezésnek tartom. 

A meetup azért jó, mert ugyan megadott időpontban van, de abszolút nyitott és kötetlen esemény. Mindenki azért jön, hogy jót beszélgessen egy ital mellett, és jól érezze magát. Hozzátenném, hogy a mostani állásomat is egy meetup-nak és gamejam-nek köszönhetem, úgyhogy komolyan mondom, hogy érdemes eljönni! :) 

Na de mi az a gamejam?

Egy gamejam általában egy hétvégén át tart (kb. 72 óra). Ezalatt a jelentkező fejlesztők összegyűlnek, csapatokat alkotnak, és egy megadott témában játékokat csinálnak.

Mire jó ez?

Megszámlálhatatlan előnye van egy jamnek, például az, hogy kötetlenül lehet fejleszteni. Nincs semmilyen megkötés, mindenki a számára legjobban tetsző ötleten dolgozhat, megvalósíthatja legjobb tudása szerint az elgondolásait.

Emellett 72 óra alatt elkészül egy játék, ami baromi nagy szó, és játékfejlesztőként igencsak jó önbizalomnövelő. Ráadásul a jamek alatt rengeteget lehet tanulni - mint jól tudjuk minden projekt során felmerülnek "megoldhatatlan" problémák, amiket nagyon gyorsan meg kell oldani, mivel nagyon kevés az idő.

Plusz, meg tudjuk ismerni az iparban dolgozókat és munkamódszereiket, valamint kipróbálhatjuk magunkat olyan területeken, amit a munkánk során nincs lehetőségünk gyakorolni. 

Hogyan zajlik? 

A jamek általában péntek este kezdődnek, amikor kihirdetik a témát. A téma bármi lehet: egy szó, idézet, játékmechanikai megkötés. A lényeg, hogy e köré kell kitalálni a játékötletet. 

A következő lépés az ötletelés. Miután kiderült a téma, jöhet a brainstorm. Mi általában egy hatalmas táblára / kivetítőre szoktuk felírni ezeket az ötleteket: jöhet bármi, mindenki ötlete felkerül. Ezután szavazunk az ötletekre. Ez nem kötelező lépés, de nagyban segíti a csapatalkotást, hiszen egyből kiderül, melyik ötlet nyerte el leginkább a résztvevők tetszését, és ez alapjául szolgálhat annak, hogy kik kerüljenek egy csapatba. Persze fontos az is, hogy minden csapatban legyen programozó, grafikus, dizájner, de a tagok száma és a csoport összetétele teljesen a résztvevőkön múlik. Akár már korábban is összeállhat egy csapat, és saját magukban ötletelhetnek, az is teljesen rendben van. A gamejam nagy előnye, hogy teljesen nyitott, mindenki úgy navigálja a projektjét, ahogy neki kényelmes. 

Ha megvannak a játékötletek, és összeálltak a csapatok, nincs más hátra, mint maga a
fejlesztés. Minden csapat magának osztja be, hogy milyen időbeosztással szeretne dolgozni, a lényeg, hogy kész legyen a projekt 72 óra alatt. Ha valaki éjszaka szeretne fejleszteni, lelke rajta, a helyszínt adó iroda általában egész idő alatt nyitva áll. 

A két leghíresebb jam:

1 Global Game Jam - évente kerül megrendezésre, a legismertebb nemzetközi jam. Akit érdekel, annak jó hírrel szolgálhatok: most lesz januárban (20-22) a következő, remélhetőleg a Nemesys irodában. 

2  Ludum Dare - háromhavonta rendezik meg, szintén nemzetközi jam. Bárki jelentkezhet rá több kategóriában. A legközelebbi decemberben lesz - érdemes nyomon követni online. Általában ez is a Nemesys irodában szokott lenni, de most decemberben nem tartjuk meg, mert vadul készülünk a Global Game Jam-re :) 

Ezeken kívül szoktak lenni engine-hez kötött jamek, amit maga a fejlesztő cég szervez, pl. Unreal jam. Ez jó alkalom arra, hogy jobban megismerjük az adott fejlesztési környezetet, és esetenként még ajándékokat is nyerhetünk. 

Az eddig felsorolt jamek nemzetközi szervezésűek voltak. Van néha lokális, magyar jamelés is, ez azonban a ritkább, és általában úgy valósul meg, hogy néhány fejlesztő kedvet kap a közös munkához, összebeszélnek és egy hétvégét játékkészítésre szánnak. 

A tematikus jamek is ritkábbak, de érdemes őket megemlíteni. Ilyen volt a nemrég megszervezett lengyel-magyar game jam, amelynek során az 1956-os események témájában kellett játékot csinálni. Ezek szerintem fontos és izgalmas kihívások, így érdemes rajtuk részt venni. 

Remélem sokaknak meghoztam a kedvét, ha bárkit érdekel bővebben a meetup vagy a jam, esetleg részleteket szeretne tudni arról hogy mikor / hol lesznek a következő alkalmak, írjon nyugodtan, mindenre válaszolok! :) 

Ha tetszett a cikk, olvasd el a többi játékfejlesztésről és eseményekről szóló bejegyzésemet is, vagy keresd fel Facebook oldalamat, ahol mindig értesülhetsz a magyar játékfejlesztést érintő eseményekről! 

Mivel nagyon sokan megkerestetek azzal, hogy szívesen olvasnátok, tanulnátok a játékfejlesztésről, ezért előre vettem a tanulási lehetőségekről szóló részt.  

Egyrészt nagyon örülök, hogy ennyi embert érdekel ez a dolog, másrészt jó lenne, hogyha lenne egy lista, ami segítséget tud nyújtani a kezdetekhez. 

A helyzet az, hogy elkezdtem ebben a cikkben összeszedni azt, hogy mit és hol érdemes tanulni illetve milyen programokat érdemes kipróbálni. A lista már most akkora, hogy nem látom értelmét egyetlen cikkbe belezsúfolni, ami aztán elveszik valahol a blog múltjában. Inkább úgy döntöttem, nyitok ennek egy állandó alfület a blog szekciói között, így mindig szem előtt lesz. 

Ennek ellenére szeretném hangsúlyozni, hogy ez egy személyes blog, tehát nem lesznek itt örök érvényű igazságok, a saját tapasztalataimról írok, és a saját szűrőmön keresztül látok mindent, így a játékfejlesztést is. Nyilván külföldön, és sok cégnél itthon is másképp működnek a dolgok. Az is előfordulhat, hogy valaki más könyveket olvasott és máshonnan szedte fel az információt, én csak arról írok, amit én ismerek. Viszont ha valaki esetleg ki tudja bővíteni a listát, mindenképp jelezze majd kommentben, mert akkor folyamatosan hozzáadom az új információkat! Tényleg szeretném, hogyha egy jó kis útmutató összejönne, ami segíti az önálló tanulást és fejlődést mindenkinek. 

Szóval megnyitom majd az oldalt, és igyekszem minél több mindent kitenni oda. Ezt a cikket pedig annak szentelem, hogy a hazai lehetőségeket áttekintsem és bemutassam a különböző programokat, amiket én is használok. 

Kezdetek

Sok ember már úgy kezd neki a tanulásnak, hogy tudja mi érdekli, és mivel szeretne később foglalkozni. Ez nagyon szerencsés eset, hiszen céltudatosan rá tud keresni. Viszont rengeteg ember van - köztük én is ide tartoztam - aki nem tudta előre, hogy mivel akar majd foglalkozni, vagy esetleg érdekli minden terület. Alapvető tájékozódásnak ajánlom a jatekfejlesztes.hu weboldalt, ahol már eleve sok információ össze van szedve az iparral kapcsolatban, és fórum is működik. 

Először lássuk a nagyobb egységeket - a teljesség igénye nélkül, majd a motorokat, és hogy melyikkel érdemes belevágni a fejlesztésbe. 

1. grafika

2D

Ezen a téren szerencsére elég nagy a képzéskínálat is (lásd MOME, vagy akár magántanárok). Nem tudom, hogy itt mennyire lehet számítógépes grafikát tanulni, de az biztos, hogy művészetileg borzasztó nagy előny, hogyha valakinek már csak a technológiát kell elsajátítani. 

Ha valaki grafikusként szeretne részt venni a fejlesztésben, a Photoshop szerintem elengedhetetlen. De emellett érdemes kipróbálni ingyenes szoftvereket is, mint pl.a GIMP, vagy az Inkscape (ami vektoros). Én az első saját játékomhoz az Inkscape-et használtam, és szerintem nagyon kezes kis program, úgyhogy bátran ajánlom mindenkinek. 

Ha valakit érdekel a grafika, a ctrlpaint oldalt ajánlanám. Van ingyenes és fizetős része, nagyon alapos és elméleti-gyakorlati tudást egyaránt biztosít (Photoshop használatot is lefedi). 

3D 

Max és Maya a két piacvezető, de próbának megéri kipróbálni az ingyenes Blendert. Ha valakit nem kifejezetten a 3D érdekel, de szeretne asseteket összerakni egy játékhoz, azt esetenként játékfejlesztő engine-ben is meg tudja oldani. A CryEngine-nek például remek modellező része van, egyszerűbb asseteket gond nélkül össze lehet benne rakni. 

2. Design

A design talán a legnehezebben megfogható terület. Sokan szeretnének designerek lenni, mert azt gondolják ehhez nem kell semmiféle speciális tudás (se jól rajzolni, se programozni nem szükséges hozzá). Ez azonban nem igaz, ugyanis egy designernek minden területhez folyamatosan alkalmazkodnia kell. Át kell látnia az egész játékot, és a sok kis részből élményt kell faragnia, ami nagyon nehéz feladat, hiszen nincs kész recept hozzá.

Magyarországon a game design még nagyon gyerekcipőben jár, annak ellenére, hogy a BME elindította a játéktervező- és elemző szakot (amiről sok diáknak kifejezetten negatív véleménye van). Szerintem szuper, hogy már van hivatalos képzés ezen a területen is, mert valahol el kell kezdeni a játékfejlesztés területeinek oktatását, és remélem, hogy a jövőben összerántják a srácok a szakot. 

Azoknak, akik designerek szeretnének lenni, ajánlom majd a tudástár design szekcióját, mert több alapos és jó könyv van a piacon, amiből én is tanultam és csak ajánlani tudom. A másik jó taktika: minél több játékot csinálni. El kell fogadni, hogy az első pár bizony gagyi lesz, de mindegyik után érezhető lesz a fejlődés. Én ezért örülök neki, hogy végül megtanultam a játékfejlesztés minden területét alap szinten, mert így nem esik nehezemre összedobni egy 2D-s játékot, és közben designerként iszonyatosan gyorsan tudok fejlődni - hiszen ki tudom próbálni, hogy mi működik és mi nem. 

3. programozás

Sokféle egyetemi képzés áll rendelkezésre, ezeket nagyrészt hasznosítani is lehet a későbbiekben (pl. szoftverfejlesztő vagy programozó matematikus szakok). Leginkább a C# és C++ tudás a hasznosítható a játékfejlesztésben - tapasztalataim szerint. 

A programozás különleges helyzetben van, főleg hogyha egy fejlesztő motorban kell dolgozni, ott ugyanis a keretrendszer már adott. Ez könnyíti is a dolgot, mivel sok minden már készre van csinálva, viszont meg is tudja nehezíteni, mert a merev kereteken belül kell megoldani a felmerülő problémákat.

Én azt gondolom - és meleg szívvel ajánlom mindenkinek, nem csak programozóknak - hogy mindenki akit érdekel a fejlesztés, kezdjen el játékfejlesztő motorokat tanulmányozni. Ezzel nagyon sokat lehet tanulni, és később nagy haszna lehet - ráadásul mindegyik elérhető ingyenesen, maximum akkor kell fizetni, amikor már kint van egy projekt és eladásokat produkál. 

Na de milyen motort érdemes választani? A választék egyre bővül, ezért erre koránt sem olyan egyszerű a válasz. 

Fejlesztő engine-ek

Ha valaki 2D-s játékot szeretne csinálni, és esetleg a programozás sem annyira megy neki, nagyon ajánlom a Construct nevű programot. Ennek is van ingyenes verziója, de a fizetős sem túl drága. Én ezzel kezdtem a pályafutásom, és igen megszerettem. Gamejam-ek alkalmával még mindig szívesen veszem elő, mert egyedül is tudom vállalni a kód részét, pedig nem vagyok programozó (azért szeretnék az is lenni). 

3D-s projektekre ott van a szent triumvirátus: Unity, Unreal, CryEngine. Itt bele lehetne menni a komolyabb összehasonlításba, de az nagyon hosszú és unalmas lenne. Azt gondolom (személyes vélemény következik) hogy a Unity nagyon felhasználóbarát, és rengeteg oktatóanyag és dokumentáció elérhető hozzá ingyen. Az Unreal-ben rettenetesen szép dolgokat lehet alkotni, és ráadásul van visual scripting is benne - bár kicsit túl van bonyolítva, de legalább nem kell konkrétan programozni benne, ha valakit ez esetleg megrémít. A CryEngine nagyon jó nagy külső terek építésére, szuper level design tool-ok érhetőek el, viszont a dokumentáció nem teljes körű, a UI pedig egy rémálom. Én mindegyiket kipróbáltam már, megvan mindnek az előnye és a hátránya is. Ezeken kívül is vannak lehetőségek, de egyrészt azokat nem ismerem annyira, másrészt nem találkoztam még olyan céggel, ahol ezeken kívül más felmerült volna, hogyha külső engine-nel dolgoznak. De ha valakinek van másról tudomása, az ossza meg hogy ki tudjam bővíteni ezt a szekciót! :)

Ennyit terveztem erre a részre. Tudom, hogy sok részterület kimaradt (pl. játékíró, vagy animátor), de a tudástárban ezekhez is lesznek segédanyagok. 

Búcsúzásképpen pedig egy kis jó tanács: 

 Ha tetszett a cikk, vagy érdekel a játékfejlesztés, el tudod olvasni a többi cikket is a témában itt! 

Csatlakozz a Facebook oldalamhoz, hogy értesülj a legújabb hírekről és információkról! 

A játékfejlesztős posztsorozat második részében a fejlesztés különböző területeit szeretném röviden körbejárni. Szó lesz arról, hogy milyen szakemberek szükségesek egy játék elkészítéséhez, és arról is, hogy mennyire fontos a projekt mérete a fejlesztés szempontjából.

A játékfejlesztés egy olyan iparág, amiben nagyon sokféle szakma és még többféle ember dolgozik együtt. Éppen ezért sokaknak nem átlátható a fejlesztési folyamat, valamint az sem mindig egyértelmű, hogy pontosan mi kell egy sikeres projekthez. 

Részterületek

Egy játék négy területre bontható, legalábbis Jesse Schell szerint, rá pedig általában hallgatunk. Ez a négy terület pedig:

1. esztétika
Egy játék kinézete, hangulata, vizuális egysége. Ide tartoznak a hangok, animációk és zenék is, minden, amitől kellemes lesz egy játék. 

2. mechanika
A mechanika a játék alapját képezi. Magába foglalja a szabályokat, a lehetséges játékos cselekedeteket, és a játékvilág működését. 

3. technológia
A technológia azt a platformot jelöli, amin a játék működik. Ez befolyásol nagyon sok dolgot: felbontást, irányítást, kényelmi szempontokat (gondoljunk csak a PC és konzol közötti hatalmas élménybeli különbségre).

4. narratíva
A narratíva nem csak a szigorúan vett történetre vonatkozik, hanem jelenthet egy olyan premisszát is (előfeltevést), mint a Monopoly esetében az, hogy a játékvilágban minden játékos a gazdasági elit tagja, akik ingatlanokat fognak vásárolni a játék során, egymással versengve. 

Ahhoz, hogy ezek a részek tökéletesen ki legyenek dolgozva, szükség van 2D grafikusokra, akik megtervezik, hogy milyen legyen a hangulata a játéknak, és egyes tárgyak pontosan hogyan nézzenek ki (concept).

3D modellezőkre, akik ezek alapján elkészítik a modelleket, amik bekerülnek majd a játéktérbe.

Sokszor alkalmaznak külön animátorokat, akiknek a feladata, hogy mozgassák a 3D-s modelleket.

Szükség van továbbá programozókra, akik a játékteret működésre bírják, ők ültetik át gyakorlatba a szabályrendszert, és felelnek azért is, hogy hiba nélkül fusson a játék.

A fejlesztésen dolgoznak designerek, akik kitalálják a szabályokat, és összehozzák a négy területet egy nagy egységes élménnyé. Az ő feladatuk, hogy jó legyen a játékkal játszani, izgalmas és érthető legyen a szabályrendszer és az irányítás.

Általában dolgozik a fejlesztésen level designer, aki az egyes pályákat építi fel.

Általában a fejlesztés végén kerülnek be a hangok és a zene, amiért a sound designer a felelős.

Hogyha narratív játékról van szó, akkor szükség van írókra is, akik a történetért felelnek. 

A fentiekből kiderül, hogy a fejlesztés elég hosszú és összetett folyamat, aminek során minden részleg munkája egymásra épül. Így nagyon fontos a koordináció, hogy mindig meglegyenek azok az assetek, amik feltétlenül szükségesek a haladáshoz, és itt jön képbe a producer. 

Az, hogy egy cég hogyan épül fel, és hányan dolgoznak ott, nagyban befolyásolja a szerepeket. Jellemző, hogy kisebb cégeknél több szerep kerül egy emberhez. Én például a producerség mellett általában designerként is részt veszek a fejlesztésekben, azaz nem csak a munkafolyamatokat osztom be, hanem az én feladatom az is, hogy élmény váljon egy játékból.  

Nagyobb cégeknél pontosan körülhatárolt szerepkörök és feladatok vannak. Egy nagy fejlesztésnél elengedhetetlen, hogy legyen egy kreatív vezető, aki a vízióért felel (hogy pontosan az a hangulat és élmény valósuljon meg, amit a tervezési fázisban elképzeltek), és legyenek lead-ek (vezetők) minden területen, akik összehangolják az egyes részterületek munkáját. 

Minél nagyobb egy fejlesztés, annál jobban szét vannak bontva a részek és feladatok, emiatt a fenti felsorolásból sok szerep kimaradt. Hogyha valakit részletesebben is érdekel a téma, tudok ajánlani rengeteg jó cikket és könyvet, úgyhogy ne habozzatok megkeresni! :) 

Ha tetszett a cikk, olvasd el kapcsolódó írásaimat, és keresd fel Facebook oldalamat, ahol további érdekes információk és folyamatos hírek olvashatók! 

Ez egy bevezető írás, ami egy hosszabb posztsorozat első része, és azoknak szól, akiket érdekel a játékfejlesztés mint karrier, de nem tudják hogy mi is ez pontosan, és hol érdemes elkezdeni. 

"Szóval... Mi leszel ha nagy leszel?" Azt hiszem mindenki utálta ezt a kérdés gyerekkorában. Legalábbis én biztosan, mivel nagyon sokáig mindennel akartam foglalkozni.

Azt gondolom hogy egyre nehezebb választ adni erre kérdésre, mivel manapság már rengeteg út létezik, és a pályaváltás is elterjedt opció akár idősebb korban is. Egyes szakmák vonzóbbnak tűnnek most, mint régen, és szerintem a technológia és a játékfejlesztés is ilyen. Sokan menő és szexi szakmának tartják (amúgy az is) és azt gondolják simán bekerülnek, sokan félnek tőle, és bátortalanok ezzel kapcsolatban. 

A fejlesztésről általában

A játék egy nagyon új médium, ezért állandó és gyors fejlődésben van. Folyamatosan új trendek, új mechanikák alakulnak ki, a technológia eszméletlen ütemben változik, amivel a fejlesztéseknek is lépést kell tartani. Pont emiatt főleg Magyarországon, de úgy gondolom hogy egyelőre nagyjából mindenhol igaz az, hogy a játékfejlesztés egy erősen autodidakta dolog. Az oktatás már ugyan kiépülőben van, de nehezen tud lépést tartani az állandó változással. 

A másik kulcspontja a fejlesztésnek, hogy rengeteg alterülete van, így az, hogy milyen területtel szeretne valaki foglalkozni, nem annyira egyértelmű. Sokan azonosítják a játékfejlesztést a programozással, én is sokszor szembesültem vele, hogy amikor valaki megtudta hogy játékfejlesztő vagyok, hitetlen szemekkel kérdezett vissza hogy "akkor te most programozó vagy?". Nem, nem vagyok programozó, producer és designer vagyok. Itt meg már általában az emberek elvesztik a fonalat :)

Úgyhogy az egyik legfontosabb dolog, hogy tisztában legyünk azzal, miből is áll egy játék elkészítése, és kiválasszuk azt, ami legjobban érdekel. Ennek majd külön írást fogok szentelni, úgyhogy itt nem is kezdek neki a hosszú fejtegetésnek, jöjjön inkább pár általános szabály. 

Néhány alapszabály

A legfontosabb, és szeretném nagyon kihangsúlyozni: bárki lehet játékfejlesztő. Tudom, ez úgy hangzik, mintha könnyű lenne a dolog, de ettől még igaz. Nem számít, hogy valaki nő vagy férfi, alacsony vagy magas. Ha tehetséges vagy, és minden erőddel csinálod, az ipar nagyon nyitott és el fogja ismerni a fáradalmaidat. Ez szerintem egy hatalmas előny, ráadásul a nyitottság nem csak ebben merül ki. Akár kritikáról, akár tesztelésről van szó, lehet számítani a játékfejlesztő kollegákra: fáradhatatlanul fogják tologatni a szürke dobozokat amiket összreaktál, és segíteni fognak abban, hogy tudsz jobbat csinálni abból, amid van. 

A játékfejlesztéshez nem kell zseni programozónak lenni. Szerencsére most már nagyon sok olyan eszköz áll rendelkezésre, amit könnyű beszerezni, és meg lehet tanulni használni. Sok játékkészítő engine elérhető akár ingyen is, és rengeteg oktatóvideó van hozzájuk, amiből elég kitartással sok mindent meg lehet tanulni. Úgyhogy tényleg bárki meg tud tanulni játékot csinálni, ha igazán komolyan gondolja. Az persze nem árt, ha van otthon egy erősebb gép ami elbírja a folyamatos igénybevételt, de ezen kívül szinte semmilyen más eszközre nincs szükség a fejlődéshez. 

Ahogy írtam, bárkiből lehet játékfejlesztő, de azt hozzátenném, hogy megfelelő mindset kell hozzá. Borzasztó nyitottnak kell lenni, mivel az egész ipar folyamatosan változik. Szeretni kell a magányos problémamegoldást, és az autodidakta tanulást. Nem arról van szó, hogy nem lehet segítséget kérni: rengeteg fórum elérhető az interneten is, de úgy gondolom, a tapasztaltabb kollegáktól is nyugodtan lehet kérdezni, mert biztos vagyok benne, hogy válaszolni fognak. Ettől függetlenül kell egy alap fokú kreatív problémamegoldó készség, hiszen sokszor bele lehet futni olyan problémákba, aminek 15 féle megoldási kísérletén kell átküzdeni magunkat, mire végül működésre bírjuk az elképzeléseinket. 

És persze ott az örök kérdés: ki hogyan szeret játékot csinálni? Vannak akik a saját ötletüket akarják megvalósítani, és az indie utat választják, és vannak akik egy területen gyúrják ki magukat, és nagy cégnél helyezkednek el. Azt gondolom, hogy mindkettőnek megvannak a szépségei és negatívumai, de a folyamatos tanulás és az engine-ek alapvető ismerete sosem jön rosszul egyik pályaúton sem. 

Akkor mi a tanulság?

Szerintem az egyik legfontosabb pont, hogy aki játékfejlesztő szeretne lenni, készüljön fel arra, hogy nem fog túl sok dolgot készen kapni. Ez nem egy olyan szakma, aminél működik az, hogy beül valaki az iskolapadba és utána megy minden magától. Rengeteget és folyamatosan kell tanulni, komplex problémákat segítség nélkül megoldani. Szerencsére az internet tele van információval, így azért mindenre lehet így vagy úgy választ találni, viszont néha bizony meg kell érte küzdeni. Viszont mindenképp érdemes belevágni, mert gyorsan és egyszerűen össze lehet rakni akár egy platform, akár egy endless runner játékot. És akármennyire szürkék azok a dobozok a pályán, nincs annál jobb érzés, mint hogy egy saját játékkal játszik az ember a metrón munkába menet. 

Ha tetszett a cikk, nézd meg a többi játékfejlesztéssel kapcsolatos írásomat is, vagy kukkants be a Facebook oldalamra, ahol folyamatosan értesülhetsz a legfrissebb infókról. 

Köszönöm a figyelmet! :)