You are on page 1of 64

Jamie Parish

000730301

2014 - 2015
AN INVESTIGATION INTO IMPROVING PLAYER
EXPERIENCE USING DYNAMIC DIFFICULTY
ADJUSTMENT THROUGH MODELLING PLAYER
PERFORMANCE

Jamie Parish
000730301
Page 1 of 64

Jamie Parish

000730301

ABSTRACT

This project investigates the various techniques which can be used to help implement Dynamic Difficulty
Adjustment (DDA) systems within games, along with the mental state of Flow and how a game
maintains a players optimum enjoyment level by using a DDA system to accurately adjust the games
difficulty to match a players playing style. This project will implement a DDA prototype with a simple
video game as a proof-of-concept to the research and to reveal accurate results by recording
participants gameplay performances to see if they have achieved Flow.

Page 2 of 64

Jamie Parish

000730301

ACKNOWLEDGEMENTS
I give my thanks to the following people who have given me support and feedback throughout this
project:
My supervisors DarrenLloyd Gent and Damon Daylamani-Zad, who has helped me guide this project
through different ideas to a more focused area and with appropriate deadlines to keep me on track. But
would like to personally thank Damon Daylamani-Zad who has been a great help in giving me great
advice and constant feedback throughout the development of this project.
I would also like to thank the people who gave up their free time to test my product and gave me instant
feedback.

Page 3 of 64

Jamie Parish

000730301

CONTENTS
1

INTRODUCTION ..................................................................................................................................... 6
1.1

PROJECT OVERVIEW...................................................................................................................... 6

1.2

AIMS AND OBJECTIVES.................................................................................................................. 8

GAME DIFFICULTY IN LITERATURE ........................................................................................................ 9


2.1

FLOW ........................................................................................................................................... 10

CONDITIONS OF FLOW ........................................................................................................................ 11


2.2

DYNAMIC DIFFICULTY ADJUSTMENT (DDA) ................................................................................ 14

THE MATTHEW EFFECTS ..................................................................................................................... 15


2.3

PLAYER MODELLING.................................................................................................................... 15

2.4

DYNAMIC GAME ELEMENTS ....................................................................................................... 17

2.4.1

ENEMY SPEED...................................................................................................................... 18

2.4.2

ENEMY HEALTH ................................................................................................................... 18

2.4.3

ENEMIE SPAWN FREQUENCY .............................................................................................. 19

2.4.4

FREQUENCY OF POWERUPS ................................................................................................ 19

2.4.5

POWER OF PLAYER .............................................................................................................. 19

2.4.6

POWER OF ENEMIES ........................................................................................................... 20

2.4.7

DURATION OF GAMEPLAY EXPERIENCE .............................................................................. 20

2.5

THE BALANCE OF DIFFICULTIES................................................................................................... 20

ALIEN: ISOLATION ............................................................................................................................... 21


3

ANALYSIS OF EXISTING DDA SYSTEMS IN GAMES ............................................................................... 22


3.1

MARIO KART................................................................................................................................ 22

3.2

RESIDENT EVIL 5 .......................................................................................................................... 23

3.3

LEFT 4 DEAD ................................................................................................................................ 23

3.4

FALLOUT 3 ................................................................................................................................... 24

DEVELOPMENT TOOLS AND METHODOLOGIES .................................................................................. 26


4.1

PROJECT MANAGEMENT............................................................................................................. 26

4.2

UNITY 3D ..................................................................................................................................... 27

4.2.1

2D Engine ............................................................................................................................ 28

4.2.2

Physics Engine ..................................................................................................................... 28

4.2.3

CONCLUSION ....................................................................................................................... 31
Page 4 of 64

Jamie Parish
5

000730301

DESIGNING THE DDA SYSTEM ............................................................................................................. 32


5.1

VIDEO GAME ............................................................................................................................... 32

5.2

PLAYER MODEL ........................................................................................................................... 35

5.3

DYNAMIC DIFFICULTY ADJUSTMENT SYSTEM ............................................................................ 36

DEVELOPMENT.................................................................................................................................... 38
6.1

ABOUT THE GAME....................................................................................................................... 38

6.2

THE DDA SYSTEM ........................................................................................................................ 40

TESTING AND EVALUATION ................................................................................................................ 44


7.1

TESTING THE DDA SYSTEM.......................................................................................................... 44

7.1.1

DATA RECORDING ............................................................................................................... 46

7.1.2

EXPERIMENTAL RESULTS AND ANALYSIS ............................................................................ 50

7.2

EVALUATION ............................................................................................................................... 53

7.2.1

DEVELOPMENT PROCESS .................................................................................................... 53

7.2.2

PROJECT EVALUATION ........................................................................................................ 54

7.2.3

PERSONAL EVALUATION ..................................................................................................... 56

CONCLUSION ....................................................................................................................................... 57

BIBLIOGRAPHY .................................................................................................................................... 60

Page 5 of 64

Jamie Parish

000730301

1 INTRODUCTION

1.1 PROJECT OVERVIEW


This project will research how Artificial Intelligence (AI) decisions in games can be manipulated
to make adaptive decisions based on a players actions - to make it have options that could turn
the tide in an abnormal situation that a player would see themselves in. For example, if a player
is a higher level than the enemy, the system will adapt its situation and try to even-out the
experience by making specific decisions based on the players performance.This research
investigates what brings a player closer to the character and game in terms of enjoyment and
Flow, and how a game keeps that flow at which keeps the player focused on the game
objective. Also how a game brings out that sense of achievement by adjusting its game difficulty
based on player performances. By researching into dynamic difficulties, this project will show
how previous games have balanced out their difficulty to keep their players happy. Findings can
help show how the enemy can surprise the player by taking actions that the player might not
anticipate.
Psychologist Mihaly Csikszentmihalyis research and his Flow model will be discussed
throughout the report. Flow is an euphoric state of concentration and complete involvement
(Csikszentmihalyi, 1990). To achieve an optimal experience such as Flow, a balance would be
required between the challenges set in that specific situation of the game and the set of skills a
player brings to tackle them. A challenge includes any opportunity for action that humans are
able to respond to (Csikszentmihalyi 1988a).
Page 6 of 64

Jamie Parish

000730301

There are specific techniques used in previous games that deal with their difficulty setting and
this project will find out what has worked and what hasnt and why, how their techniques have
been used to make this experience work in terms of how it deals with monitoring the players
performance.
AI has been around in almost all games but not all AI has been regarded as intelligent. Reasons
for this could have been due to the lack of resources the gaming area had at the time. More
particularly, early gaming technology was comparatively limited by todays standards, in terms
of computer specification and software used to program sophisticated AI and gameplay
techniques. Or when applied to the subject of this paper, the lack of usage of Flow within those
games contributes to the lack of regard for early AI. This project will look into specifically what
Flow is, how it can be used within games, conditions and characteristics of Flow.
This project will research deeper into player models and how games that use Dynamic Difficulty
Adjustment (DDA) systems monitor player performances based on the readings from the model
- by discovering how they have used their own system to make decisions following the player
model.

Page 7 of 64

Jamie Parish

000730301

1.2 AIMS AND OBJECTIVES


There were many aims to this project which was derived from research found from gaming immersion
which led into Flow and then into Dynamic Difficulty Adjustment (DDA). This is the main focus of the
project, to research dynamic difficulty within games and how various techniques have been used to
influence the gaming experience in terms of the game type and how game difficulty Is balanced with
maintaining a games Flow.
Many aims were expanded and refined through further research to help narrow the focus of this
project. Objectives were then created from the aims researched, to then meeting an overall aim of the
project which was to implement a dynamic difficulty adjustment prototype set to monitor the player
model created for this game.
The following are a set of objectives for this project to measure whether or not progress towards the
main aim has been achieved:
1. To investigate dynamic difficulty adjustment systems within other games and how they have
kept to Flow with their game decisions and to find out how they have solved the problem of
creating a challenging experience whilst keeping to the Flow.
2. To investigate other techniques that could be used to help monitor a players performance
which would then lead onto developing a more stable Dynamic Difficulty Adjustment system
3. To develop a prototype from techniques investigated, that monitors a players performance to
create a non-repetitive, all surprising gameplay experience.
4. To evaluate the prototype

Page 8 of 64

Jamie Parish

000730301

2 GAME DIFFICULTY IN LITERATURE

Players want the AI to surprise them, to try to defeat them in ways that they had not
anticipated - (Rouse III 2010)

The point in video games is to entertain - (Adams 2010)

The field of AI has grown enormously to the extent that tracking proliferation of studies
becomes a difficult task - (Ambite, J. L. and Knoblock 2001), (Oke 2008)

Page 9 of 64

Jamie Parish

000730301

When playing video games, the interaction between player and game has centered on
'enjoyment' according to (Cowley et al. 2008) and The point in video games is to entertain
according to (Adams 2010). When a player has enjoyment, he/she tends to keep playing, but
when such obstacles arise such as a very hard boss, what keeps that sense of enjoyment
flowing? Some players will be persistent and wont rest until that obstacle is gone.
When engaging with an enemy, if the player is at a higher level he/she will tend to not consider
more effective attacks due to their attack level being higher than the opponent. They will just
use any attacks to defeat the enemy in order to quickly progress within the game.
A system would therefore be created to handle how difficult the game would be depending on
the game idea. For example, Left 4 Dead uses an Artificial Intelligence system called AI Director,
and this system modifies the density and ferociousness of the zombie horde in response to the
user's performance (Mark.J.P.Wolf 2012). This is known as a Dynamic Difficulty Adjustment
(DDA) system, allowing a variation of the games difficulty depending on the players
performance. For example, if the player is finding the games challenge to be below their
current skillset and breezing their way through quickly, the AI Director would make a decision
spawn a trickier opponent such as a Tank, thereby increasing difficulty and giving the player a
challenge, thus maintaining Flow.

2.1 FLOW
As mentioned in the literature review The point in video games is to entertain (Adams 2010).
And gaming Flow is the state in which people are so involved in an activity that nothing else

Page 10 of 64

Jamie Parish

000730301

seems to matter, the experience itself is so enjoyable that people will do it even at great cost,
for the sake of doing it(Csikszentmihalyi 1990). Players desire a worthy challenge that the
game sets for them. If the challenges are insufficient for the perspective we bring, we feel
frustrated, switched off, and eventually anxious, hesitant and low on
confidence(Csikszentmihalyi 1988a). By using Flow, the games challenges can be kept
balanced by increasing the difficulty at times at when players feel the games challenge level is
below their current skill level, and decreasing when the game becomes too challenging. You
know that what you need to do is possible to do, even though difficult, and sense of time
disappears. You forget yourself. You feel part of something larger (Csikszentmihalyi 1988b).

CONDITIONS OF FLOW
There are several conditions that a game would have met if conquered and for Flow to be
achieved. Some conditions could be found in the games tasks (Ma et al. 2011), consisting of:
1. A balance between the challenges set by the game objective and the skills that the
player would employ to tackle them.
2. Immediate feedback for the player as to how well they are progressing.
3. Having clear sense of what has to be done moment by moment.
Mihaly Csikszentmihalyi, more recently has suggested these three element are best understood
as conditions for achieving flow, whereas other elements would compromise Flow. Although
these have been focused more on individual activities, the theory is compatible with social
experiences.
Page 11 of 64

Jamie Parish

000730301

The Flow model (see figure 1) that Csikszentmihalyi published illustrates different states of a
game based on research and findings. If the challenge level and players ability has no
correlation to meet that challenge then it will be much harder for Flow to be achieved.

Figure 1: Csikszentmihalyis Flow model (Jacobsen 2013)


D Jacobsen states in Happiness, Flow, & Better Leadership coupled with mastery, [it] is often the

staging point for entering a state of flow. He describes five best ways to encourage gaming
flow:
1. Set goals that have clear and immediate feedback
2. Become immersed and focused on a particular activity
3. Pay attention to what is happening in the moment
4. Learn to enjoy immediate experience
5. Proportion the skills to the challenge at hand

Page 12 of 64

Jamie Parish

000730301

Csikszentmihalyi also further explains the so-called dimensions (Wentzel & Brophy 2014) and
has come up with eight characteristics:
1. The activity has to have clear goals and that provides immediate feedback about the
effectiveness of the players responses
2. Merging of action and awareness
3. Focused concentration on the task at hand
4. The frequent opportunities for the player to act upon that are matched by the players
perceived ability to do so effectively, which basically means the players personal skills
are well suited to the activitys challenges
5. A sense of potential control
6. Loss of self-consciousness
7. Altered sense of time
8. Autotelic or self-rewarding experiences which basically means that the activity becomes
worthy of completing for its own sake.
All of these characteristics can be used to help make the perfect game. However, some games
tend not to use flow depending on the development team, the design process, and the type of
game thats been created.

Page 13 of 64

Jamie Parish

000730301

2.2 DYNAMIC DIFFICULTY ADJUSTMENT (DDA)


As stated in the literature review section Players want the AI to surprise them, to try to defeat
them in ways that they had not anticipated (Rouse III 2010), and by having a Dynamic Difficulty
Adjustment system enemies could then become surprising to the player. As previously
mentioned, the AI Director used to help monitor Left 4 Deads gameplay, as seen in figure 2
below, is an example of adapting the gameplay experience for the player so that every
playthrough would not be the same as the last because it uses feedback loops to adjust the
difficulty of play (Salen & Zimmerman 2004).

Figure 2: Passive Flow Adjustment model (Chen 2006)


Within a game there will be dynamic elements that could be changed and manipulated by a
DDA and by using a Dynamic Difficulty Adjustment system fed from the readings from the
player model, the system would be able to calculate how the player is finding the game in
terms of difficulty, how much the enemies are affecting the player and if they can keep up their
Page 14 of 64

Jamie Parish

000730301

tactics to complete their objective. An example could be having the DDA make enemies target a
players weaknesses more often or learn from the players repetitive choices. All of this needs
to balance difficulty in order to help the player, without telling them, and progress further
within the game. An example of discussing this theory of a players progression within a game is
called the Matthew Effect.

THE MATTHEW EFFECTS


"To him who hath been given much, more shalt be given." (Newheiser n.d.) As a player
progresses within a game they are more than likely to at least remain at the level they are at.
For example, if a player is controlling a level 50 character and it approaches an enemy at level
20, the player is likely to be able to withstand this enemys attack - thus maintaining a game
characters survival. This wouldnt be much of an example of balanced difficulty because it
would seem as if the game was not attempting to re-balance the gameplay, and this could lead
to the player being unchallenged, and this potential boredom means that Flow is not being
entered.

2.3 PLAYER MODELLING


A player model is the attributes of the player that the system monitors to make decisions
regardless of the game having dynamic difficulty or not. Challenge tailoring is the problem of
matching the difficulty of skill-based events over the course of a game to a specific players
abilities (E. Zook & O. Riedl 2012). For a game that does use a Dynamic Difficulty Adjustment
Page 15 of 64

Jamie Parish

000730301

system, it will study the player but monitor specific actions that the player makes. This could be
such elements as:
1. Player accuracy the amount of hits and misses the player has, for example shooting
bullets and missing. The system would calculate the players accuracy and make a
decision on the next area based on these readings.
2. Player aggression whether or not the player is aggressive in terms of if the player is
attempting to eliminate all enemies in the level. The system would make decisions
based on the difficulty the player is experiencing. For example, the AI could be
programmed along the lines of: If the player thinks he/she can destroy all enemies,
then Ill create tougher enemies.
3. Player curiosity some players could regard games as an exploration adventure, and
that could mean there are hidden treasures to be found. This could be in the form of
ammunition crates, loot boxes or even loose weapons. The system would read the
players movements and would monitor how often the player would go searching for
that treasure, by looking into how long the player has spent in that area, to actually
having triggers set up in specific places so that when they trigger it, it would add to the
calculation of if the player is trying to find something. It would then make decisions
based on those actions.
Every system and every game would have various player models to monitor as not everyone is
the same. By having a Dynamic Difficulty Adjustment (DDA) system, everyone that plays the
game will have a different and an exciting gameplay experience each time they play. (Zad et al.
2011)(Missura & Thomas 2009)
Page 16 of 64

Jamie Parish

000730301

To monitor a player model there will need to be a plan that makes adjustments based on the
flow of action and the player performance, as seen below in Figure 3.

Figure 3: Overview of adaptive game generation process. (Wiley 2014)


This model will circle in a loop and progresses in stages that begin by measuring the content
and players personality, behavior and experience as they play, and then adapts and creates
new elements such as events, adjustments in enemies or the flow of gameplay. (Browne et al.
2014)

2.4 DYNAMIC GAME ELEMENTS


When a game has dynamic elements, there are some that can be changed that could affect how
the game can be experienced in terms of Flow.

Page 17 of 64

Jamie Parish

000730301

2.4.1 ENEMY SPEED


With using Nintendos Mario Kart as an example, it has a DDA system that monitors the players
performance within the race. For example if the player was way out ahead of the other
opponents, the game would adjust the speed of the other opponents to make them catch up,
using Flow to balance out the difficulty of staying ahead (Fullerton 2014. p325). The speed of
the opponents will be determined by the specific characters statistics, but for situations when
the games DDA system monitors the players performance, it starts to manipulate the
opponents speed and luck according to the position the player is in.

2.4.2 ENEMY HEALTH


The health of enemies can be whatever the game chooses and not affect Flow depending on
the other dynamic elements and how much they affect the enemy. For example, if the enemy
has a high restriction for incoming attacks and its health is high, it might make an acceptable
challenge for the player, but if another element such as enemy attack power and speed has
increased also, then there will be a difficulty imbalance. If one element is high, then there
should be something that imposes a weakness. For example, if the enemy health high, with
strong attack power and tough defence, its movement speed should be lowered so that the
player can jockey around the enemy waiting for a chance to strike. This will keep the games
difficulty balanced and increase the likelihood of Flow.

Page 18 of 64

Jamie Parish

000730301

2.4.3 ENEMIE SPAWN FREQUENCY


Using Left 4 Dead as an example, the frequency of enemy spawning is one of the key factors
that the AI Director deals with as it has to decide, based on the players performance whether
or not to increase or decrease the enemy frequency. This again would be designed around Flow
and to make sure there is a balance with the difficulty (Fairclough & Gilleade 2014).

2.4.4 FREQUENCY OF POWERUPS


When having powerups in games there would need to be something that falls back onto the
player, otherwise with great power comes the sense of boredom after a while of playing
without being challenged, which is why a DDA would be useful because it will make decisions
and adjustments based on the games difficulty. An example of this would be to let the player
have a power up and after a time increase the difficulty slightly by increasing the frequency of
enemies or increasing the enemys health. This would make the player feel like they have
power and control, thereby disguising the difficulty adjustment that has been designed to
balance out the gameplay.

2.4.5 POWER OF PLAYER


The same for the frequency of powerups. If the players power/skill level is higher than the
enemy, there will be a sense of being unchallenged and players will breeze past an enemy
without taking much notice. Uses of a Dynamic Difficulty Adjustment system could be useful
here to bring something back for weaker enemies, for example increasing the frequency of
enemies to attack the player. This will make the player focus as they will have a lot more to do.

Page 19 of 64

Jamie Parish

000730301

An example of a game that uses this is Fallout 3, as it uses a system to replace old enemies with
newer, stronger ones if the players skill increases to a point, to retain constant difficulty.
(Burke 2012)

2.4.6 POWER OF ENEMIES


The power of enemies in a Dynamic Difficulty Adjustment (DDA) system would be determined
on the readings of the specific player model. For example if the players weapon choice or
current abilities were either too low or of a poor quality, it would adapt the systems decision to
help match difficulty with the player, thereby maintaining the flow by keeping the challenge
and skill rate at its best.

2.4.7 DURATION OF GAMEPLAY EXPERIENCE


The duration of the gameplay experience could be set depending on the difficulty. If the games
challenge level was too high and the player could not advance through that specific area
because of a very challenging enemy, it could decrease the likelihood of Flow. There are many
ways to make the duration of the gameplay experience fun, some elements as previously
mentioned could be adjusted to help increase the likelihood of Flow.

2.5 THE BALANCE OF DIFFICULTIES


Video Games are boring when they are too easy and frustrating when they are too hard
according to (Hunicke & Chapman 2003). If a games challenge level is below the players

Page 20 of 64

Jamie Parish

000730301

current skill level, the player at times will not find that sense of accomplishment, which is why
most games introduce a difficulty selection to give the player a choice if they want to just
experience what happens within the story or if they want to make their gameplay experience
last and feel fully immersed into the environment and gameplay by playing at the hardest level.
Dark Souls 1 and 2 for example have a slightly different approach as they do not offer a
difficulty selection. The enemy levels are set within their own specific environment and if the
player chooses to venture forward into those areas, they had better be ready.

ALIEN: ISOLATION
Another example that expresses difficulty is the game Alien: Isolation. It was originally
defaulted to the hardest difficulty meaning that by playing at the hardest difficulty, the player
would have a much more realistic approach to the gameplay and the environment that they
have been placed in. (Dingman 2014). The player has been put into an environment where it is
just him (the character) and the alien. By playing on the hardest difficulty the players get
realistic reactions from the alien and an overall realistic gameplay experience. This will then
connect the player more to the environment, as from time to time the player will have to hide
at some point, such as in locker or under a desk, making the player feel more connected with
the character as they wait for that brief opening to a safe area.
These types of enemies would have some constraints, otherwise by giving the AI too much
control of the environment for example, it would lead to an unfair situation depending on the
type of player playing. As in Alien: Isolation the alien will roam the corridors and areas that the
gaming character would be in. There will be times that the alien would jump up into the vents

Page 21 of 64

Jamie Parish

000730301

and this would give the player a brief moment of opportunity for an action to be made which
would balance out the games difficulty.
(Lecky-Thompson 2008)

3 ANALYSIS OF EXISTING DDA SYSTEMS IN GAMES


Although many games have a Dynamic Difficulty Adjustment system configured to control their
difficulty, each will have been uniquely designed but all will equally attempt to balance out the
games difficulty by using different techniques.
This section will look at the difference between four DDAs systems that were designed to
address the genre specific issues within their respective games.

3.1 MARIO KART


Mario Kart 64 (1996) is a go-kart racing game developed and published by Nintendo for the
Nintendo 64 video game console. To extend from the dynamic elements section and from the
speed of enemies, Mario kart has a self-balancing mechanism that activates when the race
starts. It makes the other opponents (other cars) accelerate up to their maximum speed which
would be slightly lower than the players maximum speed achieved by the players chosen
character. The maximum speed of the other opponents is maintained only if the player is
leading the race, but if the player crashes, the speed of the other opponent decreases to a

Page 22 of 64

Jamie Parish

000730301

point so that the player can catch up. This will bring a balance to the difficulty as it helps the
player but lightly to give it a fair match. (Fullerton 2014. p325)

3.2 RESIDENT EVIL 5


Resident Evil 5 (2009), known in Japan as Biohazard 5, is a third-person shooter video game
developed and published by Capcom. Resident Evil 5 had a system in place called the Difficulty
Scale, which is unknown to most players, that bases the players performance on a grade scale
from 1 10 and then makes decisions on adjusting both the enemys behavior/attacks and
enemy damage/resistance. This system will monitor the players death rate, critical attacks etc.
The selected difficulty would lock players to a specific number, for example if the player chose
to play the game on normal difficulty, the number would be locked to grade 4 but then
adjusted to grade 2 if the player was playing poorly and 7 if playing well. The grades between
difficulties can overlap depending on the performance. (Burke 2012)

3.3 LEFT 4 DEAD


Left 4 Dead (2008) is a cooperative first-person shooter video game with survival horror
elements, developed by Turtle Rock Studios and Valve Corporation. Left 4 Deads AI Director is
an artificial intelligence that dynamically adjusts the challenge posed by the game in response
to the players performance (Fairclough & Gilleade 2014. p34). This AI deals with balancing the
difficulty of the game, for example if the group is having a hard time, its less than likely that it
will make a Tank spawn, an enemy that changes the difficulty a lot. An excellent example of
the use of Flow is if the game becomes hard it turns the difficulty dial down to a manageable
Page 23 of 64

Jamie Parish

000730301

level in order to guide the players through without them being aware of being assisted, and
then increasing the difficulty when the group of characters starts being unchallenged, thereby
maintaining a gamers attention and focus.
The DDA system in L4D gives the game a high replayability factor. It allows players to play the
same scenario and same maps over and over again with new experiences each time round.

3.4 FALLOUT 3
Fallout 3 (2008) is a post-apocalyptic, sci-fi, action role-playing open world video game
developed by Bethesda Game Studios, the third major installment in the Fallout series. Its
system uses player level to determine what kind of enemies to spawn. The more the player
levels up, the harder the types of enemies generated become (i.e. enemies with higher and
higher statistics and better weapons) (Burke 2012). This game uses an in game slider that
adjusts the rate at which the decision is made, which also gives a bonus experience to players
using a harder difficulty setting. This means that better players not only get a challenge but also
get rewarded which can make them level up faster.
Csikszentmihalyi has broke up sections of the flow chart to show the stage of the players state
of mind and each of these games have used their DDA systems to adapt the experience of the player to
try and balance out the difficulty but each have their own way of producing this method. Mario Kart had
only one difficulty which adapted the difficulty based on the players position. If the player starts losing
and they are finding the game difficult, the game would start throwing bonus items to get the player
back in front, thus entering the flow state.

Page 24 of 64

Jamie Parish

000730301

Resident Evil 5s difficulty will be decided on the difficulty setting chose by the player. And if the player
would find it difficult, the DDA system would try to rebalance the difficulty with the range value set on
their choice. As this tries to help the player through but not too much, it maintains a fine line and guides
the player towards Flow.
Left 4 Dead is pretty much the same as Resident Evil 5 in how it handles the DDA system after choosing
the difficulty setting but it doesnt make changes based on the difficulty value. It judges the players
performances through the level and makes a decision to increase or decrease the difficulty depending
on the performance. This chooses the gameplay elements and makes changes to them such as enemy
frequency, weapon positions and the chance of spawning special/harder enemies. If the decision is that
the player is finding the game non challenging, then it makes a final calculation from the performance to
start increasing the difficulty, which would push the player back towards the Flow state.
Fallout 3s DDA system makes a decision based on the players current level to decide on what type of
enemies the player has to deal with. This makes the player feel like they are powerful and in control, but
then the game rebalances the difficulty so the player has a greater challenges every time. This will keep
the player in Flow because its updating its difficulty consistently over time due to monitoring the
players current level.

Page 25 of 64

Jamie Parish

000730301

4 DEVELOPMENT TOOLS AND METHODOLOGIES


4.1 PROJECT MANAGEMENT
When creating a project it is necessary to have a project management model becausethis way
the project can be planned into different stages throughout the development process. As seen
in Figure 4 below, the initial planning of the project starts, and then onto researching the
requirements of the project, and if there are any specific tools that will be needed. Then to
analyse and design the project, to starting designing how it will look and play out, as well as
implementing any features such as gameplay. When all of these have been completed, then the
project will need to be tested as the developer will not want to release an unfinished product.
When testing has finished, the evaluation of the final product will be required to point out any
areas that could be addressed and re-furbished. If after the evaluation the project is ready, then
the developer will deploy the product onto whichever platform.

Figure 4: Project Management Flow Model (Lia Productions 2014)

Page 26 of 64

Jamie Parish

000730301

If after the evaluation there are any possible chances of improvements that could be
implemented, then the project will go back through the loop and replay the development
process as before.
This type of model will be used to help the development process of this project so that it can be
fully functional without any errors. Accordingly, the participants who want to play test this
project will be able to be fully immersed into the experience and will be able to give accurate
feedback on any improvements relating to the specific content researched and planned.

4.2 UNITY 3D
Unity is the preferred choice for small studios, indie developers, and those of us who have
always wanted to make our own game (Blackman 2011). Unity3D is a powerful cross-platform
3D engine that has a user friendly development interface. Unity3D is easy enough for beginners
and powerful enough for experts. This software is perfect for anyone who wants to create
simple and/or advance games/applications for mobile, desktop, the web, and consoles. The
features of Unity3D include a complete physics engine that supports real-time cloth simulation
and collision layers, a graphical rendering engine that can support 2D/3D textures and an
integrated development environment (IDE) (Bethell 2013).
The Dynamic Difficulty Adjustment (DDA) system prototype will be created using Unity3D and
the features within. There are many features included with Unity3D that can help with the
development of this project and the creation of the DDA system. The DDA system will need to
be programmed using different scripts that consist of the players statistics, and the source for

Page 27 of 64

Jamie Parish

000730301

the difficulty selection which will hold different conditions for each difficulty option. Each
difficulty condition will determine the outcome of the gameplay as it will each contain specific
elements that change dramatically depending on the players performance.

4.2.1 2D Engine
Unity3D have recently developed a fully functional built-in 2D engine due to many 2D games that have
been developed using the original 3D engine but manipulated to make the perspective 2D, such as
BattleHeart, Tumbledrop, Ski Safari, Bad Piggies, Year Walk. The 2D engine has its own features which
consist of:
1. A new Sprite type, with an editor that will the user to cut up the users sprites automatically
from one texture sheet which can lead them to be dragged in separately into either the scene or
the animation timeline.
2. An upgraded Animation window with Dopesheet style view and quicker parameter animation.
3. Integration with the Animator to easily create states for 2D animated characters which can
allow the user to create Booleans or triggers for when the animation can be played.
4. An integrated 2D physics engine with rigid bodies, colliders and joints.
These tools allow the development of 2D games to be less time consuming and more productive as
there are many shortcuts that can lead to faster results. (Goldstone 2013)

4.2.2 Physics Engine


As mentioned before, Unity3D has a number of built-in physics components as seen in Figure 5.
It handles physical simulations. By adjusting a few parameter settings, we can create an object
Page 28 of 64

Jamie Parish

000730301

that behaves in a realistic way (Rani 2014). By using scripts to control and manipulate physics,
we can give dynamics to static objects such as vehicles, machines and cloths.

Figure 5: Built-in Physics Components. (Rani 2014)

4.2.2.A Rigidbody
Rigidbodies allow the object to have its own gravity parameter as well as having the ability to
restrict the orientation easily by using the parameter setting. These will be useful for objects
that collide with each other and if any object wants to either jump or fall from a specific height,
it allows a realistic behavior. Having too many rigidbodies could cause a problem, especially for
mobile developments as there would be a lot of information that the specific platform would
need to keep updated with. (Rani 2014)

4.2.2.B Physic Materials


Different materials are used for different object types. When the collisions interact with another object,
its surface needs to simulate the properties of the physical material, for example a ball, when colliding

Page 29 of 64

Jamie Parish

000730301

with the floor, will need a bouncy physical material to create a realistic behavior. There are two types of
physical materials which are 3D and 2D

4.2.2.C Colliders
Colliders are one of the most important built-in components of Unity3D. A collider component
is used to define the shape for the physical collision(Rani 2014). Different shapes use different
shaped colliders and doesnt get rendered in game view. In 3D the following are the basic
colliders and can be created with a click of a button:
1. Box Colliders - these can be used to create collisions for buildings or any squared
shapes.
2. Sphere Colliders - a sphere collider would be used on objects such as balls or anything
that will roll across the surface.
3. Capsule Colliders - these can be used to create a basic shape around a character for
when playing a game and controlling a character in first person.
4. Mesh Colliders- these colliders are heavier in terms of computer rendering as it creates
a collider based on the shape of the object.

4.2.2.D Character Controllers


Character Controllers allow the user to control their character dynamically with basic already
set up controls such as its height and minimum move distance properties.

Page 30 of 64

Jamie Parish

000730301

4.2.2.E Joints
When a Rigidbody is attached to another object using joints, Unity provides different joints to
help the user in different scenarios. This will allow rigidbodies to be connected and
manipulated accordingly.

4.2.2.F Debugging
Unity3D provides many tools that can help with reliable performances. One of them is
debugging as it allows the user to write debug logs into their scripts, allowing the user to step
through the code and use breakpoints and inspect variables that have errors. This makes the
development less time consuming depending on how complex the scripts are. If errors show up
in the inspector and the user has no recollection of where the error could be, they can use the
dubbing tools to go through each part of their scripts and then find it easily. (Bethell 2013)

4.2.3 CONCLUSION
Unity is a straightforward cross-platform development kit that is suitable for developing a
unique and effective Dynamic Difficulty Adjustment (DDA) system as it is extremely useful and
accessible, being free to use and publish any game. There are advanced features but it requires
a Pro license, which is costly for each specific platform.
Overall the Dynamic Difficulty Adjustment will be implemented using scripts which hold the
player models variables that get calculated to place the player in specific states. These states
will affect the variables associated with the gameplay elements to make the prototype
appropriately easier or more difficult.

Page 31 of 64

Jamie Parish

000730301

5 DESIGNING THE DDA SYSTEM


To effectively create a DDA system, certain planning is in order. Such plans as mind maps that
can set out the logic of the system and what the DDA system will be recording. By planning out
the logic, this allows the results to be more accurate when recording data which will lead to a
more efficient difficulty adjustment. Also to effectively find the balance point of the difficulty
challenge level, the prototype will need to adapt the Flow method as this will achieve accurate
results.

5.1 VIDEO GAME


This Project has chosen the DDA system to be incorporated within a video game. The reason
behind this is that there is a wide variety of game players. This will show multiple, varied results
in terms of player performances which will eventually place all players in their most
comfortable situation with a DDA system in place.
The appropriate game genre chosen for this video game and the DDA system is a simple, top
down, role playing game. The decision on this game genre was made using Left 4 Dead as a
reference and even though the game is a 3D first person shooter, the idea of its types of
enemies seemed to fit the idea for this projects game and DDA system - because of the enemy
speed, enemy attack damage and boss spawns that can be adjusted in game. This genre
provides enough mechanics for a DDA system to be implemented effectively and player
performances can be recorded with the highest possible accuracy. This type of game also fits

Page 32 of 64

Jamie Parish

000730301

well with the project scope due its simplicity in art style and gameplay mechanics which doesnt
make it over ambitious.
The gameplay was designed with one goal in mind: for the player to reach the safe zone with
two types of enemies attempting to stop the player. One being the normal zombie and the
other as the zombie boss. The gameplay elements such as enemy speed, attack damage or
enemy frequency can be adjusted using the DDA system. The players character will start off
with a pistol, 100 percent life and 50 bullets for which they will need to have to eliminate any
opposing zombies. The zombies will have just one attack which will only happen if they are
colliding with the player and if they are colliding then the players health will start to decrease
to give the illusion of being bitten. There are checkpoints in the game that check the players
performances and these checkpoints are for position spawns when the player has lost all of
their health points.
The idea to make the game as simple as possible with short objectives allowed more focus to be
set on the DDA system. As the DDA system is the main focus, this had to be fully functional and
be as accurate as possible, otherwise the results recorded will not back-up the research found
in the earlier stages of this project. This will also not place the player accurately in Flow as often
as it should do, which can provide an inaccurate analysis of the method chosen for the
development of this DDA system. By having a fully functional DDA system it allows the game to
have a high replay ability factor.
The conditions for Flow were the main objectives for this product with the use of the DDA
system, but in order for the player to feel comfortable within the game, they need to enter

Page 33 of 64

Jamie Parish

000730301

Flow. This games connection with the Flow will be state three, which means if the player gets
pushed into this state, then no changes within the game are needed, which means the player is
currently happy with the games variable values and is both a challenge but fun at the same
time.

Page 34 of 64

Jamie Parish

000730301

5.2 PLAYER MODEL


Before the development of the game and the DDA system, as mentioned earlier in this report, planning
is needed and this comes with noting the key attributes for the DDA system to record from the player.
For this product, four variables have been chosen to be recorded:

Player Health Remaining

Bullets Remaining

Lives Remaining

Time Remaining

These values will be used to calculate the overall state value by adding them all up and dividing them by
how many variables there are, which in this case there are four variables. To make an accurate
calculation every variable total would start at 100, as if it were a percentage. For example:

Player Health Remaining = 85 out of 100

Bullets Remaining = 67 out of 100

Lives Remaining = 9(90) out of 100

Time Remaining = 70 out of 100

Adding together these values totals 312. This then would be divided by 4 to make an average of 78. This
would be the overall state value. Now the decision needs to be made to place the player into whichever
state 78 falls into. To determine this, a mind map is required to accurately display the logic in the
decision:

Page 35 of 64

Jamie Parish

000730301

Figure 6: State Mind Map


As can be seen in Figure 6, it checks the state value and places the player into that state to which a
decision can be made on what gameplay elements to affect. To successfully enter a state, the player has
to have been pushed into state three and then remain there. Even if the player has been there just for
two checkpoints, they have experienced a comfortable situation.

5.3 DYNAMIC DIFFICULTY ADJUSTMENT SYSTEM


Once the research into other existing DDA systems and requirements analysis had been completed, the
objectives for this products DDA system could be decided. This ensured the research found backed up
the logic for this DDA system and can then carry out the remaining steps of this process.

Page 36 of 64

Jamie Parish

000730301

The DDA system will check the players performance at every checkpoint so that it can make necessary
changes to the game for each checkpoint. This means that the DDA system needs to be fully functional
in terms of making the correct decisions at the correct time, making sure that if the amount of enemies
needs to be adapted, then it would need to be done at that specific point. Otherwise the player would
play through the next checkpoint without any changes which could affect the possibility of entering a
Flow state. The DDA system would not need to continuously keep checking the game statistics but when
it does, it must count, which means all variables must be recorded properly.
If any gameplay elements needs to be changed to influence the difficulty of the game, the DDA system
needs to be able to do that. The system should be able to take the chosen variables and have them
stored and ready to be checked at each checkpoint. Then based on the players performance, the
elements would then need to adapt to the correct state the player is in.

Figure 7: DDA System Diagram


The basic structure of a DDA system for this prototype, as in Figure 7, would allow the gameplay with its
default settings and logic and then when the player reaches the checkpoint/check state. The DDA
system then activates and checks the player model variables against their original value; checks the

Page 37 of 64

Jamie Parish

000730301

performance by calculating the state value as mentioned earlier in this report; analyses the result;
places the player into the correct state with the correct gameplay element changes; applies the adjusted
experience to the player; continues from checkpoint and repeat at every checkpoint. This allows the
game to be adjusted so that the player can have a different experience each play through and will push
the player into their most comfortable situation and enter the flow state.

6 DEVELOPMENT
After the initial research and planning had been completed and is ready for the testing phases, then
became the start of development which involves setting up the scenes environment, enemy AI and
player. Prefabs have been set up to handle the overall settings and variables for each object type.
Prefabs are the template for any object that uses it as an instance and any changes to that prefab,
automatically updates the rest of the game objects.

6.1 ABOUT THE GAME


Before implementing the DDA system into the game, a game had to first be ready and set-up. As the
game had only one goal it seemed easy to set-up, as the player would only need to have collided using
the colliders from Unitys 2D physics engine with the end trigger in the safe zone. Once collided with the
end trigger, it would restart the game but with updated gameplay elements due the changes the DDA
system has made, which would then make the game have a high replay factor.
A game has been developed as it allows for the implementation of a DDA system as a proof-of-concept.
With a game, comes aims, objectives and challenges. The results of a player performance can be
calculated by the list of conditions that a game has set, so a game was a suitable choice for this
prototype DDA system to be implemented.
Page 38 of 64

Jamie Parish

000730301

All assets were either royalty free images from the internet or hand-drawn in Adobe Photoshop. As the
game is only using 2D sprites, there was no need for any 3D models. The music and sound effects were
also taken from the internet but made custom through an 8-bit converter software called GXSCC, which
converts the original sound file to its custom output.
The whole prototype would be programmed using Unitys C# scripting language. The reason for this
choice is because of how effectively scripted events can be produced using C#. Although the same
events can be produced using Unitys JavaScript, certain functions would be less time consuming using
C#. By using C# it provides high maintenance for the elements of object-orientated programming that
would make the development be less time consuming.
The overall game mechanics were then developed from the scripts provided which made the base of the
product. At this stage such mechanics as AI behaviors and player controls were set so that the game was
playable. Next was to create the gameplay elements that get affect by the DDA system so they were
ready. These gameplay elements that would be affected consisted of:

Enemy Frequency

Enemy Attack Damage

Enemy Speed

Resource Frequency (Ammo and Health Packs)

Boss Frequency

All of these gameplay elements would be adjusted accurately from decision made from the DDA system.
If these changes werent accurate then the player would lose the chance of entering the flow state.
The final stages of development are split into two sections. The first would be to go over the games
mechanics and check each condition was met with every event. Make sure each checkpoint would be
triggered; the enemies would attack the player; the player to lose health on contact with the enemy; the
Page 39 of 64

Jamie Parish

000730301

restart the game when they finish and to make sure that the player controls were player friendly with no
confusion, otherwise the player might focus their attention more on the control rather the game itself.
The game would then be checked to make sure there were enough mechanics for the DDA system to be
implemented.
The second would be to make sure the product was presentable and easily playable. A basic layout for
the GUI was developed to help the player see their statistics such as a health and how many bullets
remained and which weapon was in use. Having confusing information on the screen could leave the
player unsure and would focus attention more on elements that are not the gameplay.

6.2 THE DDA SYSTEM


After the game had been developed and amendments had been made, the DDA system was finally able
to be implemented and the game was ready to have its gameplay elements adapted. By using the
diagram in Figure 7 it made it easier to keep track of the flow of the game.
Using checkpoints in the game made it easier to break down the game into sections. By having these
sections it allowed a simple state check to be used that would check the players performance from the
readings of the player model. This would give the player their freedom to play and move around the
environment with the updated gameplay elements, with no changes being constantly made every
frame. A choice was made from deciding how to make these state checks as effective as possible in
terms of returning more accurate results. If the state checks were made to check the player at every
frame, this would be ineffective due to the player not making any sort of progression. By using these
checkpoints to make the state checks, allows the player to make some progression and then have a
more effective analysis, to which will then provide more accurate changes to the game.

Page 40 of 64

Jamie Parish

000730301

The state checks will calculate the average state value from the player model and will place the player
into a specific state from 1-5 as mentioned earlier in this report. Each state will have a list of changes
that will be made as seen in Figure 6. The lower the state the harder the game will become in terms of
the gameplay element changes being applied, and vice versa for the higher state numbers except state
three. State three will be used as the Flow state which does not make any changes the game. This
means the player is happy with the games current elements. As Flow is the target for the player, making
these state checks is crucial and has to be made correctly.
Now that the DDA system is fully functional and makes the changes that accurately adapt the games
difficulty, then comes the next stage of the development which is to get participants to play and test the
game and see whether or not they enter Flow. This will allow the results to pinpoint each checkpoint to
ascertain if certain areas are either too challenging or the challenge level is below the players skill level,
and to see if the DDA system has accurately made the games difficulty correct in terms of the changes
made to the gameplay elements. Below are a few example of how the scripts work and how they handle
the conditions:

Figure 8: Checkpoint Trigger Condition


Page 41 of 64

Jamie Parish

000730301

From what is shown in Figure 8, the condition set is, if the players collider collides with the checkpoint
collider using Unitys physics engine, make the conditions inside proceed. So in this example theres
another condition on the playermodel script that if met, set that process to complete a function, which
in this case is to calculate the players performance. Also as shown in Figure 8, it shows that in the
playermodel script it has another function called SendToDatabase. This sends the variables set in this
game to the database so that they can be later used in Excel to produce visual results.

Figure 9: List of variables set for the DDA prototype

Page 42 of 64

Jamie Parish

000730301

As shown in Figure 9 these are the list of variables that the DDA prototype will register and make
changes accordingly. There are five states that the player will be placed into and each five states will be
divided up between values from 0-100, calculated by the StateValue as shown in Figure 10 below.
Each variable that makes up the state value starts off at 100, so that they can be calculated by a
percentage to obtain accurate results.

Figure 10: State Conditions

Page 43 of 64

Jamie Parish

000730301

7 TESTING AND EVALUATION


At this point in the investigation, there has to be an effective method that is a suitable fit for a
DDA system to be implemented in order to achieve accurate results.

7.1 TESTING THE DDA SYSTEM


This project could be tested with an environment set around an A B game type where the
player needs to escape. This will have a system that judges the players play time as well as
received damage to then judge the spawn rate of specific enemies that would attack the player,
as well as the spawn rate a boss would appear that could be added towards the end. The
further the player progresses towards the end, depending on the time it has taken them, the
spawn amount of the enemies could increase or decrease accordingly. If the player reaches the
end point quickly with no trouble, the spawn rate of a boss will be much higher but if the player
has a hard time and loses a lot of his life, then the rate will be a lot lower.
By asking people to play this test and to record their reactions and overall opinions on such
elements this project could find results in how difficult it was, was it worth it? Did they feel
immersed into the area of action and series of events that affected the environment? What did
they get out of it?
To explain further, from helping the player so that they can progress further without actually
telling them, this can be tested again with the use of a Dynamic Difficulty Adjustment system
but with another variable such as health rate. This would monitor how many times the player

Page 44 of 64

Jamie Parish

000730301

would die and the system will make decisions on whether or not to decrease the spawn
amount, to maybe decrease the enemies movements speed or attack power.
Another test that could be used within this project could use a Dynamic Difficulty Adjustment
system that focuses on controlling one AI that would adapt to the players performance. Each
would have specific statistics and hit points and both would have weaknesses and strengths
whether that be extra armor with gaps to allow the players weaknesses to be struck or maybe
create an options list that would have a set of skills, each with pros and cons. The AI enemys
statistics will be adjusted by the DDA to then be made to react accordingly as it will make
calculations on each attack phase to determine how much damage it can withstand to how
much damage it can produce. If say the player is dealing more damage, the enemy will start to
target the players weaknesses more and more, giving the player more of a fight and turning
the tables on the player.
A structure of Flow that this prototype could use would be to measure the players
performances with a state value, that is then calculated from the listed variables set, to then be
divided by how many variables that are recorded. Then by using states from 1-5 that affect the
games difficulty in specific ways can determine how difficult the prototype can become. By
making state three the Flow state when nothing changes, no alteration to the difficulty needs to
be made as the player is comfortable; and by having the prototypes, difficulty become harder
as the state number lowers and easier as the state number increases, and this should bounce
the player back and forth until they would reach the flow state automatically.

Page 45 of 64

Jamie Parish

000730301

7.1.1 DATA RECORDING


At this point a number of participants have been asked to play test the game to see if this DDA
prototype would effectively adjust the games difficulty and also to see if these players would enter the
Flow state whilst playing. Before getting the players to actually play test the game, the DDA system will
need a method of sending the data somewhere where it can be stored and later analysed. A web service
was set up for storing data and this takes the variables from this project and sends them to a database
which can then be analysed in an Excel spreadsheet using graphs to display the results. On the next page
are some examples of some of the participants performances.

Page 46 of 64

Jamie Parish

000730301

Figure 11: Participant 1s Gameplay Performance

Figure 12: Participant 2s Gameplay Performance

Figure 13: Participant 3s Gameplay Performance

Figure 14: Participant 4s Gameplay Performance


Page 47 of 64

Jamie Parish
000730301

Figure 15: All Participants Values Averaged and Future Prediction

Figure 16: Participant 1s State Prediction

Page 48 of 64

Jamie Parish

000730301

Figure 17: Participant 2s State Prediction

Figure 18: Participant 3s State Prediction

Figure 19: Participant 4s State Prediction


Page 49 of 64

Jamie Parish

000730301

7.1.2 EXPERIMENTAL RESULTS AND ANALYSIS


From looking at Figure 8, it shows that all participants state values average up into the Flow state. By
using these charts, it can also predict the average state value after 50 state checks, which shows that
this DDA system will rebalance the game to a point that is most comfortable for the player and has
made it more than likely for the player to enter Flow. From looking at these results it shows that the
games difficulty has been adjusted back and forth until the player is comfortable, and can be seen from
the State Prediction line, the game will reach a perfect game state.

Page 50 of 64

Jamie Parish
000730301
From looking at Figures 15-18 the results show that these participants will eventually enter the Flow
state more likely the longer they play, but looking at Figure 19 the results show that participant 4s state
value trend will stay within the Flow state boundaries up until the 50th state check.
To observe the predictions for the state value forecast a Logarithmic Trendline was used, using
Microsoft Excel. A Logarithmic Trendline is a best-fit curved line that is most useful when the rate of
change in the data increases or decreases quickly and then levels out. A logarithmic trendline can use
negative and/or positive values according to (Corporation, 2010). The Logarithmic Trendline takes the
data increased and decreased from the results and calculates the average throughout the range from
the data recorded at the beginning to the end and makes the forecast prediction from that range. A
Logarithmic Trendline equation assumes that data sheet has two named ranges: x and y and below is an
example of how it handles the data:

Figure 20: Logarithmic Trendline Equation

Figure 21: Trend Types (Chandoo 2011)

Page 51 of 64

Jamie Parish

000730301

As can be seen in Figure 21 these are the differences between the different trend types. Logarithmic
Trend takes the range of data and creates an average line from the equation of the increases and
decreases in the data recorded. This trend fit the recording from this DDA systems data flow.
If the players pattern of behavior stays the same, then this predicted forecast will be accurate. But as
the players skill level and the difficulty level change then the prediction is not accurate but merely an
indication that the dynamic difficulty adjustment is aiming to keep within the Flow state.
As shown in Figures 11 14 above, each player ends up in the Flow state or near enough, which are
successful gameplay tests. The results also show the average state value line which, as proven in the
results, the participant eventually if not always ends up in an average Flow state.
By using these charts, the project can easily identify the areas of difficulty. So for example, if the player
remains in state two for too long, then the results will show that the game needs to be made more
difficult, so then the DDA system can make a decision to make it harder and try to push the player back
into the Flow state, which is state three.

Page 52 of 64

Jamie Parish
000730301

7.2 EVALUATION
The final product designed and developed for this investigation will need an evaluation to help
summarise the research and project tests to see if the project meets the requirements and objectives of
this report.
The project is not expected to be subjectable to any serious legal, social or ethical issues, except there
was a short testing area where this project obtained a few participants within the University of
Greenwich and any local participants to test this projects short game. This required ethical and consent
forms to be filled out to make sure that any personal information can be used towards the progression
of this project.

7.2.1 DEVELOPMENT PROCESS


This project was able to start developing some of the key factors of the DDA system early due to the
planning of the logic that the DDA prototype was going to follow as shown in Figure 6. This diagram
made it possible to think how the games difficulty was going to be affected and by how much. This
project also successfully followed an incremental cyclic development model by using the diagrams in
Figures 1-4 as reference.
Throughout testing and modifying the DDA prototype, using the research as reference, this project was
able to be developed successfully from the start. By analysing previous games DDA systems to see how
they were used to manipulate their gameplay and how Player Models were analysed, the aim for this
project was clear, as the objectives were completed in quick succession, such as creating the variables
for the Player Model, setting up the scripts to handle those variables that affect the difficulty and letting

Page 53 of 64

Jamie Parish

000730301

the DDA prototype do the rest. Once those key factors were added, extra functionality was added to
create the gameplay.
By using the methods chosen for planning, using mind maps to lay out the logic of how the DDA
prototype will handle the games conditions allowed a smooth development process and allowed each
section of the development to be completed in order.
By using the diagrams in Figures 1-4 earlier in this report, the DDA logic was able to be kept stable in
terms of its flow design. By looking at the stages of the diagrams, it was clear to see how to structure the
stages of the games development. This allowed a fully functional DDA check for each of the games
checkpoints, which allowed the difficulty to be adjusted more and more accurately as player progressed
through the game. This was then proven in Figures 15-19 by using a Logarithmic Trendline to calculate
the predicted state value from the readings of the player.
Aspects of the game could have been made simpler in terms of the actual gameplay, meaning that
instead of having games genre set as a top down retro shooter, the game could have been a simple
game with basic controls such as left and right movement and to have the player shoot up-screen at
any opposing enemies. This would have reduced the usage of the physics which would allowed the game
to play smoother, reducing the risks of any glitches with collisions of triggers, which could also affect if
the game skips a state check.

7.2.2 PROJECT EVALUATION


The project goal was to successfully implement an effective DDA system to improve the players
experience by using Flow as a reference to help the player reach a comfortable state. The key factors
that needed to be implemented were the environment, gameplay, the DDA system and an end goal for
the player to reach.

Page 54 of 64

Jamie Parish

000730301

The environment is basic in terms of its design as it is inconsequential in regards to DDA which was the
focus. The design is a simple top down street with alleyways, but works well with the specific game

genre. By using streets and alleyways to help draw out a path to the safe zone, it allows each checkpoint
to be placed accurately within the game. Certain secret pathways were added to give the player a sense
of exploration, in which they could find hidden weapons, health or ammo packs, but by doing so it might
leave the player trapped between enemies, which could be crucial if their health and ammo count is
running low. This added to the games replay factor, which means every time they venture forth down
that specific path, a new experience arose. This was successfully made possible by having the DDA
system implemented. Replayability was important for this project because of time constraints, so by
making the game short but having the game have a different experience each playthrough, this allowed
the games development to be completed with extra time to focus on the DDA system to be successfully
implemented. If the game had be created for the players to play for around 4-5 hours, for example,
then the participants may have been bored or may not have had the time to take part in the tests.
Recordings were helpful and essential to the DDA system because it made it possible to analyse every
participants gameplay performances and pinpoint the more difficult sections of the game, and also
ascertain if certain areas were not being affected as much as they should. As mentioned previously, the
charts were chosen to give a visual representation of each participants results and find out their
average state value. This allowed the product to have an idea on how effective the DDA system has
adjusted the game difficulty.
Problems did occur with this DDA system but that was because of the scripts order of functions. An
example of one of the errors, was the placement of the player into a specific state. Because of the order
of the function was placed before the calculation of the state value, it would place the player in a state
and then the result from the state value would place the player in the correct state after the next
checkpoint. This led to the DDA system initially providing inaccurate results. These errors were
Page 55 of 64

Jamie Parish

000730301

overcome by readjusting the order functions to make certain actions work before others, it resolved the
problems and made the game make accurate changes. An example of a problem which disrupted the
DDA system was the placement of the player into the correct state. At times it would make the change
to the next upcoming checkpoint section instead of the checkpoint the player just hit.
One of key factors to the game is that there is no incentive for the player to try and achieve a high state
value and this because the game has no reward system. Key aspects such as showing the overall score
for their performance at the end of the game. This will give the player an incentive to try and beat their
score, which will make them play more, which also should increase their skill level, so then the
Logarithmic Trendlines prediction should change and the DDA system will update the games difficulty
to make it more balanced.
An interesting scenario for improving the DDA system, would be to try and increase the range of
changes made to each gameplay element variable that it makes in each state. This might quicken the
process of the player entering Flow.

7.2.3 PERSONAL EVALUATION


One of the reasons for the DDA systems success was how well time was allocated to focus of this
report. From planning to the start development, everything went according to plan with finding the
research and any earlier tests to the DDA prototype. There was a clear understanding of the focus once
the research had been found and how this prototype was going to be implemented within the product.
Every phase was carefully planned out and allowed a smooth development process.
New skills have been developed with programming, as certain elements of the game had to be
optimised and by doing so, the games performance improved and it allowed the game to be played
with no interference or glitches.

Page 56 of 64

Jamie Parish

000730301

There werent many complications that occurred with the product but if any did occur, then it was
probably due to the scripts not being labelled correctly, which made it difficult to locate certain
functions and when they were supposed to take action.
Overall this development process has been a fun and challenging experience. Even when errors did
occur, the feeling when those errors were put right added to the enthusiasm of the process, due to
ensuing progress being made in quick succession.

8 CONCLUSION
This projects objectives were to understand Flow and Dynamic Difficulty Adjustment system and to
then demonstrate an effective way of showing the research through the results shown in the prototype.
By looking at the results from the recordings of the participants gameplay performances, it is clear the
project was a success, as there is evidence that the research had been backed up by the results made
from the DDA prototype.
Initially, game difficulty was discussed to compare how other games prepare their difficulty for the
player, and through research, Flow was introduced and conducted research was found to find its
relation between the player and the game. A GameFlow model had been found that was developed by
Mihaly Csikszentmihalyi and his model gave the product a clear understanding on what it takes for the
player to enter the flow state.
After looking through all of the research of Flow, Dynamic Difficulty Adjustment systems were then
found. DDA systems affect the original games difficulty and adjusts the experience to help push the
player into the flow state automatically by calculating the Player Model. This made it possible for an

Page 57 of 64

Jamie Parish

000730301

accurate reading and an analysis to then be attached to the game to make it adjust how comfortable the
player is.
The games Player Model chose an appropriate attribute list that fits the games genre. This kept the
game simple but effective as such elements as Health and Bullets were the key factors to the game and
as the values were starting at 100. The DDA prototype disguised it as a percentage, so it found it easy to
track and make accurate calculations.
The overall aim was to find the balance of the difficulty by using Csikszentmihalyis Flow model and by
using a DDA system to keep track of the players performance. As can be seen by the results earlier in
this report, there is a rise and fall with the players state value but the longer they played, the range
between high and low eventually became smaller to a point where it will stay flat. And looking at the
results, it proves that the ending value for the players state value always ends up in the flow state.
This report can conclude by showing that there are important decisions to make when using a DDA
system because if the DDA system makes wrong decisions by the wrong calculations, it can disrupt the
player and could possibly ruin the gameplay experience. Not every game can use a DDA system, it
depends on chosen genre and the complexity of the game. The product chosen genre made it possible
for an effective DDA system to be implemented.
By choosing to have Flow, the target for the game design can be a difficult and challenging process, but
if achieved, it can be worthwhile - as shown throughout this report. To achieve Flow, distractions must
be eliminated by providing clear goals and instant feedback for the player. This will keep the players
attention at a high, but by having inconsistent gameplay, difficulty can adversely affect the players
experience. This aspect of games design is a thin line and it has to be made accurate in order to achieve
successful experiences.

Page 58 of 64

Jamie Parish

000730301

Overall this project has been a rewarding and challenging experience, as well as an opportunity to
further expand this knowledge onto a bigger experiment due to the skills learnt and research found. A
key element to the success of this project is project management because deadlines were met,
sometimes before the next stage of development was due to begin, leaving enough time for feedback
and suggested improvements that could be made to make this product look and feel more presentable.

Page 59 of 64

Jamie Parish

000730301

9 BIBLIOGRAPHY
Adams, E., 2010. Fundamentals of Game Design, New Riders. Available at:
http://books.google.com/books?id=-BCrex2U1XMC&pgis=1 [Accessed October 30, 2014].
Ambite, J. L. and Knoblock, C.A., 2001. JAIR. Journal of Artificial Intelligence Research, 15, pp.207261.
Available at: http://www.jair.org/ [Accessed October 30, 2014].
Bethell, J., 2013. An investigation into the effects of games design and development on player attention
and enjoyment, Available at: https://www.dropbox.com/s/a2e3g4dva6iznce/An investigation into
the effects of games design and development on player attention and focus.pdf?dl=0.
Blackman, S., 2011. Beginning 3D Game Development with Unity: All-in-one, multi-platform game
development, Apress. Available at: http://books.google.com/books?id=SI4f2fjGHTgC&pgis=1
[Accessed December 4, 2014].
Browne, C. et al., 2014. Toward the Adaptive Generation of Bespoke Game Content 17. In M. C.
Angelides & H. Agius, eds. Handbook of Digital Games. Hoboken, New Jersey, USA: Wiley-IEEE
Press, pp. 1761.
Burke, A., 2012. Using Player Profiling to Enhance Dynamic Difficulty Adjustment in Video Games viewcontent.cgi, San Luis Obispo. Available at:
http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1078&context=cpesp [Accessed
November 26, 2014].
Chandoo, 2011. Using Excel statistical functions for trend analysis. | Chandoo.org - Learn Microsoft Excel
Online. Available at: http://chandoo.org/wp/2011/01/26/trendlines-and-forecasting-in-excel-part2/ [Accessed March 17, 2015].
Chen, J., 2006. Welcome to Flow in Games. Available at:
http://www.jenovachen.com/flowingames/designfig.htm [Accessed December 4, 2014].
Corporation, I., 2010. Adding a Trendline to Your Chart. Designing Effective Projects, p.4. Available at:
http://www.intel.co.uk/content/dam/www/program/education/us/en/documents/projectdesign/track/track-spreadsheet-trendlines.pdf [Accessed March 17, 2015].
Cowley, B. et al., 2008. Toward an understanding of flow in video games. Computers in Entertainment,
6(2), p.1. Available at: http://dl.acm.org/ft_gateway.cfm?id=1371223&type=html [Accessed
October 27, 2014].
Csikszentmihalyi, M., 1988a. Fact Sheet - factsheet_flow_workshop.pdf. Flow, p.1. Available at:
http://www.bioss.co.za/pages/files/library/factsheet_flow_workshop.pdf [Accessed November 26,
2014].

Page 60 of 64

Jamie Parish

000730301

Csikszentmihalyi, M., 1990. Goodreads | Flow: The Psychology of Optimal Experience by Mihaly
Csikszentmihalyi Reviews, Discussion, Bookclubs, Lists, Harper Perennial. Available at:
https://www.goodreads.com/book/show/66354.Flow [Accessed November 26, 2014].
Csikszentmihalyi, M., 1988b. Mihaly Csikszentmihalyi | Speaker | TED.com. Flow, the secret to
happiness. Available at: http://www.ted.com/speakers/mihaly_csikszentmihalyi [Accessed
November 26, 2014].
Dingman, H., 2014. Alien Isolation hands-on: In space no one can hear you get frustrated | PCWorld.
Available at: http://www.pcworld.com/article/2464169/alien-isolation-hands-on-in-space-no-onecan-hear-you-get-frustrated.html [Accessed October 28, 2014].
E. Zook, A. & O. Riedl, M., 2012. A Temporal Data-Driven Player Model for Dynamic Difficulty Adjustment
- aiide12.pdf. A Temporal Data-Driven Player Model for Dynamic Difficulty Adjustment, p.6.
Available at: http://www.cc.gatech.edu/~riedl/pubs/aiide12.pdf [Accessed December 4, 2014].
Fairclough, S.H. & Gilleade, K., 2014. Advances in Physiological Computing, Springer Science & Business
Media. Available at: http://books.google.com/books?id=6Cm5BAAAQBAJ&pgis=1 [Accessed
November 26, 2014].
Fullerton, T., 2014. Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third
Edition, CRC Press. Available at: http://books.google.com/books?id=7nDvAgAAQBAJ&pgis=1
[Accessed November 26, 2014].
Goldstone, W., 2013. Unity Native 2D Tools Unity Blog. Unity Native 2D Tools. Available at:
http://blogs.unity3d.com/2013/08/28/unity-native-2d-tools/ [Accessed December 4, 2014].
Hunicke, R. & Chapman, V., 2003. AI for Dynamic Difficulty Adjustment in Games. In Challenges in Game
Artificial Intelligence AAAI Workshop. San Jose, pp. 9196.
Jacobsen, D., 2013. Happiness, Flow, & Better Leadership | Globoforce Blog. , p.1. Available at:
http://www.globoforce.com/gfblog/2013/happiness-flow-and-how-to-be-a-better-leader/
[Accessed November 26, 2014].
Lecky-Thompson, G.W., 2008. AI and Artificial Life in Video Games, Cengage Learning. Available at:
http://books.google.com/books?id=xagLAAAAQBAJ&pgis=1 [Accessed October 30, 2014].
Lia Productions, 2014. Concept to Fruition | Lia Productions 2014. Liapros Strategy Series. Available at:
http://www.liaproductions.com/2012/01/25/concept-to-fruition/ [Accessed December 4, 2014].
Ma, M., Oikonomou, A. & C.Jain, L., 2011. Serious Games and Edutainment Applications M. Ma, A.
Oikonomou, & L. C.Jain, eds., Springer Science & Business Media. Available at:
http://books.google.com/books?id=pTa-b_PRIWkC&pgis=1 [Accessed November 26, 2014].
Mark.J.P.Wolf, 2012. Encyclopedia of Video Games: The Culture, Technology, and Art of Gaming, ABCCLIO. Available at: http://books.google.com/books?id=deBFx7QAwsQC&pgis=1 [Accessed
November 25, 2014].
Page 61 of 64

Jamie Parish

000730301

Missura, O. & Thomas, G., 2009. Player Modeling for Intelligent Difficulty Adjustment J. Gama et al., eds.,
Berlin, Heidelberg: Springer Berlin Heidelberg. Available at:
http://www.springerlink.com/index/10.1007/978-3-642-04747-3 [Accessed December 4, 2014].
Newheiser, M., Strange Horizons Articles: Playing Fair: A Look at Competition in Gaming, by Mark
Newheiser. Available at: http://www.strangehorizons.com/2009/20090309/newheiser-a.shtml
[Accessed October 28, 2014].
Oke, S.A., 2008. A Literature Review on Artificial Intelligence. International Journal of Information and
Management Sciences, 19(4), pp.535570. Available at:
http://ijims.ms.tku.edu.tw/pdf/m19n41.pdf [Accessed October 30, 2014].
Rani, K.A., 2014. Learning Unity Physics, Packt Publishing Ltd. Available at:
http://books.google.com/books?id=7JQeBQAAQBAJ&pgis=1 [Accessed December 4, 2014].
Rouse III, R., 2010. Game Design: Theory and Practice, Second Edition, Jones & Bartlett Learning.
Available at: http://books.google.com/books?id=tGePP1Nu_P8C&pgis=1 [Accessed October 28,
2014].
Salen, K. & Zimmerman, E., 2004. Rules of Play: Game Design Fundamentals, MIT Press. Available at:
http://books.google.com/books?id=UM-xyczrZuQC&pgis=1 [Accessed November 25, 2014].
Wentzel, K.R. & Brophy, J.E., 2014. Motivating Students to Learn, Routledge. Available at:
http://books.google.com/books?id=wqnmAgAAQBAJ&pgis=1 [Accessed November 26, 2014].
Wiley, J., 2014. Handbook of Digital Games M. C. . Angelides & H. Agius, eds., Wiley. Available at:
http://books.google.com/books?id=4CLnAgAAQBAJ&pgis=1 [Accessed December 4, 2014].
Zad, D.D., Angelides, M.C.. & Agius, H., 2011. Personalise your massively multiplayer online game
(MMOG) with Artemis. Multimedia Systems, 18(1), pp.6994. Available at:
http://link.springer.com/10.1007/s00530-011-0237-x [Accessed December 4, 2014].

Page 62 of 64

Jamie Parish

000730301

CIS, Maths and CPDA REC approval of projects involving working with people - guidelines

A project involving a survey, questionnaire or interviews, which does not contain sensitive questions or
anything which might cause embarrassment or offence, or upset a participant, is likely to be approved
provided the following conditions are met:

Participants do not include children or vulnerable adults and all participants are capable of
granting informed consent. Signed consent is obtained from all participants. (In the case of a
questionnaire, completion of the questionnaire can be taken as consent, so long as the participant
has been given a consent form carrying the information below.)
Participants must be given an information sheet / consent form explaining the purpose of the
study, and indicating the degree for which the student is studying. It would be good practice to
offer to inform participants, on request, of the outcome of the study.

A sample consent form is attached. Those sections highlighted in yellow should be adjusted as
appropriate.

The Consent Form must be printed on university headed paper (it is the responsibility of the
project supervisor to arrange this with the School Office students must not have access to blank
headed paper). It should carry the university contact details of the student and of the supervisor the email address of the student, and the email address, postal address and phone number of the
supervisor. It should not contain private contact details.

The consent form must make clear that participation is entirely optional and refusal to participate,
or withdrawal at any stage, will not affect any subsequent dealings the participant might have
with the university (eg if the participants are students it must be made clear that their participation
or failure to participate cannot affect their marks, while if the participants were potential students
it must be clear that participation would have no effect on the processing of their application).

The consent form must tell the participant what will be done with any personal information, how
it will be held securely, and how long it will be held for.

No personal information should be included in the project report or in any other publication. All
personal information must be held securely, and wherever possible must be anonymised. All data
gathered should be destroyed on completion of the project.

Work by students involving children or vulnerable adults will always require approval from the
University Research Ethics Committee, with the following exception. Where the students work is
undertaken as part of the Undergraduate Ambassadors Scheme, under the supervision of the school in
which they are serving their placement, and evidence is supplied that the school has approved and will
supervise the project, approval can be granted by CIS, Maths and CPDA REC.

Page 63 of 64

Jamie Parish

000730301

(On University headed paper with departmental address)


Participant Information Sheet
Thank you for agreeing to participate in this study, which is being conducted by Jamie Parish, a student at
the University of Greenwich, as part of the project for their BSc Games Design and Development. The
project is supervised by Damon Daylamani-Zad
The Gameplay Recording:

As part of this study, you will be asked participate in a game play test to obtain your performance results
The purpose of the study is record your performance so that I can be used to help justify the projects
product techniques.
While you are under no obligation to answer any of the questions we would appreciate if you could provide
an answer to all of the questions if there were any to answer.
The entire process should take about 5-10 minutes of your time.
If at any time you wish to withdraw from the study, please inform the researcher and you will be free to
leave: no reasons need to be provided.
Your choice to participate or not in this study will have no effect on your studies at the University of
Greenwich (if participants are students or potential students).

What we will do with your answers:

The answers you provide will be analysed and the data will be stored.
We will keep the data for research purposes only. Some of the data we have gathered may be published as
part of the project report.
Your name and any personal details will not be published and it will not be possible for any reader of the
report to identify you.
All data gathered will be destroyed on completion of the project.

For further information about this study please contact:


Jamie Parish

Dr Damon Daylamani-Zad

Email: pj210@greenwich.ac.uk

Faculty of Architecture, Computing and Humanities


University of Greenwich,
Old Royal Naval College, London SE10 9LS
Tel: 020 8331 8665
Email: d.d.zad@gre.ac.uk

________________________________________________________________
I have read the consent form and agree to participate in the study by Jamie Parish. I understand that I am
free to withdraw at any time.

Signed

Date
Page 64 of 64