volition technical manual - web servercsi.ufs.ac.za/courses/bcis1623/2016/practical... · web...

Project Number:XXXXXXXXXX

VolitionTechnical Manual

Name: FE van Greunen

Volition Technical Manual

Volition

Technical Manual

Submitted as partial requirement for the degree of B.Sc(IT) Honours

Department of Computer Science and Informatics

Faculty of Natural and Agricultural Sciences

University of the Free State

Francois van Greunen

2009002011

Project Advisor: Dr E Kotze

October 2013

ii | P a g eFE van Greunen - 2009002011


Table of ContentsList of Figures_______________________________________________________________v

List of Abbreviations_________________________________________________________vi

Acknowledgements__________________________________________________________vi

Chapter 1:Introduction________________________________________________________1

1.1 Introduction__________________________________________________________________1

1.2 Purpose of the Project__________________________________________________________1

1.3 Project Objectives_____________________________________________________________2

1.4 Scope of the Project____________________________________________________________3

1.5 Complications and Challenges____________________________________________________4

1.6 Reasons for doing the project____________________________________________________4

1.7 Limitations of the Project_______________________________________________________5

1.8 Document Overview___________________________________________________________6

1.9 Conclusion___________________________________________________________________6

Chapter 2: Literature Review___________________________________________________7

2.1 Introduction__________________________________________________________________7

2.2 Computer Game Development Technologies________________________________________7

2.3 Artificial Intelligence for Games__________________________________________________9

2.4 Supporting Terminology_______________________________________________________15

2.5 Existing 1st Person 3D Shooting Games____________________________________________20

2.6 Proposed Solution____________________________________________________________21

2.7 Conclusion__________________________________________________________________21

Chapter 3: Requirements and Analysis__________________________________________22

3.1 Introduction_________________________________________________________________22

3.2 Non-Functional Requirements (to be)____________________________________________22

3.3 Functional Requirements (to do)________________________________________________22

iii | P a g eFE van Greunen - 2009002011


3.4 Performance Requirements____________________________________________________23

3.5 Use Case Diagram____________________________________________________________24

3.6 Use Case Descriptions and Scenarios_____________________________________________25

3.7Program States_______________________________________________________________43

3.8 Menu Hierarchy______________________________________________________________44

3.9 AI Finite State Machine Diagram________________________________________________45

3.10 AI Finite State Machine Behaviours_____________________________________________46

3.11 NPC Types__________________________________________________________________48

3.12 Other Game Mechanisms_____________________________________________________49

3.13 Conclusion_________________________________________________________________50

Chapter 4: Architectural Design________________________________________________51

4.1 Introduction_________________________________________________________________51

4.2 Motivation for Technologies and Methodologies Used_______________________________51

4.3 Schedule - Gantt Charts________________________________________________________54

4.4 Class Diagrams_______________________________________________________________56

4.5 Conclusion__________________________________________________________________71

Chapter 5: Source Code and Implementation_____________________________________72

5.1 Introduction_________________________________________________________________72

5.2 Pathfinding Service___________________________________________________________73

5.3 The Pursuing Behavioural State_________________________________________________78

5.4 Terrain Content______________________________________________________________80

5.5 Conclusion__________________________________________________________________82

6. Reference List____________________________________________________________83

iv | P a g eFE van Greunen - 2009002011


List of Figures Figure 3.1 : Overall Use Case Diagram___________________________________________24

Figure 3.2 : Exit Program Use Case______________________________________________25

Figure 3.3 : View About Screen Use Case_________________________________________26

Figure 3.4 : Start New Game Use Case____________________________________________27

Figure 3.5 : View Main Screen Use Case__________________________________________28

Figure 3.6 : View Instructions Screen Use Case__________________________________29

Figure 3.7 : View Controls Screen Use Case______________________________________30

Figure 3.8 : Set Difficulty Use Case____________________________________________31

Figure 3.9 : Select Map Use Case________________________________________________32

Figure 3.10 : Set Map Size Use Case_____________________________________________33

Figure 3.11 : Move Character With Jump Use Case_________________________________34

Figure 3.12 : Move Character Use Case___________________________________________35

Figure 3.13 : Quit Game Use Case________________________________________________36

Figure 3.14 : Pause/Resume Game Use Case________________________________________37

Figure 3.15 : Switch Weapon Use Case____________________________________________38

Figure 3.16 : Place Obstacle Block Use Case_____________________________________39

Figure 3.17 : Use Ammo/Med Facility Use Case____________________________________40

Figure 3.18 : Reload Weapon Use Case____________________________________________41

Figure 3.19 : Shoot Weapon Use Case_____________________________________________42

Figure 3.20 : Program States____________________________________________________43

Figure 3.21 : Menu Hierarchy____________________________________________________44

Figure 3.22 : AI Finite State Machine Diagram___________________________________45

Figure 4.1 : Expected Schedule__________________________________________________54

Figure 23.2 : Actual Schedule____________________________________________________55

Figure 24 : Class Diagram Part 1_______________________________________________56

Figure 4.4: Class Diagram Part 2________________________________________________57

Figure 4.5 : Class Diagram Part 3_______________________________________________58

Figure 4.6 : State System Class Diagram_________________________________________59

Figure 4.7 : Menu System Class Diagram__________________________________________61

Figure 4.8 : Terrain Module Class Diagram_______________________________________62

Figure 25 : NPC Module Class Diagram___________________________________________64

Figure 4.10: Pathfinding Module Class Diagram___________________________________66

v | P a g eFE van Greunen - 2009002011


Figure 4.11 : Player Module Class Diagram_______________________________________67

Figure 4.12 : Finite State Machine Class Diagram________________________________69

Figure 4.13 : Helper Classes Class Diagram______________________________________70

List of Abbreviations XNA – XNA’s Not an Acronym

3D – 3 Dimensional

AI – Artificial Intelligence

HLSL – High Level Shader Language

GPU – Graphics Processing Unit

CPU – Central Processing Unit

NPC – Non-player Character

Acknowledgements I would like to thank my supervisor, Dr EduanKotzé of the University of the Free

State, for the guidance, constructive criticism, compliments and contributions that he

provided. I would also like to thank all those that enabled me to reach this level of

education and ability, to whom I am eternally grateful.

vi | P a g eFE van Greunen - 2009002011


Chapter 1: Introduction

1.1 Introduction For the purpose of the RIS693 year module project, I created a 3 Dimensional First-

Person Shooter Windows game, via Microsoft’s XNA Game Studio (v4.0). This

entertainment application posed technical, artistic and software engineering

challenges. It seemed to me a natural choice for a project, since it aligned with my

personal, financial and research interests.

The name of the game is ‘Volition’. Volition is a cognitive process where an individual

decides on and commits to the execution of an action. The player will decide on and

commit to trying to beat the computer game, and the opposing enemy characters will

try to halt that, hence the name Volition.

1.2 Purpose of the Project Creation of a fully-fledged 3D game in any genre requires knowledge and application

of a multitude of technical and user-orientated techniques. The creation of this game

provided a platform from which I could learn many concepts related to the creation of

an entertainment product.

The knowledge gained enables me to pursue a passion of mine, namely interactive

game development and evaluation. Evaluating games in terms of the user

experience can be very beneficial to game development companies, and can also

provide strategic information for publishing and sponsorship agents. In the future I

would like to use my acquired knowledge and skills in pursuing further research (not

necessarily academic, perhaps personal) into game evaluation.

It benefits me greatly having a working and significant project which I can

demonstrate to future employers in the gaming or coding industry.

I created the product such that most essential (and some nonessential) and specific

techniques of game programming are covered, albeit to a small extent. Techniques

and principles include but are not limited to:

Terrain rendering

Page 1 of 85FE van Greunen - 2009002011


Collision detection

Model rendering

Shader programming

Artificial Intelligence for the characters

Sound

Input handling

There were no doubt areas of the process and programming that did not correspond

to game programming per se, but which add to the functionality and user experience

of the product.

The system features basic and functional artificial intelligence for the enemy

characters. This includes varying levels of difficulty and intelligence depending on

level progression. Algorithm (-s) were implemented to this effect, and object

orientated design patterns were used to effectively manage the enemy

characters/objects.

1.3 Project Objectives Personal:

Learn the XNA framework. Learn about several general game concepts and ideas, such as how to design

the menu, and the in-game display. Learn about user interaction in terms of gaming. Learn about graphics, shaders and 3D technologies. Learn about 3D modelling and art creation. Experience the software engineering cycle first-hand.

Product: Provide an enjoyable 3D survival-shooter experience through addictive

gameplay. Visually appealing in terms of graphics (within scope of project). Robust architecture. Application of good object orientated principles. Coding and documentation with maintenance in mind. Create a usable and fun product which can be shown to potential employers. Enemy characters have basic and functional artificial intelligence. Provide varying levels of difficulty, corresponding with enemy intelligence and

behaviour.



1.4 Scope of the Project This first-person shooter game features a survival component. The objective of the

game is to survive until the final enemy character has been slain. The player will face

ever-increasing difficulties of enemy characters. The enemy characters will spawn at

single or multiple predefined spawn points. The difficulty will increase in terms of

enemy hit points, accuracy and other physical metrics, but also byoccasionalpath

finding, decision making,and some resemblance of tactical and strategic intelligence.

The player will wield a set of different ranged weapons, each with a reloadable

magazine. Enemy characters arenot ranged, i.e. they will be melee and cannot

attack from afar. The environment is a closed arena filled with elementary trees

andsparse grass to set the stage. There is an ammunition stackplacedon the map

where the player will need to restock his/her ammo supply. An ammunition stack will

also have an accompanying medical station where players will need to stop by

periodically for health regeneration and to refill their hunger bar. If the player’s

hunger bar runs out, he/she will die. Obstacle blocks in the form of man-sized cubes

can be collected and placed on the terrain in order to build basic obstacles as

protection. Obstacle blocks are impassable to all, including the player.

Features and implementation in the game can be summarised as follows:

Navigational menu system

Basic melee enemy characters, with no or very basic animations

Enemy characters pursue the player using AI

Pathfinding using A* or modified A*

Decision making using decision trees and/or finite state machines

Limited inclusion of tactical and strategic information in decision making

processes

Various weapons to choose from

Ammunition/hunger station to refill needs

Basic low-detail environment with trees, grass

Obstacle blocks that can be placed.

Basic sound effects

Basic models



1.5 Complications and Challenges Complications and challenges were abundant as this area of programming was very

new to me. The mathematics, complex calculations and algorithms used in the code

proved to be a challenge. The presentation and visual aspects of the game certainly

took some time, expertise and research to create. Content creation in terms of

models, textures and sounds were difficult to create to an appealing degree, but free

content on the internet assisted me with this relatively non-programming, artistic

task. Another challenge was the vast number of classes and interfaces that had to

be created in order to ensure robustness and maintainability.

The implementation of the artificial intelligence engine was also a challenge. In order

for the enemy characters to have any resemblance of intelligence, the artificial

intelligence engine needed to be fully functional with a dynamic nature; not only rule-

based and based on if-else statements. I had much to learn in this area.

Some focus shifted from programming for the CPU to programming for the Graphics

Programming Unit (GPU). This shift was a worthwhile endeavour, since general

purpose computations on GPUs are becoming more and more ubiquitous. I had to

become conversant in Microsoft’s High Level Shader Language (HLSL) to a basic

level in order to accomplish rendering of 3D objects with custom effects to the 2D

representation on the screen.

1.6 Reasons for doing the project I have an interest in games and the interest in games has also manifested in an

interest in creating games. Using a framework such as XNA provided me with an

opportunity to learn about game programming, from terrain generation, character

animation, lighting, artificial intelligence, collision handling and so on. Game creation

can be a very technical endeavour, and requires the implementation of good

programming principles in order to create an entertaining product. I would like to

know how modern games accomplish what they do. This project also gave me a

good foundation in artificial intelligence for games, a knowledge set that is much

desired in the gaming world. Using some of these techniques and concepts,

although relatively elementary, deepened my understanding of the game

development world.



Present games have seemingly advanced AI. However, there is room for

improvement. The more widespread application of machine learning will, for

example, fill some gaps in existing artificial intelligence modules in games. I believe

that AI will be the next big thing in games, just as graphics is the current trend.

Players might soon begin expecting more than great visuals, instead looking for a

realistic, smart, immersive and believable game environment. AI used in games can

be applied to business and educational problems. Using AI which is normally only

prevalent in games can be a worthwhile and rewarding endeavour.

Additionally, including the AI elements in the project broadened and deepened my

understanding of AI in general. The knowledge gained in using AI might assist with

identifying a novel application area.

1.7 Limitations of the Project It should be noted that the project does not provide high quality 3D graphics as is

common in modern games, because the development effort of the game (single

person development, limited timeframe) prohibited this. However, the graphics are at

least low-detail and fully functional.

The artificial intelligence in the game is functional. Its goal is to imitate realistic

human behaviour for the enemy characters within the computer game. There is no

process of learning involved, although the AI of the characters is adaptive and will

change over time as difficulty increases.

The computer game’s human-computer interface is functional and supports an

enjoyable experience. However, the focus of the project was not on developing many

user interactions that are common in commercially developed modern games. The

interactions of the human player with the computer game environment are limited in

such a way that basic functionality is present in order to render the game playable

and enjoyable.

1.8 Document Overview Chapter 2 contains the literature review. The review provides a foundation for the

project, and discusses relevant technologies and terminologies.



Chapter 3 covers the Requirements and Analysis phases of the software

development cycle. This chapter serves to extract all the requirements for the

application to be developed, and these requirements will then be further analysed in

preparation for the following phases.

Chapter 4 covers the Architectural Design of the application. It includes class

diagrams, an initial schedule, a final schedule, and a motivation for the technologies

used.

Chapter 5 reveals some implementation details, and includes discussions on

selected code snippets.

1.9 Conclusion In conclusion, this project was a worthwhile endeavour. It is broad in that there are

many concepts that was explored that differ from one another, for example

programming the AI engine and designing the human-computer interaction are two

distinct work packages. It is also deep in scope, because for example, the AI engine

had complexity and adaptability. There were sound reasons for doing this projectas

discussed above, and the scope of the project is fitting for an honours project

module. The following chapter presents the literature review.

Chapter 2 : Literature Review

2.1 Introduction The world of game development is vast. It consists of many programming and artistic

spheres, such as computer graphics, artificial intelligence, networking (multiplayer

games), modelling (creating the in-game models, characters, the visual aspects),



and software engineering. Computer game development is a highly technical field,

borrowing from real world programming concepts, principles and ideas. This goes

both ways, as game development principles and ideas can spill over into other

application domains, such as military research and medical science applications

(Kato, 2010). Computer gaming is now a predominant entertainment genre, and

demands rich, interactive, realistic and immersive gameplay in order to capture and

retain the attention of consumers. This chapter will discuss existing computer game

development technologies that are in use today. It will also introduce artificial

intelligence aspects and terminology. These discussions will provide a background

for the project.

2.2 Computer Game Development Technologies The following section describes the common tools and technologies used in

computer game development.

2.2.1 Software Frameworks

A software framework is defined as follows: “A software framework is a universal,

reusable software platform used to develop applications, products and solutions.

Software frameworks include support programs, compilers, code libraries, an

application programming interface (API) and tool sets that bring together all the

different components to enable development of a project or solution” (Maxxess-

systems, 2010). A framework is thus a platform that affords the programmer or

developer some abstraction from the lower, nitty-gritty details. It still provides control

over how the program runs or behaves.

XNA is Microsoft’s approach at allowing indie (amateur, not-for-profit) and student

game developers to create simple games for the Xbox360 and the PC. XNA is not an

acronym. It is a set of programming tools designed for use with Microsoft’s .NET

Framework. It provides a content pipeline which enables developers to import

existing textures, models, sound and other content seamlessly. It features a game

loop where the programmer specifies game logic and rendering.



2.2.2 Game Engines

A Game Engine is similar to a software framework in some ways. It also provides

abstraction from lower level details, it also affords the developer customization of the

game to be developed (albeit to a smaller extent), and it also has a set of tools and

API’s that enable the developer to create the game (Ward, 2008). The engine,

however, may provide much more pre-implemented modules such as a physics

module, a rendering module, input handling and so forth. The engine already has

some features and functionalities implemented which allows the developer to focus

on making the game itself, not the fundamentals. Therefore, an engine provides a

greater level of abstraction and allows the developers and artists to quickly get past

the technical difficulties. Examples include Unity3d, CryEngine2 and the Havok

Physics engine.

2.2.3 Shaders

A shaderis a small program or a set of algorithms that executes on a graphics card in

order to do shading (Webopedia, 2010). Shading is the process of determining and

rendering the correct amount of light within an image, per pixel. They determine how

3D objects appear. Shaders are also used to produce special effects such as

enhanced detail mapping, and are also used to do post processing such as blurring

of an image. In other words, shaders are the small programs that translate

positioning and shading effects of in-game models (via the graphics processor) into

the visual representation as seen on the screen.

HLSL (High Level Shading Language) is a programming/shading language for use

with Direct3D;Microsoft’s graphics interface (Microsoft MSDN Library, Retrieved

2013/04/07). Programmers can create shaderswith HLSL which execute on the

graphics card itself. XNA (as discussed previously) uses HLSL to render an image to

the screen.

2.2.4 Game Development Software Engineering

The development process for computer games is a complex procedure. The

development team usually consists of many technical, artistic and management

specialists. Therefore software engineering team aspects are important. There is

also a producer who is responsible for marketing- and production-related aspects.

There are many approaches and methodologies to developing computer games,



because the many traditional software development approaches can be adapted for

this kind of software product. The project was developed using an agile development

methodology. Reasons for this decision are enumerated in chapter 4.

2.3 Artificial Intelligence for Games This section distinguishes between general artificial intelligence (AI) and artificial

intelligence for computer games. It will also discuss relevant and common elements

of AI in games. Furthermore, it will discuss an approach to implementing an AI

engine.

2.3.1 General Artificial Intelligence

Some experts define AI as ‘The science and engineering of making intelligent

machines, especially intelligent computer programs. It is related to the similar task of

using computers to understand human intelligence, but AI does not have to confine

itself to methods that are biologically possible’ (McCarthy, 2002). Basically, AI is the

pursuit of injecting intelligence into normally non-intelligent objects, not necessarily

confining intelligence in human terms. AI is somewhat related to the ability of a

program or an object to achieve goals.

2.3.2 Artificial Intelligence for Computer Games

Artificial intelligence found an application in games. From the early days of artificial

intelligence, researchers were developing leaner, smarter and faster ways of artificial

intelligence in order to beat a human expert-level game player. For example in

Chess,thegrandmasters were beaten by an AI computer program. However, there

are some games that have still to be conquered, such as Go, a Chinese-Japanese

board game (McCarthy, 2002).

According to TIGA, the trade associate representing the UK videogames industry

defines a videogame as follows: "A game is interactive entertainment software

whose primary purpose is to entertain or educate" (VideoGamer.com).Artificial

intelligence in this field is no longer primarily concerned with beating a human

opponent, but rather to give realism, replayability and enjoyment to games. People

who play games want their opponents to be as smart and realistic as a normal

human player, replete with their own shortcomings and strengths. On this note, it is



often very important to note and implement the shortcomings of humans into a

game; players will soon recognise if a computer is ‘cheating’.

It has been proposed that AI in computer games is a research area in which human-

level AI can be pursued(Laird & van Lent, 2001) (Kato, 2010).Laird and van Lent

(2001) make a strong case for research into this application area, as games are

indeed ever evolving in complexity and realism. This realism is achieved by

advanced graphics and artificial intelligence. It is possible to use computer games

and the insights that they provide in order to solve greater and more abstract AI

problems. The gaming industry is awash with money, owing to the popularity of

games. This is a great platform to develop AI along with the long-established but

relatively quenched field of academic AI.

The three basic needs of AI in games are: the ability to move characters, the ability

to make decisions about where to move, and the ability to think tactically or

strategically (Millington, 2006).Nowadays a broad range of techniques are used to

fulfil these basic requirements.

2.3.3 The Inference Machine in Artificial Intelligence in Games

An inference machine is the central component of the AI engine. Its task is to apply

knowledge from the knowledge base to the current situation in order to decide on

actions. The inference machine constantly cycles through a decision cycle. (Laird &

van Lent, 1999)

Laird & van Lent (1999) proposed the following model or approach in order to

simplify the AI development process for a computer game:

Perception Layer (Sense, Perceive)

This is the sensory layer, the world interface. The character in the game

obtains information about its environment. The information that is obtained will

be used in the decision-making process later on.

For example, a character wanders the world until it sees the player. It takes in

a variety of information every few frames, which may include sounds emitted

by the player, gunshots in the character’s direction, signals from other

characters, the lay of the land, obstacles in the way of movement, interesting



nearby objects, and so forth. This information can be varied, and generally the

more information is gathered, the better decisions can be made. There is,

however, a trade-off between the amount of information that is gathered and

the performance of the system as a whole. Also, a player does not want to

compete with in-game characters that have too many information, and it will

seem obviously fake to the player.

Decision Layer (Think)

This is the layer where the information gained in the perception layer is turned

into knowledge and used to make informed decisions. Decisions will ultimately

result in actions being performed.

For example, an in-game character has garnered sensory information about

the player and its environment. The information is in the form of numbers, or

variables. The information does not yet represent knowledge. When the

character first uses the information in a structured way or transforms it the

information will become knowledge. The challenging part is to make decisions

based on this knowledge. Decision making is discussed in a later chapter.

Concerning knowledge, one is faced with questions such as how much

knowledge must one save. Does it even have to be saved? What significant

advantages are you granting a character upon saving knowledge from

previous perceptive information? Can you use knowledge to train, to teach a

character to avoid negligent or bad decisions and to favour productive

decisions?

Action Layer (Act)

This is where decisions become actions. Decisions are translated into a set of

instructions that are executed.

For example, after considering all options based on knowledge, the decision

layer of a character might have decided to attack a nearby player. The action

layer is responsible for executing that decision: the actual movement,

shooting, and animation.

This is a challenging layer in that it is the layer that is most prominent to a

player. Transitions and animations need to be smooth; otherwise players will



quickly notice the machine-like nature of the characters. This layer is also

where the character must be limited in some ways, for example the character

is expected not to run too fast, or shoot too accurate, or turn and accelerate

too fast, or dodge incoming bullets, and so forth.

2.3.4 Pathfinding

In most modern computer games the in-game characters do not move on strict paths

or certain areas. Characters need to be able to traverse the whole terrain or area

that is accessible to them. They need some way of finding a path through terrain or

among buildings. They do not know in advance that within the next few frames they

will pursue the player through alleys. The route must normally be as effective and

efficient as possible and it should at least be sensible.

Pathfinding is part of the decision layer. There needs to be some decision on the part

of the character for it to decide to move somewhere. The decisions that need to be

made, or the heuristics (discussed under the A* algorithm) that need to be taken into

account are all part of the pathfinding algorithm. For example, the pathfinding

algorithm might need a decision whether to stop somewhere at a refuel point or keep

moving on the optimal path.

No pathfinding algorithm can work directly with a game’s terrain or level (Millington,

2006). Therefore, a way is needed to represent the geometry of the level.

Mostpathfinding algorithms use a mathematical structure, a graph. It consists of

nodes, or locations in the game world, and connections or paths between these

nodes. Connections can be one-way or two-way. A connection such as jumping off

an overhanging ledge is a one-way connection, whilst a ladder might constitute a

two-way connection. The connections each have weights or costs associated with

them, and that is how pathfinding algorithms work. They calculate the most optimal

route between points A and B by considering the costs associated in getting there

via different routes. Here follow examples of a few pathfinding algorithms.

Dijkstra

This is the simplest and oldest of the pathfinding algorithms. It is originally a

mathematical solution to finding the shortest route from every node to every

other node. Game pathfinding is generally not interested in finding all possible



routes from here to everywhere. It can, however, be used to gather tactical

information (Millington, 2006).

Dijkstra’s algorithm works in that it starts at the beginning node, and then in a

circular fashion extends outwards to the other nodes. Each node in the

outermost ring (foreach iteration) evaluates all possible connections from it to

other nodes. It saves these already calculated paths and the cost involved in

getting there in order to make a suitable judgement on the optimal path at the

end of the algorithm. A drawback of Dijkstra’s algorithm is that it does not stop

at the destination, nor does it provide a mechanism such as heuristics,

problems which the A* pathfinding algorithm solves.

A*

A* is the most prevalent of the pathfinding algorithms in games (Grzyb,

2005).It is simple to implement, efficient, and has lots of room for optimization

(Millington, 2006).

The A* is different from the Dijkstra in at least two ways. Firstly, it seeks only

the optimal path between a start node and an end node; it is not originally

intended to find the shortest paths between all nodes. The algorithm ceases

when the shortest path is found. This cessation of the algorithm is based on

estimations, and therefore A* is known to be sub-optimal in terms of accuracy.

It can be altered to provide better accuracy, but at the cost of an increased

number of iterations. Heuristics mitigate this shortcoming somewhat.

Secondly, it allows the inclusion of heuristics to the algorithm. Heuristics help

determine the ‘most likely’ shortest path, based on predetermined settings.

Each node has a ‘heuristic value’ in addition to the cost of travel accumulated

so far. This heuristic value of each node is an estimation of the travel cost to

the end node, whereas the cost-so-far value is an estimation of the cost up to

the current node so far. Heuristics can be based on Euclidean distance to the

destination, or the change in elevation over the terrain, the nature of the

terrain, and so forth. Heuristics is an art in itself, and can be easily over- or

underestimated, rendering the pathfinding algorithm inaccurate or inefficient.



2.3.5 Decision Making

Decision making is the process of determining a suitable course of action based on

obtained or stored knowledge of the in-game environment or situation. This is the

behind-the-scenes AI, which usually manifests itself in a number of actions or

executions. Although not directly visible by the human player, it is essential that

decision making is structured, unpredictable and realistic in order to provide a

believable in-game character. Decision trees and finite state machines are examples

of decision making algorithms.

Decision Trees

Decision trees are the simplest of the decision making techniques in games.

They are fast and easy to create, resulting in modular code that facilitates

debugging and maintenance. The tree starts at a node, evaluates a condition,

and after that, branches down the tree corresponding to a yes/no answer. The

tree can extend deeply or can be very flat in terms of how many decisions can

be made. Traversing of the tree stops at a leaf node: resulting in a decision

being made. Decision trees can have a random element to the evaluations at

each node, many evaluations can merge into one leaf node, they can be

balanced in order to provide better performance based on usage statistics,

and they can even be learned by certain learning algorithms such as a neural

network.

Finite State Machines

A Finite State Machine (FSM) represents a set of states in which a character

can be. Some states may include, pursuing the character, or wandering, and

so forth. FSMs are prevalent in modern games. States are connected by

transitions between states, like a transition between going to the battle and

participating in the battle itself. Transitions themselves may require actions to

be executed, and therefore they are considered alongside the states.

FSMs are sometimes abstracted into hierarchical FSMs. This simply means

that a higher level state can have many states associated with it. For

example, the high level act of patrolling can have children in the sense that

one can also investigate suspicious activity whilst patrolling, which is a state in

itself. This allows more specific behaviour and facilitates modular code.



The combination of decision trees and finite state machines is a worthwhile

endeavour (Millington, 2006). Decision trees can be used to determine transitions

between states. This allows a rich decision making structure.

2.3.6 Tactical and Strategic Artificial Intelligence

This level of AI has to do with the tactical information and decision-making available

to in-game characters. A position on the terrain which has lots of high-rise debris

scattered around will provide cover against enemy fire, and therefore has tactical

advantage. Tactical information about the in-game environment can be pre-

generated before the game starts, or can be dynamically altered by observing the

human player, or analysing the sensory information obtained. Tactical information

will influence pathfinding as well as decision making.

The strategic level of AI is associated with many characters simultaneously. The

strategic AI is responsible for coordinating the in-game characters. For example, if

an alarm was raised at one part of the environment, patrolling characters should

immediately receive a high level tip-off in order to simulate realistic behaviour. This

tip-off will likely happen at the strategic level, as tip-offs are for multiple characters.

Strategic AI can also use tactical information, and may take on many forms in terms

of decision trees, learning algorithms, finite state machines, and so forth. The

function and structure of a strategic AI system depends on the goals of strategic AI

as well as the game genre.

2.4 Supporting Terminology Here is a list of terminology that would be encountered throughout the project, if not

already discussed above.

2.4.1 Game Loop

Refers to the XNA Game Studio’s iterative loop that one hooks into in order to draw

and update game components such as the terrain and models.

2.4.2 Texture

A texture is a 2D image that can be used for a variety of purposes. A sprite is a 2D

texture that is drawn in 2D. Textures can be wrapped or mapped onto a model in

order to give it its skin or outward appearance. Textures can also save information



used to generate certain aspects of a scene, such as a height map, which is

discussed later on.

2.4.3 Terrain

A terrain is the physical land or water on which the character treads.

2.4.4 Multitexturing

Multitexturing is a texturing technique which maps different textures to a specific

height of the terrain. For example, low terrain heights might be mapped a grass

texture, while high peaks might be mapped with a snowy texture. Normally

multitexturing is done with 4 textures.

2.4.5 Heightmap

A height map is a grayscale image or texture that represents the height of the terrain

at a specific point. The texture has grayscale values, where lessgrey areas denote

higher elevations on the terrain than darker areas. This texture is used to generate

the terrain and is a 2 dimensional representation of the actual terrain.

2.4.6 Lighting

Lighting refers to any light source in the scene, as well as the techniques used to

render the objects in the scene with the correct amount of lighting.

2.4.6.1Ambient lighting: This type of lighting is the lighting that is always

present. Models and the terrain will be lit by this amount at all times of the

rendering and game cycle.

2.4.6.2 Directional light: A directional light is a light source that shines light in

one direction. This light source will light the whole scene from one particular

direction. It should not be confused with a spotlight or a point light.

2.4.6.3 Spot light: A spot light is analogous to the light from a torch. It shines

in one direction and lights up a cone area.

2.4.6.4 Point Light: A point light is a light source that shines in all directions

from a single position. The light diminishes as the distance from the source

decreases.



2.4.7 Primitive

A primitive is a simple polygon. It is a way of referring to a low-level graphics part or

constituent. A polygon is a geometric construct with multiple sides, for example a

triangle, or a hexagon. Everything that gets drawn to the screen in 3D consists of

primitives.

2.4.8 3D Model

A model is a 3 dimensional object that consists out of vertices, or simple geometrical

lines that make up the object. These lines form primitives. The model can also store

one or more textures which will be wrapped to the model at runtime. Models can also

store other information, such as animation detail. An example of a model is a

character or building in a 3D world.

2.4.9 Mesh

A model can consist of many meshes. A mesh is a certain part of a model, for

example a character’s head might be a mesh, and his torso another. The mesh

handles the physical appearance, the shape of the model.

2.4.10 Bones

The model consists out of bones, analogous to a human having a thigh bone, an arm

bone and so on. Bones cannot be seen, and are used to animate a model.

2.4.11 Sound

Sound can be anything that is played back by the computer. This includes

background music, music that is played on cue, intermittent music, and so on.

2.4.12 Animation

A model per se is not animated. A model may have animation model stored along

with it. Animation is when the model moves. It is not simply a translation to another

position, but a change in how the model looks. Animation is done via bones. The

bones are moved and rotated in order to simulate a realistic movement.

2.4.13 Billboard

A billboard is a 2D texture primitive that is rendered in a 3D world. The texture

always faces the perspective of the player. Billboards can be used to simulate grass,

trees and other details. Billboards are usually used for objects that are far away from



the user, which in this case could not have been distinguished from a model. A

billboard is much less expensive to render than a model. This is why billboarding is

used to render grass; many grass blades can be rendered to simulate a field or

grassy terrain.

2.4.14 Mathematical Terms

Mathematics is everywhere in gaming. It is used from artificial intelligence, graphics,

networks, right through game logic, scene management and sound. Game

developers are expected to at least have some proficiency with entry-level

mathematics at college level. Below are a few fundamental mathematical constructs

that game developers need to be proficient in.

2.4.14.1 Vector: In terms of game programming, a vector is a data structure

that can represent a position in 2D or 3D space, or a direction in 2D or 3D

space. It has 2, 3 or 4 components, where for example the 3-component

version has an x, y and z-component that places or directs it. Vectors are

used to keep track of positions, calculate directions, rotations, and many

more. Vectors can even represent colour in terms of their RGB and alpha

values.

2.4.14.2 Matrix: A matrix is an n-by-n data structure that consists out of

numbers. Matrices are used extensively in 3D programming. They can contain

positioning data, rotation data, translation data, scaling and more. Matrices

are also used to orient the user’s camera into the direction they are facing.

2.4.14.3 Rotation:Rotation is a movement about a certain axis. For example,

rotation along the x-axis is rotation by a specified amount around the positive

direction of the x-axis. Rotation is measured in radians. Rotation data is

stored in matrices to orient models correctly.

2.4.14.4 Normal:A normal is a vector that is exactly perpendicular to another

vector or plane. A 90 degree angle is formed between the object and the

normal of the object. Normal data can for example be used to determine the

lighting amount on each vertex or pixel.



2.4.15 Collision

A collision is defined as an intersection of two models or a primitive and another

primitive. Often collision handling algorithms need much optimization, for collisions

between objects need to be checked constantly. When a projectile from a player’s

gun travels forward, all objects within the path of that projectile needs to be checked

for a hit. When models move about the terrain, they have to be checked for collisions

against one another as well as against the environment. One can use spheres or

boxes around objects and then check whether those polygons intersect each other.

2.4.16 Projectile

Projectile can be defined as any potentially lethal missile/bullet that travels in the 3D

world.

2.4.17 Special Effects

These are effects that are applied to the scene or to objects within the scene in order

to create an embellishing effect. Merriam-Webster, an online dictionary and

thesaurus, defines special effects as ‘visual or sound effects introduced into a motion

picture, video recording, or taped television production.” It further states that ‘the

growing use of computer animation and computer-generated imagery has produced

increasingly elaborate and realistic visual effects’ (Merriam-Webster.com). This

definition is in terms of televised content. Special effects for video games are very

similar, although special effects in video games are generated electronically,

whereas special effects in films are not necessarily electronically generated.

2.4.18 Spawn Point

This is an area on the terrain where characters spawn. To spawn, in terms of

gaming, means to enter the gaming world or scene; to start playing. Thus enemies

spawn at a certain point of the map. From there onwards they are active and

participate in the game world.

2.4.19 Physics

Physics in computer games has developed greatly over the years. It is common to

see realistic and accurate movement these days on modern games. Game physics

encompasses many things, such as applying gravity to objects, determining how

projectiles ricochet off objects, how certain game-world objects react to a moving



object colliding with them, and much more. It is a demanding and highly technical

subarea of game programming, hence the tendency of game developers to use

physics engines.

2.4.20 NPC

An NPC is a Non-Player Character. Therefore it is a game entity that is not controlled

by the player, and the player competes against it.

2.5 Existing 1 st Person 3D Shooting Games

Counter-Strike v1.6

This is a relatively old first person shooter game: it was released in 2000. It features

an array of weaponry and many maps. It eventually evolved to become a

predominantly multiplayer computer game, but there are computer-controlled enemy

characters called ‘bots’ that compete against human players. These bots generally

have no true AI: their difficulty increases mostly by a decrease in reaction time and

an increase in accuracy. It features 3D graphics, collision detection (even for some

objects in the game, such as an empty food can), basic physics and a few special

effects.

Crysis

Crysis was released in 2007. It features fully destructible environments: you can

literally destroy almost anything you see. Computer games that offer the player some

power to change the game environment are known as ‘sandbox’ games.Additionally,

Crysis has immersive and life-like graphics which is enhanced by a complete and

realistic physics engine. The game is filled with special effects. Enemies within the

game have strategic intelligence, because they can respond to certain local or

remote events in an intelligent way. There are clear signs of communication between

enemies, and this also contributed to making Crysisa best-selling computer game.

Call of Duty Modern Warfare 2

This first person shooter game was a very popular multiplayer computer game. It

provides players with an intuitive and fun environment in which to compete against

their friends: online or locally. It also features good graphics, realistic physics and AI

for the singleplayer side of the game.



2.6 Proposed Solution In the above 3 games the characters do not have leaders, merely ‘bosses’, or very

strong and unique opponents. Leaders are also ‘bosses’, but they have leadership

qualities, and will affect the behaviour of most other enemy characters within the

game environment. It might be beneficial to the experience of the game if there are

some aspects of leadership present. The computer game developed will enable

investigation of the usefulness of including a leadership element.

Most computer games have some decision making structure in the form of a finite

state machine. The computer game developed features a decision making engine in

order to create adaptive character behaviour.It is different from existing systems in

that the finite state machine and the resulting behaviour for each character will be

influenced by nearby leaders.

Pathfinding for adaptable terrains was also investigated. It also enables investigation

of how best to calculate a heuristic for terrain pathfinding.

2.7 Conclusion It is evident that game development is a complex and challenging endeavour. The

gaming arena has changed in magnitude and complexity since the early days of

gaming. The concepts learned by studying and implementing games can be valuable

in real world applications.

The game development and AI techniques described here provided a good

foundation for developing the game. These techniques and technologies are what

are used in the field today.

The following chapter will present the Requirements and Analysis part of the

software development cycle

Chapter 3: Requirements and Analysis

3.1 Introduction This chapter documents the Requirements and Analysis software development

phases. Firstly, the interaction of the user with the program is explored and



documented. Secondly, the state-like nature of the program is described. Thirdly, the

enemy characters, their decision making systems and their behaviour is described.

Lastly, some general game elements are described.

The ‘application’ consists of 2 parts: the menu part and the gameplay part.

Whenever the word ‘application’ or ‘program’ is used, it is referring to the complete

application. Whenever ‘menu system’ is used, it refers to only the navigational menu

screens. Whenever ‘game’ or ‘game system’ is used, it refers to only the actual part

where the game is played.

3.2 Non-Functional Requirements (to be) The application must be robust: it should be fault-tolerant and should not

accidentally (or purposefully) broken by the user;

The application must be extendable, in that functionality or content can be

easily added;

The extension of the application must be easily documentable;

The application must facilitate maintenance of existing code;

The application must be immersive for the player and provide entertainment;

3.3 Functional Requirements (to do) The menu part of the application should be easily navigable, and should be

intuitive;

The game part of the application should be easy to play;

The AI engine must have different behaviours, and there should be

meaningful interactions between minions and leaders (defined later);

The pathfinding engine must be adaptable and utilise the topology of the

surrounding terrain;

3.4 Performance Requirements The application should be able to run on a modern PC, with modern being

the technologies from 2009 and onward;

The application should run at a minimum of 40 frames per second;



3.5 Use Case Diagram Here follows the overall use case diagram for the application (the complete package:

menu system and game system):

Figure 3.26 : Overall Use Case Diagram



3.6 Use Case Descriptions and Scenarios Here follows an elaboration of each use case, as well as a possible normal scenario

and an exception scenario.

Figure 3.27 : Exit Program Use case

Exit ProgramActor: Player

Description: Enables the user to exit the application, whilst he/she is in the menu system.

The user is on the ‘Main Menu’ screen.

Step-by-step:

1. The user selects to exit the application.2. The application exits.

Normal Use Scenario Exception ScenarioUser John returned from playing a game. He is on the ‘Main’ screen. He wishes to exit the application and return to his desktop.

Step-by-step:

1. John selects to exit the application.

2. The application checks if a control is selected.

3. The ‘Exit’ control has been selected.

4. The application exits.

User John returned from playing a game. He is on the ‘Main’ screen. He wishes to exit the application and return to his desktop.

Step-by-step:

1. John clicks on open space, no control is selected.

2. The application checks if a control is selected.

3. No control is selected.4. The application does

nothing/continues.



Figure 3.28 : View About Screen Use Case

View About ScreenActor: Player

Description: Enables the user to view the ‘About’ screen, where information concerning the creator and contributors of the program are displayed.


Step-by-step:

1. The user selects to view the ‘About’ screen.2. The program navigates to the ‘About’ screen.

Normal Use Scenario Exception ScenarioUser John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about the creators of the program.

Step-by-step:

1. John selects to view the ‘About’ screen.

2. The program checks if a control is selected.

3. The ‘About’ control has been selected.

4. The program navigates to the ‘About’ screen.

User John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about the creators of the program.

Step-by-step:



3. No control is selected.4. The program does nothing.



Figure 3.29 : Start New Game Use Case

Start New GameActor: Player

Description: Enables the user to start a new game and be directed to the ‘New Game’ screen, where parameters for the upcoming game will be specified.


Step-by-step:

1. The user selects to start a new game.2. The program navigates to the ‘New Game’ screen.

Normal Use Scenario Exception ScenarioUser John started the program. He is on the ‘Main’ screen. He wishes to start a new game.

Step-by-step:

1. John selects to view the ‘New Game’ screen.


3. The ‘New Game’ control has been selected.

4. The program navigates to the ‘New Game’ screen.

User John started the program. He is on the ‘Main’ screen. He wishes to start a new game.

Step-by-step:






Figure 3.30 : View Main Screen Use Case

View Main ScreenActor: Player

Description: Enables the user to view the ‘Main’ screen, which is the navigational root of the menu hierarchy.

The user is in either one of the ‘New Game’, ‘About’, ‘Instructions’, or ‘Controls’ screens.

Step-by-step:

1. The user selects to return to the ‘Main’ screen.2. The program navigates to the ‘Main’ screen.

Normal Use Scenario Exception ScenarioUser John viewed the program creator’s details. He is on the ‘About’ screen. He wishes to return to the ‘Main’ screen.

Step-by-step:

1. John selects to view the ‘Main‘ screen.


3. The ‘MainScreen‘control has been selected.

4. The program navigates to the ‘Main’ screen.

User John viewed the program creator’s details. He is on the ‘About’ screen. He wishes to return to the ‘Main’ screen.

Step-by-step:






Figure 3.31 : View Instructions Screen Use Case

View Instructions ScreenActor: Player

Description: Enables the user to view the ‘Instructions’ screen, where information concerning the instructions on how to play the game is displayed.


Step-by-step:

1. The user selects to view the ‘Instructions’ screen.2. The program navigates to the ‘Instructions’ screen.

Normal Use Scenario Exception ScenarioUser John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about how to play the game.

Step-by-step:

1. John selects to view the ‘Instructions‘ screen.


3. The ‘Instructions‘ control has been selected.

4. The program navigates to the ‘Instructions’ screen.

User John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about how to play the game.

Step-by-step:






Figure 3.32 : View Controls Screen Use Case

View Controls ScreenActor: Player

Description: Enables the user to view the ‘Controls’ screen, where information and commands on how to play the game are displayed.


Step-by-step:

1. The user selects to view the ‘Controls’ screen.2. The program navigates to the ‘Controls’ screen.

Normal Use Scenario Exception ScenarioUser John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about the controls of the game.

Step-by-step:

1. John selects to view the ‘Controls’ screen.


3. The ‘Controls’ control has been selected.

4. The program navigates to the ‘Controls’ screen.

User John returned from playing a game. He is on the ‘Main’ screen. He wishes to view more information about the controls of the game.

Step-by-step:






Figure 3.33 : Set Difficulty Use Case

Set DifficultyActor: Player

Description: Enables the user to change the difficulty level of the upcoming game.

The user is on the ‘New Game’ screen.

Step-by-step:

1. The user changes the difficulty level on a control.2. The input is validated.

Normal Use Scenario Exception ScenarioUser John is on the ‘New Game’ screen. He wishes to set the difficulty level of the upcoming game.

Step-by-step:

1. John selects to make the game easier, in the ‘Set Difficulty’ control.

2. The program visually indicates the change.

3. The program stores the new difficulty level.

User John is on the ‘New Game’ screen. He wishes to set the difficulty level of the upcoming game.

Step-by-step:






Figure 3.34 : Select Map Use Case

Select MapActor: Player

Description: Enables the user to select a preferred map to play the upcoming game on.


Step-by-step:

1. The user changes the selected map on a control.2. The input is validated.

Normal Use Scenario Exception ScenarioUser John is on the ‘New Game’ screen. He wishes to select a new map for the upcoming game.

Step-by-step:

1. John selects another map in the ‘Select Map’ control.


3. The program stores the new map selection.

User John is on the ‘New Game’ screen. He wishes to select a new map for the upcoming game.

Step-by-step:






Figure 3.35 : Set Map Size Use Case

Set Map SizeActor: Player

Description: Enables the user to set the map size of the upcoming game.


Step-by-step:

1. The user changes the map size on a control.2. The input is validated.

Normal Use Scenario Exception ScenarioUser John is on the ‘New Game’ screen. He wishes to set the map size for the upcoming game.

Step-by-step:

1. John selects another map size in the ‘Select Map Size’ control.


3. The program stores the new map size specification.

User John is on the ‘New Game’ screen. He wishes to set the map size for the upcoming game.

Step-by-step:






Figure 3.36 : Move Character With Jump Use Case

Move Character With JumpActor: Player

Description: Enables the user to move the in- game character around in the form of jumping, whilst playing the game.

The user is in the gameplay state, i.e. he/she is playing the game. The game is not paused.

Step-by-step:

1. The user presses one or more of the movement keys.2. The in-game character moves in the appropriate direction.3. The user presses the ‘Jump’ key whilst pressing one of the above keys.4. The in-game character jumps whilst moving.

Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to jump over a block.

Step-by-step:

1. John presses the appropriate movement key to run forward.

2. John’s in-game character moves forward.

User John is playing the game. He wishes to jump over a block.

Step-by-step:

1. John presses a key that is not assigned.

2. Nothing happens.



3. John presses the ‘Jump’ key.4. John’s in-game character jumps.

Figure 3.37 : Move Character Use Case

Move Character (No jump)Actor: Player

Description: Enables the user to move the in- game character around in the form of running, whilst playing the game.


Step-by-step:

1. The user presses one or more of the movement keys.2. The in-game character moves in the appropriate direction.

Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to run forward.

Step-by-step:

1. John presses the appropriate movement key to run forward.

2. John’s in-game character moves forward.

User John is playing the game. He wishes to run forward.

Step-by-step:


2. Nothing happens.



Figure 3.38 : Quit Game Use Case

Quit ProgramActor: Player

Description: Enables the user to quit the gamewhilst playing the game.

The user is in the gameplay state, i.e. he/she is playing the game. The game can be paused or resumed.

Step-by-step:

1. The user presses the ’Quick Exit’ key.2. The game ends.3. The user is redirected to the ‘Main’ screen.

Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to exit to the menus.

Step-by-step:

1. John presses the ‘Quick Exit’ key.2. The game ends.3. The program returns to the ‘Main’

User John is playing the game. He wishes to exit to the menus.

Step-by-step:


2. Nothing happens.



screen.

Figure 3.39 : Pause/Resume Game Use Case

Pause / Resume ProgramActor: Player

Description: Enables the user to pause or resume the game, whilst playing the game.

The user is in the gameplay state, i.e. he/she is playing the game. The game can be either paused or resumed.

Step-by-step:

1. The user presses the ‘Pause’ key. 2. The game is either paused if resumed, or resumed if paused.

Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to pause the game in order to rethink his strategies.

Step-by-step:

1. John presses the ‘Pause’ key.2. The game pauses.

User John is playing the game. He wishes to pause the game in order to rethink his strategies.

Step-by-step:




2. Nothing happens.

Figure 3.40 : Switch Weapon Use Case

Switch WeaponActor: Player

Description: Enables the user to switch the in- game character’s weapon whilst playing the game.


Step-by-step:

1. Then user presses the ‘Change Weapon’ key.2. The in-game character’s weapon is changed.

Normal Use Scenario Exception Scenario



User John is playing the game. He wishes to switch to another weapon.

Step-by-step:

1. John presses the ‘Change Weapon’ key.

2. The program checks whether there is another weapon available.

3. Another weapon is selected.

User John is playing the game. He wishes to switch to another weapon.

Step-by-step:

1. John presses the ‘Change Weapon’ key.

2. The program checks whether there is another weapon available.

3. There is no other weapon.4. The current weapon is still the

current weapon.

Figure 3.41 : Place Obstacle Block Use Case

Place Obstacle BlockActor: Player

Description: Enables the user’s in- game character to place an obstacle block whilst playing the game.


Step-by-step:

1. The user presses the ‘Place Obstacle’ key.2. Collision checks are done for the obstacle block’s position, which is

determined by where the in-game character is looking.3. The block is placed dependent on the outcome of the collision check.



Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to place an obstacle block to provide protection and cover.

Step-by-step:

1. John presses the ‘Place Obstacle’ key.

2. Collision checks are done for the obstacle block’s position, which is determined by where John’s in-game character is looking.

3. No collisions are detected.4. The block is placed at that

position.

User John is playing the game. He wishes to place an obstacle block to provide protection and cover.

Step-by-step:

1. John presses the ‘Place Obstacle’ key.

2. Collision checks are done for the obstacle block’s position, which is determined by where John’s in-game character is looking.

3. A collision is detected.4. John is notified of the collision.

Figure 3.42 : Use Ammo/Med Facility Use Case

Use Ammo/Med FacilityActor: Player

Description: Enables the user’s character to use the Ammo/Med Facility in order to restore its resources (ammo/health/hunger), whilst playing the game.


Step-by-step:

1. The user presses the ‘Ammo/Med Facility’ key.2. The in-game character’s health is regenerated.3. The in-game character’s ammunition stores are regenerated.4. The in-game character’s hunger is fulfilled.



Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to get more ammunition.

Step-by-step:

1. John is at the ammo/med facility.2. He presses the ‘Ammo/Med

Facility’ key.3. The program checks whether the

in-game character is near the facility.

4. The in-game character is near the facility.

5. The in-game character’s ammo is regenerated.

User John is playing the game. He wishes to restore his health.

Step-by-step:

1. John is at the ammo/med facility.2. He presses the ‘Ammo/Med

Facility’ key.3. The program checks whether the

in-game character is near the facility.

4. The in-game character is not near the facility.

5. The in-game character’s ammo is not regenerated.

Figure 3.43 : Reload Weapon Use Case

Reload WeaponActor: Player

Description: Enables the user’s character to reload its weapon whilst playing the game.


Step-by-step:

1. The user presses the ‘Reload’ key.2. The in-game character’s current weapon is reloaded.

Normal Use Scenario Exception Scenario



User John is playing the game. He wishes to reload his weapon.

Step-by-step:

1. John presses the ‘Reload’ key.2. The program checks whether

John’s in-game character has ammunition available.

3. There is ammunition available.4. The weapon reloading delay is

started.5. Time expires.6. The weapon is reloaded.

User John is playing the game. He wishes to reload his weapon.

Step-by-step:

1. John presses the ‘Reload’ key.2. The program checks whether

John’s in-game character has ammunition available.

3. There is no ammunition available.4. The weapon is not reloaded.

Figure 3.44 : Shoot Weapon Use Case

Shoot WeaponActor: Player

Description: Enables the user’s character to shoot its weapon whilst playing the game.


Step-by-step:

1. The user presses the ‘Shoot’ key.2. The in-game character shoots a projectile in the direction it is facing.

Normal Use Scenario Exception ScenarioUser John is playing the game. He wishes to User John is playing the game. He wishes to



shoot an opponent.

Step-by-step:

1. John presses the ‘Shoot’ key.2. The program checks whether

there is any ammunition in the weapon’s magazine.

3. There is ammunition available.4. The weapon shoots a projectile in

the direction of aim.

shoot an opponent.

Step-by-step:

1. John presses the ‘Shoot’ key.2. The program checks whether

there is any ammunition in the weapon’s magazine.

3. There is no ammunition available.

3.7Program States Here follows a diagram of the states in which the application can be.



Figure 3.45 : Program States

3.8 Menu Hierarchy Here follows a diagram of how the menu structure is laid out.



Figure 3.46 : Menu Hierarchy



3.9 AI Finite State Machine Diagram Here follows a diagram of how the NPCs will make decisions based on certain

stimuli within the game world.

Figure 3.47 : AI Finite State Machine Diagram



3.10 AI Finite State Machine Behaviours Here follows a short elaboration on each behavioural state that an NPC can assume.

Some general terms that require explanations: Field-of-View Detection is the

immediate visible area that an NPC sees without turning, and is used by NPC’s to

spot the player. A ‘frame’ is just an iteration of the game loop, for example 60 times a

second. NPC Instantiated means that an NPC is created.

Three facets of a state are described: a behaviour, which describes what an NPC

does whilst in the state; entry conditions, which enumerate how a particular state can

be entered; and exit conditions, which enumerate how a state can be exited.

3.10.1 Wandering

Behaviour

1. NPC walks to a random target point within the terrain

2. NPC does field-of-view detection in each frame

Entry Conditions

1. NPC Instantiated

2. NPC’s health reached upper health threshold whilst fleeing (it

regenerated)

3. Player not spotted by NPC after reaching the random target point

Exit Conditions

1. NPC is attacked by player (Searching)

2. NPC wandering target reached (Searching)

3. Player spotted by NPC (Pursuing)

4. Strategic Information (swarm command) received by other NPC

(Converging)

5. Leadership asserted (organised swarming command) by LNPC

(Converging)

3.10.2Fleeing

Behaviour

1. NPC’s health reached lower health threshold, it flees from player, runs

in opposite direction as the player

2. Field-of-view detection in each frame, in order to avoid the player

Entry Conditions



1. NPC’s health reached lower health threshold because of being

attacked by the player

Exit Conditions

1. NPC’s health reached upper threshold (Wandering)

3.10.3Converging

Behaviour

1. NPCs swarm to a single position in the arena

2. Field-of-view detection in each frame

Entry Conditions

1. Strategic Information (swarm command) received by another NPC

2. Sight of player lost, NPC converges on last known player position

Exit Conditions

1. Player is spotted by NPC (Pursuing)

2. NPC arrived at convergence point without spotting the player

(Searching)

3. NPC is attacked by player (Searching)

3.10.4Pursuing

Behaviour

1. NPC pursues player


Entry Conditions

1. Player is spotted by NPC

Exit Conditions

1. NPC is heavily injured, its health reached lower health threshold

(Fleeing)

2. NPC loses sight of player (Searching)

3.10.5Searching

Behaviour

1. NPC rotates for a certain time period in order to spot the player


Entry Conditions

1. NPC converged on a point



2. NPC wandered up to the target wander point

3. NPC has been attacked, but doesn’t know from where

Exit Conditions

1. Player is spotted by NPC (Pursuing)

2. Player is not spotted by NPC (Wandering)

3.11 NPC Types There are 2 types of NPCs (Non-player characters). This will serve to add some

diversity and challenge to the game play.

3.11.1 Minion

The first type will henceforth be known as a ‘minion’. A minion is the core of the NPC

force, and executes basic decisions and behaviours, as described by the entire

“Finite State Machine for NPC AI” diagram.

311.2 Leader

There is also a smarter NPC type. It is a specialist type of minion. They will

henceforth be referred to as ‘leader’ or LNPC (Leader NPC).The aim is to make a

leader:

Stronger: a leader will be able to deal more damage per hit.

Faster: a leader can run slightly faster than a minion.

More resilient: a leader can absorb more attacks by the player.

More relentless: a leader will retreat or flee at a lower health threshold,

thereby providing a greater opportunity for a leader to get to the player and

inflict damage.

Leadership skills: a leader will be able to summon (call) minions in order to

swarm the player.

These factors serve to enhance the leader type. The leader type is there to insert

some ordered behaviour (leadership) into the minions’ behaviours. Also, the leader

makes the game more challenging on higher difficulty levels.



3.12 Other Game Mechanisms

Pathfinding

The game implements an A* pathfinding algorithm. On startup, the game terrain is

broken up into nodes, which will facilitate pathfinding. The algorithm takes into

account the Euclidean distance between two nodes, as well as the height difference

between the two nodes, where a greater positive height difference indicates that the

destination node is more difficult to get to than a less positive difference. It uses

these metrics or heuristics to influence which nodes to travel through.

It starts off at the departure node, and loops in a circular fashion to each adjacent

node, choosing the best route node based on calculated heuristics. This process

continues until the destination is reached.

The pathfinding mechanism is architected as a sequential service. A request is

logged for a pathfinding job into a pool, and a service services this pool of pending

jobs. The waiting object is notified upon completion of the job. This service

orientation ensures reliable performance in terms of frames per second, and a

bottleneck or extensive queue of jobs is not foreseen. Please see chapter 5 for a

discussion of the technique surrounding this pathfinding.

Sound

There is a sound manager that is responsible for the loading, playing and stopping of

sound effects and backtracks.It exposes methods that allow in-game objects to play

sounds.

Hunger

The player has a hunger bar/level. Hunger increases as time passes. Once hunger

reaches a threshold, the player’s health starts to decrease. This can cause death if

the player does not replenish his/her health.

Ammunition

A player can only carry a certain amount of ammunition. Ammunition is a general

term. It consists of the bullets currently in the gun (-s), as well as the bullets in the

magazines.



Ammunition/Hunger Depot

Hunger is replenished and ammunition is restocked at a depot. A depot is a visible

block or obstacle in the middle of the terrain. Players should be within a certain

vicinity of the box in order to recharge.

NPC Spawn Point

NPC’s will spawn at spawn points. There are 2 spawn points. One is for minions and

one is for leaders. The spawn point positions will constantly change.

There will be a delay between NPC spawning. Minions will spawn faster than

leaders.

There can only be a certain number of NPC’s in a level.

Difficulty Levels

The difficulty starts at the level which is chosen. Once the player has completed a

level by destroying a set number of NPC’s, a new level will begin, this time with a

higher difficulty setting.

The difficulty level determines a variety of things. It determines the health and lower

health threshold of NPC’s. It determines their speed, rate of attack, the distance that

they can see the player, the distance that they can remain in pursuit of the player,

health regeneration, call/communication distance and spawn (NPC

instantiation/creation) frequency.

Maps

There are a number of customised maps, each with different flora and terrain. The

player can choose a map in the menu.

3.13 Conclusion The above diagrams and documentation will serve the requirements and analysis

phases of the development cycle well. This chapter also documents some more

general gameplay elements of the game. All parts of the application have been

represented here and were analysed on a high level. The following chapter will go

into more depth and will present the architectural design.



Chapter 4: Architectural Design

4.1 Introduction This chapter documents the Architectural Design part of the application. It starts off

with a motivation for the selection of the technologies that were used to create the

application. It then continues by presenting class diagrams of the functionality of the

application. Lastly, it presents the initial Gantt chart that was drawn up at the start of

the project, and compares that to the final and actual time schedule.

4.2 Motivation for Technologies and Methodologies Used

4.2.1 Development Methodology

I used some aspects of the agile methodology combined with some aspects of the

traditional waterfall product development cycle.

The reason for choosing to follow some agile principles such as release early and

often is that agile methodologies are very user-focused and set on delivering

satisfactory results. Following this methodology ensures that the uncertainties and

problems that arose throughout the project were dealt with in an incremental and

iterative manner, thereby reducing some complexity. Also, since my study leader

was the client per se, following some agile methodology principles provided constant

feedback and guidance from him, and likely lead to a much more superior final

product. The waterfall aspects are included since that is how the requirements of the

project documentation are laid out, and it also helped in keeping to certain deadlines

and milestones.

4.2.2 Modelling Software

The earlier stages of the developmental cycle (requirements, analysis, and design)

were modelled by Microsoft Visio 2010. It is a familiar modelling program to me and

fulfilled the requirements of the documentation of the project.



4.2.3 Game Development Framework

A framework was chosen to develop the game, as opposed to using a game engine.

Please see the literature review chapter for an explanation of the difference between

the two. The following section describes why a framework was used and not a game

engine.

One of the reasons for choosing a framework and not an engine is the power that it

gives the developer. A framework allows one to build a game engine from the ground

up. It provides mechanisms to insert minute details into the: gameplay, graphics,

sound, input, artificial intelligence and other game aspects. It allows more control

over the game development than game engines, which are more oriented towards

productivity and rapid development. Everything that is done in a framework has to be

programmed; there is virtually no drag-and-drop functionality, which contrasts with a

game engine.

The framework provided an opportunity to design and implement an artificial

intelligence system to a finely detailed level. Behaviour and decision making systems

have to be coded by hand and allow virtually any degree of freedom. Some game

engines have AI modules built into them, and offer interfaces for a game. This

functionality is not needed, since the game will define its own AI system.

Using an existing framework rather than developing a system from low-level modules

ensures more rapid development. The framework also provides a way to implement

collision detection, input handling, sound and other critical factors.

A framework will suit my needs well, keeping in mind the relative simplicity of the

graphics and AI of the game, compared to commercially developed games.

4.2.4 Specific Framework and Programming Language Considerations

The XNA Game Studio version 4.0 from Microsoft was used to develop the game.

The software, framework and development environments are all available free of

charge at this time.

Some of the reasons for choosing the XNA framework version4.0 to develop the

game are the widespread availability of the framework, many tutorials on the

internet, many published books on the framework, some local familiarity with the

framework in the Computer Science and Informatics department, as well as it being



a familiar environment in terms of programming language and IDE. Programming in

C# is often faster than programming in traditional game programming languages

such as C or C++, but these languages are often faster in terms of performance.

Moreover, programming in lower-level languages would have necessitated more

concern and devotion to lower-level details such as platform dependence. For the

game to be developed, C# will suffice, as all the aspects of the game could be coded

in this one framework. Additionally, C# allowed the development of robust class

hierarchies and software patterns, which were essential for developing the game and

implementing the AI system.

High-Level Shader Language (HLSL) was also used in order to render (draw) the

images to the computer screen. This shader language is universally used and is a

standard in game development. Other shader languages do exist, but they are either

not well supported or generally have some issues, such as only working on older

graphics cards. The XNA framework has a built-in editor for HLSL effect files, and

this fact is another reason for choosing the XNA framework.

4.2.5 Integrated Development Environment

XNA Game Studio v4.0 is a plug-in for Microsoft’s Visual Studio 2010 Express or

Ultimate editions. Therefore, Microsoft Visual Studio 2010 Express was used to

develop the computer game, because the software can be obtained for free and suits

the needs of the project development.

4.2.6 Conclusion

The above technologies and methodologies suited the development of the

application well. As is evident from the above discussions, the project required the

use of many technologies.


ID Task Name Optimal Normal Pessimistic Expected Time Start Date End Date1 Project Proposal 3 6 8 6 07 February 2013 13 February 20132 Literature Review 30 25 30 27 16 February 2013 15 March 20133 Use Case Diagrams 16 21 24 21 04 March 2013 25 March 20134 Scenarios 16 25 25 24 26 March 2013 19 April 20135 Class Diagrams 15 20 22 20 30 March 2013 19 April 20136 Motivation for Technology Used 1 3 5 3 16 April 2013 19 April 20138 Project Day 1 3 5 3 30 April 2013 03 May 2013

11 Application 140 190 270 195 23 March 2013 04 October 201312 Technical Manual 35 55 65 54 18 August 2013 11 October 201313 User Manual 25 45 50 43 29 August 2013 11 October 201314 Project Day 2 6 8 6 12 October 2013 18 October 2013

Time Estimates (Days)

04 February11 February18 February25 February

04 March

11 March

18 March

25 March

01 April08 April15 April22 April29 April06 M

ay13 M

ay20 M

ay27 M

ay03 June10 June17 June24 June01 July08 July15 July22 July29 July

05 August12 August19 August26 August

02 September

09 September

16 September

23 September

30 September

07 October14 October

Project Proposal

Literature Review

Use Case Diagrams

Scenarios

Class Diagrams

Motivation for Technology Used

Project Day

Application

Technical Manual

User Manual

Project Day


4.3 Schedule - Gantt Charts The following Gantt chart is the initial schedule that was drawn up for the project

deliverables. The expected time per task is a function of the optimal, normal and

pessimistic times. The function for expected time is as follows:

T (Expected )=T (Optimal )+T (Normal )+4T (Pessimistic )6

The coding of the application itself was expected to take the longest time. Many of

the other tasks such as drawing up use cases or compiling the technical manual

were dependent on the progress of the application’s coding. Due to the prototypical

and iterative nature of development of the application, documentation actually

underwent continuous change and improvement.


Figure 4.1 : Expected Schedule


The following Gantt chart is the actual schedule for the project deliverables. Note

that an ‘Actual Time’ column has been added.

Figure 48.2 : Actual Schedule

Coding was started earlier than expected due to early completion of use case

diagrams and scenarios. Therefore the manuals could also be completed earlier.

This resulted in the application and its accompanying documentation being

completed in time.



4.4 Class Diagrams The 3 diagrams below provide a bird’s eye view of the class hierarchies. A detailed

view of each module is given hereafter. Methods, attributes and properties have

been omitted for the sake of brevity.


Figure 49 : Class Diagram Part 1



Figure 4.4: Class Diagram Part 2


Figure 4.5 : Class Diagram Part 3



4.4.1 State System

Figure 4.6 : State System Class Diagram



The State System describes how the game states are managed, how context is

switched between gameplay and being in the menu, as well as specifying the

difficulty level.

The Volition class is the main (most prominent) class of the application, and is

accessible everywhere throughout the game, as it has important global properties

such as the difficulty level. It is customary of game applications to have one main

class that delegates its tasks.

There are 2 game states: the Gameplay state and the Menu state. The game will

alternate between these states depending on what the player wants to do at that

moment in time and how the game progresses.This state system facilitates fast

coding and easy debugging.It also provides a clear way of splitting up logic. There

are separate classes for each of these states, as well as an enum to manage them

effectively.

The Volition class inherits from the Game class, which is an XNA framework

specification. This inheritance allows us to update and draw its components.

The IDifficulty interface provides a contract that a difficulty level needs to adhere to.

This concept facilitates polymorphism, and allows easy add-on to the difficulty levels.

One can potentially include any number of implementations for a difficulty level,

which makes the application extensible.



4.4.2 Menu System

Figure4.7 : Menu System Class Diagram

The Menu System is a Composite Pattern which represents the menu. The Menu

Screen is the prominent class here, since it is the point of control and provides a

base class for implementations.

The inherited classes (HomeScreen, NewLevelScreen, etc.) provide the details of

specific screens, and define the look and feel of each. This facilitates easy

extension.

The Composite pattern is used for representing the menu. This pattern was chosen

because it facilitates easy addition to, and extension of, the menu’s components.

Note how the Menu class inherits from and also contains a list of its base class,

MenuComponent.

The other inherited classes provide controls for a menu, such as a button, which is

also a menu component. One can thus easily add a new component to a menu, and

define it with its own unique behaviour.



4.4.3 Terrain Module

Figure 4.8 : Terrain Module Class Diagram



The terrain module delivers all the features and functions for defining the terrain. It

encapsulates all the aspects of the terrain, for example the grass and trees.

The Terrain class itself is responsible for building up the geometric representations

for the terrain, as well as for rendering its entire child or contained components. It

also handles the day/night cycle.

The TerrainContent class specifies a terrain map, such as the map’s

topography(height difference, contours) and colour, the amount of grass, and the

number and type of trees.This class contains a TreeManager class which

instantiates and manages all the trees in the terrain, so that the TerrainContent does

not have to worry about the trees individually. It also contains GrassLevel instances,

which are responsible for creating and drawing the grass in a terrain. The

GrassLevel class defines a certain type of grass at a certain height within the terrain,

and is a collection of instanced grass geometries.

The ITreeType interface specifies a contract that a certain type of tree has to adhere

to. This facilitates polymorphism in the implementing classes, and is a Strategy

pattern. The Tree class is the physical representation of a tree. The LTree package

is an open-source class library that helps define and render the trees. It also

provides wind animation (trees sway from left to right) for the trees.

The SkyBox class is the class that handles what one sees above the terrain. It is

essentially a large cube surrounding the player and the environment/terrain.

The VertexMultiTextured class is used in communications with the graphics card for

drawing the SkyBox.

The InstanceDataVertex is used to draw the GrassLevels, and represents the way in

which grass objects are sent to and processed on the graphics card.



4.4.4 NPC Module



The BasicEnemy/NPC module controls the creation, updating and deletingof NPCs

in the game world.

The BasicEnemy class is the prominent class here. It is an abstract class for

representing an NPC in the world, and handles all logic for doing that.

The Minion and Leader classes inherit from the abstract BasicEnemy class and

these 2 classes will be instantiated. Thus, NPC types can easily be extended.

The EnemyManager class manages all BasicEnemy objects within the game world.

The BasicEnemyFactory is an implementation of a Factory pattern, and is

responsible for creating/spawning enemies at specified intervals and at random

points on the terrain. The factory abstracts the creation logic and allows one to focus

on other implementation details.

The SkinnedModelWindows is an open-source library used to render animated

models.


Figure 51 : NPC Module Class Diagram


4.4.5 Pathfinding Module

The pathfinding module is responsible for the creation, execution, and returning of a

result for a pathfinding request. The PathfindingService is a service which services

requests one by one, and notifies the requesting object. The PathfindingService is an

example of one of the many Singletons in the class hierarchies.

The PathfindingNode is a representation of a node in the terrain. The whole terrain

area is broken up into nodes, and pathfinding is done on these nodes. The number

of nodes can be increased or decreased, depending on desired accuracy and

computer performance. Between each twonodes are PathfindingConnections, which

specify how difficult or costly it is to move from one node to another.

When an NPC wishes to do pathfinding, it logs a PathfindingServiceRequest and is

inserted into a queue, awaiting service.

The service queue is used to limit the resource consumption.It is undesirable to

prioritise pathfinding when the framerate drops.


Figure 4.10: Pathfinding Module Class Diagram


4.4.6 Player Module


Figure 4.11 : Player Module Class Diagram


The Player module handles all aspects of the player.

The Player class is the prominent class here. It is the representation of the player,

and is responsible for most logic for the player. It is also a camera, since it is the

player’s eyes into the game world.

The Player class contains a PlayerArmamentManager. This class manages all the

weapons that a player has, as well as the projectiles (bullets) that are projected from

them.

The IWeaponData interface specifies a contract that defines how a weapon is

defined and loaded. Concrete classes implement this interface in order to be

dynamically instantiated as a weapon type. The Weapon class represents a weapon,

and the IWeaponData interface is used in its constructor in order to define a weapon.

Weapon types can now easily be added or removed, and this is a strategy pattern.

The ObstacleBoxManager manages the ObstacleBox-es in the terrain.

The HeadsUpDisplay renders the visual items on the screen while playing, such as

the ammunition left, or the health level.



4.4.7 Finite State Machine Module for NPCs

Figure 4.12 : Finite State Machine Class Diagram

The Finite State Machine (FSM) module defines the behaviour of an NPC. It consists

of an interface which specifies a contract for behaviour types.

Each state has a reference to another state. This controls how states are switched

between one another. So after the next iteration of the game loop, a state gets

switched with its transition state. The game itself is wholly unaware of this transition,

and this transition is only apparent to the state that is being switched to. This allows

dynamic switching of states.



4.4.8 Helper Classes

Figure 4.13 : Helper Classes Class Diagram

The helper classes provide support to the other classes.

The InputHandler class handles all the keyboard and mouse inputs. It can be

extended to handle inputs for other devices, such as eye-trackers or console

controllers. The SoundManager plays all the sounds in the game. The

RandomHelper class exposes random number generation methods. The

FieldOfViewDetection class provides assistance with doing field of view detection.

The CollisionHandler class checks for and handles all collisions within the game

world.



4.5 Conclusion This chapter discussed the technologies, methodologies and approaches that will be

followed. It also includes class diagrams which gives insight into how the program

operates on code level. The next chapter will provide sample code snippets and

describe some implementation details



Chapter 5: Source Code and

Implementation

5.1 Introduction This chapter will introduce sample code snippets from the program, and will include

discussions and explanations of some of the more complex code pieces.



5.2 Pathfinding Service

5.2.1 Code// ======================================================// Class Names: PathfindingService, PathfindingRequest// Author: Francois van Greunen// Date: October 2013// Status: Complete // Description: Represents the pathfinding service and requests.

usingSystem.Collections.Generic;usingMicrosoft.Xna.Framework;

namespace _3D_Shooter{publicclassPathfindingService// This class provides the pathfinding service. It is a singleton, meaning there will only ever be one. {publicstaticPathfindingService Instance = null; // SingletonprivatestaticQueue<PathfindingServiceRequest> Requests; // The queue for the requests.privatestaticPathfindingServiceRequestCurrentRequest;// The current active request that is being handled.PathfindingNodeStartNode, EndNode, NextNode; // Thepathfinding nodes that will take part in the pathfinding. boolIsNewRequest = true;boolIsComplete = false;

privatePathfindingService()// Private constructor for the singleton. {// We anticipate a maximum of 100 requests. Size can change though. Requests = newQueue<PathfindingServiceRequest>(100); }// End of Constructor

publicstaticvoidCreateInstance()// Public functionality to create a singleton. { Instance = newPathfindingService(); }// End of CreateInstance()

// Log a request for pathfinding. The PathfindingServiceRequest contains all the data necessary to do pathfinding.publicvoidLogPathfindingServiceRequest(PathfindingServiceRequest Request)

{Requests.Enqueue(Request); }// End of LogPathfindingServiceRequest()

publicvoid Update() // Handle a part of or an iteration of an existing request, or start a new one. {

// One iteration of pathfinding is done per frame. Pathfinding typically needs many iterations, depending on the distance between the start // and end nodes. One pathfinding request is thus broken down into multiple processing or computational units, in order to ensure // consistent performance. Thus, one / request may take more than one frame to complete.

if (!IsNewRequest&&CurrentRequest != null) // It's an old request: {HandleRecurringRequest();// Do the next iteration for an existing old request.

if (IsComplete) // Request was completed. {NotifyRequestor(CurrentRequest); // Let the requestor know that pathfinding is completed. The requestor is notified.IsNewRequest = true;IsComplete = false; } }elseif (Requests.Count> 0) // It's a new request. {HandleNewRequest();// Do different calculations than for a recurring request, such as initial and end node detection and determination.IsNewRequest = false; } }// End of Update()



privatevoidHandleNewRequest() {// Thismethod is executed on the first iteration of handling a request. It gets the start and end nodes for a request based on the // pathfinding start and end points specified.CurrentRequest = Requests.Dequeue(); // Get the new request from the list.if (CurrentRequest == null) {IsComplete = true;return; }PathfindingNode.End = CurrentRequest.EndVector;

StartNode = null; EndNode = null;

// We can find a node within a 2D set of nodes by first searching in the x-direction, then searching in the z-direction (the y-direction is // up/down), thereby limiting search cost.

// Find the StartNodeint x;for (x = 0; x <PathfindingNode.NodeCountPerDimension.X; x++) // First search in the x-direction.if (CurrentRequest.StartVector.X<= PathfindingNode.Nodes[x, 0].NodeBox.Max.X)// Is the x-position less than the box’s max?break;

for (int z = 0; z <PathfindingNode.NodeCountPerDimension.Y; z++) // Now search in the z-direction.if (PathfindingNode.Nodes[x, z].IsPointInBox(refCurrentRequest.StartVector))// Is the specified position in the box? {StartNode = PathfindingNode.Nodes[x, z];break;// Node found. }

// Find the EndNodefor (x = 0; x <PathfindingNode.NodeCountPerDimension.X; x++) // First search in the x-direction.if (CurrentRequest.EndVector.X<= PathfindingNode.Nodes[x, 0].NodeBox.Max.X)// Is the x-position less than the box’s max?break;

for (int z = 0; z <PathfindingNode.NodeCountPerDimension.Y; z++) // Now search in the z-direction.if (PathfindingNode.Nodes[x, z].IsPointInBox(refCurrentRequest.EndVector))// Is the specified position in the box? {EndNode = PathfindingNode.Nodes[x, z];break;// Node found. }

NextNode = StartNode; // Starting point for the pathfindingsearch. }// End of HandleNewRequest()

privatevoidNotifyRequestor(PathfindingServiceRequest Request) {// This method notifies the requestor that its request has been completed.if (Request.Requestor.BehaviourStateisConverging) // We want to notify requestors that are still interested in their pathfinding request. { ((Converging)Request.Requestor.BehaviourState).Path = Request.Path; // The actual path that will be followed. ((Converging)Request.Requestor.BehaviourState).PathfindingIsReady = true; }

Request = null; }



privatevoidHandleRecurringRequest() {// This method handles the iteration of a pathfinding request. It finds the next best node to put in the path.if (StartNode != null&& !IsComplete&& !StartNode.IsPointInBox(refCurrentRequest.EndVector)) {floatLeastCost = float.MaxValue; // Will be used to find the smallest cost connection between nodes.PathfindingNodeLeastNode = null; // The optimal node from the NextNode.

foreach (PathfindingConnection connection inNextNode.Connections) // Iterate through all possible connections from this node to find the optimal next node to go to. {floatIntermediateHeuristic = float.MaxValue;

if (connection.Node1 == NextNode) {if (connection.Node2.IsPointInBox(refCurrentRequest.EndVector)) // Check if this is the end node. {IsComplete = true;CurrentRequest.Path.Add(CurrentRequest.EndVector);// Populate the path.break; }else// Not the end node. {if (!connection.Node2.IsClosed)// Only iterate through nodes not already processed. {IntermediateHeuristic = PathfindingNode.CalculateHeuristic(ref

connection.Node2.Center) + connection.GetConnectionCost(NextNode); // The totalcost.// The PathfindingNode.CalculateHeuristic() method calculates the heuristic value or cost between the current iteration // node (the parameter), and the end node. It takes into account the height differences. The GetConnectionCost() method // gets the cost of the path between two nodes, based on the distance between them.

if (IntermediateHeuristic<LeastCost) {LeastCost = IntermediateHeuristic;LeastNode = connection.Node2;// We found the next best node. } connection.Node2.IsClosed = true; } } }Else// (connection.Node1 != NextNode) {

// Do the same as the code above, but on the other node in the connection.if (connection.Node1.IsPointInBox(refCurrentRequest.EndVector)) {IsComplete = true;CurrentRequest.Path.Add(CurrentRequest.EndVector);break; }else {if (!connection.Node1.IsClosed) {IntermediateHeuristic = PathfindingNode.CalculateHeuristic(ref connection.Node1.Center) +

connection.GetConnectionCost(NextNode);if (IntermediateHeuristic<LeastCost) {LeastCost = IntermediateHeuristic;LeastNode = connection.Node1; } connection.Node1.IsClosed = true; } } } }

NextNode.IsClosed = true; // Don't iterate through this node again.if (LeastNode == null) // Couldn't find an optimal route from the current node = end! {IsComplete = true;CurrentRequest.Path.Add(CurrentRequest.EndVector);// Let the requestor go to the destination directly. }elseif (!IsComplete) {NextNode = LeastNode; // Continue with pathfinding…CurrentRequest.Path.Add(LeastNode.Center);// The next node is added to the path. } }else {// Pathfinding within the same node. This node is thus the end node.CurrentRequest.Path.Add(CurrentRequest.EndVector);IsComplete = true; }



// If the pathfinding is complete, reset all the nodes.if (IsComplete) {foreach (PathfindingNode Node inPathfindingNode.Nodes)Node.IsClosed = false; } }// End of HandleRecurringRequest() }// End of PathfindingService class.

publicclassPathfindingServiceRequest {// This class handles the pathfinding service request.publicVector3StartVector, EndVector;publicBasicEnemy Requestor;// The requesting object.publicList<Vector3> Path;// The path that will be populated by the pathfinding algorithm.

publicPathfindingServiceRequest(Vector3StartVector, Vector3EndVector, BasicEnemy Requestor)

{this.StartVector = StartVector;this.EndVector = EndVector;this.Requestor = Requestor; Path = newList<Vector3>();Path.Capacity = 15;// We anticipate a maximum path length of 15, but this can be increased dynamically by the list itself. } }// End of PathfindingServiceRequest class.}// End of namespace.

5.2.2 Discussion

These 2 classes, the PathfindingService and the PathfindingServiceRequest, will be

used to describe how a pathfinding request is handled.

Firstly, a PathfindingServiceRequest is logged. It contains a start and end node, and

details who sent the request. It also contains a list which will be populated when

pathfinding is being done.This list is the actual path that a requestor will take when

its pathfinding request had been serviced. The request is logged via a method.

The PathfindingService is a singleton class, since we only ever want one instance of

it. This is the principle upon which the service is created.

The service first checks whether its current request is an old one (this happens in the

Update method). If it is, it then handles an iteration of the request, in other words it

does a part of the request. It then checks whether the request is complete, and if it

is, it notifies the requestor. If it turns out to be a new request, the service follows a

different route. It first finds the start and destination nodes that will be used for

pathfinding. The next update it will continue with the pathfinding, or the servicing of

the old request. So each new request has one unique iteration at the beginning of its

cycle to determine start and end nodes, then they undergo iterative pathfinding.

The NotifyRequestor notifies the requestor that a path has been found. The path to

the destination is also provided. This is all that the requestor needs to know.



The HandleNewRequest takes a new request from the queue when it is time for this.

It then determines the start and end nodes for the request.

The HandleRecurringRequest does the pathfinding. It operates on one node. This

node is changed after each iteration. The method goes through each connection that

the current node has, and determines which node is the next best, by using

heuristics and connection costs. The algorithm takes into account the height

difference between nodes (the heuristic) as well as the Euclidean distance between

their center points (the connection cost).

To summarise: there is a service that processes each request iteratively and only

one at a time. Requests are logged. The first time a request is serviced, the service

determines the start and end nodes to find a path between. Thereafter, the service

finds the next best node to travel to based on heuristics and connection costs. Upon

completion, the requestor is notified and provided with a path.



5.3 The Pursuing Behavioural State

5.3.1 Code// ===========================================// Class Name: Pursuing// Author: Francois van Greunen// Date: October 2013// Status: Complete // Description:// Encapsulates the 'Pursuing' state of // a BasicEnemy.

namespace _3D_Shooter{publicclassPursuing : IBehaviourState {IBehaviourStateTransitionState;// A state is stored. This state will become the containing BasicEnemy’s next state.

publicVector3 Update(BasicEnemyCallingObject, floatgameTime) // This method is called each frame to update the state. It returns the // next position that a CallingObject will assume. The calling object is the object that contains this state and obtains its behavior from it. {// Check if the Enemy can see the player, then check if the Enemy is not seeing through terrain:boolCanSeePlayer = FieldOfViewDetection.IsSeen(CallingObject);

// The new direction that an Enemy should run in order to follow the Player:Vector3 Direction = Vector3.Normalize(Player.Instance.PlayerPosition - CallingObject.GetPosition()) * CallingObject.MoveSpeed;CallingObject.Direction.X = Direction.X;CallingObject.Direction.Y = Direction.Y;CallingObject.Direction.Z = Direction.Z;Direction.Z *= -1;

if (CallingObject.HasReachedLowerHealthThreshold() && (CallingObjectisMinion)) {// BasicEnemy lost too much health AND BasicEnemy is a minion// Transition into fleeing state...TransitionState = newFleeing(CallingObject);returnCallingObject.Position;// Immediately continue with transitioning state. }elseif (!CanSeePlayer) {// Player not spotted anymore or Enemy too far from player, transition into converging state...TransitionState = newConverging(Player.Instance.PlayerPosition, CallingObject, false);returnCallingObject.Position;// Immediately continue with transitioning state. }elseif (CallingObjectisLeader&&EnemyManager.LeadershipCounter>EnemyManager.MaxLeadershipCountdown) {// BasicEnemy is a leader AND the countdown for leadership tasks is over.// Log organised swarming command...i.e. let the minions follow this calling object.EnemyManager.LeadershipCounter = 0; // Reset the Counter:foreach (BasicEnemy enemy inEnemyManager.Instance.Enemies)if (enemy isMinion&&Vector3.DistanceSquared(enemy.Position, CallingObject.Position) <CallingObject.CallDistance&& (enemy.BehaviourStateisWandering || enemy.BehaviourStateisSearching || enemy.BehaviourStateisConverging)) {enemy.OrganisedSwarm((Leader)CallingObject); // Log the swarming command.enemy.HasChaoticSwarmCommand = false;// Stop swarming randomly, follow the leader now. } }

// Check if the Enemy can attack the player:if (CallingObject.AttackCountDown>CallingObject.MaxAttackCountDown&&

Vector3.DistanceSquared(CallingObject.GetPosition(), Player.Instance.PlayerPosition) <CallingObject.AttackDistance) {Player.Instance.Health -= CallingObject.AttackDamage;CallingObject.AttackCountDown = 0; // Can only attack every x seconds.Defined in the difficulty classes.HeadsUpDisplay.Instance.IsAttacked = true; }

// Continue...Vector3 Position = CallingObject.Position;Position.X += Direction.X * gameTime;Position.Z += Direction.Z * gameTime;Position.Y = Terrain.Instance.GetHeight(Position.X, Position.Z) + CallingObject.VerticalOffset;

return Position; }// End of Update()

publicIBehaviourState Transition() {returnTransitionState; }// End of Transition() }// End of class}



5.3.2 Discussion

The Pursuing behavioural state is the state in which an NPC is whenever it is

pursuing or following the player. It defines the behaviour of an NPC when in that

state.

The Transition method is used to transition to another state. The NPC calls this

method, and the behaviour state (Pursuing in this case) returns the next behaviour

state that it should transition to. The state is set within the Update method,

depending on certain conditions.

The Update method fires every frame (or loop).Firstly it checks whether the NPC can

still see the player (field-of-view-detection), it then calculates which direction the

NPC should run in order to chase the player.

It then checks whether the enemy has lost too much health to continue the pursuing,

and if so, transitions into the fleeing state.If it cannot see the player anymore, it will

converge on the player’s last known position.

If the containing NPC is a leader, the Update method checks whether the countdown

for leadership tasks has expired, and then logs a leadership command. All minions in

the immediate surrounding are notified, and then follow the leader.

Finally, the method checks whether the player can be attacked.



5.4 Terrain Content

5.4.1 Code

// ===========================================// Class Name : TerrainContent// Author: Francois van Greunen// Date: October 2013// Status: Complete // Description:// Responsible for loading terrain content.

namespace _3D_Shooter{publicabstractclassTerrainContent {publicEffectTerrainEffect { get; protectedset; } // Effect for the terrain, multitextured.publicTexture2DHeightMapTexture { get; protectedset; } // The height map.publicTexture2D[] Multitextures { get; protectedset; } // The multitextures.protectedstringMultiTextureEffectAsset, MapAsset;// Locations of some textures.protectedstring[] MultiTextureAssets;// Locations of the textures.publicList<GrassLevel> Grass;publicTreeManagerTreeManager;

protectedvoidLoadAssets(floatambientLight) {

// Populate the assets from the asset files.TerrainEffect = Volition.Game.Content.Load<Effect>(MultiTextureEffectAsset);HeightMapTexture = Volition.Game.Content.Load<Texture2D>(MapAsset);Multitextures = newTexture2D[4];for (int i = 0; i < 4; i++)Multitextures[i]= Volition.Game.Content.Load<Texture2D>(MultiTextureAssets[i]);InitializeDraw(); }// End of LoadAssets()

privatevoidInitializeDraw()// Initializes some drawing parameters. {TerrainEffect.Parameters["xProjection"].SetValue(Player.Instance.Projection);TerrainEffect.Parameters["xWorld"].SetValue(Matrix.Identity);TerrainEffect.Parameters["xAmbient"].SetValue(Terrain.AMBIENT_LIGHT);TerrainEffect.Parameters["xConeAngle"].SetValue(0.1f);TerrainEffect.Parameters["xConeDecay"].SetValue(6f);TerrainEffect.Parameters["xTexture0"].SetValue(Multitextures[0]);TerrainEffect.Parameters["xTexture1"].SetValue(Multitextures[1]);TerrainEffect.Parameters["xTexture2"].SetValue(Multitextures[2]);TerrainEffect.Parameters["xTexture3"].SetValue(Multitextures[3]);TerrainEffect.CurrentTechnique= TerrainEffect.Techniques["MultiTextured"]; } // End of InitializeDraw()

publicabstractvoidLoadGrass(int Size); // To be implemented by inheriting classes.publicabstractvoidLoadTrees(int Size); // To be implemented by inheriting classes.

publicstaticintGetGrassCount(int Size)// Gets the number of grass patches based on map size. {int Count = 0;switch (Size) {case 1: Count = 5000;break;case 2: Count = 6000;break;case 3: Count = 7200;break;case 4: Count = 8400;break;case 5: Count = 10000;break; }return Count; } // End of GetGrassCount()



publicstaticintGetTreeCount(int Size)// Gets the number of trees based on map size. {int Count = 0;switch (Size) {case 1: Count = 22;break;case 2: Count = 35;break;case 3: Count = 50;break;case 4: Count = 65;break;case 5: Count = 75; break; }return Count; } // End of GetTreeCount() }// End of TerrainContent()

publicclassMap1 : TerrainContent {public Map1(floatambientLight) {MultiTextureEffectAsset = "terrain/MultiTextureEffect";MapAsset = "terrain/map1";MultiTextureAssets = newstring[4];MultiTextureAssets[0] = "terrain/multitextures/1/1";MultiTextureAssets[1] = "terrain/multitextures/1/2";MultiTextureAssets[2] = "terrain/multitextures/1/3";MultiTextureAssets[3] = "terrain/multitextures/1/4";TreeManager = newTreeManager();LoadAssets(ambientLight); }// End of constructor.

publicoverridevoidLoadGrass(int Size) {// Loads grass at certain height of the terrain. For example, one can specify that a certain type of grass should only be in lowlandareas. Grass = newList<GrassLevel>();Grass.Add(newGrassLevel(Volition.Game.GraphicsDevice, Volition.Game.Content.Load<Effect>("instancedgrass/InstanceEffect"),Volition.Game.Content.Load<Texture2D>("InstancedGrass/grass1"),Player.Instance.Projection, GrassLevel.GeneratePositions(TerrainContent.GetGrassCount(Size), Terrain.Instance, 0, 4))); }// End of LoadGrass()

publicoverridevoidLoadTrees(int Size) {

// Loads trees at random positions within the arena.floatmaxX = Terrain.Instance.TerrainBoundary.Max.X - 1;floatmaxZ = Terrain.Instance.TerrainBoundary.Max.Z - 1;floatminX = Terrain.Instance.TerrainBoundary.Min.X + 1;floatminZ = Terrain.Instance.TerrainBoundary.Min.Z + 1;

ITreeType type = newGraywood();// Generate a graywood tree.for (int i = 0; i <TerrainContent.GetTreeCount(Size); i++)

TreeManager.GenerateTree(type, newVector2(RandomHelper.GetRandomFromInterval(minX, maxX), RandomHelper.GetRandomFromInterval(minZ, maxZ)));

type = newGardenwoodShrub();// Generate a gardenwood shrub.for (int i = 0; i <TerrainContent.GetTreeCount(Size); i++)

TreeManager.GenerateTree(type, newVector2(RandomHelper.GetRandomFromInterval(minX, maxX), RandomHelper.GetRandomFromInterval(minZ, maxZ)));

}// End of LoadTrees() }}



5.4.2 Discussion

This code snippet contains the TerrainContentabstract class and one implementation

thereof. The TerrainContent provides the content for the creation of the terrain.The

Terrain class uses the TerrainContent class. It defines the terrain topography, the

multitextures used to create the grass/mud/snow textures on the ground, the grass,

as well as the trees. The TerrainContent abstract class also specifies the amount of

grass or the number of trees to place on the terrain.

The Map1 class represents the first map that a player can choose to play on. It loads

a certain number of trees and a certain amount of grass based on the terrain size. It

also loads a certain map type, as well as the textures that are rendered on it. Doing it

this way allows one to easily add more maps. There are 10 maps defined, each with

their own unique combinations of terrain, terrain textures, grass and trees.

Note the implementation of a Factory pattern at the TreeManager.GenerateTree

method in the last method of the code snippet. It allows one to specify which type of

tree one wants at which location.

5.5 Conclusion This chapter presented and discussed some of the more intriguing and difficult code

snippets from the game. This is the last chapter, only followed by the reference list.



6. Reference List Crytek(2013), CryEngine 3 -The Complete Game Development Solutionhttp://www.crytek.com/cryengine/cryengine3/overviewRetrieved from the World Wide Web at 2013/02/21 11:52

Grzyb, J.(2005) Artificial Intelligence in Gameshttp://www.codeproject.com/Articles/14840/Artificial-Intelligence-in-GamesRetrieved from the World Wide Web at 2013/02/26 14:00

Kato, P. (2010)Video Games in Health Care: Closing the GapReview of General Psychology 2010, Volume 14, No 2, p113-121

Keim, B. (2012)Artificial Intelligence could Be on Brink of Passing Turing Testhttp://www.wired.com/wiredscience/2012/04/turing-test-revisited/Retrieved from the World Wide Web at 2013/02/21 10:00

Laird, J. & van Lent, M. (2001)Human-Level AI’s Killer Application: Interactive Computer GamesAI Magazine,2001, Volume 22, No 2

Maxxess-systems (2013), What is a Software Frameworkhttp://www.maxxess-systems.com/whitepapers/what_is_a_software_framework.pdfRetrieved from the World Wide Web at 2013/02/21 10:30

McCarthy, J.(2002)What is Artificial Intelligence?Computer Science Department, Stanford University, Stanford

Merriam-Webster (Online Dictionary and Thesaurus)(2013)Special Effectshttp://www.merriam-webster.com/dictionary/special%20effectsRetrieved from the World Wide Web at 2013/02/26 12:20

Millington, I.(2006)Artificial Intelligence for GamesSan FranciscoMorgan Kaufmann Publishers


http://www.merriam-webster.com/dictionary/special%20effects

http://www.maxxess-systems.com/whitepapers/what_is_a_software_framework.pdf

http://www.maxxess-systems.com/whitepapers/what_is_a_software_framework.pdf

http://www.wired.com/wiredscience/2012/04/turing-test-revisited/

http://www.codeproject.com/Articles/14840/Artificial-Intelligence-in-Games

http://www.crytek.com/cryengine/cryengine3/overview


Northwestern UniversityComputer Science Department (2002)Lecture Course (CS395): Introduction to Game AIhttp://www.cs.northwestern.edu/~forbus/c95-gd/lectures /Game_AI_Introduction.pdfRetrieved from the World Wide Web at 2013/03/02 12:30

Orry, J. (2012)What is a Videogame?http://www.videogamer.com/news/what_is_a_videogame.htmlRetrieved from the World Wide Web at 2013/04/07 21:55

Poh, M.(2012)The Future of Gaminghttp://www.hongkiat.com/blog/future-of-gaming/Retrieved from the World Wide Web at 2013/02/26 13:00

Ram,A. &Ontanon, S. & Mehta, M.(2007)Artificial Intelligence for Adaptive Computer GamesTwentieth International FLAIRS Conference on AIKey West, Florida, USAMay 2007

Rosen, D. (2009)What are Indie Games?http://blog.wolfire.com/2009/08/what-are-indie-games/Retrieved from the World Wide Web at 2013/03/02 12:21

Slick2D.org (2013)What is Slick2Dhttp://www.slick2d.org/Retrieved from the World Wide Web at 2013/02/21 11:35

Stead, C. (2009)The 10 Best Game Engines of This Generationhttp://www.ign.com/articles/2009/07/15/the-10-best-game-engines-of-this-generationRetrieved from the World Wide Web at 2013/02/21 10:00

Unity3D.com (2013)Create the games you love with Unityhttp://unity3d.com/unity/Retrieved from the World Wide Web at 2013/02/21 11:35

van Lent,M. &Laird,J.&Buckman, J. & Hartford, J. &Houchard, S &Steinkraus, K.&Tedrake, R.(1999)Intelligent Agents in Computer GamesSixteenth National Conference on AIOrlando, Florida, USAJuly 1999


http://unity3d.com/unity/

http://www.ign.com/articles/2009/07/15/the-10-best-game-engines-of-this-generation

http://www.ign.com/articles/2009/07/15/the-10-best-game-engines-of-this-generation

http://www.slick2d.org/

http://blog.wolfire.com/2009/08/what-are-indie-games/

http://www.hongkiat.com/blog/future-of-gaming/

http://www.videogamer.com/news/what_is_a_videogame.html

http://www.cs.northwestern.edu/~forbus/c95-gd/lectures%20/Game_AI_Introduction.pdf

http://www.cs.northwestern.edu/~forbus/c95-gd/lectures%20/Game_AI_Introduction.pdf


Ward, J. (2008)What is a Game Engine?http://www.gamecareerguide.com/features/529/Retrieved from the World Wide Web at 2013/04/07 21:45

Webopedia (2013) Shaderhttp://www.webopedia.com/TERM/S/shader.htmlRetrieved from the World Wide Web at 2013/04/07 21:50

Wexler, J. (2002)Artificial Intelligence in GamesCourse Assignment (CS242)University of Rochester

END – 17 500 Words


http://www.webopedia.com/TERM/S/shader.html

http://www.gamecareerguide.com/features/529/

volition technical manual - web servercsi.ufs.ac.za/courses/bcis1623/2016/practical... · web...

Documents