Mindent játékokról és fejlesztésről

Developer Pixie

Developer Pixie


A virtuális valóság sajátosságai

2018. szeptember 30. - Developer Pixie

Jópár hónapja voltam a StoryCode meetupján, ahol a játékok narratív felépítéséről beszélgettünk, illetve a már lerágott narratológia-ludológia vita is szóba került. 

Ami azonban megragadt a fejemben, és még sosem írtam róla, az a VR design volt. Előkerült ugyanis az, hogy miben más VR-re fejleszteni, hogyan befolyásolja a technológia a tervezést, illetve a narratíva átadását. Miben más virtuális valóságban elérni azt, hogy a játékos arra nézzen, amerre mi szeretnénk? 

 

bethesda-vr-e3-2016-doom-fallout-6812-006.jpg

 

Ez valóban egy nehéz, de érdekes dolog. Én ugye úgy csöppentem a VR fejlesztésbe, hogy előtte nem sokat tudtam róla. Rengeteget olvastam, hallgattam és tanultam a témáról, és lehet, hogy már lerágott csont, de vannak azok az alapszabályok, amiket nem árt betartani. 

Nyilván sokaknak már egyáltalán nem újdonság ez a lista, de azoknak, akik még nem csináltak ilyet, hasznos lehet, úgyhogy összeszedtem nektek a legfontosabbakat! 

 

1. Nem mozoghat a játékos úgy, mint egy sima FPS esetében

Ekkor ugyanis az agy nem tudja eldönteni, hogy mit csináljon: a testünk egy helyben marad, az élmény mégis az, hogy mozgunk. Ettől könnyen rosszul lehetünk - és a legtöbb ember viszonylag hamar le is dobja a headset-et. Ezért terjedt el annyira a teleportálós módszer, ahol egy másodperc törtrésze alatt ott termünk valahol, ahelyett, hogy lassan és folyamatosan mozognánk. Megoldást jelenthet az is, hogy egy "járműbe" tesszük bele a játékos karaktert, ekkor az autóban / repülőben ülés érzése miatt elviselhetőbb a dolog. 

Referenciaként ajánlom összehasonlítani a Here They Lie és a Budget Cuts mozgásérzését. 

 

dexmo-dexta-vr.jpg

 

 

2. A dolgok térben vannak

Ez elsőre mókásan hangzik, de hamar rájövünk, hogy VR-ben tényleg térben van minden. Nem elég, hogyha egy oldalról / szögből tervezünk meg valamit, a játékos konkrétan körbe tud járni mindent, és nagyon közelről meg tud vizsgálni tárgyakat. Éppen ezért törekedni kell arra, hogy a környezet minden oldalról hihető legyen. Ez nem csak a grafikusoknak kihívás, hanem másfajta gondolkodást követel meg a level design és a környezet megtervezésekor is. 

 

3. A dolgokon át lehet menni (?)

HTC Vive esetében ügyelni kell arra, hogy nem tudunk collidert tenni egyes objectekre, amin a felhasználó majd jól megakad, hiszen a játékosnak szabad mozgástere van egy 2x2 méteres térben. Így minden, ami ezen a területen belül esik, átjárható lesz a játékos számára. Ez általában nem gátol semmit, de gondolni kell rá, mert tud nagyon vicces következményekkel járni. 

 

fishing-vr-gameplay.jpg

 

4. A játékos mozog

Ez is viszonylag evidens, és a fenti szabályokban is előjön, de ettől még ki kell hangsúlyozni a tervezési folyamat miatt. Tök jó új dolgokat ki lehet találni a játékos mozgatásával, különböző gesztusok használatával, de arra is fel kell készülnünk, hogy egy átlag felhasználó kifárad 3-5 perc után. Csak óvatosan a guggolással és hadonászással :D 

 

5a9abee12afde.jpg

 

5. A játékos össze-vissza nézelődik

Sosem tudhatjuk, hogy éppen mi van a szeme előtt, és ez borzalmasan nagy különbség a monitorhoz képest, ahol biztosak lehetünk benne, hogy mindenki azt látja, amit éppen mutatunk neki. Úgyhogy, ha azt szeretnénk, hogy a felhasználó egy adott pontra nézzen, akkor nagyon egyértelműen ki kell fejeznünk, amihez általában nem elég pusztán vizuális jelzéseket adni - hiszen lehet, hogy pont teljesen ellenkező irányban nézelődik. Általában hanghatásokat szoktunk ilyenkor alkalmazni, mert zsigerileg benne van az emberben, hogy a hirtelen hangok irányába forduljon. Innentől már indíthatjuk a jelzőtüzeket, és használhatunk vizuális ingereket. 

 

oculus_rift_girl-farlands_v1.jpg

 

Szerintem nagyjából ezek lennének az alapok, de ha valamit kihagytam volna, nyugodtan írjatok! :) 

Ha tetszett az összefoglaló, nézd meg a többi hasonló cikket is, illetve kukkantsd meg a Facebook oldalamat, ahol további érdekes posztok várnak! 

Indie project management

A játékfejlesztő kreatív állatfaj, még akkor is, ha programozó. Napról napra olyan problémákkal szembesül, amiket kreatív módszerekkel kell megoldania, és aminek együtt kell működnie egy csomó másik dologgal. Viszont mindez időigényes, és rengeteg apró feladatot takar. 

 

149837-sqdxmjdz-v3.jpg

 

Fogadok, hogy mindenkivel előfordult egy hét kihagyás után, hogy azt se tudta, mivel haladjon. Vagy akár egy teljesen normális napon. Persze mindenki látja, hogy a grafika nincs kész x-y pályán, vagy a karakteranimációk hiányoznak. De hogyan lehet ezt a legjobban számon tartani? 

Megint csak a saját tapasztalatomat tudom megosztani. Nekem az segített a legtöbbet, hogyha minden napra előre lebontottam a haladásomat. Minden este tudtam, hogy másnap reggel mivel kell folytatnom, és ez rengeteget segített a motivációm szinten tartásában. Kis, belátható, megcsinálható feladatokra bontottam az óriási, többhónapos (éves) projektet, amitől nem ment a kedvem menten az elején. 

Ehhez pedig rendszeres menedzsmentre van szükség, és egy jó indie projekt menedzserre, aki a legtöbb esetben maga a fejlesztő. 

 

talking-to-myself-staff-meeting.jpg

 

Én már többféle eszközt is kipróbáltam. A legelső - és leggagyibb - nyilvánvalóan egy Excel tábla volt. Ide beírtam szépen egymás alá a feladatokat, felcímkéztem a saját becslésemet hogy mikor lesz kész, és aztán a valós elkészülési időt is feltüntettem. Nem volt kegyetlenül ergya módszer, de azért nem is volt túl gördülékeny. 

Aztán elkezdtem a direkt erre kitalált eszközöket használni, mint pl. a Trello vagy az Asana. Nyilván csak olyanok jöttek szóba, amikért nem kell fizetni, ez az indie fejlesztések esetében sokszor szempont. De szerencsére a legtöbb ilyen szotver kis felhasználószám esetén amúgyis ingyenes, így emiatt nem kell aggódni, amíg fel nem nő a csapat 9-15 főre (akkor meg már szerintem nem gond összedobni erre). 

 

solo-developers.png

 

Az alapja a legtöbb ilyen programnak teljesen ugyan az, és a használatuk végtelenül egyszerű. Létrehozhatunk táblákat, azon belül pedig szabadon annyi listát készíthetünk, amennyit akarunk. Én maradni szoktam a jól bevált "to do" "in progress" és "done" kategóriáknál, de mindenkinek szíve ügye, hogyan szereti címkézni a dolgait. Ezekhez a listákhoz hozzá tudunk adni kártyákat, amik igazából egy-egy feladatot jelentenek. Ezeket utána tudjuk mozgatni, így jelezve ha valami éppen készülőben van, vagy már el is készült. Mindegyik kártyához tudunk határidőt és felelőst csatolni, vagy képet hozzáadni, és persze törölni. Általában minden feladat alatt van egy history tab, ami jelzi hogy ki, mikor és mit módosított az adott feladaton, így nagyon könnyű nyomon követni a változásokat. 

Sokáig a Trellót használtam, az szerintem a legegyszerűbb ezek közül, és a célnak tökéletesen megfelel. Viszont szerintem vannak idegesítő dolgai, amiket nem tudtam megszokni, ezért kezdtem tovább keresgélni. Nekem eddig az Asana vált belegjobban, most már a munkahelyemen is azt használjuk. Nagyon kényelmes, egyértelmű funkciókkal és UI-UX szempontból is sokkal kidolgozottabb. Asanánál eleve ki tudjuk választani, milyen projekt-menedzsment nézetet szeretnénk, nem csak a Kanban tábla elérhető, hanem van listás nézet is, ha valaki azt preferálná. 

Nem tudom,  biztos van ennél is jobb módszer és eszköz, én jelenleg itt tartok a dologban. Ha valaki esetleg megtalálta a világ legjobb projekt menedzsment szoftverét, kérem ne habozzon megosztani! 

 

indie-devs.png

 

És most egy kis motivációs beszéd. 

Amióta használom ezeket rutinszinten, azóta sokkal jobban haladok a saját dolgaimmal. Az indie fejlesztés egyik legnagyobb átka, hogy a fejlesztő a saját maga a főnöke, és mint ilyen, hajlamos engedékeny főnök lenni. De ha le van írva valami, és saját magam becsültem meg, mennyi munkaóra alatt kellene elkészülnöm, az valahogy motiváló. Illetve az a bűntudat motiváló, hogy már 3 saját határidővel nem lettem kész, és nincs mellébeszélés, hiszen ez ott van a history-ban. Persze nyilván más az, hogy valaki szabadidejében fejleszt, és az idejével zsonglőrködik. Ilyenkor nem lehet túl szigorú magával senki, de ha valaki full-time nyomja az indie-t, akkor mindenképpen megéri szigorú főnöknek lenni. 

 

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

A 22 Pixar szabály

A Pixar szuper filmeket rakott már le az asztalra, és mindig csodálkozom, mennyire profin szolgálják ki egyszerre a felnőtt és gyerek közönséget. A minap ráakadtam a 22 Pixar szabályra, ami igazából egy segítség lista arról, mire érdemes odafigyelni miközben sztorit találunk ki. Nem csak játéktervezéshez lehet használni, sőt nem is arra találták ki. Ennek ellenére nagyon jó kis lista, érdemes átfutni rajta, és időnként vissza-visszatérni hozzá. 

Nem is változtattam semmit rajta, csak lefordítottam. Használjátok szeretettel :) 

 

kepernyofoto-2017-06-15-154608_7fm8_1920.png 

#1: Egy értékes karakter többet próbál elérni a saját sikerénél. 

#2: Észben kell tartani, hogy ami befogadóként érdekes, nem mindig izgalmas alkotóként. 

#3: Témát keresni fontos, de nem láthatjuk előre miről fog szólni az alkotásunk. Akkor tudjuk meg, mire a végére érünk. És akkor írhatjuk át az egészet. 

#4: Volt egyszer valaki, akit ......-nak hívtak. Minden nap .......-t csinálta. Aztán egy nap ...... történt vele. Emiatt ........ dolgok történtek. Ezek miatt ....... Végül pedig ........ 

 

 

corso-storytelling-620x275.jpg

 

#5: Egyszerűsíts. Fúkuszálj. Kombinálj karaktereket. Kerüld a kerülőutakat. Úgy fogod érezni, hogy értékes dolgokat engedsz el, de fel fogsz szabadulni tőle. 

#6: Miben igazán jó a karaktered, mi a kényelmes számára? Dobd rá a meredek ellenkezőjét. Adj neki kihívásokat. Hogyan küzd meg velük? 

#7: Találd ki a végkifejletet, mielőtt a történet közepét megírnád. Komolyan. Befejezést írni nehéz, találd ki jó előre. 

#8: Fejezd be a történeted, és engedd el, még akkor is, hogyha nem tökéletes. Egy ideális világban kész is, és jó is amit csinálsz, de lépj tovább, és csináld jobban legközelebb. 

#9: Ha elakadtál, írj egy listát, hogy mi az ami BIZTOSAN NEM fog megtörténni. Sok esetben megtalálod a megoldást, ami miatt eladakadtál. 

 

2994image_coco-dante-pixar.png

 

#10: Szedd darabokra a történeteket, amiket szeretsz. Azok a részek, amik tetszenek, a részeiddé válnak - ismerd meg őket, mert csak utána tudod felhasználni. 

#11: Ha leírod amit gondolsz, az segít a javításban. Ha csak a fejedben létezik egy történet, az mindig egy tökéletes ötlet marad, amit sosem fogsz megosztani senkivel. 

#12: Vesd el az első ötletet, ami eszedbe jut. És a másodikat, harmadikat, negyediket, ötödiket is... Engedd, hogy az egyértelmű dolgok kikerüljenek az utadból. Lepd meg magad. 

#13: Adj véleményt a karaktereidnek. A passzív / formátlan karakterek könnyen szerethetőnek tűnhetnek a számodra, de ez méreg a hallgatóságod számára. 

#14: Miért kell pont EZT a történetet elmesélned? Milyen meggyőződés él benned, ami élteti ezt a történetet? Mert az a szíve az egésznek. 

#15: Hogyha te lennél a karakter, az adott helyzetben, hogyan éreznéd magad? Az őszinteség hihetővé teszi a leghihetetlenebb helyzeteket is. 

 

20091015pixar3.jpg

 

#16: Mi forog kockán, miért harcol a karakter? Adj neki indokot. Mi történik, hogyha kudarcot vall? Nehezítsd meg a sikerét! 

#17: Soha, semmilyen munka nem megy pocsékba. Ha valami nem működik, engedd el és lépj tovább, később vissza fog jönni és hasznod válik belőle. 

#18: Ismerned kell magad, hogy különbséget tudj tenni: mikor hozod ki magadból a legjobbat, és mikor körülményeskedsz. Egy történetet tesztelés, nem folyamatos finomítgatás.

#19: A véletlenek, amik bajba sodorják a karaktereket, jók. A véletlenek, amik segítenek a karaktereknek kijutni a bajból, rosszak. 

#20: Gyakorlásnak vedd szemügyre az építőköveit egy filmnek, amit nem szeretsz. Hogyan rendeznéd át őket egy olyanná, ami tetszene? 

 

storytelling-promo-feature.jpg

 

#21: Azonosulnod kell a helyzetekkel, és a karakterekkel. Mi venne rá téged, hogy ugyanúgy viselkedj egy adott szituációban? 

#22: Mi az esszenciája a történetednek? Hogyha nagyon röviden kellene elmesélned? Hogyha ezt már tudod, innen el tudsz kezdeni építkezni. 

 

Ennyi lett volna a lista, köszönjük meg Pixar-nak, hogy közzétette! :) Remélem nem csak nekem lesz hasznos, hanem más is hasznát tudja majd venni. 

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

Játékfejlesztés V - Egy fejlesztés lépései

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. 

 

4ad46c6a-496c-4f77-b59b-3240320c9d412.jpg

 

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. 

 

2235_evolution-of-gaming-628x250.gif

 

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. 

 

how-to-make-a-game-without-coding.jpg

 

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. 

 

game_design_500_400_v1.png

 

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. 

 

10-10_rapid_prototyping-1.jpg

 

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. 

 

fright_fight_wolf_gif.gif

 

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. 

 

gaming.jpg

 

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. 

 

 

game-creation-process-playtest.png

 

 

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. 

 

browser-preview-01.jpg

 

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! 

Tudástár

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

 

1. Fejlesztő motorok

 

2. Design

 

3. Programozás

 

4. Grafika

 

5. Modellezés

 

6. Narratíva, írás

 

 7. Animáció

 

8. Marketing

süti beállítások módosítása