VŠB Ű Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
API pro práci se strategiemi a taktikami 3D simulátoru pro hru fotbalu robotů API for Management of Strategies and
Tactics of 3D Simulator for Robot Soccer Game
2019 Sebastián Husár
Rád by som veľmi poďakoval Ing. Kateřine Slaninové, Ph.D., ktorá bola moja vedúca a konzul- tantka tejto práce a daľej Ing. Václavovi Svatoňovi, Ph.D., za ich čas strávený nad problematikou tohto projektu a ich cenné rady.
Abstrakt
Táto práca sa zaoberá vylepšením a úpravou už stávajúceho 3D simulátoru pre hru futbalu robotov v Unity Engine 3D. Vylepšenie predstavuje tvorbu API pre prácu so stratégiami a tak- tikami daného simulátoru. Vytvorené API prinieslo možnosť uživateľovi nahrávať vlastnoručne vytvorené taktiky a stratégie robotov, ktoré musia spĺnať požadovanú štruktúru a funkčnosť.
Kľúčové slová: 3D Simulátor pre hru futbalu robotov, 3D Unity Engine, futbal robotov, simu- látor, API
Abstract
This work deals with upgrading and editing of existing 3D simulator for robot soccer game in Unity Engine 3D. As upgrade we mean creating API for work with strategies and tactics of existing simulator. Created API has brought opportunity to user to load his own created tactics and strategies for this simulator, which have to fulĄll required structure and functionality.
Key Words: 3D Simulator for robot soccer game, 3D Unity Engine, robot soccer, simulator, API
Obsah
Zoznam použitých skratiek a symbolov 8
Zoznam obrázkov 9
Zoznam tabuliek 10
Zoznam výpisov zdrojového kódu 11
1 Úvod 12
2 Herné enginy 13
2.1 Herný engine . . . 13
2.2 Unity Engine 3D . . . 15
3 Simulátor futbalu robotov 19 3.1 Stratégie a pravidlá . . . 19
3.2 Rozdelenie simulátoru . . . 22
3.3 Povinná štruktúra nahrávaných DLL súborov . . . 23
3.4 Uživateľské rozhranie simulátoru (GUI) . . . 26
3.5 Adaptácia stratégií . . . 36
3.6 Detailnejšie podrobnosti kontroly a nahrávania dll súborov . . . 43
3.7 Simulátor ako OpenSource . . . 46
4 Záver 48
Literatura 49
Prílohy 49
A Stratégia ľavého tímu 50
B Ukážky vyextrahovaných sekvencii odohratých zápasov 51
Zoznam použitých skratiek a symbolov
AI Ű ArtiĄcial intelligence
API Ű Application programming interface
DLL Ű Dynamic Link Library
PC Ű Personal computer
VR Ű Virtual reality
Zoznam obrázkov
1 Príklad GameObjectu . . . 18
2 Reprezentácia hernej plochy simulátoru . . . 20
3 Z-order mapovanie a graf pravidiel . . . 21
4 Starý model simulátoru . . . 22
5 Nový model simulátoru . . . 23
6 Hlavná štruktúra dll súboru . . . 24
7 Hlavná štruktúra dll súboru s použitím StrategyAdaptation . . . 25
8 Ukážka predošlého prostredia simulátoru . . . 26
9 Ukážka nového hlavného menu . . . 28
10 Náhľad menu umožnujúce nahratie DLL súborov s taktikami a stratégiami . . . . 29
11 Indikátor „Všetko v poriadkuŞ . . . 30
12 Indikátor „ChybaŞ . . . 30
13 Error Log . . . 30
14 Strategy adaptation menu . . . 31
15 Náhľad hernej plochy simulátoru . . . 32
16 Časti hernej plochy . . . 33
17 Ukážka esc menu . . . 34
18 Model robota „Wall-EŞ . . . 35
19 Model robota „Threshing ClawerŞ . . . 35
20 Náhľad 3D modelov prostredia . . . 36
21 Výsledky zápasov real-time adaptácie . . . 40
22 Základná stratégia pre ľavý tím - LCSS . . . 41
23 Adaptovaná stratégia pre ľavý tím - LCSS . . . 41
24 Set 1 - 10. iterácia porovnania sekvencií pomocou LCSS . . . 42
25 Náhľad dokumentácie simulátoru na webovej stránke GitHub . . . 47
Zoznam tabuliek
1 Unity 3D licencie . . . 16
2 Ukážka štruktúry stratégie . . . 20
3 Výsledky odohratých zápasov . . . 38
4 Adaptovaná defenzíva vs. predošlá pravá stratégia . . . 38
5 Adaptovaná defenzíva a ofenzíva vs. predošlá pravá stratégia . . . 39
6 Set 1, Reprezentácia postupnosti pravidiel 10. iterácie pomocou LCSS . . . 43
Zoznam výpisov zdrojového kódu
1 Implementacia LogHolder triedy . . . 25 2 Úryvok kódu z MenuUIController scriptu . . . 28 3 Kód ktorý počas hry skúma či uživateľ chce využívať triedu StrategyAdaptation 31 4 Pauza a zmena rýchlosti hry . . . 33 5 Kontrola DLL súborov . . . 43 6 Konečné overovanie DLL súborov . . . 44
1 Úvod
Simulátor obecne je počítačový program alebo osobitné zariadenie, ktoré modeluje (simuluje) aspekty reálneho života (napr. simulátor lietadla) a môže byť ovládaný tak, aby sme sledovali výsledky rôznych predpokladov alebo činností, bez toho aby sme boli vystavení akémukoľvek riziku alebo hrozbe.
Simulátor futbalu robotov reprezentuje neisté a dynamické prostredie spolupracujúcich čin- niteľov v našom prípade robotov, kde uživateľ môže deĄnovať ich správanie pomocou deĄnícii stratégii a taktík. Stratégiou z pohľadu hernej teórie, chápeme množinu možností, ktoré má uživateľ k dispozícii v danej situácii, za cieľom dosiahnuť požadovaný výsledok. Tento princíp môže byť aplikovateľný v rôznych oblastiach reálneho života a obecne sa nazýva strategické plánovanie. Tento simulátor futbalu robotov používa stratégie pre opis prostredia a objektov v ňom. Tento simulátor je zaujímavý v rôznych oblastiach výskumu. Dá sa využiť v oblastiach ako napríklad oblasť ovládania robotov, AI, plánovanie trasy a analýza obrazu [7], [5]. Simulátor futbalu robotov sa riadi medzinárodnými pravidlami pre simulátor futbalu robotov, viď1.
Hlavnou náplňou tejto práce bolo vytvorenie prostredia, ktoré by malo umožniť použiva- teľovi počas chodu simulátoru nahrávať jeho vlastné deĄnície stratégii a taktík v podobe .dll súborov do už stávajúceho simulátoru futbalu robotov a tým prepojiť funkcionalitu simulátoru s týmito súbormi. Ďalej okrem tohoto cieľa boli ako bonus vykonané zmeny na vzhľade a dal- šej funkcionalite simulátoru, ktoré budú viac opísané v nasledujúcich kapitolách. Na simulátore boli vykonané rôzné experimenty pomocou adaptácie stratégií, vizualizácie a adaptácie. Takisto bol tento simulátor oĄciálne zaregistrovaný ako software a následne vydaný ako OpenSource na webovej stránke GitHub a tým bol sprístupnený verejnosti.
Kapitola 2 sa zaoberá teoretickou časťou o programe Unity 3D v ktorom sa odohrávala celá práca na tomto simulátore.
V kapitole 3 sa nachádza praktická časť v ktorej sú detailnejšie popísané všetky zmeny, ktoré boli na simulátore vykonané ako: rozdelenie simulátoru, nové uživateľské rozhranie, nové 3D modely atď. Takisto je tam popísaná funktionalita adaptácie stratégii, jej opis a problematika adaptácie stratégii. Ďalej sa práca zaoberá samotnou problematikou dynamického nahrávania, kontroly .dll súborov a prepájaním ich funkcionality so simulátorom čo bolo hlavným cieľom tejto práce. Nakoniec je v tejto kapitole opísaná samotnoá oĄciálna registrácia tohto simulátoru a následné vystavenie tohto simulátoru verejnosti ako OpenSource.
1http://firaworldcup.org/visitorpages/Show.aspx?ItemID=805,0
2 Herné enginy
Táto kapitola opisuje čo je to herný engine, základné vlastnosti herných enginov, ktoré herné enginy sú v dnešnej dobe najpoužívanejšie a ich základné charakteristiky. Ďaľej sa zaoberá podrobnejším opisom herného enginu Unity 3D, ktorý bol použitý v tejto práci.
2.1 Herný engine
Herný engine je softvérový framework vyvinutý za účelom vývoju a úpravy videohier[3]. Vývojári tieto herné enginy využívajú pre tvorbu hier pre konzoly, mobilné zariadenia a PC. Herný engine nie vždy slúži len na vývoj videohier ale takisto aj na tvorbu webových aplikácii a rôznych pluginov.
Jadro funkcionality herného enginu typicky obsahuje engin pre rendering (2D alebo 3D gra- Ąku), fyziku alebo detekciu kolizii, zvuk, skriptovanie, animácie, networking, streaming, memory magement, threading, localization support a môže obsahovať podporu pre prehrávanie videa pre rôzne Ąlmové ukážky využívané v hrách.
Proces vývoju hier je vďaka týmto enginom veľmi ušetrený kôli znovupoužiteľnosti rovnakého herného enginu pre tvorbu rozličných hier a vývoju jednej hry pre viacero platforiem. Proces vývoju hier sa vďaka týmto enginom uľahčil a predstavuje veľký pokrok vo vývoji hier. V dnešnej dobe je čím daľej viac hier vyvíjaných v herných enginoch a to vďaka prehľadnosti, jednoduchosti a v niektorých prípadoch aj bezplatnosti týchto herných enginov.
2.1.1 Najpopulárnejšie herné enginy
Dnes medzi tie najpopulárnejšie herné enginy patria:
• Unreal Engine
• CryEngine
• Unity Engine 3D Unreal Engine[1]
Bezpochyby jeden z najpopulárnejších a najúspešnejší herný engine v dnešnej dobe - ocenenie Guinnesovým rekordom. Veľmi dobrý na budovanie rozsiahlych a soĄstikovaných hier.
• Tvorca: Epic Games
• Podporované platformy: Windows, Mac, Linux, iOS, Android, Playstation, Xbox atď.
• Uživatelia: Capcom, Activision, Ubisoft, Microsoft Studios, Nintendo atď.
• Populárne hry: Marvel Heroes, Batman: Arkham Origins, WWE Immortals, PUBG, Fortnite atď.
• Licencia:Voĺno dostupný (developer odvádza 5% zárobku produktu ak produkt presiahne prvých 3 000$)
Cry Engine[1]
Veľmi silný herný engine, ktorý poskytuje vývojárom plný prístup k zdrojovým kódom a neúčtuje vývojárom žiadne poplatky. Je známy pre nástroje na tvorbu veľmi peknej graĄky a prostredia.
Takisto obsahuje Fmod, čo je jeden z najlepších herných audio nástrojov.
• Tvorca: Crytek
• Podporované platformy: Windows, Linux, iOS, Android, Playstation, Xbox a Wii.
• Uživatelia: Poppermost Production, CI Games, Obsidian Entertaiment, atď.
• Populárne hry: Far Cry, Crysis, Sniper: Ghost Warrior 2, atď.
• Licencia: Voĺno dostupný, členstvo sa pohybuje okolo 50$ mesačne.
Unity Engine 3D[1]
Takisto ako aj predošlé dva aj Unity 3D patrí dnes medzi rozšírené herné enginy. V dnešnej dobe 34% z top 1000 mobilných hier je práve vyvínutých pomocou Unity Engine 3D [1].
• Tvorca: Unity Technologies
• Podporované platformy: Windows, Mac, iOS, Android, Playstation, Xbox, Windows Phone, Tizen, atď.
• Uživatelia: Electronic Arts, LEGO, Ubisoft, Square Enix, atď.
• Populárne hry: Pokémon GO, Super Mario Run, Angry Birds 2, Wasteland 2, atď.
• Licencia: Voĺno dostupný pre osobné účely, členstvo sa pohybuje okolo 35$ mesačne.
Zatiaľ čo Unreal engine a Cry engine sa zaoberajú hlavne vývojom hier pre PC platformu, Unity engine 3D napreduje hlavne vďaka vývoju mobilných hier a obľúbenosti mobilných vývo- járov. Takisto je známy vďaka napredovaniu vo VR, kde je používaný v 90% Samsung Gear VR a 53% Oculus Rift hrách.
Simulátor robotov bol vyvíjaný niekoľko rokov práve v Unity Engine 3D a úlohou tejto práce bolo ďalej sa podieľať na vývoji v tomto hernom engine a ďalej tento simulátor vylepšovať a upravovať. Podrobnejšiemu opisu Unity enginu sa zaoberá nasledujúca kapitola 2.2.
2.2 Unity Engine 3D
2.2.1 Čo je Unity Engine 3D
Unity 3D je multiplatformový herný engine vyvinutý spoločnosťou Unity Technologies v roku 2005. Prvá verzia bola predstavená na konferencii Apple a podporovala len systém OS X. Neskôr bol tento engine rozvinutý o viac ako pätnásť ďalších platforiem. Unity poskytuje možosť vývoja pre 2D, 3D a VR hry ľubovoľného žánru a zamerania, pre rozličné platformy. Takisto Unity Engine poskytuje možnost vývoja desktopových a mobilných aplikácií a webových rozhraní.
Avšak tvorba hier je najdominantnejšia.
Okrem graĄckého zamerania pre tvorbu, podporuje aj tvorbu skriptov a to predovšetkým v jazyku C#. Unity Engine podporuje aj dalšie dva programovacie jazyky, Java a Boo, ktoré sú menej rozšírené oproti vyššie spomínanému C#. Výhodou graĄckého prostredia Unity Enginu je hlavne „drag and dropŞ funkcia, ktorá uživateľovi umožnuje rýchlu a jednoduchú tvorbu hier a aplikácii.
Unity Engine predstavuje veľmi dôležitú časť v dnešnom hernom priemysle. Čím daľej sa vyvíja viac a viac hier na tomto engine a to vďaka jeho jednoduchosti a bezplatnosti.
2.2.2 Podporované platformy
Platformy, ktoré podporuje Unity Engine:
1. Mobilné: iOS ,Android, Tizen a Windows mobile 2. Desktop: Universal Windows Platform, Linux a MacOS 3. Web: WebGL
4. Konzoly: PlayStation 4, Playstation Vita, Xbox One, Wii U, Nintento 3DS, Nintendo Switch
5. Virtuálna realita: Oculus Rift, Google Cardboard, Steam VR, Playstation VR, Gear VR, Windows Mixes Reality, Daydream
6. Ostatné: Android TV, Samsung Smart TV, tvOS, FireOS, Facebook Gameroom, Apple ARKit, Google ARCore, Vuforia
Unity Engine má vlastný Unity Web Player, ktorý bol vyvinutý ako plugin do webových pre- hliadačov na podporu prehrávania webových projektov, ako napríklad hier a aplikácií, ktoré boli vyvinuté práve Unity Enginom. Najskôr bol tento plugin podporovaný len systémami Windows a OS X a až neskôr sa dostal do ostatných systémov.
Ohľadom práce v 2D, Unity Engine umožnuje import spritov a pokročilejšieho 2D rendero- vania. Čo sa týka 3D herného prostredia, Unity Engine umožnuje špeciĄkáciu compresie textury,
mipmapovania a nastavenie rozlíšenia pre každú z vyššie uvedených platforiem. Ďalej Unity En- gine poskytuje podporu pre: bump mapping, reĆection mapping, parallax mapping, screen space ambient occlusion (SSAO), dynamické tienovanie a full-screen post-processing effects.
2.2.3 Podporované graĄcké API
Unity Engine zahŕňa nasledujúce graĄcké API:
1. Direct3D- Windows, Xbox One 2. OpenGL - Windows, Linux, macOS 3. OpenGL ES - Android, iOS
4. WebGL - web
Mimo vyššie uvedené graĄcké API Unity Engine podporuje aj low-level API ako: Mental pre iOS a macOS, Vulkan pre Android, Linux a Windows a v poslednom rade Direct3D 12 pre Windows a Xbox One.
2.2.4 Licencie Unity Engine 3D
Unity engine prichádza v štyroch licenčných podobách, ktoré sú uvedené v tabuľke 12:
License Name All engine Features Multiplayer Performance Reporting Premium Support Access to Source Code
Personal YES 20 CCUs NO NO NO
Plus YES 50 CCUs YES NO NO
Pro YES 200 CCUs YES YES NO
Enterprise YES Custom Multiplayer YES YES YES
Tabuľka 1: Unity 3D licencie 2.2.5 Prostredie Unity 3D
Prostredie Unity sa skladá z Unity project manageru a editoru, kde editor je tou hlavnou a najpodstatnejšou časťou Unity enginu.
Unity project manager
Domovská obrazovka, ktorá sa objaví po spustení Unity a umožnuje správu našich projektov a možnosť vzdelávania sa v oblasti Unity pomocou rôznorodých tutoriálov.
GraĄcké prostredie Unity Editoru
Srdce Unity enginu, v ktorom sa odohráva samotný proces vývoju aplikácii. Unity Editor disponuje špeciálnym rozložením spravovacích okien, vďaka ktorým je práca v Unity prehľadná a jednoduchá. GraĄcké rozhranie Unity Editoru by sa dalo rozdeliť do 5-tich skupín:
2https://store.unity.com/compare-plans
1. Hierarchy Window - hierarchická prezentácia každého objektu v scéne.
2. Toolbar - predstavuje prístup k najnevyhnutelnejším nástrojom, ktoré sú potrebné pri práci v Unity Editore. Naľavo obsahuje základné nástroje na mainupuláciu so scénou a objektami v nej. V strede toolbaru sa nachádzajú play, pause a step control tlačidlá. V poslednom rade na pravej strane toolbaru sa nachádzajú tlačidlá na prístup k Unity Cloud Services a Unity Account.
3. Scene View-umožnuje nám sa vizuálne navigovať v scéne a upravovať ju. Takisto umož- nuje zobrazovanie v 2D alebo 3D perspektíve, zavisí na našom projekte.
4. Inspector Window - dovoľuje nám vidieť a upravovať všetky vlastnosti nami zvoleného objektu. Nie vždy ma Inspector Window rovnaký vzhľad kvôli rozličnosti objektov v scéne a ich rozličných vlastností.
5. Project Window - zobrazuje našu knižnicu pomôcok, ktoré je možné v našom projekte využiť alebo sa už využívajú. Keď sú do projektu naimportované rôzne assety sú zobrazené práve tu.
2.2.6 Prostredie a základné pojmy Unity 3D
Tie najzákladnejšie pojmy v Unity 3D sú gameObject, hlavný stavebný prvok celého gameEnginu a asset store, v ktorom si môžme sťahovať už predpripravené gameObjekty od iných uživateľov a následne ich implementovať do nášho projektu a tým si ušetriť kopec práce.
Asset store Unity 3D disponuje vlastnou webstránkou 3 určenou na získavanie rôznych assetov (modely, textúry, fonty...). Toto rozhranie dovoľuje uživateľom pridávať ich vlastnoručne vytvorené assety alebo ich získavať. Uživateľ ich môže získať zadarmo alebo za určitú peňažnú čiastku. Toto rozhranie uľahčuje prácu v Unity a to vďaka tomu, že uživateľ nemusí vytvárať vlastné assety, jednoducho ich stačí na asset store nájsť a pripojiť do projektu.
GameObject
Predstavuje najdôležitejšiu čast v Unity Editore. Každý objekt, ktorý sa nachádza v scéne predstavuje GameObject, ktorý vytvára celkový vzhľad nášho projektu. Avšak na to musíme každému objektu prideliť jeho vlastnosti aby sme tým deĄnovali jeho správanie a úlohu, ktorú v projekte predstavuje (prostredie, hráč, nepriateľ, svetlo, atď). Vlastnosti, ktoré budeme Ga- meObjectu pridávať sa nazývajú Komponenty. Ukážku GameObjectu môžme vidieť na obrázku 1.
3https://assetstore.unity.com/
Obr. 1: Príklad GameObjectu Základné komponenty GameObjectu
Každý GameObject má pridelenú komponentu Transform, ktorá určuje jeho pozíciu a orien- táciu v scéne, túto komponentu nie je možné odstrániť. Ostatné komponenty je možné prideliť ručne. Medzi tie najzákladnejšie komponenty patria:
1. Rigidbody 3D - hlavná komponenta, ktorá umožnuje deĄnovať fyzicke správanie pre GameObject. Akonáhle pridelíme Rigidbody objektu začne automaticky reágovať na gra- vitáciu.
2. Collider - deĄnuje tvar objektu za cieľom fyzickej interakcie. Collider nie je viditeľný a nemusí byť rovnakej veľkosti ako GameObject na ktorý je pridelený, veľkosť a tvar deĄnuje uživateľ. Základné tvary collideru sú: Box Collider, Sphere Collider a Capsule Collider. V 2D je možné využiť Box Collider a Circle Collider. Pre vlastnú deĄníciu tvaru Collideru slúžia Mesh Collider a v 2D Polygon Collider 2D.
3. Particle System - sú to malé, jednoduché obrazky ktoré sú zobrazované mnoho krát partical systémom. Ako príklad môže slúžit dym, ktorý sa skladá z mnoho menších častic, ktoré dohromady vytvárajú efekt dymu.
4. Script - každému GameObjectu v projekte môžeme prideliť Script v ktorom mu progra- mujeme chovanie alebo chovanie iných objektov.
5. Audio - pridelenie zvukového efektu objektu.
3 Simulátor futbalu robotov
V tejto kapitole sa budeme zaoberať podrobnejšim opisom zmien a vylepšení, ktoré boli v už stávajúcom simulátore vykonané. Avšak najskôr treba lepšie priblížiť informácie o simulátore ako takom.
Ako vyplýva už z názvu jedná sa o typ simulátoru, ktorý simuluje futbalový zapas medzi dvoma tímami robotov. Na hracom poli sa nachádzajú dva tímy robotov, kde sa v každom tíme nachádza päť robotov. Roboti majú presne deĄnované svoje správanie v podobe deĄnícií strategií a taktík, ktoré určujú ako sa majú chovať v určitých situáciach, ktoré môžu na hracom poli nastať. Tieto situácie vyplývajú z pozície všetkých objektov na hracom poli (oponent, lopta, spoluhráč)[4].
Simulátor slúži predovšetkým na simuláciu futbalového zápasu medzi robotmi, kde uživateľ má možnosť nadeĄnovať si vlastné správanie robotov v podobe.strgsúboru, obsahujúce stratégie robotov. Herné pole simulátoru je logicky rozdelené na časti (viď obrázok 2), presnejšie mriežku, kde práve spomínaný súbor obsahujúci stratégie pracuje s týmto gridom a kde pomocou neho deĄnuje ako sa majú roboti správať v opísanej situácii. Súbor obsahuje vo vnútri sadu pravidiel, kde každé pravidlo obsahuje: informáciu o pozícií súperových hráčov, vlastných hráčov a lopty (čo vyjadruje situáciu, ktorá môže behom hry nastať) a nakoniec obsahuje kam sa majú moji roboti v tejto situácii presunúť. Na základe tejto sady pravidiel, ktorá sa pred spustením hry načíta v podobe.strg súboru, sa počas hry roboti správajú. Podrobnejší opis tejto funkcionality sa nachádza v kapitole 3.1.
Ďaľej uživateľ má možnosť nahrať dynamicky do simulátoru pomocou API vlastný.dll súbor, pred spustením simulátoru, ktorý rieši ako bude simulátor vyberať tie správne pravidlá, z vyššie spomínaného súboru stratégii, a taktiku robotov. Pod taktikou robotov chápeme napríklad výber tej najlepšej cesty k lopte, oblasť záujmu robotov o loptu atď. Dll súbor musí spĺnať určitú štruktúru aby pracoval správne so simulátorom. Toto umožnenie uživateľovi nahrať vlastný.dll súbor do simulátoru je hlavnou náplňou tejto práce a je daľej podrobnejšie opísané. Takisto má použivateľ možnosť získať po zápase výsledky z priebehu hry, v ktorých má možnosť vidieť svoje chyby a podľa nich svoje deĄnície stratégii ďalej vylepšovať pomocou adaptácie stratégii, ktorá je opísaná v kapitole 3.5.
3.1 Stratégie a pravidlá
Architektúra simulátoru používa dva typy reprezentácie hernej plochy (viď obrázok 2):
• veľmi presný súradnicový systém, používaný pre presnejšiu koordináciu robotov na hernej ploche
• gridový systém, ktorý sa používa pre deĄníciu strategií - herná plocha je rozdelená na grid (mriežku)
Obr. 2: Reprezentácia hernej plochy simulátoru
Využitím gridového súradnicového systému zredukujeme presnosť mapovania fyzických sú- radníc robotov na logické súradnice. Tým pádom môžme jednoducho podľa týchto súradnic opísať situáciu na hernom poli a na túto situáciu reagovať. Pre toto nám slúžia už spomínané stratégie, ktoré si uživateľ deĄnuje a pred spustením simulácie ich nahrá v menu, toto menu a nahrávanie stratégií je opísané v kapitole 3.4.3. Táto stratégia je v podstate textový súbor, ktorý má určitú štruktúru, viz tabulka 2. Tento súbor obsahuje množinu pravidiel, kde každé pravidlo deĄnuje čo majú roboti v danej situáci robiť a ako sa zachovať. Jednotivé pravidlo ob- sahuje: pozíciu súperových robotov, pozíciu mojich robotov, pozíciu lopty a kam sa majú moji roboti pohnúť ak táto situácia nastane. Herná plocha simulátoru je presnejšie rozdelená na grid (mriežku) o veľkosti 6x4.
1
Mine 4,2 4,3 2,2 2,3 Oppnt 4,2 4,3 5,1 5,4
Ball 4,2
Move 5,2 5,3 2,2 3,3
2
Mine 5,2 5,3 2,2 3,3 Oppnt 5,2 5,3 5,1 5,4
Ball 5,2
Move 6,2 5,3 2,2 3,3
3
Mine 6,2 5,3 2,2 3,3 Oppnt 5,2 5,3 5,1 5,4
Ball 6,2
Move 6,2 5,3 2,2 3,3
Tabuľka 2: Ukážka štruktúry stratégie
3.1.1 Výber pravidla
Počas hry sa tieto deĄnované pravidlá musia overovať voči situácii na hernej ploche a podľa toho vybrať pravidlo, ktoré sa v danú chvíľu použije. Tento výber pravidla má na starosti API, dll nahraté do simulátoru, ktoré by malo tento výber pravdila v danej situácií uskutočniť.
Ako bolo vyššie spominané každých 20 ms sa volá metóda z dll súboru kde ako parameter sa posiela trieda StrategyStorage obsahujúca informácie o situácii na hernom poli ako je pozícia všetkých hráčov a pozícia lopty. Na základe týchto údajov by malo dané API vybrať to najlepšie pravidlo a tým reagovať na danú situáciu.
V už existujúcom API, ktoré bolo oddelené od simulátoru a teraz je nahravané dynamicky (podrobnejší opis v kapitole 3.2.2), tento výber najlepšieho pravidla bol realizovaný pomocou Z-order algoritmu a grafu. Z-order algoritmus bol použitý pretože roboti na hracom poli nemajú presný identiĄkátor alebo presne danú rolu. Z-order algoritmus práve mapuje viac-dimenzionálny priestor do jedno-dinemzionálneho takže v našom prípade bol použitý pre konvertovanie dvoj- dimenzionálnej matice, reprezentujúcej herné pole, na jedno-dimenzionálne pole s individuál- nymi pozíciami robotov. Graf bol použitý na reprezentáciu pravidiel v danej stratégii. Každý uzol predstavuje pravidlo danej stratégie a hrana obsahuje evaluáciu čo korenšponduje vzdiale- nosti medzi dvoma susednými uzlami (pravidlami), ktorá bola vypočítana pomocou Euklidovej vzdialenosti, viz obrázok 3.
Obr. 3: Z-order mapovanie a graf pravidiel
Takisto môžeme v stratégií deĄnovať podrobnejšie pravidlá (substratégie). Substratégia pred- stavuje herné situácie ako ofenzíva pravého krídla alebo defenzíva ľavého krídla.
V priebehu hry sa teda vyberá to najlepšie pravidlo odpovedajúce hernej situácii na hracom poli a následne nám API vráti súradnice, kam sa majú roboti pohnúť a simulátor tento presun zabezpečí. Kedže môže nastať veľmi veľa situácii na hracom poli a nie vždy uživateľ dokáže po- písať všetky, tak sa vyhodnocuje podobnosť pravidla so situáciou a vyberie sa pravidlo podobné danej situácií.
3.2 Rozdelenie simulátoru
Pre umožnenie uživateľovi nahrávať vlastné .dll súbory, obsahujúce stratégie a taktiky, bolo nutné prerobiť štruktúru starého simulátoru na novú, pričom bolo nutné zrušit závislosť hlav- ného projektu na projekte obsahujúcom deĄnície stratégí a taktik a tým docieliť dynamické nahrávanie .dll súborov obsahujúcich stratégie a taktiky. Toto nahrávanie bolo docielené po- mocou jazyka c#, presnejšie knižníc assembly a reĆection, vďaka ktorým sú funkcie potrebné k chodu simulátoru z oddelených projektov dynamicky načítavané z pripojených .dll súborov obsahujúcich deĄnície stratégii a taktík.
3.2.1 Starý model simulátoru
Zjednodušený starý model simulátoru, kde všetky triedy boli zahrnuté v jednom projekte a simulator bol na nich závislý, je zobrazený na obrázku 4. Informácie o robotoch a informácie zo.strg súboru boli posielané do triedy Storage a GridStrategy odkial boli posielané údaje do triedy Strategy z ktorej volala hlavná funkcia TickTactic v hlavnom scripte simulátoru MainControl a vracala údaje späť do Storage. Ďalej bola volaná funkcia TickTactic a takisto vracala údaje triede Storage.
Obr. 4: Starý model simulátoru 3.2.2 Nový model simulátoru
Na obrázku 5 môžeme vidieť zjednodušený model nového simulátoru. V porovnaní so starým mo- delom boli z projektu odstránene závislosti na Strategy a Tactic projektoch a oba boli presu- nuté pod jeden spoločný projekt, ktorý vracal výsledný.dllsúbor. To znamená, že simulátor ostal nezávislý na týchto triedach, čo bolo cieľom. Tým pádom je projekt pripravený na dynamické na- hrávanie.dll súborov, ktoré obsahujú deĄnície strategí a taktík dôležité pre chod simulátoru. Dll súbor je nahrávaný dynamicky a sú z neho volané funkcie TickStrategy, ktoré ako parameter
využívajú inštanciu triedy StrategyStorage obsahujúcu informácie o pozicí robotov na her- nom poli. Tieto funkcie naspäť vracajú inštanciu triedy StrategyStorage späť do simulátoru, ktorý ju daľej spracúvava. Dll súbor takisto môže obsahovať triedu StrategyAdaptation. Táto trieda nie je povinná, zaleží na tom či ju uživateľ do projektu inplementuje a chce ju využívať.
Podrobnejšiemu popisu o nahrávaní .dll súboru a jeho štruktúre sa budeme venovať v dalších kapitolách.
Obr. 5: Nový model simulátoru
3.3 Povinná štruktúra nahrávaných DLL súborov
Aby bol uživateľ schopný vytvoriť projekt obsahujúci stratégie a taktiky, musí pri tvorbe jeho projektu dodržiavať predpísanú štruktúru, inak výsledný.dllsúbor nebude možné do simulátoru pripojiť.
Projekt musí obsahovať:
1. Triedu PlayerStrategy.
2. Konštruktor triedy PlayerStrategy s parametrami: GameSetting, String a bool. Inštancia triedy GameSetting obsahuje informácie o nastaveniach hry a herného poľa, String parameter predstavuje názov súboru, do ktorého sú predávané informácie o prie- behu hry. Parameter bool predstavuje informáciu o tom či sa bude jednáť o pravý alebo ľavý tíma tým sa zabezpečí otočenie nastavení.
3. V triede PlayerStrategy hlavnú metódu TickStrategy, ktorá je volaná v simulátore v metóde Tick.
4. Metóda TickStrategy musí ako parameter brať inštanciu triedy StrategyStorage ob- sahujucu aktuálne informácie o robotoch na hracom poli.
5. Ďalej trieda PlayerStrategy obsahovať funkciu CurrentRuleNumber vracajúca aktu- álne číslo využívaného pravidla.
Projekt ďalej môže/nemusí obsahovať:
1. Triedu StrategyAdaptation.
2. Konštruktor triedy StrategyAdaptation bez žiadnych potrebných parametrov.
3. V triede StrategyAdaptation sa musí nachádzať hlavná funkcia AdaptStrategy vra- cajúca list typu object, kde objekty predstavujú stratégie. Ako parameter táto metóda musí brať object predstavujúci inštanciu triedy LogHolder a object predstavujúci in- štanciu triedy Strategy.
4. Triedu LogHolder, obsahujúcu informácie o pozíciach všetkých robotov a hernej situ- ácii(čas, skóre atď.). Triedu LogHolder uživateľ môže implementovať podľa kódu uvede- ného nižšie.
5. Trieda PlayerStrategy musí obsahovat metódu AdaptStrategy, ktorá ako parameter vyžaduje List<object>.
Toto je povinná štruktúra dll súboru, ktorú musí uživateľ dodržať. Ostatný obsah jeho pro- jektu závisí čisto na uživateľovi.
3.3.1 Hlavná štruktúra bez StrategyAdaptation
Na obrázku 6 môžme vidieť hlavnú štruktúru API bez implementácie StrategyAdaptation.
Obr. 6: Hlavná štruktúra dll súboru 3.3.2 Hlavná štruktúra s implementáciou StrategyAdaptation
Na obrázku 7 je hlavná kostra simulátoru s implementáciou StrategyAdaptation. Funkci- onalita StrategyAdaptation slúži na vylepšovanie uživateľových stratégii a je podrobnejšie opísaná v kapitole 3.5.
Obr. 7: Hlavná štruktúra dll súboru s použitímStrategyAdaptation
Ak chce uživateľ používať StrategyAdaptation triedu musi spolu s ňou implementovať do svojho projektu aj triedu LogHolder, ktorú StrategyAdaptation vyžaduje ako parameter vo funkcii AdaptStrategy. Implementácia LogHolder triedy, viz výpis 1:
public class PositionsHolder {
public PositionsHolder(int lr, int rr, Vector2D ball, Vector2D r1, Vector2D r2, Vector2D r3, Vector2D r4, Vector2D r5, Vector2D l1, Vector2D l2, Vector2D l3, Vector2D l4, Vector2D l5, string score, string time, int control) {
ballPosition = new Vector2D(0.0, 0.0);
leftPlayerRobots = new Vector2D[5];
rightPlayerRobots = new Vector2D[5];
lRule = lr;
rRule = rr;
ballPosition = ball;
leftPlayerRobots[0] = l1;
leftPlayerRobots[1] = l2;
leftPlayerRobots[2] = l3;
leftPlayerRobots[3] = l4;
leftPlayerRobots[4] = l5;
rightPlayerRobots[0] = r1;
rightPlayerRobots[1] = r2;
rightPlayerRobots[2] = r3;
rightPlayerRobots[3] = r4;
rightPlayerRobots[4] = r5;
this.score = score;
this.time = time;
this.control = control;
}
public int lRule;
public int rRule;
public Vector2D ballPosition;
public Vector2D[] leftPlayerRobots;
public Vector2D[] rightPlayerRobots;
public string score;
public string time;
public int control;
}
public class LogHolder {
public List<PositionsHolder> positions;
public LogHolder() {
positions = new List<PositionsHolder>();
} }
Výpis 1: Implementacia LogHolder triedy
Trieda LogHolder obsahuje vovnútri triedu PositionsHolder obsahujúcu konštruktor, s parametrami o ľavom a pravom využívanom pravidle, pozíciu lopty, pozíciu pravých a ľavých robotov, skóre, čas a kto práve má loptu pod kontrolou. Nakoniec trieda obsahuje konštruktor LogHolder() v ktorom sa vytvára inštancia triedy PositionsHolder. Ďalšie detaily o využití a nahrávaní StrategyAdaptation sú opísané v kapitole 3.3.
3.4 Uživateľské rozhranie simulátoru (GUI)
Uživateľské prostredie simulátoru bolo upravené a navrhnuté za cieľom priblížiť sa tématike futbalu robotov. Modely robotov, textúry, fonty a modely prostredia boli prevzaté z Unity Asset Store. UI prvky ako buttony, panely a iné UI prvky boli vytvorené vlastnoručne. Prostredie tohto herného simulároru a zmeny vykonané v nom budú bližšie popísané v nasledujúcich kapitolách.
3.4.1 Staré prostredie simulátoru
Táto kapitola sa zaoberá zmenami vykonanými v prostredí herného simulátoru. Popisuje zmeny týkajúce sa vzhľadu starého simulátoru a prípadné vylepšenia. Funkcionalita simulatóru, čo sa týka správania robotov ostala nezmenená.
Obr. 8: Ukážka predošlého prostredia simulátoru
Na obrázku 8 môžeme vidieť ukážku predošlého simulátoru. Hráči sú oddelení farebne a to červenou a modrou farbou. Na hernej ploche sa nachádza tlačidlo reset, počítadlo gólov, počítadlo hier, odpočet času a informácia o tom, ktorý z hráčov má pod kontrolou loptu. Po spustení predošlého simulátoru sa nám objavila rovno herná plocha, ktorú môžeme vidieť na obrázku 6, bez rozsiahlejšieho menu.
3.4.2 Zmeny simulátoru
Oproti predošlému simulátoru boli pridané dalšie scény a vylepšenia:
• Hlavné menu s výberom súborov .strg, ktoré deĄnujú správanie robotov v rôznych situ- áciach.
• Menu umožnujúce použivateľovi nahrať vlastné .dll súbory so stratégiami a taktikami.
• Vylepšenia hernej plochy (panel rozhodcu, skóre panel, panel nástrojov, esc menu, 3D modely...)
3.4.3 Hlavné menu nového prostredia
Po spustení simulárou sa objaví hlavné menu (viď obrázok 9), v ktorom má uživatel možnosť nahrať dva.strg súbory obsahujúce pravidlá, podľa ktorých sa roboti majú správať v určitých situáciach. Nahrávajú sa dva.strg súbory, jeden pre pravý a druhý pre ľavý tím. Na nahranie týchto súborov sú použité dve tlačidlá BROWSE. Po kliknutí na tlačidlo sa nám objaví nové okno, v ktorom zvolíme požadovaný.strgsúbor, ktorý chceme pripojiť do simulátoru. Ak by bol nahratý iný typ súboru, malo by to negatívny dopad na funkcionalitu celého simulátoru. Práve kvôli tomuto sú oba vstupy ošetrené proti nahratiu iného typu súboru ako je .strg. V menu sa nachádzajú dva Input Fieldy, ktoré zobrazujú cestu k pripojeným.strg súborom. Ďaľej sa v hlavnom menu nachádzajú tlačidlá NEXT a QUIT. NEXT tlačidlo nás presunie do nasledujúcej scény pre nahravanie DLL súborov so stratégiami a taktikami. Tlačidlo QUIT simulátor ukončí.
Obr. 9: Ukážka nového hlavného menu
Funkcionalitu hlavného menu, ako napríklad spomínané ošetrenie vstupov, zabezpečuje pri- pojený script MenuUIController, ktorý je pripojený na hlavný panel menu (viz. výpis 2).
public void Browse1(){
string path = EditorUtility.OpenFilePanel("Select strategy", "strategie", "");
tactic1.text = path;
if(tactic1.text.Length != 0){
if(!tactic1.text.EndsWith(".strg")){
EditorUtility.DisplayDialog("Warning", "File has to end with .strg!", "Ok")
;
start.enabled = false;
} else{
start.enabled = true;
} } else{
EditorUtility.DisplayDialog("Warning", "Please, choose a file.", "Ok");
start.enabled = false;
} }
Výpis 2: Úryvok kódu z MenuUIController scriptu
3.4.4 Nové menu umožnujúce uživateľovi nahrať vlastné DLL súbory
Po stlačení tlačidla NEXT v hlavnom menu sa nám objaví menu, ktoré umožnuje použivateľovi nahrať vlastné DLL súbory so stratégiami a taktikami (viz. obrázok 9). Tieto DLL súbory popisujú funkcionalitu robotov a ich správanie na ihrisku.
Obr. 10: Náhľad menu umožnujúce nahratie DLL súborov s taktikami a stratégiami V tomto menu sa nachádzajú:
1. Dva input Ąeldy, ktoré zobrazujú cestu k zvoleným.dll súborom pre pravý a ľavý tím 2. Dve tlačidlá BROWSE, ktoré umožnujú vybrať požadovaný .dll súbor, ktorý chceme do
simulátoru nahrať pre pravý alebo ľavý tím
3. Dva indikátory, ktoré po skene.dll súborov zobrazujú informáciu o tom či je zvolený.dll súbor v poriadku a či spĺňa požadovanú kostru
4. Tlačidlo SCAN, ktoré slúži na kontrolu nami nahratých.dll súborov
5. Tlačidlo ERROR LOG, ktoré zobrazuje chyby, ktoré nastali pri kontrole.dll súborov 6. Tlačidlo BACK, ktoré nás vráti do hlavného menu
Takisto ako aj v hlavnom menu sú tieto vstupy ošetrené, aby dovolili nahrať len súbory s koncovkou.dll, inak by došlo k pádu celého simulátoru. Tieto súbory sú ďalej skenované pomocou tlačidla SCAN, aby spľňali požadovanú kostru a funkcionalitu stratégii a taktik. O správnosti týchto .dll súborov nás po kontrole informujú dva indikátory správnosti, ktoré sa nachádzajú napravo od input Ąeldov.
Indikátory nadobúdajú dva stavy:
1. Všetko vporiadku Ű súbor spĺňa požadovanú kostru a funkcionalitu, viď obrázok 11
Obr. 11: Indikátor „Všetko v poriadkuŞ
2. Chyba Ű súbor nespĺňa požadovanú kostru a funkcionalitu, viď obrázok 12
Obr. 12: Indikátor „ChybaŞ
V situácii kde nastala chyba v určitom súbore, uživateľ má možnosť informovať sa o chybe pomocou tlačidla ERROR LOG, ktoré mu zobrazí nové okno, ktoré obsahuje podrobnejšie in- formácie o chybe. Vďaka tomuto oknu má uživateľ možnosť chybu rýchlejšie odhaliť a opraviť viď obrázok 13.
Obr. 13: Error Log
Ak oba súbory spĺňajú požadovanú štruktúru, tlačidlo SCAN sa zmení na tlačidlo START GAME pomocou ktorého sa presunieme do už očakávanej hernej plochy simulátoru. Celú fun- kcionalitu tohoto menu zabezpečuje pripojený skript DLLMenuKontroller. Funkcionalita a pod- robnejšie informácie o kontrole pripojených.dll súborov sú popísané v kapitole 2.4.
Ďalšia funkcionalita tohoto menu spočíva v tom, že ak.dllsúbor obsahuje StrategyAdaptation triedu, po kontrole.dll sa objaví okno, v ktorom má uživateľ možnosť zvoliť, či chce funkcionalitu tejto triedy využívať. StrategyAdaptation takisto musí spĺnať určitú štruktúru, aby bola v simu- látore funkčná. Ak požadovanú štruktúru nespĺňa, informácie o chybe a požadovanej štruktúre tejto triedy sú úživateľovi poskytnuté v error logu.
Obr. 14: Strategy adaptation menu
Na obrázku 14 môžeme vidieť okno, v ktorom má možnosť uživateľ, ktorý nahral .dll pre ľavý tím, zapnúť StrategyAdaptation. Dll súbor pravého tímu túto možnosť nemá, pretože sa v jeho .dll súbore nenachádza StrategyAdaptation trieda. Po stlačení tlačidla APPLY sú informácie o používateľovej voľbe uložené a odosielané do triedy StaticVariable a následne po spustení hry odtiaľto odosielané do hlavnej triedy simulátoru MainControl, kde sa počas hry táto použivateľova voľba skúma a podľa nej sa z DLL súboru volá funkcia AdaptStrategy alebo nie, viď výpis 3.
//left
if(StaticVariable.leftAdaptation == true){
List<objects> newRules = (List<objects>)leftAdaptStrategyMethod.Invoke(
leftStrategyAdaptation, new object[] { logHolder, leftInstance });
if(newRules.Count > 0){
MethodLeftAdaptStrategy.Invoke(leftInstance, new object[] { newRules });
} } //right
if(StaticVariable.rightAdaptation == true){
List<objects> newRules = (List<objects>)rightAdaptStrategyMethod.Invoke(
rightStrategyAdaptation, new object[] { logHolder, rightInstance });
if(newRules.Count > 0){
MethodRightAdaptStrategy.Invoke(rightInstance, new object[] { newRules });
} }
Výpis 3: Kód ktorý počas hry skúma či uživateľ chce využívať triedu StrategyAdaptation
Metódy AdaptStrategy sú následne volané vo funkcíi Tick, ktorá sa volá každých 20ms počas hry. Vo výpise 3 môžme vidieť toto volanie funkcie AdaptStrategy z uživateľovho .dll súboru vo funkcii Tick. Najskôr sa overuje pomocou vetvenia, či si uživatel praje využívať StrategyAdaptation triedu, tak ako to možme vidieť vyššie vo výpise 3. Následne sa do listu typu object s názvom newRules načítajú objekty, ktoré vracia funkcia AdaptStrategy vo- laná z uživateľovho.dll súboru z triedy StrategyAdaptation. Tejto funkcii sú predavané dva parametre: logHolder a leftInstance/rightInstance. Tieto parametre predstavujú inštan- cie tried LogHolder a Strategy, tak ako to vyžaduje povinna štruktúra funkcie AdaptStrategy opísaná na obrázku 7. Ďalej sa pomocou vetvenia overuje počet newRules, čo predstavuje počet nových pravidiel. Ak počet nových pravidiel väčší ako 0 volá sa metóda AdaptStrategy z triedy PlayerStrategy a ako parameter sú jej predávané nové pravidlá v podobe vyššie deklarovaného listu newRules, aby sa tieto nové pravidlá adaptovali do strategii. Čo je StrategyAdaptation a jeho podrobnejším opisom sa zaoberám v kapitole 3.5.
3.4.5 Vylepšenia hernej plochy simulátoru
Herná plocha bola vylepšená za účelom skrášlenia simulátoru, tak aby zapadala to tématiky simulátoru robotov a umožnovala používateľovi lepšiu orientáciu a ovládanie v simulátore (viz.
obrázok 15). Boli použité viaceré assety získané z Unity asset store, ktoré budú opísané nižšie.
Všetky použité assety sú k dispoícii zdarma.
Obr. 15: Náhľad hernej plochy simulátoru
3.4.6 Rozloženie a funkcionalita hernej plochy
Herná plocha simulátoru sa skladá z niekoľkých častí, viz obrázok 16:
Obr. 16: Časti hernej plochy
1. Ľavý panel predstavuje panel nástrojov obsahujúci indikátor rýchlosti hry SPEED s mož- nosťou zrýchlenia alebo spomalenia hry, tlačidlo na pozastavenie hry alebo odpauzovania a daľej dve tlačidlá RESTART a RESET. Tlačidlo RESTART reštartuje aktuálne pre- biehaujúcu hru a tlačidlo RESET resetuje celý simulátor. Nakoniec tento panel obsahuje vrchný panel TOTAL SCORE, ktorý obsahuje informáciu o celkovom skóre hry.
2. Vrchný panel obsahuje informácie práve prebiehajúcej hry ako: skóre, čas, poradové číslo prebiehajúcej hry a informáciu o kontrole lopty.
3. Pravý panel slúži ako panel rozhodcu obsahujúci tlačidlá na kontrolu ľavých a pravých robotov. Tlačidlá predstavujú rozvrhnutie tímu podľa určitej situácie, ktorá môže počas hry nastať, napríklad ako: penalta, kop brankárom, pokutový kop atď.
4. Ďalej herná plocha obsahuje už hernú arénu s robotmi a okolité prostredie arény.
Celá funkcionalita hernej plochy je deĄnovaná v hlavnom skripte MainControl. Úryvok kódu z MainControl skriptu predstavujúci funkcie na ovládanie rýchlosti hry a pauzu, viď výpis 4:
public void IncreaseGameSpeed() { GameSpeed++;
}
public void DecreaseGameSpeed(){
if (GameSpeed > 1) {
GameSpeed--;
} else { } }
public void PauseGame() {
pause.gameObject.SetActive(false);
play.gameObject.SetActive(true);
GameSpeed = 0;
}
Výpis 4: Pauza a zmena rýchlosti hry
3.4.7 Escape menu
Ďalšiu funkcionalitu hernej plochy simulátoru predstavuje takzvané escape menu, ktoré umož- nuje uživateľovi návrat do hlavného menu alebo simulátor ukončiť (viz. obrázok 17). Ak dôjde počas hry ku stlačeniu klávesy esc dôjde k zastaveniu hry a použivateľovi sa objaví menu v ktorom má možnosť z hry odísť späť do menu, daľej pokračovať v hre alebo simulátor ukončiť.
Obr. 17: Ukážka esc menu 3.4.8 Použité 3D modely robotov a prostredia
Ako bolo spomenuté vyššie, modely robotov a prostredia boli prevzaté z Unity asset store a sú k dispozicíi zdarma. Jednotlivé modely som vyberal tak, aby nepodliehali autorským právam a bolo ich možné využiť v mojom projekte. Takisto som vyberal tak, aby zapadali ku zvolenej tématike a postredia simulátoru. Taktiež som musel pri vyberaní dohliadnuť na kompatibilitu Unity verzie s vybranými modelmi.
Obr. 18: Model robota „Wall-EŞ
Obr. 19: Model robota „Threshing ClawerŞ
Na obrázkoch 18 a 19 môžme vidieť zvolené modely robotov a ich box collider. Rozmery box collideru museli zostať rovnaké z predchádzajúceho modelu z dôvodu medzinárodných pravidiel pre simulátor robotov, kde sú určené presné rozmery collideru4.
Pre prostredie simulátoru bol použitý balíček 3D modelov získaný z Unity asset store ob- sahujúci niekoľko 3D betónových modelov roznych veľkostí a tvarov (viz. obrázok 20). Tento balíček bol použitý práve preto, pretože skvele dopĺňa prostredie pre simulátor. Modely boli
4http://firaworldcup.org/visitorpages/Show.aspx?ItemID=805,0
jednoducho implementované do projektu a rozmiestnené po okolí tak aby dotvárali prostredie simulátoru.
Obr. 20: Náhľad 3D modelov prostredia
3.5 Adaptácia stratégií
Táto kapitola sa zaoberá funkcionalitou adaptácie stratégii a experimentami s touto adaptáciou.
3.5.1 StrategyAdaptation
Futbal robotov je dynamické a rýchlo meniace sa prostredie. Za cieľom rýchlej odpovede, adaptá- cie, na protivníkovu stratégiu musí byť systém Ćexibilný a vedieť sa na túto situáciu adaptovať[6].
Z toho vyplíva, že StrategyAdaptation je teda v tomto simulátore funkcionalita, ktorá umožňuje adaptáciu stratégie na danú situáciu, a tým odpovedať na protivníkovu stratégiu.
Tak ako to bolo s výberom pravidla v kapitole 3.1.1, takisto aj tu si uživateľ môže implementovať svoju adaptáciu stratégií v.dll, ktoré potom nahrá do simulátoru (podrobnejší opis toho ako to má vyzerať je na kapitole 3.2.2), avšak implementácia StrategyAdaptation nie je povinná, je to na uživateľovi či ju chce využívať alebo nie.
V našej architektúre, adaptácia stratégií pozostáva s týchto krokov:
1. Extrahovanie informácie o priebehu hry z logu, ktorý obsahuje informácie o dohranej hre.
2. Detekcia relevantných herných situácií pre adaptáciu stratégií.
3. Analýza pravidiel, ktoré predchádzali tejto danej extrahovanej situácie.
4. Vytvorenie agregovaných proti-pravidiel pre túto situáciu.
5. Zahrnutie týchto nových pravidiel do originálnej stratégie.
Takže základná myšlienka adaptácie stratégii je odhaliť slabé miesta v stratégii, založenej na dátach získaných po hre z daného log súboru, a následne tým adaptovať (vylepšit) našu stratégiu aby sa v budúcnosti tejto situácii predchádzalo. Ako to vyplýva z prvého kroku adap- tácie stratégií, po každej hre sa vytvorí súbor (log), ktorý obsahuje informácie o priebehu hry.
Každých 20 ms, počas behu hry, sa do tohto logu zapisujú informácie o priebehu hry. Zapisujú sa predovšetkým pozície robotov a lopty, ktoré pravidlo práve využívali roboti pravého tímu a ľavého tímu. Takisto sa zapisuje do logu skóre a herný čas. Tým padom, že sa loguje každých 20 ms, výsledný log obsahuje 6000 záznamov pri 2 min herného času. Vďaka tomuto logu sme teda schopný vyextrahovať informáciu o určitej hernej situácii (napríklad inkasovanie gólu). Ako bolo vyššie spomínané, do logu je zapisovaná informácia o hre každých 20 ms, ale počas týchto 20 ms nemajú roboti priveľa času pohnúť sa, takže sa musí extrahovať väčší časový interval, ktorý predchádzal danej situácií a ten sa ďalej analyzovať. Pri počte 6000 záznamoch a trvaní hry 2 min vyplýva, že dostatočný počet záznamov je 150 čo odpovedá 3 sekundám herného času.
Tento počet by mal byť dostačujúci na reagovanie na danú situáciu na hracom poli. Informácia extrahovaná z logu je použitá ako spomínané proti-pravidlo. 150 extrahovaných záznamov, re- prezentujúcich hernú situáciu (slabinu stratégie), je použitých na vytvorenie pravidla, ktoré by malo tejto situácii v budúcnosti predchádzať. Záznamy logu sú teda rozdelené po 50 záznamoch (1 sekunda hry) a následne agregované do jedného pravidla, takže vo výsledku sa jedná o 3 nové pravidlá pre jednu hernú situáciu. Agregácia sa vykonáva tak, že týchto 50 záznamov sa spriemerujú gridové súradnice robotov a lopty a výsledné súradnice sa uložia do pravidla.
Vo Ąnálnej fáze adaptácie sa modiĄkujú súradnice v danom pravidle, kam sa majú roboti pre- sunúť a tým zabrániť tejto situácií, presnejšie prepíšu sa súradnice dvoch robotov aby sa pohli smerom k lopte. Týmto spôsobom sme schopní vytvoriť proti-pravidlo, ktoré opraví danú sla- binu v našej stratégií. Tento spôsob nemusíme aplikovať aby sme predišli zlej hernej situácií, keď inkasujeme gól ale takisto to môžeme aplikovať napríklad ak náš tím bol pred súperovou bránkou ale nepodarilo sa mu dať gól, a tým sa pokúsiť túto chybu v buducnosti napraviť.
3.5.2 Experimenty s adaptáciou stratégii
Experiment bol vykonaný tak, že boli nadeĄnované dve stratégie. Prvá stratégia, ktorú využíval ľavý tím, môžme ju vidieť v prílohe A, mala naschvál nadeĄnované slabiny (ľavá obrana a stredná obrana je zameraná hlavne na útok). Pravá stratégia mala nadeĄnované základné defenzívne a ofenzívne pravidlá. Medzi týmito dvoma tímami bolo následne odohratých 10 zápasov, kde výsledok bol 5:9 v prospech pravého tímu. Ľavému tímu sa podarilo vyhrať 3 krát, prehral 5 krát a 2 krát remízoval, výsledky môžme vidieť v tabuľke 3. Slabina dobrej obrany bola v hrách vidno a pravý tím dával najviac gólov práve ľavou stranou hernej plochy.
Game# Left Score Right Score Result
1 0 1 Loss
2 1 0 Win
3 0 2 Loss
4 0 2 Loss
5 1 0 Win
6 1 1 Draw
7 1 0 Win
8 0 1 Loss
9 1 1 Draw
10 0 1 Loss
SUM 5 9
Tabuľka 3: Výsledky odohratých zápasov
Adaptácia pomocou log súboru
Pomocou vyššie spomínaného postupu boli vyselektované záporné situácie a z nich boli vytvo- rené nove pravidlá, ktoré by mali zabrániť tejto situácií v budúcnosti. Ako záporné situácie sme brali inkasovanie gólu a tým padom vznikli pre každú túto situáciu 3 nové pravidlá, vo výsledku 27 nových odlišných pravidiel, ktoré boli nasledovne pridané do už existujúcej stratégie. Ná- sledne boli znovu odohraté zápasy, ktorých výsledky môžme vidieť v tabuľke 4 nižšie. Vylepšená stratégia skórovala rovnaký počet gólov ako pravý tým s dvoma výhrami, jednou prehrou a 7 remízami. Z toho vyplýva, že adaptovaná nová stratégia sa môže teraz rovnať pravému tímu a to vďaka adaptovaným pravidlám, ktoré posilnili obranu.
Game# Left Score Right Score Result
1 0 0 Draw
2 0 0 Draw
3 0 2 Loss
4 0 0 Draw
5 0 0 Draw
6 0 0 Draw
7 1 0 Win
8 1 0 Win
9 1 1 Draw
10 1 1 Draws
SUM 4 4
Tabuľka 4: Adaptovaná defenzíva vs. predošlá pravá stratégia
Postupom opísaným vyššie v kapitole 3.5.1, bola stratégia ďalej adaptovaná a vylepšovaná, za cieľom zlepšiť jej ofenzívu. Behom hry bolo zaznamenaných veľa nepodarených pokusov o gól, takže sa očakávalo veľa nových pravidiel, ktoré by túto situáciu mali v budúcnosti vylepšiť. Bolo vytvorených 138 nových unikátnych pravidiel a pretože sa pre každú každú detekovanú situáciu vytvárajú 3 nové pravidlá (3 sekundy herného času, ktoré predchádzali tejto situácií), množstvo detekovaných situácií sa pohybovalo okolo 46. Toto číslo bolo pravdepodobne vyššie ale kvôli duplicite alebo veľkej podobnosti sa mnoho pravidiel z adaptácie vyhodilo. Tieto nové pravidlá boli následne pridané do stratégie ľavého tímu a znovu boli odohraté zápasy, ktorých výsledky môžme vidieť v tabuľke 5.
Game# Left Score Right Score Result
1 1 0 Win
2 2 0 Win
3 1 1 Draw
4 3 1 Win
5 0 0 Draw
6 2 0 Win
7 1 0 Win
8 1 1 Draw
9 0 1 Loss
10 2 0 Win
SUM 13 4
Tabuľka 5: Adaptovaná defenzíva a ofenzíva vs. predošlá pravá stratégia
Výsledok nám ukazuje, že ĺavý tím bol schopný vyhrať nad pravým v 6 prípadoch, 3 krát remízoval a prehral len jeden krát. Najviac viditeľný rozdiel na adaptácií vidno na počte gólov.
Real-time adaptácia
Ako bolo spomínane vyššie v predošlom API, ktoré riešilo taktiky a stratégie a je teraz odde- lené od simulátoru, už bola implementácia StrategyAdaptation, na ktorej boli vykonávané tieto experimenty. Táto adaptácia má hlavnú metódu, ktorá sa využíva práve na adaptáciu stratégií počas hry, kde sa volá každých 20 ms. V tejto metóde sa vytvára veľké množstvo adaptovaných pravidiel a následne sa overujú voči už vytvoreným pravidlám, na základe ich Z-order súrad- niciam, aby sa prešlo duplicite. Real-time experimenty boli vykonané nad 5 setmi hier. Každý tento set obsahoval 10 zápasov medzi originálnou stratégiu ľavého tímu A a základnou straté- giou pravého tímu. Behom hry ľavý tím bol schopný adaptovať svoju stratégiu, takže detekoval behom hry negatívne situácie a bol schopný vytvoriť nové pravidlá a zahrnúť ich do už exis- tujúcej stratégie. Adaptované stratégie ostali uložené, takže boli schopné sa vylepšovať behom každej iterácie. Výsledky týchto hier sú zaznamenané v tabuľkách v obrázku 21. Výsledky nám
ukazujú, že adaptovaný ľavý tím je rovnocenným súperom pravého tímu (3 výhry a 2 prehry) a je takisto schopný dať dostatočný počet gólov. Tabuľky takisto obsahujú počet automaticky adaptovaných pravidiel, ktoré boli dodané do originálnej stratégie.
Obr. 21: Výsledky zápasov real-time adaptácie
Zápasy na obrázku sú zoradené z ľava do prava podľa postupnosti odohrania zápasov. Podľa týchto výsledkov môžeme vidieť, že defenzíva je adaptovaná len v prípade ak inkasujeme gól, takže tým sa stratégia učí protivníkovu stratégiu a vyvíja si tým pravdilá aby tejto taktike za- bránila. Najväčší počet nových pravidiel sa práve ukladá v prvej hre, čo je logické pretože na začiatku je malý súbor pravidiel a nové adaptované pravidlá nie su až v takom počte vyhadzo- vané kvôli duplicite, ale ako hry pokračujú väčší a väčší počet pravidiel je vyhadzovaných kvôli duplicite.
3.5.3 Validácia a vizualizácia
Predošlé výsledky experimentov môžeme overiť pomocou sekvenčnej extrakcie a porovnania, ktoré je takisto veľmi užitočné pre vizualizáciu. Sekvencie sú v našom prípade extrahované z herných logov, ktoré obsahujú dáta priradené k pravidlám danej stratégie.
Každá sekvencia je označená sekvenčným číslom a číslom, ktoré určuje ktorý tím mal pod kontrolou loptu (0 - nikto, 1 - ľavý tím, 2 - pravý tím). Každá sekvencia obsahuje zoznam pravi- diel, vybratých pre ľavý tím každý herný tik (20 ms) až kým sa nezmenila kontrola lopty (ľavý tím strati loptu alebo mu ju protihráč vezme). Tieto sekvencie sú porovnávané použitím metódy porovnania sekvencí - LCS (longest common substring), LCSS (longest common subsequence)[8]
a T-WLCS (time-wraped longest common subsequence)[9]. Výsledky sekvenčného porovnávania môžu byť vizualizované zhlukovaním podobných sekvencií.
Vizualizáciu pomocou LCSS metódy originálnej základnej stratégie pre ľavý tím a adaptovanej defenzívnej stratégie pomocou logu môžeme vidieť na obrázkoch 22 a 23. Zhluky podobných sekvencií často reprezentujú herné situácie deĄnované vzhľadom ku originálnej stratégii, takže originálna stratégia by mala obsahovať základné herné situácie a adaptovaná stratégia by mala takisto obsahovať nové zhluky skladajúce sa z novo pridaných pravidiel. V najviac prípadoch sú stratégie vytvárané manuálne s ohľadom na špeciĄcké herné situácie. Napríklad prvých X počet pravidiel, reprezentujúcich ľavé defenzívne krídlo, dalších Y počet pravidiel, reprezentujú- cich pravé ofenzívne krídlo atď. Tým pádom vyššie spomínané metódy porovnávania sekvencií a vizualizácia môžu byť takisto použité na validáciu stratégií a vizualizáciu priebehu futbalu robotov vo vzťahu ku adaptácii stratégií.
Obr. 22: Základná stratégia pre ľavý tím - LCSS
Obr. 23: Adaptovaná stratégia pre ľavý tím - LCSS
Pri bližšom preskúmaní vyextrahovaných sekvencií z odohratých zápasov, Set 1 v prvej tabuľke na obrázku 21, môžme vidieť koreláciu medzi zhlukmi a pravidlami. Zhluky podobných sekvencií pre vybraté iterácie hry preSet 1 sú znázornené v obrázkoch v prílohe B .
Každý uzol reprezentuje sekvenciu vybratých pravidiel. Každá táto sekvencia je označená sekvenčným číslom a číslom, ktoré vyjadruje kto mal pod kontrolou loptu. Tým pádom každé sekvenčné číslo môže byť namapované do postupnosti stratégií, ktoré boli vykonané počas určitej hernej situácie. Na obrázku 24 môžme vidieť zvolený zhluk sekvencii, 10-tej iterácie porovna- nia sekvencií a ich reprezentácia je zaznamenaná v tabuľke 6. Tabuľka 6 vyjadruje zobrazenie postupnosti pravidiel vo zvolených uzloch.
Obr. 24: Set 1 - 10. iterácia porovnania sekvencií pomocou LCSS
Sequence # Rules
209 - 2 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, 8,8,8,8,8,8,8,8,8,8 211 - 2 8,8,8,8
212 - 1 8,8
213 - 2 8,8,8,8,8,8,8,8 214 - 1 8
216 - 1 8,8,8,8,8
218 - 1 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, 8,8,8,8,8 220 - 1 8,8,8,8,8,8,8,8,34,34,34,34,34,8,8,8,8,8,
8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8, 8,8,8,8,8,8,8,8,8 223 - 2 8,8,8,8,8,8
226 - 2 8,8,8
Tabuľka 6: Set 1, Reprezentácia postupnosti pravidiel 10. iterácie pomocou LCSS
3.6 Detailnejšie podrobnosti kontroly a nahrávania dll súborov
Problematiku dynamického pripájania .dll súborov do simulátoru, tak aby fungovali za behu simulátoru, som sa rozhodol vyriešit pomocou funkcionality assembly a reĆection jazyka c#.
Assembly je knižnica, ktorá sa jednoducho implementuje do projektu a pomocou ktorej môžme nahrávať .dll súbor dynamicky za behu aplikácie, kontrolovať čo sa v jeho vnútri nachádza, tvoriť inštancie tried nachadzajúcich sa vovnútri týchto.dll súborov, volanie funkcíi atď. Práve kvôli tomuto sa mi použitie týchto knižníc zdalo ako najlepšie riešenie tohto problému.
3.6.1 Kontrola dll súborov
Kontrola.dll súborov sa odohráva v menu pre načítavanie.dll súborov opísaného na strane 25.
Po tom ako uživateľ vyberie daný.dll súbor pomocou tlačidla SCAN ho simulátor skontroluje či spĺňa požadovanú kostru opísanú v kapitole 2.2, tak aby bolo možné tento.dll súbor pripojiť do simulátoru a simulátor správne pracoval.
Pre kontrolu dynamicky načítavaných .dll súborov slúži skript DLLMenuController.cs a presnejšie funkcia ScanDLL pripojená na tlačidlo SCAN. V skripte je využitá knižnica jazyka C# System.Reflection, vďaka ktorej je možné dynamicky načítať a kontrolovať .dll súbory.
Úryvok kódu ktorý vo funkcii ScanDLL kontroluje.dll súbor nahratý pre ľavý tím, viď výpis 5:
leftDLLassembly = Assembly.LoadFile(leftDLL.text);
Type[] leftTypes = leftDLLassembly.GetTypes();
foreach (Type type in leftTypes) {
if (!type.IsPublic) {
continue;
}
MemberInfo[] members = type.GetMembers(BindingFlags.Public | BindingFlags.Instance
| BindingFlags.InvokeMethod);
foreach (MemberInfo member in members) {
if (type.Name == "PlayerStrategy") { leftPlayerStrategy = true;
ConstructorInfo constructorInfoObj = type.GetConstructor(new Type[] { typeof(GameSetting), typeof(String), typeof(bool) });
if (constructorInfoObj != null) {
leftConstructorOK = true;
}
if (member.Name == "TickStrategy") {
leftmethodIsThere = true;
}
if (leftmethodIsThere == true) {
MethodInfo Mymethodinfo = type.GetMethod("TickStrategy");
ParameterInfo[] pars = Mymethodinfo.GetParameters();
foreach (ParameterInfo p in pars) {
if (p.ParameterType.Name == "StrategyStorage") {
leftParameters = true;
} } } } } }
Výpis 5: Kontrola DLL súborov
Vyššie uvedený úryvok kódu z funkcie ScanDLL overuje či sa v danom .dll súbore nachá- dza požadovaná trieda PlayerStrategy a či sa vo vnútri tejto triedy nachádza konštruktor s požadovanými parametrami a požadovaná metóda TickStrategy, ktorá vyžaduje parameter StrategyStorage. Podobne ako vyššie sa daľej vo funkcii kontroluje celá požadovaná kostra .dll súboru opísaná na strane 18-19.
Pri tom ako sa kontroluje súbor sa nastavujú boolean premenné podľa ktorých sa na konci súbor vyhodnocuje ako zlý alebo v poriadku a podľa ktorých sa v Error Logu, opísanom na strane 25, vypíše informácia o tom kde má uživateľ chybu a ako ju má odstrániť. Ak všetko prebehlo v poriadku a všetky boolean parametre sú nastavené na hodnotu true, je .dll súbor označený za v poriadku a uživateľ môže spustiť hru. Konečné overovanie.dll súboru:
if (leftPlayerStrategy == true && leftmethodIsThere == true && leftParameters == true
&& leftConstructorOK == true && leftRuleNumber == true && leftRuleNumberReturnType
== true) {
leftDllOK = true;
} else
