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