Thesis Project The Use of Potential Fields as a Navigation System for Autonomous Helicopters in 3D Games.

(1)

Author: Mohsen S

ADEGHI

G

OL

Supervisor: Johan H

AGELBÄCK

Examiner: Sabri P

LLANA

Semester: VT 2015

Thesis Project

The Use of Potential Fields as a

Navigation System for Autonomous

Helicopters in 3D Games.

(2)

Abstract

The use of artificial potential fields is beneficial in most two dimensional environments but they are bound by limitations. Introduction of the third dimension eradicates some of the limitations and brings about a set of new problems. If the emergent problems are solved then the new approach can give way to smarter helicopters and consequently a new game-play experience or possibly safer flight.

This thesis aims to solve the emergent problems and proposes a new solution for guidance of autonomous helicopter agents in 3D games based on artificial potential fields. This new approach is compared to the most used alternative the A* pathfinding algorithm. Our experiments reveal that potential fields is a formidable alternative for navigation of helicopters. It can perform many times faster than the A* alternative and has lower rate of collision.

Keywords: Artificial Potential Fields, A*, Helicopter, 3D games

(3)

Preface

Thanks to Dr. Johan Hagelbäck for his support, supervision and contribution.

(4)

Glossary

3D Three Dimensional.

A* Is a graph search algorithm. It is widly used for pathfinding in computer games.

AI Artificial / Agent Intelligence (context dependent).

CPU Central Processing Unit.

DC Death by Collision.

MIT Massachusetts Institute of Technology.

PF Potential Fields.

PFA Is a navigation system utilizing the potential fields approach along with the A*

search algorithm.

(5)

List of Figures

2.1 A* in action, source node (Pink), Parent Nodes indicated by arrow (edited

image with permission from the author)[11]. . . 3

2.2 A potential field. . . 4

2.3 A potential fields. The product of a field for the goal along with a repelling obstacle field in the center. . . 5

4.4 A unit with its underlying physics model. Red dots are points of contact [15]. . . 7

4.5 Raw height map on the left, its resulting height map terrain on the right (rendered using neoaxis engine) [15]. . . 8

4.6 Local (left) and global (right) bounding boxes of an object in 3D space [17]. 8 5.7 Small test map, N avBounds shown by blue lines. With blocks containing a collision object shown as black [15]. . . 10

5.8 Coordinates of a block containing a static model of a robot near the zero point axis [15]. . . 11

5.9 Small test map with blocks containing a collision object shown as black [15]. . . 12

5.10 The test map of Figure 5.9. Sections shown as black contains blocks of size 3 [15]. . . 13

5.11 A crane tower within a section [15]. . . 14

5.12 Weight calculation for static and moving obstacles . . . 17

5.13 Weight calculation for navigation towards enemy units . . . 18

5.14 Provision of Optimum . . . 18

5.15 Our helicopter with its axis of rotation visible [15]. . . 21

5.16 Our helicopter when in a not perfect scenario [15]. . . 23

6.17 Showing the obstacle field in experiment three [15]. . . 24

6.18 Experiment four underway with 80 helicopter agents using Potential Fields [15]. . . 25

6.19 Experiment four underway with 80 helicopter agents using A* [15]. . . . 25

8.20 Chart made from results of experiment 1, showing average of Kills and Deaths of helicopter groups. . . 29

8.21 Chart made from results of experiment 2, showing average of T ickT ime for helicopters. . . 30

8.22 Chart made from the result of experiment 3, showing average of Death by Collision of helicopters. . . 31

8.23 Results of 30 helicopters fighting for each side. . . 32

List of Tables

7.1 Results of experiment 2 . . . 26

7.4 Results of experiment 4. Error bar of +-1% CPU and 2MB memory. . . . 28

8.5 Mean Tick Time from the result of experiment 1. . . 29

8.6 Mean Tick Time from the results of experiment 1. . . 30

(6)

1 Introduction

This thesis investigates the challenge of using the potential fields approach for navigation of autonomous helicopters in 3D games. New approaches in game artificial intelligence can be of great value and lead to higher performance of the helicopters using less resources. Alternative approaches spend a significant amount of processing power and at times are not suitable for real time applications and can greatly influence the performance of the helicopter [1].

Potential fields is very popular in the field of robotics as an approach for obstacle avoidance [2]. Goals produce an artificial attractive field and obstacles a repelling one.

The sum of the attractive and repelling fields would be a potential field which the robot would then use to glide around obstacles toward the goals [3]. This thesis argues that potential fields can be a feasible approach for pathfinding and obstacle avoidance of autonomous helicopters in 3D games. Moreover the main contribution of this thesis is design, implementation and analyses of a navigation system called PFA, adopting the potential fields approach along with the A* pathfinding algorithm. The following research questions are addressed:

RQ1 How feasible is the use of potential fields as a navigation system for intelligent helicopter agents in 3D games?

RQ2 What are the emergent problems that occur with the use of potential fields approach in three dimensional space?

Our investigation will be limited to comparison of the adopted potential fields and A*

approaches and their corresponding agent performance.

1.1 Thesis Organization

Chapter 2 introduces and describes the main theory needed for this paper. Chapter 3 describes our methodology. Chapter 4 introduces engine specific concepts relative to our method. Chapter 5 describes our solution and concludes the bulk of this paper. Moreover it includes our representation of the world the PF and A* navigation systems, agent intelligence and a brief look at helicopter controls. Chapter 6 describes our four experiments.

Chapter 7 contains the raw results. Chapter 8 concludes our analysis and finally Chapter 9 and 10 our discussion and conclusion.

(9)

2 Background

The background consists of technical review of pathfinding and obstacle avoidance in computer games. This chapter provides the reader with sufficient information to grasp the concepts.

2.1 Pathfinding

Pathfinding is the process of finding a path between two nodes in a graph and an important subject in the field of computer science [4]. It is widely used by intelligent agents in computer games. Any agent not using a pathfinding process in its movement planning is doomed to fail or get stuck [5]. An important aspect of pathfinding in games is to find a short path while avoiding obstacles. Most pathfinding solutions are not computationally cheap and take polynomial time to compute [6].

Time complexities of pathfinding algorithms are critical in real-time applications.

Moreover the search for faster and more optimized solution is still on going [7]. Nearly all pathfinding solutions resembles the shortest path problem in a graph. While there are advances in better and faster star algorithms, the main principle still remains the same [8].

There are many pathfinding algorithms available each having certain characteristics. As always there is no perfect choice and the tradeoffs should be considered for each application. Below is a brief review of solutions for finding obstacle-free paths for intelligent agents of computer games.

2.2 A*

A* is the most commonly used pathfinding algorithm for computer games [9]. The algorithm works by using two lists to find a path. The first list is called F rontier (or sometimes called open list) and it contains all the possible choices to visit, at any given time [4]. Similar to a priority queue, F rontier is designed in a way that can provide the next best choice to visit. Choices are represented as nodes each corresponding to a cell or a block. At each visit, the surrounding nodes are created and if they are walkable they will be added to the F rontier list. The visited node is then removed from F rontier and kept in the second list called Closed. Each A* node holds certain information [11] [10]:

Heuristic: States the estimated distance of each node to destination node.

Cost: States the actual distance from the start node to the current node.

T otal Cost: Calculated as F = Heuristic + Cost P arent A reference to the parent node.

Getting the next best node to visit from the F rontier list is done is by finding the node with the lowest Total Cost. This will yield the closest node to the destination. It is worth noting that the significant factor in the T otal Cost is the Heuristic of the node.

Heuristic is the Greek word for "discover" and is a sufficient estimation of distance for guiding the algorithm to continue search towards the goal. [11] [10].

At each visit, Heuristic and Cost of surrounding nodes will be calculated and parents set to the selected node (brown nodes in Figure 2.1). Surrounding nodes will then be added to the F rontier list (pink nodes in Figure 2.1) containing candidates for next node to visit. The algorithm continues until the destination node is detected in surrounding nodes. At which point iteration over the destination node’s parents would yield the found

(10)

Figure 2.1: A* in action, source node (Pink), Parent Nodes indicated by arrow (edited image with permission from the author)[11].

While A* can be the perfect choice for narrow passages and mazes, it has significant disadvantages when it comes to open worlds [4]. Moreover A* has a big overhead per calculation, and might lead to long calculation times. A brief look at the algorithms’

pseudo code indicates that for optimum results a custom data structure must be utilized containing frontier nodes. This data structure should have O(1) insertion time, with the fastest operations for finding and deleting the node with the lowest Total Cost.

(11)

2.3 Potential Fields

The concept of potential fields might be a bit hard to grasp. A simple example might help.

What happens when a loose rock on top of a mountain is released? Naturally it moves tumbling down the mountain until it reaches a flat surface. We know that acceleration requires energy. As a result we can say that the rock had some potential energy when it was on top, but lost most of it when it reached the flat surface.

Potential fields resembles the above example for pathfinding and obstacle avoidance.

Notice that the goal is the center of the earth with gravity as its attracting field. Also note that we are relating energy to the rock’s position and not the rock itself. In a potential fields approach every position has a similar energy value called W eight. At each position agents utilizing this approach compare the weights to move to a new position with lower potential energy. This will continue until the goal is reached or the agent gets stuck in a position with the lowest energy [12]. The rock reaching a flat surface represents such a scenario. The rock is always stuck as it can never reach the center of the earth.

Figure 2.2: A potential field.

Figure 2.2 shows the potential field of a single goal located on the bottom left. Note that weight values for this field are calculated and presented as the height. It is easy to observe that any object on this field will be pushed down towards the goal. What might not be apparent is that the weight is a function of distance to the goal.

A potential field alone cannot provide obstacle avoidance as there can be obstacles along the falling path of the object that are not considered. To avoid them we need to somehow divert the object’s falling path away from them. Given that the object follows the lowest energy position we can achieve avoidance by increasing the weight values around the obstacles. This can be done by representing obstacles as repelling fields [3].

A repelling field increases the weight values as on object gets closer to the source of the field. In our rock scenario a hill along the falling path is the example of a repelling field.

The rock usually avoids it by going around the hill as it takes more energy to climb over it. Thus to achieve obstacle avoidance repelling fields are maintained over obstacles so that agents would be guided around them. The concept might become clear by looking at Figure 2.3 on the following page.

(12)

Figure 2.3: A potential fields. The product of a field for the goal along with a repelling obstacle field in the center.

A crucial part of potential fields is the provision and calculation of weight values.

There are a few possible ways and the correct choice depends on the type of application.

In grid based computer games with stationary field sources it is possible to calculate the weight of all cells once and use it during runtime [3]. As it will be evident such scenarios almost never happens since most games have a highly dynamic world. As a result some field sources might relocate or perish. In such cases recalculation of weights affected by the dynamic field is needed.

Also, most game worlds are not based on a grid, and objects can exist on infinitively many positions. Thus it is hardly possible to calculate weights in advance unless the game world is divided into known sections each holding a single weight value. This idea can be rephrased into having a representation of the world, made out of cells or in our case blocks. One which should be constantly updated because of the highly dynamic environment of the game world.

(13)

3 Method

To answer the feasibility of potential fields in 3D space we have to implement a 3D game where helicopters are controlled by artificial intelligent agents. The agent should then be guided by navigation systems. Thus a PF based along with an A* based navigation system should be implemented so comparisons between the two systems can be made. This will allow us to run experiments to compare the two systems.

Moreover the emergent problems that occur with the use of potential fields shall be identified and reported on the Solution chapter.

The two systems shall be compared by monitoring significant metrics of each helicopter groups when running controlled experiments. Hence in our methodology a single AI is used for both approaches rendering it a controlled variable.

In our experiments we shall change the navigation system guiding the agents as the only independent variable. A helicopter and in general any air unit is very vulnerable to collisions. Thus we can reason that higher collision rate is among the significant factors of an inferior approach. Moreover in most real-time applications computation time is of high importance. As more time gives space for extra procedures aiding the agent to perform better. As a result we have decided to consider the following Collisions, Kills, DeathbyCollision and Avrage Computation T ime as our dependent variables.

Whenever possible we shall keep other factors as controlled variables to the best of our ability. Equality of tick intervals, distance and number of A* nodes and PF Blocks are among a few. Moreover equilibrium of targeting and weapon system of helicopters along with avoiding non-deterministic game mechanics aspects such as critical hit chance are also considered.

As a result We have identified the following significant requirements for our implementation:

- Detection, calculation and persistent storage of static fields and their weights upon creation of a map and its retrieval during the loading process.

- Tracking enemy targets as possible goals.

- Generation of fields during runtime.

- Combination of dynamic and static fields to provide the potential fields.

- Both the A* and Potential Fields approach must be given identical environment data.

- Equal amount of nodes and blocks should be used.

- A common core agent intelligence must be adopted.

- Non-deterministic elements should be avoided.

- Extra functionality avoided to reduce the overheads not related to our investigation.

Moreover interruptions during the experiments will be avoided, and in such case the results discarded. Furthermore since Death metric can be the effect of different causes Death by collision was introduced to isolate it from other causes.

The data gathered for all experiments along with experiment maps and settings are available for the public to examine or replicate. Full source code for the PFA method along with agent AI is available for the public under MIT license. This excludes the helicopter physics in which case the exact version of its class library used for the experiments is available to the public. Thus any researcher or member of the public can study, modify and replicate the experiments along with the PFA solution.

(14)

4 Neoaxis

Neoaxis is a free game engine capable of running real-time simulation of a game world. Its nearly open source giving developers the needed flexibility to freely design and construct any scenario [13]. As with most advance game engines, Neoaxis uses a physics engine to simulate the behavior of moving objects. Moreover Neoaxis provides great flexibility to freely develop any idea into existence [14].

4.1 Unit

In neoaxis Neoaxis a unit is a controllable entity that stays passive unless affected by a controller. Example of units are tanks, cars and helicopters. Units can be controlled by a human player or an artificial intelligence. In both cases control happens by means of sending commands (i.e. key presses on a keyboard). Commands will then get translated into appropriate actions by the unit. An example would be sending the F orward key command to a car unit to stimulate the forward force.

This is both a curse and a blessing. A curse as we must not manipulate the units directly from the controlling entity. And a blessing as we can have different types of controller for the same unit.

A unit can also be a moving entity by utilizing an underlying physics model as seen in Figure 4.4. A physics enabled entity can then be moved around by means of adding forces.

Figure 4.4: A unit with its underlying physics model. Red dots are points of contact [15].

4.2 Height-map Terrain

Height-map Terrain is a piece of artificial land generated from an image called height- map. In a height map every pixel of the image corresponds to a tiny section of the land.

Data on pixels indicate the elevation of the land. In most cases a height-map is a raw 16- bit image, meaning every pixel holds a single byte thus it usually looks gray-scale [16].

To simplify a brighter pixel results in a higher section as seen on Figure 4.5.

(15)

Figure 4.5: Raw height map on the left, its resulting height map terrain on the right (rendered using neoaxis engine) [15].

4.3 Bounds

In the Neoaxis engine Bounds is a set of two vectors in 3D space a minimum and a maximum vector. Together they represent a bounding box. It is important to note that whenever we refer to bounds in this paper the global bounding box is in mind. Figure 4.6 illustrates bounds along with concept of global and local.

Figure 4.6: Local (left) and global (right) bounding boxes of an object in 3D space [17].

4.4 Volume-cast

Volume-cast is a volumetric collision detection method usually provided by the physics engine. This operation needs a volume to check [18]. To simplify take a look at Figure 4.6 above. Running volume-cast over the orange bounds would return the monkey head on the right as the result. Running volume-cast over a new bounds slightly bigger containing even a fraction of the left head would yield both heads presented in the results. Of course this is only true if the monkey heads are set as collision object. When the result of a volume-cast is empty it means the volume in mind is not in collision with any object [19].

The above explanation is oversimplified. For further research about volume-cast please refer to the open dynamics physics engine documentation [19] or Neoaxis API [15].

(16)

5 Solution

Our Solution consists of five parts:

-The block world consist of block representation of static objects in a game map along with its underlying structures.

-Our approach towards use the of potential fields for navigation of agents uses the block world along with its structures.

-Our adaptation of A* pathfinding algorithm that also uses the structures of block world.

-Agent intelligence utilizing A* and PF part of our solution for guidance of helicopters.

-Helicopter control, translations between physics world and agent intelligence.

We shall discuss each part in the following sub-sections.

5.1 Block world

In this section we will discuss our block representation of static objects in a game map and introduce the bounding box of our representation along with block size defining its resolution. We shall discuss the need of a new coordinate system with the introduction of block size. Moreover we will identify the underlying methods for converting coordinates to and from this new system.

Now it is time to consider what artificial intelligence is. Is it anything but a way of making a computer "Think"? Then what is thinking? Is it anything but reasoning about a perception? The block representation of our solution is the perception of the agent intelligence. A wrong representation of the world will result in wrong perception and reasoning. Thus it is an important part our solution.

(17)

5.1.1 Resolution and Operational area

Before we begin lets consider a few calculations. Suppose we have a map sized (X,Y) with a mountain in the center with height Z. Then a direct block world representation would have blocks of size (1,1,1) with absolute values of axes as index. Such representation would require X ∗ Y ∗ Z blocks. Note that a typical map is on the scale of 3km by 3km with 200 meters height difference in terrain. Thus a typical map would require 1.8 Billion blocks. It is immediately clear that the block world needs to be cut down in resolution by adopting bigger block sizes.

With the introduction of Blocksize (b) we define the size of each block in our representation. Now a new problem emerges. Since the absolute value of a position vector no longer corresponds to the representing block a new coordinate system should be created.

As a consequence the underlying methods for conversion between the coordinate systems should be defined.

Before generating the representation of the world we need to know where to begin and how far we shall continue. To solve this N avBounds is introduced as a Bounds value representing the bounding box of our block representation. N avBounds is calculated as the union bounds of every static object including the terrain. Moreover it is extended accordingly to Blocksize to avoid possibility of fractions, as shown in Figure 5.7.

Figure 5.7: Small test map, N avBounds shown by blue lines. With blocks containing a collision object shown as black [15].

N avBounds, Blocksize and the third power of Blocksize conclude the most important variables in our solution. We shall refer to them repeatedly in the rest of this chapter.

(18)

5.1.2 New Coordinate system

Our engine coordinate system consists of three decimal values for each axis with zero point at the center of each map. Hence vectors can include negative axis values. For the new coordinate system we avoided negative vectors altogether. The reason behind this decision shall become clear in later subsections.

The coordinates of a block containing an object is calculated by Equation 1, where pos is engine coordinates of the object.

Cords_b =





b(pos.X − N avBounds.min.X)/Blocksizec b(pos.Y − N avBounds.min.Y )/Blocksizec b(pos.Z − N avBounds.min.Z)/Blocksizec



 (1)

Figure 5.8: Coordinates of a block containing a static model of a robot near the zero point axis [15].

Respectively whenever the engine position vector is needed the center of block is used and is calculated with Equation 2:

pos_c =





Blocksize ∗ Cords_b.X + N avBounds.min.X Blocksize ∗ Cordsb.Y + N avBounds.min.Y Blocksize ∗ Cords_b.Z + N avBounds.min.Z



+





Blocksize/2 Blocksize/2 Blocksize/2



 (2)

Equation 2 is mostly used when a block is considered for setting the movement task of an AI. Moreover its worth noting that Blocksize in both Equations 2 and 1 are subject to change. There will be instances where Blocksize will be replaced in the equation to give us the coordinates of a bigger block. As we shall see in later chapters Blocksize³ will be used for sections.

A careful look at Figure 5.8 and Equations 1 might reveal helpful observations. First that the reference point of engine coordinates is the center point of any map while the block coordinates start from the minimum point of navigation bounds. This is illustrated by yellow and gray dotted lines. Second that the block coordinates correlates with block count in each axis starting from 0. And finally the first part of Equation 2 gives us the minimum vector of blocks volumetric bounds.

(19)

5.1.3 Partitioning Sections

There is another problem with the primitive representation. With a Blocksize of 3, the map will have 67 Million blocks. Given that the minimum data type available is a byte, a single representation will result in 67 MB of memory space used. This is clearly unacceptable and shows that the traditional approach is not feasible and a new one must be adopted.

Increasing the Blocksize might be a temporary fix for this problem, but in general this leads to new sets of problems thus it is not an acceptable solution. Figure 5.9 illustrates an interesting observation. Most of our representation will be allocated for empty space, hence a solution that would only represent the blocks containing collision objects and ignoring the others would be both feasible and beneficial A such approach needs a fraction of memory space allocated for the traditional array based approach. Moreover it will be beneficial since small Blocksizes can be adopted giving us a more detailed representation of the map.

Figure 5.9: Small test map with blocks containing a collision object shown as black [15].

This led us to the adaptation of a custom structure for storage and representation of the block world. The world is divided into square block sections with the size of (b³, b³, b³), for example (27, 27, 27) where b is Blocksize. Each of these sections will then hold an array of blocks. Please note that the array is allocated only when at least a single block is used within a section. This new approach not only helps to avoid storing empty space but also reduces the amount of volume-casts significantly (discussed more in later sections).

Moreover it gives us great flexibility. Firstly the representation of the map is very detailed as small block sizes can be used. Secondly we can now store extra variables such as coordinates in sections without worrying about memory space². This is possible as the number of sections is significantly lower than blocks in any scenario and can be calculated by Equation 3:

#All sections = &

X b³ '

∗

&

Y b³

'

∗

&

Z b³

'!

(3) Similarly the array representing the blocks will be of size (b², b², b²) holding a total

2 In total 6 Bytes for each empty section, for each of 3 coordinates shorts. With Blocksize of 3, approximately 10K sections amounting to 60KB. Negligible compared to 250MB needed to run the most basic map.

(20)

of b⁶ bytes within each section (for example 729). It is necessary to store coordinates in each section for managing the internal blocks.

Figure 5.10: The test map of Figure 5.9. Sections shown as black contains blocks of size 3 [15].

There are few observations worth noticing in Figure 5.10. First, that for every possible section not drawn within the N avBounds (The blue lines) b⁶ blocks are ignored. This leads to a big amount of savings in both memory space and processing time.

Second, with the adaptation of the section approach each chunk of blocks are isolated.

Initially this might seem to make our new coordinate system obsolete and give rise to a new coordination problem, but a closer look reveals that it is already solved. Considering the hierarchy in Figure 5.10. It shows that blocks under sections are similar to sections under N avBounds. Equations 1 and 2 on page 11 are still effective however there is a need to change the variables to the level of hierarchy needed. As an example Equation 4 is introduced as a permutation of Equation 2. Similarly it calculates the center vector of a section in engine coordinates.

pos_c=





b³∗ Cordss.X + N avBounds.min.X b³∗ Cords_s.Y + N avBounds.min.Y b³∗ Cords_s.Z + N avBounds.min.Z



+



 b³/2 b³/2 b³/2



 (4)

The only variable changed is the Blocksize which is replaced with Blocksize³. More- over it is important to note that recalculation with a modified equation is not always needed when changing the levels of hierarchy. As an example section of any given block can be found by the Equation 5 given the block coordinates Cords_b.

Section_Cords=Cords_b.X/b², Cords_b.Y /b², Cords_b.Z/b²T

(5) Similarly index of any block within a section can be calculated by Equation 6 given the block coordinates Cordsb.

Blkindex=Cordsb.X mod b², Cords_b.Y mod b², Cords_b.Z mod b²T

(6) Finally direct calculations for reaching the results of Equation 5 and 6 are also used which we shall introduce in later sections.

(21)

5.1.4 Generating the Static profile

Figure 5.7, 5.9 and 5.10 where all showing a block representation of static obstacles in a map. In this subsection we are covering how such representation is generated.

Unlike cells in a grid based world that can be marked as obstacle by means of the object’s position and size, there is no accurate way to do the same for blocks in a 3D world. Visualization of a tower with a large base can aid in understanding this concept.

There should be several blocks marked on lower levels and fewer ones as we move up, as shown in Figure 5.11. For this reason, bounds of an object cannot give an accurate representation of occupied blocks.

Figure 5.11: A crane tower within a section [15].

Consequently, the generation of this obstacle representation should happen by means of Volume-casts. The outcome of each cast will determine whether a block is free or an obstacle. A primitive approach would be running Volume-cast on every possible block.

This is unacceptable as Volume-cast is not a cheap operation and block count is typically several millions. Thus we have decided to adopt the section approach discussed in the previous sub-sections. Using sections not only avoid excess memory use but also makes it possible to skip the majority of Volume-casts through empty space.

A Recursive method is used starting from the minimum vector of N avBounds. It considers a square blocks with size of b³over a nested loop of X, Y, and Z, extending until the maximum vector of N avBounds. For each square Volume-cast will be performed.

If the results indicate empty space the block will be discarded and the loop will continue with the next block.

If the results indicate any static collision object a new section will be created and kept in a data structure we shall refer to as the StaticP rof ile. Following the creation of each section the recursive call will happen, passing the newly generated section as the argument. This time square blocks of size b within the section will be checked and the result of Volume-casts will be stored directly in the block array of the argument section.

Since StaticP rof ile is among the basic building blocks of our solution it is important to choose a suitable data structure. The major requirement is to access the corresponding section of any given map position in constant time. An Array can be utilized to meet our requirements only if there exists a function index(pos) such that when given a position it returns the array index of the corresponding section. Happily such function exists as

(22)

shown in Equation 7:

index(pos) =





b(pos.X − N avBounds.min.X)/b³c b(pos.Y − N avBounds.min.Y )/b³c b(pos.Z − N avBounds.min.Z)/b³c



 (7)

Upon further examination it becomes apparent that the function closely resembles the calculation of the new coordinate system. In fact this is intentional to avoid having another set of vectors representing the index.

After the generation process we will have a three dimensional array which can be the fundamental representation of the environment. Using the given index(pos) function each vector in the world corresponds to an element in StaticP rof ile. A null element indicates free space. A section indicates possibility of an obstacle and the block array of the section gives full detail of obstacles within its bounds.

5.1.5 Dealing with Terrain

Among the significant issues that arise with the introduction of a third dimension is dealing with blocks under the terrain. Ignoring this issue results in unnecessary computations and undesired agent behavior in certain circumstance, for example when the next move is inside a hill or under the road.

Given that any column of blocks belonging to (X, Y) has at most two blocks intersect- ing with the terrain, we can consider the lower block of the two as a general cutoff point for our navigation systems. This brings forth the issue of identifying the said block. We considered two possible solutions.

A height-map terrain is a dot matrix data structure that represents exactly what we are looking for: the terrain height Z for any given point (X, Y). Using the terrain data directly brings about many complications. Mismatch between height-map resolution and block size requires complex calculations and at times produce erroneous results rendering this solution impractical.

An efficient approach which we adopted is the use of an auxiliary, two dimensional array containing the minimum height Z, and the cutoff point for any given (X, Y). Similar to StaticP rof ile this array, referred to as T errainP rof ile, is built once and kept in memory during runtime of the game.

Since every block belongs to a section, by exclusion of sections blocks are automatically excluded as well. Thus T errainP rof ile is built such that it gives the index Z for any column of sections (X,Y) corresponding to the last valid section. Having sections as cutoff point gives several benefits but also raises a problem.

Indexing of T errainP rof ile and the StaticP rof ile will become identical. This is a major benefit concerning dynamic generation of fields and A* nodes, where the weights and costs should be calculated with respect to the relative height from the terrain (see later sections). Moreover there will be no additional build process needed as most of the calculations are done during generation of the static profile. Recall that before a section is made its bounds are checked for static objects. The result of each check can also indicate the type of static object. If the terrain is among the results then the Z value of the section will be used for the T errainP rof ile.

The problem with this approach is dealing with blocks under the terrain within each section. This can be solved by assigning a special value to them which does not require

(23)

additional data structures. Similarly this assignment is done during the generation process. In our solution a value of 255 in block array of each section represents a block which is under the terrain.

To summarize: N avBounds defines possible area of detection and processing whereas T errainP rof ile sets the operational area limits within it. Thus it is now possible to define exclusion of a section. By means of checking whether the section is within our bounds and if the section is above (or equal to) the T errainP rof ile.

5.2 Potential Fields

In this section we will discuss our approach for using potential fields. First we introduce F ieldSection as the building block of all fields similar to the previously described section. Then we describe P F Sources list and its necessity for creation of fields. Finally we explain how the provider uses the underlying structures of block representation (such as StaticP rof ile) to generate fields at runtime and provide it to agents.

5.2.1 Runtime generation of fields

Now that the static part of our solution is defined it is time to provide the dynamic fields.

Because of Highly dynamic environments along with large amount of blocks in 3D space we have decided to depend completely on runtime generation of fields.

In our solution field requests from the provider is limited to the surrounding blocks of an agent. Hence it is sufficient for the provider to only handle such requests. But, demonstration purposes along with the possibility of further expansion made us design for more flexibility. As a result our provider requires the agent to specify the size of the field requested.

Thus when a request is placed, the provider generates an empty temporary field with equal size as the bounds specified. This temporary field will then go through a nested for- loop of weight calculations related to the type of field requested. Finally the temporary field is returned as the result.

Asides from providing fields our provider also needs to keep a list of all field affecting entities on the map, ranging from moving obstacles to enemy units. This list which is conveniently called P F Sources is essential for generation of the fields. P F Sources is constantly checked and cleaned for validity (for example when an enemy unit dies).

Similar to sections containing blocks in the StaticP rof ile, blocks in potential fields are partitioned into structures of the same size (b³). These structures are called F ieldSections and contain a single global weight and a reference to a possible static section. Our nested for-loop generates F ieldSections within the bounds and calculate their weights by passing them through various methods. These methods are limited to increasing or reducing the weight value only.

(24)

5.2.2 Obstacles weight

A common factor for all field types is the influence of obstacles. Both dynamic (moving) and static obstacles in the vicinity of the block in question should increase the weight, de- creasing the chance of the block being selected as optimum. In our solution the influence of obstacle factor is calculated as shown in Figure 5.12:

INPUT: A F ieldSection.

OUTPUT: Weight value of F ieldSection modified according to obstacles around it.

procedure OBSTACLES_WEIGHT(F ieldSection) for Section c in sorounding sections do

if c is obstacle then

Weight += BlockSize + 1 end if

end for

Range = BlockSize³* 3 for moving obstacles D do

Distance = D.Position - F ieldSection.center if Distance < Range then

Weight += Range - Distance;

end if end for end procedure

Figure 5.12: Weight calculation for static and moving obstacles

The section c is defined as an obstacle if it exists in the StaticP rof ile. BlockSize + 1 is carefully selected so that a head-on collision with a 90 degrees cliff will be avoided.

Range defines the propagation for dynamic obstacles. Its multiplier (3) defines how many F ieldSections away that will be affected.

5.2.3 Enemy weight

In our solution obstacles produce a positive field and goals a declining one. For example the tactical field is calculated as shown in Figure 5.13:

Note that when two or more PF sources affect a given F ieldSection the minimum value will be selected thus the closest enemy will be predominant. Since the calculation is directly affected by distance a negative weight value is never valid. Calculation of F ieldSection center position can be achieved by Equation 2 on page 11.

(25)

INPUT: A F ieldSection.

OUTPUT: Weight value of F ieldSection modified according to distance of enemy units.

procedure ENEMY_WEIGHT(F ieldSection) Weightrais = MaximumValue

for Enemy unit U do

Distance = U.Position - F ieldSection.center if Distance < PFDR then

if Distance < Weightrais then Weightrais = Distance;

end if end if end for

Weight += Weightrais end procedure

Figure 5.13: Weight calculation for navigation towards enemy units 5.2.4 Provision of Optimum

In our solution the optimum is the block having the minimum weight within a field. In most cases the field in question consists of 27 blocks surrounding the agent, in which case the optimum represents the next best position for the agent. At times a high number of blocks along with existence of different heights make it possible for more than two blocks to have the same weight value. In this case one of them is selected at random as the Optimum block. The algorithm for the provision of optimum is shown in Figure 5.14:

INPUT: An array of F ieldSections.

OUTPUT: A single F ieldSection with the lowest weight value.

procedure OPTIMUM(F ieldSection[ ]) Optimum = null

ListofEquals

for cBlock in F ieldSection[ ] do

if cBlock.Weight < Optimum.Weight then Optimum = cBlock

Flush ListofEquals

else if cBlock.Weight equals Optimum.Weight then Add cBlock to ListofEquals

end if end for

if ListofEquals is not empty then

Optimum = Random of ListofEquals end if

Provide Optimum;

end procedure

Figure 5.14: Provision of Optimum

(26)

5.3 A*

In this section we will discuss the adopted A* approach for our navigation system. We shall also describe cost and heuristic calculations for nodes. Finally we will explain how the path provider uses the underlying structures of block representation (such as StaticP rof ile) to generate a path at runtime and provide it to the agents.

5.3.1 Generation and provision of paths

Any A* algorithm adopted for pathfinding in computer games needs a representation of the game world for traversing. Waypoints or navigation meshes are the two most common ways of game world representation [9]. While the waypoints approach seems to be promising for our scenario we cannot adopt it since, as stated in the requirements, both PF and A* navigation systems should be given the same representation of the game world.

Thus we shall adopt a way to use the StaticP rof ile along with sections as the representation for our A* algorithm. A custom structure called AN ode is used. Each AN ode takes a square block in our representation with the size of b³, similar to sections and F ieldSections. The center of this block is considered a waypoint. Nodes outside the bounding box of our navigation system as well as the ones below terrain are ignored.

Any node belonging to a section containing obstacles is marked and ignored, thus we can generalize our solution as a waypoints approach.

Unlike the potential fields method the A* algorithm is agnostic towards agents and their factions. Provision of a path using this approach requires only a source and a destination vector, hence it is the responsibility of the agent intelligence to provide the desired destination. Finally a path is not always guaranteed and the agent intelligence should be able to deal with this scenario.

(27)

5.4 Agent Intelligence

The helicopter agent intelligence in our solution has three levels of hierarchy implemented using inheritance. The first level called Intellect deals with underlying engine and unit relations as well as handling and passing control commands (see sub-section 4.1). The intellect module will not be discussed further in this report.

The second level, called PFAHeliAI, deals with helicopter controls, target acquisition and movement based on a single vector. It also contains the major part of our agent intelligence excluding anything specific to each navigation system.

The final level consists of two different AIs each tasked only with the provision of a movement vector. They are called AstarHeliAI and PFHeliAI utilizing the A* and potential fields navigation system respectively.

This design was adopted to minimize the effects of agent intelligence on our evaluation. With a unified AI dependent on a single variable the effects of the navigation systems can studied while ignoring AI as a constant.

5.4.1 Second level

This level is a fairly simple AI with only two states, Attack and Move. The agent is always in move state, unless an enemy is in range and within sight. If so the agent will transition to Attack state.

Regardless of state and the kind of AI a closest target is always maintained at this level. This target is passed on to gun AI for shooting and is also used for A* destination vector.

Regardless of state the AI considers helicopter Position and Rotation against the move vectorto calculate the correct values for helicopter controls. This will be discussed more in the following sub-section. For now it is important to understand that the helicopter is constantly trying to reach the move vector.

During the Attack state any new assignments to the move vector will be ignored, thus the helicopter will hold its position. If the target runs away or hides behind any object then the move state will be activated again. During move state the AI accepts new move vectorfrom the higher levels.

5.4.2 Final levels

The only task for PFHeliAI is to provide a single movement vector and therefore only needs a simple structure. On every tick the AI checks if the helicopter has moved into a new F ieldSection. This check happens by calculating the section coordinates using Equation 7 on page 15 and comparing it to the coordinates of the previous tick.

If the helicopter is in a new section then a request will be sent to the potential fields’

provider. The provider will then return the tactical field surrounding the helicopter. In most cases 27 F ieldSections will be provided unless the requested tactical field is near the edge of the world. Now all that is left is to select the optimal F ieldSection. This can also be done by the potential fields’ provider as discussed in the previous chapter.

Finally the center vector of this optimum F ieldSection is calculated using the Equa- tion 2 on page 11 and is passed down to the second level as the move vector.

AstarHeliAIis similar to PFHeliAI and is also only responsible for providing a single movement vector (to be used by lower AI levels). It treats a list of AN odes as the path.

On every tick it checks if the path is empty. If so a request will be sent to the A* provider sending the current position of the helicopter and the target (provided by the second level).

(28)

When the helicopter enters a new section contents of the path will be checked for an AN ode with the same coordinates as the section in the current path, in other words checking if the helicopter has reached a waypoint in our path. If so any AN odes up to and including the AN ode found will be removed.

It is worth noticing that there are a few factors that can invalidate the path. This will result in disposing of path and requesting a new one. Among them is when the above check is done and the new section is not a waypoint in our path. Such a case indicates that for some reason the helicopter has deviated from the path and has entered an unintended section. Another invalidating factor is the movement of the target. Thus the target position is also under constant monitoring for when it enters a new section.

Finally the center vector of the last AN ode in our path is calculated using the Equa- tion 2 on page 11 and is passed down to second level as a new move vector.

As a final note in both cases only the request call for paths and fields are measured for our evaluation.

5.5 Helicopter Controls

Our helicopter physics resembles simulation of a real world helicopter. Its unit has three main controls along with the collective. Each control is controlled by an autopilot like intelligence that only asks for the needed angle of each axis. As an example when giving an angle value of 0 to all controls results in stabilization of the helicopter. This is true even if an external force is added to the helicopter (wind or a bullet). The autopilot will try to compensate by modifying controls to reach and maintain the angle.

Figure 5.15: Our helicopter with its axis of rotation visible [15].

Respectively if an angle of -15 (345) is given to the pitch control (rotate forward 15 degrees on the green axis in Figure 5.15) the autopilot will try to maintain this pitch angle.

Doing this will in turn change the direction of the main rotor force and move the helicopter forward. Similar scenarios apply for the roll control when values will "roll" the helicopter causing it to move to the sides. The pitch and the roll controls represent the cyclic which is the main stick in a helicopter (more on page 10 [20]).

(29)

(Check page 38 on [20]) we always want to align the helicopter with the direction of movement. Finally the collective (page 12 on [20]), to simplify let’s consider it only affecting the height of the helicopter.

Now that the controls are identified it is time to move to the problem at hand. How can we calculate the appropriate control values to pilot the helicopter to the desired vector?

A primitive way which surprisingly is still being used in game projects is to control yaw (blue axis in Figure 5.15) towards the move vector. If the direction is within a degree of accuracy then pitch the helicopter forward to reach the move vector.

There are however problems associated with this approach. The smallest corrections on position of the helicopter will require change of direction. This can lead to unnecessary turns while holding position. It also produces step by step Boolean like flight. But before we discard it lets examine it in more detail to see if we can find a better approach. First lets answer the question of how we can calculate the required angle based on a vector?

Dif f_P = M ove_P − Heli_P (8)

ϕ = arctan(Dif f_P.Y, Dif f_P.X) (9)

To solve the problem we simply deduct the position of our helicopter from the move vector, as seen in Equation 8. The resulting vector (Dif fP) is a representation of a line starting from our helicopter that gives the direction to move vector. We can easily extract our heading from this direction vector by calculating ϕ in Equation 9. Note that ϕ will be in radians.

A direct calculation is usually avoided since more metrics will be extracted from Dif f_P. For example the length of this vector |Dif f_P| is our distance to move vector.

We also need to consider for how long the helicopter shall move forward to reach the point. A primitive approach is to continue moving forward using a fixed pitch angle until the helicopter is at a certain distance from the point. This approach is by itself useless but we can extract the affecting variables from it. We can observe that the speed should be inversely related to distance otherwise the helicopter will pass the move vector. We also know that helicopter pitch controls the speed. Thus we can formulate the problem of how to calculate the correct pitch angle needed for moving the helicopter to move vector?

To solve it we had to look for a function giving us an increasing, concave down output.

The pitch angle ψ for forward movement when the helicopter is facing the move vector is calculated as seen in Equation 10.

ψ = arctan(|Dif f_P|/dAngle) ∗ dAngle (10) Note that dAngle in Equation 10 should be a non-zero value. Moreover it represents the desired pitch for forward movement. The resulting ψ is in degrees starting from 0 to π/2 ∗ dAngle depending on the distance |Dif f_P|. Note that ψ is always positive thus can only be used with the primitive approach. If used directly for pitch control, passing the move vectorwill result in the helicopter moving away endlessly.

In this approach, by turning the helicopter we are neutralizing the effects of rotation.

This is necessary for vehicles limited to one axis of drive like a car or a tank. Helicopters on the other hand can also move sideways. Thus there is another way for reaching the move vector, one that does not require the helicopter to rotate. Instead of changing the rotation we can include it in our control calculations to yield values affecting both cyclic controls.

(30)

Note that by calculating the length of Dif fP another neutralization happen which merges the distances in each x,y and z axis to a single value. This is problematic and should be avoided. A simple example would be a helicopter 4 blocks under the move vectorperceiving that it should move 4 blocks forward. As a result we can now say that Z value of Dif f_P represents the height difference and should be used by the collective.

Consequently we are left with X and Y of Dif f_P to control the two cyclic controls.

In a perfect scenario when the helicopter is absolutely facing the move vector, the X value of Dif f_P represents the longitudinal distance and Y value the lateral but the helicopter is almost never in such a scenario. Thus we can present a new problem. how can we affect Dif fP so that the above statement will always hold?

Figure 5.16: Our helicopter when in a not perfect scenario [15].

The answer is quiet simple. We should just rotate Dif fP according to the rotation of the helicopter which is done by the Equation 11. There is also another solution using sin and cos but we thought this is more intuitive.

Dif f_{P r}= Dif f_P ∗ HeliRotation⁻¹ (11) Now that Dif fP ris calculated we can use it along with permutations of Equation 10 for our cyclic controls.

Ψ = arctan(Dif fP r.X/pitchAngle) ∗ pitchAngle (12)

θ = −arctan(Dif f_{P r}.Y /rollAngle) ∗ rollAngle (13) We now have all that is needed to constantly fly the helicopter towards the desired point. Angles of Ψ and θ are calculated using Equations 12-13 and will be used for pitch and roll controls. Z value of Dif fP will be passed to the collective for height control.

At the same time the AI has the freedom of setting any heading with no restriction over movement. Either towards the enemy for rocket alignment or towards the move vector using Equation 9 for higher movement speed.

(31)

6 Experiments

For our evaluation we have conducted experiments using test maps. Each map is designed to test a different aspect of the navigation system.

Experiment one consists of helicopters fighting each other in two factions. The map is obstacle free and its terrain is leveled. The aim of this experiment is to monitor the effects of pathfinding on tactical performance of the helicopter, meaning the Death and Kill metrics. The AI for the helicopters is evenly distributed per faction to achieve a balanced game.

Figure 6.17: Showing the obstacle field in experiment three [15].

Experiment two consists of fewer helicopters fighting each other in a larger map. He- licopter bases are placed diagonally to achieve longer distance since increased distance might affect the performance of navigation systems.

Experiment three uses the same map as experiment two but has an obstacle field with block size 3 in the center of the map (see Figure 6.17). Each of the obstacles takes up a section. Since the helicopter bases are placed diagonally the obstacle field is always the region where helicopters encounter the enemy. Also, since the map is fairly large the helicopters need to travel a large distance and thus they enter this region with high speed.

As a result the Death by Collision metric is compared in this experiment.

Finally experiment four is designed to monitor the resource usage such as memory space allocation and CPU usage of each approach. It uses a small map with 80 helicopters fighting each other. This experiment is repeated several times to extract results for each aspect of our solution. Figure 6.18 and 6.19 on the following page were made during repeated runs of experiment four.

(32)

Figure 6.18: Experiment four underway with 80 helicopter agents using Potential Fields [15].

Figure 6.19: Experiment four underway with 80 helicopter agents using A* [15].

(33)

7 Results

This chapter describes the results of our experiment. Please note that experiment one, two and three ran for the duration of 5 minutes. Also note that in every table "Tick time" is in micro seconds and DC is short for Death by Collision. It is important to mention the experiments were ran several times and each time similar consistent results were achieved.

7.1 Experiment Two

Table 7.1 shows that helicopters using the A* approach use almost 5 times the processing time compared to the PF approach.

Table 7.1: Results of experiment 2

# AI Type Faction Collisions Kills Deaths DC Tick time

0 PF AI Good 0 2 0 0 9.596

3 PF AI Good 0 7 0 0 13.827

4 PF AI BadF 0 4 0 0 9.311

7 PF AI BadF 0 5 0 0 9.158

1 A* AI Good 1 1 8 1 41.994

2 A* AI Good 1 3 9 1 37.054

5 A* AI BadF 0 4 7 0 42.213

6 A* AI BadF 0 2 6 0 44.892

7.2 Experiment Three

Table 7.2 shows high amount of collisions and Death by collisions for both helicopter groups.

0 PF AI Good 5 0 3 0 5.804

3 PF AI Good 6 1 3 1 6.177

4 PF AI Bad 15 0 4 4 6.240

7 PF AI Bad 12 2 4 0 7.381

1 A* AI Good 14 4 6 4 73.318

2 A* AI Good 14 2 7 5 82.683

5 A* AI Bad 16 4 8 7 66.963

6 A* AI Bad 6 4 4 1 44.513

7.3 Experiment One

Table 7.3 on the next page shows the result of experiment one. During the testing no PF helicopter died as a result of collision while this happened for a few of the A* helicopters.

(34)

0 PF AI Good 0 5 4 0 7.446

6 PF AI Good 0 8 2 0 6.375

8 PF AI Good 1 7 4 0 8.699

10 PF AI Good 0 3 3 0 9.066

12 PF AI Good 0 5 4 0 7.781

30 PF AI Good 0 4 5 0 8.292

32 PF AI Good 0 0 5 0 7.744

34 PF AI Good 0 6 4 0 7.355

36 PF AI Good 0 6 4 0 9.405

38 PF AI Good 0 5 5 0 8.054

14 PF AI Bad 0 6 3 0 10.182

16 PF AI Bad 0 2 3 0 10.224

18 PF AI Bad 0 5 3 0 9.891

20 PF AI Bad 1 1 5 0 14.125

22 PF AI Bad 0 10 3 0 6.658

26 PF AI Bad 1 6 4 0 10.261

27 PF AI Bad 0 5 4 0 9.842

28 PF AI Bad 0 14 2 0 13.400

2 PF AI Bad 0 2 4 0 7.844

5 PF AI Bad 0 4 3 0 8.888

1 A* AI Good 11 7 6 0 21.640

7 A* AI Good 7 6 7 0 22.741

9 A* AI Good 10 7 6 1 27.790

11 A* AI Good 6 2 7 2 24.289

13 A* AI Good 15 4 7 1 21.796

31 A* AI Good 8 3 7 0 18.268

33 A* AI Good 9 3 8 1 21.728

35 A* AI Good 8 8 7 1 25.094

37 A* AI Good 8 4 7 0 20.138

39 A* AI Good 3 6 8 1 23.503

3 A* AI Bad 7 4 7 2 21.944

4 A* AI Bad 6 4 7 1 51.985

15 A* AI Bad 7 6 6 0 53.623

17 A* AI Bad 3 6 7 1 22.047

19 A* AI Bad 4 5 6 0 22.963

21 A* AI Bad 6 4 8 0 56.627

23 A* AI Bad 6 6 7 0 53.651

24 A* AI Bad 1 1 7 0 22.506

25 A* AI Bad 5 6 7 0 19.987

29 A* AI Bad 7 5 7 1 23.100

(35)

7.4 Experiment Four

Note that a new entity called dummy AI exists in the Table 7.4. This is an artificial intelligence that gives random way points as move tasks to helicopters. The reason why this was included is to measure the resources used for the unified base AI.

Table 7.4: Results of experiment 4. Error bar of +-1% CPU and 2MB memory.

Resources CPU Usage Memory Use Collisions

Empty map No PFA 4 % 317MB 0

Empty map PFA 4 % 319MB 0

No AI 7 % 323MB 0

Dummy AI 24 % 343MB 94

A* AI 32 % 345MB 47

PF AI 29 % 352MB 6

(36)

8 Analysis

In this chapter the analysis of the data obtained from the experiments is presented. The purpose of this research is to answer the feasibility of potential fields in 3D space. As a result have we decided to compare our approach of potential fields with the most used alternative A*. The two systems are compared using different performance metrics of agents utilizing each system. Consequently we have decided to consider Collisions, Kills, DeathbyCollision and Avrage Computation T ime metrics in our analysis. These metrics are extracted during the experiments and are presented in the results section.

8.1 Experiment One

Figure 8.20 shows that while the average Kills of both groups are fairly close the average Deaths differ quit a bit. Note that the average Deaths for A* group is higher than PF Kills, telling us that there is another factor at play causing this effect. The chart also shows that both groups are performing equally when attacking.

Figure 8.20: Chart made from results of experiment 1, showing average of Kills and Deaths of helicopter groups.

Considering the metrics in this analysis we can say that tactical performance of PF is higher in this scenario. Also note in Table 8.5 that PF is using less computation time.

Table 8.5: Mean Tick Time from the result of experiment 1.

NavType Mean Tick Time

A* 28.77025

PF 9.076915

(37)

8.2 Experiment Two

Figure 8.21 shows that the A* group of helicopters use significantly higher tick times compared to the potential fields group.

Figure 8.21: Chart made from results of experiment 2, showing average of T ickT ime for helicopters.

Table 8.6: Mean Tick Time from the results of experiment 1.

NavType Tick Time EX1 Tick Time EX2

A* 28.77025 41.537

PF 9.076915 10.47305

Table 8.6 points to an interesting observation. Compared to the last experiment the the map size is increased which also caused the tick time of A* to increase. As a result we can say that A* computation time is dependent of path length, which is a trivial observation as we know the time complexity³ is dependent of nodes and edges.

Another observation is the slight increase in tick time for the PF group. Theoretically the computation time for real time provision of fields depends on the number of dynamic field sources. We can therefore say that this slight increase is within acceptable margin of error since the number of dynamic field sources has decreased compared to the last experiment.

(38)

8.3 Experiment Three

Figure 8.22 shows that the A* group of helicopters are more prone to fatal collisions.

Such results can be avoided to a certain extent by limiting the performance of A*. Visual observation of the experiment revealed that most fatal collisions of A* group is caused by mistakes that can be avoided. One such mistake is diagonal movement without considering the side block. This mistake is automatically avoided in the PF approach upon calculation of weights. Moreover it is fair to say that the obstacle field in center of the map is quite hard to avoid.

Another factor contributing to high fatality of A* is the characteristic of its path, which in most cases is a straight line making it possible to achieve higher movement speeds. On the other hand the PF approach tends to make the helicopters oscillate left and right in a zig zag pattern thus reducing speed. As a result, higher speed tends to make the helicopter transgress outside of its allowed section and possibly collide and die.

Figure 8.22: Chart made from the result of experiment 3, showing average of Death by Collision of helicopters.

8.4 Experiment Four

Simple subtraction of the values of Table 7.4 on page 28 can yield rough estimate of resource usage. Note that we have been able to run our PFA system with complete block representation of the game world on 2MB of memory allocation. Also note that the 3%

increase in CPU usage from "Empty map PFA" to "No AI" is related to scanning and targeting solution of intelligent guns attached to helicopters. Finally it is possible to extract rough usage of each PF and A* systems by comparing them to the Dummy AI usage.

Please note that Dummy AI also includes the PFA system.

(39)

8.5 Equality and balance

We made sure that the maps are balanced for experiment 1, 2 and 3 where the AIs are fighting against each other. To verify this we assigned helicopters using the same navigation system in each map. Figure 8.23 shows an acceptable balance between factions all using the PF AI. Similar results were achieved for the other maps. It is worth noticing that the slight shift towards good faction in this case is not an indication of map giving advantage to any side, but rather data gathering stopped at the moment when the good faction was winning.

Figure 8.23: Results of 30 helicopters fighting for each side.

(40)

9 Discussion

Among the results presented a surprising trend of potential fields superiority over A* is evident. Thus we have identified that potential fields in 3D games are not only feasible but also a formidable alternative to the most used approach for control of helicopters. Note that such a trend cannot be generalized over all applications of potential fields. Moreover we believe that the introduction of third dimension is a contributing factor to the results.

As the freedom in movement eradicates limitations of potential fields [21].

As always there are exceptions to this trend. The zig zag movement issue can disturb flight dynamics or at times the targeting system. It can also make the approach impractical for other air units. Similarly we believe that potential fields will loose this superiority when adopted for constricted environments such as mazes as it will not have the possibility to pass above the local optima of a region.

A way to eradicate the zig zag movement issue is to favor the sections in the current path of the units. This can be done by affecting the weight values by a calculation involv- ing linear velocity along with the rotation of each unit. Moreover it is a good topic for future improvements.

We have also identified a new helicopter flight control method that is capable of pro- ducing smooth flight even with provision of blocky waypoints, proving that it is not necessary to adopt for a nonholonomic vehicles [22].

During the start of this research project the amount of blocks for representation of a 3D game world was the most discouraging factor. This factor contributed to the storage requirement of obstacle profile since the build time of the profile was in minutes. With the adaptation of the section approach this requirement is ignored as the profile is now generated in a few seconds instead.

Among the most significant limitations of this research project is the provision of small blocks for guidance of ground units. Moreover the lack of path planing is among the limitations but it is generally not utilized with potential fields. Among our unexpected findings is the superiority of potential fields for control of a helicopter and also the possibility to process and store a billion blocks in matter of few seconds with insignificant memory requirements.

Since our helicopter physics closely resembles a simulation it is possible to adopt our solution to real world scenarios.

Finally a recommendation for further research is spatial calculations using fields for helicopter landing.