UNREAL TOURNAMENT 3 GOAL ENVIRONMENT Michiel Hegemans Peter Evers
#1320386 #4013964
VOORWOORD In dit document wordt uitgebreid verslag gedaan van het ontwerpproces van ons bachelor eindproject. In het eerste hoofdstuk wordt de architectuur van GameBots, Pogamut en de GOAL environment behandeld om inzicht in het project te geven. Er wordt eerst een schets gemaakt van het ontwerp, er wordt ook behandeld waarom wij bepaalde keuzes hebben gemaakt en tegen welke problemen wij zijn aangelopen.
2
INHOUDSOPGAVE
Voorwoord ............................................................................................................................................................... 2 Inhoudsopgave ......................................................................................................................................................... 3 Samenvatting ........................................................................................................................................................... 5 1.
Inleiding ........................................................................................................................................................... 6
2.
Oriëntatieplan .................................................................................................................................................. 7 2.1 2.1.1
Wapens in UT2004 en UT3 .................................................................................................................. 7
2.1.2
Items in UT2004 en UT3 ...................................................................................................................... 8
2.1.3
Speciale wapens in UT3 ....................................................................................................................... 9
2.1.4
Navigatie ........................................................................................................................................... 10
2.1.5
Overige verschillende tussen UT2004 en UT3 .................................................................................... 10
2.2
Bestaande practicumsoftware ............................................................................................................... 11
2.3
UT2004 Visualizer .................................................................................................................................. 11
2.4
Introductie tot GOAL ............................................................................................................................. 12
2.5
Unit tests in GOAL ................................................................................................................................. 12
2.6
De opdracht ........................................................................................................................................... 13
2.6.1
De gewenste situatie van de UT3 omgeving ...................................................................................... 13
2.6.2
De gewenste situatie van het test framework ................................................................................... 15
2.7 3.
Unreal Tournament ................................................................................................................................. 7
Kwaliteitswaarborging ........................................................................................................................... 15
Ontwerp......................................................................................................................................................... 16 3.1
Lagenstructuur GOAL UT3/UT2004 Environment ................................................................................... 17
3.2
GameBots .............................................................................................................................................. 17
3.2.1 3.3
Ontwerp GameBots ........................................................................................................................... 18 Pogamut ................................................................................................................................................ 19
3.3.1
Architectuur Pogamut ....................................................................................................................... 19
3.3.2
Sensor modules ................................................................................................................................. 20
3.3.3
Ontwerp PogamutUT3 ....................................................................................................................... 21
3.4 3.4.1
UT3 GOAL Environment ......................................................................................................................... 22 Deployable weapons ......................................................................................................................... 22
3.5
Visualizer ............................................................................................................................................... 23
3.6
Test framework ..................................................................................................................................... 23 3
4.
5.
6.
Aanpak en tijdsplanning ................................................................................................................................. 24 4.1
Resources .............................................................................................................................................. 24
4.2
Tijdsplanning en taakverdeling .............................................................................................................. 25
4.3
Scrum log............................................................................................................................................... 26
4.3.1
SCRUM 1 ........................................................................................................................................... 26
4.3.2
SCRUM 2 ........................................................................................................................................... 27
4.3.3
SCRUM 3 ........................................................................................................................................... 27
4.3.4
SCRUM 4 ........................................................................................................................................... 28
4.3.5
SCRUM 5 ........................................................................................................................................... 28
4.3.6
SCRUM 6 ........................................................................................................................................... 29
Testen ............................................................................................................................................................ 30 5.1
Testen van GameBots ............................................................................................................................ 30
5.2
Testen van Pogamut .............................................................................................................................. 31
5.3
GOAL Environment ................................................................................................................................ 32
5.4
Map ....................................................................................................................................................... 32
Resultaat ........................................................................................................................................................ 34 6.1
GameBotsUT3 ....................................................................................................................................... 34
6.2
Pogamut ................................................................................................................................................ 35
6.3
UT3 GOAL Environment en de visualizer ................................................................................................ 36
6.3.1
7.
Won't fix problemen ......................................................................................................................... 36
6.4
Aanbevelingen ....................................................................................................................................... 37
6.5
Software Improvement Group Feedback ............................................................................................... 37
6.5.1
Aanbevelingen tussentijdse evaluatie ................................................................................................ 37
6.5.2
Verbeteringen ................................................................................................................................... 38
6.5.3
Feedback uiteindelijke product ......................................................................................................... 38
Conclusie ....................................................................................................................................................... 38
Referenties ............................................................................................................................................................. 40 Appendix A - SIG ..................................................................................................................................................... 41
4
SAMENVATTING In dit verslag wordt beschreven hoe het Unreal Tournament 2004 platform voor GOAL is omgebouwd naar Unreal Tournament 3. Er is gekozen om Pogamut, GameBots en de GOAL environment voor UT2004 uit te breiden en geschikt te maken voor Unreal Tournament 3. Er zijn significante aanpassingen gemaakt aan het Pogamut platform en GameBots. Naast de ondersteuning voor UT3 is er ook gewerkt aan externe tools die de studenten kunnen gebruiken bij het programmeren van hun agents. De Visualizer is aangepast zodat deze kan werken met UT3 en UT2004. Naast dit alles is er ook een test framework ontwikkeld voor GOAL om agents mee te testen.
5
1. INLEIDING De opdracht is om een omgeving te bouwen voor de programmeertaal GOAL waardoor bots aangestuurd kunnen worden in Unreal Tournament 3 (UT3). GOAL is een agent programmeertaal die ontwikkeld is aan de TU Delft. Dit is een programmeertaal die faciliteiten bevat om het gedrag van een agent uit te drukken. Dit wordt veel gebruikt in het programmeren van kunstmatige intelligentie. Het vak Multi-Agent Systemen aan de TU Delft maakt nu al een aantal jaren gebruik van GOAL voor het programmeren van bots voor het spel Unreal Tournament 2004 (UT2004). GOAL maakt gebruik van UnrealEnvironment2004 om de bots aan te sturen, dit is een omgeving die ervoor zorgt dat de bots aan te sturen zijn vanuit GOAL (K. V. Hindriks, 2011). Omdat het spel UT2004 verouderd is wil de opdrachtgever overstappen op UT3. Dit zorgt naast een enorme grafische vooruitgang ook voor meer uitdagingen in het programmeren van de bots omdat er meer mogelijk is in UT3. Naast de omgeving voor UT3 richten wij ons ook op het bouwen van een test framework. Dit test framework moet het mogelijk maken om unit tests uit te voeren op het GOAL platform zodat studenten meer tools hebben om de bots te testen. De doelstelling van dit project is als volgt, de nieuwe omgeving moet makkelijk te gebruiken zijn en betrouwbaar. Dat betekent dat de omgeving een dermate abstractie moet bevatten dat hij met weinig detail in GOAL aan te sturen is, maar niet te abstract zodat er geen uitdaging voor de studenten overblijft. De studenten moeten er van uit kunnen gaan dat alle onderdelen die beschreven zijn in de handleiding ook daadwerkelijk functioneren en uitgebreid getest zijn. Tot slot moeten studenten een unit test framework kunnen gebruiken voor het testen van de bots. Dit project is uitgevoerd in opdracht van Koen Hindriks aan de TU Delft voor het vak Multi-Agent Systemen.
De opbouw van dit rapport is als volgt. Hoofdstuk 2 bevat het oriëntatieplan met een beschrijving van het huidige systeem en een MoSCoW model. Hoofdstuk 3 beschrijft de opbouw van het bestaande project in verschillende lagen en het design voor het nieuwe systeem. De aanpak voor het testen van ons systeem wordt behandeld in hoofdstuk 5 en in hoofdstuk 6 worden de resultaten behandeld en wordt er een aanbeveling gedaan voor de voortzetting van dit systeem. In hoofdstuk 7 wordt een conclusie gegeven en een reflectie op dit project.
6
2. ORIËNTATIEPLAN In dit hoofdstuk zal de situatie van het huidige project geschetst worden en wordt er een plan gemaakt voor de gewenste situatie. De projectopdracht is gespecificeerd in een MoSCoW model en er is ook een tijdsplanning opgenomen.
2.1
UNREAL TOURNAMENT
Unreal Tournament 2004 is een first-person shooter die ontwikkeld is door Epic Games. Het is het vervolg op het succesvolle spel Unreal Tournament uit 1999.
AFBEELDING 1 - UITGAVE VAN UT2004 EN UT3 OP DVD
De studenten krijgen in het project van Multi-Agent Systemen de opdracht om een team van bots te maken dat Capture The Flag speelt. Capture The Flag is een gamemode waarin er twee teams zijn en ook twee vlaggen. Het team dat de meeste punten scoort door de vlag van de tegenstander terug te brengen naar de eigen basis wint. UT3 is de opvolger van UT2004 en bevat een aantal uitbreidingen. Er zijn veel meer verschillende gamemodes en er zijn ook andere items en wapens. In de volgende paragrafen bespreken we de veranderingen van de wapens en items in het spel.
2.1.1 WAPENS IN UT2004 EN UT3 Het belangrijkste in een shooter game zijn, natuurlijk, de wapens. We hebben onderzocht of de wapens in Unreal Tournament 3 anders zijn dan die in Unreal Tournament 2004, en zo ja, op welke manier. Met deze informatie kon een plan worden gemaakt voor een andere implementatie van het schiet gedrag met het desbetreffende wapen. Het schietgedrag met een rocket launcher is bijvoorbeeld anders dan het schietgedrag van een sniper rifle. De 7
rocket launcher is het meest efficiënt als er richting de grond wordt geschoten en een sniper is het meest efficiënt als er op het hoofd wordt gemikt. Bijna alle wapens in UT2004 en UT3 hebben twee verschillende firing modes, deze komen overeen met de linker of rechter button op de muis. In de onderstaande tabel staan alle wapens in UT 2004 en hun equivalent in UT 3. Wapen Translocator Shield Gun Impact Hammer Assault Rifle Enforcer Shock Rifle Link Gun Bio Rifle Minigun Stinger Minigun Flak Cannon Rocket Launcher Sniper Rifle Lightning Gun Redeemer Ion Painter AVRiL Grenade Launcher Mine Layer Ball Launcher
Unreal Tournament 2004 X X
Unreal Tournament 3 X X
X X X X X X X X X X X X X X X
X X X X X X X X X X X X
TABEL 1- VERSCHILLEN TUSSEN DE WAPENS IN UT2004 EN UT3
De enige grote verschillen zijn de Assault Rifle, Enforcer, Shield Gun en de Impact Hammer. De rest van de wapens is nagenoeg hetzelfde. De Ball Launcher is een wapen dat in UT2004 gebruikt werd in de Bombing Run game mode, maar deze bestaat niet meer in UT3. De Lightning Gun en de Ion Painter komen niet meer voor in UT3.
2.1.2 ITEMS IN UT2004 EN UT3 In UT2004 is er een mogelijkheid om naast health en armor ook adrenaline te verzamelen. Als een speler 100 adrenaline had verzameld dan kon hij een van de volgende vier acties uitvoeren:
Berserk - Schiet sneller, of doe 33% meer damage Regenerate - De speler regenereert health Speed - De speler loopt sneller Invisibility - Maakt de speler onzichtbaar
Adrenaline zit niet meer in UT3 en is grotendeels vervangen met powerups die je kan vinden op de map. Een powerup is een speciaal item die je kan oppakken om een tijdelijke bonus te krijgen in het spel. In de onderstaande tabel zijn de verschillen tussen de items in UT2004 en UT3 te vinden.
8
Item Jump Boots Adrenaline Pills Berserk Damage Amplifier Invulnerability Invisibility Slow Field Health Vial Health Pack Big Keg O’ Health Super Shield Pack Shield Belt Shield Pack Armor Vest Thigh Pads Helmet
Unreal Tournament 2004
Unreal Tournament 3 X
X X X X X X X X X
X
X X X X
X X X
X X X
TABEL 2 - VERSCHILLEN TUSSEN DE ITEMS IN UT2004 EN UT3
Vooral op het gebied van armor is er redelijk wat veranderd ten opzichte van UT2004. In UT2004 kan de speler maar twee verschillende soorten armor oppakken, de Shield Pack en de Super Shield Pack die samen voor maximaal 150 armor kunnen zorgen. In UT3 kan de speler vier verschillende stukken armor oppakken die elk weer andere eigenschappen hebben. In afbeelding 3 zijn alle soorten armor te zien met de bijbehorende eigenschappen.
2.1.3 SPECIALE WAPENS IN UT3 In UT3 zijn de zogenaamde deployable weapons geintroduceerd. De bot kan dit wapen oppakken en pas weer kwijtraken als hij dit wapens ergens deployed of dood gaat. Dit wapen creëert een veld dat van invloed is op de spelers die hier door heen lopen. Een voorbeeld is het Slow Volume in afbeelding 2. Een Slow Volume zorgt er voor dat alle spelers en objecten die in het volume komen afgeremd worden. Dit kan heel handig zijn en zorgt voor een aantal tactische voordelen als ze op de juiste plek worden geplaatst. AFBEELDING 2 - SLOW VOLUME IN DE TESTMAP
9
AFBEELDING 3 - SOORTEN ARMOR IN UT3
2.1.4 NAVIGATIE Navigatie in de UT2004 en UT3 gebeurt allebei door middel van navigation points, of te wel navpoints. In elke map liggen punten op de grond die met elkaar verbonden zijn om paden te maken. Deze paden kan de bot volgen om een route te plannen. Elke navpoint heeft speciale flags die aangeven hoe de bot hier bij kan komen. Sommige navpoints zijn bijvoorbeeld alleen bereikbaar door te springen of door te duiken.
2.1.5 OVERIGE VERSCHILLENDE TUSSEN UT2004 EN UT3 In UT3 is het ook mogelijk om in grote maps gebruik te maken van een hoverboard. Dit is een soort skateboard waardoor de spelers sneller door de map kunnen bewegen. Zodra de bot wordt geraakt op een hoverboard valt hij er van af en duurt het even voordat de speler weer opstaat.
10
2.2
BESTAANDE PRACTICUMSOFTWARE
Voor het Multi-Agent Systemen practicum wordt gebruik gemaakt van de UT2004 Environment. Deze software is ontworpen om te werken met UT2004, GameBots2004 en het Pogamut platform. De environment dient als een vertaler tussen Pogamut en GOAL. De environment zet de data uit Pogamut om naar de Environment Interface Standard (EIS) (T.M. Behrens, J. Dix, K.V. Hindriks, 2009), zodat GOAL, en andere EIS platformen, kunnen communiceren met UT2004. De communicatie met UT2004 verloopt via GameBots2004, dan via Pogamut naar GOAL. In GOAL wordt de kunstmatige intelligentie geprogrammeerd. GameBots (University of Southern California's Information Sciences Institute) is een moderator voor Unreal Tournament waarmee het spel aangepast kan worden. De standaard game modes in Unreal Tournament, zoals DeathMatch en Capture the Flag zijn ook moderators voor het spel. Met de Capture the Flag moderator wordt het spel zo aangepast dat er een vlag komt op een vlag basis en dat spelers er punten mee kunnen verdienen. GameBots is een moderator die naast de standaard spel modus draait, zoals Capture the Flag, en alle data die de bots zien doorsturen naar, in dit geval, het Pogamut platform. Pogamut is Java middleware die er voor zorgt dat agents aangestuurd kunnen worden in diverse games gemaakt met de Unreal Development Kit (Epic Games, 2009) zoals Unreal Tournament 2004, EmoHawk en DEFCON. Pogamut zorgt voor een Java API die het besturen van de bots verzorgd. Het doel van het project was om het aanmaken van agents te versimpelen. Dit zorgt er voor dat zelfs een complexe taak zoals routeplanning eenvoudig uitgevoerd kan worden. Met de release van Pogamut 3 in Maart 2012 is er voor gekozen om een nieuwe weg in te slaan en de complete architectuur te veranderen, dit heeft geleid tot een robuust framework dat vele toepassingen kent. Pogamut wordt onder andere gebruikt aan de Charles University in Praag om studenten kennis te laten maken met het programmeren van agents.
2.3
UT2004 VISUALIZER
De Visualizer is een tool om een versimpelde weergave van de map te krijgen. Via deze tool kan men ook de server herstarten, pauzeren en een andere map laden. Tevens kunnen er GOAL bots en native Unreal Tournament bots geladen worden. Bots en spelers kunnen via de Visualizer ook uit de map gehaald worden via het kick commando. Dit commando zorgt ervoor dat de speler of bot wordt gedisconnect van de server. Naast bot en player server management kan de tool ook gebruikt worden om items te spawnen op de map of om wapens direct aan een bot te geven, zoals wapens, ammo en health. De tool kan ook gebruikt worden om bots en spelers te respawnen of naar een ander team te verhuizen.
11
AFBEELDING 4 - HET UITERLIJK VAN DE VISUALIZER
2.4
INTRODUCTIE TOT GOAL
GOAL is een agent programmeertaal voor het programmeren van cognitive agents. De agents in GOAL (K.V. Hindriks, F.S. de Boer, W. van der Hoek, J.-J.Ch. Meyer, 2002) voeren actions uit gebaseerd op beliefs en goals. De programmeertaal biedt de mogelijkheid om de beliefs en goals van de agent te manipuleren en om de manier waarop de agent zijn beslissingen maakt te structureren. De UT3 omgeving verstuurd percepts met informatie in de omgeving, dit is bijvoorbeeld een wapen dat de bot ziet liggen. Dit percept wordt afgevangen door GOAL en de gebruiker kan er voor kiezen om dit op te slaan in de vorm van een belief. In de knowledge section van het GOAL programma staat de kennis die de agent heeft over het domein. Een voorbeeld staat in het volgende stuk code. knowledge{ useableWeapon(W) :- weapon(W,A), A>0. needWeapon :- findall(W,useableWeapon(W),L), length(L,N), N<3. }
SNIPPET 1 - KNOWLEDGE SECTIE VAN EEN UNREAL AGENT
De knowledge wordt hier gerepresenteerd met behulp van de taal Prolog. De term useableWeapon(W) is waar wanneer er een wapen is met ammo. Deze regels worden gebruikt bij de beslissingen die de agent neemt. In de Unreal omgeving is dat bijvoorbeeld wanneer de bot op zoek gaat naar armor. Heeft de bot al 200 punten aan armor dan is het niet zinvol om te gaan zoeken naar nieuw armor.
2.5
UNIT TESTS IN GOAL
Het idee van een kunstmatige intelligentie is dat hij zelf beslissingen kan maken, precies om deze reden is het belangrijk dat de fundering van de bot goed werkt en dus ook goed getest wordt door middel van unit tests. Een kunstmatige intelligentie wordt redelijk snel een complex geheel en het is meestal lastig te bepalen of een nieuwe functie niet werkt, of dat een oude functie niet goed is getest waardoor de nieuwe functie niet werkt. Tot voor kort kon er in GOAL alleen maar handmatig getest worden. Dit betekent, start de bot, hou zijn mental state in de gaten en kijk of alles goed gaat. Helaas staat er vrij veel in de mental state van de bot en wordt het vrij 12
snel onoverzichtelijk wat er gebeurd voor een mens. Dit heeft als resultaat dat er meestal weinig, slecht, of alleen simpel getest wordt. Tijdens dit project is er ook een unit test omgeving ontwikkeld voor GOAL en deze helpt met het draaien van unit tests in GOAL. Deze omgeving helpt ons ook met het testen van de nieuwe implementaties van UT3. Door middel van het draaien van UT2004 tests op UT3 code kunnen we ook snel zien of de eis dat UT3 en UT2004 vrijwel hetzelfde zijn in GOAL, gehaald is.
2.6
DE OPDRACHT
De opdracht is om een omgeving te bouwen voor de programmeertaal GOAL waardoor bots aangestuurd kunnen worden in UT3. Er is een start gemaakt aan de UT3 omgeving voor GOAL door Rien Korstanje. Hij heeft ook gewerkt aan de UT2004 omgeving. Het is mogelijk voor een bot om rond te lopen en op tegenstanders te schieten. Er is nog geen ondersteuning van Capture The Flag mode en de omgeving ondersteunt nog lang niet alle acties en percepts. Tot slot moeten de geprogrammeerde bots te testen zijn door middel van unit tests in GOAL.
2.6.1 DE GEWENSTE SITUATIE VAN DE UT3 OMGEVING De gewenste situatie is uit te drukken in een MoSCoW model. Dit model is in samenwerking met de opdrachtgever gemaakt en beschrijft alle ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’. Must: 1.
2.
3.
4.
Drie verschillende Capture The Flag (CTF) mappen: het moet mogelijk zijn om de bots op drie verschillende mappen een CTF game te laten spelen. De mappen hebben een verschillende grootte en niveau van uitdaging. Een test map die relatief klein is maar wel alle soorten pickups, jump-pads, teleports enz. bevat. Deze map kunnen studenten gebruiken om hun agent te testen. De test map zal naast de andere mappen ook worden gebruikt om het eindproduct te testen. De interface voor acties voor de UT3 omgeving is een conservatieve uitbreiding van de interface voor acties voor de UT2004 omgeving. De acties die al beschikbaar zijn in de interface voor UT2004 worden ook beschikbaar gemaakt voor UT3 (met dezelfde effecten). Dat betekent dat een UT2004 bot ook in de UT3 omgeving kan draaien zonder problemen en zich hetzelfde gedraagt in de UT3 omgeving. Eventuele wijzigingen worden ook doorgevoerd in UT2004 (als een actie een andere specificatie krijgt dan in de originele specificatie voor UT2004, dan wordt geprobeerd dat ook te wijzigen voor UT2004). Als dat niet mogelijk is, wordt overlegd met opdrachtgever over de wijziging en de nieuwe specificatie. De interface voor UT3 kan wel uit meer acties bestaan dan die voor UT2004. De omgeving moet percepts sturen over informatie in de wereld. Dit zijn wapens, armor, health, speciale wapens en bonussen maar ook informatie over de bot zelf en bots die elkaar kunnen zien. Opgesomd bestaat dit uit de volgende onderdelen. Wapens Navigation points (paden in de wereld) Armor Health Power-ups Spelers Flags Ammo Type spel Aantal kills 13
Aantal deaths Speciale velden in de map 5. Ondersteuning van alle normale wapens zoals beschreven in tabel 2. 6. Ondersteuning van het Slow Volume wapen. 7. Ondersteuning van alle soorten armor. Shield Belt Thigh Pads Helmet Vest Armor 8. Ondersteuning van alle acties uit de UT2004 omgeving. 9. Het ondersteunen van UT3 specifieke acties voor het afvuren van een deployable wapen. 10. Een gebruikershandleiding voor de UT3 omgeving met details over alle acties en percepts van de omgeving. Afhankelijk van het aantal verschillen is deze handleiding een uitbreiding van de bestaande handleiding voor UT2004, of een handleiding speciaal voor UT3 (maar wel met dezelfde structuur als de handleiding voor UT2004). 11. De performance van de UT3 omgeving is gelijk aan of beter dan de performance van de UT2004 omgeving. In termen van milliseconden (ms) per ronde. UT3 heeft extra info per pad, dus dit kan voor extra overhead zorgen. De vertraging mag maximaal 25% zijn ten opzichte van UT2004. (10ms ronde mag dus maximaal 12,5ms zijn in UT3). 12. De omgeving moet kunnen draaien op de computers van de Drebbelweg. In het bijzonder moet er aan het eind van elke Sprint getest worden op de daarvoor beschikbaar gemaakte PC’s waarop UT3 is geïnstalleerd in het Studielandschap. De resultaten van deze test worden aan het eind van elke Sprint per mail gerapporteerd aan de opdrachtgevers.
Should: 1. Een visualizer met ondersteuning voor: Spawnen van wapens, armor, health, bonussen en spelers (GOAL bots of Epic bots) Het weergeven van een compact overzicht van de map Het tekenen van geplande paden van bots 2. Hoverboard ondersteuning De hoverboard is een item die op grote mappen gebruikt kan worden om snel over de map te bewegen, het nadeel is wel dat je een paar seconden op de grond ligt zodra je geraakt wordt en de vlag dropt. 3. Ondersteuning van teleporters in de pathfinding. Dit betekent dat bots gebruik kunnen gaan maken van teleporters om zicht te verplaatsen over de map. 4. Translocator ondersteuning. De translocator kan gebruikt worden om op speciale plekken te komen binnen een map. 5. Visueel verschillende teams door middel van skins en kleur. 6. Ondersteuning van het Minelayer wapen. Could: 1. 2. 3. 4. 5.
Moderator schrijven voor UT3 zodat spectaten makkelijker gaat in UT3. Diverse game modes waaronder Vehicle CTF, Deathmatch en Team Deatmatch. Ondersteuning van voertuigen. Dit wil zeggen dat bots ook auto's of vliegtuigen kunnen gaan besturen. Ondersteuning van de AVRiL (anti-vehicle wapen). Dit werkt anders dan de andere wapens in UT3 en UT2004 omdat dit wapen een lock moet krijgen op zijn target. Ondersteuning van de volgende acties: Vehicle grapple - dit kan in UT3 door achter een voertuig te gaan hangen met een hoverboard Enter vehicle - de bot laten instappen in een voertuig Repair vehicle - een voertuig repareren
14
6.
De moderator uitbreiden met een automatische spectate mode. Dit betekent dat de spelers automatisch gevolgd worden waar actie te zien is. Momenteel kan je alleen handmatig de bots volgen, het zou interessant zijn om de spectator automatisch naar actie te laten gaan. UDK ondersteunt PIP (Picture in Picture) dit kan een uitkomst bieden voor handmatig spectaten met in een hoek een kleiner schermpje die de auto-focus doet op actie.
Won’t: 1. Een andere spelmodus dan CTF, Vehicle CTF, Team Deathmatch en Deathmatch wordt niet ondersteund
2.6.2 DE GEWENSTE SITUATIE VAN HET TEST FRAMEWORK Het test framework wordt niet door ons ontwikkeld maar gaat wel een onderdeel worden voor het practicum van Multi-Agent Systemen. Er is daarom afgesproken dat wij een aantal unit tests schrijven voor de GOAL bots in de UT3 omgeving, deze tests kunnen dan als voorbeeld dienen voor het practicum.
2.7
KWALITEITSWAARBORGING
Het uiteindelijke product gaat gebruikt worden door honderden studenten. Het is daarom erg belangrijk om de code goed te testen en er zeker van te zijn dat er een stabiel eindproduct is geleverd. De code wordt tijdens het project voortdurend getest door middel van integratie tests. Aan het einde van het project wordt er ook volgens de richtlijnen van het vak Multi-Agent Systemen een bot-team gemaakt zoals wordt verwacht van de studenten. Er wordt ook een test map gebouwd waardoor specifieke onderdelen eenvoudiger te testen zijn. Tot slot wordt de code opgestuurd naar de Software Improvement Group (SIG). Dit is een organisatie die de kwaliteit van de code onderzoekt en beoordeeld.
15
3. ONTWERP De opdracht is om het mogelijk te maken voor GOAL agents om te communiceren met UT3 bots. Hiervoor moeten we data uit UT3 krijgen en door geven naar GOAL. Om dit te bereiken zijn er een aantal opties: 1. 2. 3.
Client connecten direct op de server, net als het normale spel, en proberen deze output op te vangen. Normale UT3 cliënt starten en via video analysis proberen output te genereren en mouse en keyboard input terug geven. Een custom server schrijven en daarmee verbinden.
Optie 2 valt eigenlijk direct af aangezien deze ernstig inefficiënt is. Optie 1 is een goede keus, maar moet worden geschreven in UnrealScript en als apart programma gedraaid worden. Optie 3 is een goede keus en, in het geval van UT3, kan tegelijk op de server gestart worden als moderator. Optie 2 en optie 3 zijn eigenlijk hetzelfde, met als verschil dat we bij optie 3 de output zelf kunnen bepalen en zo ook netwerk overhead kunnen reduceren, het interesseert de bot bijvoorbeeld niet wat voor model of skin de tegenstanders hebben, alleen waar hij is. Optie 3 is de uiteindelijke keus geworden, omdat we zo specifiek onze output kunnen bepalen en ook geen extra programma’s hoeven te draaien. Tevens bestaat er al een dergelijke implementatie in de vorm van GameBots2004. Zoals beschreven in hoofdstuk 2.4 doet GameBots2004 precies wat we nodig hebben, alleen moet het klaar gemaakt worden voor UT3. Nu is de vraag of we Pogamut nog steeds nodig hebben als we zelf GameBots gaan upgraden en ontwerpen voor UT3. We kunnen immers de output van GameBots zelf bepalen en laten aansluiten op onze environment. Met het programmeren in GOAL is het niet de bedoeling dat men te veel bezig is met triviale dingen, zoals het handmatig mikken op een doelwit. Dit moet allemaal op een hoger niveau, zodat GOAL alleen maar het commando heeft zoals “schiet op dit doelwit” of "loop naar x". Tevens het schieten zelf (overhalen van de trekker, of linker muis knop voor een menselijke speler), navigeren van punt A naar punt B, is allemaal lager level intelligentie wat niet in GOAL thuis hoort, omdat dit alles erg complex maakt voor de programmeur. Er is dus behoefte aan een stuk software tussen UT3 en GOAL. Wederom kunnen we weer opnieuw beginnen met het ontwikkelen van deze software, maar het Pogamut platform gebruikt voor UT2004 kan al GameBots aan de ene kant accepteren en de GOAL environment voor UT2004 aan de andere kant. Aangezien het Pogamut platform alles bevat voor UT2004 en omgezet kan worden naar UT3 hebben we er voor gekozen om dit te gebruiken. Het project bestaat uit de volgende onderdelen: 1. 2. 3. 4.
Goal UT2004 omgeving uitbreiden Goal UT3 omgeving ontwikkelen UT3 visualizer ontwikkelen Test framework ontwikkelen voor het MAS-project
In dit hoofdstuk komt elk onderdeel van dit het project uitgebreid aan bod. Er wordt een schets gegeven van de huidige situatie en een ontwerp van de gewenste situatie.
16
3.1
LAGENSTRUCTUUR GOAL UT3/UT2004 ENVIRONMENT
Om inzicht te krijgen in het project is het goed om te weten hoe de UT3 GOAL environment wordt opgebouwd uit verschillende lagen. Het spel Unreal Tournament draait op de Unreal Engine, dit is een veelgebruikte game engine die vooral gebruikt wordt voor first person shooters. Een groot deel van de gameplay is geschreven in UnrealScript, een scripttaal die is ontwikkeld door Epic Games. Hierdoor is het eenvoudig om bijvoorbeeld mods of uitbreidingen te maken voor het spel. Op deze manier is ook GameBots ontstaan. GameBots is een mod van Unreal Tournament die het in staat stelt om een server te starten en ondertussen via een TCP/IP verbinding informatie over het spel te versturen in een tekst formaat. Er wordt bijvoorbeeld informatie verzonden over spelers, pickups of bijvoorbeeld de positie van de vlag. GameBots verstuurd de berichten in een plat tekst formaat naar Pogamut. Een voorbeeld is gegeven in snippet 2 waar een FLG message wordt verstuurd. Dit is een bericht met informatie waar de vlag van elk team ligt. In dit geval ligt de vlag van 'Team 1' op de NavPoint 'CTF-UG-AbsoluteZero.xBlueFlag' en zijn tot slot ook de coördinaten mee gestuurd.
FLG {Id CTF-UG-AbsoluteZero.xBlueFlag} {Team 1} {State home} {Location 0.00,5632.00,1630.00}
SNIPPET 2 - FLG MESSAGE VAN GAMEBOTS,
Pogamut is een platform dat het bericht omzet in een Java object. Dit zorgt er voor dat bots te programmeren zijn vanuit Java. Tot slot is het hoofdonderdeel van dit project de GOAL omgeving die via EIS (K.V. Hindriks, T. M. Behrens, W. Pasman , 2013) wordt aangestuurd om Java om te zetten in GOAL en omgekeerd. Een overzicht van de verschillende lagen staat in de onderstaande afbeelding. De rode blokken geven aan waar aan gewerkt gaat worden in dit project.
AFBEELDING 5 - ALLE BELANGRIJKE LAGEN VAN HET GOAL UNREAL ENVIRONMENT PROJECT
3.2
GAMEBOTS
Zoals eerder is uitgelegd is GameBots een mod van Unreal Tournament. In 2000 is er begonnen aan de ontwikkeling van GameBots aan de University of Southern California’s Information Science Institute door Andrew, Marshal en Gal Kaminka. Pogamut heeft een branch gemaakt van GameBots voor UT2004 en later ook een voor UT3. De functionaliteit van de oorspronkelijke GameBotsUT3 versie was erg beperkt en moet dus uitgebreid worden. In dit hoofdstuk behandelen we wat er moet gebeuren aan GameBots en waarom we hier voor gekozen hebben.
17
3.2.1 ONTWERP GAMEBOTS GameBotsUT3 is opgedeeld in de volgende drie verbindingen.
Bot connection – deze verbinding wordt gebruikt voor het aansturen van de bot in de omgeving en tegelijk voor het ontvangen informatie uit de omgeving (wat de speler kan zien, health, armor, team etc.) Control connection – deze verbinding wordt gebruikt voor de aansturing van spel mechanismen zoals het pauzeren van het spel, verwijderen van spelers uit het spel en het veranderen van de map Observer connection – deze verbinding wordt gebruikt voor het observeren van spelers of bots in het spel, informatie wat de speler of bot doet wordt geëxporteerd via het protocol
Dit is op deze manier gedaan zodat de snelheid hoog kan blijven voor belangrijke taken. Een belangrijke taak is bijvoorbeeld het schieten op een bot, dit moet snel gebeuren en daarom kan de verbinding niet continue belast worden met bijvoorbeeld het spawnen van wapens door de host.
AIN {Id UTWeap_RocketLauncher_0} {Type RocketLauncher} {PickupType RocketLauncher.WeaponPickup} {Sniping False} {Melee False} {PrimaryInitialAmmo 9} {MaxPrimaryAmmo 30} {SecondaryInitialAmmo 0} {MaxSecondaryAmmo 0} IPK {Id UTWeap_RocketLauncher_0} {InventoryId UTWeap_RocketLauncher_0} {Location 1886.64,-350.26,-78.00} {Type RocketLauncher} {Amount 9} WUP {Id UTWeap_LinkGun_0} {PrimaryAmmo 100} {SecondaryAmmo 0} {InventoryType LinkGun} CWP {Id UTWeap_RocketLauncher_0} {PrimaryAmmo 18} {SecondaryAmmo 0} {Type RocketLauncher}
SNIPPET 3 - GAMEBOTS BERICHT NA HET OPPAKKEN VAN WAPENS
In dit bericht komt er eerst een 'AddInventory (AIN)' binnen door het oppakken van de rocket launcher. Vervolgens wordt er een 'ItemPickedUp (IPK)' verstuurd die er aangeeft hoeveel ammo de rocket launcher heeft en op welke locatie het wapen lag, daarna wordt er een 'WeaponUpdate (WUP)' verstuurd waarin de status van het oude wapen wordt verstuurd. Tot slot wordt er een 'ChangeWeapon (CWP)' verstuurd om aan te geven wat het nieuwe wapen wordt, in dit geval is dat de rocket launcher. De code wordt grotendeels afgekeken van GameBotsUT2004, maar omdat die op de Unreal Engine 2.5 draait en GameBotsUT3 op de Unreal Engine 3, moeten er veel aanpassingen gedaan worden. Bijna alle messages in GameBots moesten worden aangepast zodat ze werken met UT3. Er was een begin gemaakt door het Pogamut team in de vorm van een bachelor project aan een nieuwe GameBotsUT3 en die hebben we als basis gebruikt. De code moest voor een groot deel opnieuw geschreven of aangepast worden aangezien deze niet werkte. Een aantal voorbeelden hiervan zijn de vlag berichten die aangeven waar de vlag is, het respawn bericht wat ervoor zorgt dat de bots kunnen respawnen, en het spawn item bericht, wat ervoor zorgt dat er een item spawnt op de map.
18
Naast het repareren van al bestaande functies moesten er ook nieuwe berichten ontwikkeld worden om ervoor te zorgen dat de nieuwe gameplay elementen vanuit UT3 het ook doen. Een voorbeeld hiervan zijn de deployables en slow fields. Omdat er voor UnrealScript geen unit test framework bestaat is het niet mogelijk om automatisch de resultaten te controleren. Dit moet dus handmatig gebeuren. De tests worden geschreven in Java en de log wordt afgevangen door de Unreal Development Kit.
3.3
POGAMUT
In dit hoofdstuk zal enkel een korte beschrijving worden gegeven van de werking van Pogamut. De details over de werking van Pogamut kunnen worden gevonden in de paper (J. Gemrot, C. Brom, R. Kadlec, M. Bída, O. Burkert, 2009) . In dit hoofdstuk komt ook de Pogamut implementatie voor UT3 aan bod.
3.3.1 ARCHITECTUUR POGAMUT Omdat Pogamut is ontwikkeld voor Unreal Tournament 2004 en de bijbehorende Unreal Engine 2.5, behandelen we in dit hoofdstuk wat er veranderd moet worden aan Pogamut om ook Unreal Tournament 3 te ondersteunen. Het is belangrijk dat dit een constructieve verbetering wordt zodat er na het afsluiten van dit project ook nog aan gewerkt kan worden vanuit Praag. De volgende afbeelding geeft een overzicht van de architectuur van Pogamut.
AFBEELDING 6 - POGAMUT ARCHITECTUUR
De kern van Pogamut wordt de Gavialib genoemd en is paars in afbeelding 6. De berichten vanuit GameBots worden door de Yylex parser omgezet in Java objecten, de Yylex parser is een onderdeel van JFlex (JFlex, 2009), dat is een lexical analyzer generator1 voor Java. Deze parser zet de berichten vanuit GameBots om in InfoObject Java 1
lexical analyzer - het omzetten van een reeks karakters in symbolen 19
objecten. Dit object wordt doorgegeven aan de WorldMessageTranslator, die er voor zorgt dat dat het object vertaald wordt naar een WorldEvent object. Een WorldEvent object is het daadwerkelijke object wat informatie bevat over de wereld. De WorldAdapter is optioneel, dat wil zeggen dat, door middel van dependency injection met Guice (Guice, 2008), de ontwikkelaar de gewenste adapter kan maken en deze kan injecteren in de agent. Elke adapter luistert naar events en verstuurt commands die door de ontwikkelaar zijn opgegeven. Op deze manier zorgt Pogamut er voor dat er meerdere games worden ondersteund en dat het platform zo min mogelijk dependencies heeft. Een voorbeeld hier van is als de ontwikkelaar een mod voor UT2004 maakt waarin de agent ook appels moet eten om in leven te blijven. Dit zit niet standaard in UT2004 dus moet er door een nieuwe WorldAdapter geluisterd worden naar berichten of de agent honger heeft.
3.3.2 SENSOR MODULES PogamutUT2004 bestaat voor een groot deel uit sensor modules die luisteren naar de events van de WorldAdapter. Een aantal van deze modules zijn.
AgentInfo - informatie over de bot zoals de hoeveelheid leven, locatie, team etc. Items - geeft aan of bepaalde items opgepakt kunnen worden, welke items zichtbaar zijn etc. Weaponry - informatie over de wapens en ammo in de inventory
Er zijn nog veel meer sensor modules die gebruikt worden door PogamutUT2004. De sensor modules vormen de basis voor het programmeren van een bot met behulp van Pogamut. Een bot geschreven in Java kan bijvoorbeeld uit de sensor module AgentInfo de functie getHealth aanroepen om te controleren hoeveel health de bot nog heeft. Pogamut ondersteund een aantal games die gemaakt zijn met de UDK. Voor elke van deze projecten is er een branch gemaakt van de PogamutUT2004 versie en zijn de sensor modules aangepast om nieuwe speleigenschappen te ondersteunen zoals het eten van appels. Dit betekent dat alle bestaande code voor PogamutUT2004 gekopieerd is en de sensor modules aangepast zijn om specifieke items en wapens te ondersteunen. Twee belangrijke modules die hier een rol spelen zijn de items- en de weaponrymodule. De weaponrymodule handelt informatie over de wapens af. Een voorbeeld staat in de volgende snippet.
public boolean changeWeapon(ItemType weaponType) { if (weaponType == null) return false; if (weaponType.getCategory() != ItemType.Category.WEAPON) return false; Weapon weapon = getWeapon(weaponType); return changeWeapon(getWeapon(weaponType)); } public UnrealId getWeaponInventoryId(ItemType weaponType) { return weaponTypeToInventoryUnrealId.get(weaponType); }
SNIPPET 4 - SOURCE WEAPONRY.JAVA
De bot kan bijvoorbeeld deze module gebruiken voor het wisselen van wapens. Dit illustreert meteen het probleem van deze module, namelijk de dependency op ItemType. ItemType is een klasse die alle onderdelen in het spel koppelt aan de de types die worden opgestuurd door GameBots. De volgende snippet laat een paar regels uit ItemType.java zien.
20
/** LinkGun weapon. */ public static final ItemType LINK_GUN = MakePrototype(Category.WEAPON, Group.LINK_GUN, new String[] { "LinkGun.WeaponPickup", "LinkGun" }); /** LinkGun ammo. */ public static final ItemType LINK_GUN_AMMO = MakePrototype(Category.AMMO, Group.LINK_GUN, new String[] { "LinkGunAmmo.AmmoPickup", "LinkGunAmmo" }); /** RocketLauncher weapon. */ public static final ItemType ROCKET_LAUNCHER = MakePrototype( Category.WEAPON, Group.ROCKET_LAUNCHER, new String[] { "RocketLauncher.WeaponPickup", "RocketLauncher_Content.WeaponPickup", "RocketLauncher" });
SNIPPET 5 - ITEMTYPE.JAVA
De waardes "RocketLauncher.WeaponPickup" en "LinkGun.WeaponPickup" worden gebruikt bij het opsturen van de locatie van de RocketLauncher en de LinkGun door GameBots. Deze klasse kan enkel om gaan met items uit UT2004 en moet dus vervangen worden voor een klasse die UT3 wapens ondersteund. De weaponry module is verder hetzelfde voor UT3; de gebruiker kan wisselen van wapen, schieten met een wapen en ammo opvragen van een wapen.
3.3.3 ONTWERP POGAMUTUT3 Het is niet aantrekkelijk om voor UT3 een branch te maken van Pogamut en UT2004 specifieke code, zoals de ItemType uit de vorige paragraaf, te vervangen voor UT3 items. Dit zou een grote hoeveelheid duplicate code2 opleveren omdat ook een groot deel van de sensor modules blijven bestaan. In afbeelding 6 is de Pogamut architectuur besproken en een dergelijke aanpassing heeft als gevolg dat alle blokken identiek blijven op een paar wijzigingen in de WorldAdapter na. Omdat wij een constructieve bijdrage willen leveren aan het Pogamut project is er gekozen voor een abstractie van Pogamut. In deze aanpak wordt er voor gekozen om het bestaande Pogamut project uit te breiden zodat verschillende versies van Unreal Tournament ondersteund worden door hetzelfde platform. Om dit te bereiken moet er het volgende gebeuren.
2
Abstracte ItemType klasse - de ItemType klasse beschrijft elk object in de game, dit is voor elke versie van Unreal Tournament weer anders. Door een abstractie te maken van deze klasse kan elke variant van UT een eigen subklasse implementeren van de abstracte klasse waarin de onderdelen van het spel zijn gedefinieerd. De Yylex parser moet ook uitgebreid worden omdat op dit niveau de parser moet weten met welke implementatie hij te maken heeft. Door middel van code injection wordt er aan de parser meegegeven om welke implementatie het gaat en kan de parser het juiste object doorgeven zoals aangegeven in afbeelding 6 UT3AgentInfo -in UT3 wordt er anders om gegaan met armor dan in UT2004. Dit kan eenvoudig opgelost worden in Pogamut door de AgentInfo sensor module te overerven. Hierdoor worden de basiselementen
duplicate code - stukken code die meer dan één keer voorkomen in een programma of entiteit 21
zoals het opvragen van health en kills behouden maar kan de module uitgebreid worden om UT3 armor te ondersteunen. UT3Visiblity - de Visibility sensor module zorgt er voor dat de bot informatie kan opvragen over zijn omgeving. Het gaat dan bijvoorbeeld om bots of wapens. In UT3 zijn hier de deployables bijgekomen; dat zijn de wapens die op de grond gelegd kunnen worden en een veld creëren. Deze module wordt net als de AgentInfo module uitgebreid om deze UT3 functionaliteit te ondersteunen. UT3Items - de Items sensor module zorgt er voor dat bots weten wanneer een item opgepakt kan worden. De module geeft voor een aantal items de respawntijd terug, deze zijn voor sommige UT3 items veranderd en daarom is deze sensor module nodig.
3.4
UT3 GOAL ENVIRONMENT
In deze paragraaf zal ons eindproduct de UT3 GOAL Environment worden behandeld en komen de keuzes aan bod die wij hebben gemaakt voor het ontwerpen van dit onderdeel. De opdracht is om een GOAL environment te ontwikkelen voor UT3. Deze environment bestaat al voor UT2004 en zal ook grotendeels gebruikt worden voor UT3. De meeste acties en percepts blijven hetzelfde met uitzonderingen van een paar UT3 specifieke uitbreidingen die in deze paragraaf worden behandeld. De bestaande acties en percepts blijven hetzelfde omdat we Pogamut zo verbeteren dat het bruikbaar wordt voor zowel UT2004 als UT3.
3.4.1 DEPLOYABLE WEAPONS Om deployable weapons te ondersteunen moeten we in alle drie de lagen (GameBots, Pogamut en de Environment) een aantal veranderingen doorvoeren. We willen als eerst dat de bot een veld kan zien dat neer is gelegd met een deployable weapon, daarom wordt de SeeVolume message geïntroduceerd. SVL - SlowVolume Id(UnrealId) Id van de navpoint in de slow volume. Visible(boolean) Geeft aan of de navpoint met Id zichtbaar is in een slow volume.
SNIPPET 6 - JAVADOC VAN DE SVL MESSAGE
Dit bericht moet dus door GameBots verstuurd worden zodra een bot een slow volume ziet liggen. Alle navpoints die binnen de slow volume liggen worden verstuurd naar de bot. Het is dan van belang dat er in Pogamut een sensor module wordt gemaakt die deze informatie afvangt en de bot informeert over de zichtbare navpoints in het volume zodat we dit uiteindelijk in de environment kunnen gebruiken. GameBots behandeld voor de rest deployables op dezelfde manier als gewone wapens. We handelen de speciale eigenschappen af in de hogere lagen. De environment is verantwoordelijk om er voor te zorgen dat als de bot een deployable vast houdt, hij niet automatisch gaat schieten wanneer er een vijandige bot in de buurt komt. Dit moet gebeuren want anders zou de bot bij elke willekeurige vijand die hij tegen komt, direct zijn wapen neerleggen. Daarom is de actie deploy/1 geïntroduceerd waarmee de GOAL gebruiker het wapen zelf kan neerleggen.
22
3.5
VISUALIZER
De visualizer voor UT2004 draait direct boven op de output van GameBots. Om de visualizer te porten naar UT3 hoeven we dus alleen maar GameBots aan te passen. Omdat de opdrachtgever zoveel mogelijk overlap wil tussen UT2004 en UT3 is er gekozen om de visualizer niet apart te maken voor UT3, maar uit te breiden met UT3 commando’s waar nodig. De visualizer moet kunnen bepalen of hij verbonden is met een UT3 of een UT2004 server, dit kan standaard niet en zou verholpen kunnen worden door een bericht te sturen vanuit GameBots naar de visualizer om zich te identificeren met UT3 dan wel met UT2004. Het Pogamut team wilde dit liever niet omdat hier voor het protocol aangepast moet worden voor de handshake. Dit zou betekenen dat UT2004 en eventuele andere games op de UDK ook deze wijziging moeten doorvoeren. Daarom is er voor een andere oplossing gekozen, namelijk een UT3/UT2004 keuze menu in de visualizer. De standaard acties zoals pauzeer server, kick bot, respawn bot, etc. moet geïmplementeerd worden. In dit geval is ervoor gekozen om het bericht naar GameBots in hetzelfde formaat te houden als bij UT2004, op deze manier hoeft de visualizer zo min mogelijk aangepast te worden om zowel UT2004 als UT3 te ondersteunen. Aangezien het spawnen van wapens en dergelijke werkt door direct de naam van het object door te geven zoals deze in de Unreal Engine heet, en omdat sommige items anders heten dan in UT2004 is ervoor gekozen om een apart sub menu te maken voor het spawnen van UT3 items ten opzichte van UT2004 items.
3.6
TEST FRAMEWORK
Het test framework wordt een onderdeel van de programmeertaal GOAL. Dit betekent dat GOAL omgebouwd wordt om unit tests te kunnen ondersteunen zodat de studenten de agents beter kunnen testen. het framework wordt niet door ons ontwikkeld maar gaat wel gebruikt worden om agents te testen. Eerst worden er tests ontwikkeld voor de UT2004 omgeving omdat deze al robuust en betrouwbaar is. Zodra het testframework en de UT3 omgeving is afgerond gaan de tests ook gedraaid worden op de UT3 omgeving. Dit geeft ons ook weer meer inzicht in de kwaliteit van de UT3 omgeving.
23
4. AANPAK EN TIJDSPLANNING In dit hoofdstuk wordt beschreven wat voor resources wij hebben gebruikt, hoe wij de taakverdeling hebben gedaan en wat voor tijdsplanning wij hebben gemaakt. Voor dit project is een Wiki, Trac en een SVN aangemaakt. Op de Wiki 3 staat het eindproduct met de manual, updates en log-changes van de omgeving. Omdat het project gebouwd is rond bestaande software zoals Pogamut en GameBots2004 zijn de eerste twee weken van het project gebruik om het Pogamut platform uit te testen. Dit hebben wij gedaan door aan de oude UT2004 omgeving een paar bug-fixes en verbeteringen door te voeren. Daarna is er begonnen met de ontwikkeling van de UT3 omgeving en de laatste twee weken worden besteed aan het schrijven van het rapport. Elke week is er een afspraak met onze begeleider Rien Korstanje ingepland om vragen te stellen en de laatste veranderingen door te spreken. Eens in de twee weken is er een afspraak met de supervisor Koen Hindriks om een update te geven van het project. Omdat er ook een aantal veranderingen aan Pogamut gedaan moeten worden is er een fork gemaakt van de Pogamut SVN. Wij gaan met het Pogamut team overleggen hoe zij tegenover onze veranderingen staan en of dit ook opgenomen kan worden in een nieuwe release van het Pogamut platform.
4.1
RESOURCES
Hier volgt een overzicht van de resources die we gebruiken voor dit project. Dit zijn de meest belangrijke resources. Alle triviale resources zijn weggelaten. Naam Maven SVN TRAC UnrealED
Beschrijving Automatisering van het build proces. Versie beheer. Ticket beheer systeem. Map editor voor Unreal Tournament.
Netbeans Javadoc Visual Studio 2012
IDE voor Java. Genereerd documentatie voor het project. IDE voor UnrealScript, wordt gebruikt voor het ontwikkelen van GameBots. Add-on voor Visual Studio zodat er syntax highlighting is voor UnrealScript en ondersteuning voor IntelliSense.
nFringe
TABEL 3 - DE RESOURCES VOOR DIT PROJECT
3
http://ii.tudelft.nl/trac/goal/wiki/Projects/UT3 24
4.2
TIJDSPLANNING EN TAAKVERDELING
Het volledige project moet afgerond zijn op 14 januari 2014. Hier volgt een tijdsindeling van onze SCRUM sprints. De taken zijn gebaseerd op het MoSCoW model. Alle taken worden door zowel Michiel als Peter gedaan.
Taak
Deadline
Oriëntatiefase: Plan van aanpak schrijven. Inlezen UT2004 code. Kleine verbeteringen implementeren en bug fixen in de UT2004 omgeving. Rapport oriëntatiefase
20/9/2013
SCRUM 1: Ondersteuning van alle UT2004 functionaliteit in UT3. UT2004 Percepts. UT2004 acties behalve dropWeapon, het droppen van weapons wordt niet ondersteund in UT3. UT2004 manual aanpassen zodat ook de UT3 omgeving gebruikt kan worden. SCRUM 2: Schietgedrag van de UT3 omgeving implementeren en verbeteren, al het schietgedrag van de basiswapens implementeren. Ondersteuning van speciale UT3 gerelateerde items: Hoverboard ondersteuning onderzoeken. Slow field wapen ondersteunen. SCRUM 3: Visualizer met basis functionaliteit waaronder o Het spawnen van bots o Bots respawnen o Bots/Spelers kicken o Wapens spawnen o Kiezen van de map o Pauzeren/Resumen van de server o Overzicht van de map Opzet test framework indien mogelijk. Schrijven van unit tests voor het test framework. Afronding: Betrouwbaar eindproduct met alle ‘could haves’ uit het MoSCoW model, dit betekent een 100% werkend product zoals het staat beschreven in de handleiding. Test framework afgerond. Rapport: Rapport conform de eisen van TI3800.
14/10/2013
30/9/2013
28/10/2013
11/11/2013
1/01/2014
14/01/2014
Op de TRAC pagina worden voor elke SCRUM sprints tickets aangemaakt en verdeeld. De verdeling van de taken wordt in overleg gedaan. Taken waar één van de groepsleden niet uit komt worden met meerdere personen opgelost door middel van pairwise programming.
25
4.3
SCRUM LOG
Legenda: Gehaald
Opgeschoven
Vervallen
4.3.1 SCRUM 1 In deze fase zijn we aan de slag gegaan met het repareren van fouten die we direct zagen, zoals het probleem met de ItemTypes. Alleen niet gehaalde of opgeschoven SCRUM punten worden besproken, de rest is volgens plan. Categorie MUST MUST MUST MUST SHOULD SHOULD WONT MUST MUST
MOSCOW 4 5 6 2 3 4 1 8 9
Omschrijving Percepts van de items moeten goed binnen komen Nieuwe UT3 items moeten worden ondersteund Acties moeten werken Test map maken waarin alle items getest kunnen worden Ondersteuning Teleporters in navigatie Translocator ondersteuning Andere spelmode dan CTF, VCTF, TDM, DM ondersteuning Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs
Status
MUST 4 In eerste instantie lijken alle percepts goed te werken. Alleen zijn alle items van het type en categorie [Other,Other], hier door kunnen de GOAL bots niet omgaan met de items. Dit probleem zat in Pogamut en er was tijdens deze fase een tijdelijke oplossing, maar Peter heeft samen met Rien gezocht naar een mooiere oplossing en er is besloten om in fase 2 daar mee verder te gaan.
SHOULD 4 De translocator is niet ondersteund in UT2004 en we dachten in eerste instantie dat het wel mogelijk moest zijn om dit te implementeren voor UT3. Na overleg met Rien vertelde hij ons dat de runner die de bots bestuurd in Pogamut niet om kan gaan met translocators en is er voor gekozen de ondersteuning te laten vallen.
WONT 1 Andere game modes vergen extreem complexe AI en er is besloten dat dit buiten de scope ligt van ons project.
MUST 8 Aangezien de code nog niet goed kan draaien zijn de performance tests opgeschoven totdat we een minimaal product hebben.
MUST 9 Er was nog geen computer beschikbaar op de Drebbelweg om te testen. Bart zou een computer op de 12e verdieping van EWI zetten voor ons om op te testen.
26
4.3.2 SCRUM 2 In deze fase is Peter verder gegaan met het oplossen van het ItemType probleem, Michiel heeft tests gemaakt voor de acties die de bot moet uitvoeren. Peter heeft ook de TestSuite gemaakt voor alle percept tests. Categorie MUST MUST MUST COULD COULD COULD MUST SHOULD SHOULD
MOSCOW 4 8 9 2 3 4 10 6 5
Omschrijving Percepts van de items moeten goed binnen komen Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs VCTF, DM, TDM ondersteuning Ondersteuning van voertuigen Voertuig specifieke acties Integratie tests GOAL environment Minelayer/Deployables ondersteuning Visueel verschillende teams
Status
COULD 2 Door gebrek aan tijd is er voor gekozen om de Vehicle Capture The Flag niet te ondersteunen.
COULD 3 Omdat VCTF niet langer wordt ondersteund is deze feature ook komen te vervallen.
COULD 4 Omdat VCTF niet langer wordt ondersteund is deze feature ook komen te vervallen.
SHOULD 6 Primitieve ondersteuning is gehaald in deze fase. Rien en Koen wilden graag dat de deployables op dezelfde manier behandeld moeten worden door de bots als door menselijke spelers. De bot kan namelijk gewoon switchen naar een wapen wanneer hij een deployable vast heeft. Menselijke spelers kunnen dit niet. Deze ondersteuning is opgeschoven naar fase 3.
SHOULD 5 Team kleuren werken. Het wisselen van teams werkt in de visualizer, alleen is er nog geen lijst met Skin namen gemaakt. Aangezien de kleuren werken is het zoeken naar skins opgeschoven naar fase 4.
4.3.3 SCRUM 3 In deze fase was het de bedoeling om drie mappen te kiezen waarop de bots konden spelen. Tijdens het testen liepen we tegen navigatie problemen aan waardoor nog niet alle mappen werken. Tevens overlapte deze fase met de tentamen periode. Peter heeft wel het SlowField wapen geïmplementeerd. Categorie SHOULD MUST MUST MUST MUST COULD
MOSCOW 6 8 9 10 1 5
Omschrijving Minelayer/Deployables ondersteuning Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs Integratie tests GOAL environment Ondersteuning drie verschillende maps Slowfield ondersteuning
Status
27
MUST 1 Na testen op verschillende mappen werd al snel duidelijk dat de navigatie van de bot niet goed was. Deze bug was niet aan het licht gekomen in onze test map. Dit kwam omdat er geen vreemde paden in zaten zoals 'flying' of 'proscribed' paths. De bot zag alle paden als gelijk en nam onmogelijke paden. Het probleem komt uit het feit dat Unreal Engine 3 met ReachSpecs werkt op paden, terwijl Unreal Engine 2 met FLAGS werkte. Er is besloten om de ReachSpecs om te bouwen naar de oude FLAGS zodat Pogamut niet aangepast hoeft te worden.
4.3.4 SCRUM 4 In deze fase hebben we het probleem met navigatie opgelost en zijn er nog meer tests geschreven. Tevens is er in deze fase voortgang geboekt met het werkend krijgen van de visualizer functies. Categorie MUST MUST MUST MUST SHOULD
MOSCOW 1 8 9 10 1
Omschrijving Ondersteuning drie verschillende maps Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs Integratie tests GOAL environment Visualizer ondersteuning voor spawnen en map weergave
Status
SHOULD 1 De visualizer kan wapens spawnen en vehicles. Het probleem in UT3 is dat je geen wapens direct neer kan leggen, maar ze zitten verscholen in een UTDroppedPickup Actor. Deze Actor is wel te plaatsen met daarin een Weapon. Zelfde soort problemen zijn er voor de deployables en ammo. Respawn werkt ook nog niet voor de agents. Change Team werkt wel.
4.3.5 SCRUM 5 In deze fase hebben we voornamelijk onze code terug verhuisd naar de Pogamut servers. Het Pogamut team heeft onze patches geaccepteerd en wij hebben er voor gezorgd dat dit ook op de server is verwerkt. Categorie MUST MUST MUST SHOULD COULD
MOSCOW 8 9 10 1 2
Omschrijving Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs Integratie tests GOAL environment Visualizer ondersteuning voor spawnen en map weergave DM, TDM ondersteuning
Status
SHOULD 1 De visualizer kan wapens, ammo, deployables, powerups, armor en vehicles spawnen. Tevens kan de visualizer nu ook ammo geven aan een bot. De rest geven is nog in ontwikkeling.
COULD 2 Na overleg met Koen is er besloten om de Deathmatch en Team Deathmatch weer te ondersteunen aangezien ze dezelfde functionaliteiten nodig hebben als voor Capture the Flag.
28
4.3.6 SCRUM 6 In deze fase hebben we de visualizer uitgebreid en opnieuw getest op de Drebbelweg. Categorie MUST MUST MUST SHOULD MUST
MOSCOW 8 9 10 1 3
Omschrijving Performance moet gelijk of beter zijn aan UT2004 Testen op Drebbelweg PCs Integratie tests GOAL environment Visualizer ondersteuning voor spawnen en map weergave Minimaal UT2004 mogelijkheden
Status
SHOULD 1 De Visualizer ondersteunt nu alle functies die we willen.
MUST 3 Alle UT2004 mogelijkheden, behalve de Shock Combo van de Shock Rifle zitten nu in UT3.
29
5. TESTEN Omdat er op drie verschillende niveaus gewerkt wordt in dit project is het noodzakelijk om een goed test framework op te zetten voor dit project. Fouten die optreden in de onderste laag kunnen er voor zorgen dat tests in de bovenste laag niet werken, helaas weet je dan nog niet waar je moet zoeken. Wij hebben verschillende strategieën gebruikt voor het testen van elk framework. In dit hoofdstuk wordt behandeld welke testen zijn opgezet, hoeveel en waarom wij hiervoor hebben gekozen.
5.1
TESTEN VAN GAME BOTS
Zoals in hoofdstuk 2 is besproken is het lastig om GameBots te testen. Dit komt omdat GameBots ontwikkeld is met behulp van UnrealScript. Deze taal is een scriptaal die in de Unreal Development Kit omgeving draait; waarin het niet mogelijk is om unit tests te draaien. Dit betekent dat we op een andere manier tests moeten gaan schrijven. De output kan eenvoudig gelogd worden door de UDK en er bestaat ook een mogelijkheid om met Telnet 4 commando's te sturen naar GameBots zodat het ook mogelijk is om zonder Pogamut, GameBots te testen. De meest triviale manier om te testen is om een kale bot te schrijven die enkel inlogt op de server. Tijdens dit proces heeft GameBots al een grote hoeveelheid informatie verstuurd over de map zoals de locatie van de vlag, wapens, ammo, health etc. waardoor deze informatie door Pogamut vertaald is naar sensor modules in de WorldAdapter (zie hoofdstuk 3). Deze informatie is met behulp van unit tests te controleren. We gaan er hier bij van uit dat Pogamut de informatie correct vertaald; zonder deze aanname is het erg lastig om de tests te automatiseren omdat we dan zelf een parser moeten schrijven die het GameBots protocol verstaat. De tests voor dit project zijn geschreven in Java en voeren acties van de bot uit, vervolgens wordt er gecontroleerd wat het resultaat is. Er is een test-interface geschreven die automatisch inlogt op de server en er voor zorgt dat de acties van de bot niet langer mogen duren dan een ingestelde tijd. De GameBots tests zijn opgedeeld in de volgende categorieën.
4
Telnet - command line tool voor het versturen van plain tekst over een TCP/IP verbinding 30
# 1
Ammo Test
Test
2
Switch Weapon Test
3
Initial Ammo Test
4
Self Test
1
Spawn Ammo Tests
2
Spawn Inventory Test
Omschrijving De bot spawnt in het rode team naast de vlag en loopt naar de weaponlocker. Zodra de bot de wapens heeft opgepakt worden voor alle wapens de hoeveelheid ammo gecontroleerd. De bot spawnt in het rode team naast de vlag en loopt naar de weaponlocker. Zodra de bot de wapens heeft opgepakt zal de bot één voor één wisselen van wapen tot dat alle wapens zijn geweest. Na elke wissel controleerd de bot of zijn huidge wapen daadwerkelijk het gewenste wapen is. De bot spawnt in het rode team naast de vlag en loopt naar alle weapon pickups in de map en controleert dan opnieuw de hoeveelheid ammo zoals in test 1. De bot spawnt in het rode team en controleert informatie over de bot zelf zoals zichtbare navpoints, health, armor en de score. Ammo van verschillende wapens wordt gespawnt in de map en gecontroleerd of het aanwezig is in de map. Diverse ammo en wapens worden in de inventory van de bot gezet via de controlconnection. Vervolgens wordt er gecontroleerd of dit daadwerkelijk aanwezig is.
TABEL 4 - GAMEBOTS TESTS
Een eenvoudige test zoals de 'Ammo Test' zegt al veel over de werking van GameBots. Dat komt omdat het oppakken van wapens aan het bericht 'AIN' (AddInventoryMsg) uit GameBots is gekoppeld. Dit bericht bevat zes parameters en kan dus ook op zes plekken foute informatie bevatten. Hoe weten we nou precies wat er fout is als er een test faalt? Deze informatie wordt uit de log van GameBots gehaald; hierin staat alle informatie die is opgestuurd naar de client en daardoor kunnen wij precies uitzoeken wat er is opgestuurd en waar het fout gaat. De 'Switch Weapon Test' wisselt elk wapen van de bot. Hier zijn ook weer diverse GameBots berichten en commando's aan gekoppeld, namelijk het 'ChangeWeapon' commando en de 'SLF' (SelfMessage) bericht. Op dezelfde manier als bij de 'Ammotest' wordt er gecontroleerd of GameBots de juiste informatie opstuurt. De 'Initial Ammo Test' doet hetzelfde als test 1, maar pakt de wapens één voor één op uit de map en controleert of de hoeveelheid ammo klopt. Dit is belangrijk omdat het verschilt hoeveel ammo een bot van een wapen uit een weaponlocker krijgt, en hoeveel ammo de bot krijgt van een normale pickup. De 'Self Test' controleert informatie zoals zichtbare navpoints, health, armor en de score. Hier zitten ook tests bij die bijvoorbeeld een respawn actie uitvoeren, waardoor de bot dood gaat en één punt moet verliezen.
5.2
TESTEN VAN POGAMUT
Het Pogamut platform zit zorgvuldig in elkaar en bevat ook een groot scala aan integratie tests. Deze tests bestaan vooral uit navigatie tests waarbij de bot in een map wordt geplaatst en er wordt gecontroleerd of de bot bij elke navpoint kan komen. Deze zijn omgezet in tests op een UT3 map waarin de bot naar een aantal punten in de map loopt en controleert of zijn doel is bereikt. De Pogamut omgeving bevat een dermate hoeveelheid tests dat het niet nodig is om dit uit te breiden. De aanpassingen die gemaakt zijn aan het Pogamut platform zorgen namelijk niet voor een extra functionaliteit maar verbeteren de kwaliteit van de code. Daarom kunnen wij volstaan met de bestaande tests die zijn ontwikkeld voor het platform.
31
5.3
GOAL ENVIRONMENT
De GOAL environment is het eindproduct en moet robuust en stabiel zijn, omdat het gebruikt gaat worden door honderden studenten. GOAL zorgt er voor dat Java objecten worden vertaald naar GOAL en omgekeerd. Deze vertaling kan goed getest worden met een set van integratietests. Door de bot een simpele actie te laten doen (zoals het oppakken van een wapen) kan er vervolgens gecontroleerd worden of er een update wordt verstuurd van de inventory. Deze update houdt in dat GOAL een weapon percept binnen krijgt. Deze tests komen overeen met de tests uit GameBots en daarom zullen die ook gebruikt gaan worden voor de environment. Een verschil is dat de tests aangepast zijn om ook te controleren of de percepts die opgestuurd worden kloppen. De volgende tests zijn uitgevoerd voor de environment # 1
Self percepts
Test
2
Switch Weapon Test
3
Initial Ammo Test
4
Self Test
5
See percepts
Omschrijving De bot spawnt in het rode team naast de vlag en loopt naar de weaponlocker. Zodra de bot de wapens heeft opgepakt worden voor alle wapens de hoeveelheid ammo gecontroleerd. De bot spawnt in het rode team naast de vlag en loopt naar de weaponlocker. Zodra de bot de wapens heeft opgepakt zal de bot één voor één wisselen van wapen tot dat alle wapens zijn geweest. Na elke wissel controleert de bot of zijn huidige wapen daadwerkelijk het gewenste wapen is. De bot spawnt in het rode team naast de vlag en loopt naar alle weapon pickups in de map en controleert dan opnieuw de hoeveelheid ammo zoals in test 1. De bot spawnt in het rode team en controleert informatie over de bot zelf zoals zichtbare navpoints, health, armor en de score. alles wat de bot kan zien zoals wapens en spelers
6
Map percepts
items in de map zoals wapens, ammo en armor
7
Navigatie
simpele navigatie tests zoals het navigeren naar een pickup
TABEL 5 - ENVIRONMENT TESTS
De wat meer complexere taken zijn moeilijk op te nemen in de integratie tests, omdat de tests dan al snel erg groot worden en dus op veel punten kunnen falen. De tests voor de environment omvatten de percepts en de acties en controleren of deze goed worden uitgevoerd. De tests zijn niet ontworpen om complex gedrag te testen.
5.4
MAP
Voor het testen is er een speciale map ontwikkeld waarin alle items liggen die we willen ondersteunen volgens ons MoSCoW model. Deze map heeft ook speciale nav points voor navigatie tests, zoals een navpoint waar geen pad naar gepland kan worden en een nav point die midden in de lucht hangt, waar dus wel een pad naar gepland kan worden, maar uiteindelijk een stuck percept geeft. Omdat dit 100% van de tijd gebeurt kunnen we stabiel testen. Ook liggen alle wapens, items, armor en powerups in deze map en is de ruimte klein waardoor eenvoudige tests snel uit te voeren zijn. Deze map is ook ideaal voor de studenten uit het practicum van Multi Agent Systemen, de projectgroepjes kunnen in deze map de basisfunctionaliteit van een bot snel testen.
32
De map is ontworpen om alle percepts te testen die de bot kan ontvangen. Naast percepts zijn er ook verschillende mogelijkheden om navigatie te testen. Zo zijn er navpoints aanwezig waar geen pad naar is, een navpoint waar wel een pad naar is, maar de bots nooit kunnen komen, paden via teleports en jump pads. De map is niet geschikt voor het testen van complexe strategieën, mede door zijn kleine omvang.
AFBEELDING 7 - OVERZICHT VAN DE TESTMAP
33
6. RESULTAAT In dit hoofdstuk zijn de resultaten van dit project samengevat en vergeleken met de eisen die gesteld zijn in het MoSCoW model. In de SCRUM log die te vinden is in appendix A staan de details van de veranderingen aan GameBots. Tot slot worden een aantal problemen behandeld en een aanbeveling gegeven voor de voortzetting van dit project.
6.1
GAMEBOTSUT3
Voordat dit project begon was er al een eerste versie van GameBots. Deze versie bevatte veel bugs en was enkel bedoeld voor de game mode Deathmatch. Tijdens de ontwikkeling van GameBotsUT3 is er veel gekeken naar GameBotsUT2004. De versie voor UT2004 is compleet en werkt goed. Het verschil is dat GameBotsUT2004 op de Unreal Engine 2.5 draait en GameBotsUT3 op de Unreal Engine 3. Dit zorgt wel voor een aantal veranderingen maar de basis van de mod blijft hetzelfde.
AFBEELDING 8- GAMEBOTSUT3 OUTPUT
GameBotsUT3 is zo uitgebreid dat het nu zonder aanpassingen draait op het Pogamut framework. Er is ondersteuning voor de speltypes Deathmathch, Team Deathmatch en Capture The Flag (CTF) en ook de specifieke UT3 items en wapens worden ondersteund. De belangrijke verbetering aan de control connection van GameBots zijn als volgt.
34
# 1. 2.
Functie Deployables ITC messages
3.
Powerups
4. 5.
Weapon Locker Flag Info
6.
Melee wapens
Omschrijving Alle deployable wapens worden herkend en opgestuurd door GameBots. ITC (ItemCategory) messages zorgen er voor dat er extra informatie over een wapen wordt verstuurd naar de client. Dit zijn gegevens zoals: "Is dit een sniper?", "Is dit wapen handig voor korte afstanden?", etc. Alle verschillende soorten powerups worden herkend en worden doorgestuurd naar de cliënt. De weaponlocker wordt ook ondersteund in GameBotsUT3. De bot weet nu ook waar in de map de vlag gevonden kan worden. Dit is nodig voor CTF en Team-CTF ondersteuning. Er is nu ook ondersteuning vanuit GameBots voor melee wapens. Dit zijn wapens die zonder ammo te gebruiken zijn zoals een impact hammer.
TABEL 6 - BELANGRIJKSTE TOEVOEGINGEN AAN DE BOT CONECTION
De belangrijkste veranderingen aan de control connection hebben vooral invloed op de visualizer en het test framework. Dit komt omdat het test framework gebruikt maakt van de control connection om de bot bijvoorbeeld ammo en wapens te geven om snel en precies een simpele test uit te kunnen voeren. # 1.
Commando Teleport
2. 3.
Map wissel Inventory
4.
Pauze/Resume
5. 6.
Powerups Respawn
Omschrijving TELEPORT commando is toegevoegd aan GameBotsUT3 om een bot op een willekeurige, andere plek in de map neer te zetten. GameBotsUT3 kan nu naar elke willekeurige CTF map wisselen. De control connectie kan elk willekeurig wapen of ammo in de inventory van de bot plaatsen. Het is nu mogelijk de server te pauzeren maar het is ook mogelijk om alleen de agent op pauze te zetten. Powerups kunnen nu ook op willekeurige plekken in de map worden geplaatst. De bot kan nu respawnen vanuit de control connection.
TABEL 7 - BELANGRIJKSTE TOEVINGEN AAN DE CONTROL CONNECTION
Veel van de code in GameBotsUT3 bevatte geen comments. Daarnaast bleek dat de vorige programmeur niet wist waar de code voor diende, of hoe hij of zij het moest aanpassen voor gebruik met UT3. We hebben de code voorzien van comments en uitgezocht wat alles doet, dit moet het voor de volgende programmeur makkelijker maken om de code aan te passen.
6.2
POGAMUT
Zoals beschreven is in hoofdstuk 3 is er ook gekeken naar het Pogamut framework. Pogamut is ontwikkeld aan de Charles University in Praag en wordt al een paar jaar gebruikt voor de Computer Science studenten. Het platform zit goed in elkaar en is erg robuust. Wij hebben er voor gekozen om ook aanpassingen te maken aan het platform. Zoals beschreven is in hoofdstuk 3.3.3 hebben wij dit voornamelijk gedaan om duplicate code te vermijden. Uiteindelijk zijn onze verbeteringen doorgevoerd in een branch op de SVN van Pogamut en wordt het in de volgende release van Pogamut meegenomen. Door de aanpassingen die wij hebben gedaan is het nu mogelijk om UT3 en UT2004 te gebruiken op hetzelfde framework. De code reusability is hier door enorm toegenomen, dit is goed te zien aan het originele UT3 project op de Pogamut SVN. Dit project bestond uit een bot voor UT3 geschreven in Java met behulp van Pogamut. Door de verbeteringen aan het Pogamut framework is de code van dit project met meer dan 50% afgenomen en is de functionaliteit hetzelfde gebleven. Door deze verbeteringen is het ook eenvoudiger geworden om toekomstige versies van Unreal Tournament te ondersteunen.
35
6.3
UT3 GOAL ENVIRONMENT EN DE VISUALIZER
Het belangrijkste onderdeel van dit project was de UT3 GOAL Environment. Deze environment gaat gebruikt worden bij het practicum van het vak Multi-Agent Systemen. Alle must-have en should-have requirements zijn gehaald en er is ook een goed werkend bot-team geschreven. De environment gaat ook ingezet worden bij het practicum van het vak Multi-Agent Systemen. De manual is te downloaden van http://ii.tudelft.nl/trac/goal/wiki/Projects/UT3 evenals de installer voor de environment. De oude UT2004 bots kunnen draaien op zowel de UT2004 omgeving als de UT3 omgeving. De volgende percepts zijn toegevoegd aan de UT3 omgeving. # 1
2
3
Percept Armor
Omschrijving armor(
, , , <Shieldbelt>)
Powerup
- Armor rating van de helmet. - Armor rating van het vest. - Armor rating van de thighpad. <Shieldbelt> - Armor rating van de shieldbelt. powerup(, )
slowVolume
- None, udamage, berserk of invulnerability. <Time> - Duur van de powerup in secondes afgerond op twee decimalen. slowVolume([]) [] - Een lijst met alle UnrealID's die in het slow volume liggen.
TABEL 8 - NIEUWE PERCEPTS IN DE UT3 OMGEVING
De volgende acties zijn toegevoegd aan de environment. # 1 2
Actie Deploy Chat
Omschrijving De deploy actie zorgt er voor dat de bot een veld neer kan leggen als deze opgepakt wordt. chat(<Scope>,<Message>) Verstuurd het bericht <Message> naar de console, werkt alleen voor UT2004.
6.3.1 WON'T FIX PROBLEMEN Er zijn tijdens het ontwikkelen van de omgeving een aantal belangrijke keuzes gemaakt. Er zijn een aantal problemen waarvoor niet genoeg tijd was om ze op te lossen of achteraf gezien erg onpraktisch waren. De ondersteuning voor de hoverboard is niet geïmplementeerd, omdat de game mode Vehicle Capture The Flag niet wordt ondersteund. De hoverboard wordt alleen gebruikt in deze mode, om spelers die te voet zijn niet een al te groot nadeel te geven. Met de hoverboard kun je sneller over de map bewegen en ook achter voertuigen hangen. Het besturen van en navigeren met voertuigen is erg complex, voornamelijk omdat GameBots geen obstakel ontwijking heeft. Dit resulteert in dat de bots overal tegen aan rijden met de voertuigen. In UT3 komen ook zogenaamde 'Jump Boots' voor. Dit item zorgt er voor dat een bot extra hoog kan springen en op moeilijk plekken kan uitkomen. De timing van deze jumps is erg belangrijk omdat er precies vanaf de goede plek gesprongen moet worden. Pogamut stuurt alle berichten in batches op om de 200 ms, doordat GameBots veel berichten naar veel verschillende bots moet sturen kan de latency dus al gauw meer worden waardoor een perfecte sprong niet gemaakt kan worden.
36
6.4
AANBEVELINGEN
Het project is tot zover afgerond dat alle must-have en should-have functionaliteit is afgerond. Er staan echter nog steeds features open die geïmplementeerd kunnen worden om het systeem te verbeteren. Deze verbeteringen worden in deze paragraaf behandeld. Er is veel tijd besteed aan GameBotsUT3 voor dit project, dit komt omdat GameBotsUT3 de onderste laag vormt van dit project en de originele versie erg slecht in elkaar zat. GameBotsUT3 is nog niet helemaal afgerond en staat nog open voor een aantal verbeteringen zoals ondersteuning voor de observer connection (behandeld in hoofdstuk 3.2.1). Het is lastig om UnrealScript te debuggen en te testen, daarom is foutopsporing een tijdrovende taak in dit project. Er wordt vanuit Praag nog steeds doorgewerkt aan Pogamut. Dit zijn projecten die gebaseerd zijn op de Unreal Development Kit (UDK) waar Pogamut uitkomst biedt als Java middleware. Omdat Pogamut van oorsprong alleen ontwikkeld is voor UT2004, zijn er vaak nog roots terug te vinden naar UT2004 en moet er code herschreven worden om gebruikt te kunnen worden voor andere games. Voor UT3 is inmiddels een stap gezet naar de unificatie van Pogamut. Vanuit Praag wordt er op lange termijn aan gewerkt om dit nog meer te verbeteren. Een visuele upgrade van de visualizer met bijvoorbeeld JavaFX, zou veel strakker en professioneler overkomen. De visualizer moet ook op den duur net als Pogamut universeel worden voor alle UDK games. Het is onhandig dat de maps moeten worden aangepast aan de beperkingen van de bots. Dit zorgt er ook voor dat er een beperkt aantal maps is waarop de bots kunnen spelen. Een bot kan bijvoorbeeld niet goed wachten op een lift omdat de lift niet naar beneden komt als de bot er recht onder staat. Als we dit mogelijk willen maken dan zal er van elke lift in het spel, continue informatie gestuurd moeten worden naar de client. De bot moet namelijk weten of het de moeite waard is om te wachten op de lift of om een andere weg te kiezen. Wij hebben hier ons niet verder in verdiept omdat het eenvoudiger is, en waarschijnlijk ook voor een stuk sneller om de lifts in elke map aan te passen zodat de lift toch naar beneden komt ondanks eventuele bots die in de weg staan.
6.5
SOFTWARE IMPROVEMENT GROUP FEEDBACK
De feedback is terug te vinden in appendix B. In dit onderdeel zullen wij de feedback samenvatten en onze verbeteringen opsommen.
6.5.1 AANBEVELINGEN TUSSENTIJDSE EVALUATIE De code van ons systeem scoort volgens SIG bijna 5 sterren op het onderhoudbaarheidsmodel, dat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald op de volgende onderdelen.
Component Independence - er wordt gekeken naar de hoeveelheid code die alleen intern binnen een component wordt gebruikt, oftewel de hoeveelheid code die niet aangeroepen wordt vanuit andere componenten. Volgens de code evaluatie wordt de string "NearestEnemy" gebruikt in de file 'NearestEnemy.java' maar ook in de 'SelectorTranslator.java'. Deze componenten zijn niet expliciet onafhankelijk en zorgen volgens SIG er voor dat er eerder inconsistentie optreedt bij het doorvoeren van toekomstige wijzigingen. Echter zijn deze onderdelen expres niet explicitiet gemaakt omdat het in de file 'NearestEnemy.java' over de string-representatie van de klasse gaat en in de 'SelectorTranslator.java' over de vertaling van een GOAL parameter naar een Java klasse.
37
Unit size - een aantal functies zijn bovengemiddeld lang. Het gaat hier voornamelijk om de 'logic'methode in de 'UT3BotBehavior'-klasse. Deze functie is het hart van de environment en is al redelijk opgesplitst. Verder opsplitsen van deze methode geeft naar onze mening minder overzicht en structuur. Unit complexity - er wordt gekeken naar de complexiteit van een functie (het aantal beslispunten). In het geval van de test-cases moeten deze niet te complex zijn. De 'StopTests'-klasse heeft 13 beslispunten en kan dus op veel punten falen. Hier moet opnieuw naar gekeken worden om deze test op te splitsen in kleinere en eenvoudigere tests.
6.5.2 VERBETERINGEN Zoals aangegeven in de vorige paragraaf hebben wij geen veranderingen aangebracht in de component independence en de unit size. Aan de unit complexity is wel wat te doen. Te grote unit tests kunnen snel complex worden en zijn niet betrouwbaar omdat er te veel beslispunten zijn. Hier is wat aan gedaan en de tests zijn kleiner geworden en het aantal tests is ook toegenomen. 6.5.3 FEEDBACK UITEINDELIJKE PRODUCT De tweede feedback van de Software Improvement Group kijkt voornamelijk of het advies van de eerste feedback is meegenomen in het eindresultaat. Het commentaar van Eric Bouwers: " In de tweede upload zien we dat de omvang van het systeem is gestegen, maar dat daarbij de score voor onderhoudbaarheid licht is gedaald. We zien dat de score voor Component Independence vrijwel gelijk is gebleven, de impliciete connecties zijn dan ook nog steeds aanwezig. Voor Unit Size zien we dat de nieuwe methodes binnen het systeem over het algemeen kleiner zijn, maar dat de langere methodes die al bestonden niet zijn aangepast. Dit heeft er toe geleid dat de Unit Complexity score licht is gedaald. Qua test-code zien we in kleine stijging in volume, maar ook een stijging in het aantal complexere test-methoden" Zoals te verwachten komen dezelfde resultaten uit de component independence en de unit size omdat wij hier geen aanpassingen in hebben gemaakt. Er is wel werk gemaakt van de test-methoden om de unit complexity score te verbeteren. Volgens de feedback zijn er nog steeds methoden die te complex zijn, er wordt niet gezegd welke methoden. Wij denken dat dit waarschijnlijk om tests gaat waar de bot bijvoorbeeld naar een paar specifieke navpoints moet lopen. Dit is een goede test en kan soms niet opgesplitst worden omdat de bot deze opdrachten sequentieel moet uitvoeren.
7. CONCLUSIE Bij het begin van dit project hebben wij vastgesteld dat het erg belangrijk is om een robuust systeem te maken. Dit betekent dat het door honderden studenten vrij eenvoudig gebruikt kan worden. Het is in onze ogen gelukt een systeem neer te zetten dat het onderwijs zal bevorderen op het gebied van Artificial Intelligence. Aan het begin van dit project hebben wij een onderschatting gemaakt van de tijdsbesteding aan diverse onderdelen van dit project. Dit heeft er voor gezorgd dat wij niet alles hebben kunnen implementeren wat wij graag hadden willen zien. Wij hebben een grote bijdrage geleverd aan GameBots door alle missende onderdelen uit de control connection en de bot connection te implementeren. Daarnaast heeft het Pogamut team een stap heeft kunnen zetten naar de unificatie van het platform voor de Unreal games door onze input. Door de problemen in de oorsprong aan te pakken hebben wij verder gekeken dan de eenvoudige oplossing en er voor gezorgd dat Pogamut verder kan werken met de software die wij hebben gemaakt.
38
Een van de redenen om over te stappen naar UT3 was omdat het er moderner en mooier uitziet. Een goed idee om dat moderne gevoel te versterken is om de omliggende visuele componenten ook een moderne look te geven. Parallel aan ons project is er ook gewerkt aan een Eclipse plugin voor GOAL wat het werken in GOAL ook een modernere look en feel geeft. Dit laat de visualizer nog achter, studenten vinden het prettig om met nieuwe dingen bezig te zijn, vooral op een universiteit. Alle componenten zouden dit moeten uitstralen.
39
REFERENTIES Charles University. (n.d.). Pogamut GameBots. Retrieved February 6, 2014, from Pogamut: http://Pogamut.cuni.cz/main/tiki-index.php?page=GameBots Epic Games. (2008). Unreal Engine. Retrieved 2013, from Unreal Engine: http://www.unrealengine.com/ Epic Games. (2009). Unreal Development Kit. Retrieved 2013, from Unreal Engine: http://www.unrealengine.com/en/udk/ Guice. (2008). Guice. Retrieved 2014, from Guice: https://code.google.com/p/google-guice/ J. Gemrot, C. Brom, R. Kadlec, M. Bída, O. Burkert. (2009). Pogamut 3 – Virtual Humans Made Simple. Retrieved 2014, from Pogamut: http://Pogamut.cuni.cz/main/papers/Pogamut_-_Book_chapter.pdf JFlex. (2009). JFlex. Retrieved 2014, from JFlex: http://jflex.de/ K. V. Hindriks, B. v. (2011). Unreal Goal Bots - Conceptual Design of a Reusable Interface. Delft: TU Delft. K.V. Hindriks, F.S. de Boer, W. van der Hoek, J.-J.Ch. Meyer. (2002). Agent Programming with Declarative Goals. K.V. Hindriks, T. M. Behrens, W. Pasman . (2013). EIS. Retrieved 2014, from EIS: http://sourceforge.net/projects/apleis/ M. Bída, M. Cerny, J.Gemrot, C. Brom. (2012). Evolution of GameBots project. Retrieved from Pogamut: http://artemis.ms.mff.cuni.cz/main/papers/Evolution_Of_GameBots-2012-07-03_camera.pdf Pixel Mine. (2011). nFringe. Retrieved from http://pixelminegames.com/nfringe/ T.M. Behrens, J. Dix, K.V. Hindriks. (2009). Towards an Environment Interface Standard for Agent-Oriented Programming.
40
APPENDIX A - SIG Feedback eerste ronde: Hierbij ontvang je mijn evaluatie van de door jou opgestuurde code. De evaluatie bevat een aantal aanbevelingen die meegenomen kunnen worden in de laatste fase van het project. Deze evaluatie heeft als doel om studenten bewuster te maken van de onderhoudbaarheid van hun code en dient niet gebruikt te worden voor andere doeleinden. Mochten er nog vragen of opmerkingen zijn dan hoor ik dat graag. Met vriendelijke groet, Eric Bouwers [Aanbevelingen] De code van het systeem scoort bijna 5 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Component Independence, Unit Size en Unit Complexity. Voor Component Independence wordt er gekeken naar de hoeveelheid code die alleen intern binnen een component wordt gebruikt, oftewel de hoeveelheid code die niet aangeroepen wordt vanuit andere componenten. Hoe hoger het percentage code welke vanuit andere componenten wordt aangeroepen, des te groter de kans dat aanpassingen in een component propageren naar andere componenten, wat invloed kan hebben op toekomstige productiviteit. In dit geval valt met name op dat er een aantal connecties impliciet zijn doordat er op verschillende plekken dezelfde constante waarde gebruikt wordt. Een voorbeeld hiervan is de String "NearestEnemy", deze komt voor in zowel 'NearestEnemy.java' als in 'SelectorTranslator.java'. Het is aan te raden om deze impliciete afhankelijkheden expliciet te maken zodat het consistent doorvoeren van toekomstige wijzigingen makkelijker zal worden. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de 'logic'methode binnen de 'UT3BotBehavior'-class, zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld '// 1. The target that we may shoot at' en '// 5. Prepare new batch of percepts' zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Voor Unit Complexity wordt er gekeken naar het percentage code dat bovengemiddeld complex is. Ook hier geldt dat het opsplitsen van dit soort methodes in kleinere stukken ervoor zorgt dat elk onderdeel makkelijker te begrijpen, makkelijker te testen en daardoor eenvoudiger te onderhouden wordt. In dit geval komen de meest complexe methoden ook naar voren als de langste methoden, waardoor het oplossen van het eerste probleem ook dit probleem zal verhelpen. Wat nog wel opvalt is dat er complexe code aanwezig is binnen de test-code, de 'testDroppedPowerup'-methode binnen de 'StopTests'-class heeft bijvoorbeeld 13 beslispunten. Bij deze complexiteit is het altijd een vraag of de test het juiste gedrag test, de test kan immers ook een fout bevatten. Het is aan te raden om deze complexe tests kritisch te bekijken en de complexiteit van de nieuwe tests zo laag mogelijk te houden. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de test code ook groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt.
Feedback hermeting: In de tweede upload zien we dat de omvang van het systeem is gestegen, maar dat daarbij de score voor onderhoudbaarheid licht is gedaald. We zien dat de score voor Component Independence vrijwel gelijk is gebleven, de impliciete connecties zijn dan ook nog steeds aanwezig. Voor Unit Size zien we dat de nieuwe methodes binnen het systeem over het algemeen kleiner zijn, maar dat de langere methodes die al bestonden niet zijn aangepast. Dit heeft er toe geleid dat de Unit Complexity score licht is gedaald. Qua test-code zien we in kleine stijging in volume, maar ook een stijging in het aantal complexere test-methoden.
41
Uit deze observaties kunnen we concluderen dat de aanbevelingen van de vorige evaluatie niet zijn meegenomen in het ontwikkeltraject. Het is wel goed om te zien dat een stijging in het volume van de productie-code ook nog steeds een stijging in het volume van de test-code te zien is.
42
