gondolataim elsősorban játékfejlesztésről

Miután áttértem projekt menedzselésben a CMake használatára szinte azonnal adta magát, hogy kipróbáljam lefordítani az enginem iOS ill. MacOS rendszerekre is. Az utóbbira történő fordítás nem igényelt különösebb előkészítést - mondhatni azonnal működött. Az iOS projekt készítésével már akadtak nehézségek:

Az utóbbi bejegyzés óta történt talán legnagyobb változás az, hogy áttértem az "automata" projekt menedzselésre nevezetesen a CMake használatára. Nagyon sok platform, nagyon sok IDE és sok toolchain használata elérhetővé válik ezután.

Az elmúlt hetekben főleg az AI-val töltöttem el a fejlesztési időt: kétféle humanoid és kétféle egyéb kategóriába sorolható viselkedés modellezésével. Tekintve, hogy a játék tekintélyes részét az ellenfelekkel való harc teszi ki (ill. az is izgalmas, hogy a gép hogyan játszik önmaga ellen) igyekeztem minél ésszerűbbnek ható és egyértelműen szabályozható intelligenciát kidolgozni a humanoidokra.
A kétféle humanoid viselkedés valójában egyet takar a különbség mindössze annyi, hogy van-e fegyver a felvett tárgyak között vagy sem. Természetesen teljesen problémamentes a kettő közötti átmenet: amennyiben úgy ítéli meg az AI megkeresi a számára kedvenc fegyvert vagy ha olyat nem talál a legközelebbi fegyver megszerzését tűzi ki célul. Ha pedig elfogy a lőszer a fegyverből, akkor egyszerűen eldobja azt.
Most pedig következzenek azon paraméterek amikkel "karakterisztikát" adhatunk az adott szereplőnek:

• félénkség. támadás esetén mennyire szeret menekülni.
• reakcióidő: mennyire gyorsan követi az célpontját ill. milyen gyorsan veszi azt célba
• célzási pontosság: ez azt hiszem önmagáért beszél
• támadó erő: közelharc esetén a támadott félen okozott sebzés mértéke
• mozgási sebesség: futás ill. járási sebesség
• alacsony élet riasztás típusa: alacsony életerő esetén a választott cselekvés - menekülés, segítséghívás, életerő feltöltés stb.

Ezek némelyike értelemszerűen vagy csak az egyik vagy csak a másik viselkedés esetén befolyásoló tényező.

A lista természetesen még nem végleges, de tapasztalatom szerint már élvezhető viselkedésmintákat lehet vele készíteni (pl. egy félénk, de lassan reagáló ill. bátor, de gyors ellenfél harca pláne, ha különböző fegyvereik vannak).

Ehhez tartozik még, hogy a következő demóhoz még összeraktam három, egyre nagyobb tűzerőt képviselő fegyvertípust, amikkel (talán) még változatosabbá tehető majd a játék.

Végezetül pedig megemlíteném, hogy a HDR mellé végre implementáltam egy elfogadható minőségű bloomot:

Szép lassan a végéhez ér a Grypania v2 kivitelezése nemrégiben készítettem el az intro egyik lehetséges változatát. A helyszín, szereplők, ellenfelek gyakorlatilag elkészültek a scriptek és az in-game átvezető jelenetek (amik szintén scriptek) vannak hátra és az ezekkel járó tesztelés / debugolás.

Alant pedig egy kép az intro hátteréről. A modellek valós(nak tartott) adatok alapján készültek.

A Maya plugin több hónapnyi használata megmutatta, hogy sajnos a játék szerkesztésének bizonyos elemei nem vagy csak nagyon nehezen valósíthatók Maya alatt. Úgy tűnik tehát, hogy mindenképp szükséges egy saját, "valamilyen" gui-val elkészített szerkesztő is.
Az egyetlen problémám, hogy a "valamilyen" gui-nak több szempontnak is meg kell felelnie:

• érett szoftver legyen vagyis ne annak a debugolásával kelljen foglalkozni
• jól használható / érthető dokumentáció
• a mérete minél kisebb legyen
• bináris SDK vagy könnyen fordítható legyen
• legyen hozzá designer alkalmazás
• kezelje az általunk használni kívánt gui funkciókat
• multi-platform
• "jól nézzen ki"

A WinForms-ot használtam régen, amellyel akadtak problémák - GL renderelő ablak kezelése, fa alapú listában többszörös kijelölés natív támogatása. Aztán megpróbálkoztam ismét a CEGUI-val, de a rengeteg lefordítandó függőség a kedvemet szegte. Elgondolkoztam a Qt használatán ám annak a mérete és gcc-vel való (túl) közeli kapcsolata rémített el.
Jelenleg a FLTK mellett kötöttem ki, amely kissé ódivatú megjelenése ellenére biztató tulajdonságokkal rendelkezik. Sajnos az undo-redo rendszer java részét ezzel a váltással elvesztettem azonban a Maya tapasztalataim alapján könnyen készíthetők különféle exportálók.

Itt pedig egy kép minderről:

Hogy mik változtak:

• Maya importerek
• emitterek turbulenciával (mert azt mindenki szereti)
• egyszerűsített pályakészítés automata generátorral kiegészítve
• qhull használata
• külön svn repo a scriptekhez, mert számuk és bonyolultságuk egyre nő

és ami a legizgalmasabb: Quake3 által ihletett botok - egyre összetettebb döntési rendszerrel.

• Képesek fegyvert keresni maguknak, amelyek közül a kedvencüket választják.
• Amennyiben fontosnak tartják elmennek a legközelebbi health terminálhoz, hogy életerőt szerezzenek.
• Szorult helyzetben segítséget hívnak.
• Járőrözés.
• Ha lehetőség van rá, lövik az ellenfelüket, ha nem akkor kergetik.

Rövid összefoglaló, hogy az elmúlt bő egy hónapban mi növelte meg a revíziószámot:

Engine:

• Videó lejátszás Theora segítségével
• Lightprobe-ok generálása navmesh alapján
• Lightprobe-ok mellé envprobe-ok
• Star Wars: The Force Unleashed 1/2 modell ill. csontváz importálási lehetőség ill. részleges animálás

Maya plugin:

• Elérhető a radiosity alapú lightmap készítés
• Számos saját maya-s típus
• Material, mesh ill. csontváz importálás
• Játék mentése scriptként

Vállalkozó szellemű embereket keresek, akik értenek az Autodesk Maya használhatához és szívesen tesztelnék az enginemmel készült plugint. A plugin a Maya 2013 64 bites verziójához készült, de némi segítséggel és időráfordítással más Maya változatokhoz is el tudom készíteni.
A feladat a plugin funkcionalitásának ill. stabilitásának tesztelése lenne egy tetszőleges, apró jeleneten.

A pontosabb részleteket, a bináris csomagot ill. a hozzá tartozó readme doksit kérésre szívesen elküldöm.
Jelentkezni az oldalon megtalálható email címek bármelyikén lehetséges.

Köszönettel,
syam aka HZ :)

A Maya plugin fejlesztése során átlépte az engine revíziószáma ezt a bűvös határt.
Az a tény, hogy az enginem egy másik szoftver által biztosított környezetben fut igencsak átformálja a tervezést:

• legfontosabb talán, hogy a hibakezelést a lehető legrészletesebben ki kell terjeszteni a pluginen belül ezzel elkerülve a teljes szoftver összeomlását
• hirtelen sok és valós felhasználási igénnyel találkozik az ember
• a funkciókat minél inkább automatizálhatóvá kell tenni, hogy minél kevesebb figyelem ráfordításával és minél gördülékenyebben történhessen a plugin használata
• emiatt ahol lehetséges egyszerűsítés / egységesítés szükséges pl. több, nagyon hasonlóan működő függvényt összevonni
• visszajelzést adni az engine belső állapotáról ill. ezt olvasható formában megjeleníteni
• az események logolása arra az esetre, ha mégis "visszavonhatatlan" esemény történik
• minél egyszerűbb és egyértelműbb (egy feladatra csak egy funkció létezzen) interfész megteremtése a két szoftver között
• amennyiben lehetséges közvetlen elérést biztosítani a pluginhez hibakeresés céljából

A plugin jelenlegi állapota pedig:

• saját típusok attribútumokkal
• a saját típusok saját Maya renderelés
• közvetlen engine renderelés Maya viewportban
• statisztika szöveges megjelenítése Angelcode-os bitmap fontokkal
• és elérhető az összes Maya szerkesztői parancs :)

  Alant pedig a fenti jelenet forrásának rövid részlete:

requires maya "2013";
requires "maya_win64_plugin" "1.0";
currentUnit -l centimeter -a degree -t film;
fileInfo "application" "maya";
fileInfo "product" "Maya 2013";
fileInfo "version" "2013 x64";

Úgy, hogy ír hozzá az ember egy plugint.

Kontra:

• Meg kell érteni a Maya API-t.
• Meg kell érteni a Maya belső működését.
• Össze kell tudni hangolni a saját engine-t a Mayával a fentiek ismeretében.

Pro:

• Így az ember készhez kap egy profi 3D szerkesztőt.
• Ezt a szerkesztőt elég sok modellező ismeri és tudja is használni.
• Ha a programozó magára van utalva, némi tanulással (elég gyorsan) lehet készíteni "programmer art" szintű jelenettel játékot.
• Ha már sikerült a hangolás az engine és egy külső API között, akkor egy újabb API nem lehetetlen kihívás.
• Az importálás nem függ külső (esetleges hibás, nem teljeskörű támogatással bíró) exportálóktól - importálót pedig mindenképp kell készíteni.
• Szélesíti az ember látókörét.