1 Contents
2
Introduction.................................................................................................................................. 5
2.1
3
Research ....................................................................................................................................... 7
3.1
4
5
Contents of the report ........................................................................................................... 6
State of the Art....................................................................................................................... 7
3.1.1
Three-faction games .......................................................................................................... 7
3.1.2
Asymmetric Games ........................................................................................................ 8
3.1.3
Triangularity in Games .................................................................................................. 9
3.2
Final Problem Statement ..................................................................................................... 11
3.3
Target group ......................................................................................................................... 11
Analysis ....................................................................................................................................... 12
4.1
Cooperation and competition ............................................................................................. 12
4.2
Game theory ........................................................................................................................ 13
4.3
Metrics ................................................................................................................................. 16
4.4
A discussion of Balance ....................................................................................................... 18
4.4.1
Balancing the game ...................................................................................................... 18
4.4.2
Play-testing .................................................................................................................. 21
Design ......................................................................................................................................... 23
5.1
Product requirements ......................................................................................................... 23
5.2
Game Design ....................................................................................................................... 23
5.2.1
5.3
Setting .......................................................................................................................... 23
Mechanics............................................................................................................................ 25
5.3.1
Differences from Staghunt ........................................................................................... 25
5.3.2
Principles of the Stag-hunt .......................................................................................... 25
5.3.3
Death-Cap .................................................................................................................... 26
5.3.4
Amplify ......................................................................................................................... 26
5.3.5
Other issues.................................................................................................................. 26
Page 1 of 55
6
Implementation .......................................................................................................................... 28
6.1
Introduction: ....................................................................................................................... 28
6.1.1
General overview ............................................................................................................. 28
6.1.2
The master server......................................................................................................... 29
6.2
Gameplay .............................................................................................................................30
6.3
Human................................................................................................................................. 31
6.3.1
MANGLER NOGET HER............................................................................................. 31
6.3.2
Raptor .......................................................................................................................... 31
6.4
Pack raptor AI ..................................................................................................................... 32
6.5
The Metric System............................................................................................................... 35
6.6
Client overview .................................................................................................................... 36
6.7
Modelling for Games ........................................................................................................... 37
6.7.1
Requirements ............................................................................................................... 38
6.7.2
Playable Characters: .................................................................................................... 38
6.7.3
Animations:.................................................................................................................. 39
6.7.4
Environment: ............................................................................................................... 39
6.7.5
Tricks and techniques .................................................................................................. 39
6.7.6
Colour Mapping ...........................................................................................................40
6.7.7
Normal Mapping ..........................................................................................................40
6.7.8
Transparency Mapping ................................................................................................ 41
6.7.9
Inverse Kinematics ...................................................................................................... 41
6.7.10
Walkthrough ................................................................................................................ 41
6.7.11
Importing to Unity ....................................................................................................... 44
6.8
Internal Testing ................................................................................................................... 44
6.8.1
Introduction ................................................................................................................. 44
6.8.2
Types of Tests ............................................................................................................... 45
6.8.3
Concurrent Testing ...................................................................................................... 45
6.8.4
Final Evaluation ........................................................................................................... 45
Page 2 of 55
6.9
Lessons learned from Testing ............................................................................................. 46
6.9.1
7
Chapter Summary ........................................................................................................ 46
Testing ........................................................................................................................................ 47
7.1
Balance test ......................................................................................................................... 47
7.2
Product test ......................................................................................................................... 47
7.3
Results ................................................................................................................................. 48
8
Discussion ................................................................................................................................... 52
9
Conclusion .................................................................................................................................. 53
10 Bibliography ............................................................................................................................... 54
Page 3 of 55
Figure 3.1 - Characters from Guild Wars 2 (Forbes 2012) .................................................................. 7
Figure 3.2 – The Kabuto from Giants: Citizen Kabuto. (macgamezone u.d.) ..................................... 8
Figure 3.3 – The concept of Triangularity (Schell 2008) .................................................................... 9
Figure 4.1 – the Prisoner’s Dilemma (Varian 2002) ......................................................................... 14
Figure 5.1 – concept art of the game-arena. ...................................................................................... 27
Figure 6.1 The general overview of the game component interactions ............................................. 28
Figure 6.2 – the Master Server ..........................................................................................................30
Figure 6.3 – Human UML diagram ................................................................................................... 31
Figure 6.4 – Raptor UML diagram .................................................................................................... 32
Figure 6.5 - Separation ...................................................................................................................... 33
Figure 6.6 - Cohesion ......................................................................................................................... 33
Figure 6.7 - Avoidance ....................................................................................................................... 34
Figure 6.8 - Alignment ....................................................................................................................... 34
Figure 6.9 – Sequence Diagram......................................................................................................... 36
Figure 6.10 – Sequence Diagram 2 .................................................................................................... 37
Figure 6.11 – UV map of the Tyrannosaurus ..................................................................................... 42
Figure 6.12 – Color map of the Tyrannosaurus ................................................................................. 42
Figure 6.13 Hi- and low-poly versions of the raptor .......................................................................... 43
Figure 6.14 – Joint Hierarchy for the hunter .................................................................................... 43
Figure 6.15 – Hunter skeleton and controls ...................................................................................... 44
Figure 7.1 – Qualitative game 1 .......................................................................................................... 48
Figure 7.2 - Qualitative game 2 .......................................................................................................... 49
Figure 7.3 - Qualitative game 3 .......................................................................................................... 50
Page 4 of 55
2 Introduction
Dinosaurs!
That’s in some way what this report is about. In other more important ways, it is about gamedesign, game-theory, and part of the human psyche.
We love games. We love playing them, thinking about them, talking about them, so in that sense
there was never much doubt about what this project would be about. Having acquired the skills
necessary for this undertaking, we set out to create a game - but which kind of game? And how?
Very early on we were inspired by what we called “three-faction games”. By this is meant games
which include three rivaling factions, fighting against each other at the same time. These kinds of
games produce a very interesting, asymmetric scenario, and one which modern game designers in
increasing degree are acknowledging1. Player’s suddenly have a choice of whom to attack, and the
effect of this on different aspects of the game is what brings innovation to the game type- and idea.
If you think about it, this is not present in as many games as you might think – look at Chess,
Football, Counter-Strike and so forth – the vast majority of games are “pitched battles”, in the
sense that it is just you – and your opponent.
Three-faction gaming, on the other hand, is a tactically different matter – you no longer have to
just decide when to attack, or with which units, but also whom you send them against. This choice
might seem arbitrary, but consider the following scenario: You are battling two enemies, one of
which is powerful, the other which is not. If you attack the weaker of the two, then you might wipe
him out – which might seem like a good thing as you can now turn your hungry attentions to the
remaining enemy, yet when you pause to consider the fact that the scenario has now changed to
being just you against a powerful opponent, you might just have upset a precarious balance.
Let us consider the alternative scenario – you attack the stronger player instead, and perhaps
weaken him a bit. There is no guarantee that the player you just ‘spared’ is as tactically soundthinking as you, yet if he too considers the scenario above, he might reach the same conclusion. Of
course, you might just both get pummeled into the ground by your stronger adversary, but that’s a
calculated risk.
1
The upcoming game Guild Wars 2 sometimes involves three factions – see State of the Art chapter for more details
Page 5 of 55
Some of this might seem a stretch, but several games have actually used this very mechanic as a
sort of player-driven balancing of the game2 - if a faction gets too powerful, the two weaker factions
will generally gang up to even the odds out a bit (Ferguson 2012) – but only for as long as the
balance is unsettled.
A game which inspired us a great deal is the game Giants: Citizen Kabuto. In the multiplayer part of
this game, three-factions are present, one of which is Kabuto himself – a titanic beast that grows in
size and power as he feeds. This idea, of one faction being purposefully more powerful than the
others was very inspirational, and this, coupled with the asymmetric three-faction gaming, seemed
to provide a very diverse and interesting and unorthodox kind of gameplay, and it were these
aspects which in the end would provide the basis for this project.
The main focus will be laid on the aspect of choices between opponents, and how this comes to
fruition in what is essentially an unbalanced game, the impacts this will have on the experience of
the players, and the overall quality of the game that we have created from scratch.
2.1 Contents of the report
This report follows a mainly chronological outline that will seek to show the project’s evolution
from initial idea and inception, through the different research phases and the construction of the
design, to the tested and analyzed final game-product.
The course of this report will cover the following chapters:
A further introduction to three-faction- and asymmetric games in the Research chapter. This will
provide the base information for further development of the project-idea.
An Analysis which seeks to discover how best to create the planned game. The analysis will detail
how best to balance an asymmetric game, then investigate the subject of Mathematical Game
Theory which is used to describe ‘player’ behavior depending on outcome, and finally research the
subject of Metrics, which will help determine the results of the final product-test.
The Design and Implementation, which build upon the Analysis to create the game. The design
will explain the thoughts behind the game itself, and the implementation will detail how the game
was made, with focus on graphics, Artificial Intelligence and the connection between computers in
a multiplayer game.
2
See State of the Art, subsection ”Asymmetric Games”.
Page 6 of 55
The Test and the subsequent discussion and conclusion of results gathered. These will determine
to which degree the project can be deemed a success.
3 Research
This chapter will seek to perform extensive research into three-faction and asymmetric game
examples, providing a foundation for the upcoming analysis phase while constituting one of the
main inspiration parts for the design of the game.
3.1 State of the Art
The state of the art section will look at already existing three-faction- and asymmetric-games, and
analyze these and their method of creation to search for special characteristics or theories which
could prove helpful in creating the product.
3.1.1
Three-faction games
Many games have the option for three (or more)-faction gaming, but seem rarely designed with
that in mind; popular strategy-games, like Starcraft or Warcraft, or a First Person Shooter like
Modern Warfare 2, all of these have the option of ‘free-for-all’, that is, pitting everyone against
everyone.
Games that are purposefully designed for this special case, however, are rarer. Two games which
prominently features this scenario, are Dark Age of Camelot and the upcoming Guild Wars 2.
Dark Age of Camelot (DAoC) is a well-reviewed Massive Multiplayer Online game developed my
Mythic Entertainment, released in 2001. The game features three factions, and a unique (at the
time) game-style called Realm vs. Realm, in which the three realms would battle each other. If one
realm got too powerful at some point, the other realms would ‘gang up’ and cooperate to bring that
realm down a bit, functioning essentially as player-driven balancing system based in the Player vs.
Player aspect of the game (Schober 2012) (Zissu 2011).
The upcoming MMO Guild Wars 2, in development
by ArenaNet, features the same game-style and
principle; three large factions fighting against each
other at the same time. This functionality was
included in particular for the balancing issues and
the plethora of choices this way of playing presents
the player. A system designer on the game, Mike
Ferguson, explicitly states that this form of
Figure 3.1 - Characters from Guild Wars 2
(Forbes 2012)
Page 7 of 55
balancing cannot be present with only 2 factions (Ferguson 2012).
What should be noted though is that the scenarios described in these games take a long time –
indeed, in Guild Wars 2 the large battles are scheduled to take 2 weeks, meaning that factions will
have ample time to plan and discuss their approach. In addition, the players have available to them
easily accessible and understandable information regarding the state of the game - which faction is
in the lead and so forth, and this undoubtedly influences their decisions. Therefore, it is unknown
whether this player-driven balance effect will occur in shorter games, or games apart from MMO’s.
3.1.2 Asymmetric Games
Symmetric
Asymmetric
<------------------------------------->
Same starting options
Diverse Starting options
(Sirlin, 2008)
An asymmetric game can be defined as one in which the players start with a different set of options
– so in essence, any game wherein your player-controlled force in some way is different to your
opponents. This also means that a strategy-game like Starcraft 2, which features three separate and
unique races, can be asymmetric, as long as the two battling races are not the same. Asymmetric
games can often be interesting and thought-provoking for the players, because it is not always
obvious what the correct tactic or strategy is. Players can also become curious about whether the
different factions are indeed balanced, and will often spend a lot of time trying to decide this
through developing evermore complex and innovative strategies (Schell 2008).
“I can say with confidence that the farther to the right on that scale your game goes, the more
difficult balancing your game will be.” (Burgun 2011)
As mentioned in the introduction, this project was
largely inspired by the game Giants: Citizen
Kabuto. Three different races are playable in the
single-player campaign of this game, with all three
also being playable in the multiplayer part. What was
particularly interesting about this aspect was that the
Figure 3.2 – The Kabuto from Giants:
Citizen Kabuto. (macgamezone u.d.)
Page 8 of 55
Kabuto (see pic) was often alone against several of the other races – something only possible due to
his inherent strength. In addition, when feeding, Kabuto would grow both larger and stronger –
almost as if the developers wanted the other teams to notice him.
Another example of an asymmetric action game is Alien versus Predator, where three races are
also playable – the humans, the Predators and the Aliens. In the multiplayer part of this game, it is
apparently generally accepted and recognized that the Alien is at a significant disadvantage when
facing a Predator, yet this is not considered unfair, as it is in keeping with the Alien vs. Predator
world (Schell 2008). Players instead take it as a badge of pride when they actually manage to win
the game when playing as an Alien and this player-acceptance of imbalance because of underlying
reasons is highly interesting.
3.1.3 Triangularity in Games
“One of the most exciting and interesting choices for a player to make is whether to play it safe,
and go for a small reward, or take a big risk, to try for a big reward.” (Schell 2008)
This situation, which Schell calls Triangularity, seems present in many of the situations
mentioned above – if an Alien in Alien vs. Predator, you can take a big risk by trying to defeat the
Predator, but if you win you know you have done well due to the imbalance between these two, and
this can be seen as a type of reward too (Schell 2008). In Citizen Kabuto, you run a big risk by
trying to defeat him, yet if you succeed you are rewarded by the Kabuto respawning at his
Figure 3.3 – The concept of Triangularity (Schell
2008)
Page 9 of 55
minimum size, thereby becoming a smaller threat for the next few minutes, a direct gameplay
reward.
An example used by Mr. Schell himself is the game Space Invaders – this game features
Triangularity in the way that everyone once in a while a small red flying saucer flies across the
screen – this target grants much more points than the standard enemies, yet trying for these points
is also a big risk – the target is far away, and requires you to take your eyes off your own vessel in
order to aim, increasing the risk of failing to accurately spot and predict where bombs will land,
thereby endangering yourself for the chance at extra points.
Triangularity fits well with the thoughts and ideas on the project-game – one faction will be
stronger than the other, and they can choose to hunt this quarry for a larger sense of Risk vs.
Reward, or they can hunt the easier prey, but get fewer points.
In this section, the following has been discussed:




Balancing an asymmetric game is more difficult than balancing a symmetric one.
With enough incentive and knowledge of current situations, warring players will in certain
scenarios cooperate to bring down a stronger adversary, something sometimes known as
co-opetition (from cooperative-competition).
Players can in some situations accept imbalance for reasons related to story or lore.
Triangularity provides an interesting set of choice for the player.
To detail the aspect of risk vs. reward, later sections will research the subject of mathematical
game-theory to describe and detail the choices presented to the players in the game. Furthermore,
a section devoted to the subject of game-balance will be created, to ensure the game functions and
feels as desired.
With some basic knowledge about the ideas and motivations of the group gathered, a final problem
statement, which will function as a guideline for the work-efforts of the rest of the project-period,
can be crafted.
Page 10 of 55
3.2 Final Problem Statement
In an asymmetric three-faction game, to which extent will two warring factions cooperate to defeat
a stronger faction if it is to their mutual benefit, and under which circumstances does this
cooperation occur?
3.3 Target group
The main project aspects revolve around three faction- and asymmetric games, which means that
the only requirements from the test participants are that they have some experience with games.
The idea of distributing the game on various game-related forums online has been established. This
means that the test can be two-pronged; a quantitative test, which will receive its data from the
test-persons recruited through the internet, and a qualitative test conducted with interviews and
questioning. The reasoning for dividing the test this way is to both hopefully get a large amount
empirical data through the quantitative test, as well as a bit ‘deeper’ data through the qualitative.
For the online test, it was decided not to focus on demographics too much when choosing forums
for distribution; the game will likely be linked to on such sites as Reddit and Facebook.
A Demographics test was performed on Reddit in 2011, which stated that 86.7% of users are male
while 13.3% are females, the average age being 24 years old. Also there have been indicators that
the majority are either involved in a bachelor education program, or has a bachelor degree.
(Jenakalif 2011)
Page 11 of 55
4 Analysis
The analysis will research such subjects as mathematical game-theory, cooperation and
competition in games, how to balance a game properly and lastly, how to gather data by using
metrics.
The sections mentioned will provide the necessary knowledge needed for creating the game.
4.1 Cooperation and competition
The base idea of the project is based around the idea that three people who are competing for the
highest score in a game, will sometimes choose to cooperate with another player, at least
temporarily, because there is a perceived benefit from it.
There are two sides to the coin here. There is cooperation from a mathematical game theory
point of view, and from a game design point of view. It is relatively important to keep both in
mind, firstly in relation to mathematical game theory because this seeks to explain what people
should, or rather could, do to receive the greatest payout (Varian 2002). Secondly, actual game
design decides the options and limitations of the product (Salen 2004). The mixture of these two is
the frame for cooperation and competition.
From a mathematical game theory point of view, there are two situations: The first could be zero
sum games, where one player winning means the other is losing: whenever a player gains
something, the opponent loses that same amount (Varian 2002), forming the idea that only one
player can receive a positive outcome at any given time. The second case could be the
coordination game, where coordinating choices can give positive outcomes of the same or
different levels to both competing factions (Varian 2002).
In terms of game design (non-mathematical) there is not a specific term for it, however Salen and
Zimmerman (Salen 2004) explains that there is always competition and cooperation in games on a
systemic level (Salen 2004). Competition always exists, but player cooperation is not possible in all
games (Salen 2004). An example they mention that has both of these aspects is the game “Joust”. It
is a game wherein two players can attack monsters to increase their score, while at the same time
having the possibility of attacking each other. This allows the players to completely cooperate to
increase both players’ score, while also allowing the players to create a zero-sum game situation by
attacking each other. Lastly, players can attack each other tactically to deprive the other player of
earning points, thereby gaining a score advantage.
Page 12 of 55
The authors explain this game as creating a constant tension within the game environment, even if
the players are not actively trying to kill each other, simply due to the possibilities mentioned above
(Salen 2004).
In the area of three-faction cooperation, this area has not performed much analysis. However, one
paper “Olson vs. Course: coalitional worth in conflict” (Esteban 2002) which revolves around the
use of alliances in economics with focus on three factions involved, uses mathematical game
theory:
“… we analyze a contest (that is, a conflict where the players only value their favourite outcome)
for any possible distribution of the size/strength of the individuals. We find that sequencing will
never occur. Next, – for equal distribution of power – we show that no matter how much players
value each other’s favourite options, unless they completely agree sequencing does not occur in
equilibrium. “ (Esteban 2002)
This states that, at least in economics, if there is an equal distribution of power – “sequencing” will
never occur. Sequencing is when, after two teams have formed a temporary alliance, and after that
alliance has achieved its goal, the two teams will disperse and fight internally after. This means that
in a three faction situation with equal power, alliances will only last temporarily – however, it does
not state what would happen if power was unequally distributed.
Finally, a study has been made on the effect of symmetry and asymmetry when it comes to the
“Prisoner’s Dilemma” style of game-theory (to be explained in the following chapter). The study
concludes that an asymmetric setup causes a significant decrease in cooperation, and also has a
negative effect on the stability of longer alliances (BeckenKamp 2007).
What can be extrapolated from the sources found is that, according to economics, each ‘player’ will
go for the perceived highest outcome (in terms of score), and according to game design, that the
player will try to go for the biggest perceived threat.
4.2 Game theory
John von Neumann and Oskar Morgen-Stern wrote the book Theory of Games and Economic
Behavior in 1944. The book used games to describe a specific type of problems, wherein different
generalized strategies were assumed (Juul 2005). According to Juul (2005) game theory can be
useful for improving video games, even though game theory in its core does not relate to actual
enjoyable games (Juul 2005).
Page 13 of 55
Game theory is used to analyze strategic interactions, and is applied within many areas, e.g.
economic behaviour, parlour games, board games and political negotiations. [Varian 2002]
To explain in greater detail how game theory works, a classic model within game theory, the
Prisoner’s Dilemma, will be used as an example. It is a called a coordination game, which
means it’s a game where the outcomes are the highest when players coordinate their strategies.
[Varian 2002]
In the Prisoner’s Dilemma, imagine that two criminals caught in a given crime (called player A and
B) are interrogated by the police in two different rooms; both players now have two options, to
deny or confess, where confessing essentially means betraying the other criminal. To show the
payoff of their options a payoff matrix can be used. [Varian 2002]
Player B
Player A
Confess
Deny
Confess
-3, -3
0, -6
Deny
-6 0
-1, -1
Figure 4.1 – the Prisoner’s Dilemma (Varian 2002)
What can be read in table 4.1 is that if player A chooses to confess and player B chooses to deny the
accusations, the payoff for player A is 6 months in prison while player B walks free.
If they both choose to deny they will both get only be sentenced to one month in prison. If they
both confess they get 3 months in prison each.[Varian 2002]
To describe what is the best employed strategy in a game, the term pareto efficient is used - this
describes an outcome that cannot be improved. In the game above, this would be both players
denying, as one player cannot be better off without hurting the other player. [Shor 2005b]
Another term is the Nash equilibrium; this is used to describe a situation where player A's
choice is the optimal one in regard to player B's choice, and the other way around. In the Prisoner’s
Dilemma, this would be both players confessing, as neither player knows what the other player
chooses. [Varian 2002]
Nash equilibrium is often not pareto efficient. [Shor 2005b]
Page 14 of 55
If the game is played repeatedly, it opens up for different strategies. If the Prisoner’s Dilemma is
played only once, the choice of confessing is a reasonable one, since it will yield an outcome of -1½
if the other player has en equal chance of choosing either, whereas denying would yield -3½.
If the game is repeated, the players will have the chance to accommodate their choices based on
how the opponent has played previously. If a player chooses the same option every time, this is
called a pure strategy – however, if he chooses differently it is a mixed strategy. One type of
mixed strategy could be the tit for tat strategy, in which the player will start by denying; however,
if the other player chooses to confess the first player will deny in the next round to punish this,
before denying in the next round again. This has in a computer simulation of strategies been
proved to be the most efficient, even though it is a simple strategy. [Varian 2002]
Another game theory model is Stag hunt, which is also a coordination game. This model presents a
case of two hunters who can choose to either hunt a stag, which has a great payoff but requires both
hunters to hunt it, or a duck which has a smaller payoff but can be hunted alone.
A payoff matrix will look like this.
Hunter B
Hunter A
Stag
Duck
Stag
a, w
b, x
Duck
c, y
d, z
Where the following is true:
a > c >= d > b
w > x >= z > y
[Shor 2005]
Stag hunt was found to be the model that corresponds best with this project, so a modified Stag
Hunt will be used, looking like the following: In this the raptor and the hunter will replace the
hunters, b and a, in the payoff matrix, which will look like this:
Page 15 of 55
Weak Faction 2
Weak Faction 1
Strong Faction
Weak Faction 1
Strong Faction
2, 1
0, 1
Weak Faction 2
1, 0
½, ½
The strong faction should be impossible to defeat alone; however if the weak factions cooperate,
then going for the strong faction will yield the most points - in this case two points for both of the
weak factions.
The situation where the game will differ the most from stag hunt is when the weak factions choose
to hunt each other - in this case it is only possible for one of them to succeed, and the payoff will
therefore be even lower, since only one of them can succeed, so it will yield on average half a point.
There is one pareto efficient choice in this case, which is if the weak factions cooperate against the
stronger; however, the only Nash equilibrium is if they hunt each other.
The payoff matrix above will be used as the score system for the game, so defeating the weaker
factions will yield 1 point to the killer while defeating the strong faction will yield 2 points both of
the weak factions.
This payoff system will be used in analyzing how players choose their strategies.
4.3 Metrics
This section seeks to clarify how and what to measure in order to analyze the player behaviour in
the game. Metrics used in this report is short for “game metrical data”, meaning data collected
from within the game itself.
In a typical program a user initiated event (UIE), such as clicking the print button in a text-editor
prompts the program to print, but nothing further is done with this data. However, tracking of UIE
within the field of Human-Computer Interaction is becoming more frequently used. [Kim et al
2008]
Page 16 of 55
Kim et al (2008) describes a system that they have developed to collect extensive amounts of usage
data, called TRUE - Tracking Real-time User Experience. This system was created with games
research in mind, and have been used in the development of the game Halo 2, created by Bungie.
The system creates a log-file which holds all the collected data, with time stamp on individual logs
so it can be seen how long the user spends e.g. looking at the help screen. Furthermore the system
logs data in event sets rather that single data points – for example, instead of just collecting the
event of a crash in a racing game, TRUE will also collect data on the type of car, weather etc.. This
way the developers will have a better chance of determining why different events occur when they
do. [Kim et al 2008]
The system also collects attitudinal data; this being done through brief questionnaires pertaining to
the users’ attitude towards the games entertainment value and difficulty. Finally TRUE also records
video of the gameplay, which then can be viewed afterwards with the time stamped events to
analyze what may have to change. [Kim et al 2008]
In this project, the goal is to figure if players start to cooperate at given times. A system like TRUE
could be very good at analyzing this, however, certain things speak against using as comprehensive
a system as TRUE.
TRUE has been used on Halo 2, a very big game. The project-game is almost microscopic in
comparison, and assuming there was even time to implement as extensive a system as TRUE, there
would not be time to conduct such a long detailed test on enough participants.
This does not mean that the system cannot be used for inspiration - recording a few games for
deeper analysis could prove to be a valuable tool.
To conclude, the list of metrics that could be used all fit in the two categories; mechanics and
physical behaviour.
The metrics that have been deemed as important and which will be collected in this project are:
time (time stamp), damage dealt, damage taken, kills, position.
Each in-game event, like one faction attacking another should trigger all the values in the above
mentioned metrics being saved.
Page 17 of 55
4.4 A discussion of Balance
(This section must necessarily follow the one on Game Theory, and this space is reserved for an
introduction following that).
In order for the test to adequately build upon a fair Game Theory scenario(??), the game must
incorporate elements of balance; that is, that the two ‘lesser’ factions of the previously mentioned
product-game idea, must be as equal in strength as is possible, as explained below. This is
necessary both to allude to the Staghunt game theory, but also to ensure that each of the factions
do not feel underpowered compared to its direct opponent, something which could ruin the
player’s motivation for playing. Despite the obvious need for balance, the game must also, in a
sense, be unbalanced. The bedrock of the test on player behaviour is still the fact that one faction is
stronger than the others, so this must naturally be incorporated too.
In summary, that provides the following checklist:
•
The two lesser factions (hereafter referred to as ‘the Hunter’ and ‘the Raptors’) must be as
equal in strength compared to each other as the game allows. By this is meant that when
two equally inexperienced players battle each other as the two factions, the ratio of win/loss
should be about 50% for each of them.
•
The stronger faction (hereafter referred to as ‘the Tyrannosaurus, or ‘T-Rex’ for short) must
be powerful enough to be able to defeat either of the other two opposing factions when on
their own, but not so powerful that it can defeat them when they’re working together.
•
The two lesser factions do not necessarily need to be equally effective in their fights against
the Tyrannosaurus. This point might seem harsh and unreasonable, but remember that as
long as neither faction can defeat the Tyrannosaurus alone, this should have no impact on
the overall experience.
4.4.1
Balancing the game
Balancing of the game, as described above, is a crucial element, but defining what constitutes it
within a game world is unique and different to each one. In locating exactly which elements need
focus to achieve balance, we base our initial analysis on expert opinions from experienced
developers.
Page 18 of 55
This section will build on two articles on Game Balancing, by game developers David Sirlin and
Keith Burgun. Firstly the product-game will be described in-depth using game developer terms,
followed by a discussion of how best to go about reaching the above-mentioned balancing-goals.
David Sirlin speaks of what he calls depth in games, described thus:
“A multiplayer game is deep if it is still strategically interesting to play after expert players have
studied and practiced it for years, decades, or centuries.”
(Sirlin, January 2002)
Herein lies the largest breaking-point with some of Mr. Sirlins musings – the intended productgame cannot, by Mr. Sirlin’s standards, be considered deep.
As a game developed for testing a specific hypothesis, this is not an issue, however, as the players
will not be able to play the game for extended periods of time in any case. This point is highlighted
regardless, as the remainder of the base article assumes a game that incorporates his definition of
depth, and where this is the case this section will seek to translate these measures to ‘shallow’
games instead. (Sirlin 2008)
“I can say with confidence that the farther to the right on that scale your game goes, the more
difficult balancing your game will be.”
(Burgun 2011)
While asymmetric games are inherently more difficult to balance than symmetric games like Chess,
which is considered balanced due to the fact that each player has the exact same force and
properties, different approaches could be used to help balance the two lesser factions against each
other. One of these, the ‘Yomi Layer 3’, uses the skill of the players to accomplish this. ‘Yomi’
(which is Japanese for ‘reading’) means the skill of reading your opponent, and counteracting his
tactics and moves before they happen.
This might sound abstract, but consider the scenario of the Hunter and the Raptors in a duel:


The Hunter can do a roll to get out of the way, and is a ranged-fighter.
The Raptor can quickly close the distance with its jump-attack.
If the Hunter sees the raptors come running, he can roll out of the way, expecting the jump attack.
The raptors can counter this tactic by not jumping in the first place. Remember that the Yomi-
Page 19 of 55
layers mean ways of counteracting your opponent, before he strikes. To counter the raptors not
jumping, the Hunter simply turns and fires instead.
These are the 3 Yomi-layers, because now we return to the original situation – now, the raptors can
counter the Hunters stand-and-shoot reaction, by jump attacking! (Sirlin 2008)
These must be present to ensure that both the raptors and the hunter have viable counters to each
other, achieving balance despite the differences in properties and abilities.
Another element which must be considered is what is called ‘lame-duck’ situations. A situation is
called a ‘lame-duck’ when it at one point is clear that one player cannot win, yet the game has not
ended yet. As an example, in the game Marvel vs. Capcom 2 the players can compete with teams of
3 fighters each. However, if one player loses 2 of his fighters (and is thus playing 1 vs. 3), the game
has already effectively ended, even though it has not ended yet from a purely game mechanics point
of view.
This type of gameplay can cause the game’s climax to appear in the middle of the game, instead of
the end, because the game was over when one player was reduced to his last fighter, which also
means that the rest of the game is mostly pointless because the chance of winning is so diminutive.
These ‘lame-duck’ situations should be avoided where possible as they make the game boring to
play and negates the otherwise created impacts of balance.
For the product-game, a lame-duck situation could occur if the Tyrannosaurus kills the hunter
early on, and is left alone against the raptors, and as described, the raptors’ chances of winning on
their own is minute. The counter to this situation is to allow the defeated faction to ‘respawn’, that
is, letting the player back into the game after a little while to rejoin the fighting.
Another game-developer-analogy which will be considered, one that is closely-tied with the Yomilayers, is the concept of Double-Blind guessing, which means to commit to a choice before you
know what the opponents own choice is. This in turn alludes to the Prisoner’s Dilemma from the
Game Theory section. This concept can be used to describe the situation of the hunter and the
raptors versus the Tyrannosaurus, and how they decide to handle the situation, and can also be
used for the inter-faction fights that can be present, like the hunter and the Tyrannosaurus
fighting; the hunter might believe the Tyrannosaurus to attack with the tail-swipe, and so rolls out
of the way, thereby guessing his opponents intention.
Page 20 of 55
4.4.2
Play-testing
“All the theory in the world does not substitute for playtesting”.
(Sirlin 2008)
Situations arise which the designer could not have predicted, and the only way to discover these
unforeseen consequences is through playtesting. Perhaps the players favour one distinct tactic over
all others, or a local unintended imbalance is discovered – the sentiment is that theory cannot
substitute expert-players trying their best to win, and it is therefore a certainty that a game needs
playtesting to be balanced.
That being said, however, it should not be forgotten for whom the product-game is intended, or
more accurately, who will end up playing it. As previously stated, the game will likely not be
available for an extended period of time, and even though the game is much simpler than many
others, the time required to obtain the rank of ‘expert’ in unlikely to be available. In addition, as the
game is meant to be played only briefly, it should not have its balance efforts focused for when
experts play it, but instead when new players do, because this player demographic segment will
most likely constitute the larger part of those playing. Game designer Keith Burgun echoes this
sentiment:
“It's best to figure out what you want your game to be, and then focus your balance efforts
towards that.”
(Burgun 2011)
As stated, the game is meant to be played by inexperienced players, and the balancing efforts
should accommodate new players and not experts.
It can be difficult to obtain useable data from some play-testers, alluding to the concepts of ‘local
imbalance’ and ‘levels of scope’. By these are meant that something may often seem imbalanced,
but only when one is not looking at the whole picture. For example
As an example, in the game Starcraft 2 by Blizzard Entertainment from 2010, the units are widely
asymmetrical; a Protoss Zealot is much more powerful than a Zergling, and this may seem
imbalanced until one considers the Zerglings lower cost and faster speed. One of the most difficult
points lies in knowing what to do when two play-testers disagree on something, but it stands to
reason that the individual test-conductors experience and knowledge plays a role in deciding which
outcome to follow. However, the limited development time of this project means that should a
Page 21 of 55
situation arise where the outcome and measures taken cannot be determined (given that the testerconductors will all be of limited experience) the choices made will be based on our best logical
reasoning.
In his article, Mr. Burgun speaks of weaknesses, for example in class-based shooters, like Team
Fortress 2. The overall sentiment is that the weakness of each class is as important (or more so)
than its strengths, and that each class must have a weakness for all of them to be fair against each
other. This idea was incorporated in the product-game in the following way:
•
The raptors are fast and many, but can only attack via their jump attack. In addition, the
raptors are easy to hit with attacks due to them running in a pack.
•
The Tyrannosaurus, while purposely being more powerful than the others, is somewhat
slow, and also easy to hit. Remember that the raptors and the hunter, if working together,
should still be able to defeat it. To give it a bit more utility, and to help ensure it will not lose
a one-on-one situation, it has a tail-swipe attack, which pushes back anyone close by.
•
The Hunter is a ranged attacker, but will quickly lose a close-quarter fight. The hunter is
supposed to lose versus the Tyrannosaurus, but should be on equal footing with the raptors.
Knowing that the raptors can only attack in a straight line with their jump attack, the
Hunter can roll out of the way of said attack. The reason this is still fair is that the raptors
are many, and have more hitpoints than the hunter.
The balance of a game is crucial to the overall feel and success, and with the concepts considered
above it is felt that, despite the limited time and playtesting oppertunities predicted, a solid
theoretical basis has been descirbed for the forthcoming design part.
Page 22 of 55
5 Design
The design will chronicle the choices made for creating the project-product itself, determining all
aspects needed for creating this.
5.1 Product requirements
Based on the findings in the Analysis the following should be implemented:
-
A robust game that includes three factions
The game has to resemble a modified Stag Hunt setup
Two factions have to be balanced equally with a third being stronger
A metrics system that allows for data gathering has to be implemented
The game needs to include networking to allow players to play with others on the internet in
order to fill out the roles of all factions
5.2 Game Design
This chapter will seek to bridge the divide between theory and practise through a combination of
the theories and ideas from the previous chapters, converging to form the design document of the
product itself.
More specifically, the different subjects contained herein are the following:


The setting, and visual design of the game. This section will be explained first, so the terms
and ideas from it can be used in the next section.
The game mechanics, which should be designed to best accommodate a satisfying testing
environment, providing a suitable foundation for answering the hypothesis.
5.2.1 Setting
The setting of the game describes in which fictional arena, if any, the game will take place,
including environments, overall story if relevant, and the graphical representation thereof. The
decisions made in this area has little actual testing value, but serves to encompass the game in a
presentable and usable world. The chosen settings were based on personal motivation and
conviction.
As mentioned in Chapter bla: State of the Art, the project was partially inspired by the game
Giants: Citizen Kabuto. In the multiplayer modes of this game, two smaller races and one big race
are fighting each other, and this idea, of one faction in particular being large and fearsome –
especially given that this faction was denoted the 'stag' from the Staghunt game-theory - was
deemed fitting, and chosen as a base for the design of the game.
After an intense group-discussion, the idea of creating the three factions in a Dinosaur/Jurassic
Park-like setting soon emerged, and this was elected with the visual design being based off this
Page 23 of 55
The setting chosen, an environment fitting this choice of visual subjects was determined as needed
to provide an easily identifiable visual backdrop for the arena which the players will populate.
The project is, however, neither seeking to emulate Citizen Kabuto or digitalized stag-hunt
completely, but a interesting and unique amalgam of these.
A quick summary of the list of theories that will be translated into fuction:

The Stag/Kabuto - the large, imposing target, which will also serve as the 'big reward' if the
two 'hunters' decide to cooperate, will be represented by a Tyrannosaurus Rex. Going with
the dinosaur-theme, a Tyrannosaurus, besides actually being large and imposing, was
thought to be the most recognizable dinosaur due to the popularity of the Jurassic Parkmovies of the 90's, and would ensure most people could relate in some part to the game and
instinctively understand its role, something which was hoped would heighten interest.
•
The first hunter of the stag-hunt theory was decided to be another dinosaur, or actually,
several other dinosaurs! More specifically, the first hunter would be represented by a small
pack of theropod dinosaurs, similar in appearance to the Velociraptor of the Jurassic Park
movies. Once again, this design choice was based on what was believed to be most peoples
perception of popular dinosaurs. The actual dinosaur model chosen was, however, based on
the Deinonychus genus, which can be considered the Velociraptor's larger relative, as the
actual size of a Velociraptor was deemed too small. Nevertheless, the race will be denoted
"the Raptors".
•
The second hunter of the stag-hunt theory will be represented by a human soldier of some
form. It was felt that the inclusion of a human with some sort of weapon would add a very
different set of dynamics, and would also allow people to relate, as well as tying it in with
several types of dinosaur movies and games.
In terms of choice between complete adherence to historical reality, and making changes for the
sake of gameplay and visuals, the design of the dinosaurs and other elements will root in popular
media, rather than reality (in terms of the raptors having feathers, and matters like that).
With the characters set, the next section will discuss the inception of the game mechanics.
Page 24 of 55
5.3 Mechanics
Transferring the discussed theory into an actual game is a crucial element in the project’s design
stage. This section will discuss the limitations and choices included to accommodate the test as
much as possible.
The term "hunter" or "hunters", whenever mentioned in the following sections, refers to the
theoretical hunters from the stag-hunt game-theory.
5.3.1
Differences from Staghunt
The game differs from the stag-hunt in a number of meaningful ways - first of all, in this scenario
the stag is out to eat you, the hunter also becoming the hunted. Secondly, instead of hunting rabbits
or hares, the hunters are hunting eachother and naturally, this introduces some deviation from the
game theory in question. The main principle of the stag-hunt - that both hunters would reap a
larger benefit if they work together - along with the issues concerning the inclusion of this in a
deviating game-version of the same, will be discussed in this subsection.
5.3.2
Principles of the Stag-hunt
The main point of the game theory is that the hunters must work together to reap the larger benefit
- if one hunter decides to hunt the 'rabbit', then the other hunter gets nothing. If both hunters
decide to hunt rabbits, this still leaves a lower payoff than had they hunted the stag instead.
The stag in this version is the Tyrannosaurus. If both the raptors and the human decide to hunt it,
they will both receive a greater reward than had they hunted each other. This leaves the following
conclusions:
•
The 2 hunters must cooperate in order for them to, so to speak, "bag-the-stag". This means
that no matter what, neither of the players can be able to defeat the Tyrannosaurus on their
own.
•
Killing the Tyrannosaurus must yield more points than killing either the raptors or the
humans. In addition, both hunters must profit from the Tyrannosaurus' demise.
The fact that the hunters must cooperate to kill the Tyrannosaurus proved an interesting issue - in
its first inception, the Tyrannosaurus was simply a lot more powerful than either of the hunters,
and it was deemed unlikely enough that a hunter would be able to defeat it alone. There was a small
chance of it happening however - either the hunter-player was an expert, or the Tyrannosaurus
player was completely new to the game - and this was unacceptable in reference to the game theory.
To counteract this, it was proposed that each of the hunters had to deal damage to the
Tyrannosaurus just once, or else it would not be able to die. This was still not satisfying though, as,
Page 25 of 55
first of all, an errant shot from the human could strike the large Tyrannosaurus, fulfilling the
requirement without intent. Second of all, a scenario could occur where one of the hunters would
remove all of the health of the Tyrannosaurus bar the last hit, being unable to kill it until the
second hunter merely attacks it once, felling the mighty beast. Although this technically fulfils the
requirement of the two hunters cooperating, the cooperating aspect was deemed too shallow to be
considered appropriate.
As a result, the following two mechanics were introduced seeking to ensure that the hunters would
have to cooperate to 'hunt the stag':
5.3.3
Death-Cap
The death-cap system is the above mentioned limitation that both hunters have to attack the
Tyrannosaurus once, or else it will not be able to die.
5.3.4
Amplify
As has been established, the Tyrannosaurus is far stronger than either of the hunter-factions, and
these should not be able to kill it alone. The death-cap system above, however crudely, assures this
to some extent. However, recalling the 'errant-bullet' problem, even if the death-cap limitation was
lifted, the hunters should cooperate in order for them to be able to defeat the Tyrannosaurus.
However, when they do cooperate, they should also be able to succeed, and due to the
Tyrannosaurus' vast reservoirs of strength and swag, this can be difficult.
To counteract these problems the Amplify system was created. What it means is that whenever the
human deals damage to the Tyrannosaurus, the next raptor-attack, if done within a short timeinterval, will deal increased damage, and vice versa. This system should ensure that when the
hunters cooperate, they will realistically be able to defeat the Tyrannosaurus, because they
complement each other.
As an example, if the raptor is dealing 20 damage with its attack normally, if he now attacks
immediately after the human, he would receive some damage multiplier, maybe dealing 50 damage
instead.
5.3.5 Other issues
As mentioned in a previous section, if the hunters decide to hunt rabbits instead of stag,
they will effectively be fighting each other, and this match-up should be balanced as evenly
as possible to ensure even chances of scoring points.
Page 26 of 55
Figure 5.1 – concept art of the game-arena.
Page 27 of 55
6 Implementation
6.1 Introduction:
The implementation section will contain explanations of how the elements of the product
were created; which tools and methods were used for the different parts.
All of the graphical assets, the textures and 3D modeling, were made in Adobe Photoshop
and Autodesk Maya. The game itself was created in the Unity3D engine using C#. It
contains approximately 10 terrain models,3 fully animated player models, 20 textures, 20
sound assets and over 2500 individual lines of code.
Due to the time limitation and the authors' lack of previous experience with creating sound
effect and music, it was deemed a better choice to find the sound files for the game using
external sources. A list of the sound files and sources can be found on the CD.
This chapter will cover only the areas deemed most relevant to project, and ignore minor
thing that were added, such as the "on-hit" graphical effects and the graphical user
interface (GUI) which was kept to a minimum.
6.1.1 General overview
Though slightly daunting at first glance, the image below is actually a general, if somewhat
simplified, overview of how the different internal parts of the product interact. Later parts
of the implementation will elaborate on the areas considered relevant.
Figure 6.1 The general overview of the game component interactions
Page 28 of 55
When the game starts, from the user perspective, there are 2 options; to either host or join
a game. If the player tries to join a game, the user is sent information about all available
games from the Unity3D master server. On hosting a game, the game registers at the
master server so that other people can see it as available.
After joining or hosting a game, the player is sent into the lobby. At this point the user
chooses a lobby slot, which also accounts for which race the player gets to play.
The spawner object will then pull information from the user to allocate the user ids, the
races and so forth. Upon starting the game, it then spawns the objects that the user
controls. Furthermore, it also assigns values depending on race and so on, in the “Damage
script”, which then handles all damage values that is dealt between the players throughout
the game. It also relays this information in lists to the Metrics script that simply saves all of
the information.
Finally, at the end of a game session, the host will find the data collector, a server we have
running as background infrastructure, through the master server and the metrics script
will be relayed to the it, receiving and printing out all of the data we want from the game,
aiding in our subsequent analysis.
The following sections will focus a bit more on specific implementations as well as show
UML diagrams and images to explain how it works. Although the UML diagrams are not a
hundred percent accurate, there were constructed to be useful approximations of how the
system interacts.
6.1.2 The master server
The master server is the system which main functionality is not to run games, but control
the flow of users that wants to host and users that wants to join games. Every hosted game
will be registered , and client users that want to join games, can request the list of hosts
from here.
A first attempt to implement the master server was done by making it all from scratch. As
the authors, at the time, were network programming novices, the complications of various
network issues were not yet fully understood, with preliminary testing and analysis
showing the creation of the master server to be much more difficult than first anticipated.
The master server that was made in the first attempt worked fine on a LAN connection but
proved to have issues when it came to handling connections from computers that were
behind different routers.
The second attempt of implementing the master server was done by using Unity’s standard
master server template, which handles host registration and host list requests from the
clients automatically. Each individual running game instance provides a gametype to the
master server (figure 6.2). This information is then used to not mix up hosts and provide
the correct connections. It also handles NAT punchthrough which is believed to be the
main reason of the failed first attempt at creating an master server.
It uses an datastructure - "hostData" - to store host information during their registration to
Page 29 of 55
the master server. The host data stores important information to be able to connect to the
host, as well as ‘trivial’ information such as gametype, number of players in the server and
general game comments. The hostdata object can be used to connect to the server with
Unity's network function, instead of having to specify IP address, port number and manual
handling of the complex NAT punchthrough.
As Unity’s master server seemed to function at a satisfying level, and was a quick win for
the project so we could focus on other more related elements, it was chosen to be used in
this project. Image 6.2 shows a simple UML diagram of the interactions between the
master server, a game instance that hosts, and a game instance that wants to join as a
client.
Figure 6.2 – the Master Server
A game client can host a game, which will start a server, and register the game client as a
host on the master server. A client can use the function getGameList() which uses the
master server to get a current list of hosts. If a client joins a host, the host will update the
number of players in game. If the number of players connected reaches the maximum
allowed players, the host will call the master server and unregister as a host, so no more
people can join and the game will start.
(Unity3D 2012)
6.2 Gameplay
Once a game starts, each connected unit will spawn their chosen race's game object with
the function, “Network.instantiate”. Each of these objects has a NetworkView
component attached to it. This component observes the game object it is attached to, and
makes sure the game object is synchronized for every user connected to the network.
Furthermore, it has a valuable property, a Boolean named isMine, that will tell each client
if the objected was initiated on said client, or using the “Network.instantiate” function of a
different client. This Boolean is useful for when the different clients receive input, as then
their input will only affect the object that they themselves initiated, i.e. the input of the
Page 30 of 55
client user that spawned the human will only affect the human object and not the raptors.
The following subsections will explain how the human, raptor and T-Rex works. Generally,
every player controlled game object has animation, control and damage script in common.
6.3 Human
Image 6.3 shows an UML class diagram that shows am overview of how the different
scripts interact with each other.
Figure 6.3 – Human UML diagram
Whenever the client performs an action, the human control script reacts to this. If the user
is shooting, rolling or dashing, the script will interact with the human animation script,
which is in charge of playing the animations.
The action shoot will create a new object, bullet, which on collision with a player, will
invoke the damage functions in the damage script. The damage script keeps track of their
players health, and makes sure damage can be both given and received. The control script
and animation script is used by the damage script in order to check if the player is
currently dead. If so, the death animation will play and all the controls will be disabled
during this time. The damage script is also in control of adding events to the event list. This
is done each time damage is dealt or received.
The T-rex works in a very similar way, with the only exception being the bullet class being
replaced with the functionality of the tailswipe class.
6.3.1 MANGLER NOGET HER
6.3.2 Raptor
Image 6.4 shows an UML class diagram that shows how the raptor scripts interact with
Page 31 of 55
each other. This race, although similar to human, has a pack, that adds a different element
to the interactions between the scripts. First there is the pack raptor, the raptors following
the main one. The raptor control script controls the amount of pack raptors present. These
pack raptors are dashing whenever the main raptor is dashing, but this is the only link
they share. The animations of the pack raptors are handled individually, since they can die
at different times, and can run at different times too. Each pack raptor interacts with the
same damage script as the main raptor does, but the float value “damageReduction”
reduces all incoming damage on pack raptors, while their AI objects forces them to try and
move to its position.
They These are empty (invisible, with no body) objects that use AI (see section 6.4) to
determine where it should move. Their goal is to stay close, but not too close, to the main
raptor, while trying to avoid hitting objects like rocks and mountains. The reason for
choosing an empty game object to ‘lead’ the way for the pack raptor, was that the AI
implemented does many irregular turns that would look very strange for the users playing,
if added directly on the pack raptor.
Figure 6.4 – Raptor UML diagram
6.4 Pack raptor AI
As shown, each “pack raptor” spawns a “pack raptor AI”; this section will cover how the Pack
Raptor AI scripts AI determines its path and position.
Page 32 of 55
The “pack raptor AI” searches in an area around them for other objects; they will then apply basic
steering AI :
Pursuit is a simple pursuit mechanic of the actual players’ raptor.
Separation - looks for nearby neighbours and get a vector opposite of these added to their
position to avoid crashing into each other.
Figure 6.5 - Separation
Cohesion – checks for nearby object, finds the mean-position of the group, and moves in a little
towards the middle. This causes the points to stay fairly close.
Figure 6.6 - Cohesion
Avoidance – sends a ray cast forward. If it hits something, it will find the quickest way around
this object. This direction will then be projected on its own side vectors, while adding it to the
movement vector as well, causing it to slide out of the way of incoming objects.
Page 33 of 55
Figure 6.7 - Avoidance
Alignment - checks the surroundings and will form a general “pack direction” that it will adopt
slightly, to cause the pack to look more organized.
Figure 6.8 - Alignment
All these AI elements are added onto a movement vector with a weight. The weight focus of the
particular raptor AI, is mainly based around separation and avoidance. This is mainly because the
actual points that the AI is added to is not the raptor itself – it is a simply a guidance point for the
raptors to run towards. This means that they have to be very close to follow things like avoidance
Page 34 of 55
and if separation is too low, the raptors would run into each other, causing the AI to be rendered
useless. This means a high separation, along with a high avoidance, allows the raptors to follow the
pack leader quite well and avoid objects at the same time, if their run speed is high enough.
The next chapter will focus on how the event collector collects the data and sends it to our
Data collector server.
6.5 The Metric System
Since every event of data that is meant to be gathered all occur when a player takes
damage, the events were added in the same script that handled damage, for convenience
sake. Every time a player takes damage, all relevant data will be stored in a list and sent to
a separate game object who will store all the data until the game has ended. Events being
added was only limited to server side, since the host would be responsible for sending the
data to the main server. Image 6.9 illustrates a sequence diagram of a simple event were
one player damages another. In this case, player 1 attacks player 2, damaging him, where
player 1 and player 2 are the characters of the host/clients, and the event is occurring
locally on the host’s game instance. The player 2 game object will recezhat is connected to
the server. Finally, another event is added to the event collector, that the player 2 has taken
damage. This means, every time a player takes damage, two events will be added; one
where player1 damages player2 and one where player2 takes damage from player1. This
was made since it was deemed easier to sort through the data with this kind of system.
Page 35 of 55
Figure 6.9 – Sequence Diagram
After a game is finished, the host of the game will attempt to connect to the data collector,
which will receive all the data that was stored in the event collector of that game.
This should conclude the main components of the game that is relevant to programming.
The next chapter will give an scenario of how the entire system would work in an ideal
scenario.
6.6 Client overview
The sequence diagram in image 6.10 shows how a standard event of hosting a game,
joining a game, and sending the data would work in an ideal scenario.
When the application is run, the first thing it will do is try to attempt to find the hostdata of
the data collector. This event will occur despite whether the user wants to host or join a
game. Next, the host user will create a server for other users to join. After the server has
been initialized, the host user will send the information to the master server, who will
register the host user’s server as a game. He will then wait for other users to join.
Meanwhile, the users who want to join games instead of hosting will send a command to
the master server to request the list of available games. If they find a game to their liking
they can join. When there are enough players in a game, the host will start the game, and
in the process, unregister the host from the master server.
As the game finishes, the host will send a message to all joined users that will reset their
client. Host user himself will attempt to connect to data collector server. The host user will
send a request to the data collector server to find out if it’s ready to receive data. If it’s not,
Page 36 of 55
it is not, the host user will wait, and then attempt again. If the data collector is ready to
receive damage, it will set its status to busy. When the host user is done transferring all its
data it will send a message to the data collector to let it know it’s done sending. The data
collector will then set its status to ready, letting other host users know it can receive data
again. The host user that just sent his data will then reset his client.
Figure 6.10 – Sequence Diagram 2
Next section is maya and modeling.
6.7 Modelling for Games
When performing 3D modelling for games, one needs to consider the real-time rendering process
for each of the objects in the game. Real-time rendering relates to the process of turning model
data and shader information into images through a series of mathematical calculations, fast
enough for it to appear as a fluid, interactive animation. If this isn't done successfully, as a player
plays the game, they might notice a drop in frame-rates and the game will not run smoothly. A
common reason for this is the model information being too complex; if they models used in the
game have been designed with too much detail and contain too many polygons, this can be more
than the graphics hardware can handle, especially when multiple instance of the same model are
present.
Page 37 of 55
In games then, models are cleverly designed and created to achieve as good graphics as possible
with the lowest amount of polygons, and thus mesh detail (Derakshani June 2011). In many feature
films the characters and objects used are often very highly detailed, because the rendering time,
although still very much important, is less of an issue as the rendering is done by super computers,
and server farms are rented specifically for this purpose at the end of a movie’s development.
This luxury cannot be offered to games, and even though graphics hardware is continuously
evolving to support better and better graphics, the real-time rendering aspects needs to be
considered when modelling for a game.
“it will always be important to maintain a polygon count that suits the needs of the game engine
and its associated hardware”
( Autodesk 2006)
In addition, as the game is envisioned to be played on a wide variety of hardware, the graphical
specifications of which cannot be assured, this method is doubly true.
6.7.1 Requirements
As per the considerations made above and through the understanding of what the game requires of
3D models, this subsection will decipher what the requirements for the product game are through
listing the individual objects that have been identified as needed:
6.7.2 Playable Characters:
As previously established, there will be 3 controllable characters (alongside the AI-controlled
raptor pack) namely;



A Tyrannosaurus
A Human soldier or hunter of some sort
A raptor
Given the time constraints, different avenues of acquiring a human model for the game rather than
modelling one were explored. While it would have been preferable that way, the time constraints
on the project coupled with the inherent difficulty of successfully creating and mapping a
sufficiently human-like model meant that this model was found as a free resource online. The
model, however, was not rigged or animated in any way, and this was achieved as will be explained
later in this chapter.
Page 38 of 55
6.7.3 Animations:
In addition to creating the static 3D models for them, several animations are required for each of
the playable characters. The most important ones (the ones shared across all characters) are listed
here:




An idle animation: This animation is used for increased realism, as living objects (or
animated ones, for that matter) are seldom completely still.
A walk/run animation: This animation was split in two – a start-run animation, which
depicts the character in question leaning into his walk/run pose and beginning movement –
and a looping animation for the run.
An attack animation: These are obviously of different types across the characters (while
a Tyrannosaurus wielding a gun is scary, a hunter jumping about and biting people is not
(although it would be unnerving)) and thus have to be created with even more focus on
individuality.
A death animation: The character has taken as much damage as he can bear, and
collapses spectacularly!
In addition to these, the Human and the Tyrannosaurus have one additional animation
representing their ‘special-move’; the Tyrannosaurus can turn quickly to swipe his tail around,
and the Human can to a combat-roll.
6.7.4 Environment:
In addition to the characters, the game requires various types of graphical doodads, that is,
background elements to be duplicated across the terrain to form the backdrop. The game has been
established as an arena-style game, and so the level map required will not need to be particularly
large. Nevertheless, the following list has been created to populate the virtual environment, which
was established as a lightly forested nature area:




One or more types of trees
One or more rock/stone/boulder-like objects
A mountain, used for bordering and enclosing the arena-area
Bushes and shrubs for increased natural detail.
With these lists of requirements established, some of the more interesting ways of creating the
models will be explained in the following section.
6.7.5 Tricks and techniques
Several ways of adding detail without fiddling with the mesh of the models themselves are possible
however, and this section will clarify the use of some of these. More specifically, the following
subsections will explain why and how different types of mappings were used on the game-models.
Page 39 of 55
The types of mappings used are the following:



Colour Mapping
Normal Mapping
Transparency Mapping
Other types of mapping were considered, namely Bump Mapping, Displacement Mapping and
Specular Mapping. Bump Mapping, which simulates small bumps or ‘wrinkles’, could have been
used on objects to offer a greater sense of realism and details, but if used incorrectly or with
insufficient specifications the result can be less than desirable and can look odd. In addition,
bump-mapping heavily increases rendering time, something definitely not desirable in this project
(AutoDesk 2012).
Displacement mapping, which changes geometry based on an image mapped onto the mesh of
a model, could have been used for quickly creating good-looking detailed rocks and boulders, or
scales on the different dinosaurs, but also increases polygon-count by a large margin, and so other
ways of creating a desirable look were pursued (Birn 2006). Lastly, Specular Mapping could
have been used to produce a more life-like sheen on dinosaur-scales or to simulate minerals in
boulders or mountains, but this effect was deemed a luxury, and was cut from the game due to
time-constraints.
6.7.6 Colour Mapping
A colour map replaces the main surface colour of an object with a texture. The color map can be
applied by firstly UV-mapping the model in question, and then applying a flat texture to the
different parts of the UV-map. When applied, the Color map will “wrap” around the model mesh.
When creating color maps, it is best to avoid drawing highlights directly on the texture, because
this highlight will show in addition to actual highlights created through lighting techniques in the
different programs (Birn 2006).In addition, when doing realistic rendering, pure black and pure
black should be avoided because these colors do not occur in nature (Birn 2006).
All objects in this project were colour-mapped.
6.7.7 Normal Mapping
Normal mapping is used to simulate increased detail by normal mapping the normal values of a
high-polygon model to a low-polygon cousin, so to speak to mask the difference. This allows for
using less polygon-heavy models while still achieving a satisfyingly detailed model – note though
Page 40 of 55
that normal mapping does increase rendering time, but the ratio of quality versus processing
requirements is higher than some other techniques (Birn 2006).
6.7.8 Transparency Mapping
A transparency map is used to make parts of a texture (and the underlying model) transparent to
some degree. In this project the technique was applied to several different doodads – the bushes
and shrubs and the different sets of leaves for the trees all included transparency mapping.
6.7.9 Inverse Kinematics
The animations were created using Inverse Kinematics (IK for short), these being useful for
animating models with a large number of joints. Unlike Forward Kinematics, which requires all
joint angles to be specified, IK techniques determine the motion of the character based on the final
angle of the key joints that define the motion (Kerlow 2009). Inverse Kinematics requires that the
three-dimensional models to be animated are created as hierarchical structures, and are most
commonly applied to models built with a hierarchical skeleton of rigid parts connected by a
number of joints (Kerlow 2009).
Inverse kinematics techniques can greatly simplify the work involved in animating models needed
to move in complex or realistic ways, and so was used on all animations in the project.
6.7.10 Walkthrough
This section details the entire process of creating and animating a model.
It is usually a good idea to create a model from a number of reference images, to both decrease the
amount of work required by the modeller and to increase the chances of the model appearing as the
concept-art dictates. These pictures were imported into Maya, and set as various image-planes, and
the base mesh of the model was created accordingly. With complex detailed models such as these,
it is usually a good idea to create some parts separately to increase the ease with which detail can
be modelled into them, and then to combine all different models afterward.
A way of saving time and ensuring uniformity on both sides of a model is to create only one half of
the actual model, and then to duplicate and flip this model across an axis, thus creating one whole
uniform figure.
With the base model created, it is time add colours through UV and colour-mapping. When UV
mapping, one essentially “flattens” the model in a sense, and when colour-mapping, one paints on
the flat surface of the 3D model. To create a gradual, smooth look across the model, if the model is
UV-mapped from different angles or with different tools, it is necessary to ‘sew’ the different parts
together.
Page 41 of 55
The UV map for the Tyrannosaurus model. The
white lines indicate where polygons are in
relation to each other. The large mass at the top
is an example of two individually UV-mapped
parts sown together – here the sides and the
back of the dinosaur.
Figure 6.11 – UV map of the Tyrannosaurus
Once the UV coordinates are satisfyingly mapped, the different types of mapping can be applied. As
explained, the colour-mapping process involves painting the desired texture onto the areas
designated by the arrangement of the UV
coordinates.
The colour-map for the tyrannosaurus. Due to
time constraints, most detail was lavished on the
prominent areas of the model, namely the head
and the sides/back.
Figure 6.12 – Color map of the Tyrannosaurus
Most further mapping techniques were omitted
both due to time constraints and the fact that the group operated with a fairly unknown gameengine, and the prospect of importing different aspects of unknown complicity was unattractive
and unneeded.
The exception of this being the choice of applying a normal map to the raptor, to increase detail
without noticeably increasing rendering time. Applying a normal map involves creating a more
Page 42 of 55
detailed version of a model, and then mapping that models normal-values to the less detailed
version, creating the illusion that light falls naturally and smoothly on geometry which might not
even be present.
Figure 6.13 Hi- and low-poly versions of the
raptor
On the left is shown the high-polygon version of the raptor, and on the right the low-polygon,
normal-mapped version. The difference in
visual appearance is not severe, yet the model
on the right consists of over 14.000 less
polygons (left model is 19490 polygons, right
model is 4850), decreasing the time needed for
rendering.
With the model satisfyingly created, the process
of rigging and animation could begin – as
explained further above, rigging the skeleton
for a model to be animated using inverse
kinematics involves creating a hierarchy of
joints in the model. Once this is finished, the
geometry can be ‘bound’ to the skeleton of the
model, this dictating what part of the mesh
follows the different movements of IK-handles.
Once applied, it is generally needed to paint
skin-weights onto the model for all separate IKhandles, ensuring that only the wanted mesh
will follow the movement.
Figure 6.14 – Joint Hierarchy for the hunter
Page 43 of 55
The animations were created using inverse
kinematics to control the joints. All animation were
created through key-frame interpolation, which
means designating some key areas where the
particular limb should be positioned in the timeline.
Through key-frame interpolation, the limb will
move from the start to the end-spot when the
animation is played. Animating with this technique
involved several key-frame interpolations for each
inverse-kinematic handle on a model, for each
unique animation.
A total of 18 animations were created for the three
Figure 6.15 – Hunter skeleton and controls
characters in the game.
6.7.11 Importing to Unity
The game engine used for creating the game, Unity3D, has a build in FBX Importer which allows
for easy importation of models and animations from a 3D modelling program such as AutoDesk
Maya. One issue with this import is that Unity does not automatically apply normal-maps, and a
few standard settings have to be changed for this to take effect – the importer needs to be told to
change the normal vectors of the low-polygon model depending on the normal map.
Importing and applying animations involves saving the keyframe values of the animations in
intervals indicating the full length of that animation. When using inverse kinematics, the option to
“bake animations” has to be turned on for the animations to show correctly.
6.8 Internal Testing
6.8.1
Introduction
In order to form conclusions about the success of the project, a testing phase inevitably follows
development, to answer the original hypotheses and evaluate completed implementation of the
different modules that make up the product.
This chapter details the different tests performed on the product elements in terms of evaluating
their success.
Page 44 of 55
6.8.2
Types of Tests
The testing of the system was split into two distinct sections; the concurrent testing of the code
as it was developed, and the eventual project evaluation focusing on the requirements being
fulfilled.


6.8.3
Concurrent Development Testing. These tests were carried out as part of the development, used to
continuously verify that the problem was on the correct path, as well as to identify and correct
weaknesses in code and graphical development early on.
Final Evaluation. This is the verification of features and goals; that the final product contains the
elements that were envisioned, as well as completing the task and answering the questions it was
intended for.
Concurrent Testing
The concurrent testing was done after and during the individual phases of the development, to
ensure a level of internally-evaluated quality and success, and included the following tests:



Qualitative Animation Tests
Connection Tests
Something code-y
The qualitative animation tests were based on the previously stated perception that the game
should include smooth and accurate animations for the characters, and involved continuously
viewing and evaluating the animations from different angles and distances, reworking errors in
rigging or keyframe interpolation if these were not satisfactory. The human hunter especially
benefitted from these, having the entire skeleton and rigging reworked and some animations
redone from bottom up.
The connection tests – Pedram and Casper Assemble! Måske noget med ting vi gerne ville have
6.8.4
Final Evaluation
The final evaluation of the product will assess the overall fruition of the game.
6.8.4.1 Internals
The elements tested in internals encompass:



Real-time rendering frame rate test
Connection tests from game to server
Correct gathering and sending of metrics-data.
6.8.4.1.1 Real-time Rendering Test
The rendering test was done by observing the in-game frame rates over a number of times running
the game on different levels of hardware. The result was that on older machines the game was still
Page 45 of 55
able to run at an average of 59-60 frames per second, which was deemed acceptable based on
knowledge of general levels of frame-rates in games.
Outcome: Success - the game ran smoothly even on older machines.
6.8.4.1.2 Connection Tests
Different connections were done, generally with three different conditions for the host of a game:



Local connection host
Remote connection to host with direct connection
Remote connection to host behind a router
No complications were found with neither local connection nor direct connection on remote
network. However, there complications with remote connections to a host that was behind a
firewall. An error message related to NAT punch through was received at seemingly random times
and we were unable to duplicate them in consecutive sessions. This is a somewhat crucial error.
Outcome: Somewhat successful, but with one crucial error that we were unable to replicate, that
could create complications during an online test.
6.8.4.1.3 Metrics tests
The overall goal of the metrics was to send all information relating to damage. Then mark them
with a time stamp as well as the positions of each of the three players. However this function
continued to create a lot of problems very late in the process which caused the testing of it to be
lacking.
Outcome: Overall the most important data was sent and received without any problems. This
included the damage taken values, the deaths values, the position values and the time values.
However specific information on “who killed who”, managed to somehow get mixed up.
6.9 Lessons learned from Testing
Due to concurrent testing, a number of serious coding bugs were caught early enough to correct
them, saving precious time in the overall development phase. In addition, some features such as
the game supporting more than three persons (er det sandt?) was cut due to bla bla.
6.9.1
Chapter Summary
The concurrent testing phase showed the importance of performing these, and though some
features were cut due to constraints, the product-game itself and its associated networking and
data-gathering features were shown to pass almost all tests, and was therefore deemed a success.
Page 46 of 55
7 Testing
7.1 Balance test
To ensure the game was balanced for those whom it was meant to be played, 3 short balancingtests were conducted on students recruited from Aalborg University Ballerup. The test consisted of
the test-participants being asked to play the game without any additional knowledge of the test or
controls provided. When the test ended, a short discussion regarding the different classes and the
individual strength of these was commenced, and the answers and actions of the test-participants
were used to alter some parts of the product.
7.2 Product test
The test will be split in two parts, - the results of the quantitative test and the qualitative test.
The quantitative will be conducted on test participants that have been drafted through various
gaming forums where the game will be ‘advertised’. The goal is to get as many participants as
possible, within an allotted time frame.
The game is playable through a downloadable executable.
The data that will be collected will only be data from within the game ie. Damage dealt, damage
received, kills, deaths, and positions at events.
The game will set up so that the participants do not know who they are playing with and against,
and will operate with unnamed servers. No form of communication will be available for the
participants.
Some players might be able to know who they are playing with - for instance if two participants are
sitting in the same room and end up on the same server there is a possibility that they would be
able to figure it out.
The qualitative test will be conducted on recruited test participants from Aalborg University
Copenhagen. In this test the quantitative data will still be collected in-game; however the game will
also be recorded. After the game, the participants will be interviewed on why they made some of
their key decisions in the game. In this instance the participants will also not have any available
form of communication with the other participants.
The participants will play on computers that have been set-up for the purpose, using screencapturing software.
Page 47 of 55
7.3 Results
This section will discuss the results gathered in the test, starting with the qualitative test.
In the first game, both participants felt the T-Rex was very tough; the raptor start to focus on the
Figure 7.1 – Qualitative game 1
hunter because of this, and then went for the T-rex while the hunter was dead. Both players
generally went after score. None of the players felt there were any alliances present.
Figure 7.1 shows the damage the T-rex took during the 30 second-intervals. The T-rex was killed
four times during this game, with three of those deaths happening in the second half of the game.
This is also apparent on the graph, as each kill can be seen at the end of high damage spikes and
there are four large spikes, discounting the last one as the game ended before the T-rex died.
Page 48 of 55
From the look of the graph it looks like they did start to cooperate more in the second half of the
game even though they did not feel they made any alliances.
In the second game the participants changed their tactics during the game, the raptor started out
focusing on the T-rex however when the hunter took the lead on points, he switched to focus on the
hunter. His tactic also went from a more defensive charge and flee tactic to being all out aggressive
in the end. The hunter generally went for the T-rex because he felt it was a bigger threat, constantly
Figure 7.2 - Qualitative game 2
chasing him, however he would have liked to attack the raptor more, as it was in front on points.
Figure 7.2 shows us that the participants actually did focus on the T-rex quite intensively at times,
as most of damage is spread on four very steep and tall spikes. Again the T-rex died four times, but
this time the damage looks to be spread more evenly over the entirety of the game, with only brief
breaks in damage taken.
Page 49 of 55
In the third game the hunters tactic was to run and shoot when somebody got near him - had he
noticed that the T-rex deaths yielded points for both the raptor and human, he stated that he would
have targeted the T-rex less, to avoid granting the raptor points. The raptor focussed mostly on
hunter in the beginning but changed focus as the T-rex gained points by killing the hunter, thereby
putting it in the lead. The raptor also went from cautious, to all out attack when he realized he was
in the lead points-wise.
Figure 7.3 - Qualitative game 3
Figure 7.3 shows that slightly more damage was dealt to the T-rex in the first half of the game; the
reason for the drop in damage in the second half could be explained by the hunter focusing on the
raptor late-game because of the scores.
The three games show different results as the first game saw the participants start to attack the Trex simultaneously towards the end of the game, where the opposite seems the case in the third
Page 50 of 55
game. Finally the second game seems to be more even throughout, with a lot of focus being put on
killing the T-rex, hence the tall spikes in damage.
Had the results on the quantitative test been collected in time for this report they would have been
analysed using graphs like the ones above; however, all the games would have been added together
into one graph so it could be seen if a general trend was present. Had the results looked something
like figure 7.1, a comparison of the damage dealt in the first half of the game with the damage dealt
in the second, would have been performed using a paired samples t-test, or if splitting it into more
than two parts, a repeated measures ANOVA.
Page 51 of 55
8 Discussion
The test results showed that even though the T-rex was overpowered, cooperation between the
weak factions meant that it could be relatively easily killed, and since it yielded more points, the
other players seemed to focus on this. Therefore, when the T-rex fell behind in scores, the raptor
and hunter would tend to target each other, even if they felt another 'race' was more powerful. This
is not necessarily a bad thing, since the expectation was that they would form a temporary
alliance, meaning they would most likely turn at each other at some point anyway.
From the gathered results, it can be seen that the method used for this test seems to be able to
collected the hypothesized data. The data gathered through metrics can clearly indicate when
players cooperate to force a common enemy to his knees. This is a fairly good indicator that the
product lives up to its product requirement and that it is a useful test platform to conduct this form
of data gathering.
Balance might have been an issue though, since there were clear differences in the amount of
points the human, raptors and T-rex scored, where the T-rex’s scores generally were much lower.
This could be remedied by granting the T-rex more points for, to balance the fact that the
human/raptors-alliance gain more points overall (due to the T-rex rewarding a total of 4 points,
two to each). Technically, the amount of points the T-rex scores should not affect the temporary
alliance between raptors and humans, unless the T-rex fell far behind points-wise compared to the
two others, in which case the T-rex would be perceived as less of a threat, and the human/raptors
temporary alliance might break off earlier than anticipated.
Finally the information given to the test participants might have had an effect on the amount of
cooperation; the information given was purposely sparse, as it was not wished to force them to
cooperate but merely observe if they would. However a more noticeable score system might be the
way to go here, and it could also be considered showing how much damage is dealt from each
attack in-game.
However, all this information has to be viewed through the light that the gathered data is extremely
sparse at this point, and no conclusion can be based on this amount of data, but can instead serve
as an indicator of what further results might show.
Page 52 of 55
9 Conclusion
From a single concept, an early idea, sprung a long, and often times exhausting process of creation,
one which, while limited in scope by the time constraints of the project, still accomplished many of
the tasks it set out to do.
From the initial inception followed a thorough theoretical phase of analysis and research,
attempting to understand the deeper mechanics that underpin the asymmetrical games chosen as
the product inspiration, while at the same time getting to terms with the advanced concepts of
game theory.
These elements were to form the foundation for the design of the game; a phase that through
different disciplines of implementation - network technology, artificial intelligence, real time
rendering - served to create a comprehensive product with a solid data collection component, that
would be used to answer the questions posed earlier in the theory.
While more time for testing would have meant a broader analysis, the limits of the project and the
development meant that these are tasks which the created product could accept in the future, as the
platform still stands with researched features and extensive graphical implementations intact.
Page 53 of 55
10 Bibliography
Autodesk. Autodesk 3ds Max 9 Essentials. Autodesk, 2006.
AutoDesk. Bump Map. 2012.
http://docs.autodesk.com/STRDET/2012/ENU/filesAUG/WS1a9193826455f5ff316fd70e123dece8002-560e.htm (accessed 05 24, 2012).
BeckenKamp, Martin, Hennig-Schmidt, Heike, Maier-Rigaud, Frank P. “Cooperation in Symmetric
and Asymmetric Prisoner's Dilemma Games.” University of Bonn, 2007.
Birn, Jeremy. Digitial lighting & rendering 2nd edition. new Riders, 2006.
Burgun, Keith. Understanding Balance in Video Games. June 2011.
http://www.gamasutra.com/view/feature/134768/understanding_balance_in_video_.php
(accessed 05 24, 2012).
Derakshani, R. Autodesk 3ds Max 2012 Essentials. Sybex, June 2011.
Esteban, J, Sákovics, J. “Olson vs. Coase: coalitional worth in conflict.” University of Edinburgh,
2002.
Ferguson, Mike. “Mike Ferguson on Guild wars 2 world-vs-world.” ArenaNet. 16th February 2012.
http://www.arena.net/blog/mike-ferguson-on-guild-wars-2-world-vs-world (accessed 05 24,
2012).
Forbes. 2012. http://blogs-images.forbes.com/johngaudiosi/files/2012/04/GuildWars2-1.jpg
(accessed 2012).
Jenakalif. Who in the world is reddit? 2011.
http://blog.reddit.com/search/label/reddit%20demographics (accessed 04 24, 2012).
Juul, J. Half-Real - Video Games between Real Rules and Fictional World, Kindle ed. MIT Press,
2005.
Kerlow, Isaac. The art of 3D computer animation and effects 4TH EDITION. John Wiley & sons,
inc., 2009.
Page 54 of 55
Kim, JH, DV, Schuh, E, Phillips, BC, Pagulayan, RJ & Wixon, D. “Tracking Real User Experience
(TRUE): A comprehensive instrumentation solution for complex system.” CHI 2008 Proceedings,
2008.
macgamezone. http://www.macgamezone.com/images/tests/giants/03.jpg (accessed 2012).
Salen, K, Zimmerman, E. Rules of Play: Game Design Fundamentals. The MIT Press, 2004.
Schell, Jesse. The Art of Game Design. Morgan Kaufmann, 2008.
Schober, Kai. “Producer's Interview on MMORPG.com.” mmorpg.com, 04 jan 2012.
Shor, M. Stag Hunt Dictionary of Game Theory Terms, game Theory net. 2005.
http://www.gametheory.net/dictionary/games/StagHunt.html (accessed 12 05, 2012).
Sirlin, David. Balancing Multiplayer Games. october 2008. :
http://www.sirlin.net/articles/balancing-multiplayer-games-part-1-definitions.html (accessed 05
24, 2012).
Tychsen, A & Canossa, A. “ Defining Personas in Games Using Metrics. .” FuturePlay 2008,
Canada, 2008.
Unity3D, Documentation. Master Server Documentation. 2012.
http://unity3d.com/support/documentation/Components/net-MasterServer.html (accessed 04
24, 2012).
Varian, Hal R. Intermediate Microeconomics - A modern approach. 6th edition. W.W. Norton &
company, inc., 2002.
Zissu, Stuart, interview by Stow. 10 Years of RvR (03 02 2011).
Page 55 of 55