Dissertation_Final_Report

Long Range Orbital Whoppers
Final Report
Submitted for the MEng in
Computer Sciences
April 2015
by
Thomas Anthony Day

1 Table of Contents
2 Introduction .........................................................................................................................5
3 Aim and Objectives.............................................................................................................6
Objective 1 – The Artificial Intelligence ..............................................................................6
Objective 2 – World Generator...........................................................................................7
Objective 3 – GUI and Controls..........................................................................................7
Objective 4 – The Game Engine ........................................................................................8
Objective 5 – The World and its Forces.............................................................................8
4 Background.........................................................................................................................9
Introduction.............................................................................................................................9
Focus Group Study ..............................................................................................................12
Collection of Game Qualities............................................................................................12
Building the Measure........................................................................................................13
The Target Audience Rating ............................................................................................15
Implementation Technologies ..............................................................................................17
The AI Component ...............................................................................................................18
The Problem of Path Finding ...............................................................................................19
Dijkstra’s Algorithm ...........................................................................................................19
The World Map Grid .........................................................................................................20
GUI Considerations..............................................................................................................21
Saving States .......................................................................................................................21
5 Technical Development....................................................................................................22
Design Process....................................................................................................................22
Agile Software Development............................................................................................22
Rapid Application Development (RAD) ............................................................................23
Test Design..........................................................................................................................23
Game Design .......................................................................................................................24
Nodes................................................................................................................................24
Node Stats ........................................................................................................................24
Types of Node...................................................................................................................25
Special Nodes...................................................................................................................26
GUI Design...........................................................................................................................27
System Design.....................................................................................................................30
Player Turn .......................................................................................................................30
Class Overview.................................................................................................................30
Algorithms.........................................................................................................................31
Architecture – The Game Load ........................................................................................36
Architecture – The Player Turn GUI.................................................................................38

Architecture – Game Engine Model .................................................................................39
Architecture – Sound Engine............................................................................................40
Architecture – Advanced Programming ...........................................................................41
Architecture – XAML & XML.............................................................................................42
6 Evaluation .........................................................................................................................43
The Journey .........................................................................................................................43
Time Management Recognitions .........................................................................................44
WPF Resource Dictionary................................................................................................44
‘ToolSet’ Class design......................................................................................................44
Time Plan Review ................................................................................................................44
Legal disputes...................................................................................................................45
Other Issues Encountered:...............................................................................................45
Risk Review..........................................................................................................................46
Project Achievements ..........................................................................................................46
Ongoing Work ......................................................................................................................46
Future Work..........................................................................................................................47
7 Conclusion........................................................................................................................49
Critical Evaluation.................................................................................................................51
Final Remarks...................................................................................................................51
Appendix A: Test Design....................................................................................................52
Appendix B: Unified Class Diagram ...................................................................................54
Appendix C: The Core.........................................................................................................55
Appendix D: Task List [Original] .........................................................................................56
Appendix E: Time Plan [Original]........................................................................................57
Appendix F: Task List [New]...............................................................................................58
Appendix G: Time Plan [New].............................................................................................59
Appendix H: Legal Dispute .................................................................................................60
Email Trail.........................................................................................................................60
Invoice & license Agreement:...........................................................................................63
Appendix I: Subversion Source Control............................................................................64
Full Update and Versioning Trail:.....................................................................................65
Appendix J: Policy Tech Trees .........................................................................................71
Imperialism........................................................................................................................71
Bureaucracy......................................................................................................................72
Militarism...........................................................................................................................73
Industialism.......................................................................................................................74
Ecclesiasticism..................................................................................................................75
PUItem Descriptions:........................................................................................................76
References...............................................................................................................................87

[This page has been intentionally left blank]

2 Introduction
This report covers the journey of discovery and the trials of execution involved in designing,
creating and implementing of a risk style strategy game. The original task in hand can be
summed up as the following:
‘The goal of this project would be to make a simple Risk-style strategy
game in which the player captures nodes (e.g. planets, countries etc.) that
build up armies/fleets, which can then be used to capture other nodes.’
(Walker, 2015)
The project definition has been quickly adapted and moulded to form a basic outline
specification which follows the simple points below:
 The game will be set in space, the ‘nodes’ cited above will be planets, all drawn onto a
square grid in random places.
 The game will utilize blank squares on the draw grid to represent space, where a player
could position and move ships to defend and attack.
 The game will include strategic objects to control to further their goals and boost their
statistics.
 The game should include an AI/neutral party which also has nodes and ships to contend
against.
 The player would be able to develop the nodes they capture to make them stronger and
more advantageous.
 The game should contain statistics which would be used to calculate the player’s
success rates.
 The game will use a turn based play style to progress the game forward, each player
taking their turn sequentially, with AI entities taking a turn between each player turn.
Below is (fig 1.1) which shows how this all could take shape:
Fig. 1.1
Each player would take turns to configure their moves and attacks which would occur in real
time, via the GUI panels as indicated in (fig. 1.1). Strategic nodes cannot be captured but
they can be controlled by either player dependent on who has the most planets nearby.

3 Aim and Objectives
To design and implement a working strategic game in which a player
(Human User) pits their wits against an opponent (Human User) to
conquer the generated map. The players would achieve this by capturing
nodes along the map and by using said nodes, recruit militants to attack
and control further nodes as well as interact with the varying difficulty AI
entities across the map.
This above Aim will be met by the completion of this list of objectives:
1. Create small AI entities to play against the player with variable difficulties, sizes and
goals. These AI entities will take the form of ‘mini players’ which can in some cases
be allied with and otherwise played against.
2. Build a generator that will populate an empty map with an arbitrary amount of nodes
and strategic points, positioning the player and the AI objects sensibly to avoid unfair
means.
3. Create an in game GUI to allow the user to gain full control of their game objects and
make wise, informed decisions as well as provide insight into the game mechanics.
4. Produce a game engine to handle all calculations and data flow during the operation
of the game, including the sound, animation, save and load storage, GUI instructions
and battle component.
5. Design a unique world, set of militants and differing nodes and technology trees to
make gameplay more complex and challenging.
Objective 1 – The Artificial Intelligence
This objective will be classed as met with the successful implementation of an AI object.
Seeing as the game would allow a multitude of human players to play against, an AI object
would take the shape of a smaller entity within the game that all human players can interact
with, befriending or enslaving. There are two sub objectives that can be identified here:
Sub Objective1.1 – Barbarians
The inclusion of a ‘Barbarian’ unit which is a sole AI that spawns ships randomly across the
map. The idea behind this being that they will aggressively attack any player or other entity
without question until destroyed. With no diplomacy or negotiation, they act as the
annoyance of the game.
Sub Objective1.2 – City States
The inclusion of City State entities, smaller, non-expansive AI players that can be either
befriended or attacked. These AI units could come in sets, allowing more than just one to
pop up on the map, or be turned off if the player wishes it. These smaller AI players add the
diplomatic effect to the game, having to work with them to gain their favour in order to win
the game without having to fight them. But equally becoming a major threat if you chose to
attack them instead.

Objective 2 – World Generator
This objective will be classed as met with the successful generation of randomly placed
nodes on the map dependent on the settings set by the user. The criteria for excellence in
this objective would be the successful implementation of different rarities and higher/lower
value nodes and randomly placed artwork on this map. Once again, a simulation of
thousands of map generations will be used to measure the random output and at the same
time sensibility of the node positions outputted, to provide a strong evaluative measure.
Having a randomly generated map adds the effect of surprise, the need for the player to
embark on vast explorations each game, rather than them quickly getting used to the set of
static maps available if random generation wasn’t included. A Good map can be defined as a
map with a good amount of randomly placed varying nodes and objects, with some wide
space areas to have those intergalactic conflicts, whereas a bad generation of map would be
one with nodes all clustered in corners added an unfair advantage to those players closest.
Objective 3 – GUI and Controls
This objective will be classed as met with the provision of a simple to use Graphical User
Interface (GUI) for the user to interact with their empire. This kind of game is likely to have
many stats for the user to keep track of, as well as development of their empire to monitor. A
key aspect would be to include many overview windows and areas for the player to keep a
constant watch on what the state of the game is. Having easy access to information such as
their unit statistics as well as what there empires planets are currently doing is also of great
importance. All of the above presented together with a simple GUI helps the player
understand the game without becoming overwhelmed by its apparent complexity as well as
giving the player better control, insight and information. The sub objectives below identify the
main areas of the GUI that are to be developed.
Sub Objective3.1 PlayerOverview
The player overview window will need to display the current players statistics, which planets
they own, perhaps even where all their current ships are on the map, as well as any other
mechanics necessary like which AI units they have befriended. This is turn gives the player
better control of their units and empire resources.
Sub Objective3.2 Planet Management
The planet management window would need to be a more in depth analysis of each and
every planet that the player owns. From here the player would be able to select what ‘task’
the planet is currently undergoing as well as purchase anything that is needed. This window
will perhaps give the player more insight into how the planet is being run and a more in
depth description of the planets advantages and disadvantages.
Sub Objective3.3 Technology Trees
There should be a graphical visualization of every possible development the player can add
to their planet, this allows the player to make informed decisions in game about which
technologies they should choose to reach their desired goals.
Sub Objective3.4 ‘Tooltip like’ Information& Status
There should be a small tool tip sized window that follows about the mouse cursor and
provides snappy information on what the player is currently hovered over, to add a simple
way for the player to get quick updates on the current gameplay.
Sub Objective3.5 Front Page
The front page would include the settings for the audio/saving/video of the game as well as
providing the area to which a new player would set up a game and start. There should be a
section for advanced features as to not over complicate the first game start up for new
players. It should be possible to load and save games from here and manage said saves.
There should be a welcoming feel as well as easy to use and simple user control objects.

Objective 4 – The Game Engine
This objective will be classed as met when the game is able to successfully load up a map,
and deploy a turn based player system to allow both human user and AI to interact with one
another in a match. Each move against the player or a neutral party (uncaptured node) will
have its success or failure judged based on calculations factoring in the overall weight of
each other’s forces, temporary benefits or boosts, AI difficulty and a random modifier. Once
the calculations are complete, The Game Engine will address the GUI to display the
changes. A criteria for excellence in this objective would simply be the smooth and quick
execution of these calculations as they would be very complex. The game engine will endure
a heavy amount of stress testing to see how it can cope in high traffic, this will be the base
line of any evaluation performed in the later stages. The Game Engine would be broken
down into the following steps:
Sub Objective4.1 Core Engine
The core of the engine should be able to call the rest of the games components and hold
them all together. This would include receiving input of what kind of game is to be made from
the front end settings, and holding that information as a central resource so it can be
accessed by other game components. It would also keep track of all the nodes and ships on
the map again acting as a global resource to maintain accessibility from other components of
the game.
Sub Objective4.2 Sound Engine
There should be a section of the game engine that deals with all sound and audio based
components, it should keep a store of sounds cached in the game and should be concurrent
so that it doesn’t ‘lag out’ and cause sounds to become out of sync. It would receive
instruction from the core and other components as to when it plays a sound.
Sub Objective4.3 AnimationEngine
There should be a separate entity attached to the game engine that handles all animations
that take place within the game, again concurrency is key as the animations must not occur
out of sync. It will be addressed by components of the game and present simple animations
when ships explode and GUI components fade in and out.
Sub Objective4.4 Battle Engine
There should be a part of the game engine that is responsible for carrying out all calculations
for attacks and defences. It should also work out whether ships have or have not been
destroyed and instruct the GUI to display the relevant changes. It should also be able to
calculate outcomes of battles without actually carrying them out to provide statistical advice
to the player.
Sub Objective4.5 Objects
The game engine should also keep track of and store all the game objects currently in the
game, for example the player objects the node objects and the ship objects. The game
engine will act as the heart of the game and provide the accessibility to these objects but
insure that they don’t get overridden by other processes. This part of the game engine must
be carefully designed to insure referential integrity.
Objective 5 – The World and its Forces
This objective will be classed as met if the game itself includes some well thought out game
mechanics with plenty of player choice for different sorts of militant, a complex technology
tree to present a number of paths for the player to go down to get the player thinking more
critically of their choices. This objective can only be measured in terms of end user testing
which would occur throughout the projects development. This kind of testing is imperative to
this objective to maintain a statistical balance between a players choices in game. Each
technological tree that is chosen must equal each other to keep the game fair for all playing.

4 Background
Introduction
To properly understand the background of this project, it is necessary to establish a focus
group, i.e. a selection of similar games that can be used to draw inspiration and highlight
problems and the fall backs before the beginning of the development.
This project links its self
almostdirectly in its title to the
strategy board game of Risk
(Hasbro Inc., 1993). This
board game involves the
conquering of countries, by
roll of the dice and troop
numbers, a concept very
close to that of this project.
Risk over the years has
become available on multiple
platforms, computerized
versions of the game most
recently but all still retaining
the unique set of rules. The
first game to be put forward
into the focus group is that of
Risk II (Atari Inc., 2003) the
longest standing
computerized version of the
Risk games. Pictured in (Figs
4.1.1-4.1.2).
This project differs somewhat
from Risk however, as
instead of a predefined map
and rolling of dice,
conquering will be calculated
using electronic dice rolls
influenced by more than just
troop numbers. It is also
worth noting that the map will
be generated at random at
the start of each game,
involving planets and other
strategic objects.
Figures 4.1.1(Top), 4.1.2(Bottom)

The factors mentioned above are all more akin to another strategic risk style online game
called TribalWars (InnoGames GmbH, 2012) pictured in (Figs 4.2.3-4.2.4).
TribalWars focuses far
more on the capturing
and development of
strategic nodes to
better them in the fight
for victory, a concept
likely to be included in
the proposed project.
Whilst also using a
large set of factors to
influence the chances
of success in a
conflict, enhancing the
original dice roll. This
makes TribalWars a
good candidate for the
second game on the
focus group.
As seen above there is the element of time based development involved, the development
aspect is an interesting focus, but the game will most likely not involve the real time element
as this would be moving too far away from the original Risk game.
The idea of a slightly rectangular distorted square grid (pictured in Fig. 4.1.4) is a
possibility to mimic also as it would not add anything more complex to the geometric math’s
involved but improve the look of the map when rendered.

Finally, a game that wasn’t discovered until after the initial review of the project has arisen
and proven to be a powerful source of inspiration and ideas is Sid Meier’s Civilization V
(2KGames Inc., 2011) pictured in (Figs 4.2.5-4.2.6). This game retains the risk styled turn
based strategy whilst also including the sense of development and ‘Empire Management’
from TribalWars and overall contains a good mix of both games mentioned earlier, making it
a suitable third game for the focus group.
Civilization V has many aspects that do not convert into risk styled aspects but there is still a
heavy reliance on node development in the sense that each city is the main centre that is
used to conquer foes in the game ahead, these would become the nodes that are to be
included in this game, extracting the element of node development from this game alone will
add significant value to the end product.

Focus GroupStudy
The purpose of the focus group is to gain a better and enhanced understanding of the similar
games out there. With this information it allows the using of comparative techniques to identify
the similar qualities and factors each game shares, enabling the identification of the main
aspects of the game that must be focused upon.
Collection of Game Qualities
Pictured below in (Fig. 4.2) is a Venn diagram of the previously mentioned games for the focus
group.
Figure 4.2
The similar factors in the centre of the Venn diagram are then turned into measures which
are identified and explained below in (Fig. 4.2).
Factor Explanation
Social How social the game is, how much real person interaction is there?
Physical Time How long does it take to progress in the game to next stages?
Development How much development of units/nodes occurs in the game
Immersion How immersive is the overall game experience?
Strategic How much strategy is involved in the game?
Diplomatic How strong is the diplomatic element of the gameplay?
Typical Game Length How long does a typical medium sized game last?
Exponential Growth How much of an exponential growth to the game pace is there?
Management Complexity How complex is the management of the players ‘empire’
Chance Element How much of the gameplay outcome is simply down to chance?
Figure 4.2.1
Religious Concepts,
Cultural Concepts,
Multiple Winning Strategies,
Free Roaming Military,
AI Specific Special Units.
CivilizationV
TribalWars
Risk
II
Social,
Physical Time,
Development,
Immersion,
Strategic,
Diplomatic,
Typical Game Length,
Exponential Growth,
Management Complexity,
Chance Element.
Singular Unit Based,
PhasedTurns,
Simplistic,
Fixed World Map,
Dice rolling.
Turn Based,
AI Playable,
No City Growth Limit,
AI Personalities.
Random Maps,
“City” Development,
Research Component,
Simple Graphics,
Military operate from
Respective “cities” Only.
Played in Real Time,
In-game Mailing System,
Human Vs. Human Only,
City Growth Limit.

Building the Measure
The list of qualities are fine on their own as a way of identifying what the game needs to
include it if is indeed going to be seen as “Risk Styled”, but a better way of using the
information gathered is to develop a measure of how much of each factor the game needs to
include.
The table above (Fig. 4.2.1) has been converted into measurable factors, with this in mind,
the following structured analysis was conducted as described below:
The Developer will play each game for an allocated amount of time (5
hours).
The player at the end of each 5 hour interval will rate each factor on a
scale of 1-10.
1 = Low and 10 = High.
The experiment was conducted twice over the course of 2 weeks, the results were then
averaged out, and are displayed in the table below (Fig. 4.3):
Factors TribalWars Civilization V Risk II Average
Social 8 6 4 6.00
Physical Time 10 5 2 5.67
Development 8 9 3 6.67
Immersion 3 10 5 6.00
Strategic 9 7 4 6.67
Diplomatic 10 10 2 7.33
Typical Game Length 10 6 2 6.00
Exponential Growth 8 8 8 8.00
ManagementComplexity 7 10 3 6.67
Chance Element 4 3 9 5.33
Figure 4.3
The most important aspect of this data is the average data which has been calculated using
the mean of the 3 data sets. It identifies the areas that need to be more and less prominent in
the Orbital Whoppers Project if it is going to remain recognizable as a “risk styled” strategy
game. Another way to view this would be to look at
the percentages of the weighted average of each
factor shown below in the table to the right (Fig. 4.4).
Looking at these percentages it is first worthy to
note that all factors are quite similar in percentage,
but this is due to the fact that all of the qualities
were taken from the Venn diagram because they
were already trending qualities.
In this respect, an increment of +/- 1.5% from the
average is viewed as a decisive and meaningful
difference in data. Meaning that the need for
Diplomacy and Exponential Growth elements
outweigh the need for Chance and Physical Time.
Figure 4.4
Social 9.33%
Physical Time 8.81%
Development 10.36%
Immersion 9.33%
Strategic 10.36%
Diplomatic 11.40%
Typical Game Length 9.33%
Exponential Growth 12.44%
ManagementComplexity 10.36%
Chance Element 8.29%
Average 10.00%

The Radar graph shown below (fig. 4.5) helps visualize the individual scores of each game
and its performance in the previously mentioned factors.
Figure 4.5
The main focus, Risk II (Atari Inc., 2003) shows a strong spike towards Chance Element, this
element is always a good trait for a game to have in the respect that it allows any person
from any level of experience to still have an adequate chance at winning the game, and
although the latter two games don’t correlate with Risk II on this factor, it will be included
anyway due to said reasoning. TribalWars (InnoGames GmbH, 2012) Shows a strong
pattern in the time based factors, it being very high, whereas the study shows that amongst
the other games these factors remain much lower, this is an important discovery which will
be reflected in the project, (the discovery of a negative aspect).
The discovery that the games shouldn’t last too long and that the
need for a quick turnaround of turns was established lead to the
decision to change a core game element… changing from a ‘Phased
Turn’ to a ‘Single Turn’ system.
The initial game concept considered followed the below diagram of (fig.4.5.1) using a “Turn
Based” gameplay style, (The notion that each player takes turns simultaneously).
Figure 4.5.1
0
2
4
6
8
10
Social
Physical Time
Development
Immersion
Strategic
Diplomatic
Typical Game Length
Exponential Growth
Management Complexity
Chance Element
Focus Map of Game Aspects
Tribalwars Civilization V Risk II Average
Tactical Phase:
Setup / edit
nodes
Attack Phase:
Place attack
orders
Overview Phase:
View Enemy
Movements, View
results

However, after the initial design process, and the outcome of the research outlined above,
the core game element which is the life cycle of a turn was adjusted to be more in line with
the diagram shown below (fig 4.5.2), the main change being players take their turns
sequentially.
Figure 4.5.2
The Target Audience Rating
As the next step in the research methodology, the data that has been generated must be
filtered into categories which either complement or work against certain target audience
groups. The target audience groups that will be used in this study are shown below (Fig 4.6)
and are derived from Adams & Ip’s definitions of Gamer dedications (Adams & Ip, 2002).
Target Audience Group Description
Casual Gamer
The kind of gamer that prefers to just play games every so
often, and when playing a game it needs to have a good
element of chance, be simple and not too long.
Social Gamer
The sort of gamer that really only plays games so they can
socialize with their friends through the game medium, they
prefer games to not be complex, and have a large social
element.
Competitive Gamer
The kind of gamer that is all about winning, the scores, the
ranks and the skill. They’ll prefer games with strategy to show
off their skill, but not necessarily anything too difficult or
complex. Again a social element is important to show off their
winnings.
Enthusiastic Gamer
The sort of gamer who focuses strongly on getting into the
game, a common example being role playing, an enthusiastic
gamer wants to be immersed, and not bothered by the outside
world.
Figure 4.6

With the definitions in mind, the below table (Fig. 4.7) has been generated to ascertain which
factors of the study positively or negatively affect the target audience groups.
Factors
Casual
Gamer
Social
Gamer
Competitive
Gamer
Enthusiastic
Gamer Legend
Social     Positive 
Physical Time  - -  Negative 
Development     Neutral -
Immersion - - - 
Strategic - -  
Diplomatic -   
Typical Game Length  - - 
Exponential Growth  -  
Management
Complexity
   
Chance Element  - - 
Figure 4.7
With this data in mind, the following rating system was developed to help make more
meaningful sense of the data.
𝑇𝑎𝑟𝑔𝑒𝑡 𝐴𝑢𝑑𝑖𝑒𝑛𝑐𝑒 𝑅𝑎𝑡𝑖𝑛𝑔
= ∑ 𝑃𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝐹𝑎𝑐𝑡𝑜𝑟𝑠 𝑜𝑓 𝑡ℎ𝑒 𝑇𝑎𝑟𝑔𝑒𝑡 𝐴𝑢𝑑𝑖𝑒𝑛𝑐𝑒 − ∑ 𝑁𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝐹𝑎𝑐𝑡𝑜𝑟𝑠 𝑜𝑓 𝑡ℎ𝑒 𝑇𝑎𝑟𝑔𝑒𝑡 𝐴𝑢𝑑𝑖𝑒𝑛𝑐𝑒
This rating system would provide a final measure on how each game in the focus group
performs against each target audience. Identifying the target audience at this stage will help
in the design process when deciding which features to prioritize against the time plan.
The graph shown below (Fig. 4.8) shows how each of the games of the focus group has
performed against each target audience identified in (Fig. 4.6).
Figure 4.8
-10.00
0.00
10.00
20.00
30.00
40.00
50.00
-30 -20 -10 0 10 20 30 40 50 60 70
Average
Casual Gamer Social Gamer Competitive Gamer Enthusiastic Gamer
Risk II 11 6 12 16
Civilization V -13 17 12 56
Tribalwars -15 17 20 53
Average -5.67 13.33 14.67 41.67
Bar Chartof TargetAudience Ratings
Risk II Civilization V Tribalwars Average
Enthusiastic Gamer
Competitive Gamer
Social Gamer
Casual Gamer

The Average line is taken from the averages defined in (Fig. 4.3), which is the effective
target line that should be aimed for in the development of this project. The data quite clearly
shows that all games of the focus group are tailored heavily towards the Enthusiastic Gamer
target audience, with a negative towards the Casual Gamer discipline.
The acquisition of this final set of data is of extremely high value to the project, as it can now
be stated that the game being developed is/should be:
A Moderately competitive, moderately social non casual game, designed
for those that like to get stuck in and immersed.
Further to this, it has been established that the factor of Exponential Growth is a constant
correlation and therefore must be included and the elements of Physical Time and Typical
Game Length must be reduced.
ImplementationTechnologies
Due to the scope of the project being so large it was thought best to choose an
implementation technology that the developer was already relatively fluent at, this would
save time and thus allow for the larger scope. With this in mind, the implementation
technologies used had to fall under a primary criteria of being programmable in C#, using
Microsoft Visual Studio (Microsoft, 2015). This created 3 possible candidates shown below
(Fig. 4.9)
Implementation
Technology
Support Comments
Windows
Presentation
Foundation
(Microsoft,
2015)
Supported under
all Windows
Operating
systems
Integrated with xaml to create a hands on visual
development approach, with familiar to
html/JavaScript/xml approach to customization of
user controls
Microsoft XNA
(Microsoft,
2015)
Support issues
with Windows 8
RT and “Metro”
System
No longer being developed since January 2013 by
Microsoft, and will slowly depreciate as new
technologies emerge. Inclusion of “Game State”
objects makes differentiating between different
states of the game easy. Made for game creation.
Windows
Forms
(Microsoft,
2015)
Maintenance
mode support.
Now in Maintenance mode, only bugs will be fixed,
and no further development will occur. Although
not an immediate hindrance, it puts into question
future proofing of the development.
Figure 4.9
Support is a major issue with Microsoft XNA, as the project aims to be as future proofed as
possible, as there is little point developing something that is not going to work for very long.
XNA is built to make games with, which is a factor that must be considered against the other
two technologies. Windows Forms is a simple implementation primarily designed to be used
to create form based applications where as Windows Presentation Foundation is shown to
incorporate more than just that. With Windows Forms being put into maintenance mode, and
XNA not being supported so well on Windows 8+ platforms, it seems to be a justified reason
to pick Windows Presentation Foundation as the implementation technology to be used in
this project.

The AI Component
A section of the proposed implementation that the focus group doesn’t help with is that of the
AI creation. As stated in Section 3 Objective 1, there is to be 2 different kinds of AI
implemented into this game, at first, a simple ‘Barbarian’ AI, which has the following game
limitations:
 It cannot capture planets, thus cannot develop planets.
 It cannot be bargained with and thus is a constant aggressive AI.
Therefore its running algorithm must only comply with the simple tasks which are: -
 Move randomly about the map.
 Attack any targets on the map, prioritising ships over planets.
This above in effect makes it a relatively small AI. Furthermore the game will use values and
statistics to define mostly all the states in game, the AI system can hook into this, and use
the values in order to base its decisions. An application of fuzzy logic would seem to suffice
for this application.
Fuzzy logic is an easy to read kind of AI logic, using vague sentences to justify its end goal
and infinite ranges to define the overall bounds in question. Cox cited a conversation he had
with a mathematician on the subject of fuzzy logic:
‘If you can’t explain fuzzy logic to me in one or two sentences, then it’s probably hogwash,
and I’m not interested.’ (Cox, 1999)
This statement sums up the apparent simplicity that is fuzzy logic, in the sense that if the
reading of the logic is complex, it isn’t suitable for use. The notion of this is appealing for a
first time AI programmer as a simple AI system implementation, such as that of the
‘Barbarian’ AI needed. A summary of a basic fuzzy logic set for defining a new product price
given by Cox below:
‘If the competition.price is not very high
Then our price should be near the competition price.’ (Cox, 1999).
This demonstrates the openness of fuzzy logic, the use of vague terms in this example will
translate to varying figures in the sense of this game.
For example Scenario A: A barbarian’s ship targeting parameters:
IF BARBARIAN IS CLOSE TO PLAYER SHIP
THEN ATTACK PLAYER SHIP.
Scenario B: A barbarian’s ship chooses between targets prioritizing low health as a metric:
IF BARBARIAN IS CLOSE TO PLAYER SHIP(S)
THEN ATTACK PLAYER SHIP WHERE LIFE IS NOT VERY HIGH.
In each example the underlined text would be replaced by game statistics such as ships
current life and barbarian proximity in relation to player ships. This is the route that the AI will
go down, with further complexity being added for the city-state AI, as a city-state will have to
decide between which planets it upgrades as well as ship movements. Calling on more
complex algorithms to be applied making use of weightings.

An example below of the planetary development decision for a city state: (extract)
IF WEIGHTS.PLAYSTYLE IS AGGRESSIVE
AND AGGRESSIVE TECHTREE HAS UPGRADE AVAILABLE
THEN PICK FROM AGGRESSIVE TREE.
IF WEIGHTS.PLAYSTYLE IS NOTAGGRESSIVE
AND CITYSTATE IS UNDER ATTACK
AND AGGRESSIVE TECHTREE HAS UPGRADE AVAILABLE
THEN PICK FROM AGGRESSIVE TREE.
It is under this basis that the AI will be developed, using IF ELSE stacks to programmatically
input the logic. And the AI would hook into the player stats system and reputation systems to
reflect on which player to prioritize and indeed, which ship.
The Problemof Path Finding
In several cases it will most likely be required within the programming to implement an AI
algorithm to handle path finding, and also to use techniques to indicate which position the
player objects are currently drawn and move them about the map. In this section the relevant
mathematical techniques and algorithms will be reviewed.
Dijkstra’s Algorithm
Dijkstra’s algorithm, a path finding algorithm outlined by Dijkstra (Dijkstra, 1976) takes the
core fundamentals of path finding, (an initial position, a target position) and sets the main
metric of decision making as Cost.
What the algorithm uses is a predefined matrix of costs, associated with other factors
predefined by the development and situation. Each path has a route and thus an associated
cost with it. The algorithm looks at all costs and outputs a result.
With a world map grid in mind, this approach seems appropriate as each square would be
assigned a cost. Obstacles may be present on the map, which would present higher costs to
consider, and from this, a Dijkstra based algorithm would be most appropriate whilst
remaining relatively simple.
Further to this, this algorithm can be used for the AI as well as the game mechanics for the
player to help the AI make decisions on best routes to take to get to its target. Below in (Fig
4.10) a small sketch depicts an example of route costs using Dijkstras Algorithm.
Figure 4.10

The World Map Grid
The grid in which the nodes, ships and objects will be rendered on will by default have to be
tessellated in order to prevent any random gaps and spaces in the map, as these kinds of
gaps don’t occur in space! It’s important to explore what grid shapes can be used in this
sense, take Civilization V (2KGames Inc., 2011) for example, this game used tessellated
hexagons as outlined using a lattice by Birkeland:
𝑎 ∶= 1 𝑏 ∶= 𝑒𝑥𝑝 (𝑖 ∙
𝜋
3
) 𝐻𝑒𝑥( 𝑎, 𝑏) ≔ (0 𝑎 𝑎 + 𝑏 2 ∙ 𝑏 − 𝑎 + 2 ∙ 𝑏 𝑏 − 𝑎 0) 𝑇
(Birkeland, 1997)
This kind of math will be tricky to implement considering the small gain it would provide,
which would be 6 directions of movement rather than 4 (assuming the use of square
tessellation). A square grid is the option chosen due to its simple mathematical approach
considering the scope of the project being so large.
The square grid math’s is simpler to implement as it follows the rules as illustrated below in
(fig 4.11):
Figure 4.11
Each node would have to have a co-ordinate programmed in and ships would need to keep
track of their associated current co-ordinates. This will be the mathematical grid co-ordinate
system this project will adopt.
Summary:
This use of square tessellating grids coupled with Dijkstra’s Algorithm is the best approach to
take given its simplicity. The constant factor that’s had to be considered with this project is
the overall scope. The scope being so large producing a working implementation is
paramount. After an initial implementation, more advanced techniques could be considered,
which is allotted within the time plan which is covered later.

GUI Considerations
Before the design process of the GUI can begin, a number of disciplines need to be adopted
to ensure that no time is wasted in the project development cycle. The GUI design is a
cornerstone to the project goals and cannot be rushed, therefore it’s important to take the
time to consider relevant GUI design good practices before the design stage. For example
when designed graphic menus the principles outlined by Brown & Cunningham are of great
relevance in this project.
‘Be sure your graphic menu items are easily selectable by the system’s graphic devices’
(Brown & Cunningham, 1989)
This can be achieved using Fitts’ Law as outlined again by Brown & Cunningham:
𝐶 + 𝐾 𝑙𝑜𝑔2( 𝐷
𝑆⁄ + 0.5)
‘Where D is the distance to the items location, S is the size of the object, and C and K are
constants thus location time increases for larger movements or smaller targets; small objects
can slow down the selection process considerably.’ (Brown & Cunningham, 1989)
The primary focus from this principle is that of using large buttons, making less strings of
menu bars and making more use of ‘click to do’ functions rather than endless menu after
menu. These considerations must be taken into account when designing the UI to ensure
that a game is created that does conflict with differing platforms such as touch tablet and
desktop usage.
In Civilization V (2KGames Inc., 2011) there is actually a special launcher page which
allows the user to choose between ‘Windows 8 touch optimized’ mode and normal, the
differences between the two are purely the size and scale of the GUI buttons and objects to
make it easier for a touch experience, and this is a possible component that could be
included in this game.
Saving States
It will be necessary for the game to be able to save states so that it can be loaded back up
and continued from where the user had left off. This can most likely be achieved using an
XML (World Wide Web Consortium (W3C), 2013) approach.
The Presentation Framework (Microsoft, 2015) has built in functionality that supports the
creation, export & import of XML files, which is a contributing factor towards the choice to
implement this technology. Alongside its compatibility, XML has a high level of code
readability as well as relative ease of editing, allowing the potential manipulation of save
states to achieve loaded states that would otherwise take hours to naturally generate via
gameplay. Below in (Fig 4.12) a conceptual demonstration is shown for how this may look.
Figure 4.12

5 Technical Development
Design Process
Before the designing and construction of the project could begin, a design methodology has
to be adopted, seeing as the scope of the project is so large, it is important to pick a
methodology that accounts for this by including a quick development approach. It is also
worthy to note that there is not customer specification to be followed in this project, and thus
any methodology honed towards increases in customer interception will not be considered.
Agile Software Development
The diagram below (Fig. 5.1) shows a Agile Software Development (Sidky, 2013) approach
to this particular project.
Figure 5.1
The Agile approach incorporates a client side mechanic, but seeing as there is not customer
other than the developer, those benefits are ruled out. The ideology behind agile software
development is that of creating several functionalities and testing between each one, taking
a pause to see if it’s ready to be pushed out, and if not, move to the next phase. This quick
approach can hit on hard times when it comes to the first release, as it is almost guaranteed
to not hit the mark on any specification, or fall short of public expectations. This places a
negative morale onto the client receiving the project, and that loss of faith in the developer
can be the downfall of the budget.
However in this project there isn’t a sole reliance on a budget, and as the specification in the
aims and objectives a set to change as the project moves on, these issues shouldn’t be a
problem.

Rapid Application Development (RAD)
Below is a diagram (Fig. 5.2) which shows the Rapid Application Development Model.
Figure 5.2
The ideology of Rapid Application Development (ISTQB, 2015) is that a program should be
got to a ‘just about working’ state as quickly as possible, so the later on objects can be
considered quicker, things like the cut over phase i.e. the system handover / installation of
the new program to the existing system. Seeing as there is such a large scope for this
project, RAD is a worthy candidate as the methodology to adopt, as it encourages the quick
development of a basic program, so that the rest of the scope can then be considered on top
of this essential building block, without the need for extensive testing in what we already
know is only a preliminary program. In comparison to Agile, there is far less focus on the
specification, and far more focus on getting things done quickly, that work. But agile has the
benefit of a phased approach and each objective in the aims and objectives section could be
seen as an iteration in the respect of Agile. It is for this reason of compatibility that Agile will
be adopted as the Design Methodology.
TestDesign
The project development will be constantly tested by means of two major methods.
1. The developer upon completion of a particular task of functionality will visually test
each part of said implementation, and apply immediate fixes to the problems arisen
until such time that the function works.
2. The developer will include Unit testing to the non-visual elements of the
implementation at the end of each major iteration in accordance with the agile
scheme (for each objective met).
In the Appendix A, “Intended Tests” provides comprehensive details of each part of the
implementation that will be/was tested, although this is subject to change as the project
changes. For the most part testing has been carried out as the development has continued
with visual checks within the game to ensure that the nodes and objects are behaving as
intended, and where they are not, bug lists have been generated and addressed in the next
versions. A full readout of the Subversion history is available in Appendix I.
Quick Analysis
and Design
Build
TestRefine
Cutover
Problem?

Game Design
Over the course of the project new additions have been added and taken away, making it
quite difficult to keep track of the game rules and design. Luckily the developer saw it fit to
keep a record of the rules in an instruction manual format. The most up to date version is set
out below and discussed at length.
Nodes
A node is an object that can be captured to aid you in your conquest to win the game. Nodes
provide passive buffs which increase your base stats, along with other special bonuses
dependent on what kind of node you have. Each node allows you to launch extra fleets on
top of the standard army you hold on your home world. Each node can be configured and
upgraded using the manage section on the UI. Each node can align itself with up to 3
affinities which shape the nodes strategic use. More details on these in Appendix J.
Affinity Description
Bureaucracy Money based affinity, increases wealth output of planet considerably.
Imperialism Expansion affinity, increases movement speed and capture chance.
Industrialism Defensive / Production Affinity. Speed up production on planets.
Militarism Offensive Affinity, Provides stronger ships and harder hits.
Ecclesiasticism Religion based Affinity, adds a faith that aids your surrounding ships.
Figure 5.2.1
Node Stats
Node stats are statistical advantages that come with each node you capture. There are
several types of stat a node can come with, which either give a bonus to the respected node,
or add to your passive overall stats. All nodes will come with some base stats, these are
Sight, Initiative & Wealth. Depending on the planet type, they may come with addition bonus
stats too.
Stat Type Passive? Effect
Fleets Yes
The number of Fleets you have defines how many mobile
armies you can control at one time in one go.
Offensive
Bonus Yes
A % modifier to all your army’s offensive strength.
Defensive
Bonus Yes
A % modifier to all your army’s Defensive strength.
Sight No
A Radius around the respect node that you can spot
enemy forces.
Luck Yes A % modifier to the luck output of a battle.
Wealth Yes A % modifier to the incoming of your Nodes resources.
Criticals Yes
A % modifier that allows a chance for your units to strike
150% in the battles.
Initiative Yes
A Def/Off Buff % modifier that is applied to Fights occurring
in your Space
Production Yes The production rate per turn.
Salvagers Yes % modifier for production.
Disciplined Yes % modifier to your Wealth Production
Figure 5.2.2

Types of Node
Node Node
Type
Fleet? Spawn
Chance
Effect
Standard Yes 10%
This is a standard Node, which provides
+1 Fleet, and like other nodes, will come
with a random allocation of base stats.
Barron Yes 10%
This is a Barron Node, it will have poor
stats, but still provide +1 Fleet.
Moon Yes 10%
This is a Moon Node, will generally have
poor Sight Stat, But will provide +1 Fleet
Distorted yes 10%
Salvager’s bonus only. Otherwise
redundant
Moltenus Yes 7%
Moltenus Planets will gain Wealth
alongside high Luck.
Cosmic Yes 7%
Gas Giants are High in Wealth, and will
come with Criticals.
Frozen Yes 7%
Frozen worlds are High in Wealth and
Salvagers.
Outlaw Yes 5%
Very high Offensive High Wealth, & High
Troops very low Defence and bad luck +
costly to run.
Industrial Yes 5%
Industrial Planets gain Disciplined,
Criticals along with double Fleet.
Cultural Yes 5%
A City State will come with +1 Fleet, gain
Disciplined Stat, And will always come
very High Wealth.
Satellite No 5%
Satellites give Oversight, and comes with
a High Sight Stat.
Wreckage No 5%
Wreckages have a small Technology
Bonus, a small Salvagers bonus, But
mainly provide Luck.
Nebula No 5%
High Wealth & Initiative, Whilst costing
little to maintain.
Station Yes 5%
High Sight and Salvagers along with a
generally high offense.
Martian Yes 5%
Low Luck but high Salvagers and
moderate Wealth.
Figure 5.2.3

Special Nodes
Node Node Type Fleet? Spawn
Chance
Effect
Home
World
Yes 1/Player
This is your home world, which comes
with a high sight stat, and high wealth
and high defence.
Tech World Yes 1-4 Rarely
This is a rare planet, appearing only a
few times per match. It gives a high boost
to production and unlocks unique items.
Dawnika Yes -
This is a The capital of the Dawnikan
Empire ‘The people of the sun’. It will
have a very high focus on Imperialism.
Vespardó Yes -
This is a The capital of the Republic of
Vespardó ‘The Lenders’. It will have a
very high focus on Bureaucracy.
Últrehk yes -
This is a The capital of the Últrehk
Empire ‘The Honorable Warriors’. It will
have a very high focus on Militarism.
Maurdórne Yes -
This is a The capital of Maurdórne ‘The
Makers’. It will have a very high focus on
Industrialism.
Quel’Thalas Yes -
This is a The capital of Quel’Thalas ‘The
Home of the One True Faith’. It will have
a very high focus on Ecclesiasticism.
Node Type Description
Asteroid
An asteroid belt will hinder player movement as it gets in
the way, it will also reduce a players sight past them and
provide a defensive bonus if fighting nearby it. Like the
other objects it can be seen as a religious significance
and provide more benefits.
Black Hole
A Black Hole can be harnessed for space travel with the
right technologies unlocked... without such technology
there is a small chance that your ships get sucked into it
and destroyed. Like the other objects it can be seen as a
religious significance and provide more benefits.
Erupting
Star
An Erupting Star exerts strength and power to its
surrounding area, giving an offensive bonus if your ships
fight nearby it. Like the other objects it can be seen as a
Tempest
Storm
A Tempest can be harnessed for space travel with the
right technologies unlocked... without such technology
there is a small chance that your ships get sucked into it
and destroyed. Like the other objects it can be seen as a
Figure 5.2.4

GUI Design
The GUI design was built to match the Windows 8 platform of flat tiles, with no 3D or
shadowing effects, this allowed the fluid transition from windows 8 devices, tablets and
phones within the implementation. The GUI is designed to scale so that it maintains its
usablility. Objects are highlighted when a GUI component appears that is relevent to it, this
is to maintain the users central eye focus. The component of Fitts’ Law as explained by
Brown & Cunningham (Brown & Cunningham, 1989) has been considered in relation to
placement and complexity of menus… the menus remain simplistic, with most of the actual
functionality occuring ingame on the panels.
The design of the GUI has been made so that users can achieve the same goal in multiple
ways to make things easier. This extra layer of thought is coming from extensive testing
where the developer has tried to set up many different games over and over to identify which
parts of the GUI are frustrating and unnecessary.
In (fig. 5.4) the demonstration of
the floating panel is shown. It will
float and follow the mouse
cursor to provide information on
the particular node or object that
the mouse is hovered over. It
uses the co-ordinates math to
work out its location relative to
each node to ensure it appears
nicely connected to each node
without overlapping anything
that is meant to be in view. The
ToolTip object has been used
here also by overriding the
‘Tip.Content’ function to overlay
a StackPanel of different
coloured labels and imagery to
be layered instead of just text.
Figure 5.4

(Fig. 5.5) shows the
technology screen, which is
a per node screen that
allows the player to select
and buy upgrades for each
node based on the strategy
they choose. This panel
makes use of simple flat
panel buttons and listboxes
to make the use of it as easy
as possible. The slider is
locked to a value of 1 or 0
and is set to ‘SnapToPixel’
as originally could be half
way between states of the
coin option and the
production option, allowing
in the rare case a selection
in the middle which caused
a game crash. The
purchase button is only
enabled when the user has
got an upgrade selected to
save a whole section of
code that would have to
check whether or not
something is selected and
when the selectedindex is
unselected (-1).
Figure 5.5
Figure 5.6
For ease of understanding the whole technology system has also been visualised in the
overview (Fig 5.6) allowing players to make informed decisions on which upgrade path to
take and remind the player of what upgrades they currently have or are working toward.

(Fig. 5.7) Shows the status
of the player that they have
selected, in this instance,
the city-state of Últrehk. The
panel gives a breakdown of
the players core stats,
aswell as how much money
the player currently holds,
how many planets they hold
(which can be viewed in
more detail on the planets
tab). In addition to this, the
panel sheds light on the
players current reputation
with the selected civilisation
which is an important factor
to consider when
approaching their territory as
well as the primary metric
used in the AI algorithms to
calculate their moves
against the player. A points
system which is made up of
factors including but not
limited to player planets
owned, ships owned and
space owned is displayed in
the top left, and a detailed
breakdown can be seen by
hovering over it.
Figure 5.7
Figure 5.8
(Fig. 5.8) shows the minimap and also just underneath it the prompt system. It is there that
the game will keep you informed of whats currently going on conflict wise. Clicking a prompt
will take you to the area in question and present you with your options. The territory lines can
also be seen in this graphic which is worked out using a number of algorithms detailed later
on. Its worth noting when you hover over the minimap it’ll move itself out of the way.

System Design
Player Turn
Figure 5.6
Pictured above in (Fig. 5.6) is the use case diagram for a player turn, one of the most
important elements of the game. During a player turn, a player can manage their forces,
nodes and place mulitple orders all in real time. The players turn won’t end until they have
pressed “End Turn”, and until that moment, they may do whatever they like up to there
movement / attack limit, this concept is taken directly from Sid Meier’s Civilization V
(2KGames Inc., 2011) which is discussed in the focus group section of the Background. This
approach has been chosen to allow more than just “the plotting of attacks” to be done in a
turn, as this seemed slow, and not as immersive.
Class Overview
In Appendix B, titled “Unified Class Diagram” there is a comprehensive diagram which
shows all the control classes. The only classes left are that of the World Engine and Game
Engine classes, which will be covered later.
The class structure was originally much smaller, but there were impracticalities
involved with them, as each class was so long it became harder and harder to read each
section of code, parts of code became alien if they were older than a few days due to the
mass of text bundled onto the screen. The solution to the problem was to break things down
more logically, which also included the creation of the ‘CaptionsCollection’ class (not shown),
which contains all the long strings of information, unit descriptions, player advice etc... in the
game. This meant that there is now one unified place to look if there is a grammatical or
spelling error, rather than trawling through the code for hours on end trying to find where the
text was declared. Static structs have been used to store the majority of the descriptions and
written communication with the player making the code more readable.
Classes like the ‘Node’ object couldn’t be broken down as all the functions within
them were relevant to the node itself, however rather than handling the pop-up box that acts
as a tool tip for the node within that class too, this was broken down into its own class “Float
Panel”. Further to this the use of partial classes has allowed larger classes that cannot be
broken down into smaller classes to be seen in separate files to make the coding easier.

The world generator is the part of the implementation that is responsible for the
generation of the map to an arbitrary amount of nodes. It was key that this would be random
every time, this is outlined in Objective 2, the World Engine and Game Engine classes are
shown in Appendix B, entitled “The Core”. The World Engine conducts the requirement of
randomly generating worlds that are random every time. This has been tested by noting
down 100 generations and every single one has been different.
The Game Engine class is more of a central management class, equipped with a
toolset shown in appendix C “The Core”. It has many methods within it called “Get-X-By-Y”,
these are the toolset methods, which simply conduct information fetching tasks. These
methods combined with consistent naming conventions has improved code writing speed
and productivity. It also allows for masses of code reusability, which is a strong point at this
stage of the development.
Algorithms
The implementation includes several complex mathematical calculations and formulae as
well as a number of algorithms which are detailed below.
List<Node> GetSurroundByNode(NodeinNode,intradius);
Figure 5.8
(Fig 5.8) shows the algorithm that is behind the system that gets an arbitrary amount of
surrounding nodes from the specified node inputted. It works simply by drawing a virtual
square around the node at the maximum height and length, worked out on line 2, further to
this it works through each row in a nested for loop and selected a steadily increasing amount
of nodes from the indent defined by the radius – the iteration. Once it reaches the middle row
it’ll reverse the process. The addition of this piece of code allowed game mechanics that
needed to manipulate radiuses around the selected node for example, a ships sight relative
to itself and other nodes or a planets firing radius all come under the same algorithm.

BarbarianAttackDecision
Figure 5.9
In (Fig. 5.9) the process undertaken by a barbarian unit is displayed. This process defines
what happened when a barbarian needs to decide whether or not to attack an enemy, and
which enemy to attack if it has the choice. The circle labelled R is a barbarian refuge, the
mothership that the barbarian must defend, in this instance, the barbarian overrides the
usual choice of attacking the weakest player (a) as player (b) is closer to the barbarian
refuge it needs to protect, if this wasn’t the case it would attack the weakest ship (a), and if
no ships were present, attack the Node (N). If no targets are available it will orbit its refuge
(R).
City State Development DecisionTree
Figure 5.10.1
(Fig 5.10.1) shows the decision tree extract from a city states development choice factoring
in if they are under attack. Industrialism is the defensive strategy and Militarism is offensive.
EACH CITY STATE IS SET A ‘NORMAL’
TECH TREE TO DEVELOP IF NOTHING
INFLUENCES THEIR CHOICE. THERE IS
A CITY STATE AI PER POLICY TECH
TREE IN THE GAME TOTALLING (5),
WHICH ORDER THE CITY STATES
APPEAR IN IS RANDOM.

City State Deployment DecisionTree
For Each Planet
Owned
Get Risk
Assess Node At
Risk or Not
Get All
Ships
Owned By
CityState
Get all
Enemies
Surroundin
g Node
Deploy Warships
for Defense
Deploy Scouts
Deploy War Ships
for Offense
Low
High Medium
Get Current
Wars
Participatin
g in
Figure 5.10.2
The flow diagram above in (Fig 5.10.2) shows the decision tree implemented to decide
whether or not to deploy a ship from one of the city-states planets. The core component to
explore here is the use of a Dijkstra (Dijkstra, 1976) inspired cost algorithm to define whether
or not the planet owned by the city-state is ‘at risk’… This is further illustrated in the equation
below (Fig. 5.10.3):
𝐶𝑜𝑠𝑡
= ∑
0 + ( 𝐴𝑙𝑙 𝐶𝑖𝑡𝑦𝑆𝑡𝑎𝑡𝑒 𝑆ℎ𝑖𝑝𝑠 𝑖𝑛 𝑅𝑎𝑛𝑔𝑒 − (2 ∗ 𝐴𝑙𝑙 𝐸𝑛𝑒𝑚𝑖𝑒𝑠 𝑖𝑛 𝑅𝑎𝑛𝑔𝑒) + 𝐹𝑟𝑖𝑒𝑛𝑑𝑙𝑦𝑆ℎ𝑖𝑝𝑠 𝑖𝑛 𝑅𝑎𝑛𝑔𝑒)
𝑖𝑓 ( 𝐶𝑜𝑠𝑡 ≥ 0) 𝑟𝑒𝑡𝑢𝑟𝑛 𝐿𝑜𝑤;
𝑖𝑓 ( 𝐶𝑜𝑠𝑡 ≤ 4− && ≥ 7−) 𝑟𝑒𝑡𝑢𝑟𝑛 𝑀𝑒𝑑𝑖𝑢𝑚;
𝑒𝑙𝑠𝑒 𝑅𝑒𝑡𝑢𝑟𝑛 𝐻𝑖𝑔ℎ
Figure 5.10.3
The Cost is used not only to assign the initial risk to the node, but referred to time and time
again when calculating further choices. For example whether or not to save money in the
long run if the city-state feels threatened by the surrounding troops.
City State Attack Priority ImplementingRisk.
Below in (Fig 5.10.4) displays the priority of attack that the city-state uses to decide which
ship to engage when presented with a choice. This process too implements the planetary
risk calculation outlined above in (Fig. 5.10.3) to help a city-state ship decide whom to
attack.
Figure 5.10.4
Highest Risk
Planet
•Attack the
weakest ship by
the highest risk
planet.
'Target' Player
Ships
•Attack the player
being targeted's
weakest ship.
'Other' Player
ships or Nodes
•Attack other
players ships or
planets not
contributing to
risk.

World Engine
The world engine takes in an arbitrary amount of nodes, city states and objects and outputs
a random world, each time entirely different. There are higher and lower limiters for all
settings dependent on the players choice of world size. There is a heavy amount of
geometric mathematics involved in the generation which is briefly detailed below.
Figure 5.11
Figures (5.11-5.12) show
the process involved to
place some of the strategic
objects and city states on
the map. Note that by this
point the grid hasn’t actually
been generated, and the
whole grid is stored in a
multidimensional array of
integers ([,]). This makes
the code far more efficient
as it only has to generate
the grid once, rather than
generating it incorrectly and
needing to restructure itself.
These objects and city
states take priority over the
placement of the final nodes
as they are larger objects
and harder to geometrically
fit in without causing too
much ‘lag’ if the nodes
positions were calculated
first.
Figure 5.12

Figure 5.13
Figure 5.13 shows the final stage of the generation, after the spots shown above as orange
stripes have been removed from the generation list of possible node places. For the rest of
the nodes it is calculated where each one should go using a random number. And if a node
is attached to another node or an object, its position is reassigned. After 1000 permutations
of unsuccessful placements, the game concludes that it’s an impossible placement map, and
starts over from the top, although though testing this only happens roughly once in every 100
attempts.
Battle Engine
Figure 5.14
Above in (Fig.5.14) is a code extract from the BattleEngine.cs class outlining one part of the
calculation that is used to determine ship damage. It uses the subsequent random seed:
‘Guid.NewGuid().GetHashCode()’
This is used rather than the standard seed, the decision to use this seed has made the
randomness of the program truly arbitrary as it is reinitialized with a new seed every single
generation to improve the random output, as the goal is to not make the engine too
foreseeable.

Architecture – The Game Load
Game Engine Starts
Game
Game Loads
New game?
Loads GameEngine
Load new
Game with
user settings
Load
Previous
gamein to
engine
No Yes
Xml Save
Initializes GUI Items
Sound EngineLoad PUIs
Load
Reference
Ships
Cache
Sounds from
file
World Engine
Generates Map
Animation Engine
Game Loaded
(Fig.5.15) Shows the architecture flow diagram of the initialization of the Game Engine. The entry point is that of when the game is loaded up.
The Game Engine loads its core components as the application loads up to save load time on the actual game load. It then takes in either a
saved game or a new game configuration and passes it to the World Engine to process and generate before the game state is then loaded and
the game can begin. The sub processed “Load PUIs” loads up a suite of all the Purchase/Upgrade Items in game which are then configured
further down the chain at the Game Engine ‘Starts’ section. Once the game is loaded, it will then listen for click events from the current player.
Figure 5.15

Turn Starts
Waits for Click
Node Click Ship Click
MenuBar Click
Show FloatPanel for
Node
Wait for
FloatPanel Click
Clicked away from Floatpanel
Show FloatPanel for
Node
Wait for
FloatPanel Click
Clicked away from Floatpanel
Carry out task
Return to listener
Tab 1:
Show Information
Yes & No
Tab 2:
Show Production
Information
Tab 3:
Show Deployment
Yes
Show Node
ManagamentPanel
Manage Clicked
Yes
Owns node?
Show Overview
Panel
Overview Clicked
Deploy Ship Mode
Deploy Ship Clicked
Tab 2:
Show Owners
Information
No
Show Player
Overview of Owner
Owner ProfileClicked
Owns Ship?
Tab 1:
Show Information
Yes & No
Show Available
Moves + Buttons
Yes
Tab 2:
Show Owners
Information
No
Show Player
Overview of Owner
Owner ProfileClicked
Ship Button
Clicked
MoveClick:
Show available
moves
Attack Click: Show
available attacks
Capture Click
Show available
capture targets
Clicked Eslewhere
End Turn Click
End Turn
Checks for
available
moves
Moves still available
Figure 5.16
Ship

Architecture – The Player Turn GUI
Above (Fig.5.16) shows the main turn based logic that the Game Engine uses and listens for
whilst a player turn is in session. The key components here are the clicking of nodes. The
first check that occurs is whether or not the player owns the node that is selected, and
further to this, whether or not a ship is currently resident within said node. After establishing
this it then opens the float panel pictured in (Fig. 5.4.) and unlocks and displays the relevant
information across the relevant tabs. The user may then select further menus and options
until they either end the turn or enter a new mode. This happens in “deploy ship mode” and
on click of all ship buttons that are clicked. Each mode is passed to the Game Engine so that
it understands in what context to handle the next click. Most of the ownership checking
occurs within the ‘Node.cs’ class itself before instructing the Game Engine that it has been
clicked from which the Game Engine takes over and handles the request.
The reason for this being that the Game Engine acts as the central resource, it holds
all the relevant data within itself and doesn’t allow any other class to write to it. This means
that only the Game Engine itself can authorize a change in game state, or a change in node
ownership of ship position, making the possibility of synchronization mismatches virtually
impossible. This is further detailed further down in (Fig. 5.18.).
Focusing on the player turn GUI for now, the next core element involved is the Sight
stat, which is detailed in (Fig.5.2.2), which is calculated using the formulae detailed in
(Fig.5.8). Below shows the process that occurs when the engine draws the ships on the map
grid relative to a new ship placement. (Fig. 5.17)
Player Deploys a Ship
Extract Ships
Sight Stat
Calculate the
Surrounding
Sight
While Ships still in
sight
Is ship enemy?
Draw Ship
Yes
Game Engine
AllShips
FinishNo
Show Prompt
No
Request Sound from Engine
Figure 5.17
This highlights again the Game Engine role in controlling the data flow of nodes and ships in
the game, whilst also showing how prompts are shown when enemies are in sight.

Architecture – Game Engine Model
Game Engine
List<Ship> Active
Ships
List<Ship>
Reference Ships
List<PUItem>
AllPUIs
List<Node> Nodes
List<Player> Active
Players
List<CityStates>
CityStates
Barbarians
World Engine
List<Node> Nodes
Rendered Onscreen
List<Node>
PartNodes
List<Refuge>
Barbarian Refuges
List<AIShip>
Barbarian Ships
List<AIShip>
CityStateShips
External Class
Requesting Access
Sound Engine
Animation Engine
BattleEngine
WPF GUI
Component
Figure 5.18
The Game Engine model pictured above in (Fig. 5.18) shows how the external classes
interact with the Game Engine. As discussed briefly above the Game Engine must maintain
referential integrity, all the data passing through the Game Engine must be the same at the
time of request to different classes and functions. Therefore each class has a private
embedded pointer to the Game Engine class within them, to allow then to read the data from
the engine whenever required, but if a class wishes to modify the datasets in the Game
Engine it must call one of the public methods in the game engine to carry out the task for
them. This use of properties via getters and setters allows the whole game to stay in sync,
as well as maintain that no duplicates are accidentally created and not removed. It is this
model that has kept the development of the project far cleaner, with virtually no record of
issues relating to data integrity and data duplication, it also keeps resource usage to a
minimum, by not using threading technology at this point to further reduce chances of data
mismatching. For a networked game, which is a possible extension to the original spec in the

future, data integrity is of upmost importance, and having it controlled at this stage paves a
strong foundation to build networking functionality upon.
Architecture – Sound Engine
The Sound Engine model differs from this pattern by making use of threading, as without
such the sounds tend to overlap and interrupt each other, resulting in a poor user experience
and constant interruption of the games general immersive nature. To address this threading
is used in accordance with the diagram below (Fig. 5.19):
Sound Engine
Initial Load
New ThreadLoad Sound
Attempt to play
sound
Is sound still
playing?
If
If
No
Kill Thread
Yes
New Thread
Loop
New Sound
Request?
Yes
No
Do
Load Background
Music
Thread PoolAdd Add
Generate
Game EngineCreate
Program
Closing?
No
Kill Threads
Sound Engine
Unload
Get
Yes
Remove
Figure 5.19
Each sound effect is loaded in from file and held in the thread that is generated. That thread
is then added to the thread pool so that no threads are lost in transition. At any time the
Game Engine can call to shut down the Sound Engine on program exit at which point it will
cycle through the threads in the pool and abort them, this allows for a cleaner exit whilst
maintaining the use of threads within the Sound Engine. The loop that occurs by “is sound
still playing?” is to address the sound loading ‘lag time’ which can occur. The benefit of this
is that the Sound Engine ensures that the sound is actually heard by the player, a negative
aspect of this was found when a sound is already cached and will occasionally play itself
twice before the while loop breaks. This has been addressed with the use of
Thread.Sleep(10); to stop this bug from occurring.
A Note on Threading
Threading the Sound Engine was essential as without the threading it would not function.
This statement could not be applied anywhere else in the code, and therefore most things
that may have benefitted from threading were not threaded, as the engine design would lose
its integrity. This being said, an attempt was made to thread the ‘game load’ part of the code
as the system does pause for over 5 seconds. But after attempts were made the
development had been paused for this unaccounted task for too long, and thus was
scrapped. The system will pause for around 5 seconds, but in playing other games, a player
will always expect to see a pause when they hit the play button, so the severity of the issue
was downsized. The only implication drawn from this is the possible design of a “Loading
Screen” to be shown whilst the program loads in the background.

Architecture – Advanced Programming
The project implementation uses a number of advanced techniques which are discussed
below:
 Inheritance: - Inheritance was used with some of the classes in this project that
needed to only build on classes that already existed. The use of inheritance came
about later on the project and there is now the chance to reflect on its usage and
whether the project could have benefitted from more inheritance.
The Player class contains a number of properties, namely:
1. The Players stats in a struct.
2. The Players name.
3. The Players type.
4. The Players reputations
5. The Players game information i.e. the prefix to be used to load player
specific graphics.
6. The Players home world node.
All of the above are needed in Barbarian class but the barbarians need to
store more than just the above. So in this case the Barbarian class inherits
from the Player class, and has all of the above plus:
1. The list of barbarian Refuges.
2. The list of barbarian AIShips.
3. The barbarian difficult level.
This simple act of inheritance saves time and wasteful coding, with the use of
reusable code and not to mention the largest benefit; the fact a Barbarian can
be cast into a Player object and used in all pieces of code that require a
Player object.
 Custom User Controls: - The WPF presentation framework (Microsoft, 2015)
provides an excellent range of custom control types that allow custom GUI items
to be created and replicated throughout the game. A prime example of this is the
PUItem class. Show below in (Fig.5.20):
Figure 5.20
The areas on this control that can be changed are all the text fields and images,
meaning that hundreds of variants can be produced rather than having to
assemble a set up like this one every time. The PUItem class contains an enum
containing all the possible variants and has setup information for each one,
making the constructor declaration relatively simple. The whole class hooks into
the global resource dictionary to allow a global configuration set to apply itself
over the user control objects to save time in the programming of stylesheets
within each class. All PUItems and their associated descriptions are detailed in
Appendix J.

Architecture – XAML & XML
The Presentation Foundation (Microsoft, 2015) uses XAML (Microsoft, 2015) to graphically
design user controls as well as dynamically edit them whilst the code is running. It is
important to note however that it isn’t actually the XAML doing the work in the background.
On compile, the program translates all of the XAML into C#, using automatically generated
files.
XAML is extremely powerful in this way as it is truly a visual programming paradigm, every
property edited in Visual Studio can be easily read and reviewed on the graphical layout
designer. This makes the programming of the GUI much easier to keep track of, which
further compliments the original choice to implement a WPF solution.
The screenshot below in (Fig. 5.21) shows an example of XAML in action, the <GRID> tag
defines the area with the black background, and each control present within it is contained
there. Most of the controls make the use of the ‘x:Name’ property which assigns the control a
name that can be hooked from the C# interaction logic. This method is used throughout the
project to allow dynamically changing objects and visual within the project.
Figure 5.21
As discussed in the background section, XML (World Wide Web Consortium (W3C), 2013)
was chosen to save the game state, this was implemented using the XMLWriter &
XMLReader libraries build into the .NET framework. Fortunately the inclusion of XAML in
WPF meant that by the time the development process reached the stage that the save game
state and XML generation logic was needed, the developer was knowledgeable in the syntax
of XML due to the similarities between XML and XAML. A snapshot of the raw save file is
showcased below in (Fig 5.22), the similarities are immediately apparent.
Figure 5.22

6 Evaluation
The Journey
From start to finish, the project has undergone the tests of time. Time was the one resource
that could not be bent or extended, so it was held in the highest regard. In the initial weeks
that followed the initial report SubVersion was set up as source control and a means of
backup in order to comply with the risk of data loss, a full printout of the subversion of the
course of the project is available in Appendix I.
The project started off as a research mission, to ascertain which technologies to use, but it
was decided early on that WPF was the key contender, due to reasoning outlined in Section
4. But to reiterate, the developer had more experience in WPF (C#) and it was the most
supported of all .NET options.
The task ahead identified quite quickly that the time plan and task list were not at all in the
right order. The logical step was to delve into some experimental coding which brought
about the creation of the Node class. A simple WPF custom control that held and Image
object, from which when you declared a new node object, you could pass in an enum
parameter or the kind of node you’d like displayed:
Node TestNode = new Node (int scale, point position, Node_Types Type);
It quickly became apparent that a container class was needed to construct the nodes and
order them, thus the World Engine Class, (originally scheduled to be produced half way
down the development plan) was constructed. This started with the creating of the
placement algorithm. Which worked using the following pseudo representation:
𝐷𝑜 {
𝐼𝑓 (
𝑖
𝐶𝑜𝑙𝑢𝑚𝑛𝑠⁄
𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑟𝑜𝑤
== 0) { 𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑟𝑜𝑤++
}
𝑁𝑜𝑑𝑒 𝑛 = 𝑛𝑒𝑤 𝑛𝑜𝑑𝑒 ( 𝑝𝑜𝑖𝑛𝑡(0|0) + 𝑝𝑜𝑖𝑛𝑡(𝑖| 𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑟𝑜𝑤))
} 𝑊ℎ𝑖𝑙𝑒 ( 𝑖 < ( 𝑅𝑜𝑤𝑠 ∗ 𝐶𝑜𝑙𝑢𝑚𝑛𝑠))
As new parts of the game were implemented, the more complex the World Engine algorithm
became, taking into account more and more factors… City State positions, tech worlds and
object placement to name a few.
As the development went on the simple rendering of maps became obsolete without
the notion of ownership and players. So the player classes were developed and each node
was assigned an “Owner” field. This presented issues as leaving unowned planets as null
caused Null Exceptions, so quite quickly the idea of the game owning planets as well as the
players was introduced and controlled using a ‘neutral’ class. Shortly after the introduction of
players, the Game Engine was built to stop so much of the games operation occurring in the
MainWindow.xaml.cs class which was meant purely for interaction logic for the main window.
This move was in comparison to leaving core game logic in the MainWindow.xaml.cs class
and risking the introduction of threading later on causing graphical errors.
The next development came as a huge game re-write occurred to account for ships,
as nodes needed not just an owner object but an occupier object as well. Further to this
when AIShips were introduced and needed further properties on top of the ship class, the
first use of inheritance was used, which was a learning experience on its own due to the
blind spot of knowledge in this area. This also presented issues with casting the generic Ship

to an AIShip, outputting further errors. This marked the end of the building process and the
beginning of the content phase.
Time ManagementRecognitions
WPF Resource Dictionary
The GUI was developed using WPF custom controls and a central resource dictionary that
all the WPF classes drew there stylesheets from. This made the proccess of development
far quicker as less time was spent on the visual design due to the connected resource
dictionary so more time allocation was available for the coding and implementation of
different UI panels.
A prime example in this field is the fact that a optional UI component ‘the overview
panel’ which is detailed above in Section 5, Fig.5.6. was set to not be developed due to time
constraints but thanks to the quick visual design aspect it was enabled and included in this
project rather than being left on the back burner for future development.
‘ToolSet’ Class design
As mentioned earlier in the report the inclusion of a toolset class library in the project allowed
the development of components that needed complex calculations to be sped up by keeping
all the calculations accessible in one central class. This allowed for more ambitious coding
as the methods available to help calculate different states and possibilities were all there
ready to be used. Not to mention the benefit of havening maximum code reusability.
Time Plan Review
In Appendix D the original task list can be viewed, and the visualization of that task list is
shown in Appendix E. This time plan was the theoretical time plan that was developed with
minimal prior research conducted, and it clearly shows now, after a review how inaccurate it
was.
The timings are on target, but the list of tasks and what order that they’d be approached in
was wrong. A prime example of this is the order in which the time plan suggested to produce
the implementation, and what turned out to actually be programmatically feasible. The First
part of the implementation that made sense to create first actually turned out to be the World
Engine, as without seeing the world, visually commenting on the aesthetics of the game
being produced proved very hard. Also, the Node class being created first came hand in
hand with the World Engine, and immediately gave the development the vital push in the
right direction that it needed, as these were the most visually prominent parts of the game.
In Appendices F & G the new task list and time plan are shown, all alterations are shown in
red, and any old text that’s been removed is struck through, further to this, in Appendix F, the
completed tasks are shown in green, and the current tasks being attempted are shown in
gold.
According to both the old and new time plan, the project is a week or so ahead of schedule,
and this is mostly due to the drastic changes to the original time plan, as on the original time
plan “Build the shell” which was meant to last 28 days, was a null task and scrapped.
Allowing 28 days to go back into the pool to be reallocated.
The World Engine took far longer than 2 weeks due to the masses of problems experienced
with the resolution support, the view of the project developer is to keep as many compatibility
doors open as possible, and this problem involving the game not rendering correctly on
anything below the resolution of 1080p caused a huge fall back, taking another 14 days to
solve, by taking into account the resolution of the users screen before any calculations

occur. This is a huge learning point for the development, as not ensuring that all known
variables were covered before the creation of code caused a 14 day delay.
Legal disputes
The project was further slowed later on down the line by an issue involving the legality
behind some sourced imagery used within the game. 4 Images that had been mistakenly
taken under the premise that they were free to use were flagged up later on when the
developer started building an asset register of all items that he himself didn’t own. They were
actually not available for free use which lead to the developer contacting the artistic owner of
the images to ask for his permission over usage. In Appendix H there is included the E-Mail
trail that was sent between the artist and the developer along with the license agreement
that has now been drawn up between them. This experience has lead the developer to lead
a more careful approach when it comes to asset selection on the internet as it can be so
easily misrepresented as free to use when the images are indeed not. Creation of an asset
register is now one of the first things that the developer of this project will do before the
addition of images to their projects. Thankfully in this case, the artist was very understanding
and no legal claims were made.
Other Issues Encountered:
The project has encountered several time hindering issues that are worthy to note for any
future developments of a similar style they are as follows…
 The WPF built in sound libraries are extremely limited. They wouldn’t allow a sound
to be played over another, thus implying that if you were to have background music,
every sound effect you played would interrupt said background music. This comes
down to the fact that WPF wasn’t designed intentionally to be a game building
technology, its worthy to bear this in mind when you consider developing a game in
C#. There was a fix however, the simple importing of the XNA.Framework.xact
libraries allow the use of the far more diverse XNA sound effect classes.
This too though wasn’t without problem as the sounds tended to overlap each
other and interrupt each other even though the XACT library claims to use
asynchronous methods when calling the Sound.Play() functions. A fix for this was to
manually thread the entire sound engine class in this game, but taking note to kill off
any threads still going when the game closes as to not cause errors on shutdown.
 As mentioned above, the resolution support is an essential part of a visual program
and indeed a game. Not considering this core component in the early stages of
development cost this developer a lot. The game never truly become 100%
compatible with all resolutions due to the compatibility being added so far down the
line, things still seem a little off centre and misaligned when not viewing in an optimal
resolution. Paying more attention to the mathematics of point positioning relative to a
standard rectangle size at the very beginning would have been key to avoid all these
troubles.
 Design of the visual classes is paramount, a faulty class system effected the
development of this game in the early stages due to the bad design, meaning that
some visual elements quite easily got mismatched and uncategorized, allowing visual
anomalies to occur such as grid squares remaining highlighted even though the user
has clicked away from said square. To remedy the problem a core re-write had to
occur costing a good week of development elsewhere. Although the developer won’t
deny that the re-write provided time to install better systems to allow for the pending
updates, it still cost more time than it was worth overall to get the system working and
visualizing the game state without irregularities.
 Casting inherited objects from their base form presented errors when a base class
object wasn’t an extended class. The work around for this was to use the ‘as’
operator to attempt a conversion and then use a null checker to see if it indeed can
be converted or not. e.g.

Ship PotentialAI = Engine.GetShip();
Object PotentialObj = PotentialAI as AIShip;
If (PotentialObj != null) { //DO STUFF }
Risk Review
The project has undergone a large change in risks, namely the original risk assessment
covered only the basics of data loss, developer illness & external time constraints, which are
all still risks and being covered using the appropriate measures, specifically, the extra two
weeks at the end of the plan to account for illnesses and time constraints, the use of SVN for
data loss and the installed mirroring RAID utility on the developer machine.
However two new internal risks have occurred which must be noted below (Fig. 6.1):
Risk Severity
(L/M/H)
How to Avoid How to Combat
Too much
data to “save”
game
M Use Shared
resources, code
reusability
Reduce data being stored by use of
serialization.
Game
Performance
Issues
M Set a threshold and
constantly track and
monitor CPU usage.
If Threshold is broken, make use of
profiling tools to ascertain which part
of the code is causing the problem.
Figure 6.1
ProjectAchievements
There can be no denying the fact that at the beginning of this project there was always the
underlying doubt of whether it would be complete finished by the end due to the large scope
of the project and the amount of research involved in order to successfully establish a fully-
fledged game. That being said the development process has been efficient and constantly
ongoing, sticking carefully to the time plan and through perseverance alone, the project is
practically perfect. The highlights are as follows:
 The game runs on multiple resolutions, and uses random generation to create some
truly unique maps. (Objective 2).
 The game contains a truly diverse set of upgrades ships and nodes, all differing in
statistical advantages and disadvantages, giving the player a real sense of strategy
by having to make so many decisions that affect the gameplay (Objective 5).
 The Game Engine is at the heart of the game, which controls all the major game
traffic, controls sound, animation, storage of objects and player statuses (Objective 4)
 The GUI contains a vast array of easy to use and aesthetically pleasing user
interfaces including overview panels and tool tips. (Objective 3).
Ongoing Work
The project has fallen short of one target however, the AI component still lacks its full
potential, the initial report speculated a fully robust AI player to play against, but due to the
technical difficulties found in developing complex AI algorithms, as well as the scope of the
project stretching the development time thin and not to mention the unforeseen issues that
slowed down the production, the AI was redesigned into a smaller less integral part of the
project which is outlined as the first objective in this report in section 3. Although the
developer was not able to overcome the hurdles of AI development, a smaller more concise
AI component has been completed and installed which allows the status of partially

completed to be applied to Objective 1. With a view to continue the implementation in the
future to see the AI players fully installed.
Future Work
The game works, which is the main aim. But that does not lead to say that the game is
complete. There are several planned extensions to the game that will continue being
developed way into the next year. Some of the main parts art detailed below:
 Network Play: - an aspect of the game that will be considered for future work is
network play, so that two human players may play over a local network
connection (LAN). The .NET framework contains lots of support for TCP
connections and networking, which would be utilized for this. The game would
load the map, and then send the map data to each player’s client and from then,
send updates ad changes to each player from the host machine via a unique
protocol. The protocol would most likely use byte streams to create special
packets. A concept is shown below in (Fig.6.2):
#
0 Type 0-255 An 8 bit byte indicating what kind of information
the packet holds.
1 Length MSB A 16 bit byte indicating the length of the packet,
giving a maximum length of 65535.2 Length LSB
3
Payload
The Payload of information relative to the packet
type for the client or host to carry out.
4
5
6+
Figure 6.2
 Quests/Missions: - The board game and indeed computerized version of Risk
(Atari Inc., 2003) contain a Mission element where you must carry out a task
whilst you play to further your goals. This is further replicated in Civilization V
(2KGames Inc., 2011) & TribalWars (InnoGames GmbH, 2012) with their
components of quests that must be completed to earn yourself free resources.
This element was conceptually thought about, but deemed not important enough
to implement into the final game, but there was thought and process that went
into them as shown in this example flow diagram: (Fig. 6.3)

The Mission would be got on a random chance every time a player captured a
node. This mimics the collection of a “Risk Card” in both the computerized and
original board game. Which functioned in the same manner as described above,
although the chance element is new due to the output of the focus group.
Player
Captures a
Node
% Chance of getting a
Mission
Player
completes
mission
(gets reward)
Figure 6.3

Dissertation_Final_Report

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Dissertation_Final_Report

Similar to Dissertation_Final_Report (20)

Dissertation_Final_Report