Masarykova univerzita Fakulta}w¡¢£¤¥¦§¨ informatiky !"#$%&'()+,-./012345 Umělá Inteligence do OpenTTD Bakalářská práce Daniela Plachtová Brno, Jaro 2015 ii Poděkování Chtěla bych poděkovat RNDr. Jaroslavu Bayerovi za odborné vedení práce, cenné rady při psaní tohoto textu a pomoc s testováním. Dále bych chtěla poděkovat své sestře za pomoc s korekturou textu práce a se spracováním testovacích výsledků. iii Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a liter- aturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Daniela Plachtová iv Klíčová slova Umělá inteligence, Open Transport Tycoon Deluxe, OTTD v Contents 1 Úvod ...... 1 1.1 Open Transport Tycoon Deluxe ...... 1 1.2 Základní cíle a pravidla hry ...... 2 1.3 Popis hry ...... 2 2 Umělá inteligence v OpenTTD ...... 5 2.1 Umělá inteligence vs. člověk ...... 5 3 Programové prostředí ...... 7 3.1 Squirrel ...... 7 3.2 NoAI framework ...... 8 3.3 Kostra UI ...... 9 3.4 Debugging ...... 10 4 Anaýza umělých inteligencí ...... 11 4.1 Analýza umělých inteligencí bez železniční přepravy 12 4.2 Analýza umělých inteligencí s železniční přepravou 14 4.3 Podrobný popis vybraných umělých inteligencí . . 15 AdmiralAI ...... 16 WormAI ...... 16 trAIns ...... 16 5 TracAI ...... 18 5.1 Základní vlastnosti TracAI ...... 18 5.2 Návrh a implementace TracAI ...... 19 General Manager ...... 20 Rail Manager ...... 20 5.3 Problémy řešené v TracAI ...... 22 Hledání vhodných kandidátů pro vytvoření trasy 22 Hledání vhodného místa pro postavení stanice . . 23 Hledání trasy ...... 24 Demolice trasy ...... 25 Ukládání a nahrávání hry ...... 26 6 Výsledky testování ...... 27 6.1 Výsledky testu TracAI proti WormAI ...... 28 6.2 Výsledky testu TracAI proti AdmiralAI ...... 31 6.3 Výsledky testu TracAI proti nejlepším UI . . . . . 35 7 Závěr ...... 41 A Příloha A – zdrojové kódy kostry UI ...... 44 vi A.1 Příloha A.1 – info.nut ...... 44 A.2 Příloha A.2 – main.nut ...... 45 B Příloha B - podrobné výsledky testů ...... 45 vii List of Tables 1 Průběh příjmů a celkového hodnocení v analýze UI bez vlaků 13 2 Průběh příjmů a celkového hodnocení v analýze UI pouze se železniční přepravou 15 3 Nastavení mapy při testování 27 viii List of Figures 1 Nástroje v OpenTTD 3 2 Mapa světa 3 3 Grafy závislosti příjmů vůči délce trasy 4 4 Směry částí silnic a železničních tratí 11 5 Ukázka stylu infrastruktury u trAIns 17 6 UML diagram tříd TracAI 19 7 Třída TracAI 20 8 Třída GeneralManager 20 9 Třída RailManager s pomocnými třídami 21 10 Vzorec pro výpočet nejvhodnějšího produkujícího průmyslu 23 11 Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – hodnota společnosti 28 12 Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – příjem 29 13 Výsledky testů TracAI proti WormAI v nevhodném nastavení mapy – hodnota společnosti 29 14 Výsledky testů TracAI proti WormAI v nevhodném nastavení mapy – příjem 30 15 Výsledky testů TracAI proti WormAI ve vhodném nastavení mapy – hodnota společnosti 30 16 Výsledky testů TracAI proti WormAI ve vhodném nastavení mapy – příjem 31 17 Výsledky testů TracAI proti AdmiralAI ve výchozím nastavení mapy – hodnota společnosti 32 18 Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – příjem 32 19 Výsledky testů TracAI proti AdmiralAI v nevhodném nastavení mapy – hodnota společnosti 33 20 Výsledky testů TracAI proti AdmiralAI v nevhodném nastavení mapy – příjem 33 21 Výsledky testů TracAI proti AdmiralAI ve vhodném nastavení mapy – hodnota společnosti 34 22 Výsledky testů TracAI proti AdmiralAI ve vhodném nastavení mapy – příjem 34 ix 23 Výsledky testů nejlepších UI ve výchozím nastavení mapy – hodnota společnosti 35 24 Výsledky testů nejlepších UI ve výchozím nastavení mapy – příjem 36 25 Výsledky testů nejlepších UI v nevhodném nastavení mapy – hodnota společnosti 37 26 Výsledky testů nejlepších UI v nevhodném nastavení mapy – příjem 38 27 Výsledky testů nejlepších UI ve vhodném nastavení mapy – hodnota společnosti 39 28 Výsledky testů nejlepších UI ve vhodném nastavení mapy – příjem 40 x 1 Úvod Umělá inteligence (UI) je obor informatiky, který se zaměřuje na výzkum a návrh inteligentních agentů [14]. Inteligentní agent je systém, který vnímá okolí a provádí určité akce tak, aby měl co největší šanci na úspěch. Vytvoření inteligentního agenta se rozděluje do několika as- pektů jako jsou například znalosti, uvažování, plánování, učení, zpra- covávání přirozeného jazyka (komunikace), vnímání, kreativita, schop- nost se pohybovat či manipulovat s předměty a další. Každý z těchto aspektů může pro agenta představovat výzvu. Umělá inteligence je využívána v robotice, ekonomice, medicíně, telekomunikaci a dalších oborech. Tato práce se zaměřuje na vývoj herní umělé inteligence, které jsou rozšířené a populární mezi lidmi. Počítačové hry obvykle závisí na umělé inteligenci. Příkladem využití UI ve hrách mohou být tzv. boti, počítačem ovládání protivníci zas- tupující hráče, pokud nejsou dostupní nebo žádání. Dále jsou tu UI algoritmy pro náhodné generování map, určování místa pro spawning nepřátelů a jiné. Cílem práce je implementovat nového, nebo netriviálním způsobem rozšířit existujícího UI protivníka o podporu dalšího způsobu přepravy a porovnat výsledky nové či rozšířené UI se stávajícími ve hře Open Transport Tycoon Deluxe (OTTD). Železniční přeprava byla vybrána, jelikož se jedná o nejkomplexnější ze všech typů přepravy. Aby bylo možné rozšířit existující UI o nový typ přepravy, bylo nutné nejprve prozkoumat vlastnosti umělých inteligencí ve hře (Kapitola 2), posléze prostudovat jazyk Squirrel a NoAI Framework API, které hra využívá pro tvorbu UI (Kapitola 3), a nakonec analyzovat existující UI pro případnou implementaci (Kapitola 4). V kapitole 5 je popsán návrh a implementace autorkou vytvořené UI a výsledky testování lze nalézt v Kapitole 6. 1.1 Open Transport Tycoon Deluxe Tato bakalářská práce se zaměřuje na tvorbu UI v Open Transport Ty- coon Deluxe (dále jen OTTD). Díky herní rozmanitosti, jednoduchému ale rozsáhlému modelu ekonomiky a velké podpoře tvorby vlastní UI ze strany vývojářů OTTD představuje jedinečnou možnost pro vývoj vlastní UI. 1 OTTD je open source verze budovatelské strategie Transport Ty- coon Deluxe, která byla vytvořena Chrisem Sawyerem a vydána firmou MicroProse v roce 1995. OTTD přebírá všechny vlastnosti originální hry a přidává mnohá vylepšení jako je například podpora více počí- tačových platform, jazyková lokalizace, volba velikosti map, hra pro více hráčů, podpora pro vytváření skriptů a UI a mnohá další. Díky přidané podpoře pro LAN se do jedné hry může zapojit až 255 hráčů vlast- nících 16 společností, které jsou ovládány buď samotnými hráči, nebo UI. OpenTTD je současně licencováno pod GNU General Public Li- cence verze 2.0. 1.2 Základní cíle a pravidla hry Hlavním cílem hry je vybudovat a posléze provozovat vlastní přepravní společnost tak, aby na konci hry měla nejlepší hodnocení. Ve výchozí verzi hry (bez přídavných balíčků NewGRF) je na výběr ze čtyř typů přepravy: • železniční doprava – klasické, elektrické, monorail a maglev vlaky, • letecká doprava – letadla a helikoptéry, • silniční doprava – autobusy, tramvaje a nákladní automobily, • lodní doprava. Ve výchozím nastavení hra začíná v roce 1950 a pokračuje do konce roku 2050, kde se o vítězi rozhodne podle podrobného výkonnostního hodnocení. To zahrnuje celkový příjem, počet vlastněných dopravních prostředků a stanic, množství a počet druhů doručeného zboží a další kritéria. Na začátku jsou na mapě vygenerovány různé druhy průmyslu a mě- sta, které po umístění stanice v jejich blízkosti, umožňují přepravu určitého zboží. Výdělek z přepravy tohoto zboží je poté určen jeho množstvím, rychlostí přepravy a také penálemi za brzké či pozdní dodání. V průběhu hry přepravní prostředky společností stárnou, proto se musí neustále obměňovat. Také se zpřístupňují různá technologická vylepšení, dávající hráči možnost koupi nových vozidel. 1.3 Popis hry V průběhu hraní má hráč k dispozici mnoho nástrojů – od konstrukce všech typů přepravy, přes úpravu terénu, po různé informace a statis- 2 tiky: finanční informace; hodnocení výkonu; grafy příjmů, hodnoty spole- čnosti a podobně (viz Obrázek 1). Figure 1: Nástroje v OpenTTD Před začátkem vlastní hry vygeneruje program dle hráčova nas- tavení a zvoleného algoritmu náhodnou mapu, rozvrhne terén, rozmístí města a průmysl a případně rozmístí vegetaci. Hráč poté zanalyzuje herní mapu a vybere vhodná spojení a typy přepravy podle informací, které lze nalézt v menu zobrazit mapu → mapa světa. Filtry, které jsou součástí mapy, umožňují hráči zvýraznit potřebné informace (viz Obrázek 2). Figure 2: Mapa světa se zvýrazněním různých druhů průmyslu a nad- mořskou výškou Každý hráč by měl mít na vědomí závislosti mezi pasažéry a různými druhy zboží, optimalizaci délky trasy, přepravní náklady a dobu doručení. 3 Na obrázku 3 můžeme vidět rozdíl v závislosti mezi příjmem a délky trasy při různých rychlostech přepravy pasažérů. Je to zajímavá ukázka toho, že příjem může začít po určité vzdálenosti klesat, protože se cena převozu pasažérů snižuje z důvodů dlouhé doby přepravy (graf vlevo, rychlost vozidla 100km/h), kdežto pokud je rychlost vozidla vyšší, ztráta příjmu se neprojeví (graf vpravo, rychlost vozidla 300km/h). Figure 3: Grafy závislosti příjmů při převozu 20 pasažérů vůči délce trasy při rychlostech 100km/h (vlevo) a 300km/h (vpravo). Převzato z [11]. Navržení a postavení vhodné přepravní infrastruktury ale není jedi- nou výzvou, které musí hráč čelit. Dalším důležitým aspektem hry je správa vytvořených cest zahrnující kontrolu událostí ve hře (otevření/uza- vření průmyslu, havárie dopravního prostředku atp.), nákup a prodej vozidel dle potřeby a další. Ekonomika hraje v OTTD velice důležitou roli. Za prvé je tu nárůst inflace a nebo měsíční úroky, které musí hráč platit, pokud si půjčil peníze od banky. Dále má hráč možnost vykupování podílů společností jiných hráčů. U měst jsou zase dostupné speciální akce, jako kampaně nebo úplatky, umožňující vylepšení místního hodnocení, díky kterému města dovolí společnostem v jejich oblasti zakládat nové trasy. Hra také obsahuje náhodné prvky, jako jsou změny v produkci a nabídky dotací. 4 2 Umělá inteligence v OpenTTD Hráči v OTTD mohou využívat mnoho strategií k dosažení cíle. Něk- teří se zaměřují pouze na zisk, jiní se zaobírají i estetikou infrastruktury kterou budují. Další skupiny tvoří lidé, kteří aktivně soupeří s ostat- ními, nebo naopak takoví, jejichž snahou je být co nejvíce v ústraní. Na rozdíl od umělých inteligencí se hráči chovají spontánně a vznikající problémy řeší unikátním a elegantním způsobem. I průměrnému hráči stačí pár jednoduchých pravidel, kterými se bude řídit, a může vytvořit funkční a hezky vypadající infrastrukturu. 2.1 Umělá inteligence vs. člověk Hráči a umělé inteligence vykazují několik typických rysů, díky kterým je lze odlišit. Pro identifikaci těchto rysů bylo nutné prohlédnout několik záznamů hráčů a umělých inteligencí. Jedním z nejdůležitějších omezení umělých inteligencí je tvorba pou- ze jednoduchých spojení, většinou zdrojového bodu s cílovým, z důvodu opakujících se schémat. Na rozdíl od hráčů, umělé inteligence nemají tvůrčí myšlení, které by umožnilo stavbu nových kreativních cest a uzlů, přizpůsobující se stávající infrastruktuře. Pokud umělé inteligence využívají uzly, tak velice primitivně, prozatím žádné z existujících UI (z oficiálního repozitáře OTTD [6]) nejsou schopny vytvořit masivní uzly, tzv. huby. Dalším omezením je akcelerační model u vlakové přepra- vy. Akcelerační model je fyzikální model simulující zrychlení při pro- jíždění zatáček nebo svahů. Efektivní trať by měla mít co nejméně lim- itujících zatáček a změn sklonu. Ve většině případů by hráč dokázal nalézt výhodnější cestu než většina existujících UI pomocí stavby vhod- ných mostů a tunelů nebo jednoduchému přizpůsobení terénu. Na druhou stranu umělé inteligence jsou oproti hráči schopny spravo- vat najednou velké množství dopravních prostředků. To ale nezaručuje, že dojde k vhodnému přizpůsobení délky a množství vozidel, popřípadě k výměně vozidla za jiný model. Nejdůležitější vlastnosti při výběru do- pravního prostředku jsou jeho kapacita, rychlost a cena za údržbu. Množství zboží, frekvence a stabilita vývozu ovlivňuje produkci zbo- ží. Proto je někdy výhodnější mít více menších vozidel než méně větších, jelikož doba nákladu může výrazně prodloužit celkový čas přepravy. Přizpůsobení dopravních prostředků jednotlivým trasám představuje 5 pro tvůrce UI netriviální problém. Dalším problémem, které řeší jen některé z existujících umělých in- teligencí, je vylepšování existující infrastruktury, například z jednokole- jky na maglev. V průběhu hry se objevují nová vozidla s lepšími parame- try a nové typy tratí (ve hře existuje možnost čtyř druhů tratí, a to kla- sické, elektrické, monorail a maglev). Implementace této funkcionality může být pro tvůrce UI výzvou. Základní rysy, ve kterých se umělé inteligence v OTTD odlišují od hráčů, lze shrnout do několika bodů: • schopnost spravovat najednou velké množství vozidel, • stavba jednoduchých tras ve stylu spojení zdrojového bodu s cílo- vým, • podpora pro přizpůsobení délky vlaků (pouze u některých UI), • modernizace cest a vozidel (pouze u některých UI), • primitivní využití uzlů, • horší schopnost využití akceleračního modelu. 6 3 Programové prostředí OTTD od verze 0.7.0 umožňuje vytvořit velice jednoduché API s herními skripty, díky kterým jsme schopni implementovat vlastní UI. Pro spo- jení hry a API byl použit jazyk Squirrel. Pomocí vestavěného interpretu, který je zabudován přímo ve zdrojovém kódu hry, není potřeba ex- terních nástrojů k vytvoření UI, stačí pouze hra samotná a jednoduchý textový editor. 3.1 Squirrel Hlavním programovacím jazykem pro OTTD je C++, avšak pro imple- mentaci UI vývojářský tým zvolil Squirrel. Squirrel je vysokoúrovňový, imperativní, objektově orientovaný pro- gramovací jazyk s malými nároky na paměť, který je velice podobný C++. Je vhodný pro aplikace běžící v reálném čase, jako jsou právě počítačové hry. Syntaxe Squirrelu je nejvíce podobná syntaxi C/C++ a Javy, ale povahou je blíže k jazykům Python a Lua. Právě Lua je největší inspirací Squirellu. Mezi prvky, které Squirrel nabízí, patří: • Open Source MIT licence, • dynamická typová kontrola, • delegace, • třídy a dědičnost, • funkce vyššího řádu, • lexikální rozsah platnosti, • generátory, • kooperativní vlákna (koprogramy), • koncová rekurze, • zpracování výjimek, • automatická správa paměti, • volitelné 16bitové řetězce, • velmi silné embedded API, • překladač i virtuální stroj mají dohromady kolem 7 tisíc řádků C++ kódu a přidávají pouze okolo 100 kB – 150 kB při spuštění [2]. Další výhody Squirrelu oproti C++ jsou jeho jednoduchost a nízké režijní náklady. Jde o velice flexibilní nástroj pro vytvoření herního 7 API. Má také mnohem abstraktnější přístup k programování umělé inteligence a vestavěnou multiplatformní podporu. Jednou z největších nevýhod Squirrelu oproti C++ je jeho rychlost. V OTTD jeho výhody převažují nad nevýhodami, a to: • Testování UI v C++ požaduje překompilování celého zdrojového kódu hry. • Chyby u UI v C++ mohou způsobit pád celé hry, kdežto u Squir- relu, který používá virtuální stroj, způsobí nanejvýš pád dané UI. Současná stabilní verze Squirrelu je 3.0.7 (15. května 2015), API v OTTD ale používá verzi 2.2.5. Je to proto, že API částečně modifiko- valo její funkce a integrovalo je do OTTD. Standardní knihovny, které jsou součástí Squirrelu, nemusí být přístupné v API, proto vše, co není explicitně v dokumentaci API [4], nemusí fungovat. Doplnění funkčnosti je možné v C++ ve zdrojovém kódu hry, to by ovšem vyžadovalo překlad celé hry. Squirrel má také několik externích nástrojů, které je možno použít při vytváření UI: • SQDEV – vývojářské prostředí pro Eclipse (plug-in), • SQDBG – knihovna pro debugger, který spolupracuje s SQDEV (plug-in), • Visual Studio Integration – přídavný balíček pro Microsoft Vi- sual Studio, • Squirrel_JIT – just-in-time optimalizovaný překladač pro Squir- rel. 3.2 NoAI framework API pro vytváření UI v OTTD se jmenuje NoAI framework. Všechny současné oficiální UI jsou jím podporovány. Při vývoji a testování UIje doporučeno používat nejnovější stabilní verzi OTTD, což je současně verze 1.5.0 (1. dubna 2015). Při vytváření UI se lze vydat dvěma směry. Umělou inteligenci je možné implementovat zcela od základů a nebo alternativně využít už existujících UI z oficiálního repozitáře OTTD[6]. Pokud se vývojář rozhodne k druhé možnosti, je nutno dodat, že využití jiných UI úzce 8 souvisí s jejich licencemi. I když většina UI, které jsou dostupné na ofi- ciálních stránkách OTTD a díky tomu je možné si je stáhnout přímo ve hře, mají GNU licenci verze 1.0 nebo 2.0, některé mají nestandardní licence, což by vývojáři UI měli brát na vědomí. Součástí NoAI framework jsou také knihovny [7] obsahující imple- mentaci základních algoritmů, které lze využít při vytváření UI. Přík- ladem může být pathfinder.road nebo pathfinder.rail, který využívá al- goritmu A* [13] pro hledání cest. 3.3 Kostra UI Implementaci nové UI pro OTTD je výhodné začít její kostrou, protože ta je pro všechny UI prakticky totožná. Tutoriál k vytvoření kostry je možné nalézt na oficiálních stránkách OTTD [8]. Prvním krokem je vytvoření souborů main.nut a info.nut. Stromový adresář pro umístění UI je následující: • OpenTTD/ ∙ ai/ ∙ MyNewAI/ ∙ info.nut ∙ main.nut Soubor info.nut slouží k definici UI. Zde jsou umístěny metody pro základní nastavení UI, jako jsou: jméno autora; jméno, popis, instance a verze UI; datum vydání. Tyto metody musí být implementovány. Mezi volitelné metody patří funkce udávající seznam nastavení hry, ve které můžeme specifikovat například rychlost hry (udává obtížnost), omezení určitých typů dopravních prostředků a jiné. Poslední nutnou funkcí je RegisterAI(), která zaregistruje danou UI v jádře hry. Při změně tohoto souboru je nutné znovu načíst UI do hry. To lze udělat buď restartováním celé hry nebo přes konzoli ve hře příkazem rescanai • Start() – obsahuje hlavní smyčku, 9 • Load() – není nutné implementovat, • Save() – není nutné implementovat. Příklad těchto souborů jsou uvedeny v příloze A. 3.4 Debugging Otestovat UI přímo ve hře lze dvěma způsoby. Prvním je herní kon- zole, která se spouští přes menu nápověda → skrýt nebo zobrazit konzoli nebo pomocí klávesy tidle (na anglické klávesnici). Příkazem list_cmds se vypíše seznam všech příkazů ve hře. Pro vývojáře UI jsou ale nejd- uležitější příkazy: • startai Druhým způsobem, jak odladit UI, je možné přes okno ladění, které nalezneme v menu nápověda → Ladění AI/herních skriptů. V ladícím okně jsou zobrazena všechna hlášení, která se ve hře mohou naskyt- nout. Prvním typem hlášení jsou chyby (jak syntaktické, tak běhové), které je možno přesměrovat do konzole spuštěním hry s parametrem -d. Pokud jde o hlášení informačního rázu, ty vývojář UI kontroluje přes výstup AILog z API. Další pomocí mohou být breakpointy v logu. Ty lze zpřístupnit pomocí příkazu v konzoli set gui.ai_developer_tools 1. Poté, pokud výpis odpovídá řetězci který je předem zadán, se hra poza- staví. Bohužel ladící okno nepodporuje přesměrování na jiný výstup, které někdy může vývojáře limitovat. 10 4 Anaýza umělých inteligencí Hlavním cílem této práce je vytvořit UI, která bude schopna konkurovat ostatním UI, primárně největším příjmem a sekundárně nejlepším hod- nocením v podrobném hodnocení výkonu. Autorka se rozhodla netriv- iálně rozšířit vhodnou existující UI o podporu dalšího způsobu přepravy, a proto bylo nutné vybrat typ přepravy, který bude nejvhodnější na im- plementaci a udělat analýzu existujících UI. Na základě následujících argumentů se autorka rozhodla implemen- tovat železniční dopravu. Za prvé, vlaky dosahují vysokých příjmů za vozi- dlo. Jediným konkurentem v tomto ohledu mohou být letadla, ale u těch se vyšší příjmy projevují až v pozdějších letech s lepšími typy letadel. Poté je tu záležitost složitosti implementace. Vlaky se považují za ne- jsložitější na implementaci, jelikož na rozdíl od letadel a lodí je nutno nalézt vhodnou trasu mezi stanicemi a oproti automobilům je hledání vhodné trasy složitější z toho důvodu, že železniční trať lze stavět více směry (Obrázek 4). Figure 4: Směry částí silnic a železničních tratí Základním cílem analýzy stávajících UI bylo nalézt vhodného kan- didáta pro rozšíření o vlakovou dopravu. Sekundárním potom iden- tifikace UI, které již vlakovou dopravu implementují, pro inspiraci i záverečné porovnání efektivity a dosažených výsledků. Autorka testo- vala pouze UI, které lze nalézt v oficiálním repozitáři OTTD. V obou dvou případech testování probíhalo od roku 1970 po konec roku 2050 na 11 mapě o velikosti 2048x2048 s normálním množstvím měst a průmyslu, velmi plochým typem povrchu a nízkou četností jezer. Tento druh mapy sice diskriminuje lodní přepravu, tu ale autorka nepovažuje na základě osobních zkušeností za vhodný typ dopravy pro dosažení co největšího příjmu. 4.1 Analýza umělých inteligencí bez železniční přepravy Cílem analýzy existujících umělých inteligencí bez implementace vlaků bylo najít vhodnou UI k doplnění o podporu dalšího způsobu přepravy. V analýze bylo zahrnuto všech 22 umělých inteligencí bez implementace vlakové přepravy. Po rychlém zhlédnutí zdrojových kódů a jednotlivých stránek s popisem UI, bylo vyloučeno 6 kandidátů pro nevhodnost implementace. Jelikož jedna hra umožňuje pouze 15 společností ovlá- daných UI (jedna společnost musí být vždy ovládaná člověkem), au- torka se rozhodla v prvním kole využít vyřazovacího systému (neboli pavouka), po kterém budou vítězové na jedné mapě porovnáni každý s každým. Aby byly dvojice ve vyřazovacím systému nejspravedlivější, byly rozděleny do skupin podle implementace typu dopravy. Což může být doprava silniční (R – road), lodní (S – ship), letadlová (A – aircraft) a jejich kombinace, a poté jestli využívají pouze pasažérů a pošty (P – passangers), nebo čistě jen zboží (F – freight), nebo obojího. Takto se utvořilo pět dvojic a dvě trojice, kde druhé místa z obou trojic vytvořilo speciální osmou skupinu. • Skupina A/P – WormAI, WrightAI, • Skupina RA/P – PAXLink, EpicTrans, • Skupina R/P – AroAI, RoadAI, Convoy, • Skupina R/F – BorkAI, MogulAI, • Skupina R/PF – Rondje, RoadRunner, PathZilla, • Skupina RA/PF – CluelessPlus, TeshiNet, • Skupina RAS/PF – TerronAI, Trans AI, • Skupina SECONDS – druhé místa ze skupin R/P a R/PF. Více informací o jednotlivých UI lze nalézt na [12]. Vítězové prvního kola se stali WormAI, EpicTrans, AroAI, MogulAI, RoadRunner, TeshiNet, Trans AI a Convoy. Tyto UI se poté utkaly proti sobě na jedné mapě. 12 Roky 1980 2020 2051 C.H. WormAI 927 Příjem letadel $26 404 732 $98 459 750 $90 508 238 Celkem $122 948 366 $2 526 315 414 $4 676 168 744 EpicTrans 812 Příjem letadel $0 $57 881 488 $119 203 290 Příjem aut $3 066 430 $6 129 058 $8 222 938 Celkem $1 284 064 $977 488 476 $3 550 806 586 AroAI 849 Příjem aut $5 753 336 $7 073 860 $7 789 612 Celkem $27 256 664 $236 769 932 $374 216 798 MogulAI 802 Příjem aut $4 401 628 $11 431 290 $20 523 734 Celkem $3 613 750 $290 628 206 $633 648 142 RoadRunner 698 Příjem aut $632 518 $7 714 602 $7 023 410 Celkem $552 606 $103 581 956 $266 058 770 TeshiNet 893 Příjem letadel $0 $16 643 796 $12 764 508 Příjem aut $1 455 788 $11 306 626 $12 051 112 Celkem $1 171 268 $583 526 066 $1 182 453 552 Trans AI 823 Příjem letadel $13 621 746 $28 355 888 $24 355 914 Příjem aut $74 058 $208 686 $236 510 Příjem lodí $92 294 $307 452 $417 422 Celkem $58 070 264 $1 016 011 374 $1 605 488 170 Convoy 759 Příjem aut $6 707 666 $6 477 932 $8 870 182 Celkem $25 688 828 $223 210 154 $382 687 876 Table 1: Průběh příjmů a celkového hodnocení (C.H.) v analýze UI bez vlaků Na prvním místě se umístil WormAI, který má implementovanou pouze letadlovou přepravu. I když se EpicTrans téměř vyrovnal Wor- mAI, a v čistém příjmu WormAI dokonce překonal, v celkové hodnotě společnosti jej nedostihl. Z tabulky 1 je patrné, že příjem z letecké 13 přepravy má největší podíl na celkových příjmech jednotlivých UI. Tomu napomáhá zvolená velikost mapy. Vhodnost WormAI pro doplnění dalšího typu přepravy spočívá v tom, že doba nalezení a stavby leteckých tras je oproti železniční nebo sil- niční přepravě mnohonásobně kratší. Poté je nutné podotknout, že jako jedna z mála UI má WormAI přehledný a okomentovaný zdrojový kód. EpicTrans má na rozdíl od WormAI implementovanou velice slabou podporu silniční přepravy, co se týče výdělku, a komplexnější zdrojový kód. 4.2 Analýza umělých inteligencí s železniční přepravou Cílem analýzy existujících umělých inteligencí s implementací železniční přepravy bylo výkonnostně porovnat existující UI mezi sebou a pro pří- padnou inspiraci. V oficiálním repozitáři OTTD lze nalézt 11 umělých inteligencí s implementací železniční přepravy. Po podrobném prostu- dování jednotlivých UI bylo vybráno 9 vhodných umělých inteligencí k dalšímu porovnání. Jelikož některé UI mají implementovány i jiné typy přepravy než železniční, bylo nutné tyto typy v nastavení zakázat. Díky tomu lze porovnat čistě implementaci železniční přepravy bez žád- ných vlivů ostatních implementací. Pro analýzu UI se železniční přepravou byl použit systém každý s každým na jedné mapě. Využití vyřazovacího systému nebylo na rozdíl od analýzy v předchozí kapitole nutné, jelikož počet testovaných UI je malý. Proti sobě na jedné mapě soupeřilo 9 umělých inteligencí: trAIns, FastPTPAI, AIAI, NoCAB, ChooChoo, AdmiralAI, OtviAI, SimpleAI a DictatorAI. V tabulce 2 lze vidět, že ze začátku hry dominoval FastPTPAI, ale kvůli absenci správy vozidel jej trAIns postupně dohnal a ke konci hry měl mnohonásobně vyšší čistý příjem a celkový výdělek než ostatní umělé inteligence. DictatorAI nedokázal z neznámých důvodů postavit ani jednu trasu, proto také u něj nebyly uvedeny žádné výsledky. 14 1980 2020 2051 C.H. trAIns 981 Příjem vlaky $6 528 526 $91 627 902 $391 406 146 Celkem $19 338 752 $1 635 220 056 $7 409 289 414 FastPTPAI 868 Příjem vlaky $17 431 440 $61 594 948 $57 778 718 Celkem $59 951 366 $1 836 340 016 $3 049 695 338 AIAI 900 Příjem vlaky $4 259 984 $54 200 600 $134 930 944 Celkem $1 540 976 $821 791 650 $3 218 078 888 NoCAB 927 Příjem vlaky $3 253 990 $38 732 434 $105 154 586 Celkem $10 085 882 $570 996 434 $2 264 566 506 ChooChoo 818 Příjem vlaky $2 906 934 $12 046 626 $46 831 958 Celkem $1 741 782 $405 294 530 $630 802 434 AdmiralAI 875 Příjem vlaky $4 055 980 $24 756 022 $55 610 770 Celkem $14 035 360 $405 294 530 $1 133 346 712 OtviAI 948 Příjem vlaky $1 436 602 $2 246 040 $1 426 902 Celkem 5 296 502 $99 362 604 $134 770 890 SimpleAI 974 Příjem vlaky $2 823 420 $31 425 626 $91 947 474 Celkem $3 572 022 $458 054 862 $1 709 644 748 DictatorAI — Table 2: Průběh příjmů a celkového hodnocení (C.H.) v analýze UI pouze se železniční přepravou 4.3 Podrobný popis vybraných umělých inteligencí Tato kapitola přináší detailní popis umělých inteligencí, které ovlivnily vývoj autorčiny UI. 15 AdmiralAI AdmiralAI je jedna z nejstarších umělých inteligencí dostupných v ofi- ciálním repozitáři OpenTTD. Tuto umělou inteligenci vytvořil Thijs Marinussen (pod přezdívkou Yexo), který je také jedním z vývojářů OpenTTD. Hlavním cílem této UI je především implementace co nejvíce druhů přepravy tak, aby bylo zábavné proti němu soupeřit. Současná verze podporuje automobilovou (včetně tramvají), vlakovou, letadlovou a lod- ní dopravu. AdmiralAI je velice stabilní a kvalitní UI. Tuto umělou inteligenci autorka zmiňuje především proto, že se často využívá k porovnávání s ostatními UI. Velmi často tvůrci do své UI přebírají některé funkce nebo dokonce i celé třídy, jelikož jeho zdrojový kód má velmi dobrou strukturu a je částečně okomentovaný (pozn. lepší čitelnosti kódu by napomohly komentáře popisující postup uvnitř funkcí). WormAI WormAI je umělá inteligence, kterou autorka vybrala pro doplnění im- plementace železniční přepravy, podle výsledků v kapitole 4.1. Autorem této UI je Wormnest. Tato umělá inteligence vylepšuje původní verzi WrightAI. WrightAI se stal první UI pro NoAI Framework, která se považovala za plnohodnotnou UI. V současnosti jediným typem přepravy jsou ve WormAI letadla, které převážejí pouze pasažéry a poštu. trAIns Umělá inteligence trAIns je založena na výzkumné práci Luise H. O. Rio- se [10]. Hlavní cíl autora je především vytvoření umělé inteligence, která se bude svými plány a rozhodnutími co nejvíce podobat lidskému hráči. V současnosti trAIns implementuje pouze vlakovou přepravu. Hlavní předností trAIns je speciálně upravený algoritmus pro hledání cest, pomocí které UI staví dvojité tratě (viz Obrázek 5). Další funkcional- itou je vybírání průmyslu tak, aby více produkujících průmyslů směřo- valo do jediného akceptujícího. K tomu využívá existujících tratí, které spojuje do uzlů. Jako jeden z mála existujících UI umí také vylepšit tratě za novější verzi a odstranit tratě, které nejsou výnosné. 16 Figure 5: Ukázka dvojité tratě, využití existující trati pomocí uzlů a sdružování produkujících průmyslů do jednoho akceptujícího u trAIns Bohužel tato UI nemá žádné komentáře zdrojového kódu a díky její rozsáhlosti (přibližně 380 kB) je značně nepřehledná. Tuto umělou in- teligenci považuje autorka za jednu z nejlepších v oblasti implementace železniční přepravy a také ji nejčastěji využívá pro inspiraci při tvorbě své UI. 17 5 TracAI Hlavním cílem autorky bylo vytvořit umělou inteligenci schopnou konku- rovat nejlepším existujícím UI v OpenTTD. Po analýze dat o dostup- ných UI byl vybrán WormAI (viz Kapitola 4), který byl rozšířen o im- plementaci železniční přepravy. Tato UI byla pojmenována TracAI, což je zkratka obou typů implementované dopravy, a to vlaků (tr) a letadel (ac). TracAI se v železniční přepravě zaměřuje primárně na transport zboží a sekundárně podporuje také přepravu pasažérů mezi městy. Lete- cká přeprava v této UI, stejně jako WormAI, podporuje pouze převoz pasažérů. 5.1 Základní vlastnosti TracAI Prvním krokem u vývoje TracAI bylo shrnoutí základních vlastností, které by měla umělá inteligence v OTTD obsahovat. A to: • schopnost nalezení vhodných kandidátů (to jest a průmyslů nebo měst) pro vytvoření trasy, • schopnost postavení dvojité tratě ve stylu spojení zdrojového bodu s cílovým, • úprava terénu při stavbě trasy, • schopnost vylepšení tratí na nový typ, • umožnění sdružení produkujícího průmyslu do jednoho akcep- tujícího (vytváření dopravních uzlů), • využití existujících tratí při stavbě nových, • správa vozidel, • správa financí, • schopnost přizpůsobení novým podmínkám, • reakce na uložení/nahrání. Při výběru stylu tratě bylo v Kapitole 2.1 zmíněno, že trať ze zdro- jového bodu do cílového je jednodušší. Složitější infrastruktura, která by se podobala lidskému hráči, by byla efektivnější. Po prohlédnutí a analýze existujících UI se přesto autorka rozhodla pro tento styl tratě, z důvodu jednoduchosti implementace a efektivitě (UI se snahou o re- alističtější styl infrastruktury z velké většiny nebyly tak úspěšné). 18 5.2 Návrh a implementace TracAI Hlavní myšlenkou návrhu bylo rozdělit UI do oddělených modulů (v tomto případě správců), kde každý modul má určitou přidělenou práci, kterou provádí. V TracAI se nachází pět správců: GeneralManager, RailMan- ager, AirManager, MoneyManager a ErrorManager, které jsou podrobně popsány v následujících podkapitolách. Výslednou strukturu programu detailně vystihuje UML diagram (viz Obrázek 6). Figure 6: UML diagram tříd TracAI Hlavní třída, rozšiřující AIContoller v API, se nazývá TracAI (viz Obrázek 7), která na začátku hry inicializuje všechny dostupné správce v konstruktoru třídy. V této třídě se nachází funkce Start() obsahující 19 hlavní nekonečnou smyčku UI (pokud je smyčka jakkoliv přerušena, UI selže) a funkce Save() a Load(). Figure 7: Třída TracAI General Manager General Manager (viz Obrázek 8) obsahuje funkce související se všemi typy vozidel. Především jde o obnovu vozidel a obstarání událostí, které se ve hře vyskytnou (např. výměna starého vozidla za nové, nákup nového vozidla po havárii a další). Figure 8: Třída GeneralManager Rail Manager RailManager (viz Obrázek 9) zahrnuje nalezení vhodných kandidátů, vytvoření trasy a funkce řízení vlaků, které využívá General Manager. 20 Figure 9: Třída RailManager s pomocnými třídami 21 K tvorbě nových tras je používán Rail Pathfinder od AdmiralAI, který využívá algoritmu A*. Jelikož doba hledání může být poněkud delší než při tvorbě trasy letadel, funkce je v Rail Manageru přizpů- sobena tak, aby byla schopna v průběhu hledání také spravovat ostatní, časově nenáročné, funkce. Rail Manager využívá další pomocné třídy. Jednou z nich je Rail Builder, který obsahuje všechny funkce pro stavbu, jako je například hledání vhodného místa pro stavbu stanic, nebo stavbu tratí, stanic, dep a signálů. Dále Rail Manager využívá Rail Route, který obsahuje všechny funkce pro správu jednotlivých tras a uchovává si o nich in- formace. Další pomocnou třídou je Rail Demolisher, který si uchovává informace o všech postavených kolejích, aby je poté mohl jednoduše odstranit. 5.3 Problémy řešené v TracAI Tato kapitola přináší podrobný popis řešení nejzásadnějších problémů v UI TracAI. Hledání vhodných kandidátů pro vytvoření trasy Hledání vhodných kandidátů pro vytvoření trasy se rozděluje na dva typy tras, a to na trasu mezi městy (pasažéři a pošta) a trasu mezi průmysly (zboží). V prvním případě, to jest hledání trasy mezi městy, železniční přepra- va využívá upravený algoritmus od WormAI, a proto se dvojice vhod- ných měst hledá podobně jak u železniční, tak u letecké přepravy. Způ- sob hledání je následující: 1. filtrace měst podle počtu obyvatel, 2. vytvoření seznamu dvojic měst s největším počtem obyvatel (u letadel vybírá dvojici náhodně), 3. seřazení dvojic podle součtu obyvatel obou měst. V případě přepravy zboží je algoritmus složitější z důvodu většího množství parametrů, které se při hledání musí zohlednit. Způsob výběru se provádí v následujících krocích: 1. seřazení typu zboží podle možné výnosnosti, 22 2. tvorba seřazený seznam nejlepších produkujících průmyslů pro každý typ zboží, 3. nalezení nejvhodnějšího akceptujícího průmyslu ke každému pro- dukujícímu a vytvoření dvojic (podle vzdálenosti). U vyhledání nejlepších produkujících průmyslů byl využit algorit- mus od trAIns [10]. Výsledný vzorec je následující: (푝푟표푑푢푐푡푖표푛 · (1 − 푡푟푎푛푠푝표푟푒푑푃 푒푟푐푒푛푡푎푔푒/100) 푣푎푙푢푒 = · 푐푎푟푔표푉 푎푙푢푒 푠푡푎푡푖표푛푠퐴푟표푢푛푑 + 1 (1) Figure 10: Vzorec pro výpočet nejvhodnějšího produkujícího průmyslu (pozn. production a transportedPercentage je za minulý měsíc) K doplnění akceptujícího průmyslu k produkujícímu byla využita optimální vzdálenost, která byla určena dvěma faktory. Kratší trasy mají ve většině případů menší příjem než trasy delší (do určité vzdálenos- ti), zároveň čím delší je trasa, kterou je nutno postavit, tím déle může trvat její nalezení. Z tohoto důvodu byla vybrána optimální vzdálenost 220 polí (pro výpočet vzdálenosti je využita Manhattanská vzdálenost, kterou používá samotná hra). Obdobný způsob využívá umělá inteligence trAIns (optimální vzdálenost 250 polí). Problém může nastat, pokud kritéria mapy nejsou pro UI vhodné. Například při hledání trasy je preferována rovina před hornatou mapou (důvodem je vyšší cena při častých změnách sklonu svahu), nebo je preferována mapa s menším poměrem vodních ploch, kde je více pros- toru pro hledání tras (mosty mají omezenou délku a jsou cena při hledání je vyšší). Proto byla v TracAI zavedena i sekundární optimální vzdálenost (110 polí), která se aktivuje, pokud UI není schopna nalézt trasu s primární vzdáleností třikrát za sebou. Hledání vhodného místa pro postavení stanice Hledání vhodného místa pro postavení stanice u průmyslu či města je dalším problémem, kterým je třeba se zabývat. I tady se hledání vhodného místa se u měst a průmyslu vypočítává odlišně. 23 V případě průmyslu je algoritmus následující: 1. výběr polí (anglicky tile), na kterých průmysl určené zboží ještě akceptuje nebo produkuje, 2. seřazení polí podle toho, kolika směry stanice může být postavena (s prioritou na přímý směr) a filtrace nevhodných polí, 3. seřazení vhodného pole podle typu průmyslu: • produkující: vzdálenost od druhého průmyslu, • akceptující: násobek příjmu přijmu zboží průmyslem a vzdá- lenosti od druhého průmyslu. U měst je algoritmus stejný jako u akceptujícího průmyslu, kromě prvního bodu, kde probíhá výběr polí podle toho, jestli dané pole městu patří či ne. Hledání trasy Hledání cesty patří mezi nejdůležitější algoritmy ve hře. Vhodně po- stavená trasa, jejíž nalezení netrvá dlouho, je klíčem k vytvoření dobré UI v OTTD. Autorka použila modifikovaný Rail Pathfinder od Admi- ralAI, což je univerzální pathfinder, jehož modifikace využívá většina existujících UI. Pathfindery jiných UI nelze tak lehce využít, jelikož jsou dělány přímo pro ně (např. trAIns). Rail Pathfinder využívá algoritmu A* [13], který je velice efektivní a jednoduchý na implementaci. Peter Hart, Nils Nilsson a Bertram Raphael poprvé popsali tento algoritmus, který rozšiřuje Djikstrův al- gorimus, v roce 1968. A* algoritmus je navržen tak, aby našel co ne- jvýhodnější cestu mezi dvěma vrcholy v grafu. A* využívá tzv. heuri- stickou funkci, která odhaduje cenu od právě používaného vrcholu k cíli. Pokud je heuristická funkce přesná, hledání cesty může být efektivní, ale pokud heuristická funkce přesná není, výkonnostně A* může být horší než Djikstrův algoritmus. V OTTD vrcholy v grafu reprezentují pole na mapě a hrany mezi nimi jsou dány jako sousedící pole (ve 4 hlavních směrech). Vstupem pro A* algoritmus je množina bodů a hran (tj. OTTD mapa), počáteční vrchol 푛0 a předpokládaný cílový vrchol 푛푔. 1. Graf 퐺 začíná počátečním vrcholem 푛0 a dvěma vytvořenými seznamy: OPEN, který obsahuje pouze 푛0, a CLOSED, který je prozatím prázdný. 24 2. Pokud je OPEN prázdný, algoritmus vrací false, což indikuje, že cesta nebyla nalezena. 3. Pokud OPEN není prázdný, vrchol, který je v seznamu první, je z OPEN odstraněn a přesunut do CLOSED. Tento vrchol je nazván 푛. 4. Pokud vrchol 푛 = 푛푔, algoritmus skončil úspěšně, nalezená cesta je vrácena. 5. Poté je seznam OPEN rozšířen o množinu 푀1, jejíž vrcholy se nenachází ani v OPEN ani v CLOSED. Tyto členy 푀1 přidáme jako následovníky 푛 v 퐺. Pro každý člen 푀1 je vytvořen ukazatel na 푛. 6. Poté je vytvořena množina 푀2 obsahující všechny vrcholy, které byly v OPEN nebo v CLOSED a pro každý člen 푀2 je ukazatel přesměrován na 푛, pokud nejlepší nalezená cesta vedla skrze 푛. 7. Zároveň také pro všechny členy 푀2, které se vykytují v CLOSED, je přesměrován jejich ukazatel k předchůdcům v 퐺 a to vytváří nejlepší nalezenou cestu k těmto předchůdcům. 8. Seznam OPEN je seřazen vzestupně podle hodnoty heuristické funkce. 9. Opakování od kroku 3 [9]. Demolice trasy Demolice trasy je jedním z netriviálních problémů, obzvlášť pokud UI využívá existujících cest, dep či stanic. Zde vývojář musí řešit dva hlavní problémy. Prvním je uchování informací o trase, popřípadě znovu nalezení trasy. Uchování informací o trase je, co se týče implementace, jednodušší, ale nároky na paměť se díky tomu zvyšují, což může vést ke zpomalení hry. Na druhou stranu znovu nalezení trasy je pro vývojáře netriviální problém a zároveň je složitější odstranit jen ty části tratě, které žádná jiná trasa nepoužívá, což je druhý problém, který musí vývojář řešit. Tuto funkcionalitu většina existujících UI nemá imple- mentovanou. V TracAI je toto vyřešeno třídou Rail Demolisher. Rail Demolisher, co se týče implementace, jde lehčí cestou. Každou postavenou kolej si indexuje do seznamu. Seznam je uložen jako table [3], což je ve Squirrelu asociativní kontejner implementovaný jako pár klíč/hodnota, kde klíč je id pole a hodnota je table s informacemi o typu koleje (most, tunel nebo trať) a pole (array) s dvojicí vlastník/směr 25 koleje, kde vlastníkem je trasa která kolej používá, a směr koleje (viz Obrázek 4), kde na jednom poli může být více kolejí. Ukládání a nahrávání hry OTTD umělým inteligencím umožňuje uložit osobní data, která potře- bují ke svému fungování. Funkce Save() by měla vrátit table s informa- cemi, která UI potřebuje. Uložit je možno pouze: • integers, • strings, • booleans, • nulls, • arrays (s maximální hloubkou 25), • tables (s maximální hloubkou 25). Instance tříd a AIList z API není možno uložit, je nutné nejprve jej konvertovat na kompatibilní typ (array nebo table). Funkci Save() je možné zavolat kdykoliv v průběhu hry (např. up- rostřed hledání či stavění trasy) a nemá to na UI žádný vliv, proto po vrácení funkce UI pokračuje, jako kdyby se nic nestalo. Při načtení hry se prvně zavolá konstruktor, poté funkce Load() a nakonec funkce Start(), kde se nachází hlavní smyčka. Což znamená, že se UI spustí od začátku, akorát s načtenými daty. UI si tedy nepa- matuje, kde se nacházela, když byla zavolána funkce Save(), proto je po nahrání vhodné úkoly, které byly přerušeny, ošetřit (např. dokončit nebo alespoň odstranit nedostavěnou trasu a podobně). Obě funkce mají limit operací, které lze uvnitř funkcí provést, proto pokud má vývojář seznamy s velkým počtem položek, je nutné je uk- ládat do kompatibilních kontejnerů (což jsou arrays a tables). Příkla- dem může být v Rail Demolisher seznam všech polí, na kterých jsou postaveny koleje (viz předchozí kapitola). Pokud by informace o koleji byly uloženy jako instance třídy, musel by se celý seznam překonver- tovat na kompatibilní typ při každém uložení hry. To by, pokud by byl seznam moc velký, mohlo způsobit pád hry z důvodu vyčerpání limitu operací. Proto je v TracAI celý seznam utvořený z kompatibil- ních arrays a tables. Tímto stačí uložit pouze samotný seznam a počet vyčerpaných operací je tedy velmi nízký. 26 6 Výsledky testování V této kapitole jsou shrnuty výsledky třech druhů testů. Testy byly provedeny proti dvěma protivníkům a jedné skupině. První test proběhl proti původní umělé inteligenci, WormAI. V druhém testu se TracAI utkal s AdmiralAI a do třetího bylo vybráno šest nejlepších UI z ofi- ciálního repozitáře OTTD. Každý ze tří druhů testů byl proveden pětkrát pro tři typy map o různém stupni obtížnosti podle nastavení mapy při spuštění nové hry. Nastavení mapy lze vidět v tabulce 3. Uvedeny jsou pouze ty vlast- nosti, které byly měněny. Ostatní vlastnosti jsou vždy ve výchozím nastavení. Hra probíhala od roku 1970 po konec roku 2050. Sledovány byly výsledky v roce 1980, 2020 a 2051. Nastavení Vhodné Výchozí Nevhodné Typ krajiny velmi nízké nízké hornatá Členitost krajiny velmi plochá plochá velmi členitá Četnost jezer velmi nízká velmi nízká nízká Počet řek žádné více více Rozmanitost terénu žádná žádná velmi vysoká Sázení stromů žádné vylepšené vylepšené Okraje mapy terén voda voda Table 3: Nastavení mapy při testování V následujících podkapitolách jsou podrobněji popsány všechny testy a jejich znázornění je v grafech, které ukazují průměry vytvořené z pěti nezávislých opakování testu a směrodatnými odchylkami vyjádřené jako chybové úsečky. Ve všech provedených testech si TracAI nejlépe vedl v testu s Wor- mAI při vhodných podmínkách s hodnotou společnosti $6 246 593 194. Nejlepší čistý příjem železniční přepravy $153 103 446 měl ale v testu s AdmiralAI při vhodných podmínkách. Naopak nejhorší výsledek dosáhl v $1 976 687 108 v testu s WormAI při nevhodných podmínkách kde měl také i nejhorší čistý příjem železniční dopravy $26 242 594. 27 6.1 Výsledky testu TracAI proti WormAI Cílem prvního druhu testu bylo zjistit, zdali nově vytvořená UI je lepší než původní. Na obrázcích grafů lze vidět výsledky testů ve výchozím nastavením mapy 12 a 11, v nevhodném nastavení mapy 14 a 13 a ve vhodném nastavení mapy 16 a 15. TracAI si v tomto testu vedl velice dobře. Hodnota společnosti má ve všech nastaveních mapy více než dvakrát větší hodnotu než původní verze. Z grafu lze vypozorovat kolísání celkové hodnoty společnosti po- dle obtížnosti. Co se týče příjmů z letadlové přepravy, výsledky příjmů TracAI a WormAI jsou srovnatelné. Důvodem obrovských rozdílů v hod- notách společnosti napomáhá příjem z železniční přepravy, který, kromě nastavení mapy ve vhodných podmínkách, je přibližně dvakrát větší než příjem z letadlové přepravy u WormAI. Ve vhodných podmínkách je příjem letecké přepravy u WoramAI a železniční přepravy u TracAI srovnatelný. Figure 11: Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – hodnota společnosti 28 Figure 12: Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – příjem Figure 13: Výsledky testů TracAI proti WormAI v nevhodném nas- tavení mapy – hodnota společnosti 29 Figure 14: Výsledky testů TracAI proti WormAI v nevhodném nas- tavení mapy – příjem Figure 15: Výsledky testů TracAI proti WormAI ve vhodném nastavení mapy – hodnota společnosti 30 Figure 16: Výsledky testů TracAI proti WormAI ve vhodném nastavení mapy – příjem 6.2 Výsledky testu TracAI proti AdmiralAI Druhý test proběhl proti AdmiralAI, umělou inteligencí od vývojáře OTTD. Tato UI je často využívána jinými vývojáři pro testování. Grafy zobrazují výsledky testů ve výchozím nastavením mapy 18 a 17, v nevhod- ném nastavení mapy 20 a 19 a ve vhodném nastavení mapy 22 a 21. AdmiralAI v tomto druhu testu má výhodu oproti TracAI v imple- mentaci silniční přepravy, která je ale velice slabá. TracAI byla v celkové hodnotě společnosti lepší než AdmiralAI, podobně jako v předchozím testu, a to, že měla dvakrát větší celkovou hodnotu společnosti. V příj- mech železniční a letecké přepravy TracAI dominoval, proto měl od Ad- miralAI velký náskok v celkové hodnotě společnosti. V testu s vhodnými podmínkami měl TracAI největší možný příjem v železniční přepravě ze všech provedených testů. 31 Figure 17: Výsledky testů TracAI proti AdmiralAI ve výchozím nas- tavení mapy – hodnota společnosti Figure 18: Výsledky testů TracAI proti WormAI ve výchozím nastavení mapy – příjem 32 Figure 19: Výsledky testů TracAI proti AdmiralAI v nevhodném nas- tavení mapy – hodnota společnosti Figure 20: Výsledky testů TracAI proti AdmiralAI v nevhodném nas- tavení mapy – příjem 33 Figure 21: Výsledky testů TracAI proti Admiral ve vhodném nastavení mapy – hodnota společnosti Figure 22: Výsledky testů TracAI proti AdmiralAI ve vhodném nas- tavení mapy – příjem 34 6.3 Výsledky testu TracAI proti nejlepším UI Poslední druh testu se zaměřuje na souboj TracAI se šesti nejlepšími existujícími UI v OTTD. Na obrázcích grafů lze vidět výsledky testů ve výchozím nastavením mapy 24 a 23, v nevhodném nastavení mapy 26 a 25 a ve vhodném nastavení mapy 28 a 27. V tomto testu TracAI poprvé nedominoval, ale zůstává mezi ne- jlepšími třemi UI. Konkurenty TracAI jsou pouze NoCAB a trAIns. Ve výchozím nastavení se na prvním místě umístil trAIns, který domino- val díky velmi vysokému příjmu z železniční přepravy, ale TracAI je mu velmi blížil. To se obrátilo při nevhodných podmínkách mapy při Tra- cAI dosáhl největší celkové hodnoty společnosti ze všech testovaných UI. Vhodné nastavení mapy prospívalo zase NoCAB, který jasně domi- noval svými vysokými celkovými příjmy. TracAI se umístil daleko za touto UI, na třetím místě. Zde je nutné podotknout, že při testování ve výchozím a vhodném nastavení mapy se často NoCAB nebo trAIns z neznámých důvodů společnosti nezačaly budovat infrastrukturu, což mohlo částečně zkreslit výsledky. Figure 23: Výsledky testů nejlepších UI ve výchozím nastavení mapy – hodnota společnosti 35 Figure 24: Výsledky testů nejlepších UI ve výchozím nastavení mapy – příjem 36 Figure 25: Výsledky testů nejlepších UI v nevhodném nastavení mapy – hodnota společnosti 37 Figure 26: Výsledky testů nejlepších UI v nevhodném nastavení mapy – příjem 38 Figure 27: Výsledky testů nejlepších UI ve vhodném nastavení mapy – hodnota společnosti 39 Figure 28: Výsledky testů nejlepších UI ve vhodném nastavení mapy – příjem 40 7 Závěr Cílem práce bylo netriviálním způsobem rozšířit existující UI o pod- poru železniční přepravy a porovnat výsledky rozšířené UI se stávajícími v OTTD. Jednotlivé cíle této práce byly splněny následovně. • Autorka se seznámíla s jazykem Squirrel a NoAI Framework, API pro tvorbu umělých inteligencí v OTTD; ukázkou tvorby kostry pro UI a popisem fungování debuggingu v OTTD. • Analýza existujících UI z oficiálního repozitáře OTTD: V rámci této práce byla provedena analýza umělých inteligencí bez imple- mentované železniční přepravy pro výběr vhodného kandidáta a analýza umělých inteligencí bez implementované železniční přepravy ke zjištění nejlepších UI pro případnou inspiraci. • Návrh a implemntace TracAI: V rámci této práce byly pop- sány základní vlastnosti (viz Kapitola 5.1), které by umělá in- teligence měla mít implementované. Autorce se podařilo splnit všechny body kromě úpravy terénu při stavbě trasy a schopnosti vylepšení tratí na nový typ, které, i když vylepšují UI, nejsou nutné pro její korektní běh. • Testování vytvořené UI: V rámci práce jsou zahrnuty výsledky rozsáhlých testů porovnávajících výkonnost TracAI s existujícími UI. Vytvořená umělá inteligence bude nahrána do oficiálního repozitáře OTTD BaNaNaS a následně dále rozvíjena. Do budoucna je možné TracAI rozšířit několika způsoby, napřík- lad přidáním podpory pro další typ přepravy, vylepšením algoritmu pro hledání tras, který není ideální, nebo upravením funkce pro stavbu signálů, které může způsobovat tzv. deadlock. 41 Bibliography [1] OpenTTD Team. OpenTTD [online]. ©2005–2014 [vid. 8.11.2014]. Dostupné z: http://www.openttd.org/en/. [2] DEMICHELIS, Alberto. Squirrel 2.2 Reference Manual [on- line]. ©2004-2014 [vid. 8.11.2014]. Dostupné z: http://www. squirrel-lang.org/. [3] DEMICHELIS, Alberto. Squirrel – The Programming Language [online]. ©2003-2011 [vid. 8.11.2014]. Dostupné z: http://www. squirrel-lang.org/doc/squirrel2.html#d0e520. [4] OpenTTD Team. OpenTTD NoAI API: Data Structures [online]. posledni aktualizace 21. října 2014, v 19:23 [vid. 8.11.2014]. Dos- tupné z: http://noai.openttd.org/docs/1.4.4/. [5] AI:Main Page – OpenTTD. Wikipedia [online]. poslední aktu- alizace 18. května 2012, v 17:31 [vid. 8.11.2014]. Dostupné z: http://wiki.openttd.org/AI:Main_Page. [6] OpenTTD Team. OpenTTD - BaNaNaS, AIs [online]. ©2005–2014 [vid. 8.11.2014]. Dostupné z: https://bananas.openttd.org/en/ ai/. [7] OpenTTD Team. OpenTTD - BaNaNaS, AI Libs [online]. ©2005–2014 [vid. 8.11.2014]. Dostupné z: https://bananas. openttd.org/en/ailibrary/. [8] AI:Indtroduction – OpenTTD. Wikipedia [online]. poslední aktu- alizace 30. září 2013, v 00:06 [vid. 8.11.2014]. Dostupné z: http: //wiki.openttd.org/AI:Introduction. [9] WISNIEWSKI, Maciej. Artifical Intelligence for OpenTTD game [online]. Kongens Lyngby: Technical University of Denmark. [vid. 9.11.2014]. Dostupné z: http://www2.imm.dtu.dk/pubdb/views/ edoc_download.php/6091/pdf/imm6091.pdf. ISSN 0909-3192. [10] RIOS, Luis H. O.; CHAIMOWICZ, Luiz. trAIns: An Artificial Inteligence for OpenTTD [online]. Rio de Janeiro: Univer- sidade Federal de Minas Gerais. [vid.2.4.2015]. Dostupné z: 42 BIBLIOGRAPHY http://www.sbgames.org/papers/sbgames09/computing/ full/cp24_09.pdf. [11] Cargo Income – OpenTTD. Wikipedia [online]. poslední aktual- izace 9. června 2012, v 15:25 [vid. 10.4.2015]. Dostupné z: https: //wiki.openttd.org/Cargo_income. [12] Comparison of AIs – OpenTTD. Wikipedia [online]. poslední ak- tualizace 8. února 2015, v 08:15 [vid. 10.4.2015]. Dostupné z: https://wiki.openttd.org/Comparison_of_AIs. [13] MILLINGTON, Ian. Artificial Inteligence for Games. A*. [online]. 2006. Morgan Kaufmann: Elsevier. s. 223-246. [vid.2.4.2015]. Dostupné z: http://www.sbgames.org/papers/sbgames09/ computing/full/cp24_09.pdfhttp://ldc.usb.ve/~vtheok/ cursos/ci5325/lecturas/Artificial%20Intelligence% 20for%20Games.pdf. ISBN 0-12-497782-0. [14] RUSSEL, Stuart; NORVIG, Peter. Artificial Inteligence – Modern Approach. 3rd Edition [online]. 2010. Upper Saddle River: Prentice Hall. s. 34 [vid.2.4.2015]. Dos- tupné z: http://51lica.com/wp-content/uploads/2012/05/ Artificial-Intelligence-A-Modern-Approach-3rd-Edition. pdf. ISBN 0-13-604259-7. 43 BIBLIOGRAPHY A Příloha A – zdrojové kódy kostry UI A.1 Příloha A.1 – info.nut class DadlooAI extends AIInfo { function GetAuthor() { return "dadloo"; } function GetName() { return "TestAI"; } function GetDescription() { return "Testing AI"; } function GetVersion() { return 1; } function GetDate() { return "2014 −10 −18"; } function CreateInstance() { return "TestAI"; } function GetShortName() { return "TTTT"; } } RegisterAI(DadlooAI()); 44 BIBLIOGRAPHY A.2 Příloha A.2 – main.nut class TestAI extends AIController { function Start() { AILog.Info("TestAI Started ."); SetCompanyName (); //Keep running. If Start() exits, the AI dies. while (true) { AILog.Info("I am test AI and I am at tick " + this.GetTick()); this.Sleep(100); } } function Save() {} function Load(version , data) {} function SetCompanyName() { if (!AICompany.SetName("Test AI")) { l o c a l i = 2 ; while(!AICompany.SetName("Test AI #" + i)) { i = i + 1 ; if(i > 255) break; } } AICompany.SetPresidentName("P. Resident "); } } B Příloha B - podrobné výsledky testů Podrobné výsledky testů lze nalézt v přiloženém soubore result.xlsx 45
Umělá Inteligence Do Openttd
