Task Difficulty, Mortality and Player Retention in Video Games: An Investigation into the Core Concepts of the Win/Lose Scenario and Their Effects on the Player
The difficulty setting is considered to be the single most influential contributor to the player experience in video games which give players the choice, as it can significantly affect the way in which the player interacts with their respective game, and how long their gameplay experience lasts. Most videogames, if not all of them contain difficulty settings in which the player is given a choice of how steep the coefficient of task difficulty they are playing against or with is going to be.
For some video games, it could be damaged based, for others it can manifest as a time stipulation, and for some few it changes the way that in-game obstacles or enemies work and operate entirely in order to give a more difficult yet realistic difficulty curve for the player.
This project will investigate the effectiveness of these difficulty systems with regards to gameplay, user progress, mortality and perceived frustration to the player – with the single goal of developing a difficulty system which can manipulate the game differently around its setting.
Abstract……………………………………………………………
Contents…………………………………………………………..
1 Introduction……………………………………………………..
1.1 Background…………………………………………………..
1.2 Overview of report………………………………………………
2 Literature Review………………………………………………….
2.1 Introduction………………………………………………….
2.2 Why and How We Play Games – Player Motivation and Frustration………………
2.3 Task Difficulty and Score………………………………………….
2.4 Mortality, Death and Progress Retention………………………………..
2.5 Key issues to use in the design and implementation…………………………
Review of Similar Products……………………………………………….
2.6 Introduction………………………………………………….
2.7 Ninja Gaiden Sigma (2007)………………………………………..
2.8 Metal Gear Solid Series (1998 – 2015)…………………………………
2.9 Dead Space 2 (2011)…………………………………………….
2.10 The Last of Us (2013)……………………………………………
2.11 LIMBO (2010)………………………………………………..
2.12 BioShock, Crackdown and Borderlands (2007, 2007, 2009)……………………
2.13 Key issues to use in the design and implementation…………………………
2.14 Conclusions………………………………………………….
3 Requirements Analysis………………………………………………
3.1 Analysis of Requirements………………………………………….
Design of Prototype(s)………………………………………………….
3.2 Basic Concept…………………………………………………
3.3 Working Limitations…………………………………………….
4 Development of Prototype…………………………………………….
4.1 Implementation………………………………………………..
4.2 Unforeseen Technical Problems……………………………………..
Explanation of Scripts…………………………………………………
4.3 Iterative Testing……………………………………………….
Legal, Social, Ethical, and Professional Issues…………………………………..
4.4 Copyright Issues……………………………………………….
4.5 Security Issues…………………………………………………
4.6 Offensiveness…………………………………………………
4.7 Potential Commercial Risks and Requirements……………………………
5 Evaluation………………………………………………………
5.1 Black Box Testing………………………………………………
5.2 User Testing and Questionnaire Results…………………………………
Personal Analysis and Critical Review………………………………………
5.3 Prototype 1 – Dynamic Difficulty via Enemy AI Variable Manipulation……………
5.4 Prototype 2 – Dynamic Difficulty via Mechanics and Environment Manipulation……..
6 Conclusion………………………………………………………
References………………………………………………………….
Appendix B – Original Project Schedule…………………………………..
Appendix C – Complete Scripts and Shots of Prototype…………………………
Appendix D – Scans of Calculations and Planning…………………………….
Appendix E – Survey Results………………………………………….
Task difficulty in video games is often associated with challenge for the player in the most part, with many games implementing a range of difficulties for the player to choose from. Task difficulty is tied to the win/lose scenario, as this is the main objective of difficulty in video games. The aim of this project will be to investigate the effectiveness of these difficulty systems, and analyse their assets and drawbacks in design regarding player retention and satisfaction, and how they relate, adapt to or handle the win/lose scenario. This can be extended to customer/player retention in many cases.
The purpose of this project will be to analyse multiple difficulty systems and though analysis arrive at a more elegant, adaptable and diverse system to handle gameplay difficulty.
This project will document the investigative processes used to gather information regarding task difficulty, progress retention and the win/lose scenario for the player in video games, demonstrating how each section is linked to one-another, and how this gathered information is subsequently used in order to create a final product or prototype that satisfies the initial goal.
Each research chapter will consider secondary research from published documentation, and the latter sections will be used to form a specification to develop the final prototype. A detailed analysis of the product requirements will be performed and documented, as well as an evolutionary product-creation cycle to document the development of the design. After this, the next session will be regarding the implementation of the product/prototype and elaboration of final changes performed after the development stage.
The final section of this report will be the evaluation and conclusion, critically reviewing the project, implementing previously declared evaluation techniques in order to assess the design, implementation, performance and results of the project as a whole.
In this research study, concepts such as death and loss will be analysed and contrasted with what video games teach the player about their respective rules of play and how value is assessed within them; this will further the understanding of why the player considers certain concepts such as progress in video games to be an important asset which needs to be protected, or why the player strives to succeed in video games when they pose no real-world gain or intrinsic value to them. This will also span into the winning side of the spectrum, and will aim at identifying what players find fun and worthwhile in video games to dedicate time towards playing them.
Multiple difficulty systems within video games will be compared and contrasted in order to produce a system that not only caters for players who play games with different ambitions/goals, but also identifies the underlying source of motivation for the player to play.
The main areas of research for this document will be the psychology of video games and their effect on the player, the addictive nature of video games, video game difficulty settings and how they affect gameplay, adaptive video game task difficulty, the psychology of value and threats, and how games are designed to accommodate, store and promote the collection of assets and progress within them.
The purpose of this literature review will be to conduct secondary research regarding video game concepts and themes, and build a specification through the findings of said research.
The Player Motivation and Task Difficulty section will discuss the effects of difficulty variance in video games, and their immediate and/or lasting effect on the player’s psyche and playing mentality. The conclusion of this research will be merged with other segments in order to create a synthesis between research chapters.
The Player Gameplay Preferences section will discuss the different gameplay styles that players are inclined to use or adopt when playing games; this includes but is not limited to playing mindset, game genres and their respective differences, as well as the density of players per genre.
The Mortality, Death and Progress Retention section will discuss the inherent characteristics of mortality in video games, how they affect player progress, and how the player would react to failing an objective multiple times; this also will be linked to research done by others regarding said themes, and their respective findings.
Kätsyri et al. (2013) conducted an experiment in which the player’s brain activity was recorded whilst playing against obviously apparent AI, and real players; the recordings of which were compared and contrasted to one another. Kätsyri et al. (2013) claim the results of their experiment indicated that the players enjoyed the game more so knowing that they were playing against a real person, as opposed to an AI, although there was still an indication of significant enjoyment from the latter.
This could be further elaborated upon to illustrate that the player has more fun when they are playing against someone who is real as opposed to artificially fashioned. This can be extended to claim that this is due to the fact that a human player is more skilled than an in-game enemy, and therefore the enjoyment of defeating them spans from the increase challenge. This being said, if the player was to believe the artificial intelligence was in fact a real person, through the placebo effect, they would enjoy the game equally as much as actually playing against a real person.
The theory of the Three R’s was created by Alan Deutschman’s desire to identify what makes people change, and the concepts that act as a catalyst for this change, be it incentive or threat. Deutschman states:
“My research shows that what really stimulates and sustains a change effort is getting positive results, really being able to feel tangible benefits from the change fairly early on.” (2007)
Deutschman indicates that in order to inflict a change, positive results must be yielded first.
Deutschman talks about and discussed a concept called The Three F’s; which he goes on to elaborate as “Fact”, “Fear” and “Force”. These Three F’s are described by him as catalysts of change currently used by many professionals, including psychologists, developers, managers and doctors in to get their patients or employees to change their work ethic, lifestyle and/or dietary habits, or to see something through to the end – motivation in a sense. He goes on to elaborate the fact that these ‘Three F’s’ do not work in the vast majority of circumstances and are “doomed to failure” as he puts it, and that a new system needed to be introduced – as he puts it – The Three R’s: which he describes as ‘Relate’, ‘Repeat’ and ‘Reframe’.
‘Relate’ refers to forming a relationship or consensus – in the case of a video game, this would be the relating aspect of explaining exposition and rules; if the player can understand what they have to do, they are relating to the game’s objective.
‘Repeat’ refers to practice, the fact that in order to understand something fully, the player must be given numerous attempts to understand, in an iterative process; this would be considered in the gamification sense as to play the game, or to try to complete said task or achieve a requirement.
‘Reframe’ essentially means to understand what you have done wrong, and to understand your shortcomings. This would mean to understand why or how you failed an objective and to give insight as to how to succeed instead. This could be the player themselves reframing their objective, or the game offering a hint or guide itself.
Gameplay “breakdown” is a terminology that (Iacovides, Cox, Mcandrew, Aczel, & Scanlon, 2015) use to refer to the disruption of the gameplay experience, or the point at which the momentum of perceived enjoyment is halted, due to the player’s failure to perform accordingly to the game. They go on to discuss that the most occurrent and known breakdowns in gameplay are when the player is “unsure about what to do or where to go.” They further their point by elaborating that boredom and specifically frustration are the most significant signs that engagement has broken down.
In contrast to this, they go on to discuss “player breakthroughs” as the event in which the player understands what needs to be done, or achieves their goal. This concept is similar to Deutschman’s concepts of the Three R’s, specifically coinciding with his term of Reframe, where the player understands what they have done wrong, and how to pass an objective.
According to (Orvis, Horn, & Belanich, 2008) there are four main potential forms/manifestations of game difficulty, or as they call them and subsequently referred to as “task difficulty”. They list them as the following:
• Static
• Increasing / forced adjustment
• Adaptive-low / learner-centred adaptive adjustment
• Adaptive-high / learner-centred adaptive adjustment
‘Force adjustment’ is described as a difficulty setting that increases in difficulty as the player progresses, regardless of their achievement or performance. This adjustment could be either linear or exponential/logarithmic in nature, depending on circumstances. This can be seen in numerous video games, where, as the player progresses, new and harder enemies are presented to them instead of the enemies they previously faced – this difficulty system is generally linked to linearly designed video games, and is often considered a fundamental cornerstone to classic game development, as primitive gaming hardware could only manifest difficulty in this form, since player telemetry recording and processing required too much RAM and processing power by gaming consoles at the time.
‘Learner-centred adaptive adjustment’ is where the game is adapted to become easier or harder based on the user’s current or accumulative performance. This system and its processing structure is usually hidden from the player and they are occasionally not informed that this process is happening in order to maintain immersion. This is often used in conjunction with Jenova Chen’s concept of Flow – to alter the gaming experience without informing the player it is happening in order to create immersion.
‘Static’ difficultly is considered the most widely used task difficulty methodology used, aside from forced adjustment, as it is essentially the easiest to implement for developers. Variables such as enemy damage or time limit are increased and reduced respectively in order to give the player the same experience but at a harder level. Static difficulty requires the game to either have one forced difficulty setting or multiple, and does not incorporate force adjustments. This difficulty type is commonly seen in games, where their main menus will offer the player a choice between ‘easy’, ‘normal’ and ‘hard’ settings. Whilst this difficulty setting is well known and used often in video games, the issue with this approach is that this system sometimes and often goes against the design and gameplay balance of the game.
Although in their readings and conclusion, (Orvis et al., 2008) describes how there is an insignificant difference in player performance between forced adjustment and learner-centred adaptive adjustments, they did find that forced adjustment did not work well with inexperienced players, as the rate of difficulty increase was too much for them, regardless of the level they started at.
They go on to elaborate on how their findings coincide with Mikulincer’s phenomenon of learned helplessness, where inexperienced players are aware of their score, and could notice they were below the others, which (Mikulincer & Mario, 1988) state “The player may have significantly doubted their ability to improve; thus, they may have eventually abandoned their performance goals.”
What this means is that when a player is given a difficulty they are not comfortable with, the player will in fact play worse than expected or projected from pervious performance extrapolation – essentially due to them losing the will to play.
Orvis and Mikulincer’s combined conclusions show that simply making the task difficulty steeper as the player progresses is not a suitable method for difficulty settings in certain games, and that constantly informing the player of their poor performance is counterproductive to the ideal player experience, especially when the entire point of the game is to attain a score, such as in racing games or arcade formatted games. This however does not hold true for many modern games, where story and the gameplay experience take precedence over performance, but this still holds true for competitive games like online modes.
Three other academics (Alexander, Sear, & Oikonomou, 2013) ran an experiment to investigate the effects of game difficulty on the player.
One main objective for them was to recommend a difficulty for the player, based on their play style. What this means is that their game initially allowed the player to choose their own playing difficulty. The issue with this idea was that in practice it did not create an ideal scenario; according to their report, the player would constantly choose a difficulty setting lower than their ability, and would constantly out-perform and become bored quickly. This is not due to the game or the design, but the mentality of the player. Since the difficulties were only marked as “easy”, “medium” and “hard”, the player knowing that they were most comfortable playing at medium would intentionally choose to play on an easy mode. What this can be explained as is that the player essentially is confused as to their own ability, and should be given a helping hand after the decision has been made.
They go on to state in their conclusions:
“A game’s difficulty should not just be matched to the highest ability of the player continually, but be tweaked for the player’s past gaming experience.” (Alexander et al., 2013)
What this essentially means is that they, too, agree with Orvis’ theory that forced adjustments systems simply do not keep the player content or satisfied with the game, as the player needing to constantly improve their skills to satisfy the minimum threshold of a game’s performance requirement will eventually frustrate and tire them. They both go on to recommend the implementation of a dynamically adjusting difficulty system which is centred around player performance, however in their design, it would be a dynamic difficulty adjustment system derived from an initial difficulty setting.
According to both (Aponte, Levieux, & Natkin, 2011b) and (Mirvis, Csikszentmihalyi, & Csikzentmihaly, 1991), Flow is a group of eight heuristics that dictate requirements that are needed to create an optimal gameplay experience. These eight components are as follows:
According to (Aponte, Levieux, & Natkin, 2011a), these eight heuristics are good definitions to build a working level or game from, in order to use Flow in games – flow being a form or dynamic difficulty adjustment.
This being said, it is good to try and understand how a difficulty system can realistically be implemented, as Jenova Chen’s Flow concept is essentially an ideal scenario and a model to start from, but not necessarily a final solution. If a difficulty system is to use this Flow framework, how would it actually manifest? In his report, (Juul, 2009) writes:
“While flow theory does suggest that the player may oscillate between anxiety and boredom, it poses the banal problem that the standard illustration suggests a smooth increase in difficulty over time.”
What this means is that Juul agrees with the concept of Flow for dynamic difficulty adjustment, however, he believes that it is too unrealistic a solution, as it works off of a perfectly smooth model and difficulty incline, which most games do not work from. In his argument, he states difficulty should be put in brackets with difficulty peaks and slight boundaries between difficulty levels. What this means is Flow works off of the notion that the game should perfectly match the player’s ability, and keep on their exact ability level, whereas Juul suggests that the slope of difficulty should not be smooth, but a step-like pattern, such that the player must still surpass difficulty thresholds in order to increase difficulty.
What Juul suggests is strikingly similar to the diagram presented by (Aponte et al., 2011a) above, such that difficulty should be quantised in brackets or steps, rather than a smooth incline. Aponte shares this point of view, and also argues that this is the most feasible and realistic implementation of difficulty adjustment, such that it adjusts to the player’s performance, but also gives a challenge to the player, or as Juul puts it:
“An irregular increase in difficulty makes the player more likely to experience both failure and successes.”
Essentially meaning that failure and success is what makes a game enjoyable.
Above is a diagram for a pre-made dynamic difficulty system, designed by (Yun, Trevino, Holtkamp, & Deng, 2010) and named PADS: Profile-Based Adaptive Difficulty System Workflow. The purpose of this design is to illustrate an effective means in which to intake player score and telemetry and process it in order to decide on a difficulty. They go on to state that the system they developed worked well in practice, as when incorporated into a video game, it offered the game a “unique, player-centric gaming experience”.
This system that they have developed is a two-way system, as it adjusts difficulty based on player profile and player performance, meaning that it stores the score of the player and creates a means to interpret the general player’s performance style, as well as their immediate performance.
(Neto, n.d.) illustrates that death is used as an arbitrary method to either restart the game, or force the player to improve. He goes on to write:
“The simulation of death is a nearly ubiquitous feature of video games. From the coin-operated arcade to the modern game console, video game designers have used the death of the player as a multivalent tool: death as punishment, death as play session limiter, death as mastery-promoting device, and so on. But death in video games bears little resemblance to the real thing.”
What he means by this is that he believes death in video games is simply a system in which to force the player to start again; a convenient reverting system to give the player a second chance, as opposed to death in the real world, where a person is not given such an opportunity to start again.
From this, it can be deduced that death in video games is not really death, but in fact a system in which to backtrack the player and give a second chance.
Further extending from his point, it is clear to see that death is not accurately resembled in the context of video games. In the real world, death is permanent, however a permanent death in a videogame will go against the purpose of a game – to be fun and enjoyable. If death was to be permanent, so would progress loss – a concept that only a few games utilise, such as DayZ and OneLife, under immense scrutiny from their own players and fans. Death to (Neto, n.d.) is seen essentially as the following:
• Punishment
• Play session limiter
• Mastery-promoting device
So this also opens the question of whether death is a part of the game, and if it is something to be welcomed or avoided.
(Neto, n.d.) states that death is a mastery-promoting device, although this can be seen in two ways; a quantitative requirement and a qualitative requirement. Some video games such as Infinity Blade, as (Moriarty, White, & Grossfeld, n.d.) puts it:
“When the player’s character dies, he or she is reincarnated as the character’s son, out to avenge his father.”
work by the player repeatedly dying in order to become more powerful in order to pass a given threshold of strength. The whole purpose of this game is to essentially die and repeat, gaining more strength through every incarnation until they are able to beat the final boss.
The exact opposite of this reiterative death system is a permanent death system, which only gives the player one life to use. This can be seen in various videogames, one being One Single Life, a platformer which gives the player one chance to pass a level. (Moriarty et al., n.d.) states:
“And to add to the pressure the game forces onto every jump, the first thing the player sees in each level is what percentage of players lost everything on this one.”
This is designed by the game to dishearten and essentially stress the player into taking the situation seriously. Moriarty calls this system “irrevocability” in his report. The system illustrated by Moriarty however goes against the conclusions of Orvis and Mikulincer, such to inflict stress and unease for the player. This system is counterproductive as it could potentially alienate the player and make them give up, essentially forcing them to quit the game.
(Juul, 2009) speaks about the concept that winning isn’t everything; as he puts it
“The simplest theory of failure states that failing serves as a contrast to winning, that failure thereby makes winning all the more enjoyable.”
What this can be elaborate as is that winning is only enjoyable due to the fact that losing is not. The purpose of losing to Juul is to create a context/contrast to winning, using the logic that something can only be considered good if there is a definition for something bad to be compared to it.
Juul describes three types of punishment for the player:
• Energy punishment
• Life punishment
• Game termination punishment
• Setback punishment
He states that these are the four types of punishment that videogames adopt. Merging these concepts with concepts described by (Neto, n.d.) a deduction can be made as to how and why death is implemented into videogames:
It can be deduced that death in video games is a designed to be a catalyst for player introspection and strategic reflection. Since death in most video games is death of the character, not the entire scenario of play, the player can assume that the game will continue from a previously achieved checkpoint; this essentially means that the player can now foresee future events which lead up to their character’s demise.
Knowing what the player has done wrong, and given time to get back to the point at which they have died, this ties in with Deutschman’s theory of the Three R’s – Relate, Reframe and Repeat.
In the case of a video game, Relate would be the player understanding that they have been backtracked to a previous point in the game, Reframe would be understanding why they died, and how they can avoid that by changing their mentality or approach to the task, and Repeat would be attempted to implement new tactics in order to proceed in the game without dying or failing again.
(SPARC (Organization) & Jason, 2008) Describe the concept of players’ mortality in their report, and illustrate that the reason why video games in this current generation handle death very simply and leniently is that the current hardware allows us to do so.
They make note of previous era video games, and arrived at the consensus that most older video games would either reset the game, or set the player back to a previous checkpoint once the player has lost a certain number of lives. This can be seen in games such as Super Mario Bros, where after the player loses all of their lives, they are set back to the start of the current world they are in.
(SPARC (Organization) & Jason, 2008) go on to elaborate that the reason for such a mortality and progress reset system was implemented was due to the fact that there were hardware constraints back then which do not exist now, so it was only feasible by the developer to lock the game’s save system to large bracketed and quantised save jumps – such that each world was a new save – as opposed to saving the most intricate detail in the instant.
They go on to describe that the reason why video games nowadays choose to have simple checkpoints and unlimited player attempts is that the current hardware allows the console/system to save the most intricate of details when regarding player progress, such that it would be more convenient for the player to pick up from where they left off, than to start at a pre-designated level. This is what they call the difference between the player simply dying, and “game over” in which the game would actually reset to a certain checkpoint by force, making the player lose progress.
Simply put, “game over” scenarios are rarely implemented because hardware advances allow the developer to save and archive progress at a greater level, such that the “game over” scenario would be more frustrating than functional, as given the complexity of current games and their achievements, losing progress in new games is more frustrating than before.
The proposed product should be able to assign difficulty settings to the player initially, whilst monitoring performance per round; this is so that the functional design remains similar to user-centred dynamic difficulty, yet does not contain the drawbacks present in previous findings.
This approach will require less ethical planning, as data on the player will only be temporarily kept, being deleted after the session is through.
The purpose of this system is to give dynamic difficulty adjustment from a set point by the player, but instead of changing variables of play, it should change the fundamental way that the game plays instead. This will be the most difficult part of the design, as this system will be manipulating the prototype game to change events and activate different scripts, instead of the default variable manipulation from most difficulty settings.
This of course would also have to differ from what already exists in other video games.
In this section, the themes and concepts covered in the literature review will be used as a criterion in which to evaluate products, or to evaluate specific features or themes that existing products / video games have implemented.
With regards to existing products, difficulty settings, the win/lose scenario, dynamic gameplay and difficulty adjustment will be contrasted and compared with previous secondary research in order to define a new specification for the project.
Constructive examples will be reinforced into the design specification, and destructive examples and themes will be compared and contrasted with research to form a new superposition on the stance of each concept; the result of which will be based on attainability within time constraints and resources to favour the most acceptable solution.
In Ninja Gaiden Sigma – hereby referred to as “Ninja Gaiden” – the player is given two methods in which to adjust and test their skill level.
Score or ranking is handled very harshly in this game, as the score, named Karma, deduced from an aggregation of clear time, kill count, ‘Essence’ or points acquired and ‘Ninpo’ or unused special attacks remaining – they are given a title of how well they have done. This essentially breaks down immediate score into five possible brackets – Master Ninja, Head Ninja, Greater Ninja, Lesser Ninja, and finally Ninja Dog. Though the game incorporates a static difficulty adjustment system, it also incorporates a forced adjustment system and a dynamic one as well.
The game when started for the very first time gives the player no difficulty choice or option, and simply tells the player to play through the entire story mode in order to attain new difficulty settings. If in the first level the player achieves a very low score, they will be given the title of Ninja Dog, and the game will alter the difficulty to a hidden Easy setting. This system is quite biased yet fair, as if the player is doing well, the game remains the same and has forced adjustment from the start, but if the player is not doing well, it will drop them to an easier level, but start a forced adjustment at that new lower level.
What this means is that the game will still become harder as the player progresses, but the difficulty will be shifted downwards when compared to the original setting. This can be considered as a dynamic difficulty setting, albeit a preliminary version of it, as from this point onwards, the game either remains at the same difficulty, or can be lowered.
The issue with this model is that it works on severe extrapolation, which is not ideal for difficulty settings. Once the difficulty setting is assigned to the single player mode, there is no going back, and since the sample space of one mission is very small, the percentage error of whether or not the difficulty assigned was the correct one is very high. Another issue with this model is that Ninja Gaiden is designed to utilise a forced adjustment difficulty system, where the enemies become harder as the game progresses, even though it originally utilises a dynamic difficulty system in the first chapter.
On top of this issue, if the player dies three times in a row (between checkpoints) throughout the game, they are given the option to ‘abandon the way of the ninja’ and are lowered down to the lowest difficulty in the game, which is not manually attainable. This level is called “Ninja Dog”, and is used by the developers to essentially shame the player. Whether or not this is a method in which to immerse the player with Japanese Ninja concepts such as honour in death or shame in failure is left to interpretation.
Ninja Gaiden is a game that utilises three different types of difficulty adjustment systems, which although is commendable, does not necessarily aide the game itself.
Ninja Gaiden is a hardcore game that is tailored to die-hard gamers, as the game is centred around mastering attack combinations, blocking enemy attacks and memorising enemy attack methods at a much faster combat speed than other games. Implementing a dynamic difficulty system in this game is counter-intuitive, as such a method is designed for games which have a more open player type.
Ninja Gaiden handles death in a perceivably classical fashion, with regards to progress retention. The player is given the option to hard save their progress at designated nodes throughout the game area, and if they are killed between this point and the next checkpoint, they will start again at this save point.
If the player dies after reaching an auto-saved checkpoint, they will start again at the checkpoint, with all progress locked to its state once the checkpoint was originally activated. This essentially means that when the player dies and respawns, all progress past the checkpoint is lost, but death statistics is kept and embedded into the save file the next time the player manually saves. What this essentially means is that if the player dies after a checkpoint and tarnishes their stats, they can simply quit the game manually and load the save which came before the auto-checkpoint, in a sense countering the negative effect of the game’s penalising system.
Ninja Gaiden is considered to be a very competitive game, as the country/world leader board is the only way for a player to show off their achievement – a roster of statistics of the game after it has been completed – included but not limited to time required to finish, total damage dealt, total kill count, total death count and total damage received. Since these statistics are only compiled between and after save points and the end of the game, simply reverting to a previous save point when things go bad essentially clears all negative statistics for the player.
The Metal Gear Solid – hereby referred to as “MGS” – series is well known for the way it handles difficulty and progress retention, as it is not the implementation of these concepts which is praised, but the delivery and immersion it retains whilst in the game.
The codec system is synonymous with Metal Gear Solid, as it is the only way for the player to save the game. For Hideo Kojima – the lead designer of the game – immersion was a priority when developing the series, and as a result of this, everything in the game outside of the main menu strives to keep face and work with both the story and gameplay.
The codec save system is built into the codec mechanic which the player uses to both gain intel for operations or tasks in the game from other in-game support characters, as well as attain narrative and exposition for the game. This can also be extended to aiding the player when they are stuck, or even reciting in-game trivia or lore.
This being said, the fundamental and most essential service the codec system brings is the ability to save, where the player has to call his operative “medic” in order to “save progress”. What this essentially means is that the game only saves when the player is in a safe place, undetected and alive. The game will not allow the player to save their game if these requirements are not met, meaning that the player must think ahead before trying to save their progress.
The main MGS progress retention system is essentially designated save files. The playable areas in most MGS games are comprised of hundreds of smaller arenas, or interior enclosures, where the game refreshes every time the player moves from one into another. Once the player enters an adjacent arena, all of their gameplay data is moved to a cache and temporarily stored – only once they manually save does this data become permanently stored. What this means is that all progress made in the immediate arena is lost, unless the player exits the arena and then returns back to it, as the game only saves snapshots of progress when entering the arena; all progress made whilst in an arena you have not yet exited is therefore discarded.
MGS adopts a very simple difficulty system; the player is given a choice between a Very Easy, Easy, Normal, Hard, Extreme and European Extreme difficulty setting, which will remain throughout the game from that initial menu. There is no way to change the setting between saves unless the player restarts the game with a new save. There is no difficulty adjustment, nor is there forced adjustment over time; the game remains equally hard as time progresses – if not easier – as the player is able to collect more weapons and items to use to their advantage, such as silent weapons and distractions for enemies, which inherently will make the game easier to play.
MGS does not make the game easier to play as time progresses via variable adjustment, but instead, makes the game easier by giving the player more options on how they would like to play the game. This could be considered as “difficulty adjustment via mechanics alteration” and could be a useful tactic to implement into the prototype.
Dead Space uses a save system identical to Ninja Gaiden and Metal Gear Solid, in which the player can only save at specific nodes, but can respawn at checkpoints. This system is considered effective for games such as these because it gives the player more options on how they would like their data recorded. The player has the choice of when to save, and thus is allowed to tailor their performance legacy at their own pace.
Where Dead Space differs from most games is in the way it handles difficulty. In Dead Space, difficulty changes alter enemy count, location, strength and emitted damage, yet does not alter damage resilience or enemy speed; the difficulty thus can be seen as the level of skill required to dispatch enemies before they reach the player, or to use in-game mechanics to prevent them from getting close and harming the player. In addition to this, loot in the game is made much more scarce, and items require more in-game currency to be bought. The game also lowers the maximum amount of ammo and health the player can carry. The purpose of this game is to make task difficulty as skewed against the player as possible, as the greater the risk and the harder the challenge, the scarier the enemies are to the player, as the desired outcome of the game – being a horror game – is to scare the player.
Where Dead Space 2 truly sets itself apart from others in the genre is its unique maximum difficulty setting, where the player is under all gameplay stipulations of the previous difficulty setting in the hierarchy, with only one added penalisation; the player can only save the game three times, and dying will set the player back to their last save.
What this essentially means is that progress retention is locked to three quantised moments in the game, excluding the game’s final completion save. If the player plays the entire game, collecting loot and upgrading their character without saving, and dies at the final boss, they will have to start the game from the beginning. If they save on the 2nd chapter of the game – there being 12 chapters in total – and die in the 8th chapter, they will start again on the 2nd chapter at the exact same progress level they were at when they saved the game.
What this essentially means is that the player not only has to ration their saves, but they must also plan ahead of time, assessing the risk involved in every fight, and contemplating the investment of a save in order to retain progress. This is a very exciting and stressful endeavour for the player to make, as not only is their progress under threat, but the task difficulty of the game is so high that dying is a reality that must be taken seriously.
The Last of Us is mainly a story driven linear narrative, and from previous research conducted, it is simple to predict that it follows a static difficulty system where the player chooses between difficulty levels.
Such in this game, the player can choose from “Easy”, “Normal”, “Hard”, “Survivor” and “Grounded”.
The variation in difficulty setting essentially manipulated variable in-game to increase or decrease ammunition, crafting-supplies, melee weapons and healing item abundance, and alters the enemy/player damage to skew in the favour of the setting.
This is considered as a classical approach, as it is the easiest to achieve without severe modification to the mechanics system – however, these concepts are set apart when the player chooses the hardest difficulty setting – “Grounded”.
In the Grounded difficulty setting – which is only available to the player after completing the game on Hard – is the only difficulty setting to remove and alter mechanics, instead of mutating them using a simple mutator system. In Grounded mode, supplies are next to non-existent and “listen mode” – a mechanic in which the player can see through walls and located enemies based on an on-screen visualisation of their ability to concentrate their hearing – is completely shut off from the player. On top of this, all enemies have triple damage and all HUD is disabled. Enemy AI is also sharper and act differently compared to the normal difficulty, and friendly players no longer drop ammo or health for the player as support, with the exception of one level, where this feature is required in order to progress.
It would seem that although the game incorporates a static difficulty system, the difference between difficulties is not linear, or relatable to one another; this makes the game difficult not simple because a threshold of the score has been raised, but because core concepts in the game have changed.
This is different than a linear approach, as now, instead of simply playing harder, concentrating more or being faster is not a plausible approach to task completion. Instead, the player must play must slower, conserve ammo and health, and change how they handle risk assessment. The only time that HUD is present during gameplay is when the player accesses their backpack, but in this state, the player cannot control character movement or defend themselves.
The Last of Us incorporates a classic approach to saving games; the user enters a checkpoint, at which point player progress is temporarily saved under an auto-save slot. Auto-save slots are overwritten as the player progresses, so manually saving is also done by the player to move that auto-save into a permanent archive. The game auto-saves at every checkpoint, and upon player death, the player is simply taken to the most recent checkpoint, with progress and telemetry loaded from that point.
Death and mortality in The Last of Us is relatively expected, considering its narrative. The game is story driven, meaning that the player is playing the game for cinematic, and expositional enjoyment as well as gameplay oriented entertainment. What this means is that since the narrative or story should not be interrupted, the concept of player death is not handled differently in this game than others, as if it were, it would go against the design of the game.
The lose scenario of this game is essentially a resetting system, not a penalising or rewarding system, although it could be seen as rewarding by some, as it allows the player to plan ahead with new information regarding their previous failure.
LIMBO – hereby written as “Limbo” essentially has no difficulty options for the player to choose from, however, the game does incorporate a forced adjustment system; the game simply adjust difficulty manually throughout the game by making puzzles and enemies harder and more dangerous, as the player proceeds through the game. Limbo’s difficulty lies in the fact that the game is inherently difficult, as it is essentially a puzzle based game. Instead of the player overcoming an enemy based on skill, they proceed through puzzles based on strategy and trial and error tactics, and as the player progresses through the game, their understanding of mechanics, rules and timing improves such that these harder obstacles are not overwhelming or unfairly difficult.
Limbo thrives from player mortality; the player is encouraged to die constantly in order to use their character as either a probe for information to help the trial and error procedure, or to simply explore, leading to further progress.
In Limbo, character death is not a primary concern to the player, as lives are infinite, checkpoints are permanent and stats are not recorded, essentially meaning that the player is free to play without fear of penalisation by the game. An example of this being used is that the player is allowed to jump off of a cliff in order to investigate what is at the bottom, knowing fully well that they will not be punished for wasting their life.
Bioshock, Crackdown and Borderlands handle task difficulty and player mortality in the win/lose scenario identically in practice.
All three products use a mortality system called “cloning”, where the player is informed of how they are revived after death, and are revived at a safe zone with all of their progress intact without affecting or reverting game time.
Suffice it to say, if you die in these games and are respawned at this safe zone, you can simply through brute force keep travelling to your previous death spot and reiteratively damage the enemy whilst dying in order to weaken them down. This is an interesting tactic regarding the win/lose scenario, as the player does not care about their death; death and mortality in this scenario is simply part of the game’s intended progression, and is used as an asset, not a threat.
With the case of BioShock, the player is informed that they are revived at a “Vita Chamber” via Plasmids reconstructed within a quantum field entanglement to bring people back to life. Plasmids being a fictional biological entity within the game lore, with the ability to mutate DNA temporarily. This is essentially a simple mechanic covered within the game’s lore in order to immerse the player, as Plasmids explain the revival process, and the quantum field entanglement explains the player’s immediate relocation to a safe spot. The game uses its own lore in order to conveniently cover for simple revival techniques.
For Crackdown, the player is constantly informed that they are a genetically cloned agent which is void of personality. When the player dies, they can choose from a plethora of respawn points in which to continue from, and once they select it, they are teleported to that point on the map/game world with full health and ammunition. Crackdown still has a main respawn point, being the agency tower, however, this is the only a formality of design; they can spawn with any weapon and vehicle they choose from at any respawn point, so there is never an incentive to respawn at the agency tower.
The issue with this mortality design is also its merit. Since the player can die, choose a point on the map and respawn there within ten seconds, it is often and widely accepted as a means of fast transport by the player. Since the game does not penalise death or failure, death simply becomes a mechanic that the player uses to either refill their ammunition, have a car they desire delivered to them or simply fast travel around the city. Although this is not inherently bad game design, it does, however, make the game very easy.
For Borderlands, death is treated slightly differently than the previously mentioned games. In Borderlands, when the player dies they are teleported and revived at a previously visited node on the map, however, they are charged in-game currency for the service of reviving them, as the lore of the game states that being revived after death is a premium consumer service in the mercenary-capitalistic game world. Although this might seem a lore/story cover for basic mechanics such as BioShock, it has an additional layer of complexity.
For every time the player dies, the price of their revival increases exponentially. What this means is that although the player may be able to be revived at a safe place with all progress unadulterated, there is a reason not to die for them – to maintain their in-game wallet. Money is earned by playing the game, and can be used to purchase ammunition, schematics and other items of value; having the game penalise you by charging you inherently links to progress destruction via the depletion of in-game asset – currency. This forces the player to plan ahead and avoid dying, as although collected loot will not be lost upon death, every time they die, the game will take more currency – and thus, progress or achievement – from them.
All three games have identical difficulty settings; the player can choose from an easy, medium and hard setting, which can be changed at any time without consequence. This choice in design is intentional, as the main feature of these games are the fact that they are mainly open world and loot driven. Having a dynamically adjusting difficulty system is counter-productive to the gameplay experience, as majority of player attention is towards picking up items and customising their character, not necessarily planning ahead or devising different strategies of battle.
Through primary research into existing video games, it can be seen that mortality, the win/lose scenario, progress retention and task difficulty are all actually tied together directly and intrinsically. It can be seen that task difficulty is the means in which to alter the gaming environment to shift gameplay dynamics, which in turn alters the score and progress of the player – including their ability to attain collectibles of value such as currency – which directly affects their ability to complete their in-game task or mission.
This essentially means that the direct origin for gameplay attitude for players in most video games would be the difficulty setting that the game is utilising or implementing.
It can be concluded that there is a strong correlation between mortality and task difficulty. In video games with complex difficulty systems, death is simplified, and for games with advanced concepts of handling player mortality and the win/lose scenario, the core gameplay becomes more fundamental and minimalist.
This could either be due to developer/studio resource management, as man-hours might be dedicated and delegated to creating mechanics that handle the win/lose scenario, and focus less effort to develop dynamic difficulty settings.
This could also be simply the design of the game, as the developers could perhaps feel that the game would become too hard to understand or anticipate. This is an issue, as dynamic difficulty systems are meant to be non-intrusive and should not explain everything to the player, as the purpose is to create a challenge for the player, not to flood them with unnecessary information.
For the prototype to be developed, it is clear that the difficulty setting is a more sound and quantifiable basis for a project, as it is the foundation and preliminary skill assessment criteria before mortality, and utilises the win/lose scenario in order to be fully utilised and made use of.
System to evaluate the difference between two different dynamic difficulty approaches, both dynamic in nature and player oriented, but the differences are how the game manifests around these difficulties.
Is it better to change simple variables around difficulty, or is it best to actually change the mechanics in the game, introduce others, or change the rules of the game around the said difficulty.
In order to complete this project, what is required are the following:
Throughout the process of conducting research for the literature review, information and advice on how to create a successful and functional dynamic difficulty system was acquired, as well as an ideal case scenario or hypothesis of results, derived from the reflection of secondary research reports, under the guise of room for improvement and indicated results from conducted experiments.
The main requirement for the prototype is it be a dynamically adjusting difficulty system which is powered by user-centred performance analysis; this means that the system should adapt automatically to the current performance level of the player without their discretion. On top of this, the system is to work off of a predetermined initial difficulty setting for the sake of assessing the player’s initial gameplay.
The system must be able to track and analyse player performance, but also to use this data to manipulate the mechanics and features of the game in order to give a scaled sense of difficulty and challenge, without seeming artificial. This answers some of the criticism of past efforts in similar designs, as they were considered too easy or hard, as difficulty to the developer was interpreted as variable manipulation instead of mechanics substitution or level alteration.
This system is to coincide with Juul and Aponte’s concept of quantised difficulty brackets, and thus difficulty should both be set in bracketed stages, but also allow the player to successfully jump between brackets with play.
In order to see if this new or alternate means of manifesting difficulty is an improvement over a system of variable manipulation – where only enemy properties are altered, two parallel but alternate prototypes must be developed; one to use a user-centred dynamic difficulty system that alters in-game variables such as enemy speed, damage and range, and another to use a user-centred dynamic difficulty system that alters in-game mechanics and level design/orientation. The latter of the prototypes will be the subject of attention, as this is an extension of what primary and secondary research has indicated, but applied to a normal system. In this sense, the latter of the prototypes will be seen as the true prototype, as it will be compared and contrasted with the first prototype, and an assessment will be made using demo players to see which version they will prefer.
As elaborated on in the literature review, the dynamic difficulty system should not inform the player that the difficulty is changing, and should not inform the player of their score with context of how high or low it is, as this will either discourage the player if they are performing poorly, or bore the player if they are doing well.
The prototypes will be split into two difference versions; one will manifest difficulty by altering enemy variables such as view distance and speed, and the other will manifest difficulty by altering the level and game mechanics itself.
In order to implement a difficulty system, it is required to first have a scoring system in which to decide the difficulty system from. This scoring system will be a script or multiple scripts of an aggregate of in-game player telemetry such as completion time, damage received and times spotted.
Thus, in order to have a scoring system, there must be a clear objective – referring to (Aponte et al., 2011b) and (Mirvis et al., 1991) and their heuristics.
The main structure of this system will be broken down into multiple sections;
“A game’s difficulty should not just be matched to the highest ability of the player continually, but be tweaked for the player’s past gaming experience.” (Alexander et al., 2013)
— as the difficulty will be taken from an average of the score, not the final score.
For this prototype, it is best to incorporate the use of third person control mechanics. The reason for this is due to the fact that the majority of video games reviewed which offered dynamic difficulty adjustment were in the third person category, and that since the implementation of difficulty will be a dynamic variant of the difficulty that Metal Gear Solid games incorporate, by introducing new mechanics instead of difficulty slopes, it is fitting to attempt to match the gameplay style in this case, such that only completion time and times spotted by the enemy is recorded. Stealth is a useful mechanic and score system to use for this prototype as it is relatively straight forward to implement and for the player to achieve well in, since the added point that the player can see themselves and around corners allows potential to score well. In a first-person game, this would not be possible and being caught – and therefore lowering your score – would be inevitable.
Before development of the prototype can commence, it is required to first understand what we are changing in the scene with regards to mechanics and level orientation, and why these specific things are being changed.
Since the game holding the prototype is going to be a third person stealth based game, and since playing time and total times spotted are factors which the player is to be scored on, for very easy difficulties, as an added mechanic, the incorporation of an ability increase the chances of attaining a higher score should be implemented as a lifeline for the player. This can be in the form of a pickup for the player, and will help those in low difficulty levels and skills to attain a higher score, which will lead to higher player satisfaction and a lower chance of “breakdown” with regards to gameplay.
This new difficulty system will also incorporate new level geometry per difficulty level.
Since enemies in this prototype are meant to find the player and eliminate them, if the geometry and orientation of levels is to help or hinder the player with regards to the difficulty, these changes must be centred around the mechanics of the enemy itself.
The easiest modes should allow the player to see through walls, and to be able to anticipate enemy movement without the enemy being able to see them either.
Normal difficulties should give the best mixture between challenge and skill by offering few of these implementations, and asking the player instead to figure things out on their own.
The hardest difficulties will hinder the player by increasing obstacle height and opacity, such that they cannot jump over obstacles or see through any walls. Being a stealth game, these features would prove to be very useful if utilised, so the concept of removing these mechanics from the player as the game becomes harder truly makes the game harder; not because of enemy strength, but because of circumstantial changes within the gameplay environment.
The scoring system proved to be difficult to work out at first, since there is little to start from when creating a heuristic for measuring player score.
I decided to research into the scoring system used in Metal Gear Solid V, and attempted to pick suitable criteria for score assessment using the game’s scoring system, based on time taken to finish a level, and times that the player was spotted. Figure 5 is an illustration of this decision, and the planning involved.
In order to understand how MGSV handles timing score for the player, I conducted primary research into observing how scores are kept within the game, and by what criteria is timing score attained or penalised. From the score menu across different levels, I recorded the time taken to complete missions and the XP awarded to the player with regards to how much time has passed. By working out how many seconds of gameplay the player took to finish the level, and then dividing it by their bonus score, I tried to ascertain the relationship between time and score. Figure 6 illustrated my findings.
When observing the graph, I realised that the correlation between time taken to complete a mission and the score attained had absolutely no correlation whatsoever. It was after this that I realised that there is no global correlation of time:score, but there is for each specific mission. Because readings of scores were taken from multiple missions, the correlation was negatively affected.
This means that the time:score ratio is specific to each level, meaning that the time taken is manually assigned to each and every level. What this can also mean is that the developers or testers are to decide how long a mission should take, and from that number, the scoring system can then tell if the new player’s performance is ahead or behind the expected score for the mission.
What this means is that I essentially had to manually tune the timing of the level in order to create a baseline for how long the level should take to be completed.
The prototype was implemented by these four scripts sitting on top of a pre-existing game that I have already created. In order for the new dynamic difficulty prototype to work properly, scripts such as enemy AI and alert scenario scripts had to be rewritten to incorporate new features such as the difficulty system itself and its output controls to alter the game, but also the ability for the AI to understand and count when it had spotted a player in order to collect this telemetry to be processed by the new system.
Since my score and difficulty system is meant to sit on top of pre-existing mechanics and code, this prototype is bespoke in nature, with its purpose to illustrate how an ordinary game can change completely, given this system. In order to do this, the system must have a way to retrieve information from within the game itself, and a way to present its findings to be processed.
This being said, in order to make the system understand and know how many times the player has been spotted, there must be a system or mechanic with a relationship to the player, such as AI or enemies.
The enemies in this project are coded by myself as past work, but needed to be altered to count how many times the player is caught. Before this project, these enemies would simply attack the player without reason or cause. Creating a way for the enemy to spot the player in specific circumstances such that it would only count one encounter with the enemy as a single encounter proved hard to implement. Before this, the enemy would technically spot the player at every update called, so that for every frame the enemy could see and chase the player, the value of a hypothetical spotCount integer would keep increasing, such that if the player had been caught for three seconds, there would be 180 incidents of the player being spotted, as each frame for three seconds would be 60×3. This inconsistency and random/erratic behaviour of the AI would doom the prototype, as there would be no way to accurately assess the player’s stealth ability.
Because of this issue, a significant amount of time was required to alter the enemy AI to only record initial spot counts of the enemy, utilising the use of Booleans as a method of validation. If the player had been spotted, the Boolean for being spotted would activate, and the excess spotting occurrences would be discarded until the player was lost and the Boolean was set to inactive.
DISCLAIMER: It should be understood that all work for this project and prototype is represented solely in the following scripts regarding both prototypes:
DifficultyControl.cs
PauseControl.cs
ScoreControl.cs
Lines 63-69 and 306-342 residing within FieldOfView.cs
All other mechanics and assets have been repurposed from previous projects and therefore should not be considered for marking – the system being developed is designed to sit on top of pre-existing games and imbed itself into the game mechanics, solely to introduce dynamic difficulty adjustment.
Scene orientation, layout and material choice is also a design factor specific to this coursework alone, so assessment of level design is also kindly requested.
The purpose of this script is to retrieve in-game telemetry and to use calculations to deduce a final score for the player, for the specific match.
The script is also designed to implement a list named scoreHistory. This list is the accumulative list of attained scores for every time the level is completed, and as a result of which, between scenes, this data must be preserved in order to work properly, which explains the need for a DontDestroyOnLoad function on line 28.
The script works by creating and instantiating a timer the second the script is active. This timer will count constantly, and is linked to “.time” meaning that if the game is paused or if time is slowed down, the timer will act accordingly to the situation and pause or slow down.
Once the level is finished, a script named PauseManager.cs is run, which stops time, and runs the function called CalculateScore () on line 48 of this script.
When this is done, the time taken to finish the level, and the amount of times the player is spotted are taken and are then changed to become new floats used to generate scores. Grabbing the values and moving them to a new named variable is very effective at severing the connection between the value and the original variable it resides in. This works so that if the timer continues for an unknown reason and needs to be reset, or the value is needed elsewhere, this data can be cleared or copied once more without affecting the value of that score needed.
Time.time is turned to timeTaken, and spotTotal is turned to timesSpotted. These new and considered ‘safe’ variables are now safe for processing without the risk of contamination, as the information described in the previous paragraph has been severed from the source variable. These variables are then processed to become two variables of score; timeScore and stealthScore.
As visible on line 22, maxScore is set at 100. maxScore is an arbitrary yet fundamental anchor for the score, and acts as a perfect score which can never be achieved. 100 signifies 100%, and thus from the calculations, this score will be divided by the timeScore and the stealthScore, meaning that in order to get the perfect 100 score, the player must finish the game at the reference speed and without being caught once, which is almost impossible.
The calculation of the timeScore and stealthScore was originally adopted from Metal Gear Solid V: The Phantom Pain’s score system.
It was decided in the design stage that these variables will be used against a fixed number to create a score of seemingly arbitrary value, but since the base number that the score is based from is a fixed value, the score is consistent and fair because the values remain consistent between readings.
Above is a continuation of the code, where it is shown how the final score is archived, and how the average score is created. This average score is then called from this script by another script named PauseControl.
This is the last segment of this script, but it is the main handler of difficulty fort the system. As previously explained, the finalScore is stored in a list of scores, and an averageScore is taken from the list via a mean calculation to find the average value. This new disposable averageScore is then called by this script and turned into a new variable named playerScore. It is possible to see this retrieval on lines 130 and 132.
averageScore is a very important, yet completely expendable value, as because it is an average of the score, it is considered an unclean variable, and only has the immediate use of being used to decide upon a difficulty to set for the player. Once this difficulty is set, the list of clean scores is preserved, but this average will disappear. The reason for this unclean variable to disappear is that because it is an average, it is an overly-processed variable. If this average score is allowed into the list, then every time the player finishes a level, an average score would be generated from a list of average results, resulting in over-rounded figures, thus ruining the preservation of score consistency and accuracy.
As is visible, the score is actively presented to the player in line 134, where it is turned to a string and shown within the GUI in the level. This is done to inform the player of their score, and thus is in accordance to the design specification.
As is visible from lines 136 to 150, the system for handling difficulty bracketing is present. This system takes the averageScore value and checks to see where in the hierarchy the player’s score sits. Based on the player’s performance, a new difficulty setting is chosen, such as on line 147 where EASY is chosen.
When the difficulty is decided, the script runs a method from another script named DifficultyControl.
DifficultyControl is the system put in place to store attributes of different difficulties, and is only present in the below form for the first prototype – the prototype responsible for manifesting difficulty in the form of manipulating in-game variables.
Here we can see that the design of the system is on par with Juul and Aponte’s theory of bracketed difficulty slopes, where the task difficulty is quantised into brackets which span throughout the score spectrum.
DifficultyControl is a system put in place to manipulate variables in the game according to the difficulty selected. If the difficulty is set to a harder one than normal, variables will be adjusted to make enemies faster, more deadly and have a greater field of view. This is done only for the first prototype to emulate commonly used tactics in videogames, where the difference between normal and hard is only how powerful and fast enemies are, simply increasing or decreasing attributes for enemies based on difficulty.
This can be seen on line 41, where the difficulty is set to HARD. When the hard difficulty is set, levelDifficulty becomes 4, and in comparison, on line 7 it can be seen that this value is originally 3. What this means is that at the start of the game, the difficulty is 3, which is normal, and if the player plays better than expected, difficulty will become 4, or HARD, resulting in the case for levelDifficulty = 4 to take place. When this occurs, difficultyDivider becomes 2, and difficultyMultiplier becomes 1.5.
These values named difficultyDivider and difficultyMultiplier are only used in separate scripts regarding enemies, such that enemy attributes are reliant on these variables.
For example, in the script GuardState.cs, which handles enemy AI, the enemy’s field of view is reliant on this, as the value for the radius of the field of view is depicted as the following:
viewRadius = originalViewRadius * DifficultyControl.difficultyMultiplyer;
What this means is that when the difficulty is set to NORMAL, the viewRadius is simply the originalViewRadius, but when the difficulty is set to HARD, the viewRadius becomes the originalViewRadius multiplied by the value 1.5, from line 44 in DifficultyContol. This basically means that in the HARD difficulty setting, the enemy’s field of view is increased to 150% of its original field of view radius, meaning it can see 50% further. This elegantly illustrated the end effect of the system, and how the difficulty system manifests. This difficulty setting is commonly used in games with similar mechanics related to stealth, such as Metal Gear Solid. In games such as these, a main difference between normal and hard is how far the enemy can see, and how much damage they deal, not necessarily how they behave.
Now that prototype 1 has been explained, it is time to discuss the differences between this one and prototype 2, which manifests difficulty by changing in-game mechanics.
Here it can be seen that the layout of this script is quite different to that of its alternate counterpart. Instead of assigning difficulty settings, it is designed to activate or disable buttons from appearing within the finished screen. Since this information is processed whilst the finish screen is shown, the button that allows the player to play the game again and therefore is the only way to play in the new difficulty is changed each time to an identical looking button, but one which leads to a different entire level.
Due to the nature of this alternate difficulty system, it was incredible difficult through code to rearrange levels, edit mechanics and introduce different materials. It was deemed an easier and functionally identical approach to move the player to a manually created level instead of making them play the same level with alterations as the first prototype did.
Since the purpose of this alternate difficulty system is to dynamically adjust gameplay, but do it so that the end result is an alternative playing experience as opposed to an identical one, new game mechanics, rearranged level design, new gameplay rules and new enemy behaviour needs to be introduced. Writing a script to automatically morph a single game level in a manner to achieve this would be incredibly difficult, and would require significantly longer development time, testing protocols and practice/research to ensure feasibility. This is considered by myself as one of the shortcomings of this prototype, as although it is functionally irrelevant as it performs its task well, it does however stand to hold significant file redundancy.
When the difficulty is set, the “CONTINUE” button on the win screen is swapped for one that leads to the level that corresponds to the attained difficulty level.
If the player achieved a score worthy of EXTREME difficulty, the CONTINUE button will change to one that when clicked, will load the EXTREME difficulty scene, instead of altering the same level to EXTREME settings. This way, enemy AI speed and danger is identical throughout, but the concept of difficulty is manifested as a tougher or easier gameplay scenario based on mechanics and environment, instead of just enemy attributes.
Making sure the average works out required constant testing, as I had to be sure that no matter how many results were kept, the average was being taken of all results in the list.
In order to do this, I wrote debug commands within my scripts to constantly print what was happening inside the console. This turned out to be extremely useful, as for a while all of my values were returning as zero. To find the route of this issue, I followed the flow of processed until I was able to see when issues where occurring. Debugging every step of the process was a very useful form of iterative testing.
As seen in Figure 1 in the Appendices, the finalScore being outputted are behaving as normal. One it outputted, and right afterwards the average score is then output so it can be compared accordingly.
The prototype currently does not rely on anyone else’s work other than my own. The game that this prototype attaches onto is previous work which has already been academically accepted, thus the only work to be related to this project is the creation of the alternate difficulty levels and the four scripts that are designed to reside with the pre-made game files.
From a legal standpoint, none of the assets used within this prototype are commercially attained and all work regarding the dynamic difficulty system is my own work.
With regards to copyright, the only foreseeable issues could be the fact that the method in which to score the player, using a mixture of time taken to complete the level and the total amount of times spotted by the enemy, was originally inspired by the system used in Metal Gear Solid V: The Phantom Pain, however, it is not an explicit copy, and only takes slight inspiration and guidance from this concept, as the execution and manipulation of variables is completely different to that of the original material, thus there is no grounds for concern.
Security is not a major concern for this product, as it does not store user profiles, but only telemetry of performance by the player, which holds no intrinsic value, or contextual value regarding the player’s identity. The data is also volatile and upon closing the application, the data is erased from the cache of the computer. No records are kept, and no player information is kept regarding their personal details, so there is no weak point for a data security breach.
The prototype being developed is simply a system to provide dynamic difficulty adjustment for video games, therefore it is void of creative themes, exposition or literature content which can spread offense, argument or ideologies which can alienate, insult or offense a user. The base game itself is void of violence, blood and sexual themes, and is simply designed as a placeholder game to act as a skeleton for the prototype, thus there cannot be any means in which offense can be portrayed to the user.
If this product was to be developed commercially, there could be many possible issues:
The prototype itself is a concept in nature, and thus the prototype is only one manifestation of this concept for the specific purpose of working around a third person, stealth based video game. If the prototype was to be developed commercially, universal implementation would be almost impossible since every video game is coded differently, using different programming languages and in different styles. Unless there is a clear repository of player and enemy attributes, or level attributes which are not baked into the game itself, each game that wanted this service or product would need to have the system manually implemented in a bespoke fashion, which essentially would make quality assurance impossible due to the high amount of variables.
Protecting the product as a commercial and intellectual property would be very difficult, as the prototype is too basic and premature to warrant such a procedure. In order to qualify for a patent, the system must have very specific characteristics and processes which make it unique to anything else, meaning that both complexity of the design and implementation method must be further developed to a point which it can stand on its own against similar concepts.
| Action | Expected Result | Actual Result | Successful? |
| Score between 140 and 200 | Moved to EXTREME difficulty | EXTREME difficulty set | Yes |
| Score between 100 and 140 | Moved to HARD difficulty | HARD difficulty set | Yes |
| Score between 80 and 100 | Moved to NORMAL difficulty | NORMAL difficulty set | Yes |
| Score between 40 and 80 | Moved to EASY difficulty | EASY difficulty set | Yes |
| Score between 0 and 40 | Moved to VERY EASY difficulty | VERY EASY difficulty set | Yes |
| Check for score averaging by playing multiple times and observing result debugs | With the exception of the first score, the average score will not be the same as the final score, and the average score will be an average of all past accumulated scores | Difficulty resets to zero | No. List needs to be altered to remain secure between scenes, otherwise it is constantly resetting |
| Check for score averaging by playing multiple times and observing result debugs | With the exception of the first score, the average score will not be the same as the final score, and the average score will be an average of all past accumulated scores | Average score is accurate and correct at every instance, and rounds from float to int correctly | Yes |
| Playing very well then very badly | System will push the player to EXTREME difficulty, then to NORMAL difficulty, as the average between EXTREME and VERY EASY will average to NORMAL | EXTREME difficulty set and then set to NORMAL difficulty | Yes |
Final testing of project by users and clients were done only on CIS department students, and no personal information about them was ascertained during both demo gameplay and the subsequent questionnaire.
After playing both variants of the game, the testers were then asked to follow a link to access a Google Forms and requested to input information and opinions regarding the prototype.
The players were first given prototype variant 1, which offers the in-game variable manipulation to make enemies faster and better sighted, and afterwards were given prototype variant 2 to play, which offers dynamic difficulty adjustment regarding game mechanics manipulation and level orientation based on difficulty.
According to the collected results of the surveys (figures 7-10), it is clear that the preferred version is the latter version – the second prototype variant that handles difficulty by modifying the game environment and mechanics around it.
The players tended to play more levels in the second prototype more so than the first, and considered the second prototype to be the more balanced of the two with regards to gameplay. Some users experienced frustration in the first prototype, and decided to play it less than the second prototype. The correlation between frustration and lower playing amounts could be linked to Learned Helplessness which was previously covered. Knowing that my second prototype frustrated the player less inherently means that it avoided Learned Helplessness, and therefore coincided with Jenova Chen’s Flow more adequately, however, this could also have been due to an imbalance between the two versions; it could be considered that more time was spent balancing the second prototype than the first, and therefore the second prototype might have been given an unfair advantage.
In general, the majority of players would prefer to play the second variant over the first, and when asked if they were to purchase a game with a difficulty system incorporated, they chose the second prototype to be the candidate. This is mainly due to the fact that the second prototype treats difficulty differently to what players are used to, and because of this, there is a sense of curiosity as to what games could offer using this system.
This prototype handles mortality and the win/lose scenario is a fairly expected method. When the player dies, they are taken back to the latest checkpoint with their score reset to the point of said checkpoint. Similar to Ninja Gaiden and Metal Gear Solid’s progress retention nature, progress is only saved once the player progresses to another checkpoint and the score becomes permanent. If the player in the prototype dies, their score is not taken, as they have not passed the level. This essentially gives them the opportunity to try again, learning what they know now, which ties in with Deutschman’s concept of Reframing – to understand what you have done wrong, with the aim of correcting the mistake with new information and a new outlook.
Difficulty in this prototype manifests in a user-oriented dynamic difficulty, or adaptive difficulty system. This means that as the player becomes better, the game becomes harder, and as the player becomes worse, the game becomes easier to maintain Flow. The main issue with this is that although Flow is supposedly reached using these means, the difficulty incline does not correlate well to the end output, essentially meaning that when the game is set to hard, it is actually slightly too hard, and tends to frustrate the player. This is due to the fact that the difficulty system directly alters enemy strength and speed, which quickly can turn the game from fun to frustrating.
Since this prototype in progress sense is identical to the first, there is not difference to be discerned between the two. The differences are found specifically in the way they treat task difficulty.
Task difficulty in this prototype is considered user-oriented and adaptive, or dynamically adjusting, however, the manifestation of the difficulty is similar to methods used in video games such as Dead Space 2 and Metal Gear Solid, in the fact that based on difficulty, the location of enemies, mechanics of gameplay and even the orientation and layout of the level alters to give the highest possible level of immersion and entertainment to the player. When difficulty is lowered, new mechanics such as health packs and extra lifelines are given to the player, and the rules of the game alter slightly to accommodate to someone who might not be too familiar with the gameplay style. Walls become transparent, larger cover is given to the player to hide away from enemies, and in between rooms are smaller rooms designed to create an extra layer of protection from enemies who would try and chase the player across rooms. As the player becomes more experienced and performs better, the difficulty increases accordingly, and these features eventually disappear. If the player is playing exceptionally well, the game environment will change to hinder gameplay, by forcing wall opacity and making obstacles unavoidable for the player, increasing their chances of being caught.
Whilst this system is unique and very few video games incorporate such an implementation for difficulty, there is still room for improvement. It would be more ideal if the player has the ability to clear their score history manually and start again with a clean performance record. It could also be said that these difficulty changes are too drastic in nature, and that more subtlety is required, this indeed could be done if there were more mechanics to implement or alter, instead of simply three. Since a game is comprised of mechanics, the more mechanics there are to be tweaked through difficulty change, the more subtly each one can be affected without shocking or confusing the player.
I believe that the project as a whole has been a success; information gathered by user testing has proven my prototype to have offered a new or original take on the difficulty system when compared to the original model, such that players found that having difficulty dictate the layout and mechanics of the game, as opposed to a rudimentary manipulation of enemy characteristics, was a more immersive, enjoyable and interesting way to play a game.
There are some issues with the prototype which if given more time, I would have liked to rectify, such as the fact that the alternate prototype used level changing in order to change the perceived difficulty, instead of the use of scripts to assign and relocate in-game assets. This I believe is one of the short fallings of the project, as due to time constraints, this method of changing the environment was the only plausible way.
Instead of this approach, I simply could have designed the single level with superpositions of level design and enemy AI/mechanics, but with redundant parts disabled. Once a difficulty was enabled, a script could have enabled the scripts, mechanics, level design and location based on the selected case for difficulty. This is one way this could have been achieved without having to have multiple levels; by having all levels put into one scene, but with different parts activating as per the selecting difficulty. This could have saved file size as well as kept the same PauseControl script, maintaining the design of the prototypes.
Alexander, J. T., Sear, J., & Oikonomou, A. (2013). An investigation of the effects of game difficulty on player enjoyment. Entertainment Computing, 4, 53–62. https://doi.org/10.1016/j.entcom.2012.09.001
Aponte, M.-V., Levieux, G., & Natkin, S. (2011a). Difficulty in videogames. In Proceedings of the 8th International Conference on Advances in Computer Entertainment Technology – ACE ’11 (p. 1). New York, New York, USA: ACM Press. https://doi.org/10.1145/2071423.2071484
Aponte, M.-V., Levieux, G., & Natkin, S. (2011b). Difficulty in videogames: an experimental validation of a formal definition. In Proceedings of the 8th International Conference on Advances in Computer Entertainment Technology – ACE ’11 (p. 1). New York, New York, USA: ACM Press. https://doi.org/10.1145/2071423.2071484
Deutschman, A. (2007). Change or Die: The Three Keys to Change at Work and in Life.
Iacovides, I., Cox, A. L., Mcandrew, P., Aczel, J., & Scanlon, E. (2015). Game-play breakdowns and breakthroughs: Exploring the relationship between action, understanding and involvement. Human–Computer Interaction, 30, 3–4. https://doi.org/10.1080/07370024.2014.987347
Juul, J. (2009). Fear of Failing? The Many Meanings of Difficulty in Video Games, 237–252. Retrieved from https://www.sfu.ca/cmns/courses/2011/260/1-Readings/Juul Fear of Failing Video Games.pdf
Kätsyri, J., Hari, R., Ravaja, N., & Nummenmaa, L. (2013). The opponent matters: elevated FMRI reward responses to winning against a human versus a computer opponent during interactive video game playing. Cerebral Cortex (New York, N.Y. : 1991), 23(12), 2829–39. https://doi.org/10.1093/cercor/bhs259
Mikulincer, M., & Mario. (1988). Reactance and helplessness following exposure to unsolvable problems: The effects of attributional style. Journal of Personality and Social Psychology, 54(4), 679–686. https://doi.org/10.1037/0022-3514.54.4.679
Mirvis, P. H., Csikszentmihalyi, M., & Csikzentmihaly, M. (1991). Flow: The Psychology of Optimal Experience. Academy of Management Review, 16(3), 636–640. https://doi.org/10.5465/AMR.1991.4279513
Moriarty, B., White, D., & Grossfeld, M. (n.d.). IRREVOCABILITY IN GAMES.
Neto, M. V. (n.d.). A Hero’s Death: Human Mortality and Video Games.
Orvis, K. A., Horn, D. B., & Belanich, J. (2008). The roles of task difficulty and prior videogame experience on performance and motivation in instructional videogames Computers in Human Behavior. Computers in Human Behavior, 24, 2415–2433. https://doi.org/10.1016/j.chb.2008.02.016
SPARC (Organization), & Jason. (2008). "You Are Dead. Continue?": Conflicts and Complements in Game Rules and Fiction. Eludamos. Journal for Computer Game Culture (Vol. 2). Singapore-MIT GAMBIT Game Lab. Retrieved from http://www.eludamos.org/index.php/eludamos/article/viewArticle/43/81
Yun, C., Trevino, P., Holtkamp, W., & Deng, Z. (2010). PADS: enhancing gaming experience using profile-based adaptive difficulty system. Proceedings of the 5th ACM SIGGRAPH Symposium on Video Games – Sandbox ’10. New York, New York, USA: ACM Press. https://doi.org/10.1145/1836135.1836140
Reflecting on this work-schedule, it is clear to me that I was too optimistic regarding the completion of the project implementation. The entire process was delayed for more than three weeks due to issues regarding implementation, which were not possible to foresee, yet in hindsight it would have been a wiser decision to dedicate more time towards this part, as implementation was bound to bring about the most difficulty throughout the project lifecycle.
Figure 1 – testing for finalScore and averageScore
Figure 2 – the process of how the win/lose scenario is handles with regards to score taking
Figure 3 – data flow in prototype and how difficulty is decided
Figure 4 – deciding on difficulty curve for score taking
Figure 5 – analysis of MGSV scoring system, taking useful points and discarding the arbitrary
Figure 6 – a graph depicting the correlation between time taken to finish and the score bonus
Figure 7 – survey results
Figure 8 – survey results
Figure 9 – survey results
Figure 10 – survey results
You have to be 100% sure of the quality of your product to give a money-back guarantee. This describes us perfectly. Make sure that this guarantee is totally transparent.
Read moreEach paper is composed from scratch, according to your instructions. It is then checked by our plagiarism-detection software. There is no gap where plagiarism could squeeze in.
Read moreThanks to our free revisions, there is no way for you to be unsatisfied. We will work on your paper until you are completely happy with the result.
Read moreYour email is safe, as we store it according to international data protection rules. Your bank details are secure, as we use only reliable payment systems.
Read moreBy sending us your money, you buy the service we provide. Check out our terms and conditions if you prefer business talks to be laid out in official language.
Read more