Project Number:XXXXXXXXXX
Volition
Technical 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 e
FE van Greunen - 2009002011
Volition Technical Manual
Table of Contents
List 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 e
FE van Greunen - 2009002011
Volition Technical Manual
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 e
FE van Greunen - 2009002011
Volition Technical Manual
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|Page
FE van Greunen - 2009002011
Volition Technical Manual
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 e
FE van Greunen - 2009002011
Volition Technical Manual
Chapter 1:Introduction
1.1 Introduction
For the purpose of the RIS693 year module project, I created a 3 Dimensional FirstPerson 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 85
FE van Greunen - 2009002011
Volition Technical Manual

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.
Page 2 of 85
FE van Greunen - 2009002011
Volition Technical Manual

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.
Page 3 of 85
FE van Greunen - 2009002011
Volition Technical Manual

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 rulebased 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
Page 4 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 5 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 6 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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” (Maxxesssystems, 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.
Page 7 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 8 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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).
Page 9 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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 humanlevel 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:
Page 10 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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?
Page 11 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 12 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 13 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 14 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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 pregenerated 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.
Page 15 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 16 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 17 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 18 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 19 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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 1st 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.
Page 20 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 21 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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;
Page 22 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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;
Page 23 of 85
FE van Greunen - 2009002011
Volition Technical Manual
3.5 Use Case Diagram
Here follows the overall use case diagram for the application (the complete package:
menu
system
and
game
system):
Volition
Exit Program
View Main Screen
View Controls
Screen
View About Screen
View Instructions
Screen
Start New Game
Set Difficulty
Set Map Size
Select Map
Shoot Weapon
Player
Move Character
«extends»
Jump
Reload Weapon
Switch Weapon
Quit Game
Pause/Resume Game
Place Obstacle
Block
Use Ammo/Med
Facility
Note, this diagram depicts the interactions between the player and the system. Other actors are
computer-generated at runtime (the so-called NPCs), and have not been included in the diagram for
sake of brevity and to allow flexibility in their design.
Figure 3.26 : Overall Use Case Diagram
Page 24 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Volition
Exit Program
Player
Figure 3.27 : Exit Program Use case
Exit Program
Actor: 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 Scenario
User John returned from playing a game. He User John returned from playing a game. He
is on the ‘Main’ screen. He wishes to exit the is on the ‘Main’ screen. He wishes to exit the
application and return to his desktop.
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.
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.
Page 25 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
View About Screen
Player
Figure 3.28 : View About Screen Use Case
View About Screen
Actor: Player
Description: Enables the user to view the ‘About’ screen, where information concerning
the creator and contributors of the program are displayed.
The user is on the ‘Main Menu’ screen.
Step-by-step:
1. The user selects to view the ‘About’ screen.
2. The program navigates to the ‘About’ screen.
Normal Use Scenario
Exception Scenario
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.
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:
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.
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 26 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Start New Game
Player
Figure 3.29 : Start New Game Use Case
Start New Game
Actor: 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.
The user is on the ‘Main Menu’ screen.
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 Scenario
User John started the program. He is on the User John started the program. He is on the
‘Main’ screen. He wishes to start a new ‘Main’ screen. He wishes to start a new
game.
game.
Step-by-step:
1. John selects to view the ‘New Game’
screen.
2. The program checks if a control is
selected.
3. The ‘New Game’ control has been
selected.
4. The program navigates to the ‘New
Game’ screen.
Step-by-step:
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 27 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
View Main Screen
Player
Figure 3.30 : View Main Screen Use Case
View Main Screen
Actor: 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 Scenario
User John viewed the program creator’s User John viewed the program creator’s
details. He is on the ‘About’ screen. He details. He is on the ‘About’ screen. He
wishes to return to the ‘Main’ screen.
wishes to return to the ‘Main’ screen.
Step-by-step:
1. John selects to view the ‘Main‘
screen.
2. The program checks if a control is
selected.
3. The ‘MainScreen‘control has been
selected.
4. The program navigates to the ‘Main’
screen.
Step-by-step:
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 28 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
View Instructions
Screen
Player
Figure 3.31 : View Instructions Screen Use Case
View Instructions Screen
Actor: Player
Description: Enables the user to view the ‘Instructions’ screen, where information
concerning the instructions on how to play the game is displayed.
The user is on the ‘Main Menu’ screen.
Step-by-step:
1. The user selects to view the ‘Instructions’ screen.
2. The program navigates to the ‘Instructions’ screen.
Normal Use Scenario
Exception Scenario
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.
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:
Step-by-step:
1. John selects to view the ‘Instructions‘
screen.
2. The program checks if a control is
selected.
3. The ‘Instructions‘ control has been
selected.
4. The program navigates to the
‘Instructions’ screen.
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 29 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
View Controls
Screen
Player
Figure 3.32 : View Controls Screen Use Case
View Controls Screen
Actor: Player
Description: Enables the user to view the ‘Controls’ screen, where information and
commands on how to play the game are displayed.
The user is on the ‘Main Menu’ screen.
Step-by-step:
1. The user selects to view the ‘Controls’ screen.
2. The program navigates to the ‘Controls’ screen.
Normal Use Scenario
Exception Scenario
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.
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:
Step-by-step:
1. John selects to view the ‘Controls’
screen.
2. The program checks if a control is
selected.
3. The ‘Controls’ control has been
selected.
4. The program navigates to the
‘Controls’ screen.
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 30 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Set Difficulty
Player
Figure 3.33 : Set Difficulty Use Case
Set Difficulty
Actor: 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 Scenario
User John is on the ‘New Game’ screen. He User John is on the ‘New Game’ screen. He
wishes to set the difficulty level of the wishes to set the difficulty level of the
upcoming game.
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.
Step-by-step:
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 31 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Select Map
Player
Figure 3.34 : Select Map Use Case
Select Map
Actor: Player
Description: Enables the user to select a preferred map to play the upcoming game on.
The user is on the ‘New Game’ screen.
Step-by-step:
1. The user changes the selected map on a control.
2. The input is validated.
Normal Use Scenario
Exception Scenario
User John is on the ‘New Game’ screen. He User John is on the ‘New Game’ screen. He
wishes to select a new map for the upcoming wishes to select a new map for the upcoming
game.
game.
Step-by-step:
1. John selects another map in the
‘Select Map’ control.
2. The program visually indicates the
change.
3. The program stores the new map
selection.
Step-by-step:
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 32 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Set Map Size
Player
Figure 3.35 : Set Map Size Use Case
Set Map Size
Actor: Player
Description: Enables the user to set the map size of the upcoming game.
The user is on the ‘New Game’ screen.
Step-by-step:
1. The user changes the map size on a control.
2. The input is validated.
Normal Use Scenario
Exception Scenario
User John is on the ‘New Game’ screen. He User John is on the ‘New Game’ screen. He
wishes to set the map size for the upcoming wishes to set the map size for the upcoming
game.
game.
Step-by-step:
1. John selects another map size in the
‘Select Map Size’ control.
2. The program visually indicates the
change.
3. The program stores the new map
size specification.
Step-by-step:
1. John clicks on open space, no control
is selected.
2. The program checks if a control is
selected.
3. No control is selected.
4. The program does nothing.
Page 33 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Move Character
«extends»
Jump
Player
Figure 3.36 : Move Character With Jump Use Case
Move Character With Jump
Actor: 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.
2.
3.
4.
The user presses one or more of the movement keys.
The in-game character moves in the appropriate direction.
The user presses the ‘Jump’ key whilst pressing one of the above keys.
The in-game character jumps whilst moving.
Normal Use Scenario
Exception Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
jump over a block.
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.
3. John presses the ‘Jump’ key.
4. John’s in-game character jumps.
Step-by-step:
1. John presses a key that is not
assigned.
2. Nothing happens.
Page 34 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Move Character
Player
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.
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.
Normal Use Scenario
Exception Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
run forward.
run forward.
Step-by-step:
1. John
presses
the
appropriate
movement key to run forward.
2. John’s in-game character moves
forward.
Step-by-step:
1. John presses a key that is not
assigned.
2. Nothing happens.
Page 35 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Quit Game
Player
Figure 3.38 : Quit Game Use Case
Quit Program
Actor: 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 Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
exit to the menus.
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’
screen.
Step-by-step:
1. John presses a key that is not
assigned.
2. Nothing happens.
Page 36 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Pause/Resume Game
Player
Figure 3.39 : Pause/Resume Game Use Case
Pause / Resume Program
Actor: 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 Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
pause the game in order to rethink his pause the game in order to rethink his
strategies.
strategies.
Step-by-step:
1. John presses the ‘Pause’ key.
2. The game pauses.
Step-by-step:
1. John presses a key that is not
assigned.
2. Nothing happens.
Page 37 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Switch Weapon
Player
Figure 3.40 : Switch Weapon Use Case
Switch Weapon
Actor: Player
Description: Enables the user to switch the in- game character’s weapon 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. 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 User John is playing the game. He wishes to
switch to another weapon.
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.
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.
Page 38 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Place Obstacle
Block
Player
Figure 3.41 : Place Obstacle Block Use Case
Place Obstacle Block
Actor: Player
Description: Enables the user’s in- game character to place an obstacle block 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 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 Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
place an obstacle block to provide protection place an obstacle block to provide protection
and cover.
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.
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.
Page 39 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Use Ammo/Med
Facility
Player
Figure 3.42 : Use Ammo/Med Facility Use Case
Use Ammo/Med Facility
Actor: 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.
The user is in the gameplay state, i.e. he/she is playing the game. The game is not paused.
Step-by-step:
1.
2.
3.
4.
The user presses the ‘Ammo/Med Facility’ key.
The in-game character’s health is regenerated.
The in-game character’s ammunition stores are regenerated.
The in-game character’s hunger is fulfilled.
Normal Use Scenario
Exception Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
get more ammunition.
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 ingame character is near the facility.
4. The in-game character is near the
facility.
5. The in-game character’s ammo is
regenerated.
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 ingame 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.
Page 40 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Reload Weapon
Player
Figure 3.43 : Reload Weapon Use Case
Reload Weapon
Actor: Player
Description: Enables the user’s character to reload its weapon 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 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 User John is playing the game. He wishes to
reload his weapon.
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.
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.
Page 41 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Volition
Shoot Weapon
Player
Figure 3.44 : Shoot Weapon Use Case
Shoot Weapon
Actor: Player
Description: Enables the user’s character to shoot its weapon 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 the ‘Shoot’ key.
2. The in-game character shoots a projectile in the direction it is facing.
Normal Use Scenario
Exception Scenario
User John is playing the game. He wishes to User John is playing the game. He wishes to
shoot an opponent.
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.
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.
Page 42 of 85
FE van Greunen - 2009002011
Volition Technical Manual
3.7Program States
Here follows a diagram of the states in which the application can be.
Start Program
Exit Program
Start Game
Gameplay State
Navigating State
End Game
Playing/
Resumed
Paused
The game can be in either of two states: Navigating or Gameplay. In the Navigating state, the user is
navigating through the various screens. In the Gameplay state, the user is playing the game.
Furthermore, the Gameplay state can be in either of 2 states: paused or playing/resumed.
Figure 3.45 : Program States
Page 43 of 85
FE van Greunen - 2009002011
Volition Technical Manual
3.8 Menu Hierarchy
Here follows a diagram of how the menu structure is laid out.
Figure 3.46 : Menu Hierarchy
Page 44 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 45 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 46 of 85
FE van Greunen - 2009002011
Volition Technical Manual

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
2. Field-of-view detection in each frame

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
2. Field-of-view detection in each frame
Page 47 of 85
FE van Greunen - 2009002011
Volition Technical Manual

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.
Page 48 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 49 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 50 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 51 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 52 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 53 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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:
𝑇(𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑) =
𝑇(𝑂𝑝𝑡𝑖𝑚𝑎𝑙) + 𝑇(𝑁𝑜𝑟𝑚𝑎𝑙) + 4𝑇(𝑃𝑒𝑠𝑠𝑖𝑚𝑖𝑠𝑡𝑖𝑐)
6
Time Estimates (Days)
ID
1
2
3
4
5
6
8
11
12
13
14
Task Name
Optimal
Project Proposal
Literature Review
Use Case Diagrams
Scenarios
Class Diagrams
Motivation for Technology Used
Project Day
Application
Technical Manual
User Manual
Project Day
Normal
3
30
16
16
15
1
1
140
35
25
2
Pessimistic
6
25
21
25
20
3
3
190
55
45
6
Expected Time
8
30
24
25
22
5
5
270
65
50
8
Start Date
6
27
21
24
20
3
3
195
54
43
6
End Date
07 February 2013
16 February 2013
04 March 2013
26 March 2013
30 March 2013
16 April 2013
30 April 2013
23 March 2013
18 August 2013
29 August 2013
12 October 2013
13 February 2013
15 March 2013
25 March 2013
19 April 2013
19 April 2013
19 April 2013
03 May 2013
04 October 2013
11 October 2013
11 October 2013
18 October 2013
14 October
07 October
30 September
23 September
16 September
09 September
26 August
02 September
19 August
12 August
29 July
05 August
22 July
15 July
08 July
01 July
24 June
17 June
10 June
27 May
03 June
20 May
13 May
06 May
29 April
22 April
15 April
08 April
01 April
25 March
18 March
11 March
04 March
25 February
18 February
11 February
04 February
Project Proposal
Literature Revi ew
Use C ase Diagrams
Scenari os
Class Diagrams
Motivation for Techno logy Used
Project Day
Application
Technical Manual
User Manual
Project Day
Figure 4.1 : Expected Schedule
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.
Page 54 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 55 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 56 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Figure 4.4: Class Diagram Part 2
Page 57 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Figure 4.5 : Class Diagram Part 3
Page 58 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.1 State System
Game (XNA Implementation)
1
Volition
1
+GameState : GameplayState
+MenuState : MenuState
+CurrentDifficulty : IDifficulty
+PlayerScore : int
-MapSelection : int
1
-TerrainSize : int
-GraphicsDeviceManager : GraphicsDeviceManager
-Game : Volition
-State : ProgramState
+Volition()
+ToggleStateNextUpdate()
#Update(in gameTime : GameTime)
#Draw(in gameTime : GameTime)
1
#Initialize()
-ToggleState()
«enumeration»
ProgramState
+Menu
+Game
State System
GameplayState
1
1
-SpriteBatch : SpriteBatch
-SpriteFont : SpriteFont
-Game : Volition
-IsPaused : bool
+Draw(in gameTime : GameTime)
+Update(in gameTime : GameTime)
+Initialize()
+GamePlayState(in Difficulty : int, in MapSize : int, in MapSelection : int, in PlayerScore : int)
#LoadContent(in Difficulty : IDifficulty, in MapSelection : int, in MapSize : int, in PlayerScore : int)
-ProcessInput()
-FramesPerSecondUpdate(in gameTime : GameTime)
1
«interface»
IDifficulty
+GetCallDistance() : int
+GetAttackDistance() : int
+GetMaxViewDistance() : int
+GetLowerHealthThreshold() : int
+GetAttackCountdown() : int
+GetLeaderAttackDamage() : int
+GetMinionAttackDamage() : int
+GetLeaderMoveSpeed() : int
+GetMinionMoveSpeed() : int
+GetLeaderHealth() : int
+GetMinionHealth() : int
+GetPlayerHealthDecay() : float
+GetPlayerHungerDecay() : float
+GetMinionKillScore() : int
+GetLeaderKillScore() : int
+GetEnemyHealthRegenerationRate() : int
+GetMaxDepotRegenerationCountdown() : int
+GetLeadershipCallcountdown() : int
+GetMaxEnemyCount() : int
+GetEnemiesToKillBeforeProgression() : int
+EscalateDifficulty() : IDifficulty
+GetIntegerRepresentation() : int
+GetLeaderSpawnCountdown() : int
+GetMinionSpawnCountdown() : int
+GetWeapons : List<Weapons>(in Game : Volition)
+GetDescription() : int
Walkover
Easy
Medium
Hard
Insane
MenuState
1
+Screen : MenuScreen
+SpriteBatch : SpriteBatch
+SpriteFont : SpriteFont
+Initialize()
+Update(in gameTime : GameTime)
+Draw(in gameTime : GameTime)
+MenuState()
Nightmare
Figure 4.6 : State System Class Diagram
Page 59 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 60 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.2 Menu System
Menu System (Composite Pattern)
GameOverScreen
MenuScreen
+Menu : Menu
+BannerRectangle : Rectangle
-width : int
-height : int
+Update()
+Draw()
+MenuScreen()
MenuComponent
NewLevelScreen
+NewLevelScreen(in PreviousDifficulty : IDifficulty, in NextDifficulty : IDifficulty)
StartNewGameScreen
+IsClicked : bool
-UpperRectangle : Rectangle
-LowerRectangle : Rectangle
-IndicatorRectangle : Rectangle
-ControlNameColor : Color
-SelectionColor : Color
-UpperTexture : Texture2D
-LowerTexture : Texture2D
-SelectedTexture : Texture2D
-IndicatorTexture : Texture2D
+SelectedIndex : int
-ControlName : string
-Indicator : string
-UpText : string
-DownText : string
-ControlNamePosition : Vector2
-SelectionIndicatorPosition : Vector2
-UpTextPosition : Vector2
-DownTextPosition : Vector2
-Delay : int
+Update()
+Draw()
-CheckMouseClick() : bool
-CheckMouseEnter() : bool
+Up() : bool
+Down() : bool
+UpDownControl()
1
+Update()
+Draw()
UpDownControl
+GetSelectedValueAsInteger(in ComponentIndex : int) : int
0..*
ControlsScreen
VisualElement
-PositionRectangle : Rectangle
-RectangleColor : Color
-Texture : Texture2D
+VisualElement()
+Update()
+Draw()
TextElement
-Text : string
-Position : Vector2
-RectangleColor : Color
-TextColor : Color
-Scale : float
+TextElement()
+Update()
+Draw()
InstructionsScreen
HomeScreen
Button
#Text : string
#PositionRectangle : Rectangle
#TextPosition : Vector2
#TextColor : Color
#RectangleColor : Color
#TextScale : float
#ClearTexture : Texture2D
#HoverTexture : Texture2D
+Update()
+Draw()
-CheckMouseClick() : bool
-CheckMouseEnter() : bool
AboutScreen
1
1
Menu
-Components : List<MenuComponent>
+Menu()
+Update()
+Draw()
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.
Page 61 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.3 Terrain Module
Figure 4.8 : Terrain Module Class Diagram
Page 62 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 63 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.4 NPC Module
Figure 51 : NPC Module Class Diagram
Page 64 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 65 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.5 Pathfinding Module
Figure 4.10: Pathfinding Module Class Diagram
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.
Page 66 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.6 Player Module
Figure 4.11 : Player Module Class Diagram
Page 67 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 68 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.7 Finite State Machine Module for NPCs
Finite State Machine (State Pattern)
Converging
-LastKnownPosition : Vector3
-TransitionState : IBehaviourState
+Path : List<Vector3>
+PathfindingIsReady : bool
-IsOrganisedCommand : bool
+Converging(in LastKnownPosition : Vector3, in CallingObject : BasicEnemy, in IsOrganisedCommand : bool)
1
Searching
Pursuing
Wandering
-TransitionState : IBehaviourState
-RotationCounter : Float
-MAXROTATION : float
-TransitionState : IBehaviourState
-WanderTarget : Vector3
-TransitionState : IBehaviourState
+Wandering()
1
1
1
1
1
1
1
«interface»
1 1
IBehaviourState
+Update : Vector3(in CallingObject : BasicEnemy, in gameTime : float)
+Transition() : IBehaviourState
Fleeing
-TransitionState : IBehaviourState
-FleeDirection : Vector3
+Fleeing(in CallingObject : BasicEnemy)
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.
Page 69 of 85
FE van Greunen - 2009002011
Volition Technical Manual
4.4.8 Helper Classes
SoundManager
CollisionHandler
+Instance : CollisionHandler
-CollisionHandler()
+CreateInstance() : CollisionHandler
+Update(in gameTime : GameTime)
+ProjectileCollision()
+CheckObstacleObstacleCollision(in BoxToCheck : BoundingBox)
+ProjectileTerrainCollision(in ProjectileRay : Ray, in MaxDistanceToAllowChecking : float, in CollisionPosition : Vector3, in StepIncrement : float)
+EnemyObstacleCollision()
+EnemyTerrainCollision()
+EnemyCollisionChecking(in Index : int, in Box : BoundingBox)
+PlayerTerrainCollision()
+PlayerObstacleCollision()
+PlayerCollisionChecking(in Box : BoundingBox, in Offset : float)
FieldOfViewDetection
InputHandler
-Bounds : Point
+PrevMouseState
+PrevMouseState : MouseState
+CurrMouseState : MouseState
+PrevKeybState : KeyboardState
+CurrKeybState : KeyboardState
-Bounds
-InputHandler()
+CreateInstance() : InputHandler
+Update(in gameTime : GameTime)
+IsKeyPressed(in Key) : bool
+IsKeyPressedOnce(in Key) : bool
-CollisionPointWithTerrain : Vector3
-ContainmentType : ContainmentType
+IsSeen(in CallingObject : BasicEnemy) : bool
RandomHelper
-Random : Random
+Instance : RandomHelper
-RandomHelper()
+BitRandom() : int
+BooleanRandom() : bool
+FloatRandom() : float
+GetRandomFromInterval(in Lower : float, in Upper : float) : float
+GetRandomIntegerFromInterval(in Lower : int, in Upper : int) : int
+Instance : SoundManager
-MenuBackground : Song
-GamePlaySongs : List<Song>
-HealthLow : SoundEffectInstance
-MenuSelection : SoundEffect
-MenuBack : SoundEffect
-RegenerateSuccess : SoundEffect
-RegenerateFail : SoundEffect
-Jump : SoundEffect
-PlayerAttacked : SoundEffect
-EnemyKilled : SoundEffect
-EnemyShot : SoundEffect
-ObstaclePlacementFai : SoundEffect
-SoundManager()
+CreateInstance() : SoundManager
+PlayMenuSelection()
+PlayMenuBack()
+PlayMenuBackground()
+StopMenuBackground()
+PlayGameBackground()
+StopGameBackground()
+ChangeSong()
+PlayHealthLow()
+StopHealthLow()
+StopAllEffects()
+PlayRegenerateSuccess()
+PlayRegenerateFail()
+PlayEffect(in Effect : SoundEffect, in Volume : float)
+PlayJump()
+PlayPlayerAttacked()
+PlayEnemyKilled()
+PlayEnemyShot()
+PlayObstaclePlacementSuccess()
+PlayObstaclePlacementFail()
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.
Page 70 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
Page 71 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 72 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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; // Singleton
privatestaticQueue<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()
Page 73 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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 StartNode
int 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 EndNode
for (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;
}
Page 74 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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;
}
Page 75 of 85
FE van Greunen - 2009002011
Volition Technical Manual
// 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.
Page 76 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 77 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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
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);
// next
// 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
}
Page 78 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 79 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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()
Page 80 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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, new
Vector2(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, new
Vector2(RandomHelper.GetRandomFromInterval(minX, maxX),
RandomHelper.GetRandomFromInterval(minZ, maxZ)));
}// End of LoadTrees()
}
}
Page 81 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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.
Page 82 of 85
FE van Greunen - 2009002011
Volition Technical Manual
6. Reference List
Crytek(2013),
CryEngine 3 -The Complete Game Development Solution
http://www.crytek.com/cryengine/cryengine3/overview
Retrieved from the World Wide Web at 2013/02/21 11:52
Grzyb, J.(2005)
Artificial Intelligence in Games
http://www.codeproject.com/Articles/14840/Artificial-Intelligence-in-Games
Retrieved from the World Wide Web at 2013/02/26 14:00
Kato, P. (2010)
Video Games in Health Care: Closing the Gap
Review of General Psychology
2010, Volume 14, No 2, p113-121
Keim, B. (2012)
Artificial Intelligence could Be on Brink of Passing Turing Test
http://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 Games
AI Magazine,2001, Volume 22, No 2
Maxxess-systems (2013), What is a Software Framework
http://www.maxxesssystems.com/whitepapers/what_is_a_software_framework.pdf
Retrieved 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 Effects
http://www.merriam-webster.com/dictionary/special%20effects
Retrieved from the World Wide Web at 2013/02/26 12:20
Millington, I.(2006)
Artificial Intelligence for Games
San Francisco
Morgan Kaufmann Publishers
Page 83 of 85
FE van Greunen - 2009002011
Volition Technical Manual
Northwestern UniversityComputer Science Department (2002)
Lecture Course (CS395): Introduction to Game AI
http://www.cs.northwestern.edu/~forbus/c95-gd/lectures
/Game_AI_Introduction.pdf
Retrieved 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.html
Retrieved from the World Wide Web at 2013/04/07 21:55
Poh, M.(2012)
The Future of Gaming
http://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 Games
Twentieth International FLAIRS Conference on AI
Key West, Florida, USA
May 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 Slick2D
http://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 Generation
http://www.ign.com/articles/2009/07/15/the-10-best-game-engines-of-thisgeneration
Retrieved from the World Wide Web at 2013/02/21 10:00
Unity3D.com (2013)
Create the games you love with Unity
http://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 Games
Sixteenth National Conference on AI
Orlando, Florida, USA
July 1999
Page 84 of 85
FE van Greunen - 2009002011
Volition Technical Manual
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)
Shader
http://www.webopedia.com/TERM/S/shader.html
Retrieved from the World Wide Web at 2013/04/07 21:50
Wexler, J. (2002)
Artificial Intelligence in Games
Course Assignment (CS242)
University of Rochester
END – 17 500 Words
Page 85 of 85
FE van Greunen - 2009002011