Freie Universitat BerlinDepartment of Mathematics and Computer Science

Diploma Thesis

Mechs And TanksA Multiplatform RTS Game with Machine Learning AI

Author:Behsaad Ramez

Advisors:Prof. Dr. Raul RojasDipl.-Inf. Miao Wang

October 11, 2011

Declaration of Academic Honesty

I hereby confirm that my diploma thesis was independently authored bymyself, using solely the referred sources and support.I also assert that this thesis has not been part of another examination process.

Berlin,Date Signature (Behsaad Ramez)

I

Abstract

The majority of AI components in video games are still heavily relying onstatic methods like finite state machines or goal-driven agent behaviour. Al-though these techniques will probably still prevail in the future of the in-dustry, dynamic, adapting, machine learning techniques can offer many im-provements and interesting game design options to game developers.

Static techniques have the advantage that they are often intuitive to use andeasier to debug, whereas dynamic methods can be used to reveal or coverAI and game design weaknesses and adapt to the player’s individual playingstyle.

These positive factors outweigh their implementation effort in games wherethe AI has a major impact on the player’s experience and fun.Traditionally AI and unit balance in real time strategy (RTS) games is muchmore important than in other genres. Even mediocre, antiquated graphics inAAA industry titles like Starcraft

TMcan be forgiven if these components are

well implemented.

The recent boom of portable devices and smartphones that have the hard-ware requirements for complex real time 3D applications has also opened newgame design and business possibilities for casual game developers on mobileplatforms.

In this paper I will describe the development of my own mulitplatform RTSgame and an implementation of an online machine learning technique for thisspecific game.

II

Uberblick

Der Großteil der KI-Komponenten in modernen Videospielen basiert nochimmer auf bewahrten statischen Techniken wie Zustandsautomaten und zielges-teuertem Agentenverhalten. Obwohl diese Methoden wahrscheinlich auch inZukunft die Spieleindustrie dominieren werden, bieten dynamische, adaptive,machinelle Lernverfahren Entwicklern neue Moglichkeiten, Verbesserungenund Design-Optionen.

Statische Verfahren haben den Vorteil, dass sie oft intuitiver einzusetzen undbesser zu warten sind als dynamische, die dazu verwendet werden konnenDesign-Schwachen zu offenbaren oder sich an die Fahigkeiten des Spielersanzupassen.

Der zusatzliche Aufwand zur Verwendung dieser Verfahren lohnt sich beson-ders in Spielen in denen die KI einen grossen Anteil an der Spielfahrung undam Spielspass hat.In Echtzeitstrategiespielen spielen KI und Ausgewogenheit der Einheiten tra-ditionell eine grossere Rolle als in anderen Genres. Selbst eine mittelmassigeoder veraltete grafische Prasentation kann durch eine gute Umsetzung dieserKomponenten verziehen werden.

Der aktuelle Erfolg von portablen Konsolen und modernen Smartphoneseroffnet besonders kleineren Entwicklerstudios neue Geschaftsmoglichkeiten.In dieser Arbeit werde ich die Entwicklung meines eigenen multiplattform(inklusive mobiler Version) Echtzeitstrategiespiels und die Implementierungeines online machinellen Lernverfahrens fur dieses Spiel beschreiben.

III

Acknowledgements

I have a passion for gaming since I first got my hands on Super Mario Landfor the classic Game Boy in the early 1990s. But even more than that I havealways had the drive to investigate the mechanics behind those games, playaround in editors and discuss the theory of fun.

My biggest dream was to publish my own games one day. I want to thankmy academic advisor Miao Wang and Professor Raul Rojas for supportingme and giving me the chance to do so in my final thesis. I also want to thankmy friends and family who have always been there for me.

A special thanks goes to Izzy, who always believed in me and gave me thestrength to pursue my dreams.

IV

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Game Design 32.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Mechs And Tanks . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Game Units . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Game Rules . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Balancing . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Architecture 83.1 Unity3D Engine . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Brief History of Unity3D . . . . . . . . . . . . . . . . . 103.2 Game Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Main Modules . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Unity Scene Setup . . . . . . . . . . . . . . . . . . . . 133.2.3 MVC Pattern . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Multiplatform Development . . . . . . . . . . . . . . . . . . . 163.3.1 The Abstract Factory Pattern . . . . . . . . . . . . . . 173.3.2 Input and Persistant Data . . . . . . . . . . . . . . . . 17

3.4 iOS+Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.1 Maximum Polygon Count . . . . . . . . . . . . . . . . 193.4.2 Draw Call Reduction and Lights . . . . . . . . . . . . . 193.4.3 Terrains . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.4 GUI-Optimization . . . . . . . . . . . . . . . . . . . . 233.4.5 Script-Optimizations . . . . . . . . . . . . . . . . . . . 23

4 AI 234.1 AI Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Layer 1 - Locomotion . . . . . . . . . . . . . . . . . . . . . . . 254.3 Layer 2 - Locomotion States . . . . . . . . . . . . . . . . . . . 254.4 Layer 3 - Steering Behaviours . . . . . . . . . . . . . . . . . . 27

4.4.1 List of Behaviours . . . . . . . . . . . . . . . . . . . . 304.5 Pathfinding and Obstacle Avoidance . . . . . . . . . . . . . . 344.6 Layer 4 - Unit AI . . . . . . . . . . . . . . . . . . . . . . . . . 374.7 Layer 5 - Group AI . . . . . . . . . . . . . . . . . . . . . . . . 37

V

5 Machine learning 395.1 Dynamic Scripting . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Dynamic Scripting for Mechs and Tanks . . . . . . . . . . . . 41

5.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 415.2.2 Fitness Function . . . . . . . . . . . . . . . . . . . . . 45

5.3 Performance Measuring . . . . . . . . . . . . . . . . . . . . . . 475.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Conclusions and Future Work 50

Bibliography 50

A Appendix 52A.1 Unity3D Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . 52

A.1.1 The Scene View . . . . . . . . . . . . . . . . . . . . . . 52A.1.2 The Inspector . . . . . . . . . . . . . . . . . . . . . . . 53A.1.3 The Project Panel . . . . . . . . . . . . . . . . . . . . 54A.1.4 The Game Window . . . . . . . . . . . . . . . . . . . . 55A.1.5 Walking Cube: A Unity Example . . . . . . . . . . . . 56

A.2 Source Code Listings . . . . . . . . . . . . . . . . . . . . . . . 61

VI

1 Introduction

Developing an RTS game is a challenging task, usually tackled by a team ofexperts. In order to create my own game I had to make some adjustmentsto the classical formula and pick the right technology.

1.1 Motivation

The real time strategy genre was established in the late 1980s by games likeHerzog Zwei

TMand Dune II

TM[5]. In classical real time strategy games play-

ers control units with the mouse from an isometric perspective and commandthem to gather resources, fight enemies or build buildings that can be usedto upgrade units or create new units. Although there are console ports offamous franchises like Starcraft

TMthe genre is at home on the PC [5] .

With the recent popularity of mobile gaming on multitouch smartphones andtablets there have been attempts to port the genre to these platforms. Thechallenge of creating an RTS game for these platforms is to adjust the UI andgame design to the capacities and limits of these systems. Typically systemslike the iPhone 4

TMhave a display size of about 3-4 inches. That makes it

hard for the player to control many units at once. Since the player cannotuse keyboard shortcuts and mouse controls on a smartphone it would be illadvised to create a fully featured classical RTS game on these systems.

I decided to make some adjustments to the game design and optimize myinterpretation of an RTS game for multitouch tablets and smartphones.

Another motivation I had for working on this subject was the idea of dy-namic, adaptive AI. A typical approach for creating the AI components inan RTS game is using finite statemachines. After some time players can spotand exploit weaknesses in the scripted behaviour and the game loses it’s ap-peal.

Adaptive game AI with online learning capabilities can help to keep thingsinteresting for the players by adjusting to the player’s behaviour and con-stantly learning new strategies. Another reason to use adaptive game AI isto make sure there are no dominant strategies in the game design that couldbe exploited by players in multiplayer matches. Balancing RTS games formultiplayer is one of the key factors for long lasting fun and success. A learn-ing AI system can reveal dominant units, strategies and races in a game.

The reason why most developers are still unwilling to use these techniques in

1

their games despite their advantages, are the difficulties to debug, maintainand predict the AI’s behaviour.

I used an adapted version of a technique called dynamic scripting for mygame’s machine learning architecture. I chose this approach over geneticalgorithms and neural networks because it achieves to meet all computa-tional and functional requirements that are necessary for adaptive AI to beapplicable in practice.

1.2 Game

My game is called Mechs And Tanks and it is playable on Mac, Web, Win-dows and iPad

TM. Android

TM, iPhone

TMand iPod Touch

TMversions are planned

in the future. You can try a demo and add comments on the official supportpage: http://www.mechsandtanks.com.

The game rules are quickly explained: Two players start a game on oppositesides of a quadratic map (see subfigure (a) below for an example map) thatis scattered with obstacles. Each player has three credits that he can use toselect his army by picking three unit groups. As illustrated in subfigure (b)below, each group consists of four units, resulting in twelve units per player.There are three different unit types that differ in their speed, damage andattack range.

(a) A map in the Unity edi-tor

(b) Game screenshot with labels

The primary goal of the game is to destroy the enemy player’s build-ings. If neither of the two players achieves to destroy all enemy’s buildings

2

in the given time the maximum number of points determines the winner.The number of destroyed enemy buildings and units determines the player’spoints.

1.3 Technology

The Unity Game Engine and C-Sharp scripting was used to program thegame [12]. The engine comes at a relatively low price and has a very intuitiveand well arranged editor. All game models, model textures and music werecustomly created for Mechs and Tanks.

2 Game Design

2.1 Prototype

Because Mechs and Tanks is a new game with new rules and conditions thegame design had to be tested before implementing the game in Unity3D.

The Starcraft II Map EditorTM

(see figure 1) was chosen for this purpose [13],[14]. The editor allows you to create a modification to the Starcraft II

TMgame

and play it with friends online. It features a scripting language called Galaxythat is based on C. Prior to the design of Mechs And Tanks I prototypedanother game in the editor and discarded the idea because it did not passsome design tests.

Figure 1: My prototype project in the Starcraft II Galaxy EditorTM

3

The next prototype was a first rough design of what would be later MechsAnd Tanks. The work on the Unity3D game began after approving the designby playing it with a friend online.

The modification is published as ’Mechs And Tanks Prototype’ and can beplayed and altered through the online gaming service called Battle.net

TM.

Figure 2: An in game view of the modification

2.2 Mechs And Tanks

This section will describe the game rules and design in detail.

2.2.1 Game Units

Each player can choose three groups of units with four units per group. Thereare three different unit types:

MechThe mech is a medium ranged medium fast unit with thefollowing statistics:

Height Mass Speed Health Range Damage Reload Time3 m 0.4 t 3.5m

s250 10 m 25 4 s

It is useful for offensive as well as defensive tactics. How-ever it is not as specialized in one of these like the runner

4

or the tank. The mech was the first unit that was added to the game andalthough a match with only mechs can be interesting, the other two unitsadd a lot of tactical variaty.

RunnerThe runner is a fast melee unit with the following statis-tics:

Height Mass Speed Health Range Damage Reload Time3.3 m 0.3 t 5m

s220 2 m 20 3 s

It is useful for fast and dynamic tactics. A group of run-ners cannot win a battle against a group of mechs or agroup of tanks. Runners should be used by experiencedplayers who can quickly react on enemy movements andsend them around enemy groups to attack unprotectedbuildings.

TankThe tank is a slow ranged unit with the following statis-tics:

Height Mass Speed Health Range Damage Reload Time1.5 m 1 t 2m

s300 20 m 45 6 s

A good way to use tanks is for defending a map spot ora base. Their health point advantage and big attack range make same thefirst choice for defensive players. Due to their slow movement speed tanksare vulnerable to certain tactics. A player who uses more than one groupof tanks should try to keep them constantly moving intelligently in order tomake it more difficult for his enemy to ambush him or take down buildingsone by one.

Here are all statistics in one table for better comparison:

5

Unit Type Height Mass Speed Health Range Damage Reload TimeMech 3 m 0.4 t 3.5m

s250 10 m 25 4 s

Runner 3.3 m 0.3 t 5ms

220 2 m 20 3 sTank 1.5 m 1 t 2m

s300 20 m 45 6 s

2.2.2 Game Rules

The game starts with two players on opposite sides of a map like in figure 3.Each player can now choose 3 unit groups with 4 units of a chosen type each.There is no time constraint for making the decision. The players can decideto wait for their opponent’s choice and make their unit choices accordinglyif they are willing to grant them a head start.

Figure 3: A top view of a map with marked spawn positions

The primary goal of the game is to destroy all the opponent’s buildingswith the selected units. There is also a time constraint to ensure a maximumgame length of four minutes. When the time has passed and neither of theplayers accomplished to destroy their opponent’s buildings the winner is de-termined in a different way. In this case the player with the most points winsthe game. Equal amount of points results in a draw. The points are simply

6

calculated by counting the number of destroyed enemy units and buildings.Each building is worth 60 points and each unit 10 points.

This relation of points makes it more appealing to players to focus on build-ings rather than on units and therefore manages to maintain the primarygoal throughout most matches.

The tactical depth of the game comes from the fact, that units have to bemaneuvered around mountains and obstacles on the map. The challenge isnow to respond to the enemy’s movements quickly and meet decisions on at-tacking or defending buildings in respect to the chosen unit’s strengths andweaknesses.

2.2.3 Balancing

In order to validate that there are no simple dominant tactics that wouldharm the game design the game was tested with many extreme tactics inmultiplayer. Among others, following strategies were tested:

• One unit type only:

It was checked if a player had an unfair advantage if the other playeronly chose units of one kind. Although tanks have an advantage indefending against other units and runners are the best choice for a quicksurprising playing style, we assured that the players strategic skills isdecisive for winning a game. To every tactic that was tested there isa counter tactic. The fact that a player can wait for his opponent topick his units before chosing his own, further reduces the probabilityof a single dominant strategy.

• Defending with tanks:

A possibly dominant strategy could be to defend the home base with 12tanks, since their strength lies in defending. After testing this techniqueand adjusting some unit values it was made sure that this strategy iseasy to counter. Because tanks are slow and buildings are relatively farapart (the typical map size is ca. 170x170 m) a player cannot defendall his buildings with a sufficient number of tanks. The opponent canjust pick runners or even mechs to outmaneuver the defenders. Thatmakes it possible to destroy at least n-1 buildings with relatively fewcasualties. Due to the time constraint the game is already won bysitting out the left time.

• Attacking with runners:

7

Another approach could be to use 12 runners in different groups to out-maneuver the enemy. The clever movement and positioning of mechsand tanks is an effective counter strategy, since runners have by far theshortest attack range and the lowest health.

3 Architecture

To better understand the game’s software architecture and object model itis useful to get a better look at the Unity3D Game Engine and editor andit’s key principles.

3.1 Unity3D Engine

Unity3D is an award winning tool for creating interactive 3D applicationson multiple platforms. Unity3D consists of a game engine and an Editor.The engine contains software components for the most common and recur-ring tasks in game developement. The topics covered by the engine includesound, graphics, physics and network functions. The engine supports C-Sharp, Boo, and JavaScript for script programming.

The other component is the Unity Editor that serves as an integrated devel-opment environment with a project panel for scripts and other components,a hierarchical object inspector containing the game scene setup and a gamepreview window (see figure 4). It also comes with several multi-languagescript editors and a unique prefab system that will be explained later.

8

Figure 4: The Unity Editor

There are several licenses available for Unity. Unity Basic with limitedfeatures is free for PC, MAC and Web development. Other platforms or fullfeature set require an additional license purchase [15].

Although there are many free and proprietary alternative game engines likethe Unreal Engine

TMor the C4

TMengine the choice fell on Unity for the fol-

lowing reasons:

It is possible to deploy to Windows, Mac OSX, Web Browser, Wii,iPhone, iPad, Android, XBox 360 and Playstation 3. It is even plannedto add Flash and linux deployment in the future. The deploymentpossbilities offer many possibilities to use the game engine or the gamescreated with the engine for monetizing or further studies.

The Unity community is very supportive and the engine as well as theeditor are well documented.

The engine is relatively easy to learn and to work with and supportsthe idea of rapid software development by providing all tools for quickprototyping and iterating as well as fast script compilation.

9

The iOS Basic license with possibility to deploy for iPhone, iPad andiPod touch comes at a relatively low price compared to other vendors.

Mechs and Tanks was created with Unity 3.0, C-Sharp scripting and the Mon-oDevelop IDE for development. You can find a Unity Tutorial in AppendixA.

3.1.1 Brief History of Unity3D

The following dates illustrate the evolution of the Unity Engine between 2001and 2011 [16].

2001

Unity Technologies started to develop their game engine in 2001. Themain incentive at the time was to create games and to create a goodtool as a foundation for these games [1].

2003

In 2003 the company noticed that the resulting engine would be a greatproduct on its own.

2005

In 2005 Unity 1 launched onstage at Apple’s WWDC.

2007

Unity 2.0 launched in 2007 and added a terrain engine, real-time dy-namic shadows and video playback among others.

2008

In 2008 Unity iPhone launched and the Cartoon Network introducedFusionFall, a game that has been played by more than 8 million people.

2010

In 2010 Unity 3.0 with dozens of new features like asset managementand beast lightmapping was released.

2011

Unity surpassed 500 000 developers and 60 million web-player installa-tions.

10

3.2 Game Architecture

Mechs and Tanks’ architecture consists of the module- and the Unity scene-architecture.

3.2.1 Main Modules

This section describes the most important modules and their relations. Thegame’s architectural style on a subsystem level is an object network with datacapsules. The following UML component diagram illustrates the subsystemsand their relations.

Game logic

This module manages the current player and AI configuration thecountdown timer and the current game state (paused, waiting for net-work reply..).

AI

The AI module contains the logic behind unit-, group- and player-AI.The unit AI makes use of diverse steering behaviours for pathfinding orobstacle avoidance and controls a unit’s state. The group AI managesa group’s behaviour and things like group pathfinding. On a higherlevel all the player’s groups are managed by a player module.

The machine learning AI saves and loads it’s data using the interfaceof the persistant data module.

11

Persistant data

This module is responsible for saving and loading data that shouldbe available between different game sessions. Among others, it storeslookup tables and graphs for the pathfinding module and manages themachine learning AI’s accumulated data.

Game actors

Game actors are terrains, units or buildings in the game. Their 3Dmodels get passed to the Unity3D rendering pipeline for visualization.Every game actor owns references to the AI modules that control it’sbehaviour.

Steering behaviours

Steering behaviours calculate forces that influence how and how fast anautonomous game agent should move. They can be used for obstacleavoidance, crowd movement or simple seeking tasks [8].

Pathfinding

This module is responsible for the creation of a pathgrid, gathering ofobstacle information and for providing an interface for various pathfind-ing requests. For better performance some information is saved to andloaded from the disk.

Input

This module keeps track of the user’s input, processes it and generatesthe feedback.

Network

The network module is responsible for managing all game actor’s statesin a network game. Another responsibility is to keep the game stateconsistent on both machines and to avoid jittering in network unitmovement.

GUI

The graphical user interface (GUI) displays all buttons, menus, theminimap and the countdown timer. It is also responsible for these ele-ment’s functionality and interacts heavily with the game logic modulefor this purpose.

12

3D rendering

This module is mainly managed by Unity3D. The scene’s main cam-era determines the objects that need to be rendered and sends themthrough the rendering pipeline. Unity3D encapsulates most renderingdetails but also offers access through pixel and vertex shaders.

3.2.2 Unity Scene Setup

Every map in the game is represented by a Unity3D scene. Here is what atypical scene setup in the Unity Hierarchy (a) and in the scene window (b)looks like:

(a) A map in the Unity Hierarchy (b) A map in the Scene View

Now all game objects from the top to the bottom of the panel will bedescribed.

CWalls

This object contains custom drawn wall nodes and wall edges. Thealternative to using custom drawn walls is to calculate them dependingon the map’s geometry.

Directional light

This light is only used to calculate the terrain lightmap. It is turnedoff afterwards due to performance reasons.

13

Game Music

Holds the game’s main music and plays it on scene start.

GameController

The GameController GameObject holds and administers all GameOb-jects that manage the game’s logic. It consists of the following objects:

CursorController

Manages the look and the logic behind the cursor.

GameInstantiator

This important GameObject is responsible for instantiating otherobjects that need to be created in a specific order.

(c) GameInstantiator in the Inspector (d) GameController in the Hierarchy

The GameInstantiator holds referenes to the buildings on themap, the PathCreator for path creation and obstacle manage-ment, the Player GameObject that manages player-configurationand -settings, the InputControl GameObject that is used to pro-cess user input, and a reference to the PlayArea GameObject thatdefines the playable area of a map.

It also contains references to the player’s spawn points and custompaths and walls.

14

GUI

Holds all the map’s GUI objects.

MachineLearningController

This GameObject controls all functionality that is needed for ma-chine learning.

spawn1, spawn2

The actual player spawn points. Spawn points are marked bygreen cubes in the Scene View.

HPaths

Custom path nodes and edges of the map. Custom nodes are labeledin the scene editor and outlined with red lines.

Main Camera

The scene’s main camera and audio listener. All 3D sounds are observedfrom the camera’s perspective.

PlayArea

Defines the actual playable area of a map.

Base Prefabs

The buildings that are scattered on the map.

Terrain

The Unity terrain object.

TestRunner

A GameObject that is used to run unit tests made with the Unity3Dunit testing framework SharpUnit [17].

3.2.3 MVC Pattern

The design of the Unity Engine encourages MVC (Model View Controller)oriented engineering. In my case the structure looks like this:

15

Figure 5: MVC pattern representation of the architecture

The model contains all GameObjects, their components and data files. Ithas access to the GameObject’s renderers and the camera object.

The view renders the models and is mainly managed by the Unity3D Engine’srenderers. It needs to access the 3D models, textures, materials and effectsthat are held by the model. It also has influence on what input options areavailable.

The controller receives user input and reacts by calling methods on modelobjects. It is represented by the Input subsystem in my game. The user caninfluence the view with his input.

3.3 Multiplatform Development

Unity allows to deploy a project on different platforms with minor changes.The presentation and functionality is largely maintained depending on theplatform’s capabilities. However, there are major differences in some areaslike the input mechanisms on different devices.

The abstract factory design pattern was applied to design these components.

16

3.3.1 The Abstract Factory Pattern

Figure 6: Abstract factory pattern

The abstract factory pattern (see figure 6) protects a client from differentplatforms that implement the same concept in different ways. A platform isa set of AbstractProduct classes. These classes represent a concept that issupported on all platforms. An AbstractFactory class declares operations forcreating single products, ConcreteFactory classes represent a specific plat-form.

The client only uses abstract factory and abstract product methods and istherefore protected from a platform’s concrete implementation.

3.3.2 Input and Persistant Data

The two main aspects of the game that ask for different implementationare the input-mechanisms and the usage of persistant file data. Unity3Ddoes not support cross-plattform databases. That is why Mechs and Tanks

17

uses persistant data as binary files on the disk. All platforms got their ownimplementation in respect to their capabilities and supported file formats.

In order to maintain readability and flexibility the following adaption of theabstract factory pattern for cross-platform input processing was used:

Figure 7: Excerpt of the Input subsystem structure

This is only a little excerpt of all the involved platforms and commands,chosen for demonstration purposes.

The InputManager gets attached to the InputControl GameObject in thescene. It calls the CommandImplementor’s Execute method every frameinside the Update function. The Execute method of a CommandImplementoriterates through all added commands, checks if their execute condition issatisfied and calls their Execute method, if so.

These are the components of the Input subsystems’s diagram in respect tothe abstract factory pattern:

18

Component in the input subsystemClient InputManagerAbstractFactory CommandImplementorConcreteFactory CommandImplementorWindows, CommandImplementorIphoneAbstractProduct Command, InputMoveCamera, InputHover, InputMultiselectConcreteProduct InputWindowsMoveCamera, InputIphoneMoveCamera,

InputWindowsHover, InputIphoneHover,InputWindowsMultiSelect, InputIphoneMultiSelect

3.4 iOS+Unity

Mechs and Tanks was created with a process of iterative development, whichis the reason why the game was already playable before any adjustments forthe iPad

TMwere made.

This chapter describes and analyses the challenges and solutions of portingMechs and Tanks to the iPad

TM.

3.4.1 Maximum Polygon Count

One of the most obvious restrictions for iPadTM

games is the number of poly-gons the graphics chip is able to render each frame. It turned out that morethan 30 000 polygons per frame started to drop the framerate below 25 FPSon the iPad

TM. After reducing the polygon count inside a 3D modeling soft-

ware by manually removing edges and applying pre-defined algorithms forpolygon reduction and even rebuiilding some models from the start, the cur-rent polygon counts on all platforms are:

Mech Tank Runner BuildingPolygon count 350 226 356 385

The average polygon count is about 300 per unit. If all 24 enemy andplayer units are captured by the camera in one frame the resulting polygoncount would be 7200 on average and about 8500 in the worst case of 24runners. Adding the maximum 4000 terrain polygons (the rest of the terraingets frustum culled), the heaviest frame would give the GPU about 12 500polygons to render.

3.4.2 Draw Call Reduction and Lights

Even more important for decent performance on mobile devices is the numberof draw calls per frame. A draw call is issued to the GPU every time a model

19

is drawn. If the model has n submeshes it will cause at least n draw calls.Every GUI texture, selection plane and health bar adds one draw call to thescene.

Another source for additional draw calls is per pixel lighting that causes anadditional draw call for every light pass. That is why all submeshes in amodel were combined into one and models don’t use dynamic lighting at all.The lights for all model and terrain textures are baked in. Light and shadowbaking calculates the brightness for each texel that gets illuminated by staticlight sources and lays a lightmap over the texture. The models look as if theyare effected by lights although no calculations are made. Figure 8 shows afew models without lightmaps or light effects.

Figure 8: Screenshot with Unlit Texture material shader and no light bakingfor models

20

Figure 9: Game view with expanded stats window in the top right corner

It is to say that Unity can combine a number of objects, sharing thesame material, at run-time and draw them together in a single draw call.This method is called dynamic batching [18]. Figure 9 shows a scene with66 draw calls that are caused by the following sources:

GUI

8 draw calls for buttons, minmap, countdown and countdown text +24 unit map spots + 8 building map spots + 1 camera map spot. Sumsup to 41 GUI caused draw calls.

Terrain

4 draw calls. One for each texture.

Visible Models

21

14 draw calls. Each model would cause 3 draw calls on its own. Onefor the unit mesh, one for the healthbar mesh and one for the selectionplane mesh. The low number can be explained with Unity’s dynamicbatching.

3.4.3 Terrains

Unity3D did not support terrains for iOS until Unity 3.4 was released inJuly 2011 [19]. In order to find the best solution for Mechs and Tanks, twoalternative ways for terrain implementation have been tested:

1. Modelling terrains in a 3D program:

Creating a terrain in a 3D modeling program and segmenting it intodifferent parts (see figure 10). The partitioning has the effect thatmost segments are frustum culled by Unity. That means that only thesegments that are at least partly visible get rendered.

Figure 10: Modelled terrain with highlighted parts

This technique was discarded because the process of creating new ter-rains gets very complicated compared to the Unity terrain system andthe texture size is either very large or the quality suffers.

22

2. Terrain for mobile systems:

Terrain for mobile systems is a solution that is available on the UnityAsset store and can convert Unity terrains to T4M terrains which canbe used on mobile devices. It turned out that the performance of thissolution was not sufficient for the game.

The final terrain solution was using the Unity terrain engine with very lowquality settings. That was only possible after Unity 3.4 was released in July2011 and added support for Unity terrains on mobile systems.

3.4.4 GUI-Optimization

The Unity engine offers two ways to implement the GUI. One way is to useUnity’s GUI system UnityGUI that needs it’s functions to be called insidea special function called OnGUI(), that is executed twice every frame andonce every event. This system is only used for the main menu and the pausemenu, where all values needed are calculated outside the OnGUI function.

GUI Textures are used for all other GUI elements like GUI buttons andthe minimap to sustain performance. GUI Textures are flat images that aredisplayed in 2D and only rendered once per frame.

3.4.5 Script-Optimizations

In order to grant high script performance the most expensive methods weretracked with a profiler. It turned out that the most expensive methodsare called either by the pathfinding or the steering behaviour subsystem.Pathfinding has been optimized as described below in the AI section. It wasalso made sure that costly functions like steering behaviours and other AIroutines don’t get called every single frame.

4 AI

This chapter describes the game’s AI up to the group abstraction level.

4.1 AI Architecture

A multilayered architecture has been chosen to implement the game AI. Thefollowing structure displays the layer arrangement:

23

Figure 11: AI layered architecture

Machine Learning AI

This layer iteratively calculates a rule set that has a good chance of win-ning against a certain play tactic. Rules in the rule set issue commandsto the underlying AI groups.

Group AI

The group AI is only available to AI players. It controls a group ofunits and manges them to fullfill the game’s winning conditions, alsothrough cooperation with other groups.

Unit AI

The unit AI controls a single unit and ensures intuitive behaviour likeattacking nearby enemy units without the need of commands, issuedfrom upper layers. It is available to all, human- and AI-player, units.

Steering behaviours

Steering behaviours calculate a steering force that influences where andhow fast an agent should move. All steering behaviours in Mechs andTanks return 2D steering force vectors [4].

Locomotion states

Locomation states decide about agent movement, for example whatsteering behaviours can be applied in a certain state. These statesinclude moving, idle, dead or attacking.

24

Locomotion This layer represents the mechanical aspects of agentmovement like the application of steering forces to an agent.

4.2 Layer 1 - Locomotion

Every unit in the game is treated with a vehicle model for movement. It hasa mass, a maximum travel-, rotation- and animation-speed, and a maximumforce that can affect it. In addition, it holds a reference to all steering be-haviours and a Move() method to update the vehicle physics.

Figure 12: Conceptional unit class

The Move method of a moving unit is called every frame and does thefollowing, conceptually:

1 Move( t ime e l apsed )2 {3 // c a l c u l a t e a c c e l e r a t i o n4 a c c e l e r a t i o n=f o r c e /mass ;5 v e l o c i t y+=a c c e l e r t i o n /mass ;6 //make sure the v e l o c i t y does not exceed the maximum ve l o c i t y7 t runcate ( v e l o c i t y , max ve loc i ty )8 po s i t i o n+=ve l o c i t y ∗ t ime e l apsed9 }

To make sure that jittering caused by vehicle alignment is reduced whentwo or more contradicting forces alternate, the heading is aligned by takingthe average heading of the last x frames.

4.3 Layer 2 - Locomotion States

This layer represents the vehicle’s current state of action. The followingstatechart diagram lists the possible states and transitions:

25

Figure 13: Locomotion states

Every state has a Start-method that gets called on state entrance, anExecute-method that is called every frame if the state is active and an Exit-method that gets called when a new state is entered. A statemachine holdsthe current state and a global state. Both get executed every frame This isa short description of all locomotion states:

Attack

A unit that attacks another unit that is in it’s attack range cannotmove or be moved by other units.

Dead

If a unit dies it is transitioned to the Dead state.

Global

This state gets called every frame and tests whether or not a unit isdead.

Idle

A breaking force is added every frame to the steering force if a unit isin the Idle state. This makes sure that the unit can still be influencedby other steering behaviours but will eventually halt.

Move

Whenever a unit gets commanded to move from one point to anotherthis will be it’s locomotion state.

26

4.4 Layer 3 - Steering Behaviours

All steering behaviours are implemented as classes that inherit from theabstract SteeringBehaviour class. The SteeringBehaviourManager managesall steering behaviours. The Steering behaviour subsystem has the followingstructure (not all behaviours are displayed):

Figure 14: Steering behaviour subsystem structure

The following code excerpt lists the most important attributes of theSteeringBehaviour class:

1 public abstract class Steer ingBehav iour {2 // the un i t that t h i s s t e e r i n g behaviour i s c a l c u l a t ed f o r3 protected Unit un i t ;45 public enum Steer ingType : int6 {7 Seek ,8 Arrive ,9 FollowPath ,10 NetworkFollowPath ,11 Of f s e tPur su i t ,12 Pursuit ,13 Alignment ,14 Separat ion ,15 Cohesion ,16 WallAvoidance ,17 ObstacleAvoidance ,18 PursuitPath ,19 Dummy,

27

20 I d l e21 } ;2223 // s t e e r i n g behaviour weights24 private stat ic f loat seekWeight=0.3F ;25 private stat ic f loat arr iveWeight=0.3F ;26 private stat ic f loat fol lowPathWeight=1.5F ;27 private stat ic f loat networkFollowPathWeight=1.5F ;28 private stat ic f loat o f f s e tPur su i tWe ight =1.5F ;29 private stat ic f loat pursuitWeight=1.5F ;30 private stat ic f loat alignmentWeight=0.2F ;31 private stat ic f loat separat ionWeight=0.4F ;32 private stat ic f loat cohesionWeight=0.2F ;33 private stat ic f loat wallAvoidanceWeight=0.2F ;34 private stat ic f loat obstacleAvoidanceWeight=0.2F ;35 private stat ic f loat pursuitPathWeight=1.5F ;36 private stat ic f loat dummyWeight=0.2F ;37 private stat ic f loat id leWeight=0.2F ;3839 private stat ic f loat [ ] we ights=new float [ 1 4 ] {40 seekWeight ,41 arr iveWeight ,42 followPathWeight ,43 networkFollowPathWeight ,44 o f f s e tPursu i tWeight ,45 pursuitWeight ,46 alignmentWeight ,47 separationWeight ,48 cohesionWeight ,49 wallAvoidanceWeight ,50 obstacleAvoidanceWeight ,51 pursuitPathWeight ,52 dummyWeight ,53 id leWeight54 } ;5556 protected Steer ingType type ;57 protected bool on=false ; // I s the behaviour enabled58 protected int p r i o r i t y ; // S t e e r i ng p r i o r i t y from 1−1059 private f loat f r equency ;60 private bool isTimeBased ; // does the s t e e r i n g behaviour get

c a l c u l a t ed on every frame or between time s t ep s61 private f loat l a s tExecuted ; // the l a s t time that the behaviour

has been c a l c u l a t ed i f i t i s time step based62 private Vector2 l a s tFo r c e ; // the l a s t c a l c u l a t ed s t e e r i n g f o r c e6364 . . .

All steering behaviours have a specific weight that is multiplied with the

28

actual steering force. All weights can be adjusted in this central file. If thecalculation of a behaviour is very expensive and can be simplified betweentime steps, it will save a lot of CPU cylcles. The attribute isTimeBaseddecides if this is the case. All steering behaviours can be enabled and disabledfor a specific unit.

The following code excerpt describes the classes’ most important methods.

1 // r e tu rn s the s t e e r i n g f o r c e or a s imp l i f i e d s t e e r i n g f o r c ebetween time s t ep s

2 public Vector2 GetForce ( )3 {4 i f ( ! isTimeBased )5 {6 l a s tFo r c e=weights [ ( int ) type ]∗ GetSteer ingForce ( ) ;7 return l a s tFo r c e ;8 }9 else i f (Time . time − l a s tExecuted >= frequency ) // only c a l c u l a t e

t h i s f o r c e in f i x ed time s t ep s10 {11 l a s tFo r c e=weights [ ( int ) type ]∗ GetSteer ingForce ( ) ;12 las tExecuted=Time . time+frequency ∗UnityEngine .Random . value ;1314 return l a s tFo r c e ;15 }16 else17 {18 // c a l c u l a t e a s imp l i f i e d s t e e r i n g f o r c e that i s c a l c u l a t ed

between time s t ep s19 l a s tFo r c e=weights [ ( int ) type ]∗ GetSteeringForceBetween ( ) ;2021 return l a s tFo r c e ;22 }23 }2425 // ac tua l s t e e r i n g f o r c e c a l c u l a t i o n26 protected abstract Vector2 GetSteer ingForce ( ) ;2728 //a s imp l i f i e d s t e e r i n g f o r c e that i s c a l c u l a t ed between time

s t ep s29 protected virtual Vector2 GetSteeringForceBetween ( )30 {31 return Vector2 . ze ro ;32 }33 . . .34 }

The SteeringBehaviourManager manages all behaviours and calculates anaccumulated steering force for a given unit. The accumulation works in the

29

following way:

1 public Vector2 Ca l cu la te ( )2 {3 Vector2 f o r c e=Vector2 . ze ro ;4 // behaviours so r t ed by p r i o r i t y5 foreach ( Steer ingBehav iour s in sor tedBehav iours )6 {7 i f ( s . IsOn ( ) )8 {9 i f ( ! AccumulateForce ( ref f o r c e , s . GetForce ( ) ) )10 return f o r c e ;11 }12 }1314 return f o r c e ;15 }1617 //add a f o r c e to CurrentForce and make sure i t does not exceed

the unit ’ s maximum f o r c e18 private bool AccumulateForce ( ref Vector2 currentForce , Vector2

forceToAdd )19 {20 f loat remaining =uni t . GetMaxForce ( )−currentForce . magnitude ;2122 i f ( remaining <= 0 . 0 ) return false ;2324 i f ( forceToAdd . magnitude < remaining )25 currentForce+=forceToAdd ;26 else27 currentForce+= ( remaining ∗ forceToAdd . normal ized ) ;28 return true ;29 }

I am going to describe all implemented steering behaviours individually.For the actual implementation see the Appendix A.2.

4.4.1 List of Behaviours

Seek

The seek behaviour (see figure 15) calculates a force that moves a unittowards a target spot. The two-dimensional force vector is calculatedin the following way:

~desired velocity = normalize( ~target spot− ~unit position) ∗ unit→MaxSpeed

~force = ~desired velocity − ~current velocity

30

Figure 15: Seek behaviour

Arrive

While the seek behaviour steers a unit towards a target, the unit doesnot halt at the target position. In order to make a unit stop gentlyat a target position the arrive behaviour calculates how much time isneeded to reach the target and calculates a steering force accordingly.The calculation of the desired velocity changes to:

speed = distance ∗ 10;

~desired velocity = ~toTarget ∗ speed/distance

where ~toTarget is the direction vector from the unit’s to the targetposition and distance is the distance to the target position.

Idle

The idle behaviour makes sure, that the unit will halt when it is in theidle state.

The force is calculated in the following way:

~force = ~current velocity/4 ∗ 5 ∗mass

where mass is the unit’s mass.

31

FollowPath

In order for a unit to follow a path the arrive and the seek behavioursare used. A path is a list of position nodes (see figure 16) and the unitseeks one node after another and finally stops at the target position.

Figure 16: Units following a path

Obstacle avoidance

This behaviour makes units avoid circle shaped obstacles by calculatinga bounding box in front of a unit and applying a lateral and a breakingforce to the unit if the box intersects with an obstacle. Figures (a)and (b) below illustrate the concept and the actual implementation inMechs and Tanks.

(a) Obstacle avoidance (b) Units with a red bounding box

Obstacle avoidance was used in Mechs and Tanks to avoid unit collisionswith buildings. However, it turned out that the calculations needed touse it are very expensive. That is why the avoidance of buildings isdirectly implemented into the path graph.

32

Pursuit

Figure 17: Pursuit behaviour

The pursuit behaviour (see figure 17) is used if a unit wants to intercepta moving target. For this purpose it returns a force that uses the seekbehaviour and steers the unit towards a predicted future position:

lookAhead = toEvader magnitude/(unit speed + target speed)

~futurepos = ~target position + target velocity ∗ lookAhead

Wall avoidance

33

A wall is represented by a line segment and a normal (cmp. figure(b) below) that is pointing away from the wall. the wall avoidancebehaviour steers to avoid unit intersection with walls. For this purposea unit has four feelers (cmp. figure (a) below) that are tested forcollisions with walls. When the closest intersecting wall is found, asteering force in the direction of the wall normal is applied.

(a) Wall avoidance (b) Walls with normals

• Separation:

Separation creates a force that steers a unit away from all neighboursthat intersect with it. The force to steer it away from another unitis simply ~unit position − ~neighbour position. To improve the perfor-mance of calculating all neighbours of a unit, every map is partitionedwith a KD-tree ([6]) as displayed in figure 18.

4.5 Pathfinding and Obstacle Avoidance

Units can move on all map areas that have a height value close to 0. Moun-tains have to be surrounded by walls and have to be walked around.

After experimenting with an algorithm that scans the maps for walls andpaths automatically, it turned out to be too slow for pathfinding on theiPad

TM. That is why paths and walls are customly created within the editor

(see figure 18). That reduced the number of pathnodes from about 1000 tonearly 100 and significantly improved the pathfinding speed.

34

Figure 18: Customly created paths(green) and walls(black), orientationnodes(pink) and map partitioning with a KD-Tree (blue)

A pathfinding request consists of the following substeps:

1. Find the closest orientation nodes (see figure 18) for the start and targetposition with a KD-Tree.

2. Find the closest path nodes for the orientation nodes with a KD-Tree.

3. Use the A* algorithm to calculate the shortest path between thesenodes. The A* algorithm is a variation of the dijkstra algorithm thatuses the euclidean distance between the currently touched and the tar-get node to update it’s distance value in the heap [7], [3], [20].

4. Smooth the resultant path.

35

Without path smoothing, calculated paths contain unnecessary edgesthat look like zigzag lines. The following Pseudocode shows a simplifiedimplementation of the smoothing algorithm:

12 Path SmoothPath (Path path )3 {4 PathNode node1 = path . f i r s tNode , node2 , node3 ;5 node2 = node1 . Next ;67 i f ( node2 != nu l l )8 node3 = node2 . Next ;9 else10 node3 = nu l l ;1112 bool b lock=f a l s e ;1314 /∗ I t e r a t e through pathnodes and remove nodes15 that are not blocked by wa l l s or bu i l d i n g s ∗/16 while ( node3 != nu l l&&!block ) {17 block = IsWallBetween ( node1 , node3 ) | |18 IsBui ld ingBetween ( node1 , node3 ) ;19 i f ( ! b lock )20 path . Remove ( node2 ) ;21 node2 = node3 ;22 node3 = node2 . Next ;23 }24 }

The orientation nodes ensure that path requests inside of walled in areas(mountains) still get executed with a nearby target position.

Obstacle (building) avoidance is incorporated into the path graph with pathnodes and edges that surround a building, like illustrated in figure 19.

36

Figure 19: Path edges around a building

4.6 Layer 4 - Unit AI

The unit AI enables units to follow user commands like path or unit followingon a unit level. It also ensures that units attack nearby enemies automati-cally. When an enemy unit moves within the startle range of an idle unit,the unit asks all nearby allies for support and starts to attack the intruder.

The unit AI is available to human and AI players and implemented as a statemachine. All group commands are eventually translated into unit commandsthat are issued to every unit in the target group.

4.7 Layer 5 - Group AI

The group AI is only available to AI players and controls a group of 4 units.It is implemented as a state machine and every group (3 per player) gets onestate machine assigned. It decides about the group’s tactics and can interactwith other groups. Enemy units are dynamically divided into clusters usingthe K-means algorithm on this layer.

There are group AIs for following tactics:

• Aggressive: All 3 groups agree on attacking one enemy cluster. Afterall clusters are defeated all groups start to attack the enemy’s buildings.

37

• Defensive: All groups are in a defensive state. If an enemy cluster movesclose to a base, all groups move to and attack that cluster. After allenemy units are defeated the enemy buildings get attacked.

• Offensive: All groups choose an enemy building and attack it. Theyalso try to move around enemy clusters by constantly calculating pathsthat do not cross enemy clusters. If no such path is available, anotherbuilding is chosen as a target.

The following UML state chart describes the defensive group AI:

Figure 20: Defensive group

Aware

The group does not move and waits for enemies to attack a friendlybuilding.

Defend

When an enemy cluster gets close to a friendly building all groupsswitch to this state.

AttackBuilding:

If all enemy units are defeated all groups attack enemy buildings.

Recollect

If the units within a group get seperated from each other they recollectin this state.

Global

The global state takes action if all enemies are defeated or units of thesame group drift apart.

38

5 Machine learning

The Machine AI layer teaches AI groups to defeat static group AI using atechnique called dynamic scripting [9].

5.1 Dynamic Scripting

Dynamic scripting is an online machine-learning technique for game AI, basedon reinforcement learning. Every learning agent (in this case a unit group)maintains a rulebase that is used to generate a script to control the agent’sbehaviour. A rulebase consists of a number of rules. Each rule has a weightthat influences the probability that a rule is selected for the controlling script.After every iteration of the game, a fitness function calculates a weight ad-justment for all active rules that were selected into the script. The goal ofdynamic scripting is that the rules’ weights get adjusted so that the agent’sfitness increases after a number of iterations.

The two main steps of dynamic scripting are weight adjustment and scriptcreation. Script creation chooses a number of rules from the rulebase intothe script, giving rules with higher weights a higher probability to be chosenover rules with lower weights. It works like this:

1 f loat sumweights=0;23 // c a l c u l a t e the sum of a l l weights4 for ( int i =0; i<ru l ecount ; i++)5 {6 sumweights+=ru l e [ i ] . weight ;7 }89 int t ry=0;10 bool l ineadded=f a l s e ;1112 // choose maximum ’ s c r i p t s i z e ’ r u l e s i n to the s c r i p t13 for ( int i =0; i<s c r i p t s i z e ; i++)14 {15 try=0; l ineadded=f a l s e ;16 int j , s e l e c t e d ;17 f loat sum=0, f r a c t i o n ;1819 while ( try<maxtr ies&&! l ineadded )20 {21 j =0; sum=0; s e l e c t e d=−1;22 f r a c t i o n=random( sumweights ) ;2324 // i t e r a t e through r u l e s and s e l e c t one

39

25 while ( s e l e c t ed <0)26 {27 sum+=ru l e [ j ] . weight ;28 i f (sum>f r a c t i o n )29 s e l e c t e d=j ;30 else31 j++;32 }3334 l ineadded=In s e r t I n S c r i p t ( r u l e [ s e l e c t e d ] ) ;35 t ry++;36 }37 }3839 F in i s hS c r i p t ( ) ;

The InsertInScript function returns true and inserts the rule into the scriptif it has not been added yet and returns false with no effect otherwise. Fin-ishScript adds one or more general rules to the script.

Weight adjustment is applied after each iteration of the dynamic scriptingalgorithm and works like this:

1 int a c t i v e =0;23 // count number o f a c t i v e r u l e s4 for ( int i =0; i<ru l ecount ; i++)5 {6 i f ( r u l e [ i ] . a c t i va t ed )7 a c t i v e=ac t i v e +1;8 }910 i f ( ac t ive <=0|| act ive>ru l ecount )11 return ;1213 // c a l c u l a t e the weight adjustment with the f i t n e s s func t i on14 int nonact ive=rulecount−a c t i v e ;15 f loat adjustment=CalculateAdjustment ( F i tne s s ) ;16 f loat compensation=−a c t i v e ∗adjustment / nonact ive ;17 f loat remainder=0;1819 // ad jus t weights and try to keep sum of a l l we ights constant20 for ( int i =0; i<ru l ecount ; i++)21 {22 i f ( r u l e [ i ] . a c t i va t ed )23 ru l e [ i ] . weight+=adjustment ;24 else25 ru l e [ i ] . weight+=compensation ;26 }

40

27 //dont l e t the weight drop under ’ minweight ’ or r i s e above ’maxweight ’

28 i f ( r u l e [ i ] . weight<minweight )29 {30 remainder+=(ru l e [ i ] . weight−minweight )31 ru l e [ i ] . weight=minweight ;32 }33 else i f ( r u l e [ i ] . weight>maxweight )34 {35 remainder+=(ru l e [ i ] . weight−maxweight )36 ru l e [ i ] . weight=maxweight ;37 }3839 Distr ibuteRemainder ( ) ;

The CalculateAdjustment function returns the fitness function’s weight ad-justment for all active rules. A compensation for all nonactive rules is cal-culated to keep the sum of all rules’ weights constant. The weights can notdrop beneath a minimum or rise above a maximum value.

5.2 Dynamic Scripting for Mechs and Tanks

[9] used a simulation environment where two teams of agents battle in anarena style fight. In order to make dynamic scripting applicable for Mechsand Tanks, some changes had to be made.

5.2.1 Architecture

There are two components that get adjusted with every iteration of the game.The first component holds a rulebase for every single player group. Therulebase contains 29 indiviudal rules that have following operations and at-tributes:

• Condition(): Rules can only be executed if a certain condition isfullfilled. If a rule is about retreating from an enemy cluster, a conditioncould be a maximum distance from that cluster.

• Execute(): The actual commands that are executed by the group ifthe rule is executed.

• weight: Weight that is used for script generation.

• frequency: The frequency decides how often a rule is checked for its’condition.

41

• priority: The priority decides which rule is picked if two rules’ condi-tion are fullfilled at the same time.

The RuleManager class holds all rules and is responsible for script generationand execution. The script size for script generation is 4 and the executionfuntion is called every frame. It looks like this:

1 // return i f the group has no un i t s l e f t2 i f ( gr . Units . Count==0)3 return ;45 /∗ choose a new ru l e every ’ f requency ’ seconds ∗/6 i f ( (Time . time−lastUpdate )>f r equency )7 {8 LinkedList<Rule> potRules=new LinkedList<Rule>() ;9 // i t e r a t e through a l l a c t i v e r u l e s and add them to the r u l e s

that can be p o t e n t i a l l y executed10 foreach ( Rule r in ActiveOptions )11 {12 i f ( r . Condit ion ( gr ) )13 potRules . AddLast ( r ) ;14 }15 int maxPrior ity=0;16 LinkedList<Rule> maxPr i o r i t i e s=new LinkedList<Rule>() ;17 //Pick r u l e s with maximum p r i o r i t i e s18 foreach ( Rule r in potRules )19 {20 i f ( r . P r i o r i t y>maxPrior ity )21 {22 maxPrior ity=r . P r i o r i t y ;23 maxPr i o r i t i e s=new LinkedList<Rule>() ;24 maxPr i o r i t i e s . AddLast ( r ) ;25 }26 else i f ( r . P r i o r i t y==maxPrior ity )27 {28 maxPr i o r i t i e s . AddLast ( r ) ;29 }30 }31 // choose a random ru l e out o f the r u l e s with maximum p r i o r i t y32 i f ( maxPr i o r i t i e s . Count !=0)33 {34 Rule pickedRule=maxPr i o r i t i e s . F i r s t . Value ;35 int pick=( int ) ( UnityEngine .Random . value ∗maxPr i o r i t i e s . Count ) ;36 int i =0;3738 foreach ( Rule r in maxPr i o r i t i e s )39 {40 i f ( i==pick )41 {

42

42 pickedRule=r ;43 break ;44 }45 i++;46 }47 /∗48 ∗ Only r ep l a c e the cur rent r u l e i f the new ru l e s ’49 ∗ Pr i o r i t y i s h igher or equal or the cur rent ru l e s ’50 ∗ cond i t i on i s not s a t i s f i e d anymore51 ∗ ∗/52 i f ( currentRule==null53 | | ( pickedRule . Pr i o r i t y>=currentRule . P r i o r i t y54 | | ! currentRule . ExeCondition ( gr ) ) )55 {56 l a s tRu l e=currentRule ;57 currentRule=pickedRule ;58 //Execute the ru l e59 pickedRule . ExecuteRule ( gr ) ;60 lastUpdate=Time . time ;61 }62 }63 }

The other component adjusts the weights of a certain tactic. A tactic decideswhat combination of unit types is chosen at the beginning of the game bythe MachineAI. If a certain combination turns out to be especially effectiveagainst a strategy it will eventually have a higher weight than other combi-nations.

There are 10 different tactics, managed by the TacticManager class, that canbe chosen from.

The following graphics illustrates the UML class model of the dynamic script-ing component:

43

Figure 21: UML chart of the dynamic scripting component

MachineAI

This class holds a reference to a list of RuleManager objects and oneTacticManager object. It inherits from the Player class and managesthe loading and storing of Tacticmanagers and RuleManagers that havebeen written to the disk.

Tactic

A tactic decides about how many mech, runner and tank groups aplayer selects in the beginning of a game. The numbers must add upto 3, due to the maximum group size of 3. There are 10 different tactics.

Rule

A rule is a list of commands concerning a unit group that can be exe-cuted under a certain condition. A rule also has a priority value thatdecides if it gets selected over another rule that could be potentiallyexecuted at the same time. A frequency attribute decides how manyseconds after the last execution of the rule, the rule condition can besatisfied again (It can be executed again).

44

RuleManager

The RuleManager class is responsible for script generation and weightadjustment of active rules. It contains a list of 29 rules and can beserialized to the disk with all it’s rules and and fitness values. EveryAI group holds it’s own RuleManager object.

TacticManager

The TacticManager picks a tactic out of a pool of 10 different tacticsand adjusts their weights after each iteration of the game. A machineplayer owns exactly one TacticManager object.

TacticManagerSerialize

This class is a helper class that is used for the serialization of a Tactic-Manager object.

RuleManagerSerialize

This class is used to serialize RuleManagers.

5.2.2 Fitness Function

If a running game is labeled as a machine learning game, the MachineLearn-ingController GameObject initializes the MachineAI class and issues weightadjustment commands for rules and tactics after every match. Afterwardsthe new weight values and the current iteration are written to the disk andthe level is reloaded for another match. After a minimum number of succes-sive wins or a maximum number of iterations the script does not reload thethe game anymore and the learning algorithm ends.

The adjustment of weights is based on a fitness function inside the Tactic-Manager and the RuleManager. The calculated fitness value is between 0 and1. A losing agent can only have a fitness value between 0 and 0.5. A winningagent has a fitness value between 0.5 and 1. The calculated fitness then getsconverted into an adjustment value. The CalculateAdjustment() method ofthe abstract WeightedOptionManager class returns the weight adjustmentvalue for all learning components of a TacticManager or a RuleManager.Equation 1 shows the formula for weight adjustment:

∆W =

−Pmax

0.5− F

0.5{F < 0.5}

RmaxF − 0.5

1− 0.5{F ≥ 0.5}

(1)

45

Rmax ∈ N is the maximum reward, and Pmax ∈ N is the maximum penalty,F 〈0, 1〉 is the fitness value that is calculated by the superclasses and 0.5 is abreak-even value that indicates whether an agent has won or lost a match.

Values below 0.5 indicate a loss and values equal to or above 0.5 indicate awin, respectively.

The RuleManager’s implementation of the fitness function is composed of ateam fitness function that returns a value that is consistent for all groups ina team, a group fitness function that states how well the group owning theRuleManager component has performed and a time fitness value that addsa higher value if a team has won quickly or lost slowly. All these functionsreturn values between 0 and 0.5 for a losing and values between 0.5 and 1 fora winning group/team. The RuleManager uses the formula in equation 2 tocalculate it’s fitness value:

F (g, t) =1

4∗ (2 ∗ T (t) + G(g) + D(t)) (2)

In equation 2, g refers to a group whose fitness is calculated and t refers tothe group’s team. T(t) describes the team fitness, G(g) the group fitness andD(t) the time fitness.

The group fitness G(g) is determined by how long the group’s units survivedand how much health points they managed to maintain. It returns highervalues if these two values are high.

G′(g) =∑u∈g

0.75 +

h(u)

hmax(u)∗ 1

|g| ∗ 4{u survived}

0.5 +∆dt(u)

∆gt∗ 1

|g| ∗ 4{u died}

(3)

The function G’(g) iterates through all units u ∈ g and calculates a fitnessvalue that depends on the unit’s health and life status. h(u) are the unit’shealth points, hmax are the maximum health points, ∆dt(u) is the durationthat a unit survived, ∆gt is the game duration and |g| is the number of unitsin group g. G(g) is now calculated with the help of G’(g):

G(g) =

G′(g) {g won}G′(g)

2{g lost}

(4)

The T(t) function of equation 2 calculates a team fitness for the team that

46

g belongs to. The formula in Equation 5 shows how it is calculated:

T (t) =

S(wp)

Smax ∗ 2+ 0.5 {t won}

0.5− S(wp)

Smax ∗ 2{t lost}

(5)

S(wp) is the game score of the winning player that is determined by thenumber of killed enemy units and buildings, Smax is the maximum playerscore.

The time fitness function D(t) in equation 2 is defined as follows:

D(t) =

(1− ∆gt

∆gtmax)

2+ 0.5 {t won}

∆gt

∆gtmax ∗ 2{t lost}

(6)

Where ∆gt is the game duration and ∆gtmax is the maximum game duration(4 minutes).

The TacticManager’s fitness function only depends on the team and timefitness values:

Ft(g, t) =1

3∗ (2 ∗ T (t) + D(t)) (7)

5.3 Performance Measuring

The machine learning algorithm was tested by letting a machine team playagainst a team of state machine controlled groups. Every statemachine con-trolled team has it’s machine learning counterpart that was trained againstit in maximum 500 iterations. If a machine learner has a winning streak of 15the algorithm stops prematurely. The values used for the weight adjustmentare listed in the table below.

Min. weight Max. weight Max. penalty Max. reward ScriptsizeTacticManager 1 100 15 25 1RuleManager 1 400 20 30 4

The following 3 graphics demonstrate the development of the average groupfitness value (y-axis) through the learning iterations (x-axis). A fitness value

47

above 0.5 indicates a win. The black line in the middle of the chart is atrendline that illustrates the general development of values over time.

Figure 22: Fitness charts (x-axis:iterations, y-axis: fitness value)

The trendlines of all three charts show a steady rise of fitness values overthe course of the algorithm. All three algorithms end prematurely after awinning streak of 15 games. However it took 444 iterations to find a fitting

48

tactic against the Aggressive AI compared to 229 tactics for the Offensive AIand only 87 iterations for the Defensive AI. The following 3 charts illustratethe win/loss statistics of the machine learning teams. A 0 value stands for adraw, a 1 stands for a win and a -1 represents a loss.

Figure 23: Win/loss charts (x-axis:iterations, y-axis: 1=win, 0=draw, -1=loss)

5.4 Conclusions

The experiments prove that my implementation of the dynamic scriptingalgorithm works well with real time strategy games. The machine learningteam learns to adapt to enemy strategies and outsmarts them after a numberof learning iterations. It even creates own strategies in the learning process.For instance, the Aggressive AI’s opponent distracts all enemy groups withtwo groups of tanks while a group of runners sneaks behind the enemy linesand attacks their buildings. This kind of behaviour resembles human likethinking and demonstrates how effective dynamic scripting can be if a goodrulebase and reasonable weight adjustment parameters are provided.

49

6 Conclusions and Future Work

An RTS game consists of many different components like sound, GUI, 3Dmodels, pathfinding, AI or network code and it usually takes a team of manydifferent people to create one. I was able to create a multiplatform RTS gameby choosing the right tools and an iterative development process. The UnityEditor provides an intuitive and solid concept for game creation that allowsdevelopers to concentrate on the main aspects of their games rather than onrecurring basic tasks.

Dynamic scripting allowed me to create an AI system that learns to adaptto it’s enemy behaviour in an efficient and robust way that is suitable forcommercial games of all kind. It can be used in various ways like game bal-ancing or giving players a more challenging single player experience.

In future work I plan to add more units and therefore more complexity toMechs and Tanks and also test online machine learning in more complexscenarios and other game genres. It is also planned to reduce the numberof iterations needed to adapt to a tactic and make the algorithms better ap-plicable against human players with varying strategies. This step could takesingle player games to a new level of interactivity and significantly improvethe replayability and entertainment value of many games.

Bibliography

References

[1] ”‘Die Zukunft von Unity3D”’ Interview, making games magazine,05/2011

[2] Ryan Henson Creighton, ”‘Unity 3D Game Development by Exam-ple”’, Packt Publishing, 2010

[3] Thomas H. Cormen, ”‘Introduction to algorithms”’, MIT Press, 2003

[4] Mat Buckland, ”‘Programming Game AI by Example”’, WordwarePublishing, 2005, pp.85-130

[5] Carl Granberg, ”‘Programming an RTS Game with Direct3D”’,Charles River Media, 2007

[6] Mark de Berg, Otfried Cheong, Marc van Kreveld, Mark Overmars,”‘Computational Geometry”’, Springer, 2008

50

[7] P E Hart, N J Nilsson, B Raphael, ”‘A Formal Basis for the HeuristicDetermination of Minimum Cost Paths”’, IEEE, 1968

[8] Craig W. Reynolds, ”‘Steering Behaviors For Autonomous Charac-ters”’, Sony Computer Entertainment America, 1999

[9] Pieter Spronck, Marc Ponsen, Ida Sprinkhuizen-Kuyper, EricPostma, ”‘Adaptive game AI with dynamic scripting”’, Springer Sci-ence + Business Media, LLC 2006

[10] Vlasios K. Dimitriadis, ”‘Reinforcement Learning in Real Time Strat-egy Games Case Study on the Free Software Game Glest”’, TechnicalUniversity of Crete Department of Electronic and Computer Engi-neering, 2009

[11] Marc Ponsen, ”‘Improving Adaptive Game AI with EvolutionaryLearning”’, Delft, 2004

[12] ”‘Unity game engine”’, Website, 2011http://unity3d.com/

[13] ”‘Galaxy Editor: Complete Hero Tutorial”’, Website, 10/11/2011http://www.sc2mapster.com/wiki/galaxy/script/language-overview/

[14] ”‘Galaxy Editor: Language Overview”’, Website, 10/11/2011http://www.sc2mapster.com/wiki/galaxy/script/language-overview/

[15] ”‘Unity License Comparison”’, Website, 10/11/2011http://unity3d.com/unity/licenses.html

[16] ”‘Unity Fast Facts”’, Website, 10/11/2011http://unity3d.com/company/fast-facts

[17] ”‘SharpUnit Framework”’, Website, 10/11/2011http://www.unifycommunity.com/wiki/index.php?title=SharpUnit

[18] ”Unity3D Draw Call Batching”’, Website, 10/11/2011http://unity3d.com/support/documentation/Manual/iphone-DrawCall-Batching.html

[19] ”‘Unity 3.4”’, Website, 10/11/2011http://unity3d.com/unity/whats-new/unity-3.4

51

[20] ”‘Binary Heap”’, Website, 10/11/2011http://content.gpwiki.org/index.php/C sharp:BinaryHeapOfT

A Appendix

A.1 Unity3D Tutorial

This section will introduce Unity3D and it’s workflow. Afterwards it willdemonstrate how a simple interactive scene is set up using Unity. Figure 24displays the Unity editor with labels for the different editor windows.

Figure 24: The Unity Editor with the tutorial scene loaded

A.1.1 The Scene View

The scene view (see figure 25) is an interactive sandbox that can be usedto position geometric objects, terrains, lights or cameras. All objects insidea Unity scene are inherently GameObjects. A GameObject is a containerthat can hold Components which add functionality to the GameObjects. Acomponent can be a script, a collider, a 3D mesh and many more. The Unityengine comes with many helpful Components that ease development.

There are two ways to add GameObjects and Components, either by scriptor by using the editor’s menu.

52

Figure 25: Unity Editor Scene View

A.1.2 The Inspector

The Inspector (figure 26) displays information about the currently selectedGameObject or Asset in the Unity Editor. If a GameObject is selected itdisplays it’s attached Components and each Component’s editable values.For instance all GameObjects in a scene have a Transform Component thatdetermines the object’s position, rotation and scale and can be edited directlyin the inspector.

53

Figure 26: Unity Engine Inspector

A.1.3 The Project Panel

The Project panel (figure 27) contains all scripts, models, textures, materials,sounds and other resources that are used in the game’s scenes and that canbe attached to GameObjects in a scene. All elements in the project panelare located in the project folder’s Assets folder.

New assets can be created inside the editor using the project panel’s createmenu or they can be imported using the Assets menu or by just draggingand dropping the item inside the project panel alternatively.

54

Figure 27: The Tutorial’s scene Project Panel

A.1.4 The Game Window

The game window (figure 28) shows the actual scene through the scene’smain camera. It can be used to play the game inside the editor.

Figure 28: Tutorial Game Window

55

A.1.5 Walking Cube: A Unity Example

The following steps illustrate how to create a simple interactive scene inUnity3D. The scene will feature a movable cube that can be used to bowldown a couple of pillars in the scene.

1. First create a new scene (File → New Scene) and save it (File →Save Scene).

2. Now go to Terrain → Create Terrain and make sure the terrain hasfollowing transform settings in the Inspector. Also make sure that whenyou go to Terrain→ Terrain Resolution the settings look like these:

3. Make sure that the terrain object is selected in the Hierarchy and chooseComponent → Terrain → Terrain Toolkit from the file menu. Youshould have the terrain toolkit installed, otherwise this component willnot be available.

56

4. In the inspector expand the Terrain Toolkit Component and add afitting texture for the terrain.

5. Now lets add a directional light to the scene. In the file menu chooseGameObject→ Create Other → Directional Light. Make sure it hasthe following settings in the Inspector:

6. Add a cube to the scene by going to GameObject→ Create Other →Cube and give it the following transform settings in the Inspector:

57

7. With the cube selected in the Hierarchy go to Component→ Physics→Rigidbody A Rigidbody is a Component that makes the GameObjectbehave like a physical object with mass and forces that can be appliedto it.

8. In the same way add a cylinder with the following transform settingsand a Rigidbody attached to it. If you scroll out in the scene view andclick on the green Y-Axis in the top-right corner, your scene shouldsomehow look like this:

58

9. In the Hierarchy right click on the cylinder and select duplicate. In theScene View Navigation pick the cross for moving objects and move thecylinder on the X-Z-Plane to a desired position.

10. Repeat the last step as often as you want to place more cylinders intothe scene.

11. Now select the main camera in the Hierarchy and give it the followingtransform values. Your Game Window should look something like this:

12. In order to make the cube contrallable by the player you have to write ascript. In the Project Panel’s create menu, select Create→ C# Script.Call the script MoveCube, open it and type in the following code:

59

1 using UnityEngine ;2 using System . Co l l e c t i o n s ;34 public class MoveCube : MonoBehaviour {56 public f loat speed ;78 // Use t h i s f o r i n i t i a l i z a t i o n9 void Star t ( ) {1011 }1213 // Update i s c a l l e d once per frame14 void Update ( ) {1516 // passed time s i n c e l a s t frame17 f loat td=Time . deltaTime ;1819 // Get the user input and t r a n s l a t e i t to a f o r c e vec to r20 f loat moveX = Input . GetAxis ( ”Hor i zonta l ” ) ∗ speed ∗ td ;21 f loat moveZ = Input . GetAxis ( ” Ve r t i c a l ” ) ∗ speed ∗ td ;2223 Vector3 f o r c e=new Vector3 (moveX , 0 , moveZ) ;2425 // apply the f o r c e to the GameObject ’ s r i g idbody26 r ig idbody . AddForce ( f o r c e ) ;27 }28 }

13. Select your cube in the Hierarchy and click Component → Scripts →Move Cube.

14. In the Inspector, change the speed value in the Move Script Componentto 2000.

15. In the Game Navigation click the play button and control the cubewith the arrow-buttons.

60

A.2 Source Code Listings

The following listing describes the wall avoidance behaviour:

1 public class WallAvoidanceBehaviour : Steer ingBehav iour {23 LineSegment2D [ ] f e e l e r s ;4 f loat f e e l e rLeng th =1.2F ;5 LinkedList<BorderEdge> wallsBetween ; //tmp . s to rage f o r wa l l s

that c ro s s ed the f e e l e r s6 LinkedList<LineSegment2D> f e e l e r sBe tween ; //tmp . s to rage f o r

f e e l e r s that c ro s s ed the wa l l s in ’ wallsBetween ’78 protected override Vector2 GetSteer ingForce ( )9 {10 wallsBetween=new LinkedList<BorderEdge>() ;11 f e e l e r sBetween=new LinkedList<LineSegment2D>() ;1213 Vector2 f o r c e=Vector2 . ze ro ;14 Ass i gnFee l e r s ( ) ;1516 Region reg=uni t . MRegion ;17 Vector2 cP ;18 BorderEdge c l o s e s tWa l l ;1920 /∗ t e s t a l l f e e l e r s f o r wa l l i n t e r s e c t i o n s and21 s t o r e them f o r the s imp l i f i e d wa l l avoidance method ’

GetSteeringForceBetween ’ ∗/2223 foreach ( LineSegment2D f e e l e r in f e e l e r s )24 {25 i f ( reg . Ge tC l o s e s t In t e r s e c t i onPo in t ( f e e l e r , out cP , out

c l o s e s tWa l l ) )26 {

61

27 AvoidWall ( c l o s e s tWal l , f e e l e r , cP , ref f o r c e ) ;28 wallsBetween . AddLast ( c l o s e s tWa l l ) ;29 f e e l e r sBetween . AddLast ( f e e l e r ) ;30 }31 }32 return f o r c e ;33 }3435 public WallAvoidanceBehaviour ( Unit un i t ) : base ( unit ,

Steer ingBehav iour . Steer ingType . WallAvoidance , 1 0 , 0 . 1F)36 {37 f e e l e r s=new LineSegment2D [ 2 ] ;38 }3940 /∗ c r e a t e f e e l e r s f o r the cur rent un i t p o s i t i o n and o r i e n t a t i o n

∗/41 private void Ass i gnFee l e r s ( )42 {43 // c r e a t e two f e e l e r s , forming a c r o s s at the cente r o f the

un i t4445 Vector2 forward=VectorOperat ions . FromV3ToV2( un i t . Transform .

forward ) . normal ized ∗ f e e l e rLeng th ;46 Vector2 r i gh t=VectorOperat ions . FromV3ToV2( un i t . Transform .

r i g h t ) . normal ized ∗ f e e l e rLeng th ;47 f e e l e r s [0 ]=new LineSegment2D ( un i t . Position2D−forward , un i t .

Posit ion2D+forward ) ;48 f e e l e r s [1 ]=new LineSegment2D ( un i t . Position2D−r i ght , un i t .

Posit ion2D+r i gh t ) ;49 }5051 public WallAvoidanceBehaviour ( Unit unit , Unit t a r g e t ) : this ( un i t

)52 {5354 }5556 /∗Calcu la te the f o r c e that s t e e r s the un i t away from a cro s s ed

wa l l ∗/57 private void AvoidWall ( BorderEdge wal l , LineSegment2D f e e l e r ,

Vector2 cP , ref Vector2 f o r c e )58 {59 f loat overshoot=(( f e e l e r . GetStart ( )+f e e l e r . GetDir ( ) )−cP) .

magnitude ;60 f o r c e+=wal l . GetNormal ( ) ∗ overshoot ∗10 ;61 }6263 /∗64 This s t e e r i n g f o r c e i s c a l c u l a t ed between time s t ep s

62

65 o f the GetSteer ingForce ( ) c a l l s to save CPU cy c l e s66 ∗/67 protected override Vector2 GetSteeringForceBetween ( )68 {69 i f ( wallsBetween==null | | wallsBetween . Count==0)70 return Vector2 . ze ro ;7172 Vector2 f o r c e=Vector2 . ze ro ;7374 Vector2 cP ;7576 LinkedListNode<LineSegment2D> f e e l e rBetween=fee l e r sBetween .

F i r s t ;77 LineSegment2D f e e l e r ;78 LineSegment2D lWall ;7980 /∗81 i t e r a t e through a l l l a t e l y c ro s s ed wa l l s82 and check i f the f e e l e r s s t i l l c r o s s them83 ∗/8485 foreach ( BorderEdge wa l l in wallsBetween )86 {87 // cur rent wa l l and f e e l e r88 lWall=new LineSegment2D ( wal l . FromPosition ( ) , wa l l . ToPosit ion

( ) ) ;89 f e e l e r=fee l e rBetween . Value ;90 i f ( f e e l e r . DoesLineSegmentCross ( lWall , out cP) )91 {92 AvoidWall ( wal l , f e e l e r , cP , ref f o r c e ) ;93 }94 f ee l e rBetween=fee l e rBetween . Next ;95 }96 return f o r c e ;97 }98 }

The next listing describes a rule used for the dynamic scripting algorithm.It makes a group flee from an enemy cluster:

1 public class RetreatRule : Rule {2 Vector2 pos ;34 //weight : 80 , p r i o r i t y : 8 , f r equency : 35 public RetreatRule ( ) : base (80 , 8 , 3 )6 {7 }89 public override bool ExeCondition (MachineGroup gr )10 {

63

11 /∗ I f the c l o s e s t c l u s t e r i s in the range ’ cRange ’12 the cond i t i on o f t h i s r u l e i s s a t i s f i e d ∗/1314 Clus te r c=gr . PlayerOwnerAI . GetClose s tC lus te r ( gr . GetPos i t ion ( ) )

;15 f loat cRange=c . GetPointCount ( ) ∗1 .2F+15;1617 i f ( c==null | | ! VectorOperat ions . AreVectorsInRange ( gr . GetPos i t ion

( ) , c . GetPos i t ion ( ) , cRange ) )18 {19 return false ;20 }2122 /∗Calcu la te the po s i t i o n that the group23 should move to in order to avoid the c l u s t e r ∗/2425 pos=gr . GetPos i t ion ( )+(gr . GetPos i t ion ( )−c . GetPos i t ion ( ) ) .

normal ized ∗50 ;26 return true ;27 }2829 protected override void Execute (MachineGroup gr )30 {31 //move to the t a r g e t p o s i t i o n32 UnitCommands . NormalMoveTo( gr . Units , pos ) ;33 }34 }

64