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. 

Szombaton az a megtiszteltetés ért, hogy meghívtak a Skool által szervezett, lányoknak szóló játékfejlesztő versenyének döntőjére. A verseny az ELTE IK szakmai, valamint a Facebook támogatásával került megrendezésre, és eszközként a Scratch fejlesztő programot használták a versenyzők. 

Ott is elmondtam, hogy mennyire jól esik látni, hogy rengeteg fiatal lány érdeklődik a programozás és fejlesztés iránt. Magyarországon különösen nagy szükség van arra, hogy növeljük a lányok számát az iparágban, úgyhogy mélyen megérintett mikor láttam, milyen sok lány került be a döntőbe. Remélem sikerült kicsit lelkesítenem őket! 

Magáról a versenyről annyit kell tudni, hogy a lányoknak csapatba szerveződve, a Scratch eszközeit felhasználva kell készíteniük egy alkotást, amit később a zsűri értékel. A nyertes csapat pedig ellátogathat a varsói Facebook irodába - ami elég tartalmas utazásnak ígérkezik. A nyertes Palacsinta csapat tagjai egy szabadulós játékot készítettek, melynek a célja, hogy a játékos el tudjon menekülni a Marsról. A nyertes projektet, a többi játékkal együtt itt lehet kipróbálni. 

Azért is nagyon örülök ennek az egésznek, mert eddig még nem hallottam sem a Skool-ról, sem a Scratchről, pedig idén már másodszorra rendezték meg a versenyt. Ráadásul idén már több résztvevője volt a rendezvénynek, összesen 99 lány nevezett a versenyre. A Skool egyébként egy non profit szervezet, aminek a célja, hogy minél több fiatal lány és nő ismerkedhessen meg a számítástechnikával. A Scratch pedig egy fejlesztőprogram, amiben leegyszerűsített vizuális kódolással, és előre megadott elemek használatával lehet játékokat, interaktív animációkat készíteni. 

Innen már igazán csak egy lépés a Contruct 2, amiben én tanultam fejleszteni! :) 

Nagyon pozitív élmény volt a számomra ez a verseny, jó volt látni a sok lelkes arcot és azt a mennyiségű energiát, amit a lányok a szabadidejükből áldoztak fel arra, hogy tanuljanak és fejlődjenek. Úgyhogy szívből gratulálok mindenkinek: a szervezőknek, támogatóknak, és persze a résztvevő lányoknak is! Csak így tovább, csajok! :) 

Ha tetszett a cikk, olvasd el a többi beszámolót is, és keress fel Facebookon, hogy ne maradj le semmiről! 

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

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! 

Ide gyűjtöm azokat a forrásokat, könyveket, oldalakat, ahonnan a játékfejlesztés területeihez információkat lehet találni. Az oldal folyamatosan bővül, mind témakörök mind pedig források tekintetében. Az ötleteket, észrevételeket örömmel fogadom! :) 

// Egy anyag több helyen is szerepelhet. 

0. Alap / általános

• Edx
• jatekfejesztes.hu
• Udemy
• Extra Credits

1. Fejlesztő motorok

• Udemy - vannak konkrét Unity, Unreal, Game maker kurzusok
• hivatalos tutorialok: Unreal, Unity, CryEngine, Construct
• könyvek: 
  • Introduction to Game Design, Prototyping, and Development: From Concept to Playable Game with Unity and C#

2. Design

• könyvek: 
  • The Art of Game Design: A Book of Lenses
  • Game Design Workshop: A Playcentric Approach to Creating Innovative Games
  • Level Up! The Guide to Great Video Game Design
  • Theory of fun for game design
  • Rules of play: Game design fundamentals

  • Introduction to Game Design, Prototyping, and Development: From Concept to Playable Game with Unity and C#

3. Programozás

• engine tutorialok: Unreal, Unity, CryEngine, Construct
• Khan Academy
• könyvek: 
  • Introduction to Game Design, Prototyping, and Development: From Concept to Playable Game with Unity and C#
  • Think Like a Programmer: An Introduction to Creative Problem Solving

4. Grafika

• ctrlpaint

5. Modellezés

6. Narratíva, írás

• könyvek: 
  • Game Writing: Narrative Skills for Videogames

  • The Ultimate Guide to Video Game Writing and Design

 7. Animáció

8. Marketing