Linköping University | Department of Computer and Information Science

Master’s thesis, 30 ECTS | Datateknik

2021 | LIU-IDA/LITH-EX-A--21/004--SE

How to develop a mini- malist, fun and engaging climb/sneak/assassination game with flow in Unreal Engine 4 Utveckla ett spel för att inducera flöde i spelare

Aakif Sultan

Supervisor : Erik Berglund Examiner : Erik Berglund

Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer- ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över- föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till- gängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet än- dras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down- load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

© Aakif Sultan Abstract

A lot of research has been done on creating flow, absorption, immersion, and engagement in video games especially in the past decade. In this report I will propose game design choices which induce flow state in players, and analyzing the creation of a stealth assassination game in Unreal Engine. The implementation of the game will be documented and the game design choices justified. The results will show that the game created does induce flow in players using quantitative analysis through a survey taken from players after they are asked to play the finished game. Even with the decent number of testers there is still more that can be done to improve the assessment the survey was aiming to make. The feedback from an industry expert has also been included in the report. Acknowledgments

I would like to thank my family who have always been supportive of whatever I pursued regardless of if they understood it or not. I would also like to thank my Examiner and Super- visor Erik Berglund for being a constant help and a great mentor, who was always present when I got stuck or had any confusion.

iv Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

1 Introduction 1 1.1 Background ...... 1 1.2 Motivation ...... 2 1.3 Aim...... 2 1.4 Research questions ...... 2 1.5 Delimitations ...... 3

2 Theoretical Framework 4 2.1 Flow ...... 4 2.2 Quantitative study ...... 5 2.3 User Experience ...... 5 2.4 Procedural Generation ...... 6 2.5 Unreal Engine ...... 7

3 Method 9 3.1 Iterative Prototyping ...... 9 3.2 Unreal Engine ...... 10 3.3 Assassination Game ...... 12 3.4 Survey ...... 12 3.5 Expert Feedback ...... 14

4 Results 15 4.1 Flow and Game Design Choices ...... 15 4.2 Game Mechanics and Features ...... 16 4.3 Result from Survey ...... 20 4.4 Expert Feedback ...... 25

5 Discussion 26 5.1 Survey ...... 26

6 Conclusion 28 6.1 Research Question ...... 28

7 Limitations and Future Work 30

8 Appendix 32

v 8.1 Questions for the testers ...... 32

Bibliography 33

vi List of Figures

2.1 Level Generation Steps in Unreal Blueprints ...... 6 2.2 Generating Enemies and Patrolling points ...... 7

3.1 Player Controls Blueprint ...... 10 3.2 Enemy Combat Behaviour Blueprint ...... 11 3.3 Enemy Patrolling Behaviour Blackboard ...... 12 3.4 Questions and Flow Factors ...... 13

4.1 Starting Location ...... 16 4.2 Enhanced Vision ...... 17 4.3 Inside the structure ...... 17 4.4 Climbing ...... 18 4.5 Detection ...... 18 4.6 Hiding ...... 19 4.7 Ledge Assassination ...... 19 4.8 Back-stab Assassination ...... 20 4.9 Aerial Assassination ...... 20 4.10 Survey Question 1 Results ...... 21 4.11 Survey Question 2 Results ...... 21 4.12 Survey Question 3 Results ...... 21 4.13 Survey Question 4 Results ...... 22 4.14 Survey Question 5 Results ...... 22 4.15 Survey Question 6 Results ...... 22 4.16 Survey Question 7 Results ...... 23 4.17 Survey Question 8 Results ...... 23 4.18 Survey Question 9 Results ...... 23 4.19 Survey Question 10 Results ...... 24 4.20 Survey Question 11 Results ...... 24 4.21 Survey Question 12 Results ...... 24

5.1 Aggregate Result ...... 26

vii 1 Introduction

1.1 Background

Video games is a relatively new form of entertainment starting in 1970 UK with simple com- puter games like Pong and Space Invaders. The market has become one of the biggest entertainment industries in the world. The appeal of video games is evident from the sales and time played by players but engagement and entertainment from these games has been deceptively hard to explain [1].

Most of the early research on video games concentrated on only the negative impacts of video games recently there has been research on how playing games have a positive impact on the players [2]. People who play games perform better intellectually due to the stimuli and have better relations with parents and peers. It has been linked to better mental health, low substance use, and improvement in self concept and there is a lot of empirical evidence to support these claims [3].

Video game design is an ever evolving field. As technology has become widely available the demand for more and better designed games has increased considerably especially in the last few years due to the availability of smartphones. There are many approaches to game design and this paper will concentrate on the principle of flow.

There are many challenges facing the games industry mainly concerning the inherent nature of the industry and how saturated it has become and how hard it is to train personnel to work with the ever expanding array of hardware and software. Game design also revolves heavily around preproduction and creating prototypes which will help gather requirements from customers[4].

The main purpose of that is to create a Game Design Document where the description may in- clude concept art, storyboards, software prototypes and more. If preproduction is successful the game developed would be engaging, and exciting and the development team can concen- trate on actually developing the game rather than figuring out what makes their game fun [4].

1 1.2. Motivation

One approach towards game design is a wholly user centric design. Scenario based studies have been conducted and they have concentrated on playability which aims to create games which support different types of players, integrate all features seamlessly like story, characters, and mechanics, and ensure that the controls are not too hard for players [5].

This paper aims to find how to induce this flow state into the players through smart game design using a stealth based game, where the aim of the player is to assassinate a target while avoiding being killed by enemies or fall damage.

1.2 Motivation

Many modern video games try to imitate successful Intellectual properties (IPs) but fail to attract players as well as keep them playing their games. Video game developers fail to understand the main reasons why a certain game was successful and engaging and only see the superficial details of a video game and attempt to replicate it.

Understanding precisely what makes a game engaging is key to success for any product. Concepts like mechanics, narrative, interface, and game-play are the most common elements considered. The model suggested by Sweetser et al [6] is concentration, challenge, skills, control, clear goals, feedback, immersion, and social interaction. Wirth et al [7] highlighted the issue of disagreements regarding labels used for subjective experiences of players, so one must first define what terms will represent what in a certain paper.

Most studies on game design concentrate on self determination theory i.e. all human be- haviour can be linked to human need for competence, autonomy and relatedness. Compe- tence refers to our basic human need to feel capable and powerful. Autonomy refers to our need for freedom and having options in actions and that is directly related to options in life or death situations. Relatedness refers to our need to feel connected which again is connected to humans collective survival strategy [1].

These studies however seem to concentrate more on why do players feel certain things while playing games rather than how to make the players feel that and what design choices will actually lead to those feelings.

1.3 Aim

The aim of this paper is to create a stealth assassination game with climbing mechanics and to induce the state of flow in the players and translate the results into game design principles.

1.4 Research questions

The following research questions will be investigated and answered in this thesis.

1. How to design a minimalist rogue-like assassination game in Unreal Engine to facilitate a high degree of flow.

The research question focuses on the design principles and elements in a rogue-like assassina- tion game made in Unreal engine which helps induce flow in the player. It is about creating a game which adheres to game design principles which encourage flow state by achieving concentration, enjoyment, and interest [8].

2 1.5. Delimitations

1.5 Delimitations

Since flow is a psychological state it is hard to identify when someone is actually in it and self reporting by players may not be accurate.

3 2 Theoretical Framework

2.1 Flow

Flow state is the complete or deep absorption of a person into the task they are performing to the point that they find the activity pleasurable, and easy. It is usually associated with athletes and other competitors in time sensitive competitions. It is a state where individuals may function at their full capacity. In this state the experience is the reward and no extrinsic reward is necessary. Flow theory states that three things must be simultaneously achieved, concentration, enjoyment, and interest in order for a person to be considered to be in a state of flow [8].

For video games flow is the state where a good balance of challenging gameplay and enjoy- ment is achieved [9]. The activity performed must be intrinsically rewarding i.e. no in game reward needs to be given to the player for them to feel a sense of achievement.

Flow theory uses factors which determine the enjoyment, engagement, and immersion of a player [10]. These are based on research by Mihaly Csikszentmihalyi, an American- Hungarian psychologist.

- A challenge requiring skill to overcome.

- Absorption in the activity.

- Clearly defined goals.

- Immediate Feedback.

- Concentration.

- Sense of control.

- Loss of self consciousness.

- Losing track of time.

4 2.2. Quantitative study

2.2 Quantitative study

Quantitative studies are studies where all participants are asked the same questions and they are standardized. The perspective of players is very important to the study since questions can be asked which may indicate how the player is feeling and so allow us to assess if the player was in a state of flow. All but one question was made multiple choice and all mul- tiple choice questions had five choices i.e. Strongly Disagree, Disagree, Neutral, Agree, and Strongly Agree. They were all questions about how the user was feeling while playing. The first question was there to make sure the players had experienced games similar to the expe- rience the game was supposed to imitate.

2.3 User Experience

There has been a recent shift of interest in user experience(UX) and so it has become the focus of game design, and evaluation of a game’s success. There are many methods of evaluating UX design and extensive studies have been done on it especially in the past decade. The in- dustries interest in UX is high for practical reasons, but the research on how to systematically evaluate and measure it is still sparse compared to the importance given to it by industry professionals [11].

There is a difference between UX and usability evaluation. While usability focuses on tasks and performance of the product UX is based more on the lived experience of the player or user. Usability deals with clicks, errors, bugs, performance issues, and navigability when it comes to User Interface(UI). UX is not easily assessed by these metrics. The only metric from Usability that may be used to evaluate UX is satisfaction. A user’s expectation and motivation also matter in UX which is not considered in usability. [11].

Usability is concerned with the following: [12]:

- Effectiveness

- Satisfaction

- Efficiency

- Improve learnability

- Ease of use for the product

UX is used for to achieve the following: [12]:

- Understanding the user

- How they behave

- What they want

- Suggestions

- Recognition

5 2.4. Procedural Generation

2.4 Procedural Generation

Procedural Content Generation in games has been used through the years for a multitude of reasons. Most common reason to use procedural generation is to increase replayability of the game by potentially creating limitless content. The gameplay loop serves to help players play similar situations repeatedly as to refine their strategies and achieve mastery. Procedural generation also allows vast game worlds to be made without human authorship. A common vocabulary for both researchers and game designers is needed for research in this area to be effective. There are a few approaches to procedural generation of levels as it concerns the game created for this paper [13].

- Optimization The most computationally expensive approach and hence used to generate content which would later be changed by a human. The content is explicitly and externally generated.

- Constraint Satisfaction This approach uses specifications and constraints on the content generated. It is con- venient for designers to specify what content they want without having to get into the development of the game.

- Grammars They are based on a grammar or set of rules which the system will develop content from. Grammar can be based on purely production rules for generations if the grammar is built in the rules.

- Content Selection This approach uses pre-made pieces of content which are placed together to make new layouts for a game. It is disputed if it is actual content generation or not.

- Constructive Using building blocks and piecing them together without any external heuristic check- ing to see if the level generated is valid although there is internal logic to each building block and where it should be placed.

Figure 2.1: Level Generation Steps in Unreal Blueprints

The game developed for the paper uses a hybrid of constraint satisfaction and constructive approach. The constraints on the system were the restrictions inside the initial generation. The level propagated outwards from an initial cube but was limited to generation inside the arena. The constructive part of the approach was that there are no external heuristics to check if the level generated is valid and completely functional. There is an internal logic to each block being placed differently whether it is a wall, floor, or ledge. The above diagram 2.1 shows these functions used to procedurally generate the levels.

6 2.5. Unreal Engine

2.5 Unreal Engine

Unreal engine is a game development engine which provides a high level environment. It has functionalities which cater to creation of games both 3D and 2D. Blueprints are an important feature of Unreal which facilitates in creating games by simplifying a lot of the functionality which would otherwise be time consuming and prone to bugs and issues if implemented.

While developing the game a limitation of Unreal was explored which stems from the high hardware requirement for Unreal Engine. Shadows had to be removed from the game to run it smoothly on a gaming laptop due to the high number of individual objects due to the procedurally generated levels. Baking a level improves performance but that was not possible because of the procedurally generated levels. One other issue with using blueprints in Unreal is that there is a limit to the functionality available in Unreal and some things might need the developer to switch from a purely blueprint based project to also using C++ scripts. This will have it’s own overhead in development cost since it is hard for developers to switch from one type of development to another to develop functionality which would otherwise be done in the same way in other engines.

Even with those problems, blueprints make developing a game very simple because of the availability of functions usually needed in game development, and which would otherwise need a considerable amount of development. Another limitation or inconvenience of Unreal Blueprints is the fact the links between functions can become really jumbled and make de- bugging and fixing issues as well as making changes harder as the complexity of functionality increases.

For procedural generation there are a few problems in Unreal blueprint which make it harder to use. The random seed generation can be used for number generation with a seed which allows the developers to save a seed for further use. Unfortunately there are functions built into blueprints that give a random location but do not accept or consider the saved seed which forces the developer to create two different ways to implement random seeds in procedural generation.

Below is one such example of a function which generates enemies, assigns patrol points, and saves these locations into a save file which is needed since the function which finds patrol points on the mesh the enemy can walk on does not take in the random seed and randomly generate a point without the developers control on the seed. This forces the developer to save and load points at the appropriate place to make the procedural generation functional.

Figure 2.2 shows how a complex function may create confusion as the developers try to im- plement or debug the blueprint. This is still a relatively simple function but procedural gener- ation can have far more complicated functions which will cause problems in both debugging and processing the scene.

Figure 2.2: Generating Enemies and Patrolling points

7 2.5. Unreal Engine

It is hard to pause the game in the editor while playing and see what is happening with each object in the scene. This makes it very hard to debug problems.

8 3 Method

During the project a 3D stealth assassination game with climbing mechanics was created us- ing Unreal Engine. After creating the game it was tested for game play fluidity, engagement, challenge, and glitches. The players must play in procedurally generated levels and race to assassinate the target. The game is fast paced with short play time, quick restarts, and fragile player characters.

In order to address the research question the game needed to be tested by different users. There were only a few testers who would play the game and give feedback periodically but the most important feedback would be from an industry expert so after completion the game was shared with an industry expert to analyze to find if it induces flow in the player as to use their time efficiently.

After completion of the game to the point that it is relevant for the scope of this study, a survey was created and given to the testers and additional people were asked to play the final build. They were asked questions in a survey to express their experience in the game. The results of the survey are in Results. Each question was designed to see if the gameplay induces a state of flow in players.

3.1 Iterative Prototyping

Feedback from players was taken periodically as to know which features would be important to them and what changes need to be made in the mechanics. The testers were provided builds of the game weekly as to quickly improve the game’s feel and add features which would be expected from a game with assassination, climbing, and fast paced game play. This informal testing was a good way to find out and fix bugs, glitches, and missing functionality. A lot of features were added due to feedback from testers.

It was only after completion that the game was handed to industry expert to use their time wisely.

9 3.2. Unreal Engine

3.2 Unreal Engine

The video game was made using Unreal Engine. It is a 3D game with and enemies made using Unreal’s own skeletal system and using much of the default animations and controls. The game uses blueprints for most behaviours and functionalities for both player and enemies. The models for the players were created using Blender. The game has procedurally generated levels. Unreal engine has specific functions which facilitate the devel- oper by helping generate positions on the navigation mesh which helps in placing enemies in case of a procedurally generated level. There are options to remake the navigation mesh at runtime which helps with dynamic path finding. Other features include basic functionality required for video games like taking and causing damage, different types of perceptions, and adjustable physics for pawns as well as basic movement and traversal.

Unreal Engine version 4.25 was used for the entire duration. Unreal Engine’s Third Person Example was used as the basic movement controls for the player and the rest of the player abilities and controls were built in the same blueprint.

Figure 3.1: Player Controls Blueprint

Figure 3.1 shows the player controls which were created in Unreal blueprints. This is a strong reason to prefer Unreal Blueprints rather than programming in a language since it makes organizing behaviour very easy and visually intuitive. Figure 3.2 shows the behaviour blueprint for enemies and this is a testament to the power of Unreal engine to create func- tional behaviour with comparatively little effort. The different functions in Figure 3.1 show different actions needed to create a climbing system, dodge roll, movement, assassinations, and general traversal like jumping, walking, and running. Some of the labelled grey boxes in 3.1 show intermediate actions like Corner tracers simply check for corners while hanging.

10 3.2. Unreal Engine

Figure 3.2: Enemy Combat Behaviour Blueprint

Figure 3.2 shows the Enemy behaviour and the response of enemies to the actions by the players. Functions like Take Down, BackStab, Mark as Target are all functionality related to the players actions and how the enemies respond to it.

11 3.3. Assassination Game

Figure 3.3: Enemy Patrolling Behaviour Blackboard

Figure 3.3 above shows the patrolling behaviour of enemy units. The states for enemies are patrolling about three points, chasing the player, and searching for the player when the player cannot be seen anymore, as well as a small delay while switching between behaviours.

3.3 Assassination Game

The game was developed using Unreal Engine Blueprints. Most of the time was used trying to make the climbing mechanics. Different implementations of climbing mechanics were considered including one where ’climbing points’ had to be placed on a surface which would contain direction and type of hanging animation which would require considerably more effort in the procedural generation of the level and it worked inconsistently. So a climbing system which works for any sort of ledge was created to make sure the character can move without additional objects attached to the walls or floor in the procedurally generated levels. This implementation would facilitate in expanding the game to making more complex levels and still retain the climbing functionality. Due to the random placement of climbable surfaces the climbing system had to be able to work with any surface as long as it has a ledge and detecting that was the first step.

The second step was to create combat which was made deliberately hard to encourage stealth game play and assassinations. The assassinations were implemented in three ways. The player could backstab enemies while on the ground. The player could assassinate aerially either from a walking or hanging position. Additionally players could assassinate an enemy while hanging from a ledge if the enemy was standing over the player. The goal of each level was to assassinate the golden enemy which can be seen with enhanced vision from anywhere in the map, after which a new map is generated.

3.4 Survey

Since the game was informally tested for iterative prototyping, there were many changes in the development phase. This means that the game needed to be tested periodically after which bugs were fixed and new features would be added and this was repeated each week. Six testers were used for this phase and they gave feedback weekly as well as six more testers

12 3.4. Survey who were not regular testers. These testers were eventually given the final build of the game and additional people were asked to play the game and fill the survey.

The survey was given to people who had previously played similar games to the game devel- oped for this paper. The player would be asked if they had played either Assassin’s Creed, Prince of Persia, Dishonoured, or similar games. This question was just a check to make sure that people playing the game and taking the survey were active players who have played games similar to these. The players’ demographic was 16-35 age group with both male and female players. All players were who played games regularly.

The questions were designed to judge whether the players were in a state of flow or not, and many questions were based on the study by Brockmyer et al [9] which concentrates on developing a game engagement questionnaire. The study by Brockmyer et al [9] aimed to distinguish which questions would be associated with which state of mind i.e. immersions, flow, absorption, or presence. For this study only questions which indicate either flow or flow and another state of mind were considered.

Below is the table showing different question numbers and the intended flow factor they aim to assess in players. Due to the subjective nature of the questions and their answers each question assesses multiple flow factors. Even a question which might seemingly ask a question related to a specific flow factor, might not only indicate that certain factor alone.

Figure 3.4: Questions and Flow Factors

Figure 3.4 shows the question numbers and Flow factors which the questions are intended to inquire about.

13 3.5. Expert Feedback

3.5 Expert Feedback

The expert feedback would be useful in deciding what features might be added for future works. It will be important in understanding the shortcomings of the design decisions made while developing the game and how the general feel of the game is from the perspective of an industry expert. The expert would be asked to play the last build which would also be given to testers before their survey so the changes suggested by the expert would not be implemented into the game but considered for analyses.

The feedback would be used to analyze what individual features made the game more enjoy- able. It would be difficult to get feedback specifically about whether flow could be induced with certain features but successful games tend to induce flow in players and keep them play- ing so the suggestions might be considered for future work and testing the suggested features for flow.

14 4 Results

4.1 Flow and Game Design Choices

The problem with assessing flow factors in a game comes from the subjective nature of some of the factors. While having a quest or goal is objective but the sense of control is very sub- jective [10].

The objective factors can be addressed through clearly made design decisions. The game developed for this paper has a clearly stated goal i.e. killing the target to progress through to the next level. Immediate feedback was given to the player by highlighting enemies which can be assassinated as well as having a detection meter which tells the player how close the enemy is to detecting them.

The game attempted to achieve a sense of control by using deliberate actions which cannot be cancelled in the middle of animation. This also contributed to the factor of challenge requiring skill to overcome. Further challenge was created by making the enemies difficult to kill. The deliberate actions were also part of the climbing mechanics as well as all methods of traversal and not just the combat. A sense of control was also achieved by creating a dodge ability which allows players to roll away in any direction while taking no damage even if the enemy’s attack connects. This ensures that the player knows that it was their fault for dying and not just a quirk of the game since they always have an action which will save the character if done correctly.

According to the study done by Chou et al [14] the most important design element which encourages flow in gamers is a feeling of control and power over the game, which means having agency when the player controls the character and feeling that no player character behaviour is out of their hands. If mastering a game’s mechanics requires little skills then the players are more likely to play the game and have a higher tendency of achieving flow state. The study by Chou et al [14] was done mostly on mobile games which may not be as relevant to the game created for this paper but is still relevant in the field of game design features that induce flow state. Chou et al [14] also concluded that games where the player character is an extension of the player and the player can identify with or create their own character have the highest chance of inducing flow state.

15 4.2. Game Mechanics and Features

The factors which cannot be determined objectively need to be self reported by the players or analyzed by a professional.

4.2 Game Mechanics and Features

The screenshots below show the game in action and the features are described. The screen- shots are from when the game was completed and handed to testers before taking the survey, and industry expert before getting feedback.

Players start the game on the ground and the randomly generated level is in front of them. They can choose to enter from any side and/or opening. This is shown in Figure 4.1. The current structure is retained until the goal is completed i.e. the target is killed, which is a golden or yellow enemy.

Figure 4.1: Starting Location

Figure 4.2 shows that the player can use enhanced vision to see where the enemies are, the golden enemy is the target which players need to assassinate to win the game. They can use the enhanced vision anytime they like with a 5 second cool down and a 2 second duration. This is kept as such and not as a switch since players may just keep this on and reduce some of the challenge of the game. This way players get only some glimpses of the enemy movement.

16 4.2. Game Mechanics and Features

Figure 4.2: Enhanced Vision

Figure 4.3 shows the inside of the structure without enemies. The floors are mostly open without much obstructions and as can be seen in the figure have missing floor tiles and walls. This was done so the player can go from inside the structure to outside and vice versa, and so the player can go up or down floors from inside the structure and do not need to go outside to climb up or down.

Figure 4.3: Inside the structure

Figure 4.4 shows that the player has the ability to hang from ledges and climb up as they want. Additionally players can move sideways and jump backwards while climbing. This not only helps in traversing the levels but also helps in staying undetected especially from enemies above the player.

17 4.2. Game Mechanics and Features

Figure 4.4: Climbing

Figure 4.5 shows that there is a small window of time when a player has to stay in the enemy line of sight before they are detected and the enemy starts to chase the player. If the player exits the line of sight by being too far from the enemy or having an obstacle which blocks vision the detection meter starts to reduce.

Figure 4.5: Detection

Figure 4.6 shows how you can shift the camera to look at enemies around a wall and study their patrol paths to make informed decisions.

18 4.2. Game Mechanics and Features

Figure 4.6: Hiding

Figure 4.7 is one of the three ways to assassinate enemies. While hanging from a ledge players can press attack button and this will execute an assassination. The target on top of the ledge will be killed as is the case with all kinds of assassinations. The blue highlight will appear on any target that can be assassinated from any of the three ways to assassinate the target. This is used mainly when players need to climb up a ledge but there is an enemy close to the top which would otherwise kill them while in the middle of climbing animation. This way the players can eliminate them and thin down the enemies number before going up a floor to make things easier for them.

Figure 4.7: Ledge Assassination

Figure 4.8 shows an enemy whose back is turned and has not detected the player. The enemy is highlighted and if the player presses the attack button a back-stab will be performed which kills the enemy. Back-stab is a good way to kill enemies on the same floor as you can thin the herd of enemies to make your traversal easier.

19 4.3. Result from Survey

Figure 4.8: Back-stab Assassination

Figure 4.9 shows an enemy on the lower floor from the player and in range to assassinate using aerial assassination. The player can press the attack button and the character will be launched at the enemy and upon landing kill it instantly. This is a good way to kill enemies on lower floors especially if they would likely kill the player as soon as they drop down.

Figure 4.9: Aerial Assassination

4.3 Result from Survey

Below are the results of the survey taken from people who played the final build. The play time varied from 15 minutes to several hours. Only people who have played similar games previously were asked to play and fill the survey.

20 4.3. Result from Survey

Figure 4.10: Survey Question 1 Results

Figure 4.11: Survey Question 2 Results

Figure 4.12: Survey Question 3 Results

21 4.3. Result from Survey

Figure 4.13: Survey Question 4 Results

Figure 4.14: Survey Question 5 Results

Figure 4.15: Survey Question 6 Results

22 4.3. Result from Survey

Figure 4.16: Survey Question 7 Results

Figure 4.17: Survey Question 8 Results

Figure 4.18: Survey Question 9 Results

23 4.3. Result from Survey

Figure 4.19: Survey Question 10 Results

Figure 4.20: Survey Question 11 Results

Figure 4.21: Survey Question 12 Results

After the results were acquired if the answers were send from the same email twice then the duplicates were removed as well as answers from people who were suspected of not playing the game for at least 15 minutes.

24 4.4. Expert Feedback

4.4 Expert Feedback

The feedback from the expert was mainly focused on whether or not the game would be viable commercially or not. The expert felt that the lack of feedback to the player concerning when they are detected, when they are attacked, and when they are in danger is going to make the game a lot harder to understand.

The problem with players not getting feedback, as told by the expert, could be solved in different ways, i.e. adding sound to different events and actions, and other types of feedback. The low feedback problem also makes mistakes made by player very punishing making the game harder than it needs to.

The expert suggested that stealth game play is hard to create if the levels are procedurally generated with very basic building blocks and at the very least the levels need waist high cover and a crouching system for players to hide behind if stealth game play needs to be encouraged, as well as enemies need a visual indication that they have detected the player which may come in the form of an overlay, UI elements, or a switch from walking while patrolling to running while searching for the player.

The expert also suggested that normally if a specific style of gameplay needs to be encouraged than the procedural generation of the level uses smaller hand crafted blocks of a level which are then stitched together to create a level which can support stealth reasonably. The game at the moment is too randomly generated for it to encourage stealth game play.

The expert also suggested additional features which will help make the game a lot better.

- Heavy guards that cannot be assassinated.

- Different patrolling behaviour for some guards i.e. some guards just stand and look in a certain direction and others may patrol the area as well as having either random patrolling or fixed patrol points for some guards.

- Lowering the density of the guards in a floor.

- Making sure there is adequate pathing opportunity for the player.

- Stealth games should not be focused on speed

The above along with places to hide are important since at the moment it is hard to get rid of an enemy chasing you without assassination or climbing up and down the level which is made harder since there is a climb down button which makes traversal a bit less intuitive.

The feedback from the expert is highly valuable but the game developed at the moment does tend to favour a development path where a fast paced multiplayer experience is created rather than a stealth based assassination game play. This can be rectified by changes done according to the feedback from the expert.

25 5 Discussion

5.1 Survey

The aggregate result of the study is shown below in Figure 5.1. The mostly positive response to most questions suggests that most players were in a state of flow while playing the game. The study aimed at isolating gameplay from visual appeal or sounds which means that the game play and mechanics themselves were enough to induce a state of flow in players.

Strongly Disagree Disagree Neutral Agree Strongly Agree 28 25 68 104 116

Figure 5.1: Aggregate Result

A considerable number of people may not have experienced flow according to the survey and this could be due to a few reasons. The game developed had no music, no sound, and no superfluous features which may increase a players engagement and enjoyment which could then increase the chances of inducing a flow state. Those reasons as well as the simple graph- ics would make a lot of players unwilling to play the game. The gameplay and mechanics can be interesting on their own but the absence of great visuals or sound would make the game less engaging. This might be the cause of some of the testers not feeling a state of flow.

A fair amount of the negative responses are from question 5 which asked if players were willing to play even after they lost a few times which might indicate that players are unwilling to play a game if it is too hard for them. The game has deliberately hard melee combat and powerful enemies to encourage stealth game play and assassinations rather than direct combat. Although it might have been far too hard and discouraged players from playing more due to it seeming unfair and frustrating. This is still uncertain as the question may not have been precise enough since it asked if the player was willing to play even after ’a few’ deaths, and ’a few’ in this context may mean different things to different types of players.

26 5.1. Survey

Question 5 was supposed to judge if challenge truly increases chances of flow and if flow was achieved the players would have been willing to play even if they died but it seems that some players found the game quite difficult and the challenge was too great for them to keep playing and was detrimental to inducing flow.

The last two questions also had more negative responses than most and question 4 had a lot of neutral responses. All three questions are about being unaware of your real world surround- ings while playing the game. These questions may be seen as accusatory and may seem to players as admitting a weakness due to their inability to stay aware of their surrounding or it may be simply that the players were not lost in the game which may have been because of the simple graphics, lack of sound, or that they simply didn’t find the gameplay very engaging.

27 6 Conclusion

The survey results indicate that players experienced a state of flow while playing the game. Flow in this context is defined by previous studies on flow in video games and as a psycholog- ical phenomenon. Further testing with more players as well as better behaviour monitoring by professionals would be better than players self reporting their experience.

6.1 Research Question

1. How to design a minimalist rogue-like assassination game in Unreal Engine to facilitate a high degree of flow?

The research question was answered considering the results of the survey as most players reported having an experience which indicates that the game mechanics and gameplay do induce flow. Considering the data size, we can not say with certainty if that would be the case for most of the target audience i.e. active gamers especially those who play similar games, but it does indicate that it is possible since most players who took the survey were active gamers who played games similar to the one developed in the project and reported experiences indicating a state of flow.

The results of the paper would suggest that game design features like climbing mechanics, assassinations, difficult enemies, weak player characters, fast paced game play, and deliberate actions i.e. once a button is pressed there is no action canceling, all these features contribute to inducing flow in the players.

The procedurally generated levels along with the above stated features seem to help in induc- ing flow in players since it consistently brings them challenges to overcome. A better study for this would be one where the players can encounter levels with different level generation parameters. Like the study done by Pedersen et al [15] the procedural generation can have different percentages of holes in walls and floors for the game developed and the entropy of holes as well i.e. in which part of the level holes more or less often. These changes could indicate what kind of level generation may encourage or discourage flow more accurately.

28 6.1. Research Question

Further testing can be done on how a larger or smaller map, and using different arena shapes or even different aesthetics can affect the induction of flow.

29 7 Limitations and Future Work

There are a lot of features that would be needed for the game to be commercially viable. At this point, the game is very simple when it comes to graphics and has no added effects. The game having no sound or music is deliberate since the aim of the project was to find out game design choices which will cause a state of flow in the player. For this reason things like sound and other superfluous effects were not added so the testers can form opinions about the mechanics and game play without being influenced by other factors. Any feature like particle effects, better graphics, sound, and music will increase the player’s enjoyment and engagement in spite of game play or mechanics and hence should not be added if the aim is to determine the game design choices which cause players to enter a state of flow.

Although it is possible that these superfluous things may inherently increase the likelihood of inducing flow, it might be important to study the effects of these features on the likelihood of a player reaching flow state with or without engaging game play or mechanics. It may be an interesting study to test what features induce a state of flow by creating a game with switches for all mechanics and features like assassinations, climbing as well as different en- emy behaviour, different player and enemy strength, music, sound, and particle effects, to judge what combination of features is the most crucial when it comes to inducing flow in players and which features contribute to what degree. This would require extensively test- ing the game with different combinations of switches and a larger set of testers using formal testing.

One of the most important features would be implementation of multiplayer functionality with a ranking system to match players with other players of equivalent skill level which can be determined by a rating system. This will use the fast paced nature of the game to create quick matches between players where they compete to assassinate the target first. Due to the shorter nature of matches compared to the time taken to find players and the want for players to compete with certain players to learn and adapt for them, one set of players can have ten matches with each other at a time and at the end of the ten rounds we can determine the ranking.

Another interesting feature could be the addition of an alarming system where the enemies can alert each other of the player’s location which will force the player to prioritize stealth

30 and assassinations even more. Currently the only sense enemies have is sight by which to observe the player character and it takes them a set detection time to detect a player. The perception system from Unreal can be used to implement hearing as well which might be a possible implementation of the alarming system to alert all enemies. If an enemy can make a noise which other enemies can be alerted by, that could work as an interesting alarm system which uses the perception in Unreal. Further testing and work is needed on the behaviour of enemies to make it more engaging and difficulty should be adjusted by making enemies behave differently. The enemies could be allowed to climb up or down the levels just like the player can and or stairs can be added randomly between levels so enemies can chase the player through different floors which is not implemented at the moment.

The informal testers were informed about the objective, win conditions, and loss conditions for the game before they began testing. This should be made more intuitive or explained through text and game design to clearly tell the player about the objective of the game as well as the win and lose conditions.

31 8 Appendix

8.1 Questions for the testers

1. Have you played any of these games? You can check multiple games.

2. My curiosity was peaked while playing the game?

3. The game mechanics were interesting to me?

4. I was entirely absorbed in the game?

5. I wanted to play the game even after I lost a few times?

6. I was scared or had a feeling of rush when enemies were chasing me?

7. It was hard to stop playing?

8. I lost track of time?

9. After some time playing the game seemed automatic and I did not have to think about the keys I was pressing?

10. After playing for a time, I don’t have to think about my actions?

11. I feel spaced out when playing the game?

12. While playing I am less responsive to real world sounds?

32 Bibliography

[1] Elizabeth A. Boyle, Thomas M. Connolly, Thomas Hainey, and James M. Boyle. “En- gagement in digital entertainment games: A systematic review”. en. In: Computers in Human Behavior 28.3 (May 2012), pp. 771–780. ISSN: 07475632. DOI: 10.1016/j.chb. 2011.11.020. URL: https://linkinghub.elsevier.com/retrieve/pii/ S0747563211002640 (visited on 10/15/2020). [2] Kevin Durkin and Bonnie Barber. “Not so doomed: computer game play and posi- tive adolescent development”. In: Journal of Applied Developmental Psychology 23.4 (Nov. 2002), pp. 373–392. ISSN: 01933973. DOI: 10.1016/S0193-3973(02)00124-7. URL: https://linkinghub.elsevier.com/retrieve/pii/S0193397302001247 (visited on 12/26/2020). [3] Sibel Çoban and I. Tuncer. “An experimental study of game-based music education of primary school children”. In: Proceedings of the European Conference on Games-based Learning 2008 (Jan. 1, 2008), pp. 85–94. [4] C. M. Kanode and H. M. Haddad. “Software Engineering Challenges in Game Devel- opment”. In: 2009 Sixth International Conference on Information Technology: New Gener- ations. 2009 Sixth International Conference on Information Technology: New Genera- tions. Apr. 2009, pp. 260–265. DOI: 10.1109/ITNG.2009.74. [5] [PDF] Player-Centred Game Design: Experiences in Using Scenario Study to Inform Design | Semantic Scholar. URL: https : / / www . semanticscholar . org / paper/Player- Centred- Game- Design%3A- Experiences- in- Using- to- Ermi-M%C3%A4yr%C3%A4/84c42457ce0af75d1ec864902f2362ed06668e19? p2df (visited on 10/16/2020). [6] Penelope Sweetser and Peta Wyeth. “GameFlow: a model for evaluating player enjoy- ment in games”. en. In: Computers in Entertainment 3.3 (July 2005), pp. 3–3. ISSN: 1544- 3574, 1544-3574. DOI: 10.1145/1077246.1077253. URL: https://dl.acm.org/ doi/10.1145/1077246.1077253 (visited on 10/15/2020). [7] Werner Wirth, Tilo Hartmann, Saskia Böcking, Peter Vorderer, Christoph Klimmt, Hol- ger Schramm, Timo Saari, Jari Laarni, Niklas Ravaja, Feliz Ribeiro Gouveia, Frank Biocca, Ana Sacau, Lutz Jäncke, Thomas Baumgartner, and Petra Jäncke. “A Pro- cess Model of the Formation of Spatial Presence Experiences”. In: Media Psychol- ogy 9.3 (May 15, 2007), pp. 493–525. ISSN: 1521-3269, 1532-785X. DOI: 10 . 1080 /

33 Bibliography

15213260701283079. URL: http : / / www . tandfonline . com / doi / abs / 10 . 1080/15213260701283079 (visited on 10/16/2020). [8] Wilfried Admiraal, Jantina Huizenga, Sanne Akkerman, and Geert ten Dam. “The concept of flow in collaborative game-based learning”. en. In: Computers in Human Behavior 27.3 (May 2011), pp. 1185–1194. ISSN: 07475632. DOI: 10 . 1016 / j . chb . 2010.12.013. URL: https://linkinghub.elsevier.com/retrieve/pii/ S0747563210003808 (visited on 10/15/2020). [9] Christine Fox and Jeanne Brockmyer. “The Development of the Game Engagement Questionnaire: A Measure of Engagement in Video Game Playing: Response to Re- views”. In: Interacting with Computers 25 (June 2013), pp. 290–293. DOI: 10.1093/iwc/ iwt003. [10] Nicola Whitton. “Game Engagement Theory and Adult Learning”. In: Simulation & Gaming 42.5 (Oct. 2011). Publisher: SAGE Publications Inc, pp. 596–609. ISSN: 1046- 8781. DOI: 10.1177/1046878110378587. URL: https://doi.org/10.1177/ 1046878110378587 (visited on 10/15/2020). [11] User experience evaluation methods | Proceedings of the 6th Nordic Conference on Human- Computer Interaction: Extending Boundaries. URL: https : / / dl . acm . org / doi / abs / 10 . 1145 / 1868914 . 1868973 ? casa _ token = CsUNn5sQbmwAAAAA : oSriYYAx38_Sr5aZRogOqwq9fl942hGFlvOsBdeOXhroPh28Lxrt40bOYi-SpA_ OhJgYclM3DIsM (visited on 10/16/2020). [12] S. Rajeshkumar, R. Omar, and M. Mahmud. “Taxonomies of User Experience (UX) eval- uation methods”. In: 2013 International Conference on Research and Innovation in Informa- tion Systems (ICRIIS). 2013 International Conference on Research and Innovation in In- formation Systems (ICRIIS). ISSN: 2324-8157. Nov. 2013, pp. 533–538. DOI: 10.1109/ ICRIIS.2013.6716765. [13] Gillian Smith. “Understanding procedural content generation: a design-centric analysis of the role of PCG in games”. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI ’14. New York, NY, USA: Association for Computing Ma- chinery, Apr. 2014, pp. 917–926. ISBN: 978-1-4503-2473-1. DOI: 10.1145/2556288. 2557341. URL: https : / / doi . org / 10 . 1145 / 2556288 . 2557341 (visited on 10/16/2020). [14] J. C. Chou, C. Hung, and Y. Hung. “Design factors of mobile game for increasing ’s flow experience”. In: 2014 IEEE International Conference on Management of Inno- vation and Technology. Sept. 2014, pp. 137–139. DOI: 10.1109/ICMIT.2014.6942414. [15] Chris Pedersen, Julian Togelius, and Georgios N. Yannakakis. “Optimization of plat- form game levels for player experience”. en. In: (2009). Accepted: 2017-10-24T07:55:21Z Publisher: ACM Publications. URL: https://www.um.edu.mt/library/oar/ handle/123456789/22943 (visited on 10/16/2020).

34