Bakaláˇrská práce Implementace inteligentn´ıch bot˚u pro
Transkript
Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetnı́ techniky Bakalářská práce Implementace inteligentnı́ch botů pro UT2004 v Pogamut podle J. Orkina Plzeň 2010 Tomáš Ettler Prohlášenı́ Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitı́m citovaných pramenů. V Plzni dne 12. května 2010 Tomáš Ettler Abstract This work is about exploring possibilities of using A Star algorithm to control bots in a computer action game. The original model was taken from the game F.E.A.R. which includes J. Orkin’s implementation of the A Star algorithm. Results of the work were implemented by the means of the Pogamut 3 system, which was developed at Charles University in Prague. The system uses Java language for programming and computer game Unreal Tournament 2004 as a virtual environment. The aim of this work is to identify advantages and disadvantages of this algorithm. Obsah 1 Úvod 1.1 Seznam použı́vaných pojmů a zkratek . . . . . . . . . . . . . . 1 2 2 Použı́vané způsoby pro řı́zenı́ AI 2.1 Podmı́nková pravidla . . . . . . . . . . . . . . . . . . . . . . . 2.2 Konečný stavový automat . . . . . . . . . . . . . . . . . . . . 3 3 4 3 Analýza algoritmu ve hře F.E.A.R. 3.1 Použı́vané prostředı́ . . . . . . . . . 3.1.1 GBDEdit . . . . . . . . . . 3.1.2 WorldEdit . . . . . . . . . . 3.2 Popis hernı́ AI . . . . . . . . . . . . 3.2.1 Cı́le . . . . . . . . . . . . . 3.2.2 Akce . . . . . . . . . . . . . 3.2.3 Přı́klad cı́lů a akcı́ . . . . . 3.3 Změna chovánı́ . . . . . . . . . . . 3.4 Testovánı́ chovánı́ bota . . . . . . . 3.4.1 Tvorba mapy . . . . . . . . 3.4.2 Nastavenı́ AI . . . . . . . . 3.4.3 Spuštěnı́ mapy . . . . . . . 4 Software Pogamut 3 4.1 Princip a prostředı́ . . . . 4.2 Řı́zenı́ botů . . . . . . . . 4.3 Navigace botů po mapě . . 4.4 Moduly . . . . . . . . . . 4.4.1 Senzorické moduly 4.4.2 Přı́kazové moduly . 4.5 Problémy . . . . . . . . . 4.6 Dalšı́ možnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 5 6 6 7 9 11 12 12 13 14 14 . . . . . . . . 17 17 18 18 19 19 19 20 20 OBSAH OBSAH 5 Implementace 5.1 Rozdı́ly hry F.E.A.R. a UT2004 . 5.2 Třı́dy v projektu . . . . . . . . . 5.2.1 GoalBot.java . . . . . . . 5.2.2 AI.java . . . . . . . . . . . 5.2.3 AStarNode.java . . . . . . 5.2.4 World.java . . . . . . . . . 5.2.5 Akce a cı́le . . . . . . . . . 5.3 Informace o světě . . . . . . . . . 5.3.1 Porovnávánı́ světa . . . . 5.4 Akce a cı́le . . . . . . . . . . . . . 5.4.1 Výběr cı́lů . . . . . . . . . 5.4.2 Výběr akcı́ . . . . . . . . . 5.4.3 Prováděnı́ akcı́ . . . . . . 5.4.4 Přı́klad akce GoToEnemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 21 21 22 22 22 22 23 23 23 25 25 28 28 6 Testovánı́ a zhodnocenı́ použitého algoritmu 6.1 Testovánı́ bota . . . . . . . . . . . . . . . . . 6.2 Výhody . . . . . . . . . . . . . . . . . . . . . 6.3 Problémy . . . . . . . . . . . . . . . . . . . . 6.3.1 Jaké akce použı́t . . . . . . . . . . . . 6.3.2 Ohodnocenı́ akcı́ . . . . . . . . . . . . 6.3.3 Vı́ce akcı́ najednou . . . . . . . . . . . 6.3.4 Rychlost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 30 31 32 32 32 33 33 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4 1 Úvod Cı́lem této práce bylo zhodnotit implementaci A* (A hvězda) algoritmu k řı́zenı́ umělé inteligence (dále AI - artificial intelligence) a najı́t výhody a nevýhody, které s sebou tento algoritmus přinášı́. Předlohou bylo řı́zenı́ botů (postav řı́zených AI) v počı́tačové hře F.E.A.R., kde J. Orkin použil A* algoritmus k výběru akcı́ tak, aby dosáhl určitého cı́le. Tı́m se hra F.E.A.R. lišı́ od většiny ostatnı́ch akčnı́ch her, kde je chovánı́ postav řı́zených počı́tačem tzv. naskriptované, což vede k predikovatelnému chovánı́ postav při opakovaném hranı́. Algoritmus byl pro zhodnocenı́ implementován do počı́tačové hry Unreal Tournament 2004 pomocı́ software Pogamut 3. Nejprve bylo zapotřebı́ prozkoumat algoritmus umělé inteligence ve hře F.E.A.R. a zjistit, jak se boti chovajı́ v konkrétnı́m světě v závislosti na nastavenı́ proměnných (ohodnocenı́ akcı́, relevance cı́lů). Pro veřejnost byly uvolněny zdrojové kódy některých částı́ hry, a proto bylo možné zjistit podrobnosti o programové implementaci výběru akcı́ a cı́lů. Dále bylo zapotřebı́ seznámit se se strukturou systému Pogamut 3, zejména s částı́ pro řı́zenı́ botů. Pogamut je vyvı́jen na Matematicko-fyzikálnı́ fakultě Univerzity Karlovy v Praze a sloužı́ k propojenı́ hry UT2004 a kódu napsaného v jazyce Java. Využı́vá k tomu vlastnı́ plug-in do vývojového prostředı́ NetBeans. Tato práce mapuje chovánı́ AI ve hře F.E.A.R., představuje možnosti, které poskytuje A* algoritmus a zabývá se aspekty implementace do jiné hry, konkrétně do hry UT2004. 1 Úvod 1.1 Seznam použı́vaných pojmů a zkratek Seznam použı́vaných pojmů a zkratek AI Bot UT2004 umělá inteligence, zkratka z anglického Artificial Intelligence postava ve hře řı́zená umělou inteligencı́ zkratka pro počı́tačovou akčnı́ hru Unreal Tournament 2004, která byla použita pro testovánı́ umělé inteligence F.E.A.R. počı́tačová akčnı́ hra, jejı́ž umělá inteligence sloužila jako předloha pro tuto práci, zkratka znamená First Encounter Assault Recon Pogamut softwarová platforma pro vývoj virtuálnı́ch bytostı́, použitá k implementaci umělé inteligence NetBeans vývojové prostředı́ pro mnoho jazyků, ve kterém byla práce vyvı́jena IDE integrované vývojové prostředı́, z anglického Integrated Development Environment Java objektově orientovaný programovacı́ jazyk, který vyvinula firma Sun Microsystems GDBEdit program z vývojového balı́ku Public Tools, ve kterém lze editovat hernı́ databázi hry F.E.A.R. WorldEdit program z vývojového balı́ku Public Tools na tvorbu map do hry F.E.A.R. Goal cı́l; definuje, čeho chce bot dosáhnout GoalSet množina cı́lů, ze které umělá inteligence vybı́rá jednotlivé cı́le Action akce; definuje činnost, kterou bot může vykonávat a tı́m dosáhnout stanoveného cı́le ActionSet množina akcı́, ze které umělá inteligence vybı́rá jednotlivé akce Relevance hodnota, která udává prioritu cı́le při jeho výběru A* A hvězda algoritmus, který je založen na procházenı́ stavového prostoru, využı́vajı́cı́ heuristickou funkci pro nalezenı́ nejvýhodnějšı́ho řešenı́ Tabulka 1.1: Použité pojmy a zkratky 2 2 Použı́vané způsoby pro řı́zenı́ AI V dnešnı́ době se téměř ve všech počı́tačových hrách (ale nejen tam) využı́vá umělé inteligence k řı́zenı́ postav, které neovládá hráč. Umělá inteligence se snažı́ co nejvı́ce napodobit chovánı́ hráčů. Dva nejpoužı́vanějšı́ typy AI v tomto kontextu jsou uvedeny dále. 2.1 Podmı́nková pravidla Použitı́ podmı́nkových pravidel (if - then pravidla) patřı́ nejjednoduššı́m způsobům řı́zenı́ AI. Jedná se o soubor pravidel, která jsou v každém kroku zpracována v předem určeném pořadı́. Každé pravidlo obsahuje podmı́nku pro své uplatněnı́. Jakmile se v průběhu testovánı́ souboru pravidel narazı́ na prvnı́ splněnou podmı́nku, provede se daná akce a prohledávánı́ končı́. Tento systém pravidel je velmi jednoduchý, ale je vhodný pouze pro jednoduché úlohy. S přibývajı́cı́m počtem pravidel začne být systém nepřehledný a špatně se udržuje. 1. if see obstacle then change direction 2. if basketful of m. and picking then stop picking 3. if see mush. and picking then pick up the mush. 4. if midday and picking then stop picking 5. if home then END 6. if picking then move random 7. if not picking then move home Tabulka 2.1: Přı́klad if - then pravidel pro bota sbı́rajı́cı́ho houby [1] 3 Použı́vané způsoby pro řı́zenı́ AI 2.2 Konečný stavový automat Konečný stavový automat Konečný stavový automat (Finite State Machine - FSM) obsahuje všechny stavy, ve kterém se hra může nacházet a přechody, které zajišt’ujı́ změnu stavu. Na obrázku 2.1 jsou stavy znázorněny obdélnı́čky a obsahujı́ několik akcı́, přechody jsou znázorněny šipkami s podmı́nkami, kdy je možné daný přechod použı́t. AI se vyskytuje právě v jednom stavu, který se měnı́ použitı́m přechodu, u kterého je splněna podmı́nka. Obrázek 2.1: Ukázka konečného stavového automatu ze hry Shuruppak [2] Navrženı́ konečného stavového automatu je dı́ky jeho grafické reprezentaci poměrně jednoduché. Zde nastává problém v přı́padě, kdy počet možných stavů je přı́liš velký a jeho nastavovánı́ a laděnı́ se stává velmi nepřehledným. 4 3 Analýza algoritmu ve hře F.E.A.R. 3.1 Použı́vané prostředı́ Při analýze chovánı́ hernı́ AI bylo použito několik programů. Na změnu parametrů a tvorbu testovacı́ mapy byly použity vývojové nástroje The F.E.A.R. Public Tools od společnosti Monolith. Pozorovánı́ chovánı́ probı́halo v samotné hře F.E.A.R. a na zkoumánı́ zdrojových kódů hry bylo použito Microsoft Visual studio 2008. 3.1.1 GBDEdit GDBEdit (Game Database Editor, na obr. 3.1) je jeden z programů vývojářského balı́ku Public Tools. Stará se o správu hernı́ databáze, ve které jsou uloženy veškeré parametry pro chovánı́ hry, včetně chovánı́ AI. Parametry jsou zobrazeny ve stromové struktuře pro lepšı́ přehlednost. Obrázek 3.1: Program GDBEdit, vybrána množina akcı́ pro postavu Soldier (voják) 5 Analýza algoritmu ve hře F.E.A.R. 3.1.2 Popis hernı́ AI WorldEdit WorldEdit (World Editor, na obr. 3.2) je dalšı́ z programů balı́ku Public Tools. Jak již z názvu vyplývá, jedná se o editor hernı́ho světa, prostředı́, kde se hráč pohybuje. Modeluje se zde vzhled, ale také určujı́ pomocné body, podle kterých se orientuje hernı́ AI. Pomocné body obsahujı́ dodatečné informace o prostředı́, které musı́ nadefinovat návrhář mapy. Poskytujı́ informace pro umělou inteligenci, aby věděla, že právě zde je výhodné se schovat (bod Cover) nebo je výhodné zde zaútočit (bod Ambush). Některé akce právě těchto bodů využı́vajı́ nebo je vyžadujı́, aby mohli být provedeny. Umı́stěnı́m pomocných bodů se dá tedy ovlivnit A* algoritmus pro výběr akcı́. Pro umělou inteligenci jsou tyto informace totiž obtı́žně zjistitelné na rozdı́l od hráče, který správné mı́sto odhadne intuitivně. Dalšı́ body se pak využı́vajı́ k navigaci bota při nějaké události, napřı́klad při vytvářenı́ scénáře dané úrovně. Obrázek 3.2: Program WorldEdit s testovacı́ mapou 3.2 Popis hernı́ AI Ve hře F.E.A.R. byl použit jako v jedné z prvnı́ch her systém cı́lů (Goals) a akcı́ (Actions). Lišı́ se tı́m od mnoha her, kde je umělá inteligence pevně naskriptována a to omezuje hernı́ zážitek při opakovaném hranı́. Systém cı́lů a akcı́ je zajı́mavý tı́m, že nenı́ třeba nastavovat konkrétnı́ chovánı́ každé jednotce ve hře zvlášt’ podle jejı́ho umı́stěnı́, ale stačı́ vybrat množinu akcı́ a cı́lů a postavy se začnou chovat v závislosti na prostředı́. Je ale potřeba mı́t 6 Analýza algoritmu ve hře F.E.A.R. Popis hernı́ AI akce a cı́le správně ohodnocené. V prostředı́ hry (v hernı́m světě) jsou určeny body (v originále Nodes - uzly), což jsou mı́sta na mapě nutná pro konánı́ určité akce (např. útok nebo krytı́). Každá bytost ve hře má nadefinovanou množinu cı́lů (GoalSet), která určuje, jaké cı́le bude mı́t postava na výběr, a množinu akcı́ (ActionSet), kde jsou uvedeny akce, které k dosaženı́ vybraného cı́le může použı́t. Jako přı́klad může být množina cı́lů Stráž, cı́l Zabij nepřı́tele, množina akcı́ Voják a akce Útok nebo Nabı́t zbraň (podrobnějšı́ přı́klad viz dále). Tı́m se hráčům může zdát, že má každá postava svou vlastnı́ inteligenci. 3.2.1 Cı́le Jednı́m z hlavnı́ch úkolů bylo zjistit, jak si AI vybı́rá cı́le, které má plnit. Definice Cı́l je stav, kterého chce AI dosáhnout. Jsou nadefinovány podmı́nky, které musejı́ být splněny, aby cı́l byl uspokojen. Každý bot má svoji množinu cı́lů, ze které jednotlivé cı́le vybı́rá. Napřı́klad cı́l Zabij nepřı́tele má cı́lovou podmı́nku cı́l je mrtvý = ano [3]. Ke splněnı́ této podmı́nky a tı́m celého cı́le je třeba sestavit plán akcı́ (viz nı́že). Parametry cı́lů Každý cı́l je popsán několika parametry (viz obr. 3.3). Nejdůležitějšı́ je parametr Relevance, který určuje, zdali je cı́l relevantnı́ (v dané situaci použitelný) a jakou má prioritu. Je to hlavnı́ kriterium pro výběr, kdy se hledá maximálnı́ hodnota tohoto parametru. Uvedená hodnota v programu GDBEdit je ale pouze základnı́ hodnota, protože se situace ve hře samozřejmě měnı́ a je mnoho podmı́nek, který výběr ovlivňujı́. Proto má každý cı́l svůj zdrojový soubor v C++, kde jsou definované funkce, které relevanci vyhodnotı́. Relevance závisı́ na aktuálnı́ch informacı́ch o prostředı́, kde se bot právě nacházı́. Tyto informace jsou uložené v třı́dě BlackBoard (tabule) - viz dále. Dále jsou důležité parametry ActivateChance - což je pravděpodobnost vybránı́ cı́le; Frequency - doba v sekundách, za kterou je možné cı́l vybrat 7 Analýza algoritmu ve hře F.E.A.R. Popis hernı́ AI Obrázek 3.3: Parametry jednoho z cı́lů v programu GDBEdit znovu; RecalcRate - rozsah doby v sekundách, za kterou bude znovu vyhodnocena relevance (náhodná hodnota v tomto rozsahu); InterruptPriority - při konánı́ některých akcı́ se ještě vyhodnotı́, jestli má nový cı́l vyššı́ přerušovacı́ prioritu než aktuálnı́ cı́l a aby systém přeplánoval; MinAwareness a MaxAvareness - minimálnı́ a maximálnı́ hodnota Awareness bota (všı́mavosti, jestli je bot v klidu nebo v plné pozornosti). Důležitý je také seznam senzorů (Sensors), které cı́l využı́vá k vlastnı́ aktivaci. Při načı́tánı́ cı́le se načtou i tyto senzory, které hlı́dajı́ děnı́ okolo bota a měnı́ hodnoty o světě v BlackBoardu. Veškeré hodnoty lze měnit v programu GDBEdit (na obrázku 3.3), který je součástı́ vývojářského balı́ku ke hře F.E.A.R. Pro editaci je potřeba v programu načı́st hernı́ databázi (otevřenı́m z pevného disku počı́tače ze složky Dev\Runtime\Game\Database). Vlevo je stromová struktura, kde je třeba rozbalit položku AI a v nı́ Goals. Zobrazı́ se seznam všech cı́lů a po vybránı́ se ukážı́ detailnějšı́ informace vpravo. Výše popsané vlastnosti lze upravit poklepánı́m na danou hodnotu. Blackboard BlackBoard je množina proměnných, které udržujı́ povědomı́ botů o stavu okolnı́ho světa. Tyto proměnné se použı́vajı́ pro plánovánı́ akcı́ a při výběru 8 Analýza algoritmu ve hře F.E.A.R. Popis hernı́ AI cı́lů. Jejich změnu zajišt’ujı́ aktivnı́ Senzory. 3.2.2 Akce Aby bylo možné splnit stanovený cı́l, je třeba najı́t správnou posloupnost akcı́. Akce jsou stejně jako cı́le sdruženy do množin a každému botu je jedna přiřazena. Definice Akce je činnost, kterou bot může provádět. Prováděnı́m akce se měnı́ stav hry. Každá akce může mı́t počátečnı́ podmı́nky, které musı́ být splněny k tomu, aby mohla akce proběhnout. Napřı́klad akce Útok má podmı́nku zbraň je nabitá. Plánovánı́ akcı́ Každá akce má důležitý parametr Cost (cena). Tato hodnota je uložena v hernı́ databázi, kterou lze upravovat a editovat v programu GDBEdit, a podle nı́ probı́há proces plánovánı́. Vlastnı́ plánovánı́ je realizováno pomocı́ A* (čti A hvězda) algoritmu. Ten nalezne posloupnost akcı́, která je nejlevnějšı́ (jejı́ž cena má nejnižšı́ hodnotu) a zároveň splnı́ požadavky vybraného cı́le. K vyhodnocenı́ použı́vá heuristickou funkci, jejı́ž hodnota se rovná počtu požadovaných podmı́nek cı́le, které ještě nejsou splněny. Tato hodnota je odhad počtu akcı́, které můžou vést ke splněnı́ cı́le. A* algoritmus A* algoritmus sloužı́ k nalezenı́ nejkratšı́ cesty v ohodnoceném grafu. Je podobný jako prohledávánı́ do šı́řky s tı́m rozdı́lem, že mı́sto fronty je použita fronta prioritnı́, ve které jsou uzly seřazeny podle funkce f (n) = g(n) + h(n). g(n) je cena cesty z počátečnı́ho uzlu n0 do n a h(n) je heuristická vzdálenost z uzlu n do cı́lového uzlu. Složitost algoritmu silně závisı́ na heuristické funkci, nebude však horšı́ než při prohledávánı́ do šı́řky. Ve hře F.E.A.R. je jako heuristická funkce použit rozdı́l nesplněných stavových podmı́nek k uspokojenı́ 9 Analýza algoritmu ve hře F.E.A.R. Popis hernı́ AI cı́le. Tato hodnota je odhad akcı́, které bude potřeba vykonat pro splněnı́ těchto podmı́nek. Vlastnı́ algoritmus vypadá takto [4]: 1. Vytvoř graf G, který obsahuje pouze počátečnı́ uzel n0 , který vložı́ do seznamu OPEN (otevřené uzly). 2. Vytvoř seznam CLOSED (uzavřené uzly), který je zpočátku prázdný. 3. Pokud seznam OPEN je prázdný, ukonči s chybou. 4. Vyber prvnı́ uzel ze seznamu OPEN, smaž ho ze seznamu OPEN a vlož ho do seznamu CLOSED. Tento uzel nazveme n. 5. Pokud uzel n je cı́lový, cesta je nalezena, ukonči a vrat’ cestu od uzlu n do uzlu n0 . 6. Expanduj uzel n, a vytvoř množinu následnı́ků M , které nejsou předky uzlu n v grafu G. Dosad’ tyto uzly jako následnı́ky uzlu n v G. 7. Nastav ukazatel na uzel n z každého uzlu množiny M , které nebyly v grafu G (které nejsou v seznamu OPEN ani CLOSED). Tyto uzly přidej do OPEN. U každého uzlu, který byl v OPEN nebo CLOSED, nastav ukazatel na uzel n, pokud nejlepšı́ cesta procházı́ skrz uzel n. Pro každý uzel z množiny M , který je v CLOSED, nastav ukazatel každého následnı́ka z G, aby ukazovali zpět směrem nejlepšı́ nalezené cesty pro tyto následnı́ky. 8. Seřad’ seznam OPEN podle hodnoty f vzestupně (druhé kritérium je hloubka vzestupně). 9. Jdi na bod 3. Poznámka k bodu 7 ze zdrojového kódu: raději znovu vložit uzly z CLOSED do OPEN než nastavovat ukazatele jejich potomků. A* algoritmus se použı́vá v mnoha počı́tačových hrách (např. akčnı́ hry, strategie) pro hledánı́ nejkratšı́ cesty při pohybu postav. Ve hře F.E.A.R. byl použit tento algoritmus k řı́zenı́ chovánı́ botů i pro navigaci. 10 Analýza algoritmu ve hře F.E.A.R. 3.2.3 Popis hernı́ AI Přı́klad cı́lů a akcı́ Jako přı́klad lze uvést dvě postavy (charaktery) ze hry. Prvnı́ z nich je Assassin. Tato postava se ve hře schovává za překážkami nebo se zneviditelňuje a přepadává hráče v nečekaném okamžiku. Jejı́ GoalSet (množina cı́lů, které může plnit) a ActionSet (množina akcı́, které může vykonávat) ilustruje obrázek 3.4. Tyto množiny se můžou do sebe vnořovat, jak je vidět na obrázku vpravo nahoře. ActionSet Assassin obsahuje množinu Base, která obsahuje základnı́ akce pro pohyb. Obrázek 3.4: GoalSet a ActionSet postavy Assassin v programu GDBEdit Na obrázku 3.4 vlevo je dále vidět, že existujı́ množiny akcı́ AssassinPatrol (na obr. 3.5) a AssassinGuard. Tyto majı́ v sobě vnořený základnı́ seznam AssassinBase a přidaný cı́l Patrol respektive Guard. Tı́m se docı́lı́, že lze jednoduše vybrat dva druhy této postavy s poněkud odlišným chovánı́m. Postavy s cı́lem Guard hlı́dajı́ určitou pozici (tato pozice se určı́ v programu WorldEdit jako jeden z parametrů postavy), postavy s cı́lem Patrol se pohybujı́ po mapě. Duhou postavou, uváděnou zde jako přı́klad, je pták - Bird. Jeho GoalSet a ActionSet shrnuje obrázek 3.6. Množina akcı́ a cı́lů je mnohem jednoduššı́ než v předchozı́m přı́padě, protože se jedná o zvı́ře a neumı́ vykonávat složitějšı́ akce. 11 Analýza algoritmu ve hře F.E.A.R. Změna chovánı́ Obrázek 3.5: GoalSet AssassinPatrol obsahuje AssassinBase 3.3 Změna chovánı́ Nejjednoduššı́ způsob, jak změnit chovánı́ hernı́ AI, je změnit parametry uvedené v programu GDBEdit. Po načtenı́ hernı́ databáze je ve složce AI vše, co se týká umělé inteligence. Seznam cı́lů a akcı́ je ve složkách Goals a Actions. v nich lze měnit jejich parametry, jako Relevance nebo Cost (cena). Pro projevenı́ změn chovánı́ ve hře je potřeba databázi zkompilovat, aby ji hra mohla načı́st. Tyto změny se ale projevı́ pouze ve vývojářské verzi hry. Originálnı́ hra všechna data načı́tá ze zabalených archivů dodávaných s originálnı́ hrou. 3.4 Testovánı́ chovánı́ bota Cı́lem bylo otestovat chovánı́ bota na jednoduché mapě a ověřit, že výběr cı́lů je založen na nastavenı́ hodnoty relevance. To bylo dosaženo sledovánı́m chovánı́ bota, jak se měnı́ v závislosti na poloze nepřı́tele a nastavenı́ relevance dvou cı́lů, a to Cover a KillEnemy. Pro testovánı́ chovánı́ botů byla vytvořena jednoduchá mapa pomocı́ programu WorldEdit. Mapa obsahovala jednu mı́stnost s několika překážkami a několika body typu CoverNode. Důležitou podmı́nkou je nastavit prostor, ve kterém se mohou boti pohybovat, jinak by stáli na mı́stě. 12 Analýza algoritmu ve hře F.E.A.R. Testovánı́ chovánı́ bota Obrázek 3.6: GoalSet a ActionSet postavy Bird v programu GDBEdit 3.4.1 Tvorba mapy Pro testovánı́ byla upravena již existujı́cı́ mapa, která byla použita v tutorialu (návodu) pro tvorbu map. Tato mapa již obsahovala osvětlenı́ a body jako WorldProperties (obsahujı́cı́ základnı́ informace o mapě) nebo GameStartPoint (mı́sto, kde začı́ná hráč po spuštěnı́). Veškeré objekty se vkládajı́ do stromové struktury (jako složky a soubory) pro určenı́ závislostı́ a pro většı́ přehlednost. Důležité bylo vytvořit uzel AINavMesh, který obsahuje informace o možnostech pohybu bota. Pod něj (ve stromové struktuře) bylo nutné vložit rovinu, která se na mapě vyskytovala těsně nad podlahou mı́stnosti a vymezovala prostor, kde se bot může pohybovat. Dále byly vloženy překážky ve tvaru bedny, kolem kterých je nutné vytvořit kvádr s nastavenı́m Type = AINavMeshCarver, což zajistı́, že bot nebude skrz překážky chodit. Nakonec byly za překážky umı́stěny body typu AICoverNode a nastaveny jejich vlastnosti tak, aby jejich pole působnosti pokryla téměř celou mı́stnost, čı́mž bylo zajištěno, že měl bot vždy možnost se ukrýt a měnit svá stanoviště (viz obr. 3.7). 13 Analýza algoritmu ve hře F.E.A.R. Testovánı́ chovánı́ bota Obrázek 3.7: Mapa ve WorldEditu, modře jsou vyznačeny body CoverNode 3.4.2 Nastavenı́ AI Finálnı́ krok představoval vloženı́ postavy do hry. Jedná se o objekt CAI (hlavnı́ objekt umělé inteligence, který umožňuje nastavenı́ grafického modelu a nastavenı́ chovánı́), který byl umı́stěn do mı́stnosti. Postavě bylo potřeba nastavit několik důležitých parametrů, mezi které patřı́ ModelTemplate a GoalSet (na obr. 3.8). Prvnı́ zmı́něný parametr nastavı́ vzhled a množinu akcı́, které bot může vykonávat a druhý parametr nastavı́ množinu cı́lů. Jako ModelTemplate byl zvolen Soldier a GoalSet byl nastaven na novou vytvořenou množinu cı́lů testovaci, která absahovala pouze cı́l Cover a cı́l KillEnemy. Obrázek 3.8: nastavenı́ parametrů pro objekt CAI 3.4.3 Spuštěnı́ mapy Pro spuštěnı́ je potřeba mapu uložit a zpracovat (Process World). Tento přı́kaz provede kompilaci (sestavenı́) a připravı́ mapu k načtenı́ ve hře. Poté lze 14 Analýza algoritmu ve hře F.E.A.R. Testovánı́ chovánı́ bota přı́mo z editoru hru spustit. Spustı́ se vývojářská verze hry a automaticky načte vytvořenou mapu. Pro laděnı́ AI lze zapnout klávesou F7 tzv. GodMode, kde hráč dostane všechny zbraně a nezranitelnost. Klávesou F6 je také možné zobrazit informace o botovi, jako množinu cı́lů, aktuálnı́ cı́l, akci atd. Pro otestovánı́ výběru cı́le jsem navrhl dva scénáře. Testovacı́ scénář 1 V prvnı́m scénáři bylo ponecháno výchozı́ nastavenı́, tzn. relevance cı́lů byly nastaveny takto: Cover (krytı́) = 100 a KillEnemy (zabı́t nepřı́tele) = 26. Po spuštěnı́ stál Bot na mı́stě. Pokud spatřil nepřı́tele, schoval do úkrytu. Testovacı́ scénář 2 Ve druhém scénáři byla relevance cı́le KillEnemy změněna pomocı́ programu GDBEdit na hodnotu 101. V důsledku toho se bot po spuštěnı́ mapy nehýbal. Pokud spatřil nepřı́tele začal pouze střı́let. Tı́m bylo ověřeno, že AI využı́vá k výběru cı́le hodnotu relevance. Obrázek 3.9: Screenshot z hernı́ mapy obsahujı́cı́ textové informace o botovi vyvolané klávesou F6. 15 Analýza algoritmu ve hře F.E.A.R. Testovánı́ chovánı́ bota Rozdı́lné chovánı́ bota ve dvou testovaných scénářı́ch je patrné na videosekvencı́ch, které byly vytvořeny vrámci této práce. Sekvence rovněž zobrazujı́ textové informace včetně údajů o vybraném cı́li (viz obr. 3.9). 16 4 Software Pogamut 3 4.1 Princip a prostředı́ Pogamut 3 je, jak jej popisujı́ autoři tohoto projektu, softwarová platforma sloužı́cı́ ke snadnému prototypovánı́ virtuálnı́ch bytostı́ (tzv. agentů) ve virtuálnı́m prostředı́. Platforma usnadňuje vývoj těchto bytostı́ a nabı́zı́ nástroje pro jejich efektivnı́ laděnı́. Důraz je kladen předevšı́m na IDE. Jedná se o Netbeans plugin, který uživateli umožňuje naprogramovat logiku agenta, ladit ji a poté spustit ve virtuálnı́m prostředı́. Jako virtuálnı́ prostředı́ využı́vá platforma Pogamut 3D akčnı́ hru Unreal Tournament 2004. Pomocı́ IDE je možné v prostředı́ vytvořit agenta, ovládat ho a ladit. Kromě toho IDE dále online zobrazuje parametry agenta. Uživatel má též možnost přı́mo vstoupit do virtuálnı́ho prostředı́ a pozorovat a/nebo interagovat s agenty. [6] Informace z prostředı́ UT2004 jsou exportovány skrz TCP/IP pomocı́ texto- Obrázek 4.1: Architektura systému Pogamut 3 vého protokolu GameBots2004 [10]. Tyto zprávy jsou zpracovávány v Java knihovně Gavialib a dı́ky tomu může Pogamut agent pracovat s Java objekty. Agent může být vzdáleně odlad’ován skrz JMX protocol a plugin Pogamut do NetBeans. Obrázek 4.2: Pogamut NetBeans Plugin 17 Software Pogamut 3 4.2 Řı́zenı́ botů Řı́zenı́ botů Vývoj probı́há v prostředı́ NetBeans a použı́vá se programovacı́ jazyk Java. Pogamut poskytuje mnoho třı́d pro zjišt’ovánı́ stavu světa, pro zı́skávánı́ informacı́ o hráčı́ch a objektech, pro pohyb bota včetně hledánı́ cesty, střı́lenı́ a dalšı́. Pro komunikaci se hrou lze použı́t samotné přı́kazy a odchytávat zprávy přicházejı́cı́ zpět, nebo použı́t tzv. moduly, které většinu práce udělajı́ za vás. Nenı́ tedy zapotřebı́ napřı́klad sledovat, kterou zbraň bot ve hře sebral, mı́sto toho lze použı́t modul Weaponry, který zbraň sám zařadı́ do inventáře a zjistı́, kolik má nábojů. Na vlastnı́ řı́zenı́ sloužı́ metoda logic(), která je pravidelně volána několikrát za sekundu. Dalšı́ možnostı́ je využı́vat posluchače (listenery), které jsou zaregistrovány k nějaké události a jsou volány okamžitě, pokud k dané události dojde. Tyto asynchronnı́ metody pak umožňujı́ rychlejšı́ reakci botů. Přı́jemná skutečnost je, že boty lze krokovat a jejich chovánı́ postupně sledovat ve hře. To se hodı́ zejména při laděnı́ a hledánı́ chyb. Jedinou nevýhodou je, že Pogamut je vı́cevláknový a některé věci se ladı́ hůře, napřı́klad hledánı́ cesty a následný pohyb. 4.3 Navigace botů po mapě Mapy v UT2004 obsahujı́ navigačnı́ graf, který umožňuje bezpečný pohyb botů. Skládá se z mnoha navigačnı́ch bodů propojenými orientovanými hranami, po kterých se boti můžou pohybovat (ve hře UT2004 je lze zobrazit pomocı́ klávesové zkratky ALT + G). Tyto informace můžeme využı́t i v systému Pogamut. Pro pohyb botů po mapě lze použı́t vestavěnou navigaci. Stačı́ vybrat mı́sto na mapě a třı́da PathPlanner vypočı́tá nejkratšı́ cestu a vrátı́ všechny body, kterými bot postupně musı́ projı́t. Tyto informace se předajı́ třı́dě PathExecutor, která postupně pohybuje botem po jednotlivých bodech až do cı́le. Při testovánı́ ale byly s navigacı́ trochu problémy. Bot se zasekával, snažil se použı́t opačně orientované hrany nebo začal chodit sem a tam. 18 Software Pogamut 3 4.4 Moduly Moduly Moduly jsou objekty, které usnadňujı́ práci při řı́zenı́ bota. Dělı́ se na dvě skupiny, a to senzorické, které poskytujı́ informace o virtuálnı́m světě, a přı́kazové, kterými je možné bota jednoduše řı́dit. 4.4.1 Senzorické moduly Mezi senzorické moduly patřı́ Game, který poskytuje základnı́ informace o hře, ve které je bot zrovna připojen, jako je časový limit nebo počet fragů (bodů) potřebných k vı́tězstvı́. Dalšı́ modul je AgentInfo, ten poskytuje informace o botovi samotném. Lze z něj napřı́klad zı́skat aktuálnı́ pozici bota nebo kolik má zdravı́. Modul Players obsahuje informace o všech hráčı́ch připojených do hry. Vracı́ množinu hráčů, které bot vidı́, rozeznává nepřátele a spoluhráče, zı́skává jejich pozice a dalšı́ relevantnı́ informace. Modul, který se stará o všechny informace o předmětech, které lze na mapě najı́t, se jmenuje Items. Vracı́ třeba jejich polohu a jestli jsou aktuálně k dispozici (jdou sebrat, jsou tzv. spawned). Poslednı́m senzorickým modulem je Senses, který spravuje události, které se botovi stali. Obsahuje informace, kdy byl bot naposledy zraněn nebo kdy slyšel nějaký zvuk bez toho, aby programátor musel na všechno psát tzv. posluchače (listenery). Informace, které bot pomocı́ modulů zjišt’uje, nemusı́ být zcela přesné. Jde o interpretaci dat, která bot zná, nebo předpokládá. Napřı́klad u pozice nepřı́tele bot nezná přesnou aktuálnı́ pozici, ale pozici, kde nepřı́tele naposledy viděl. Stejně tak u předmětů pouze odhaduje, jestli jsou dostupné, podle toho, kdy je naposledy viděl, a časů, kdy se předmět znovu objevı́ (tyto časy jsou známé a vždy stejné). 4.4.2 Přı́kazové moduly Zástupce přı́kazových modulů je Locomotion, který umožňuje ovládat botův pohyb. O střı́lenı́ se stará modul Shooting, a to včetně výběru módu zbraně nebo vrhu granátů. Modul Action poskytuje přı́kazy k prováděnı́ různých akcı́, které nespadajı́ do ostatnı́ch kategoriı́, jako zahazovánı́ zbraně nebo prováděnı́ bojových komb. Dalšı́ modul je Communication, který umožňuje zası́lánı́ textových zpráv ve hře. Nakonec je modul ConfigureCommands na 19 Software Pogamut 3 Problémy základnı́ konfiguraci bota a modul SimpleRayCasting poskytujı́cı́ ray casting, což je metoda navigace bota, kdy má před sebou paprsky do několika směrů a pokud některým paprskem narazı́ do překážky, otočı́ se a pohybuje se jiným směrem. Tak se může vyhýbat překážkám, tato metoda ale nenı́ přı́liš efektivnı́, pokud se bot potřebuje dostat na druhou půlku mapy, protože se může stát, že bot začne chodit v kruhu nebo se dostane do mı́sta, ze kterého se tı́mto způsobem nedostane (tato situace nastala, když bot stál ze strany u schodů, paprsky nebyly v kolizi, ale bot se pod schody nevešel). 4.5 Problémy Ve zdrojových kódech Pogamutu se ale občas vyskytne chyba. Napřı́klad modul Weaponry obsahoval dlouhou dobu chybu a nebylo možné měnit zbraně, protože jinak agent přestal pracovat. Proto jsem dlouhou dobu čekal na nové verze a doufal, že kód bude lépe odladěný. Několik chyb jsem i vývojářům nahlásil. V průběhu tvorby této práce vyšlo několik verzı́ Pogamutu. Začı́nal jsem na beta verzi, ale po přechodu na ostrou verzi 3 jsem zjistil, že nastalo mnoho změn. Pak vycházely dalšı́ malé verze s opravenými chybami, kde se ale také občas něco změnilo a bylo potřeba se přizpůsobit. Přechody na nejnovějšı́ verze byly ale nutné právě kvůli chybám. Nakonec jsem použil aktuálně nejnovějšı́ verzi Pogamut 3.0.8 z 3. 5. 2010. 4.6 Dalšı́ možnosti Pogamut sám o sobě se stal platformou pro mnoho dalšı́ch projektů. Za zmı́nku stojı́ AI s přidanými emocemi, která se snažı́ simulovat lidské emoce ve virtuálnı́m světě [7]. Mezi dalšı́ patřı́ chovánı́ botů podle genetických algoritmů [8] nebo StorySpeak [9]. 20 5 Implementace 5.1 Rozdı́ly hry F.E.A.R. a UT2004 Pokud srovnáme hry F.E.A.R. a Unreal Tournament 2004, zjistı́me, že se jedná o docela jiné hry. Zatı́mco prvnı́ z nich se snažı́ být realistická, co se zbranı́ a pohybu týká a snažı́ se navodit tajemnou atmosféru, napětı́ a strach. Mapy jsou uzpůsobené systému výběru akcı́ a cı́lů a obsahujı́ nejrůznějšı́ body, podle kterých se bot může orientovat. Druhá hra, jak už z názvu vyplývá, se nesnažı́ o reálnost, spı́še se snažı́ zapůsobit svou rychlostı́ a akcı́. Mapy jsou vı́ceméně jednoduché a obsahujı́ pouze omezené informace o bodech oproti hře F.E.A.R. Také je UT2004 zaměřen na sbı́ránı́ předmětů a výběru zbranı́, což u hry F.E.A.R. nenı́. Kvůli tomu se budou lišit akce i cı́le. Cı́lem implementace je otestovat A* algoritmus pro chovánı́ bota ve hře UT2004 pomocı́ platformy Pogamut 3 v jazyce Java. Projekt je založen na ukázkovém projektu NavigationBot od vývojářů Pogamutu. Jeho jednoduché chovánı́ je však nahrazeno umělou inteligencı́ inspirovanou algoritmem J. Orkina, který programoval hru F.E.A.R. Pro testovánı́ algoritmu jsem naimplementoval pouze několik akcı́, které využı́vajı́ jenom některé zbraně a pohyby. To z toho důvodu, abych mohl rychleji odladit jejich funkce a ceny. I to se nakonec ukázalo jako složitý problém. 5.2 Třı́dy v projektu Projekt obsahuje 3 balı́čky (packages). Prvnı́ z nich obsahuje implementace akcı́, druhý je vyhrazen pro cı́le a třetı́ všechny ostatnı́ soubory, které jsou nı́že popsány. Program ke svému běhu potřebuje zdrojové soubory Pogamutu 3. 21 Implementace 5.2.1 Třı́dy v projektu GoalBot.java Takto je nazvána hlavnı́ třı́da bota. Je odděděná od třı́dy UT2004BotLogicController, která je součástı́ Pogamutu 3. Nejdůležitějšı́ metoda z mého pohledu je metoda logic(), která je volána několikrát za sekundu. V nı́ se volá aktualizace instance třı́dy umělé inteligence. 5.2.2 AI.java AI je hlavnı́ třı́da, která obsluhuje umělou inteligenci. Při jejı́ inicializaci jsou nahrány všechny akce a cı́le, které se budou použı́vat, do dvou seznamů (třı́dy ArrayList). Ty se pak použı́vajı́ k jejich procházenı́. Hlavnı́ volanou metodou je metoda update(), která zajišt’uje vlastnı́ plánovánı́. Nejdřı́ve aktualizuje stav světa ve hře do proměnných a podle něj začne vybı́rat cı́le. Pro vybraný cı́l je spuštěn A* algoritmus v metodě runAStar(). Vybı́ránı́ akcı́ do plánu pak zajišt’uje metoda getNeighbors() (název převzán z implementace hry F.E.A.R.), která vybı́rá akce sousedı́cı́, tj. ty, co na sebe mohou navazovat. Každý nalezený částečný plán se všemi informacemi je reprezentován instancemi třı́dy AStarNode. 5.2.3 AStarNode.java AStarNode je hlavně datová třı́da, jejı́ž objekty sloužı́ jako reprezentace uzlů v A* algoritmu. Je možné je řadit, protože implementujı́ rozhranı́ Comparable. Obsahuje odkaz na předchozı́ uzel při sestavovánı́ plánu, odkaz na akci, předpokládaný stav světa po akci a samozřejmě cenu. 5.2.4 World.java Třı́da pro uchovánı́ informacı́ o světě, které jsou uvnitř reprezentovány mapou. Obsahuje metodu, která porovnává hodnoty dvou instancı́ této třı́dy a zjistı́ tak jejich heuristickou vzdálenost (viz dále). 22 Implementace 5.2.5 Informace o světě Akce a cı́le Akce a cı́le majı́ pak každý svoji třı́du. Ty jsou umı́stěny v balı́cı́ch (package) Actions a Goals. Jsou odděděny od třı́d AbstractAIAction a AbstractAIGoal, které jsou abstraktnı́. To je z toho důvodu, aby šlo jednoduše procházet akce a cı́le a zacházet s nimi stejně. 5.3 Informace o světě Veškeré informace o stavu hry uchovávám v instanci třı́dy World. Většina informacı́, které jsou uvedeny v tab. 5.1 je v Hash mapě. Informace se aktualizujı́ při každém volánı́ update() umělé inteligence. Zı́skávajı́ se většinou z modulů Weaponry, Items a Players. Dále se v informacı́ch udržuje aktuálnı́ pozice bota. Ta je důležitá pro správný výběr posloupnosti akcı́, aby bot mohl nalézt nejlepšı́ cestu pro sebránı́ všech potřebných předmětů. 5.3.1 Porovnávánı́ světa Při plánovánı́ je často potřeba porovnat dvě instance třı́dy World, napřı́klad aktuálnı́ a požadovaný stav nebo stavy při plánovánı́ akcı́ pro zjištěnı́, jestli jsou splněny jejich počátečnı́ podmı́nky. Probı́há tak, že se počı́tá počet rozdı́lných vlastnostı́ mezi oběma instancemi, podobně jako ve hře F.E.A.R. Vzdálenost je ale pouze jednostranná, protože nepočı́tá vlastnosti, které nejsou ve druhém světě obsaženy. Proto lze u akcı́ nadefinovat jen ty vlastnosti, na kterých v danou chvı́li záležı́. Napřı́klad pro akci GoToEnemy jsou počátečnı́ podmı́nky nadefinovány jako IS ENEMY REACHABLE=1 a HAS LOADED WEAPON=1. Ostatnı́ vlastnosti nejsou započı́tané, takže nevadı́, jestli bot má nebo nemá napřı́klad Flak Cannon. Pokud je vzdálenost nulová, znamená to, že všechny požadované vlastnosti jsou splněny. 23 Implementace Informace o světě informace HEALTH SHIELD IS HEALTH REACHABLE IS MINI HEALTH REACHABLE IS FLAK CANNON APPLICABLE IS ENEMY REACHABLE IS LINK GUN REACHABLE IS LINK GUN AMMO REACHABLE IS FLAK CANNON REACHABLE IS FLAK CANNON AMMO REACHABLE IS ENEMY DEAD IS NEAR ENEMY IS ON SNIPER SPOT IS SNIPER RIFLE REACHABLE IS SNIPER RIFLE AMMO REACHABLE IS DOUBLE DAMAGE REACHABLE IS SHIELD REACHABLE IS SUPER SHIELD REACHABLE SEE ENEMY KNOW WORLD WAS DISTURBED HAS LOADED WEAPON HAS FLAK CANNON AMMO HAS FLAK CANNON WEAPON HAS ASSAULT RIFLE AMMO HAS ASSAULT RIFLE WEAPON HAS LINK GUN AMMO HAS LINK GUN WEAPON HAS SNIPER RIFLE AMMO HAS SNIPER RIFLE WEAPON popis hodnota zdravı́ hodnota štı́tu dostupnost lékárničky dostupnost malé lékárničky dostupnost flak kanónu a nábojů dostupnost nepřı́tele dostupnost link gunu dostupnost link nábojů dostupnost flak kanónu dostupnost flak nábojů zabitı́ nepřı́tele blı́zká vzdálenost od nepřı́tele bot je na odstřelovacı́m mı́stě dostupnost odstřelovacı́ zbraně dostupnost odstřelovacı́ch nábojů dostupnost double damage dostupnost malého štı́tu dostupnost velkého štı́tu viditelnost na nepřı́tele znalost celého prostředı́ bot něco slyšel nabitá zbraň bot vlastnı́ flak náboje bot vlastnı́ flak kanón bot vlastnı́ assault rifle bot vlastnı́ assault náboje bot vlastnı́ link náboje bot vlastnı́ link gun bot vlastnı́ sniper rifle bot vlastnı́ sniper náboje Tabulka 5.1: Seznam vlastnostı́, které uchovává třı́da World 24 Implementace Akce a cı́le cı́l popis KillEnemy zabı́t nepřı́tele Cure zvýšit hodnotu zdravı́ Protect Explore poznámka pokud je nepřı́tel spatřen relevance se měnı́ v závislosti na zdravı́ bota zvýšit hodnotu brněnı́ relevance se měnı́ v závislosti na brněnı́ bota prozkoumávat svět pokud nenı́ nic jiného na práci Tabulka 5.2: Seznam použitých cı́lů 5.4 Akce a cı́le Ve hře UT2004 jsou zásadnı́ zbraně, lékárničky a štı́ty. Proto jsem se zaměřil na výběr správné zbraně. Relevance cı́lů (hodnoty, které sloužı́ při výběru cı́lů jako priorita) i ceny akcı́ se měnı́ v závislosti na stavu světa. 5.4.1 Výběr cı́lů Pro implementaci cı́lů byla použita pouze relevance. Tato hodnota určuje, jak moc je daný cı́l důležitý v aktuálnı́ situaci ve virtuálnı́m prostředı́. Podle nı́ jsou cı́le seřazeny a je vybrán ten s nejvyššı́ hodnotou. Poté je zkontrolováno, zda je cı́l použitelný. Následuje sestavenı́ plánu, tzn. sledu akcı́. Pokud cı́l nenı́ použitelný, je splněný nebo se nepodařilo najı́t plán, je vybrán dalšı́ cı́l v pořadı́. Každý cı́l má nadefinován cı́lový stav, ke kterému se musı́ dostat pomocı́ akcı́. Dále má podmı́nky na aktuálnı́ stav, jestli je cı́l použitelný. Nakonec jsem definoval pouze čtyři cı́le (viz tab. 5.2), protože jsou dostačujı́cı́ pro základnı́ chovánı́ bota. Umožňujı́ pohyb po mapě, boj s nepřı́telem a simulujı́ jednoduchý pud sebezáchovy. 5.4.2 Výběr akcı́ Akce majı́ stanovenou cenu, ale u některých se cena průběžně měnı́. Dále má každá akce zadané podmı́nky, kdy ji lze vykonat a pak definuje stav světa 25 Implementace Akce a cı́le po jejı́m ukončenı́. Dı́ky tomu lze akce skládat za sebe a tvořit tak plán. Akce jsou zařazeny do 5 kategoriı́, kterými jsou MOVE (pohyb), SHOOT (střelba), TAKE WEAPON (vzı́t zbraň), TAKE AMMO (vzı́t náboje) a TAKE BONUS (vzı́t jiný předmět). Plán se tvořı́ tak, že se A* algoritmem procházejı́ všechny akce, které jsou v aktuálnı́m světě použitelné. Použitelné znamená, že počátečnı́ podmı́nky k jejich vykonánı́ jsou splněné. Dále se procházejı́ akce znova, tentokrát jako následovnı́ci akce prvnı́ která původnı́ svět nějak mohla změnit, takže jiné akce mohou být použitelné. Testovaných akce jsou ale seřazeny podle ceny. Akce jsou vkládány do prioritnı́ fronty (kde jsou jednotlivé akce seřazeny podle ceny vzestupně), ze které se postupně vybı́rá vždy ta nejlevnějšı́ posloupnost. Tı́m se zaručı́, že vybraný sled akcı́ je nejlevnějšı́ a tı́m pro bota nejvýhodnějšı́ (např. z hlediska času nebo vzdálenosti). Cena dalšı́ akce se skládá z ceny nové akce, ceny předešlé akce a heuristické funkce, která se rovná vzdálenosti světa po této akci a světa požadovaného cı́lem. Zjednodušená ukázka plánovánı́ je na obr. 5.1. Obrázek 5.1: Ukázka plánovánı́ Pokud některá z akcı́ splnı́ všechny požadavky definované cı́lem, prohledávánı́ končı́. Stanovená podmı́nka je, že každá akce v plánu je z jiné kategorie, aby nedocházelo k opakovánı́ stejných nebo podobných akcı́ během jednoho plánu, což by bylo zbytečné, protože každá akce je splněna beze zbytku. Napřı́klad nenı́ nutné brát podruhé Flak Cannon, když ho bot již sebral nebo 26 Implementace Akce a cı́le nenı́ nutné brát dvě zbraně, když stačı́ ta lepšı́. Pokud je záhodno, aby se akce opakovala (např. sebrat lékárničku), plán zůstane stejný i po dokončenı́ požadované akce, tudı́ž se vykoná znova. To je způsobeno tı́m, že se přeplánovává často bez ohledu na to, jaká akce právě proběhla. Nakonec je vybrána prvnı́ akce úspěšného plánu a tu bot začne vykonávat. Může se stát, že nelze nalézt plán k uspokojenı́ cı́le. V takovém přı́padě je vybrán cı́l jiný (dalšı́ v pořadı́) a algoritmus se opakuje. Jednotlivé akce jsou jednoduché a přı́močaré jako např. sebrat lékárničku nebo střı́let z Flak kanónu. Neovládajı́ tedy přı́mo pohyby bota (animaci modelu), ale jeho chovánı́. O navigaci bota (jakou cestou má bot jı́t) po mapě se starajı́ funkce Pogamutu. Pro efektivnı́ chovánı́ bota je důležitý výběr správné zbraně, proto je ale nutné nadefinovat akci pro každou zbraň zvlášt’. Jejich přehled vidı́te v tabulce 5.3. 5.4.3 Prováděnı́ akcı́ Každá akce obsahuje několik metod, které zajišt’ujı́ prováděnı́. Prvnı́ z nich je metoda DoAction(), která se volá na začátku po naplánovánı́ akce. Obsahuje vlastnı́ kód, který se vykoná, např. střı́let nebo běžet k lékárničce. Dalšı́ metoda je DoDuring(), která je volána, pokud plánovač opakovaně naplánoval tuto akci. Obsluhuje napřı́klad mı́řenı́ bota na nepřı́tele, který se pohybuje. Často volá metodu doAction(). Poslednı́ metodou je DoAfter(). Tato metoda se zavolá v okamžiku, kdy plánovač vybere jinou akci a stávajı́cı́ je u konce. Zajišt’uje, aby se bot zastavil nebo přestal střı́let. Napřı́klad akce ShootByFlackCannon obsahuje v doAction() změnu zbraně na Flak kanón, natočenı́ na nejbližšı́ho nepřı́tele a spuštěnı́ střelby. V metodě doDuring() natočı́ bota na novou pozici nepřı́tele a v doAfter() je střelba zastavena (napřı́klad po smrti nepřı́tele). 27 Implementace Akce a cı́le akce GoToEnemy GoToEnemyCloser GoToSniperPoint RandomWalk ShootByAssaultRifle ShootByFlackCannon ShootByLinkGun ShootByLinkGunSecundary ShootBySniperRifle TakeDoubleDamage TakeFlackCannon TakeFlackCannonAmmo TakeHealth TakeLinkGun TakeLinkGunAmmo TakeMiniHealth TakeShield TakeSniperRifle TakeSniperRifleAmmo TakeSuperShield TurnAround význam jı́t za nepřı́telem přiblı́žit se k nepřı́teli jı́t na odstřelovacı́ mı́sto chodit náhodně střı́let Assault puškou střelba Flak kanónem střı́let Link gunem střı́let Link gunem ve druhém módu střı́let odstřelovacı́ puškou vzı́t Double damage bonus vzı́t Flak kanón vzı́t Flak náboje vzı́t lékárničku vzı́t Link gun vzı́t Link náboje vzı́t malou lékárničku vzı́t malý štı́t vzı́t Sniper rifle vzı́t Sniper náboje vzı́t velký štı́t otočit se Tabulka 5.3: Přehled naimplementovaných akcı́ 28 Implementace 5.4.4 Akce a cı́le Přı́klad akce GoToEnemy Akce GoToEnemy umožňuje botovi se přiblı́žit k nepřı́teli nebo ho sledovat tak, aby na něj mohl střı́let. Uvedu jména obsažených metod a co dělajı́, nebudu uvádět argumenty. load() - při načı́tánı́ akce nastavuje jejı́ cenu (na hodnotu 5) a zařazenı́ do kategorie MOVE. getCost() - vracı́ cenu akce, která je rovna vzdálenosti od nejbližšı́ho hráče děleno 40 (vzdálenost je v neurčitých jednotkách, kdy asi 100 jednotek se rovná dvěma krokům hráče). doAction() - vykoná vlastnı́ akci. Vybere nejbližšı́ navigačnı́ bod nejbližšı́ho nepřı́tele (nebo jeho poslednı́ známou pozici), na který začne navigovat bota. afterFinish() - specifikuje, jaký bude předpokládaný stav světa po dokončenı́ akce. Zde je to SEE ENEMY = 1 a pozice bota bude na mı́stě nejbližšı́ho nepřı́tele. getNeededWorld() - obsahuje počátečnı́ podmı́nky akce, které jsou IS ENEMY REACHABLE = 1 a HAS LOADED WEAPON = 1. toString() - vracı́ název akce, tedy GoToEnemy. doAfter() - po skončenı́ akce, tedy těsně před tı́m, než se začne provádět akce jiná, je zastaven pohyb bota. doDuring() - Pokaždé, kdy je naplánována tato akce opakovaně po sobě, je volána tato metoda. Zde volá metodu doAction(), aby bot mohl reagovat na měnı́cı́ se polohu nepřı́tele. 29 6 Testovánı́ a zhodnocenı́ použitého algoritmu 6.1 Testovánı́ bota Chovánı́ bota jsem testoval v prostředı́ Unreal Tournament 2004 na různých mapách. Pro mód hry jsem vybral DeathMatch, kde jsou všichni hráči proti sobě a vı́tězı́ ten, který nasbı́rá nejvı́ce fragů (bodů, které zı́skává za zabitı́ nepřı́tele). Testovánı́ probı́halo nejdřı́ve na jednoduché mapě TrainingDay (na obr. 6.1), která obsahuje pouze několik propojených chodeb a několik základnı́ch předmětů. Obrázek 6.1: Navigačnı́ graf mapy TrainingDay. Po spuštěnı́ bota jsem se připojil do hry jako hráč a sledoval jeho chovánı́. Jakmile mne bot spatřil, začal po mně střı́let ze základnı́ zbraně. Začal jsem ustupovat a bot mne následoval tak, abych byl v jeho zorném poli a tedy na dostřel. Když se přiblı́žil ke Flak kanónu (silná zbraň na blı́zko) a jeho nábojům, rozhodl se obojı́ sebrat a neváhal je použı́t, přiblı́žil se ke mně 30 Testovánı́ a zhodnocenı́ použitého algoritmu Výhody a dosáhl svého cı́le mne zabı́t. Protože byl z předchozı́ho souboje zraněn a neviděl dalšı́ho nepřı́tele, běžel pro lékárničku. Zkusil jsem tedy otestovat na jiné, většı́ mapě. I zde bot náhodně prozkoumával mapu (plnil cı́l Explore, tı́mto způsobem může najı́t předměty a zapamatovat si jejich pozici) a po setkánı́ se mnou jako hráčem zaútočil. Protože již při prozkoumávánı́ nalezl zbraň Link Gun, použil tuto zbraň. Střı́dal primárnı́ a sekundárnı́ mód zbraně podle toho, jak jsem byl od něj daleko. Bot se tedy pohyboval po mapě a střı́lel, nechoval se však úplně ideálně. Pokud by se hráč trochu snažil, neměl by bot moc šancı́ na úspěch. Bot nevyužı́val všech dostupných zbranı́, protože jejich akce nebyly naipmlementované, ale pro znázorněnı́ chovánı́ bylo toto dostačujı́cı́. Při sledovánı́ bota se však občas stalo, že bot se zasekl na nějakém těžce dostupném mı́stě. Problém někdy také dělaly výtahy, kdy bot si stoupl pod něj a výtah nemohl sjet až dolů. Někdy ze zastavil bez známé přı́činy a bylo nutné bota restartovat. V jiném přı́padě začal bot chodit sem a tam nebo mı́sto do hráče střı́lel do stropu. Toto připisuji chybám prostředı́ Pogamut. Podle výpisů naplánované akce (bot je vypisuje do Java konzole přı́mo v NetBeans) vypadali správně, pouze je bot nevykonal nebo vykonal špatně. 6.2 Výhody Výhodu v použitı́ tohoto algoritmu oproti jiným vidı́m v tom, že stačı́ naimplementovat jednotlivé akce a umělá inteligence si akce sama poskládá do správného pořadı́, pokud se správně nadefinujı́ počátečnı́ podmı́nky a stav po skončenı́ akce. Nenı́ třeba se zabývat, kde se bot nacházı́, z aktuálnı́ho stavu světa se vyberou pouze ty akce, které je možno splnit. Poté stačı́ nadefinovat cı́l (čeho chceme dosáhnout) a A* algoritmus se postará o to, aby toho dosáhl co nejvýhodněji. Je tedy snazšı́ vlastnı́ implementace, o to je ale obtı́žnějšı́ nalézt správná data jako hodnoty relevance nebo ceny akcı́. 31 Testovánı́ a zhodnocenı́ použitého algoritmu 6.3 6.3.1 Problémy Problémy Jaké akce použı́t Důležitým faktorem pro chovánı́ AI je výběr akcı́ samotných, co bota necháme dělat. Jejich implementace do řı́zenı́ závisı́ na možnostech hernı́ho prostředı́, možnostech chovánı́ virtuálnı́ postavy a obecně se odvı́jı́ od pojetı́ hry. Ve hře F.E.A.R. je naimplementováno asi 120 akcı́, ale většina postav jich použı́vá přibližně 30. Neméně důležitý je i seznam cı́lů, který vybı́rá směr, kterým se bot vydá a čeho chce dosáhnout (ve hře F.E.A.R. je asi kolem 50 cı́lů, z nichž postavy využı́vajı́ většinou kolem 20 cı́lů). Pro řı́zenı́ bota v UT2004 nejsou použity množiny GoalSet a ActionSet, protože se jedná pouze o jeden typ postavy, která může využı́vat všechny akce a cı́le. Pokud by bylo třeba vytvořit vı́ce typů chovánı́ (např. obraný a útočný bot), již by se těchto množin mohlo využı́t. 6.3.2 Ohodnocenı́ akcı́ Jedna z nejdůležitějšı́ch věcı́, která ovlivňuje celé chovánı́ bota, je správné nastavenı́ cen akcı́. Je však složité určit, jaké hodnoty jsou ty pravé, to vyžaduje dlouhé testovánı́ a hlı́dánı́, kdy se bot nerozhodl správně. Bez toho se umělá inteligence nechová tak, jak by si jejı́ tvůrce představoval. Odladěnı́ je proto velice pracné a možná právě proto většina her hledá jiné způsoby řı́zenı́ umělé inteligence. Na začátku vývoje jsem odhadnul ceny všech akcı́. Tyto hodnoty se ale ukázaly jako nevyhovujı́cı́, proto jsem je mnohokrát měnil, abych dosáhl lepšı́ho chovánı́. Postupně jsem zjišt’oval, že nastává přı́liš mnoho kombinacı́ a ideálnı́ nastavenı́ se zdálo být téměř nemožné i pro použitý malý počet akcı́. Přibývaly i vlastnosti pro ohodnocenı́ světa, aby se omezil počet akcı́, které lze vykonávat v aktuálnı́ situaci, což také nevedlo zcela k úspěchu. Akce pro pohyb bota jsem začal počı́tat podle vzdálenosti cı́le, což přineslo značné zlepšenı́ a bot už nechodil přes celou mapu pro nejlepšı́ zbraň. I zde ale bylo potřeba vyhodnotit, kdy se botovi vyplatı́ jı́t pro kterou zbraň v závislosti na vzdálenosti (jestli je lepšı́ jı́t 50 metrů a sebrat Flak kanón 32 Testovánı́ a zhodnocenı́ použitého algoritmu Problémy nebo jı́t 40 metrů a sebrat Link Gun). Tyto problémy nebyly ve hře F.E.A.R. řešeny kvůli absenci sbı́ránı́ zbranı́ a jiných předmětů (pro boty). Podobně jsem řešil i volbu zbraně. Každá zbraň je silná za určitých podmı́nek. Problém byl v tom, že jako vývojář, který ohodnocuji akce, musı́m vybrat, zda je výhodnějšı́ na vzdálenost 100 metrů zvolit odstřelovacı́ pušku (Sniper Rifle) nebo se přiblı́žit a použı́t Flak kanón. Pro střı́lenı́ za běhu by se musely vytvořit speciálnı́ akce pro každou zbraň (ve hře jsem využil střelby pouze z aktuálnı́ zbraně). I toto vývojáři mé předlohy neřešili, protože nepřı́tel má pouze jednu primárnı́ zbraň. 6.3.3 Vı́ce akcı́ najednou Bot může vzhledem k použitému algoritmu v jeden okamžik vykonávat pouze jednu akci. To se projevuje při přibližovánı́ nebo vzdalovánı́ se od hráče, kdy se bot pouze pohybuje a nestřı́lı́. Toto bylo potřeba obejı́t pomocı́ takových akcı́, který zajišt’ujı́ jak pohyb, tak střelbu najednou. Dalšı́ možnostı́ by bylo rozdělit řı́zenı́ pohybu a střı́lenı́, což se však po testovánı́ neosvědčilo, protože bot nevyužı́val správné plánovánı́. Při plánovánı́ by totiž bylo třeba určit, jestli má být střelba závislá na pozici bota nebo pozice na zbrani, ze které se střı́lı́. Správné plánovánı́ vyžaduje kombinaci obojı́ho, což ale opět narážı́ na problém nastavovánı́ cen akcı́. 6.3.4 Rychlost Dalšı́ problém se týká rychlosti. Přibývajı́cı́ počet akcı́ se projevuje na délce doby pro rozhodovánı́, který nesmı́ překročit hranici volánı́ metody logic() a také nesmı́ trvat přı́liš dlouho, aby reakce bota ve hře nebyla pomalá - reagoval by na změny ve virtuálnı́m světě se zpožděnı́m. To se dá omezit dobou mezi jednotlivým plánovánı́m, kdy stejně ve většině přı́padů dojde k nalezenı́ totožného plánu, nebo k prováděnı́ plánovánı́ v samostatném vlákně, kde by ale bylo potřeba zajistit správnou synchronizaci, aby byl plán stále aktuálnı́ (může se změnit stav virtuálnı́ho světa po dokončenı́ akce) - po dokončenı́ nějaké akce by bot mohl dostat plán, který právě dokončil. Doba trvánı́ se odvı́jı́ od toho, kolik akcı́ je třeba prohledat. Při procházenı́ akcı́ A* algoritmem se seznam akcı́ k prozkoumánı́ rychle zvětšuje (složitost až n!), jak se zvětšuje stavový prostor. Na obrázku 6.2 je vidět velikost stavo33 Testovánı́ a zhodnocenı́ použitého algoritmu Problémy vého prostoru (počtu prohledaných posloupnostı́ akcı́) v závislosti na počtu akcı́ v přı́padě, že zanedbáme počátečnı́ podmı́nky a akce se nemohou opakovat. Doba plánovánı́ pro sedm akcı́ v takovém přı́padě již přesáhla 6 sekund, proto vı́ce akcı́ již nebylo zahrnuto. Obrázek 6.2: Graf znázorňujı́cı́ velikost stavového prostoru v závislosti na počtu akcı́ Pokud zahrneme počátečnı́ podmı́nky, počet akcı́ bude samozřejmě mnohem menšı́, ale jejich počet bude záviset na výběru akcı́ a na aktuálnı́m stavu světa. Také nenı́ při plánovánı́ prozkoumáván celý stavový prostor, ale plánovánı́ končı́, pokud narazı́me na prvnı́ úspěšný plán. V tahovém přı́padě byl průměrný čas potřebný k plánovánı́ v reálné hře 85 ms za použitı́ všech 21 akcı́. Průměrný počet prozkoumávaných posloupnostı́ byl 82. Počet procházených akcı́ jsem snı́žil tı́m, že jsem u každé akce nadefinoval kategorii (move, shoot, take weapon, take ammo a take bonus) a nastavil podmı́nku, že v každém plánu může být maximálně jedna akce od každé kategorie. Toto neohrozilo správnou funkci plánovánı́, protože nebylo třeba vybı́rat dvě střelby nebo sbı́ránı́ dvou zbranı́. Tı́m se razantně snı́žil potřebný čas k plánovánı́ - průměrný čas plánovánı́ ve hře se snı́žil na 29 ms. Průměrný počet prozkoumávaných posloupnostı́ byl 30. 34 7 Závěr Úkolem v této práci bylo prozkoumat řı́zenı́ umělé inteligence v počı́tačové hře F.E.A.R. a implementovat jej pomocı́ softwaru Pogamut do hry Unreal Tournament 2004, použitý algoritmus zhodnotit a najı́t kritická mı́sta. Bylo zapotřebı́ zvolit a naimplementovat akce, které může bot vykonávat, a cı́le, ze kterých bot může vybı́rat. Cı́lový stav chovánı́ bota ve hře Unreal Tournament 2004 nenı́ zcela uspokojivý, protože bylo použito pouze několik akcı́ a bot nevyužı́val všechny zbraně nebo speciálnı́ vlastnosti kvůli složitosti nastavenı́ a ohodnocenı́ vyžadujı́cı́ch akcı́. Bot se pohybuje ve virtuálnı́m světě a rozhoduje se podle aktuálnı́ho situace, jaké jsou jeho primárnı́ cı́le. Těch dosahuje pomocı́ akcı́, které jsou sestaveny do plánu. Plánovánı́ probı́há podle algoritmu J. Orkina z Massachusetts Institute of Technology, který programoval umělou inteligenci ve hře F.E.A.R. Chovánı́ mých botů se ale od původnı́ch ze hry F.E.A.R. lišı́ z důvodu jiných možnostı́ hernı́ho prostředı́. A* algoritmus byl zachován a chová se velmi podobně, problémem je ale značná odlišnost obou her a s tı́m souvisejı́cı́ problémy, které se vyskytly během implementace. Nejzávažnějšı́m problémem se ukázalo být správné ohodnocenı́ akcı́, což by ale vyžadovalo dlouhé testovánı́. s tı́m souvisı́ i výběr akcı́, který nenı́ v poměrně komplexnı́ hře jako je UT2004 jednoduchý. Bud’ by jich muselo být velmi mnoho a hledánı́ plánu pro bota by trvalo přı́liš dlouho, nebo jich je méně (jako v mém přı́padě), pak ale bot nevyužije všechny možnosti hry. Dle mého názoru se tento typ řı́zenı́ nehodı́ pro tento typ akčnı́ch her. Ve hře F.E.A.R. AI neřešilo sbı́ránı́ zbranı́ a předmětů, akce byly vı́ce svázané s prostředı́m světa a byly vı́ce specializované, tudı́ž ke splněnı́ cı́le stačily kratšı́ posloupnosti a jejich počet byl menšı́ (často jen jedna), tı́m pádem ohodnocenı́ bylo méně podstatné. Dalšı́ slabinou byl systém Pogamut, který obsahoval mnoho chyb. Byl stále ve vývoji a pravidelně byly vydávány nové verze, což kvůli změnám zpomalovalo vývoj umělé inteligence. Aktuálně nejnovějšı́ verze 3.0.8 obsahovala napřı́klad chybu o počtu nábojů, což znemožňovalo správné vybı́ránı́ zbranı́. Chovánı́ tohoto bota by šlo dále rozšiřovat. Naimplementovat by samo35 Závěr zřejmě potřebovalo vı́ce akcı́ pro použitı́ všech zbranı́ a předmětů, včetně adrenalinových komb. Zajı́mavým vylepšenı́m, ale velmi složitým, by také bylo použı́t AI pro hranı́ v týmu v jiných módech hry, jako je např. Capture the Flag (seber vlajku) nebo Domination (nadvláda), které hra UT2004 obsahuje. Zde by se musela zajistit spolupráce botů při snaze o dosaženı́ určitého cı́le, třeba sebrat vlajku. Také by se daly použı́t přı́kazy botům, jako je tomu u standardnı́ch botů v UT2004. Dále by se dalo vylepšit uvěřitelnost chovánı́ botů, aby hráč nepoznal, že hraje proti umělé inteligenci a tı́m zvýšit hernı́ zážitek hráčů. Hernı́ AI by se také mohla postupně přizpůsobovat hernı́mu stylu hráče, to už by ale vyžadovalo složité učı́cı́ se algoritmy. 36 Literatura [1] Kadlec R., Bı́da M.: Pogamut 2 URL: <https://artemis.ms.mff.cuni.cz/pogamut/files/Pilsen-17-409/01-Intro-Pogamut-Extensions.pdf> [cit. 2010-05-11] [2] Kunter G.: Shuruppak URL: <http://shuruppak.strandwall.de/technical.php> úpravy 24.2.2006 poslednı́ [3] Orkin, J.: Agent Architecture Considerations for Real-Time Planning in Games. Proceedings of the Artificial Intelligence and Interactive Digital Entertainment AAAI Press, 2005 [4] Nilsson, N.: Artificial Intelligence: A New Synthesis Stanford University, 1997 [5] AI Game development URL: <http://aigamedev.com/open/articles/fear-sdk/> [cit. 201005-11] [6] Pogamut URL: <https://artemis.ms.mff.cuni.cz/pogamut/tiki-index.php? page=Uvod> [cit. 2010-05-11] [7] Pogamut: Emotional AI in UT URL: <https://artemis.ms.mff.cuni.cz/pogamut/tiki-index.php? page=Emotional+AI+in+UT> [cit. 2010-05-11] [8] Pogamut: Genetic Bots URL: <https://artemis.ms.mff.cuni.cz/pogamut/tiki-index.php? page=Genetic+Bots> [cit. 2010-05-11] 37 LITERATURA LITERATURA [9] Pogamut: StorySpeak URL: <https://artemis.ms.mff.cuni.cz/pogamut/tiki-index.php? page=StorySpeak> [cit. 2010-05-11] [10] GameBots 2004 URL: <http://diana.ms.mff.cuni.cz/main/tiki-index.php?page= GameBots> [cit. 2010-05-11] 38
Podobné dokumenty
Programování virtuálních agentů – Platforma Pogamut
inteligence zvyklí. Důvodem je výpočetní náročnost; v oblasti umělé inteligence pro
počítačové hry se i kvadratická složitost algoritmu obvykle hodnotí jako příliš vysoká.
Podobně analogie mezi kon...
Jak rychle prototypovat chovánı umelých bytostı: Pogamut 2
V dnešnı́ době stále stoupá zájem o umělé bytosti. Umělými bytosmi rozumı́me speciálnı́ softwarové agenty dle Wooldridge
[1] vtělené ve virtuálnı́m světě. Vývoj chovánı́ umělých...
II. Německé školy v ČSR Blížil se konec první světové války. V
zap sobil na N mce mohutným dojmem a stal se pro n praktickým návodem, jak by se dalo
kone n vy ešit také jejich postavení v SR. Události dostaly prudký spád a za p l roku bylo
po všem.
V pátek 30....
Herní algoritmy, předn. 4 - Proof number search Lambda search
• PNS: Victor Allis 1994; předtı́m McAllester: conspiracy numbers, min.
počet vrcholů, které ”změnı́” hodnotu kořene
• najde důkaz anebo vyvrácenı́ pro pozici
• konstruuje oba stromy souča...
prednaska Neinformovane prohledavani
velkého počtu stejných, fixně svázaných a interagujı́cı́ch výpočetnı́ch jednotek přı́klad: neuronové sı́tě
behavioralismus – který je založen na předpokladu že kombinacı́ velkého po...
CKKP :: Odešel Jiří Ployer Dne 22.listopadu 2015 naše řady opustil
m1c5UJnzHYyyEaQWYhlmkkRyUR5z5XU97pXa10KXEk9zQypt4EXydEhZdT2MtBz4Acwzw
hHVqEj9lyZI0tL4heyZwhjs1m84JYevTnitbT2+75F9QwGHjbogFdllg0iBoI+SsuFYsaE+MR
DPkJgiF4sRUY6mvEJJ3GOlSCokwBlp5sR5TPxnOOLBj8mcEYbn9Yf...
prostředí pro snadné vytváření jednoduchých (logických) her
Simple games and puzzles described by a unified set of XML files and graphical
representations enter the environment. The main file is a set of rules which operates
the play process. The proposed s...
Srovnání alternativních implementací DirectX
použít současné OpenGL 2.x nebo počkat na OGL 3?
„sbližování“ obou API
➔ OpenGL 3 jako DirectX 10