Bakaláˇrská práce Implementace inteligentn´ıch bot˚u pro

Transkript

Bakaláˇrská práce Implementace inteligentn´ıch bot˚u pro
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

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...

Více

Jak rychle prototypovat chovánı umelých bytostı: Pogamut 2

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...

Více

II. Německé školy v ČSR Blížil se konec první světové války. V

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....

Více

Herní algoritmy, předn. 4 - Proof number search Lambda search

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...

Více

prednaska Neinformovane prohledavani

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...

Více

CKKP :: Odešel Jiří Ployer Dne 22.listopadu 2015 naše řady opustil

CKKP :: Odešel Jiří Ployer Dne 22.listopadu 2015 naše řady opustil m1c5UJnzHYyyEaQWYhlmkkRyUR5z5XU97pXa10KXEk9zQypt4EXydEhZdT2MtBz4Acwzw hHVqEj9lyZI0tL4heyZwhjs1m84JYevTnitbT2+75F9QwGHjbogFdllg0iBoI+SsuFYsaE+MR DPkJgiF4sRUY6mvEJJ3GOlSCokwBlp5sR5TPxnOOLBj8mcEYbn9Yf...

Více

prostředí pro snadné vytváření jednoduchých (logických) her

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...

Více

Srovnání alternativních implementací DirectX

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

Více