Ugrás a tartalomhoz

Alkalmazott Mesterséges Intelligencia

Dudás László (2011)

Kempelen Farkas Hallgatói Információs Központ

Tanulás multi-ágens környezetben

Tanulás multi-ágens környezetben

A 2.10 pont ismertette a multi-ágens robotrendszerek fogalmát. A multi-ágens rendszerek működése speciális előkészületet feltételez. Russell és Norvig (2000) szerint egy ilyen mechanizmusban a konfliktusok elkerülése érdekében az ágensek közös, multi-ágens tervet (MAP) készítenek. A terv az összes ágens valamennyi jövőbeli cselekedetét illetve interakcióit tartalmazza. Végrehajtásával párhuzamosan azonban az ágensek folyamatosan módosítanak rajta. Centralizált tervezés esetén létezik egy koordinátor ágens, ami minden részleges és lokális tervet megkap a többiektől. Ezeket analizálja inkonzisztenciák és konfliktusok után kutatva. Az esetlegesen módosított lokális tervekből ez az ágens készíti el a multi-ágens tervet. A koordinátor szerep ágensekhez rendelése dinamikusan is történhet. Az elosztott multi-ágens tervezés alapgondolata az, hogy minden ágens rendelkezik elképzeléssel, modellel a többi ágens terveit illetően. E modellek és persze saját terveik felépítése és karbantartása érdekében az ágensek folyamatosan kommunikálnak egymással egészen az esetleges konfliktusok megszűnéséig. Mivel a multi-ágens tervezés esetén nagy mennyiségű információt kell feldolgozni, plusz ezeknek el is kell jutniuk az ágensekhez, ezért lassú.

A következőkben a multi-ágens robotrendszerek népszerű fajtáját, a robotfocizást vizsgáljuk meg közelebbről. Az alábbi ábrán a 2010-es isztambuli versenyről láthatunk képeket, különféle robotkategóriákban.

Robotfoci mérkőzések

Egy izgalmas részletet mutat a következő film: video lejátszás

A robot foci versenyeit Amerikában a RoboCUP keretében, míg Európában és a Távol-Keleten a FIRA (Federation of International Robot-soccer Association), a Nemzetközi Robotfoci Szövetség által koordináltan rendezik. A Szövetség a világméretű összeméretésekre több kategóriát szabványosított. Ezek a Szövetség honlapja (FIRA, 2011) szerinti fő kategóriák a következőkben kerülnek bemutatásra.

Robotfoci kategóriák

HuroSot – (Humanoid Robot World Cup Soccer Tournament, vagy rövidebben Humanoid Robot Soccer Tournament) Humanoid robotok: kétlábú, max. 150cm magas, max. 30kg tömegű távirányítású, vagy autonóm vezérlésű emberszerű robotok. 340-430cm x 250-350cm viszonylag szabadon választható játékmező. Lásd pl.: http://www.youtube.com/watch?v=4wMSiKHPKX4

HuroSot mérkőzés

AMiRESot – (AMiRE Soccer Tournament) AMiRE-robotok, Csapatonként 1 robot, fedélzeti látórendszerrel, teljes autonomitással. Sárga teniszlabda, 130cmx90cm-es játéktér.

AMiRESot robot és pálya

NaroSot – (Nano-robot Soccer Tournament) A csapatok egy kapusból és négy mezőnyjátékosból állnak. Mind a két csapatnak saját központi számítógépe van, mely a pálya közepe felett elhelyezett kamera képe alapján észleli a résztvevőket és a labdát és koordinálja a saját csapat játékosait. A robotok tetején a csapatok megkülönböztetésére és a robotok orientációjának meghatározására alkalmas színezés, mintázat van. A robotok legfeljebb 4cmx4cmx5.5cm-esek lehetnek, kivéve az antennát, mely magasabb lehet. A labda egy narancs színű pingponglabda. A játéktér 130cmx90cm. Lásd pl.: http://www.youtube.com/watch?v=1JJsBFiXGl0

NaroSot robot és pálya

AndroSot – (Android Soccer Tournament) Távirányított, max. 0.6kg, max. 50cm magas robotok, 220cm x 180cm-es játéktér.

AndroSot mérkőzés

RoboSot – (Robot Soccer Tournament) A csapatok 1-3 robotból állhatnak, egyikük lehet kapus. A robotok távirányítottak, vagy autonómok egyaránt lehetnek, távirányítás esetén a központi számítógép a robotok fedélzeti kamerájának, azaz a szemeiknek az információját dolgozhatja fel. A robotok legfeljebb 20cm x 20cm alapterületűek lehetnek, tetszőleges magassággal. A labda egy sárga és világoszöld színekkel rendelkező teniszlabda, a pálya 260cm x 220cm-es.

RoboSot robot

SimuroSot – (Simulated Robot Soccer Tournament) Szimulált robot futball, csak a számítógép képernyőjén zajlik. A számítógépen futó szerver program nyújtja a játékteret, robotok megjelenítését, eredménytáblát, stb., míg a két kliens program a játékstratégiákat. Öt öt ellen, vagy tizenegy tizenegy ellen játszik a csapatokban.

SimuroSot képernyő

MiroSot – (Micro Robot Soccer Tournament), a NaroSot nagyobb méretű megfelelője, háromfős csapatok, melyből egy kapus lehet, 7,5cm x 7.5cm x 7.5cm maximális robotméret, melybe az antenna nem számít bele, narancsszínű golflabda, 400cm x 200cm, vagy 220cm x 180cm pályaméret jellemzi.

MiroSot robot

A következőkben egy, az előző két kategória ötvözeteként felfogható alkalmazást mutatunk be (Tóth P. 2010) alapján, mely a MiroSot szabályrendszerével valósít meg egy robotfoci szimulációt.

Egy virtuális robotfoci alkalmazás

Millington és Funge (2005) szerint a legtöbb mesterséges intelligenciát használó játék általános modellje 3 részből áll:

  • Stratégia

  • Döntéshozatal

  • Mozgás

MI alapú játékok modellje

A játék a (játék)világban zajlik. Az innen származó hatások, információk bekerülnek az ágens team ismeretei közé – érzékel -, majd a csoport mesterséges intelligenciája stratégiát dolgoz ki a reagálásra. Ezt az egyes ágensek felhasználják a döntéshozó algoritmusaik segítségével a pillanatnyi információk birtokában a következő lépés meghatározására, majd a mozgásgeneráló algoritmusaik generálják a mozgásokat. Végül a mozgások animálása a megfelelő fizikai törvények betartása mellett lezajlik a játékvilágban.

Egyszerűbb játékoknál egyes összetevők elmaradhatnak, pl. a fizika 2D-s animációknál, vagy a stratégia ügyességi szimulációs játékoknál, egyszereplős játékokban. A megcélzott MiroSot robotfoci szimulációban elmarad a fizikai modellezés.

Stratégia

Ebben a kategóriában MI algoritmusok vannak, amelyek nem csak egyetlen robotot irányítanak, hanem a csapat egészének a viselkedésére hatással vannak. Minden robotnak a csapatban saját döntéshozó és mozgási algoritmusa van, de általában a saját döntéshozó algoritmusukra hatással van a csoportstratégia.

Döntéshozatal

A döntéshozatal tartalmazza a megoldási algoritmust arra vonatkozólag, hogy egy robot mit fog tenni a következő lépésben. Általánosságban egy játékban többféle karakter is szerepelhet. A nagyon eltérő karakterek nagyon különböző viselkedéssel rendelkezhetnek, így választhatnak végrehajtási formát, amelyek például a következők lehetnek: támadás, egy helyben állás, rejtőzködés, felderítés, járőrözés, védekezés, stb. A döntéshozó rendszernek meg kell oldania, hogy melyik ezen viselkedések legmegfelelőbbike. A választott viselkedést ezután végre lehet hajtani felhasználva a mozgást és esetleg az animációs technológiát. Egy karakternek elég egyszerű szabályai lehetnek a lépés kiválasztásra. A robotfoci játékban a mezőnyjátékos, a kapus és a labda viselkedik szereplőként, melyeknek az őket érő hatásokra reagálniuk kell, megfelelő döntések meghozása formájában.

Mozgás

A mozgás modul olyan intelligens algoritmusokra hivatkozik, amelyek valami fajta mozgást generálnak egy bizonyos döntés hatására. A mozgási algoritmusok sokkal összetettebbek lehetnek, mint az egyszerű önvezérlések. A robotoknak, vagy ágenseknek szükségük lehet arra, hogy kikerüljék az akadályokat az úton, vagy akár arra is, hogy például átküzdjék magukat a szobák egy sorozatán. Vannak játékok ahol sok akciót közvetlenül animációval hajtanak végre (pl.: Amikor mászási akciót akarunk, akkor lejátszódik egy mászás animáció). A robotfoci játékban ez a komponens van jelen a legerősebben, hiszen a döntéseknek összetett, célirányos mozgásokat kell eredményezniük.

A fenti ábrával ismertetett, mesterséges intelligencia alapú játékalgoritmusok mellett a játékokban általánosságban még igen sokféle, mesterséges intelligenciát nem igénylő algoritmus, működés van jelen. Ezek közül az animációs és az újabb játékokban megjelenő fizikai modellezést az ábra is jelzi, mint igen komoly matematikát és kódot igénylő részeket. Hasonlóan kódigényes rész a felhasználói interfész. Mindezek programozói munkaigénye általában meghaladja a mesterséges intelligenciát képviselő rész igényét. Robotfoci alkalmazásunk ebből a szempontból kivételnek tekinthető, mivel nem igényel jelentősebb felhasználói beavatkozás kezelést és a kimenetben csak nagyon egyszerű helyváltoztató mozgások animációja fog szerepelni.

A realizálást ágens alapon végezve hangsúlyozzuk, hogy az alkalmazás autonóm robotokból fog állni, melyek információt kapnak a játék mindenkori állásáról, előre meghatározzák, hogy milyen akciókat hajtsanak végre az információk alapján és végrehajtják azokat. Ez egy alulról felfelé építkező modell. Kezdésként kidolgozzuk, hogy hogyan viselkedjenek az ágensek és az implementálás során az MI-nek támogatnia kell azt. Az egész játék átfogó viselkedése egyszerűen csak annak a függvénye, hogy hogyan viselkedik az egyéni robotjátékos együttműködve a többiekkel.

Döntési Fa

Mint már korábban láttuk, a döntési fa gyors, egyszerű implementálni és könnyű megérteni. Sok mindenre használható, az animációktól elkezdve a komplett stratégián át az MI taktikáig. A döntési fát lehet tanítani is és a tanulási fa még nagyobb mozgásteret enged a programozónak. Minden választás a robotjátékos tudásanyagán alapul. Mivel a döntési fákat gyakran használjuk, mint egyszerű és gyors döntési mechanizmusokat, ezért az ágensek általában közvetlenül hivatkoznak a globális játékállásra, mintsem hogy ábrázolják azt (értelmezzék, hogy mit tudnak személy szerint). A fa minden levele egy rögzített akció. Mikor a döntési algoritmus megérkezik egy akcióhoz, akkor azt azonnal végrehajtja. A legtöbb falevél egyszerű döntésekből áll, általában csak két lehetséges válasszal.

A következőkben a részletezést a (Tóth P., 2010) irodalom felhasználásával, a szerző engedélyével végezzük.

A program által használt döntési fa

Minden játékosnak, kivéve a kapusokat, két döntési fájuk van. Az egyik akkor lép életbe, ha az ágensnál van a labda, a másik akkor, ha nem nála van a labda, hanem az ellenfélnél.

Döntési fa 1

Alapvetően a döntési fa két részre osztható. Az egyik az, amikor a játékos a kapu közelében van, a másik az, amikor még nincs a kapu közelében. Mind két részben vannak azonos részek, amelyek a következők. Ha az ágenst támadják, akkor megnézi, hogy tud-e passzolni. Ha tud, akkor elindítja a passzolási akciót a ’Passzolas()’ metódus meghívásával, ami a társához juttatja a labdát. Ha nem tud passzolni, akkor felszabadít és az ellenfél leghátsó játékosának a háta mögé rúgja a labdát. Erre mindkét csapatnak külön metódusa van. Az eltérő részek pedig a következők. Ha senki nem támadja a játékost és a kapu közelébe jutott, egy bizonyos területen belülre, akkor ellövi a labdát (erre szintén különböző metódusokat használ a két csapat). Ha viszont még nincs a kapu közelében, akkor annak irányába tovább viszi a labdát.

Döntési fa 2

Az előzőhöz hasonlóan ez is két részből áll. Az egyik rész az, hogy az ellenfél támadójánál van a labda, a másik az, hogy az ellenfél védőjénél van a labda. Ezeken belül az egyes részek azonosak. Ha tudom közvetlenül támadni, akkor megtámadom az ellenfelet és megpróbálom mögé rúgni a labdát, ha nem akkor megyek segíteni a kapusnak.

A döntési fákba és azon belül is a legtöbb metódusba csak úgy lehet belépni, ha a csapattárs és az ellenfél se nem passzol, se nem próbál felszabadítani, se nem lő.

A Szinkronizációs osztály

A választott Java nyelv lehetővé teszi a programok több szálon történő végrehajtását. Erre amiatt van szükségünk, hogy a résztvevők autonóm viselkedését biztosíthassuk. A Java szálakat a Java Virtual Machine (VM) folyamata által az operációs rendszer szintjén létrehozott szálak valósítják meg. A Java szálakhoz prioritást rendelhetünk, amelyet a Java továbbít az operációs rendszer ütemezőjének. Az operációs rendszer és a hardver lehetőségeitől függően a szálak párhuzamosan kerülnek végrehajtásra. A Java VM-ben (Benkő – Tóth, 2007) szerint kétféle szál létezhet:

  • démon (daemon) és

  • nem-démon (non-daemon) szál.

Kezdetben egy nem-démon szál jön létre, amely elkezdi végrehajtani a megadott osztály induló metódusát. A Java VM akkor áll le, ha az utolsó nem-démon szál futása is befejeződött. A démon szálak arra valók, hogy a háttérben szolgáltatásokat, illetve egyéb tevékenységeket valósíthassunk meg anélkül, hogy ez a tevékenység a Java VM leállását megakadályozná.

Tehát a Java-ban a java.lang.Thread osztály segítségével több szálon futó alkalmazásokat fejleszthetünk. A szálakat a Thread osztály és leszármazottainak példányai valósítják meg. A Thread példány elindításakor a példány run() metódusát hajtja végre egy önálló szálon.

Szálat kétféleképpen hozhatunk létre:

  • A Thread osztályból leszármaztatunk egy új osztályt, melyben a run() metódust felüldefiniáljuk,

  • vagy egy a Runnable interfészt megvalósító osztály egy példányát adjuk át a Thread osztály konstruktorának.

A Runnable interfész egyetlen run() metódust tartalmaz, használatára általában akkor van szükség, ha a run() metódust tartalmazó osztály nem származhat a Thread osztályból.

Többszálú programozás esetén szükség van a szálak szinkronizálására amennyiben azok közös adatokon dolgoznak. A szinkronizálásnak több célja is lehet:

  • kölcsönös kizárás (mutual exclusion), szemafor (semaphore), kritikus szakasz (cricital section),

  • randevú (randezvous), az egyik szál felfüggeszti futását, amíg a másik be nem fejeződik,

  • várakozás egy másik szálon történő valamely esemény bekövetkeztére (wait()),

  • stb.

A szinkronizált működéshez szükséges metódusokat synchronized módosítóval kell ellátni, valamint az Object osztályból örökölt notify() metódussal kell „felébreszteni” az épp „alvó” szálat.

Ütközések kezelése

Első Megoldás

Ezt a megoldást szokták általában használni a versenyen induló csapatok. (Mihaletzky, 2009) szerint

 

A labda és a játékosok közötti ütközések vizsgálata 3 fő részre osztható.

  • Az elsődleges vizsgálat során egy PtInRect nevű függvény segítségével vizsgáljuk a labda pontjait (Point), hogy vajon belül vannak-e valamelyik játékos (Rectangle) területén. Külön-külön kerül kiértékelésre a vízszintes és a függőleges irányú ütközés a labdával, és amennyiben teljesül valamelyik ütközési feltétel, akkor az adott logikai változó ’true’ értéket vesz fel, így a program további futása során lekezeljük az irányváltásokat. Viszont amikor két egymást követő időpillanatban ugyanazon ütközési feltétel teljesül, a labda állandó irányváltása miatt beragad a játékosba, és annak felületén rezegve végigfut. Ennek kiküszöbölésére egy 2*6 elemű tömb segítségével nyilvántartjuk minden robot esetében az egymást közvetlenül követő ütközések logikai értékeit, így ha két egymást követő ciklusban kétszer kerülne sor irányváltásra ugyanazon robot és a labda között, akkor ’false’ értékűre állítjuk az ütközés logikai változót és a labda zavartalanul haladhat tovább pályáján. A tömb sorai a robotokat modellezik, míg a két oszlop érték két egymást követő időpillanat során bekövetkező ütközések logikai értékeit tartja nyílván. Minden ciklusban az első oszlopérték áttöltésre kerül a második oszlopérték helyére. Miközben az első helyére az aktuális ütközési feltételnek megfelelő érték töltődik be újra, egy egyszerű összehasonlítással vizsgálható, hogy azonos értékeket tartalmaz-e a két oszlop.

  • Ez egy másodlagos vizsgálatot jelent. Ennek ellenére a tesztelési tapasztalatok alapján szükségessé vált még egy harmadik vizsgálat elvégzése, ami az előző kettő után esetlegesen bekövetkező pontatlanságokat orvosolja.

  • Képzeletben minden robotot négy részre darabolunk úgy, hogy függőlegesen is, és vízszintesen is egy oldalfelező vonallal kettévágjuk a játékost. Ezután minden negyedben azt vizsgáljuk, vajon a labda középpontja beleesik-e valamely robotszeletbe. Ha igen, akkor könnyen belátható, hogy az ütközés még nem teljesült az előző vizsgálatok során, így attól függően, hogy mely negyedben található a labda centruma, a szükséges irány- és előjelváltásokat elvégezzük a labda tekintetében. Ez a harmadik módszer egy erőteljes irányváltást eredményez, amely során a robot nagy sebességgel elrúgja magától a labdát.

    A robotok közötti ütközések lekezelése ugyanazt a technikát követi, mint ahogy azt a labda-robot ütközések előbbi vizsgálata során láttuk. A két eljárás között annyi eltérés van csupán, hogy itt a pont szerepét az egyes robotok sarkai jelentik, és ezeket a pontokat vizsgáljuk, hogy vajon bent vannak-e valamelyik játékos területén. Ezt a feltételvizsgálatot is a PtInRect függvény segítségével végezzük.

 
 --Mihaletzky, 2009

Második Megoldás

Az általunk használt megoldás a következő: Egy logikai változó beállítását végezzük el egy metódus segítségével, ami ellenőrzi, hogy a labda elérte-e a játékost. Az ellenőrzés megvalósítását a következő programrészlet végzi.

public void ellenorzes() {
 bumm = false;
 if (labda[0]+2 > (kocka[0]))                        //balról vizsgál
  if (labda[0] < (kocka[0]+kocka[2]+2))        //jobbról vizsgál
   if (labda[1]+2 > (kocka[1]))                      //felülről vizsgál
    if (labda[1] < (kocka[1]+kocka[3]+2))      //alulról vizsgál
	bumm = true;
}

							

A metódusban mindig a labda helyzetét viszonyítom a játékos helyzetéhez: x és y koordinátáihoz. Az ellenőrzés megtörténte után, ha a logikai változó a ’true’ értéket veszi fel, jelzi, hogy a labda hozzáütközött az objektumhoz. Ezt a fajta ellenőrzést mind a kapusnál, mind a kapunál elvégezzük, így két külön akció történik akkor, ha a kapus kivédte a lövést, vagy ha gól született.

Követés

A védőnek, támadónak és kapusnak mindig követniük kell a labda mozgását. A védőnek és a kapusnak azért, hogy elé állva megakadályozzák, hogy az ellenfél gólt szerezzen, a támadónak pedig azért, hogy gólt tudjon szerezni. Mindhárom szereplő azonosan követi a labdát, bár a kapusnak van némi megkötése.

A példaprogramról készült következő kép az egyik szál által kezelt, labdát követő játékost mutatja, aki csak bizonyos területen tartózkodhat, míg a másik szál által kezelt játékos egy másik területen belül mozoghat csak. A labda szintén egy külön szálat képvisel, ezen három szál szinkronizálva működik. Az ábrán látható, hogy amíg a védő játékos a saját térfelén belül szabadon követi a labdát, addig az ellenfél térfelére jutott labdát a védő csak vertikálisan követi, mert nem léphet át az ellenfél játékos térfelére.

A saját térfelén a játékos követi a labdát, az ellenfél védőjátékosa a saját térfelén marad

Attól függően, hogy milyen szerepet tölt be az ágens a programban, a védő és a támadó is csak adott területen belül mozoghat és ezt a területet nem hagyhatja el.

A főprogram folyamatábrája

Az alábbi ábrák tartalmazzák a focipálya alaprajzát és rajta a játékosokat elhelyezkedve attól függően, hogy melyik csapat kezd. A fociban csapatonként három robot vesz részt.

  • Támadó,

  • Védő,

  • Kapus.

Mindhárom gondolkodásáról és mozgásáról külön szál gondoskodik. A játék elején a főprogramban elindítjuk az egyes játékosok szálait és a labda szálát. Ezen felül ugyancsak ekkor töltjük be a játéktér háttérképét, a játékosok, a labda és a gól képét. A főprogramban íratjuk ki még a játék állását és gondoskodunk a gól kijelzéséről. Minden egyes gól után a játékosok újból középkezdést végeznek.

Alapfelállások

A támadási mechanizmus

Alapvetően mind a támadó mind a védekező robot tud támadni, bár csak a támadó robot kerül a kapu közelébe. Mihelyst egy meghatározott területen belül találja magát az éppen támadó ágens, elindítja a saját csapatának megfelelő lövési metódust. Az adott metódust csak akkor lehet elindítani, hogy ha a csapattársa (aki nem a kapus) és a másik két ellenfél (az ellenfél támadó és védő játékosa) semmilyen más metódust nem hajt végre. A metódus egy akciót bonyolít le, ahol a támadó kapura lövi a labdát, amit a kapus vagy kivéd, vagy esetleg nem tud kivédeni. A lövés befejezésével ha a kapus kivédte a labdát és még nem passzolta le a hozzá legközelebbi játékosnak, úgy a támadó megpróbálhatja megtámadni a kapust és így még egyszer esélye nyílhat gólt lőni.

A kapu védésének mechanizmusa, az ellenfelek közötti kapcsolatok és a gól

A kapusok feladata nyilvánvaló: megakadályozni, hogy az ellenfél gólt szerezzen. Csak a kapu keretein belül mozoghatnak és csak akkor tehetik azt, ha a labda egy bizonyos területen belülre érkezik. A kapu külön objektum a kapus háta mögött. Létezik a kapufa fogalma is, ha a kapu szélét el is találja a labda, akkor sem gól. A kapus nem jöhet ki a kapujából, csakis az y tengely mentén mozoghat. Ha a labda elhagyta a veszélyzónát, a kapus visszaáll középre. Ha a kapus kivédte a labdát, akkor a hozzá legközelebb álló csapattársának próbálja passzolni. Ha nem passzol időben, akkor az ellenfél megtámadhatja.

Mindig két játékos – a két csapat egy-egy játékosa – mozog a leggyorsabban a labda irányába, a másik kettő csak kisebb sebességgel követi a labdát. Azért, hogy mindegyik játékos látható legyen a képernyőn, a játékosok nem fedhetik le egymást teljesen, mindig van látható különbség közöttük. Van egy metódus, ami arra hivatott, hogy színesebbé tegye a játékot. Ez a metódus a ’JobbvsBal()’, ami azt eredményezi, hogy a játékosok, ha túl közel kerülnek egymáshoz, akkor csatáznak, ami hatására az egyik játékos arrébb löki a másikat.

Annak érdekében, hogy ne számoljon a program egyetlen kapuérintésnél több gólt a kelleténél, késleltetés van két gól között, ami minimum 2 másodperc. Ha valamelyik csapat gólt kapott, a két csapat állását jelző szöveg alá kiíródik a „Góóóóóól!!!” felirat piros betűkkel és 2 másodpercig marad a képernyőn, majd eltűnik. Ezután újbóli középkezdés jön.

A gól kiírása

A fenti ábrán látható az előzőekben leírt kiírás a kapott gól után. A középkezdést mindig az a csapat kezdi, amelyik kapta a gólt és így kezdődhet előröl a játék.

A labda mozgásirányításának szála

A labda saját magától nem mozog. Ebben a szálban ellenőrizzük, hogy nekiütközik-e valaminek, szabályozzuk az ütközés hatását, itt számoljuk a gólokat, aktualizáljuk a mérkőzés állását, valamint ezen a helyen található több metódus:

  • Passzolás

  • A jobb csapat felszabadítási metódusa

  • A bal csapat felszabadítási metódusa

  • A jobb csapat lövési metódusa

  • A bal csapat lövési metódusa

Passzolás

Ebben a metódusban megadhatjuk paraméterként, hogy melyik játékosnak szeretnénk passzolni a labdát. Az akció úgy zajlik le, hogy addig növeljük, vagy csökkentjük a labda x és y koordinátáit, ameddig el nem ér a passz az adott emberhez.

A felszabadítási metódus

A védekező csapat azt figyeli ilyenkor, hogy az ellenfél csapat támadója és védője közül melyik helyezkedik el a saját kapujához a legközelebb és annak háta mögé rúgja a labdát.

A lövési metódus

Ha az ágens egy bizonyos területen belülre ér és lehetősége van rá, tehát senki nem áll az útjába, akkor elindul a lövési mechanizmus. Ez a metódus megpróbálja a labdát a kapu egy adott pontjára lőni azt és ezáltal gólt szerezni. A lövés addig tart, amíg vagy gól nem születik, vagy a kapus ki nem védi a labdát.

Közös információk

A játékosoknak vannak közös információik, amiket a környezetükből nyernek ki, és amik alapján befolyásolni tudják azt. Ezen részt tartalmazza a „Kozos” osztály. Ebben az osztályban többféle metódus szerepel.

  • ’Tavolsag()’: ebben a metódusban a metódus paramétereiben megadott játékos és a labda távolságának kiszámítása történik, amivel a metódus visszatér.

  • ’JobbMehet()’: a programrészlet kiszámítja mind a jobbtámadó, mind pedig a jobbvédő távolságát és ez alapján dől el, hogy ki van közelebb a labdához.

  • ’BalMehet()’: ennél a résznél értelemszerűen a baltámadó és balvédő távolságának kiszámítása jön létre és az előzőhöz hasonlóan a döntés is megszületik.

  • ’JobbvsBal()’: ezen metódusban az kerül kiküszöbölésre, hogy a két közvetlenül egymás ellen focizó játékos lefedje egymást és így valamelyik játékos ne látszódjon a képernyőn. Ha a védő és a támadó csatázik egymással, akkor mindig a védő pozíciója változik. Ha viszont a két védő, vagy a két támadó harcol, akkor random szám generálásával dől el, hogy melyik pozíciója változzon. A pozíció mindig ugyan abba az irányba tolódik el, így van, amikor előnyre tesz szert az adott játékos, van amikor pedig hátrányra.

  • ’Kinelvan()’: itt számoljuk ki, hogy melyik játékos van közelebb a labdához, a játékos és a labda, valamint a többi játékos és a labda távolságának kiszámításával, illetve a játékos és a labda távolságának egy adott értéken belüli egyezőségével.

A működő játékot itt nézhetjük meg:

Multi ágens robot foci program

video lejátszás