EnviroCircuit Designing Immersive VR Racing Experiences for Different Levels of Player Experience Master’s thesis in Computer science and engineering RIK MUIJS Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2023 Master’s thesis 2023 EnviroCircuit Designing Immersive VR Racing Experiences for Different Levels of Player Experience RIK MUIJS Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2023 EnviroCircuit Designing Immersive VR Racing Experiences for Different Levels of Player Experi- ence RIK MUIJS © RIK MUIJS, 2023. Supervisor: Staffan Björk, Department of Computer Science and Engineering Advisor: Stefano Oliva, Lynk & Co Prospective Design Examiner: Mikael Wiberg, Department of Computer Science and Engineering Master’s Thesis 2023 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: The three unique environments that were created. The City track (top left), the Forest Track (top right), and the Space track (bottom centre). Typeset in LATEX Gothenburg, Sweden 2023 iv EnviroCircuit Designing Immersive VR Racing Experiences for Different Levels of Player Experi- ence RIK MUIJS Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Abstract This thesis explores how to design immersive virtual reality (VR) racing experiences for different levels of player experience. The thesis follows an iterative design process that involves discovering, designing, prototyping, and evaluating three different VR racing prototypes. The thesis presents a set of guidelines for designing immersive VR racing experiences and a functional prototype. The guidelines can be consid- ered by future researchers and designers when wanting to develop immersive racing experiences, and as a result make these experiences more easily accessible for people with various amounts of experience with virtual racing. Keywords: Racing, Immersion, VR, Interaction Design, Game Design, Video Game, Immersive Experience. v Acknowledgements I would like to thank my academic supervisor Staffan Björk for his excellent super- vision by helping the thesis move towards the right directions. I would also like to thank Stefano Oliva and Simon Lamarre for providing me with the opportunity to do this thesis within Lynk&Co and giving valuable comments and support throughout the thesis. I would like to thank the employees at Lynk&Co and students at Chalmers who took their time and gave their valuable feedback during the evaluation sessions. Finally, I would like express my gratitude to my partner Lucy for supporting me throughout the thesis, this process would have been much more exhausting without you. Rik Muijs, Gothenburg, June 2023 vii Contents List of Figures xiii 1 Introduction 1 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Background 3 2.1 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Sim Racing Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 iRacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2 rFactor 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.3 Live for speed . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Arcade Racing Games . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Mario Kart™ 8 Deluxe . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Need for Speed™ Unbound . . . . . . . . . . . . . . . . . . . . 7 3 Theory 9 3.1 Immersion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Comparing immersion, flow, and presence . . . . . . . . . . . . . . . . 11 3.5 Dynamic Difficulty Adjustment . . . . . . . . . . . . . . . . . . . . . 11 3.6 Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Methodology 15 4.1 Discovering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.2 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.4 Pilot study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5 Iterative Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.2 Sprint Reviewing . . . . . . . . . . . . . . . . . . . . . . . . . 20 ix Contents 4.6.3 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . 20 5 Process 21 5.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.2 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.2.1 Exploring initial requirements . . . . . . . . . . . . . 23 5.2.2.2 Sprint layout . . . . . . . . . . . . . . . . . . . . . . 23 5.2.2.3 Changing requirements . . . . . . . . . . . . . . . . . 24 5.2.2.4 Prototyping . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.2.5 Evaluating . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.2.6 Finalisation . . . . . . . . . . . . . . . . . . . . . . . 24 5.3 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.3 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4.1.1 Environments . . . . . . . . . . . . . . . . . . . . . . 31 5.4.1.2 Interaction . . . . . . . . . . . . . . . . . . . . . . . 32 5.4.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4.2.1 Choosing of environments . . . . . . . . . . . . . . . 33 5.4.2.2 Vehicle sounds . . . . . . . . . . . . . . . . . . . . . 34 5.4.2.3 Increasing Engagement . . . . . . . . . . . . . . . . . 34 5.4.2.4 VR Development . . . . . . . . . . . . . . . . . . . . 34 5.4.2.5 Creation of Environments . . . . . . . . . . . . . . . 36 5.4.3 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5 Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.5.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.5.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.5.3 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Final Results 47 6.1 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.1 Forest Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.2 City Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1.3 Space Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.1 The type of player one is designing for . . . . . . . . . . . . . 52 6.2.2 The amount of motion the player is experiencing . . . . . . . . 54 6.2.3 The audio that is being played . . . . . . . . . . . . . . . . . . 54 6.2.4 The challenge of the experience . . . . . . . . . . . . . . . . . 55 6.2.5 How the vehicle behaves according to player input . . . . . . . 55 x Contents 6.2.6 How the behaviour of the vehicle is communicated to the player 55 6.2.7 The design of the track . . . . . . . . . . . . . . . . . . . . . . 56 6.2.8 The design of the game elements . . . . . . . . . . . . . . . . 57 7 Discussion 59 7.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2.2 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.3 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.4.1 Multiplayer Mode . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.4.2 Increasing Inclusiveness . . . . . . . . . . . . . . . . . . . . . 64 7.4.3 Hardware and Interactions . . . . . . . . . . . . . . . . . . . . 65 8 Conclusion 67 Bibliography 69 A Appendix 1 - Persona and Scenario I B Appendix 2 - Consent Form III C Appendix 3 - Interview Questions V xi Contents xii List of Figures 2.1 iRacing [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 rFactor2 [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Mario Kart™ 8 Deluxe, image taken from Nintendo’s website [12] . . 6 2.4 Need for Speed™ Unbound, image taken from EA’s website [13] . . . 7 3.1 The concept of flow. One can see from the figure that when challenges exceed the person’s skills it will result in them feeling anxiety. On the other hand, if skills exceed the challenge, it will result in the person feeling boredom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 An example of the game Tic-Tac-Toe being made into a game tree. The nodes represent the state of the game, while the edges represent if the player can reach the given state within one action image taken from Gobet et al. [29, p.13] . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 The relationship between the four basic phases of Interaction Design. Taken from Sharp et al. [35, p.52] . . . . . . . . . . . . . . . . . . . . 15 5.1 The schedule created at the start of the project . . . . . . . . . . . . 22 5.2 Gantt chart for the planned schedule . . . . . . . . . . . . . . . . . . 25 5.3 Player Experience goals created at the start of the project . . . . . . 26 5.4 Examples of game elements that can be included in the prototype to achieve the experience goal ‘Getting consumed by the virtual envi- ronment’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.5 The first iteration of the vehicle the player controlled . . . . . . . . . 28 5.6 The first iteration of the track the player had to drive around . . . . 28 5.7 The second iteration of the vehicle the player controlled . . . . . . . . 29 5.8 The second iteration of the track the player had to drive around . . . 29 5.9 The ghost player model . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.10 A more exciting track was created which included a jump . . . . . . . 34 5.11 A diegetic timer seen at the side of the track . . . . . . . . . . . . . . 35 5.12 The player driving out of a tunnel in the Forest track . . . . . . . . . 36 5.13 One of the many views one can see when driving around the City track 37 5.14 Three iterations of Space tracks . . . . . . . . . . . . . . . . . . . . . 38 5.15 A castle was put on the mountain on the Forest track . . . . . . . . . 42 5.16 Robots were added to the City track, and the coins were changed to gas canisters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 xiii List of Figures 5.17 The final iteration of the Space track. It has boarders around the edges to prevent the player from falling off. Different asteroids and planets are positioned around the track. . . . . . . . . . . . . . . . . 43 5.18 Asteroids, planets, coins, and explosions can be seen around the player in the Space track. . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1 The Forest track lets the player sit back and enjoy their surroundings 47 6.2 The City track lets the player experience the thrill of racing in a futuristic city . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3 The Space track lets the player experience the crazy possibilities that Virtual Reality can provide . . . . . . . . . . . . . . . . . . . . . . . 50 6.4 The score the player accumulates can be seen on the vehicle . . . . . 51 6.5 A player performing a mini-turbo in Mario Kart™ Tour . . . . . . . . 56 6.6 The Forest track as seen from the top, is easier to drive on, as it has wide turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.7 The City track seen from the top. It has many sharp turns, making it harder to drive on . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 xiv 1 Introduction As Virtual Reality technology increases in popularity, so does the importance of research into its effect on individuals using it. One of the common effects Virtual Reality has is the feeling of being immersed in the experience. According to Jennet et al. [1], immersion has three impacts on the individual: lack of awareness of time; loss of awareness of the real world; involvement and a sense of being in the task environment. Furthermore, the authors also state that "immersion is key to a good gaming experience". From this we can say that immersion is an important criteria to meet when designing experiences. This thesis will be done in collaboration with Lynk&Co’s Prospective Design team [2] to examine what should be considered when designing an immersive experience in the racing genre specifically. 1.1 Purpose This thesis will go through how one can design and implement a racing experience in such a way as to have a high amount of immersion for people with a variety of experience levels. This is to let as many individuals experience the feeling of immer- sion as possible, thus also increasing the accessibility and quality of the experience. This gives us the projects research question which is: What should be considered when designing a virtual reality racing expe- rience to increase the feeling of immersion for a variety of experience levels? The final result will thus include a comprehensive set of guidelines, as well as the final functional digital prototype, aimed at addressing the research problem at hand. Knowing what one needs to consider when designing for a variety of players will help with getting a better understanding of what aspects of the experience are important to include, or not to include to get the feeling of immersion. This will make it easier for designers to know what to consider when wanting to develop immersive racing experiences, and as a result make these experiences more easily accessible for people with various amounts of experience with virtual racing. 1 1. Introduction 1.2 Limitation Because this study has to be done within a certain time frame, there will be some limitations. Firstly, the outcome will purely be in the form of guidelines and a prototype, no quantitative analysis will be done from the test results. Second, the evaluated experience will be limited to a single player experience only, no computer or human controlled characters and their effect on the player will be studied. The player will only be able to drive around a closed track and not in an open-world environment. As for the hardware, the study will only consider the experience being in Virtual Reality (VR), it will not look at any other emergent technologies such as Augmented Reality (AR) or Mixed Reality (MR) or the differences between them. Furthermore, the prototype will be implemented to work for computers only, it will not be designed for console, mobile, or handheld devices. Lastly, the user group that will be studied will be between the age of 18 and 55. 2 2 Background This chapter introduces the main stakeholders involved in the thesis. It also de- scribes some examples of existing racing games in different sub-genres and their features and characteristics. 2.1 Stakeholders There are a total of three main stakeholders for this thesis project. Each of them will be given a brief description of their background and why they are considered a stakeholder. Lynk & Co This automotive brand can best be described from the following quote taken from Lynk&Co’s [2] parent company Geely’s own website [3]: LYNK & CO is a global automotive brand formed as a joint venture between Geely Auto Group and Volvo Car Group that dares to challenge the established automotive industry with an offering that meets the needs and requirements of a new generation of globally connected consumer. Lynk & Co is on a quest to turn the automobile industry upside down by making mobility more flexible and hassle-free with their competitive car subscription prices [2]. Not only that, they are going above and beyond to give their customers the "wow" factor. Currently, Lynk & Co’s Prospective Design team is exploring areas outside the automobile industry, one being gaming experiences such as virtual racing. They are looking into how one can design and develop an immersive racing experience and they have given the task of exploring this with them to university students. The Author The author of this report, Rik Muijs, is singularly responsible for all components in this study. These responsibilities include, but are not limited to: design, develop- ment and evaluation of the prototype; creation of guidelines; writing of the thesis report; communication and collaboration with relevant individuals or organisations. 3 2. Background Chalmers University of Technology This study will be done within Chalmers University of Technology [4]. The university has their own set of requirements and deadlines which are expected to be met in order for it to be counted as completed [5]. Chalmers will support this study by supplying an academic supervisor and examiner who will ensure the process and results of the study are as high quality as possible. Chalmers might also support this study through financial contributions such as the purchase or letting of equipment or digital assets. 2.2 Sim Racing Games Sim racing is a sub-genre of racing games which focus on making the racing ex- perience as realistic as possible. Noteworthy sim racing games include iRacing [6], rFactor 2 [7], and Live for speed [8] and will be described further in Section 2.2.1, 2.2.2, and 2.2.3 respectively. 2.2.1 iRacing The following section is taken from the iRacing website [6]: iRacing puts you in the driver’s seat by allowing members to experience today’s newest form of competitive motorsport: virtual racing. iRacing is a fun, inexpensive and highly-competitive way for race fans and gamers to break a sweat by braking hard at the apex, while overcoming head-to-head racing challenges usually reserved for professional racers. iRacing is a subscription based service created for competitive racing. It includes more then 100 tracks and vehicles for players to choose from. Players pay a monthly fee in order to race against other players and compete in leagues. The game is also compatible with VR headsets. An image of someone playing iRacing can be seen in Figure 2.1. 2.2.2 rFactor 2 The following text was taken from the rFactor website [7]: The newest creation, rFactor 2, creates a dynamic racing environment that for the first time puts you the driver into a racing simulator, instead of just a physics simulator. Changing tires, track surfaces, grip, weather and lighting make rFactor 2 a true challenge to any sim racer. rFactor 2 is the second installment of the rFactor series and available for a set price. It offers online racing against other players and offline racing against Artificial Intelligence. There are numerous vehicles and tracks available for the player to download. It has high-end graphics and audio, with the addition of VR support. An in game screenshot of rFactor 2 can be seen in Figure 2.2. 4 2. Background Figure 2.1: iRacing [6] 2.2.3 Live for speed ‘Live for Speed is a serious racing simulator. No arcade modes, no steering aids - YOU have to do the driving.’ [9]. Live for speed is a free sim racing game, it offers realistic vehicle physics and sounds with the addition of VR support. However, it does not have high quality graphics. Players can play on one track and choose between three free vehicles, additional vehicles and tracks are available for purchase. 2.3 Arcade Racing Games Arcade style racing games are another sub-genre of racing games, these are racing games of the style played on old-school arcade machines. These games are less realistic but instead focus more on a fun and fast-paced experience. Typical features for these types of games are power-ups to boost the speed of the vehicle, ramps on the track, and abilities that sabotage the other players on the track to give you an advantage. Some examples of arcade racing games are games from the Mario Kart™ franchise such as Mario Kart™ 8 Deluxe [10] or Need for Speed™ Unbound [11] from the Need for Speed™ franchise. These two games will be discussed in Section 2.3.1 and 2.3.2 respectively. 5 2. Background Figure 2.2: rFactor2 [7] 2.3.1 Mario Kart™ 8 Deluxe Released on the Nintendo Switch in 2017, Mario Kart 8 Deluxe is currently the latest Mario Kart game in the franchise. It offers 48 courses, 40+ characters, and allows for up to 12 players to compete against each other [10]. During the race, the players can use different items which can help them get the upper-hand over their opponents. An image of Mario Kart™ 8 Deluxe can be seen in Figure 2.3 Figure 2.3: Mario Kart™ 8 Deluxe, image taken from Nintendo’s website [12] 6 2. Background 2.3.2 Need for Speed™ Unbound The following description has been taken from EA’s1 website [11] Race against time, outsmart the cops, and take on weekly qualifiers to reach The Grand, Lakeshore’s ultimate street racing challenge. Pack your garage with precision-tuned, custom rides and light up the streets with your style, exclusive fits, and a vibrant global soundtrack that bumps in every corner of the world. Need for Speed™ Unbound stands out with its unique visual style by mixing realistic- with cartoon style graphics. An example of this visual style can be seen in Figure 2.4. The game lets the player embark on a journey through an open world. The player can do various activities such as exploring the open world, racing against other vehicles, or trying to escape the police. Races often happen right in the middle of the city, so the player will have to act quickly by dodging traffic, pedestrians, and buildings. Figure 2.4: Need for Speed™ Unbound, image taken from EA’s website [13] 1Electronic Arts (EA) is the interactive entertainment software company who created Need for Speed™ Unbound 7 2. Background 8 3 Theory This chapter will go through important and relevant theories for this thesis. These include: immersion, flow, presence, dynamic difficulty adjustment, and virtual re- ality. The difference between immersion, flow, and presence will also be briefly described. 3.1 Immersion Let us start by defining what an immersive feeling actually means. In its most basic form, according to Jennet et al. [1] immersion is the extent to which a person’s attention is focused on the game. The authors further define immersion by stating that it produces the following effects: lack of awareness of time; loss of awareness of the real world; involvement and a sense of being in the task environment. Further- more, Brown [14], explored a grounded theory on immersion and states that levels of involvement with a game can be seen in three distinct degrees: engagement, engrossment, and total immersion. A taxonomy dividing immersion along three orthogonal dimensions also exists to better differentiate the different uses of immersion [15]. These dimensions being: immersion as a property of the system; immersion as a response to an unfolding narrative, the diegetic space, or virtual characters; and immersion as a response to challenges demanding use of one’s intellect or sensorimotor skills. There are two main ways to measure immersion, namely through questionnaires [1], [16] or physiological signals [17]. Looking more closely at the structure of the questionnaires, Jennett et al. [1] divide the questions into eight distinct categories. These categories are: basic attention, temporal dissociation, transportation, chal- lenge, emotional involvement, and enjoyment. On the other hand, Qin et al. [16] divides these into the following categories: curiosity, concentration, challenge and skills, control, comprehension, and familiarity. The differences of these question- naires could lay in the method each of the authors used in their studies. For exam- ple, Jennet et al. had participants do tasks in an immersive, or a non immersive task, and afterwards fill in their questionnaire, which was later evaluated. Qin et al. on the other hand asked participants to ‘imagine a familiar game with a story frame while answering the questions about player immersion in the computer game narrative’ [16, p.119]. This could suggest that Jennet et al. had a more sophisticated 9 3. Theory approach to the creation of the questionnaire. 3.2 Flow The concept of flow has been extensively studied by Csikszentmihalyi [18]. Ac- cording to his studies ‘flow is a subjective state that people report when they are completely involved in something to the point of forgetting time, fatigue, and ev- erything else but the activity itself’ [18, p.230]. Furthermore in order for someone to get into flow, Csikszentmihalyi concluded that three main conditions have to be met. Firstly, the activity needs to contain a ‘clear set of goals’. Secondly, there needs to be ‘a balance between perceived challenges and perceived skills’. Finally, there needs to be ‘clear and immediate feedback’ [18, p.232]. In the second condition, if challenges exceed the person’s skills it will result in anxiety and if skills exceed the challenge, it will result in boredom [18]. A visual representation of this described concept can be seen in Figure 3.1. It is thus important to keep a good balance between challenge and player skills in order for the player to feel the sense of flow. Further information regarding game challenge is discussed in Section 3.5. Figure 3.1: The concept of flow. One can see from the figure that when challenges exceed the person’s skills it will result in them feeling anxiety. On the other hand, if skills exceed the challenge, it will result in the person feeling boredom 3.3 Presence According to Witmer and Singer [19] ‘presence is defined as the subjective experience of being in one place or environment, even when one is physically situated in another’. 10 3. Theory Felton and Jackson [20] state that presence consist of two core dimensions: spatial presence and social presence. The authors state that ‘spatial presence refers to the subjective sense that one is physically located within the perceived environment and subject to any physical consequences therein’. While ‘Social presence refers to the degree to which another animate entity appears to coexist in the same environment as the user’. 3.4 Comparing immersion, flow, and presence Immersion has been compared with similar concepts such as flow and presence [15], [21]. Michailidis et al. [21] state that flow and immersion do not appear as concep- tually distinct and can be used interchangeably, however, presence and immersion are not the same as presence is enveloped in immersion. We can clearly see that presence is enveloped in immersion as one of the main features of immersion - the sense of being in the task environment - is incredibly similar, if not identical, to the concept of spatial presence. Mechailidis et al.’s view on the difference between flow and immersion clashes against that of Jennett et al. [1]. Jennet et al. argue that, even if a game does not have a clear goal or direct feedback - the two conditions that have to be met in order for someone to experience flow - it can still be capable of giving the individual an immersive experience. 3.5 Dynamic Difficulty Adjustment To give the player an appropriate challenge, one first has to know the skills that player holds. This is commonly done with pregame profiling with, for example, a selection of difficulty levels [22]. However, this neglects the fact that the player is a dynamic entity and will adapt to the selected difficulty [23], [24]. Dynamic difficulty adjustment (DDA) thus aims to solve this problem, by dynamically changing the difficulty during the course of the game. There have been different papers studying DDA on experiences and games [24]–[26]. DDA has been shown to improve the gaming experience. For example, Paraschos and Koulouriotis [26] state that ‘the players favor the dynamic game environments over the static ones, as they can offer them more challenging tasks and therefore improve their overall gaming experience’ [p.13]. Furthemore, Paraschos and Koulouriotis also state that numerous studies suggest that ‘the players feel more immersed when the game content or environment is adapted or personalized according to their exhibited emotions’ [p.13]. DDA relies on knowledge of the player skill level and game difficulty, this difficulty is then dynamically changed in order to match the player abilities. We will now look further into the ways in which player abilities and game difficulty are usually measured. Note that the player skill is enveloped in the difficulty of the game, this is because the way the player perceives the difficulty is dependent on their skill. There is therefore an overlap of definition between measuring player skill and game difficulty. Dziedzic [24] suggests there are three ways to measure the difficulty of a game: using 11 3. Theory the formal model of gameplay, using the features of the game, and direct examination of the player. When using the formal model of gameplay, ‘DDA systems are based on the analysis of the structure of the game tree’ [24, p.709]. The nodes of the game tree contain each possible state of the game, with each edge representing if the player can reach that state within one action. This method of evaluating difficulty is suitable in, for example, a board game such as chess, as these types of games are predictable and thus suitable to be modelled into game trees. An example of using the formal model of gameplay on a game of Tic-Tac-Toe can be seen in Figure 3.2. The second way - using the features of the game to determine difficulty - is used ‘where the formal model is not known or it is too complicated to it – due to a large number of moves the player can make it is not possible to create a full game tree’ [24, p.709, 710]. Here we can use both characteristics from game elements and player performance to evaluate the difficulty. For game element parameters, this could for example be the number of enemies alive in a shooter game. For player performance characteristics, this could be the percentage of time that the player is off the track, and the average speed of the car in a racing game [27]. For parkour games, player performance characteristics can be the amount of obstacles the player has passed [28]. Lastly, direct examination of the player is where ‘designers of DDA systems analyze the difficulty perceived by the player instead of elements of the gameplay’ [24, p.710]. One could for example do this with the examination of physiological signals [17]. Figure 3.2: An example of the game Tic-Tac-Toe being made into a game tree. The nodes represent the state of the game, while the edges represent if the player can reach the given state within one action image taken from Gobet et al. [29, p.13] 12 3. Theory 3.6 Virtual Reality In short, ‘Virtual Reality (VR) is an advanced, human-computer interface that sim- ulates a realistic environment’ [30]. Its ‘central objective is to place the participant in a virtual environment that gives the participant a feeling of “being there.”’ [30]. This is done by wearing what is called a Head Mounted Display (HMD). There have been numerous studies stating that VR has a positive effect on immersion [31], [32]. However, one major problem with VR is that it can cause so called "cybersickness". [33]. Rebenitsch and Owen state that the most common source of cybersickness is sensory mismatch. This is where ‘stimuli from the outside environment [is] being perceived differently by different senses’ [33, p.105]. Furthermore, Saredakis et al. [34] found that gaming content induced the highest amount of sickness. 13 3. Theory 14 4 Methodology This chapter will go over the different methodological concepts that are relevant for this study. Starting with describing the process of Interaction Design, according to Sharp et al. [35] this process can be divided into four basic phases, namely, dis- cover, design, prototype, and evaluate [35, p.50]. A similar process is described by Cooper et al. [36], namely, Research, Modeling, Requirements Definition, Frame- work Definition, Refinement, and Support. Although Cooper et al.’s process is more extensive, Sharp et al.’s phases are more suitable for smaller projects as they focus on less formal requirements such as modeling user behavior or defining system be- havior. Looking at the design process for games specifically, Fullerton’s [37] process is quite similar to that of Sharp et al. Fullerton describes the process with the fol- lowing steps: Brainstorming, Physical Prototype, Presentation, Software Prototype, Design Documentation, Production, and Quality Assurance. All of these processes have iteration at their core. The concept of iterative design is taken up in Section 4.5 Figure 4.1: The relationship between the four basic phases of Interaction Design. Taken from Sharp et al. [35, p.52] We will now go into further detail about the four phases proposed by Sharp et al. A visual representation of how these four phases relate to each other can be seen in Figure 4.1. Firstly, the discovering phase includes activities that help build under- 15 4. Methodology standing of the target user and scenario by creating requirements for the product. Common activities used in the discovering phase are interviews, questionnaires, and observations, see Section 4.4.1, 4.4.2, and 4.4.3 for more information regarding these activities. The design phase is where the requirements are met by creating a possible design solution, more information about the design phase can be found in Section 4.2. The prototyping phase is where the previously created designs are made tangi- ble, Section 4.3 will go into more detail about prototyping. Finally, the evaluating phase is where one or several prototypes are tested by users and evaluated based on the users experience with the prototype. The same activities from the discover phase are commonly used in the evaluation phase as well. The evaluation phase will be taken up in Section 4.4. 4.1 Discovering The discovering phase is all about exploring the problem space and defining require- ments for the product. In short, the problem space is the area in which we define the problems that we want to solve [38]. While a requirement can be defined as ‘a statement about an intended product that specifies what it is expected to do or how it will perform.’ [35, p.387]. Sharp et al. also state that another way to specify what a product is expected to do is by defining a user story. A similar concept mentioned by Fullerton [37] is "experience goals". She defines this as ‘goals that the game designer sets for the type of experience that players will have during the game’ [37, p.12]. Sharp et al.’s definition of requirements can be compared with Fullerton’s [37] definition of experience goals, as in essence, they both try to answer the same question, that being what outcome one wants with a certain artefact. In the case of Sharp et al. this artifact is the design, while for Fullerton it is the game. A common activity that can be done to explore the problem space is conducting a literature review. In short, according to Knopf [39], ‘a literature review summarises and evaluates a body of writings about a specific topic’. This is important to do when carrying out a study about a specific topic, as one can get insights about what research has been - or has not been - previously done. This is a vital part as the aim of research studies is to contribute to existing knowledge [39]. 4.2 Design The design and prototyping phase discussed in Section 4.3 can either be seen as two separate phases or as one whole phase. This is because, essentially, they are both about finding solutions to the requirements or experience goals which were created in the previous discover phase. The design phase can be seen as an activity where a document of high concept solutions of the requirements is created before going on to the prototyping phase. Sharp et al. [35] call this document a conceptional design and it describes ‘what people can do with a product and which concepts are needed for the user to understand how to interact with it’[p.434]. Johnson and Henderson [40] describe conceptual models as ‘a high-level description of how a 16 4. Methodology system is organized and operates’ [p.26]. In the area of games, Fullerton [37] calls this a treatment or concept document. Fullerton states that ‘a treatment does not go into great detail about every aspect or level of the game; however, it will address [the] top-level questions about the idea’ [p.190]. The conceptional design can include things such as metaphors, analogies, concepts, relationships, and mappings [40]. As for games, it can also include game mechanics. 4.3 Prototyping The prototyping phase is where a more concrete, tangible artefact is made which meets the requirements of both results of the discover and the design phases. After completion, the prototype is evaluated with the user, the evaluation phase will be covered in Section 4.4. A prototype can either be of low or high fidelity (called lo-fi and hi-fi respectively). For exmaple, a lo-fi prototype may be made with paper or cardboard and offer a lower amount of functionality, while a hi-fi prototype could, for example, be a digital program which will have more functionality. Both hi- fi and lo-fi prototypes have their pros and cons, and each have their respective purposes. Benyon et al. [41] describe both in great detail, stating that low fidelity prototypes require little effort to put together; ‘they are designed to be produced quickly, and thrown away as quickly’ [41, p.256]. This makes it suitable for creating lots of different variations of the product which can then be communicated to and evaluated by users. High fidelity prototypes on the other hand are ‘useful for detailed evaluation of the main design elements’ [41, p.254]. Hi-fi prototypes are generally created later in the design process when the main design elements have been realised. 4.4 Evaluation As Sharp et al. [35] describe it, the evaluation phase ‘involves collecting and analysing data about users’ or potential users’ experiences when interacting with a design artefact such as a screen sketch, prototype, app, computer system, or com- ponent of a computer system’ [p.496]. One should do this because the data that gets collected produces valuable information on what the target users think of the prod- uct that is being evaluated. There are several different data collection methods that can be used in the evaluation phase. Most common are interviews, questionnaires, and observations. These methods will be descirbed in Section 4.4.1, 4.4.2, and 4.4.3 respectively. The data collection method that is being used depends on what part of the artefact one wants to evaluate. Benyon et al. [41] propose the acronym IM- PACT; intention, metrics, people, activities, context, and technologies. These are six important aspects of the user evaluation one should consider before one starts evaluating. Firstly we have intention which is where one decides what the aim of the evaluation is. Second is metrics, this is where specifications are made about why, what, and how things will be measured. The third aspect, people, is where one decides what and how many users will be part of the evaluation. The fourth aspect is activities, this aspect concerns what, and in what order, the user will carry out specific actions during the evaluation. Fifth is context, which is where outside 17 4. Methodology variables such as social or physical aspects are considered. Lastly is technologies. What kind of hardware or other media that will be used during the evaluation is considered here. After each of these aspects are considered, Benyon et al. suggest writing a plan outlining the decisions made, and then conducting a pilot session to fix any potential issues. Pilot studies are described in Section 4.4.4 4.4.1 Interviews If one is looking to collect qualitative data, interviews are a good activity to carry out. There are several different kinds of interviews, namely, unstructured, struc- tured, and semi-structured [35]. In short, the difference between these types is how strictly the interviewer wishes to follow a certain schedule. Unstructured interviews typically have open-ended questions, and the interviewee is free to answer how thor- oughly or shallowly they like. They can be compared to a more casual conversation, and the interviewer can decide to pivot the conversation to whatever they want to know more about. Unstructured interviews are useful for when one wants gain un- derstanding in a specific type of topic [35]. During a structured interview, closed questions with a limited amount of available answers are asked. These questions are asked in the same order to each participant. The format of each question asked during a structured interview can be quite similar to the closed-ended questions in questionnaires. More information about questionnaires will be discussed in Section 4.4.2. The goal of structured interviews is to get answers about specific aspects of, for example, the design or the user experience. One can also later compare the answers and try to find patterns or relationships between them and the experience of the users. Lastly are semi-structured interviews, which combine both aspects of unstructured and structured interviews. Interviews can for example be done after showing the target user a prototype to get information about what they though about it. In addition, they can also be done right after a questionnaire. Benyon et al. mention that: ‘short individual interviews after testing are very valuable in clarifying user reactions, or amplifying the answers to questionnaire items’ [41, p.281]. 4.4.2 Questionnaires A questionnaire is another way to collect data from users. In most cases, question- naires are most useful when one requires quantitative data. There are different types of response formats that are common in questionnaires, for example, responses to close-ended questions can be ‘yes’ or ‘no’, or a rating from a scale that ranges from one to five [35]. The biggest difference between questionnaires and interviews is that when a questionnaire is made, it can be distributed to a substantial amount of users [35]. 4.4.3 Observations As Sharp et al. write: ‘it can be difficult for people to explain what they do or to describe accurately how they achieve a task. It is unlikely that an interaction 18 4. Methodology designer will get a full and true story using interviews or questionnaires.’ [35, p.288]. This is why observations are an important addition to an evaluation. Benyon et al. also support this, they say that ‘you should complement interview and questionnaire data by observing people’s activities as they happen’ [41, p.222]. Observations help fill in the gaps that interviews and questionnaires leave by examining what users are doing during the course of the activity. 4.4.4 Pilot study As Sharp et al. explain that ‘a pilot study is a small trial run of the main study’ [35, p.265]. The main objectives of a pilot study are to validate the feasibility of the study, and to allow the researchers to practise their role in that particular study [42]. For example, after a potential evaluation plan has been created, the researchers can first try out the evaluation themselves to test if it is appropriate and works smoothly. 4.5 Iterative Design One of the most important aspects of interaction design is the fact that one does iterations of the process. Iterations make it possible for the design to be based on feedback from users [35]. In the concept of games, Fullerton [37] describes iteration as a process in which ‘you design, test, and evaluate the results over and over again throughout the development of your game, each time improving upon the gameplay or features, until the player experience meets your criteria.’ [p.16]. 4.6 Scrum A common agile project management technique called Scrum is a framework that helps people generate value through adaptive solutions for complex problems [43]. A typical scrum team contains a scrum master, product owner, and developers. Scrum activities include the planning, reviewing, and concluding of a Sprint. These activities will be taken up in more detail in Section 4.6.1, 4.6.2, and 4.6.3 respectively. A Sprint is a fixed length event typically lasting less than one month. During this time, all work necessary to achieve the product goal and other activities is done. One usually creates and maintains a list of all product improvements that can be done within a sprint. This list is called the Product Backlog and helps with keeping track of what has been done, and what still needs to be done within the project. Scrum works well as it splits big projects into smaller sub-projects which makes handling them easier. 4.6.1 Sprint Planning Before each Sprint begins, one first needs to specify a development goal that needs to be met at the end of the Sprint [43], [44]. Schwaber and Sutherland [43] divide three main topics to take up during the planning phase. Topic one considers questions regarding how and why the product can increase in value during the Sprint. Topic 19 4. Methodology two is about deciding how much work will be done in the Sprint. This is done by selecting appropriate product improvements to work on from the Product Backlog. The last topic is about how the previously selected items will be developed. This could, for example, be done by dividing each item into smaller daily tasks. 4.6.2 Sprint Reviewing A Sprint review is done after a Sprint has been finished [43], [44]. ‘The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations’ [43, p.9]. This is also an opportunity for the Product Backlog to be updated to represent the new implementations. 4.6.3 Sprint Retrospective The last activity of a Sprint is called the Sprint Retrospective. This is where one looks back on the completed Sprint and reflect on the work that has been done. More specifically, the following questions are asked: what went well, what could be improved, and what will be improved in the next sprint [44]. 20 5 Process This chapter will go though the design and development process of the thesis. Firstly, the planning phase conducted at the very start of the project will be covered in Section 5.1. Then, the pre-study phase will be covered in Section 5.2. Finally, the three main phases will be covered in detail in Sections 5.3, 5.4, and 5.5. In each of these sections, design decisions, implementation specifications, and evaluation results will be described. 5.1 Planning At the very start of the project, an initial planning phase was done. It was planned that the prototype was to be created in the Unity Game Engine. The prototypes two main components would be a race track and a car that could be controlled by a player. It was also planned that further components could be added to increase the immersion of the experience, this could for example be decoration or game objects that are added to the race track. The look of the car interior and user interface were also considered to be areas of interests, these areas could make room for further design decisions that could increase immersion. It was also planned to do several evaluations throughout the development process. The evaluations would let the participants interact with the experience, this inter- action could for example be driving a lap around the race track. After this, it was planned that the participants in the evaluation would be asked to fill out a survey which will measure how immersed they felt in the experience and why. The plan was that the participants in this evaluation should have varied experience levels. The aim of this was to see if there are any significant differences between their feeling of immersion. A Gantt chart was also created that illustrated the planned schedule that would be followed for the thesis. This chart can be seen in Figure 5.1 5.2 Pre-study A pre-study phase was done to get a better idea of the scope of the project and what needed to be included in the prototype to answer the research question. This 21 5. Process 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Research Implementation Evaluation Report Figure 5.1: The schedule created at the start of the project stage could also be seen as a first hypothesis, as during this time, it was not sure yet what factors would have the most effect on immersion. The pre-study phase was done as described in Section 4.1. This Section will go through the various different activities done in the pre-study phase. These activities include the literature review which will be covered in Section 5.2.1 and the project plan in Section 5.2.2 which will cover how the project was planned to be carried out in detail. 5.2.1 Literature Review A literature review was done to get up to date with the most relevant theories, methodologies, and previous works such as similar immersive experiences including Sim racing and Arcade racing games. Previous works are taken up in Section 2.2 and 2.3. As for researching relevant theories and previous works, specific keywords were used to search through literature database Google Scholar [45]. Examples of keywords used were: Immersion, Flow, Presence, Realism, VR, Racing, Dynamic Difficulty, and Games. Twenty one papers on the topic of immersion and eight on the topic of racing games were thoroughly examined. Relevant methodologies were also studied. These included details of the design process such as the four phases: discover, design, prototype, and evaluate. The details of the scrum project management technique were also examined. Research was also done on relevant implementation details. This was done by watch- ing various YouTube videos related to different topics such as how to do different implementations, for example, how one can implement vehicle mechanics, and how to make a race track in Blender [46]. The results of the examined theories can be found in Section 3. The relevant exam- ined methodologies can be found in Section 4. 22 5. Process 5.2.2 Project Planning The project was re-planned after the literature review. This was because relevant information was gained through it and thus an improved plan could be structured to better fit the goal of the project. It was planned that the project would follow the four previously stated activities of Interaction Design. These activities being, discovering (4.1), designing (4.2), prototyping (4.3), and evaluation (4.4). Further- more, it was planned that the project would follow the agile project management technique Scrum discussed in more detail in Section 4.6. Details of how the initial requirements are planned to be created is taken up in Section 5.2.2.1. Then, the planned layout of the Scrum sprints will be discussed in Section 5.2.2.2. Finally, the planned way in which this study will be finalised will be covered in Section 5.2.2.6. An overview of the planned weekly activities can be found in the schedule in Figure 5.2. 5.2.2.1 Exploring initial requirements In this subsection, the planned activities between weeks three and nine will be covered. Firstly, an initial research phase, followed by a discovering phase is planned to be done. The research phase includes a literature review of relevant topics such as immersion (3.1) and dynamic difficulty adjustment (3.5). The discovering phase (4.1) is planned to set product requirements, for example, this could contain setting experience goals and deciding which users will be included in the design process, as well as what environment it could be in. Part of this information may be supplied by and discussed with Lynk&Co (2.1). The design phase (4.2) is planned to explore solutions to the requirements made in the discovery phase. This could include possible designs of visuals and game- play. The visuals could include designs such as the user interfaces and visual styles. Gameplay designs could, for example, include game mechanics, track design, how dynamic difficulty is planned to be implemented, and vehicle behaviour. 5.2.2.2 Sprint layout There are three Scrum sprints planned, each with a duration of three weeks. This will cover a total amount of nine weeks spanning weeks nine to eighteen. The start of a sprint is planned to change any requirements depending on the results of the previous sprint, this will be covered further in Section 5.2.2.3. Then, the prototype is planned to be further developed to match these requirements over the course of two weeks, Section 5.2.2.4 will cover this. After the sprint is done, an evaluation is planned to be done on the prototype, this is discussed in Section 5.2.2.5. After the evaluation is done a new sprint will begin. A rough plan of what could be implemented in these sprint is shown in the following list: • During the first sprint, basic vehicle physics are planned to be implemented so that the player is able to control a vehicle and drive around a basic track. 23 5. Process • The plan of the second sprint is to implement the dynamic difficulty to match the challenge with players skills. • The final sprint is planned to focus on adding further game mechanics to make the experience more exciting and engaging. 5.2.2.3 Changing requirements This activity is planned to be done in weeks twelve and fifteen, after each evaluation has been completed. The purpose of this activity is to react to user feedback from the previous evaluation phase, and assess what progress has been made by possibly changing requirements and looking for new design solutions that can be implemented in the next Sprint. Essentially, this activity is planned to be much similar to the methodologies described in Sections 4.2, 4.6.1, 4.6.2 and 4.6.3. 5.2.2.4 Prototyping The prototyping phase is where the implementation of the design solution is planned to take place. This is the most time consuming task of the study which is why it has the most weeks dedicated to it in the schedule. The implementation is planned to be done in the author’s preferred game engine: Unity [47]. Some assets, including vehicle model and environment may be supplied by Lynk&Co or Chalmers. 5.2.2.5 Evaluating A total of three evaluations are planned to take place. The first evaluation is planned to be done after the first two week prototype phase in week twelve. This evaluation is planned to focus on testing features regarding the mechanics of the vehicle. For example, how difficult it is to control the vehicle, and how realistic it feels to drive. The second evaluation, taking place in week fifteen, is planned to examine the implemented dynamic difficulty to see if it is producing the desired results. The last evaluation is planned to take place at the end of the implementation, this evaluation is planned to be done at a larger scale to see how well the prototype works at giving the participant the feeling of immersion. The evaluation is planned to be done by first letting the participants get hands-on experience with the prototype while being observed (4.4.3) by the researcher. Afterwards, the participants are planned to be asked to fill in the immersion questionnaire created by Jennett [1], see Section (4.4.3) regarding information about questionnaires. Additionally, a short interview (4.4.1) is planned to be held to get further information and insights about the participant’s experience. Note that these mentioned evaluations are planned and thus are subject to change. 5.2.2.6 Finalisation During the last four weeks, the study is planned to be concluded by summarising the most important findings in a report. Also, a comprehensive set of guidelines are planned to be created to aid future researchers and game designers regarding the feeling of immersion for a variety of experience levels. Furthermore during this time, 24 5. Process work is planned to be done towards the creation of a presentation of the study, and time is planned to be spent on being an opponent of another Master Thesis project. 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Research Discovering Design Prototyping Evaluation Report Finalisation Figure 5.2: Gantt chart for the planned schedule 5.3 Phase 1 As stated in Section 5.2.2.2 the goal of the first sprint was to make a basic vehicle which the player is able to control as they drive around a track. A first sprint planning phase was done as described in Section 4.6.1. It was determined that the product would increase in value by adding the ability for the user to control the vehicle. This is important because we want the user to be able to feel that they have control of the vehicle, and are not watching, for example, a video of someone else driving a vehicle. The way this goal would be achieved was by implementing common characteristics for the vehicle such as acceleration, steering, and friction. Furthermore, basic collision with the ground is also planned to be implemented. 5.3.1 Design During the design phase, experience goals, a persona, and a scenario were created. The experience goals were created to better detail what we want the player to feel when playing. After the experience goals were created, they were then prioritised based on importance. For each experience goal, some general ideas were written down on how these goals could be achieved. The results of this process can be seen in Figure 5.3. The experience goals will now be described in more detail, and will be mentioned in order of importance. 25 5. Process Driving is  easy, but  getting the  extra score  will be hard harder track The player  is their  own  enemy Objectives Challenging but fun &  engaging Getting  consumed by  the virtual  environment Feeling of  ownership get X  amount  of coins Complete the lap in x time Dynamic  Difficulty  Adjustment Lap and  split  times Leave  behind  obstacles Ghost replay Speed boost Teleport Tricks/stunts Unrealistic track non  realistic  gravity flying,  high  jumps Power ups Rockets, laser Invisibility,  phase  though  obsticles The ability to bypass objects Loops,  drive on  walls Bonus  points for coolness Drifting Visuals Audio Feedback Many lights Stuff  happening  not related  to the race Crowd Background  noise Car  sounds Music,  suspenseful, electronic Customization Choice Haptic  feedback Something  good =  something  bad later More power  ups used =  harder track Bad  driving Wrong  turn / bad shortcut Over- confidence Figure 5.3: Player Experience goals created at the start of the project Getting consumed by the virtual environment. This experience goal was cho- sen to represent the fact that the experience should be immersive. As described in Section 3.1, immersion has the following features: lack of awareness of time; loss of awareness of the real world; involvement and a sense of being in the task environment. Getting consumed by the virtual environment summarises these features of immersion in a good way and makes it clear that the experience should be immersive. As seen from Figure 5.3, this could for example be done through the addition of realistic visuals, other elements not related to the race could also help with immersion as the player could have several things to look at. The addition of audio could further enhance the realness. Challenging but fun and engaging. Making the experience challenging while not making it too difficult for the player follows the theory of Flow described in Section 3.2. Dynamic Difficulty Adjustment described in Section 3.5 will help with creating the right challenge for the player. This could also be done through the addition of different game elements such as power-ups or speed boosts. One could also have novelty in the track design such as having loops or having the ability to drive on walls. 26 5. Process The player is their own enemy. As described in Section 1.2, one of the main limitations of this study is that it will only be a single player experience. It was thus chosen to add this experience goal in order to give the player an additional challenge. One could accomplish this through different challenge aspects such as lap timers or a ghost replay. The player could also leave behind different obstacles so they have to think carefully about how they drive around the track. Driving is easy, but getting the extra score will be hard. This experience goal expands further on the previously mentioned goal. By making sure the controls are kept easy, the experience will remain accessible for players with very little experience with racing games. Experienced players will enjoy the challenge of getting the extra score to keep engagement levels high. This could for exam- ple be implemented by having dynamic difficulty adjustment, it could also be done through the addition of different kind of objectives such as completing a lap in a certain amount of time. Feeling of ownership. One of Lynk&Co’s goals and values is to give the player a feeling of ownership. Furthermore, Schmierbach et al [48] found that ‘al- lowing players to customise their car increased identification, which amplified both transportation and presence’[48, p.367]. It was thus decided to add this experience goal to further investigate this area. This could for example be im- plemented through the ability for players to customise their vehicle by letting them choose the model and colour. After the experience goals and general ideas on how to achieve them were created, they were further expanded by brainstorming specific game mechanics and elements. These would be of much help by giving concrete examples on how to implement the experience goals in the prototype. The result of this process being done on the experience goal ‘Getting consumed by the virtual environment’ can be seen in Figure 5.4. To further define the design space, a persona and scenario were created. The goal of the persona was to provide a concrete example of the background and lifestyle of a potential user who would play the experience. The goal of the scenario was to create a future hypothetical situation which illustrated how the experience might be played by the described persona. Both the persona and scenario can be found in Appendix A. 5.3.2 Prototyping The physics of the vehicle were created using Unity’s built in Wheel Collider com- ponent [49]. Taken from Unity’s own description of this component: ‘The Wheel Collider is a special collider for grounded vehicles. It has built-in collision detec- tion, wheel physics, and a slip-based tyre friction model’ [49]. It was thus relatively straightforward to implement the physics of the vehicle. More time was spent on tweaking the values of the Wheel Collider component in each wheel to make the vehicle behave in a natural way. This included things such as how easy it is for the 27 5. Process Strobe Light Spot  light Lazer Neon lights Track light Crowd lights Hologram AR type stuff Wireframe lights Screens TV  ads Billboard Overhangs Skyscrapers Crowd Bariers flagsCones  on track Montains stars planets Flying  donuts Airplanes Clowds Zeppelins Glitch  effects Getting  consumed by  the virtual  environment City Race  track Nature Space Environm ent Lights Objects  close to  track Objects  farther  away Crowd  cheering Tire  noise Engine Music Environment  noise Rain Start  sound Switching gears Sound effects Sounds Figure 5.4: Examples of game elements that can be included in the prototype to achieve the experience goal ‘Getting consumed by the virtual environment’ vehicle to loose grip, how fast it could go, and how easy it should be to turn. To make the vehicle more interesting to control, a feature was added to allow the player to carry out a manual drift. This was done by making the back tyres lose grip when the player quickly taps the brake while the vehicle is in motion. The vehicle was constructed by creating one large rectangle, resembling the body of the vehicle, with four identical cylinders attached to it, resembling the wheels. The body was given a red texture while the wheels were given a wooden texture. The results can be seen in Figure 5.5. A basic track was created in the 3D modelling program Blender [46]. The track was made short with some difficult turns and some easy turns to make it interesting to drive on. It was also decided to make the track float in the sky so that if the player went off the track they would fall. This made it more important to stay on the track, increasing the challenge of it. The first iteration of the track can be seen in Figure 5.6. Figure 5.5: The first iteration of the vehicle the player controlled Figure 5.6: The first iteration of the track the player had to drive around 28 5. Process Two different camera modes were implemented. One where the camera was in a third-person position with the whole vehicle in view, and another where it was in a first-person position where the player would be on top of the vehicle with only the front wheels in view. The player could choose to switch between the two camera modes at any time while playing and the camera would smoothly transition between the different views. Both cameras had a slight smoothing effect to make it look natural when driving around the track. The next step was to register if the player had gone a lap around the track. This was done by implementing a checkpoint tracker. This made it possible to check if the player was driving in the right direction, a lap would only count if the player had successfully gone through all the checkpoints in the right order. These checkpoints were also used for respawn points; when the player fell off the track, they would respawn at their last reached checkpoint. A timer was also created which kept track of the player’s fastest lap. This was done to add an additional challenge by incentivising the player to beat their personal best time. User interface elements were created to show the player’s current and personal best lap time. Further interface elements were also created for debugging reasons; information such as the vehicles speed, tyre grip, and tyre RPM could all be displayed on screen and monitored. Further improvements were made to both the vehicle and the environment. The vehicle model was made more realistic by updating it to a Go Kart model taken from a royalty free source [50]1. This model can be seen in Figure 5.7. The environment was made more interesting by adding simple shapes around the track. The purpose of these objects were to provide the player with more things to look at while driving around the track. This track can be seen in Figure 5.8. Figure 5.7: The second iteration of the vehicle the player controlled Figure 5.8: The second iteration of the track the player had to drive around As the experience was planned to be in VR, the development of making the expe- rience work in VR also started in this phase. The VR headset which was used was the HTC Vive Pro 2 which was provided by Chalmers. The Unity XR interaction toolkit [51] was used as it provides an easy way to make various VR interactions work within Unity. It was planned that the player would have to grab on the steering wheel and rotate it in order to steer, just as a steering wheel works in real life. 1Model created by Spaehling, model is under the following license: https://creativecommons.org/licenses/by-nc-nd/4.0/ 29 5. Process 5.3.3 Result The outcome of the sprint was the creation of a sophisticated vehicle controller which lets the player control the vehicle in a realistic way. The player can drive around a simple track and a timer will keep track of the time it takes for the player to drive around. Due to the VR equipment being supplied late, it was unfortunately not possible to make the steering work with the VR controllers at the end of the sprint. It was planned that the priority for the next sprint would be to add a way for the user to interact with the steering wheel in VR, also, further mechanics would be added to make the track more interesting and engaging to drive on. 5.3.4 Evaluation Before doing the evaluation, the IMPACT method described in Section 4.4 was done. This resulted in the following outcome: Intention: Get an alternative view on the product from university students. How to move forward, what to think about when considering the research question. Metrics: Observe the difficulty of the track, how focused they are on the task. Then some open ended questions will be asked about their experience. People: University students. Activities: Firstly, have a quick introduction to the project and prototype. Then, let the participants play. Lastly, ask open ended questions about their experi- ence. Context: No outside variables will be considered. Technology: The experience will be played on a laptop. The participants will use a wireless Xbox One controller to control the vehicle. A total of three participants were part of the evaluation. Overall, the students were satisfied and impressed with the prototype. However, they did have some points of improvements and feedback, these will be mentioned now. • Vehicle handling can be made more predictable and realistic. • Show more feedback on how well and fast you are driving and progressing. • Find a better way to motivate the player. • Just driving laps gets boring after a while. Keep the player more engaged by making more things happen, this can, for example, be done by having the following elements: real time events, secondary objectives, coins, speed boosts, jumps to make it more exciting, obstacles on the track that could be dynamic or static, changes in environment when driving around the track. • Additions of sounds can make the experience more immersive to play. 30 5. Process The biggest issue with the prototype was that it was not engaging enough. The participants stated that the base functionalities were good but there needed to be more things to do while driving around. 5.4 Phase 2 A slight pivot of the project was done during the start of this phase. It was decided that there were going to be no efforts in trying to examine the effect of dynamic difficulty on immersion as a better method of going forward was found. Instead, efforts were going to be put into creating three different types of experiences. These three experiences would make the end evaluation more sophisticated as the user would get a better idea of what type of experience gives them more immersion. This approach seemed to be more appropriate in answering the research question. It was planned that the experiences would focus on creating different types of im- mersion, this includes immersion through realism, through engagement, and through "craziness". For each of the three experiences, features will have to be implemented in order to make each experience unique and distinguishable from the others. As a start, the main focus will be to add these distinguishable features for each experience, then, further improvements will be made by adding environments and audio. 5.4.1 Design Both the way the different environments were going to look and how the player would interact with the vehicle had to be designed before starting the sprint. The different aims for the environments are taken up in Section 5.4.1.1, while the different steering wheel interactions will be taken up in Section 5.4.1.2. 5.4.1.1 Environments It was planned that the three experiences would each be set in a different environ- ment. This was decided to further make them easily distinguishable from another, while also investigating if changes in environment would effect immersion. The envi- ronments were chosen to be a forest, a city, and a space setting. These environments would immerse the player through realism, engagement, and "craziness" respectively. We will now go though how the design of each track was planned. Starting with the Forest track, the aim was to make the player feel immersed through realism, meaning that the player is immersed through the realism of the vehicle controls and the environment around them. Sounds and other real life effects such as shadows and realistic lighting thus had to be prioritised for this track. It was decided not to include any game elements in this track and to keep actions per minute low. This was because the aim of the track was solely to let the player enjoy the environment around them and not to become focused on other game objectives such as driving fast or gaining a certain amount of points. 31 5. Process The City track would immerse the player through engagement. The way the track would be made engaging would be through a mix of game elements. Different kinds of game elements were considered, however, most of these got discarded as they would require too much time to implement into the prototype. The elements which were planned to be implemented were: a timer, a ghost player which would mimic the player’s best performed lap, and the ability to collect pickups which would allow the player to boost their speed. These elements all seemed to be appropriate to implement as they would add basic game elements which would engage the player. Finally, the aim of the Space track was to give the player immersion through "crazi- ness", meaning that the player would get immersed through a high amount of vi- suals happening around them, while also including various game elements to keep the player engaged. The visuals were planned to be various asteroids and planets which would be seen around the track. While the game elements would be similar to that of the City track. It was planned to have a less realistic vehicle behaviour for this track. The vehicle was planned to be able to drive on any surface, no matter its orientation. The track would be designed in a way where it would twist and turn in 3D space and the vehicle would still just drive on the track normally. This would further increase the craziness of the track as it would be similar to going on a rollercoaster ride. 5.4.1.2 Interaction Three different types of methods and hardware for using the steering wheel were considered. The first option was to use a racing wheel controller, these controllers are often used by realistic racing game enthusiasts and offer the best control and feedback. The second option was to use the HTC Vive VR controllers themselves, this was a valid option with two main ways to control the steering wheel. First, one could have to "grab" on to the steering wheel with the controllers by pressing down the grip button on the VR controller. While grabbing the steering wheel, one would then have to move the controllers in a circular motion in order to rotate the steering wheel, just like a real steering wheel works. The second way would be that the steering wheel was always being grabbed without the player having to press the grip button. They would then have to move the two VR controllers around to simulate the steering. The third and final option would be to continue using the Xbox controller as the input to control just as it worked in the first phase. The steering wheel controller would have been used if there was one available for the study as it seemed the most realistic and intuitive option to steer. Unfortunately it was not possible to gain access to one for the study. The option that was chosen was where the player would have to grab the steering wheel by pressing down the grip button on the VR controllers. This option was chosen because it seemed to be the most realistic and intuitive way to interact with the steering wheel that was available. Just as in real life, one has to grab onto the steering wheel in order to 32 5. Process steer it. By using this option it would also be possible to steer with only one’s right or left hand, or to steer with both hands. 5.4.2 Prototyping When starting the prototyping phase, priority was given to the elements which could be reused for several environments. For example, engine and skidding sounds could be used on all three environments, so it was given high priority . The ability to collect coins was planned to be done on two tracks, so that feature was also prioritised. 5.4.2.1 Choosing of environments To save time, different environments to fit the Forest, City, and Space tracks were searched for on the Unity Asset Store [52]. This is a website where one can find various 3D and 2D models, textures, and programming tools specifically tailored for use in Unity projects. In general, all the environments that were chosen were of high quality in terms of graphics. Details about each selected asset will be gone through now. The forest environment2 had a built in racing track. This track fit well as it had no sharp turns, making it easy for inexperienced players to drive on. The track includes some minor changes in environment, as at one point, the track goes into a mountain through a tunnel. This incorporates some of the feedback given in the first feedback session discussed in Section 5.3.4. The environment around the track was also realistic with trees and rocks closer to the track and mountains further in the background creating an illusion of depth and thus making it almost identical to real life. The city environment3 was chosen to be set in a futuristic scene. This would make the environment become more abstract and thus make the planned game elements fit in with the environment more. The asset contained many different models such as neon signs, robots, houses, and many other props. As there was no premade track design or environment, it was planned to create a completely custom track and populate the environment around it with the models available in the asset. The asset used for the space environment included different types of asteroid mod- els4. Each asteroid could have a glowing effect where colour and intensity could be easily adjusted. Each asteroid could also be split into smaller asteroid pieces. It was planned that this would be used when an asteroid got hit by the player or crashed onto the track. Before these assets could be implemented into Unity, a request to Chalmers was sent to let them carry out the purchase of the assets. While waiting for the transaction to be carried out, several other implementations were done which will be taken up in detail now. 2https://assetstore.unity.com/packages/3d/environments/forest-racing-track-117020 3https://assetstore.unity.com/packages/3d/environments/sci-fi/cyberpunk-cyber-city-120137 4https://assetstore.unity.com/packages/3d/environments/sci-fi/highres-asteroids-pack-72323 33 5. Process 5.4.2.2 Vehicle sounds Various different sounds were added to the experience to make it more realistic and enjoyable to play. Firstly, engine sounds were created by making a dent in a metal can at its centre point and humming into the opening. The sound created by this was recorded and edited in the audio editing software Audacity [53]. A script was then created in Unity which changed the pitch of the sound to simulate that the engine was changing gears. Note that the player did not have the ability to change gears by themselves, this was decided not to be included as it would be too complex for inexperienced players. A skidding sound was also added as it further increased realism and also gave audio feedback to the player when the vehicle lost grip in any of the tyres. The skidding sound was implemented by downloading a royalty free skidding sound from a YouTube video and importing it into Unity. A script was created which faded the sound in and out depending on the sidewaysSlip value stored in each WheelCollider component of the vehicle. 5.4.2.3 Increasing Engagement Further engagement elements were added including a ghost player and an improved track. These two elements will be introduced now. A ghost player was added to create an extra engagement aspect to the experience. This was done by recording the player’s position and orientation during a lap. If the player finished the lap and set a new record in doing so, the recording will be saved and played back. This would allow the player to see how they drove on their best performed lap and compete against themselves. The ghost model was made as a transparent version of the player vehicle model and can be seen in Figure 5.9. A new, improved, and more engaging track was created in Blender which allowed the player to perform a jump over a previous section of the track. White road markings were also added to the track so that the player can better tell how fast they are going. This decision was also inspired by the feedback from the first evaluation session (5.3.4). The track can be seen in Figure 5.10. Figure 5.9: The ghost player model Figure 5.10: A more exciting track was created which included a jump 5.4.2.4 VR Development The VR development continued throughout the duration of this sprint. Several features had to be added and changed to make the experience playable in VR. 34 5. Process These features will be discussed now. To make the experience as realistic as possible, instead of the camera being at a fixed orientation in either first-person or third-person view, the camera would always need to be in first-person view to make it identical to real life. The player could then move their head around with the Head Mounted Display (HMD) and the camera would orient itself identically to it. As is common with VR games, virtual hand models were added which represent the position of the VR controllers. Both the change in camera and the addition of player hands could easily be added with the help of the Unity XR interaction toolkit [51]. Figure 5.11: A diegetic timer seen at the side of the track Making the player be able to use the VR controllers to steer the vehicle was more dif- ficult to get working than anticipated, they were however successfully implemented after a lot of effort. When the VR controller now got close to the steering wheel and the player pressed the grip button the virtual hand would grab the steering wheel. This would be visually shown by playing an animation where the hand would go from an open hand to a closed hand around the steering wheel. While the player was holding the steering wheel, they could move their hands in a circular motion around the pivot of the steering wheel. This would then steer the vehicle accord- ingly. When the player released the grip button, the virtual hand would release the steering wheel and go back to its original state. Another features that was changed was the way the timer was shown. Previously, one could always see current lap time and best lap time, however, due to the change of the camera to VR, this was no longer the best option. The timer was instead chosen to be of diegetic form, a common attribute of UI elements seen in other VR games. The effect of diegetic UI in VR has also been studied by Salomoni et al. [54]. They found that ‘the use of a diegetic interface has a significant (and not accidental) effect on the perception of immersion’ [54, p.182]. Diegetic timers were thus added 35 5. Process along the side of the track for the player to see. Three timers were added in total at certain checkpoints. Each timer showed the current lap time and a split time which showed the best time between the start of the lap to that checkpoint. The checkpoint system was also improved to support these lap splits. The new diegetic timers can be seen in Figure 5.11. 5.4.2.5 Creation of Environments As mentioned in Section 5.4.2.1, three different environment assets were requested to be purchased by Chalmers. When these assets were acquired, the environments could be put into the Unity project and made into beautiful playable tracks. As the forest asset already had a pre-made track and a suitable environment, no big changes had to be made to it. The vehicle model and its relevant behaviour scripts could be easily moved to the Forest track to make it possible to drive around it. When testing the driving with the existing vehicle behaviour from phase one, it seemed that the vehicle drove in an unrealistic way. It was going too fast and responded too sharply to player inputs. This was now only realised because the environment was scaled correctly to the size of the vehicle model. Slight changes were thus made to the vehicle physics to match it more with how cars behave in reality. A reverb audio effect was also added when the player went through the tunnel to make the vehicle sounds more realistic while the player was in the tunnel. This could easily be done through Unity’s Reverb Zones script [55]. An example of how the environment looked like at this stage can be seen in Figure 5.12 Figure 5.12: The player driving out of a tunnel in the Forest track The city environment was created by first designing a track and then adding various different buildings and props around it. The track was designed to have a mixture of long and short sections to make it more enjoyable for experienced players, following what has been found by Surarerks and Kotrajaras [56], and Galdieri et al. [57]. To make the track more interesting to drive around, different shortcuts were made 36 5. Process so that players would get rewarded for their curiosity. After the track had been designed, various different buildings provided by the city asset were placed next to the track. When this was done, further props such as street lamps, cables, neon signs, and food stands were added to make the environment more interesting. Taller buildings were also placed further away from the track to make the player feel like they were driving in a vast city. The results of a finished street can be seen in Figure 5.13. Figure 5.13: One of the many views one can see when driving around the City track Coin and speed boost game elements were also implemented on the City track. These two elements seemed to be a simple way to increase the amount of features the player could interact with and act on. The coins would spawn slightly to the side of the track, the reason for this was so that the player would have to make an extra effort if they wanted to pick up the coins. A speed boost feature was also implemented which allowed the player to go faster for a short period of time. The coins acted as fuel for the boost, each time the player picked up a coin it would play a coin pickup sound and it would then increase the boost fuel. The player could decide whether to boost at any time; with the press of a button on the VR controller, the boost meter would get used and the vehicle would go faster. Because the aim of the City track was to motivate the player to complete a lap as fast as possible, further elements were added to support this. One of these elements was a countdown timer. Before the player would start racing, there would be a countdown to give the player a feeling they were in a race. A diegetic visual of a countdown timer was added hanging over the track. Music was also added to create an extra element of excitement. Lastly, the previously created diegetic timer elements were transferred to the track. Finally, the development of the Space track was started. Several different track 37 5. Process (a) The first iteration of the Space track. It is shaped like a Möbius strip and has sharp turns (b) The second iteration of the Space track. It is a simplified version of the first iteration (c) The third iteration of the Space track. It has a handful of turns and twists Figure 5.14: Three iterations of Space tracks 38 5. Process iterations were designed, these tracks can be seen in Figure 5.14. Starting with the first iteration of the track which can be seen in Figure 5.14a, this track is shaped like a Möbius strip. This meant that the player would first drive on one side of the track and then drive on the other side. This track was simplified and turns were made less sharp, to make the track easier to drive on. This resulted in the second iteration of the track seen in Figure 5.14b. After some internal testing, having the idea of the track shaped like a Möbius strip was discarded. This was because driving on the other side of the track was not particularly interesting as one could not see the rest of the track. A different design was thus created which resulted in the third iteration of the Space track seen in Figure 5.14c. A new vehicle behaviour had to be created to make the vehicle drive on any surface. The way this was implemented was by creating a sphere collider which would roll along the track, different forces would then be applied to this sphere to make the vehicle move. The model of the vehicle was set to follow the sphere and be oriented on the normal of the surface it was driving on. Gravity would also act on the sphere according to the normal of the surface to prevent the vehicle from flying off the track. Unfortunately, the full implementation of the vehicle behaviour could not be completed before the end of the sprint and could thus not be tested in the evaluation. 5.4.3 Result The sprint was semi-successful, the forest and City track worked successfully in VR, but due to some delays and difficulties, the Space track could not be finished on time. A Forest track was created which is set in a large nature style environment where the player drives around and through a part of a mountain. A City track was also created, it is set in a futuristic city environment. The player has the goal to drive around the track as fast as possible, they have the ability to boost their vehicle, but only if they have picked up enough coins to fuel their boost. Both of these tracks work in VR and the player uses the VR controller to grab on to the steering wheel in VR and rotate it like one would with a real steering wheel. 5.4.4 Evaluation Before doing the evaluation, the IMPACT method described in Section 4.4 was done. This resulted in the following outcome: Intention: Get usability and general feedback from university students. How to move forward, what to think about when considering the research question. Metrics: Observe the difficulty of the controls. Then some open ended questions will be asked about their experience. People: University students. Activities: Firstly have a quick introduction to the project and prototype. Then, 39 5. Process let the participants play. Lastly ask open ended questions about their experi- ence. Context: No outside variables will be considered. Technology: The experience will be played on a desktop computer. The partici- pants will use a HTC Vive Pro 2 with its Vive controllers. A total of four participants were part of the evaluation and gave valuable suggestions of features to add or change. Three participants felt the need to stop playing because of cybersickness. Participants also had difficulty interacting with the steering wheel in VR. More details about the evaluation will be taken up now. One participant said that the Forest track should have more landmarks and become more lively. They said that it was hard to see where they were positioned on the track while driving, as the surroundings around the track looked very similar. The participant also said that the goal of the Forest track was unclear and that there should be at least be some goal so that players know what to do. They did however state that they liked the Forest track more compared to the City track. In contrast to the first participant, another said this was because the Forest track made them more relaxed due to the little amount of challenge or game objectives, which in turn made them feel more immersed. The participant also said that the coins giving boost fuel did not make much sense, their first thought when seeing coins was that they would give points and not fuel. The biggest problem with the two tested tracks was the way the participants had to control the vehicle. This was especially true with participants inexperienced with VR games, but experienced players were also having trouble controlling the vehicle through the VR interaction. Participants did not like that they had to keep pressing down the grip buttons on the VR controller in order to grab the steering wheel. Even after only a few minutes of playing, two participants said that it was hurting their hands to constantly have to press down the grip button. Some participants stated that the vehicle was too responsive when steering and it therefore felt less realistic compared to a real vehicle. One participant also said he didn’t feel in control of the vehicle, adding that the vehicle unexpectedly went off the track without them knowing why it happened. This participant also said that they had to constantly think about how to make the vehicle behave as they wanted. Participants also had extreme problems with cybersickness, this is possibly because of the vast amount of motion the participant is experiencing while playing. One participant said that when the vehicle went on a slope, they thought that they also should be moving the same way which caused them to feel dizzy. 5.5 Phase 3 This phase will act on the feedback given in the evaluation session in phase 2 de- scribed in Section 5.4.4. This will be done by making some minor changes to the 40 5. Process Forest track, by making interaction better, and by decreasing cybersickness. Im- proving vehicle controls and behaviour will allow the players not to get frustrated when playing. Users will also have a chance to get immersed by avoiding having to stop playing because of cybersickness. The development of the Space track will also be continued. 5.5.1 Design A difficult choice had to be made when choosing whether to improve the VR steering interaction, or to discard the implementations made and instead go back to the Xbox controller. It was chosen to make the vehicle be controlled with an Xbox controller, just like how it worked in phase 1, instead of adjusting the VR controls to make them more easy to use for the player. This was to minimise the risks that the VR steering interaction would still be difficult to control after constant development. The development time could instead be used for other meaningful implementations. Cybersickness was going to be reduced by minimising roll and pitch rotations of the vehicle, to decrease the amount of motion the player sees while turning and braking the vehicle. The Space track was still incomplete, but it was planned that the asteroids would be used as game elements. The player would be able to shoot the asteroids to get points and the goal of the track would be to get as many points as possible. The way the player would shoot was with a laser, which could be aimed by the way the player looked with their head. If an asteroid would get hit by a laser, it would break into smaller pieces, if a smaller piece would get shot it would explode and disappear. To incentivise the player to drive around the track while shooting the asteroids, coins were decided to be added to the track which the player could pickup. These coins would give the player additional points. To further increase the amount of craziness, it was decided that some asteroids would crash into the track and break apart in front of the player. Several new assets were searched for on the Unity Asset Store [52]. These were all medieval style buildings which were planned to be placed on the Forest track. This was done in response to the feedback gotten from the previous evaluation session taken up in Section 5.4.4. Having several distinct buildings placed around the map would increase the amount of landmarks, thus making it easier for the player to know where they are on the track, and also having more interesting things to look at. 5.5.2 Prototyping Some changes were made to the amount of motion the player would experience when driving the vehicle, this may decrease the chances of the player feeling cybersickness. This was done by changing the damping rates in the spring of the vehicle. Previously, when the player would turn, brake, or accelerate, the springs of the tyres would contract at a fast rate and the whole body of the vehicle would tilt, making a motion 41 5. Process that would roll or pitch the camera a few degrees at a fast speed. To decrease this motion, the contracting rate was made slower which greatly decreased both roll and pitch movements the player would experience. This alteration did not change the behaviour of the vehicle to a noticeable extent. Some slight changes were made to the Forest track. More distinct objects such as houses and bigger buildings were placed around the track. One big castle was also placed on top of the mountain the player is driving around, this castle can be seen in Figure 5.15. More additions to the environment around the City track were also added to make it more lively. This was done by adding robots to it which would move and fly around the track. The coins were changed into gas canisters to make their purpose more clear to the player and the pickup sound was also changed to resemble a gas canister more. An image of the robots and gas canister can be seen in Figure 5.16 . A boost sound was also added to make it clearer to the player that they were boosting. Figure 5.15: A castle was put on the mountain on the Forest track Figure 5.16: Robots were added to the City track, and the coins were changed to gas canisters The vehicle behaviour in the Space track was developed to be fully working as it was planned to be. It could now drive on any surface no matter its orientation. After some internal testing of the track made in the previous phase, it was decided that it was too difficult