Úgy gondoltam, lenne értelme megtanulni a C# programozási nyelvet. A lenti, szigetes feladat egészen jó alanynak tűnt ahhoz, hogy elkezdjem, úgyhogy a következő szigetest már c#-ban írtam meg, és – Geot felvetése kapcsán – gravitációval. Kifejtés és képek alant:

more…

Egy cikkben olvastam az előbb az alább idézett szöveget. Mindenféle további magyarázkodás nélkül, ezért szeretnék játékot írni:
“Take my father. Born in the 1950s, the only windows he knows about are on the front of his house. Computers were just never part of his life, but he is, in his own way, a gamer. The man loves chess and his biggest joy is playing people online. Why? To him it’s amazing that the computer lets him play a guy in Russia one minute and a guy in Thailand the next. The man types with two fingers, but he always asks where his opponent is from, and I’m not entirely sure he hasn’t marked them all off on a map somewhere. He even started getting up at obscene hours of the morning so he could play people in even further away places.”

Magyarra fordítva:
“Vegyük példának az apámat. Az 50-es években született, az ablakokról (windows) az jut eszébe, ami otthon az utcára néz. A számítógépek sosem játszottak fontos szerepet az életében, mégis, a maga módján megszállott játékos. Imádja a sakkot, és a legnagyobb öröme az, amikor online játszhat. Hogy miért? Mert teljesen lenyűgözőnek találja, hogy a számítógép segítségével az egyik percben még egy orosz fickóval játszik, a következőben pedig már Thaiföldről valaki mással. Két ujjal gépel, mégis mindig megkérdi az ellenfelét, hogy honnan játszik, és abban sem vagyok biztos, hogy nem jelölte meg őket valahol egy térképen. Mostanában már egyre furcsább időpontokban kel fel, hogy még távolabbi emberekkel játszhasson.”

Íme az első screenshot az “legközelebbi felé mozgunk és ha odaértünk, megállunk” viselkedéshez:

Egyszerű szomszédvizsgálat

A kék az alapszín, a világoskék a megtett utat jelzi, a sárgák pedig a “végpontok”, ahol a kis szigetek megállapodtak. A következő kísérletben megpróbálok egy olyan vizsgálatot beillesztni, ahol a kis szigetek mindig a környéken lévő legnagyobb sziget felé igyekeznek..

Mondanom sem kell, ez a kép is nagyszerűen mutatja, hogy ebből a szabályrendszerből csak egy valamivel rendezettebb káosz alakul ki, de egészen távol van attól, hogy egy valódi sziget alakuljon ki..

A lentebb említett emergence kapcsán gondolkoztam el azon, hogy pályaépítést szeretnék ahhoz hasonló módon csinálni. A lényeg a valószerűség. Vannak apró egységeim, amikre definiálok néhány szabályt, majd véletlenszerűen elhelyezem őket egy terepen. Innentől az egységek olyan módon módosítják lépésről lépésre az állapotukat, hogy a szabályok alapján kedvezőbb pozicióba kerüljenek. Minden lépésben minden egységre meghívom ezt az állapotjavító függvényt, és figyelem, hogy hány egység változtatott. Ha a passzív – elégedett – egységek száma elér egy bizonyos %-ot, mondjuk 80-at, akkor megállok, és ha elég ügyesen definiáltam a szabályokat, akkor a pályám kialakult – véletlenszerűen.

Nyilván itt is oda kell figyelni egy pár dologra:

- Megfelelően sok és szigorú szabállyal el lehet azt érni, hogy bármilyen kezdőállapot ugyanahhoz a végállapothoz vezessen. Ezt nem akarom.

- Ugyanakkor elég szigorú szabályok kellenek, hogy a végkifejlet megfeleljen az elvárásoknak, ne csak egy véletlenszerű kaotikus valami maradjon. Ezt legkönnyebben emberi aggyal lehet ellenőrizni.

- Lehetnek oszcilláló végállapotok. Ez azt eredményezi, hogy minden lépésben pontosan ugyanannyi egység mozog egy olyan állapotba, amiből aztán az előző állapotba kerül vissza. Így folyamatosan van változás minden lépésben, de összességében pontosan ugyanabban a helyzetben leszünk folyamatosan. Ha ez még azelőtt beáll, hogy elérnénk a kritikus passzív tömeget, akkor soha nem fejeződik be a generálás.

Nézzünk egy egyszerű példát:

- Tengeren akarok szigeteket alkotni. A magassággal nem törődöm, csak azzal, hogy az adott pont víz vagy szárazföld.

A kiindulási pontom egy óriási tengerszelet, amelyre pici – egységsugarú – úszó szigeteket helyezek el.

A szigeteknek a következő viselkedést definiálom:

- Ha nincs közvetlen szomszédod, nézd meg, merre van a legközelebbi kis sziget, és mozogj felé.

- Ha van közvetlen szomszédod, ne csinálj semmit.

Ez a viselkedési minta több következménnyel is jár:

1: nagyon sok olyan sziget lesz, ahol két pici szigetdarab tapad csak össze. Ez vsz nem megfelelő.

2: Nincs definiálva szabály arra, hogy mi történik, ha egyforma távolságban több sziget is van.

Ez a szabályrendszer a második pontnak megfelelő viselkedést produkál.

Ha kicsit átalakítjuk a szabályt úgy, hogy

- Ha van közvetlen szomszédod, számold meg őket, és ha látsz ennél nagyobb szigetet valahol, mozogj arra

Azzal viszont gyakorlatilag az egyes pontot érjük el, mert minden esetben a végállapotban valahol egy marhanagy sziget lesz.

Ebből a két egyszerű példából is látható, hogy némiképpen bonyolultabb a probléma, mint várnánk. Akarok egy kis testbed-et írni ennek a kipróbálására, egyszerű szabálynyelvvel. Ha lesznek eredmények, rakok fel screenshotokat. (csak ne feledjük: lusta.hu)

Egy MMO-hoz kapcsolódó cikk kapcsán olvastam a fenti kifejezést: Emergence. Mivel nem tudtam, mit is jelent pontosan, rákerestem, és találtam egy nagyon jó definíciót a wikipedian:

“In philosophy, systems theory and science, emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions. Emergence is central to the theories of integrative levels and of complex systems.”

Azaz, a lényeg magyarul az, hogy amikor viszonylag egyszerű cselekvésekből valami minta, összetett dolog következik, azt hívják így. Ez valahol pont a fordítottja annak, amire én törekszem, de hiszen én egy mintából szeretnék egy egyszerű viselkedést kihozni, de biztos, hogy van helye a játékok világában. Részletesebben ki fogom fejteni később, milyen szituációkat tudok én elképzelni, ahol ezt hasznosítani lehet..

Mennyire lehet nehéz előre megjósolni egy játékos viselkedését? A csapdaállítás kapcsán már kiderült, hogy ahhoz, hogy a csapdánk hatékonyan működjön, szükségünk van arra, hogy a játékos mozgását befolyásoljuk. Ha egy kicsit általánosítunk, akkor azt is mondhatjuk, hogy a stratégiánk helyes viselkedéséhez tudnunk kell, hogy a játékos mit fog csinálni.

A kiszámítás nyilván nem egyszerű dolog, hiszen a legtöbb esetben maga a játékos sincs tisztában azzal, hogy mit akar csinálni, mintahogy az sem biztos, hogy ha elkezd egy terv szerint dolgozni, akkor azt be is fejezi. A legnyilvánvalóbb megoldás az, hogy ha a gép tanul, és a korábbi viselkedési minták alapján megmondja, hogy jó eséllyel mi következik. Ennek azonban több hátránya is van: nehéz megcsinálni, rengeteg információt kell hozzá nyomon követni, számításigényes és nem elég dinamikus, mivel a játékos viselkedését meg kell tanulni mielőtt reagálni tudnánk rá.

Ennek a gyorsabb, de kevésbé rugalmas változata a játékosmodellek alkalmazása, ahol többféle viselkedési sémánk van, és csak azt próbáljuk meghatározni, hogy a játékos ezek közül melyikhez áll legközelebb. Ennek sikeressége nagyban függ a modellek részletességétől, a játékos besorolásának pontosságától és attól, hogy a játékos ne legyen tisztában azzal, hogy milyen modellek vannak, hiszen akkor arra alapozva tud csalni. Cserébe ez a megoldás sokkal gyorsabban alkalmazható az aktuális helyzetekre, és gyorsabban lehet vele reagálni a stratégia váltásra is – ám sokkal kevésbé precízen.

Ez a két technika kombinálható is, nyilván, és ha elég ügyesek vagyunk, akkor mindkettőből a lehető legtöbb pozitív tulajdonságot átvisszük.

Ugyanakkor van egy olyan lehetőség is, ami ennél sokkal egyszerűbb. Mi van akkor, ha nem sokat foglalkozunk a játékos besorolásával és a predikcióval – hanem inkább megpróbáljuk befolyásolni a viselkedését? Feltételezzük, hogy bizonyos helyzetekre miként reagál, és megpróbáljuk annak megfelelően irányítani. Például egy RTS játékban ha a játékost folyamatosan légi egységekkel támadjuk és csak névleges földi erőt vonultetunk fel ellene, akkor ő várhatóan légi egységek ellen fog felkészülni. Ha ezek után indítunk ellene egy szinte kizárólag földi egységekből álló offenzívát, akkor találhatunk rést a védelmén. – feltételezve, hogy a játékosnak feltűnt a légi egységek fokozott használata.

Régi vesszőparipám a csapdaállítás a szerepjátékokban. Háromféle lehetőség van erre: A pályatervező készít csapdát, a játékos készít csapdát illetve az ellenfél készít csapdát. Ebből az első általában jól sikerül – nyilvánvaló, hiszen a pálya maga úgy készül, hogy el tudják helyezni benne a csapdát. A játékos csapdaállítása többnyire haszontalan, hiszen a játékok alapvetően progresszívek, a játékos mozog, a környezet reagál, ebbe nem illik igazán bele az, hogy a játékos elhelyez egy nem mozgó objektumot. A hangsúly azonban ebben a bejegyzésben a harmadik ponton van.

Az első játék, ami a csapdaállítással kapcsolatban eszembe jut, a guild wars. Emlékeim szerint ott a gépi ellenfél képes volt egészen hatékonyan csapdát állítani – a saját lábánál. Gondolkozzunk el azért inkább azon, hogy milyen szempontokat lenne érdemes a csapdaállításnál figyelembe venni:

- Alapfeltételeink: Az ellenfél 1 egyed, ami bár kommunikációképes, de nem irányítja a többi ellenfelet. Az ellenfél nem csal, azaz a saját maga által állított csapdába ő is bele tud lépni.

- Először is határozzuk meg a csapda jellegét: A játékost egy szerkezettel/mágiával/etc. akarjuk elkapni/sebezni/mérgezni/sít vagy tőrbe akarjuk csalni, egy várakozó csoporthoz, akik majd jól megtámadják.

- Mindkét esetben a játékos mozgását kell irányítanunk, hogy egy adott ponthoz elérkezzen vagy áthaladjon rajta. Ez lehet vonzó vagy taszító jellegű irányítás, azaz a játékos valami felé vagy valamitől elfelé mozog. Mivel az ellenfél 1 egyed, ezeket is neki kell valamiképpen megoldania: maga után csalhatja a játékost, vagy éppen egy nyilvánvaló csapdát állíthat valahol, amit a játékos kikerül, és emiatt mozog bele az igazi csapdába.

- A mechanikus/mágikus csapdát olyan helyre érdemes állítani, ahol a játékos nehezen kerüli ki, azaz pl. a folyosó egy szűkületében, vagy éppen egy ajtóban. Ugyancsak jó ötlet lehet egy könyvespolc elé rakni, ha tudjuk, hogy a játékos vsz. úgyis odamegy és megvizsgálja. A csoportok olyan helyen jók, ahol a játékos körülzárható vagy a menekülése valamilyen más módon megakadályozható.

- A csapdaállításnak akkor van értelme, ha aránylag ritka, emiatt a játékos nemigen számít rá.

Ez a logika meglehetősen bonyolult, így nem feltétlenül van értelme megvalósítani egy játékban. Ugyanakkor mégiscsak színesíti a dolgot, meg a programozó számára érdekes a kihívás is..

A fentiek, mint az írtam is, elsősorban a szerepjátékok világára igazak. Kis módosítással azonban a csapdaállítás egy csomó más játékműfajban is használható: FPS-ben vannak a falra tapasztható lézeres aknák; stratégiai játékokban a települések köré vonhatunk aknamezőt, illetve a gerillák is aláaknázhatnak utakat; harci szimulátor játékokban a tőrbe csalásnak van helye. Összességében véve úgy gondolom, ebben elég sok kiaknázatlan lehetőség van (no pun intended.).

A többlépéses minta alapú AI kapcsán jutott eszembe, hogy lenne értelme egyfajta visszacsatolást beépíteni a minták használatába. Ahhoz, hogy az AI eldöntse, hogy melyik mintát alkalmazza, valamilyen értékelési rendszert kell követnie, és a minták pontszámai alapján kell kiválasztania, hogy az adott helyzetben melyik a megfelelő. Ebbe az értékelési rendszerbe lehetne integrálni egy olyan mutatót is, hogy az adott játszmában/környezetben alkalmazott minták közül melyik hányszor volt sikeres, illetve hányszor bukott el. A sikerességnél természetesen lehet egy olyan fokmérő is, hogy mennyire volt sikeres, de ezt nem minden esetben könnyű mérni, nyilvánvalóan.

A sikeresség fokmérője lehet egy sima skála. Középről indul, a sikeresen használt minta növeli, a sikertelen/félbeszakított minta csökkenti a mutatót. Ha tudunk a sikerhez-sikertelenséghez fokmérőt/pontszámot rendelni, akkor annyival növelhetjük-csökkenthetjük az adott értéket, ellenkező esetben pedig csak eggyel.

Ugyanakkor van értelme annak is, hogy két értékben tároljuk a sikerek és hibák számát. Ebből az előző érték ugyanis számolható, ugyanakkor a szórást, azaz a minta esetében a kockázatot is meg lehet belőle határozni. Nyilvánvalóan, ha rossz az aktuális helyzetünk, akkor nem akarunk nagyon kockázatos lépésekbe belevágni – vagy minden mindegy alapon éppen bele is vághatunk, de ez már személyiség kérdése. Igen, az AInak is lehet személyisége, mint azt már sok stratégiai játékban láthattuk is.

Egy probléma van ezzel a módszerrel: a nehézségi szint beállítása. A tanuló ellenfélnél nehéz beállítani egy nehézségi szintet, hiszen tanul, ennél fogva folyamatosan fejlődik, és egyre erősebb lesz. Valószínűleg fogok azon is elmélkedni a közeljövőben, hogy milyen módon lehet megoldani egy önszabályozást, amitől sem túl buta, sem túl okos nem lesz az ellenfél.

Egy pár éve, azt hiszem, az egyik Mérő könyv kapcsán az egyik bátyám mondta, hogy szeretne egy olyan táblás játékot fejleszteni – már nem emléxem, melyik volt az – amiben nem elsősorban az aktuális helyzet értékelése alapján dönti el a gép, hogy mit lép, hanem alkalmaz többlépéses patterneket is. Tudtommal manapság a sakk programok is alkalmaznak hasonló stratégiákat.

Felmerült azonban bennem a kérdés, hogy mi van akkor, ha hasonló alapon próbálunk összetettebb játékokhoz írni AI-t. Azon túl, hogy az AI-nak fel kell ismernie, hogy az adott helyzetben melyik pattern használható egyáltalán, és azon felül, hogy képesnek kell lennie egy patternből kilépni, ha megváltozik a szituáció, vannak kevésbé nyilvánvaló kérdések is.

Egyrészt, ki kell találni, hogy milyen jellegű, és egyáltalán, milyen hosszú (hány lépésből álló) mintákról beszélünk. Az sem mindegy, hogy milyen, az aktuális kontextusnak megfelelő változókat illesztünk bele – ha túl kevés van, akkor nem elég rugalmas, ha túl sok van, akkor nem elég értékes – és nyilván az is elég fontos, hogy egyáltalán milyen jellegű játékról beszélünk, hiszen egy stratégiai játékban egészen más sablonok vannak, mint egy lövöldözősben vagy egy szimulátorban.

Az elkövetkező napokban szerintem sokat fogom ezen jártatni az agyam, és ha bármi értékeset szülök, azt szerintem megosztom majd itt..

A grafikában már egészen jól ismert fogalom a shader: gyakorlatilag egy pixelre vagy képegységre eső árnyalatot tudunk vele kiszámolni nagyon gyorsan, hardveres támogatással, és ha jól tudom, párhuzamosan.

Mivel a napokban a játékok AI részével kezdtem el foglalkozni, elgondolkoztam rajta, lenne-e létjogosultsága egy olyan hardvereszköznek, amivel AI behaviour-t lehetne párhuzamosan számolni. Mivel napjaink játékaiban egyre nagyobb szerepet kap a realisztikus viselkedés, az AI egyre bonyolultabb lesz, ami viszont azt jelenti, hogy sok egységre kiszámolni a viselkedést bizony elég megterhelő lehet a processzor számára. Ugyanakkor az AI-k (legalábbis a döntéshozó rész; itt nem vonom bele a szenzoros inputot) nagyon gyakran egy viszonylag könnyen leírható logika szerint működnek: állapot átmenetek vagy feltétel vizsgálatok, esetenként véletlenszerű módosításokkal. Ez azt jelenti, hogy az AI programozáshoz egy viszonylag egyszerű nyelvet lehetne alkotni.

A fentiekből számomra az következik, hogy simán meg lehetne csinálni, és talán érdemes is lenne. Az is nyilvánvaló, hogy ez nem egy egy emberes vállalkozás. Azért kíváncsian várom, mikor és ki fogja ezt kitalálni