Abstract

This paper is focused on two artificial intelligence (AI) techniques and how they can be used to promote emergent narrative (EN) within a hitman-style game.  The first of these techniques is goal-orientated action planning (GOAP) and the second is the use of a centralised AI storyteller which is present within many storytelling engines.  To achieve this, a literature review was undertaken which examines the current best practises in the fields of EN and AI in video games.  An artefact was then designed and developed using the current best practises found in the literature review.  This artefact was then evaluated through playtesting with a total of ten participants.  To evaluate the effectiveness of the artefact at promoting EN the playtest focused on the new methodology of retelling.  The results showed promise that the techniques used can promote EN within some players.  However, it is unlikely that these players would still experience the same levels of emergence after multiple playthroughs due to relatively short features for an EN-based game.

Introduction

The differentiating factor between narrative-driven games and other narrative-driven media is interactivity.  The ability for players to impact both a game’s narrative and environment is something unique to the medium. This ability is what creates the sense of immersion that is not discussed in more traditional mediums.  However, many narrative-based games deal with the same problem: Ludonarrative Dissonance (origin: Hocking (2007)).  This is the conflict that occurs between the linearity of a pre-scripted narrative and the fluid nature of gameplay.  Aylet (1999) describes this problem as the “clash between the pre-scripted character of much narrative and the freedom afforded by a Virtual Environment.”  The solution she proposed, and which many others have built upon, is EN.

EN is any narrative that is experienced by the player but has not been written by the author. Instead, the player writes the narrative through being immersed in game’s world and events.  Designing games with the goal of creating EN amongst players is not only an elegant solution to the problem of ludonarrative dissonance, but also often provides players with a re-playable experience due to the unscripted nature of both the game’s narrative/events.  EN-based games also create experiences that feel unique to each player due to the involvement of the player’s own imagination. Brown (2020) refers to this as the ‘Snowflake Con’.  Fahraeus (2016) states that unpredictability is a key ingredient for EN and therefore it is no surprise that AI is often a technical pillar of these games.

Literature Review

Before starting the design and development phases of this project, a review of the existing literature was undertaken to gain an in-depth understanding of current best practises and theories in this field.  It covered two categories: the primary being the current practise for creating EN-based games and the second being an examination into the current AI-based techniques in the context of EN-based games.

Emergent Narrative Practises

EN was first outlined by Aylet (1999) as a response to the narrative paradox that occurs in narrative-based games, since then many others have built upon her work.

Fahraeus’s Principles for Emergent Narrative

Fahraeus is considered one of the leading experts on EN within the games industry, he worked on both the game and narrative design of Crusader Kings 2 (2012).  During a 2016 GDC talk, Fahraeus lays out what he considers to be the core principles that can promote EN.  These are a complex simulation, unpredictability/chaos, a human factor, a seedling of prewritten narrative, conflict and dubious morals.  These principles were proved correct in Crusader Kings 2 which is considered a masterpiece in emergent gameplay.

The effectiveness of these principles can be contributed to them all working together.  For example, the complex simulation provides life to the game world but without the unpredictability, it would likely result in rigid routines that do not promote EN.  The human factor gives the player chance to empathise with the characters, especially when the game has provided the seedling of narrative about them.  This gives the player the starting point to fill in the blanks and prompts them to start writing the rest of the story themselves.  Lastly, it is no surprise conflict is included in this list. As without it there can be no tension or motivation within the narrative.  This will often require using dubious morals to find a solution and that leads to memorable and story worthy experiences.

Storytelling Engines

EN-based games have recently started being referred to as ‘storytelling engines’ by both developers and academics.  Some notable examples being Kreminski et al (2020), Brown (2020) and Sylvester (2019).  Storytelling engines focus on providing the ingredients needed for EN instead of focusing on telling a single story like more traditional games.  The primary advantage of this approach is that the player is given a game that has the potential to create as many stories as the player can imagine.  This open-ended nature means storytelling engines often have the potential to adapt or change the narrative in reaction to the player’s actions in a way that is not feasible in linear or branching narratives.  Therefore, storytelling engines often avoid the ludonarrative dissonance that comes with these more traditional games.

Goal Based Characters

One common feature of both emergent games and storytelling engines is goal-based characters. This can be seen in the work of Aylett Et Al (2006), Louchart (2007), Szilas (2003), Cavazza & Charles (2002). These are characters within the simulation that make decisions based on their own goals. This technique is used to give characters a wider variety of behaviours that feel more organic as they can quickly adapt to changes in their environment.  These goals can be practical and survival based, such as the characters in the Sims, as shown by Brown (2020) or more abstract and narrative-centric, as proven by Cavazza Et al. (2002).   This is also present within the work of Riedl & Young which is discussed below.

Centralised Storytellers

A recurring concept within the field of EN is the centralised AI storyteller.  This concept can be described as an AI entity that does not exist within the game’s narrative or world.  This entity is responsible for altering the game’s simulation with the intention of creating a more interesting series of events that promote EN.  This concept has been featured in much EN focused research; some of which include Szilas Et al. (2003), Louchart & Aylett (2007) as well as Cavazza et al (2002).  Riedl & Young (2003) used a centralised storyteller called ‘the blackboard’ that aims to combine the benefits of a character-centric and author-centric approach through its top-down control.  They build further on this concept in 2005 with a more advanced story planner.

The use of this kind of system in EN-based games was justified by Cavazza, Charles & Mead (2002), through the statement “There is a need to incorporate some kind of narrative control on top of the system to ensure the narrative relevance of generated situations”.  Without a centralised storyteller, simulations of AI agents are likely to produce repetitive outcomes that do not produce interesting or varied narratives.

A popular EN-based game that utilises a centralised AI storyteller is Rimworld (2013). In this title players are given the choice of multiple AI storytellers (each with their own personalities and levels of cruelty/difficulty). This mechanic not only offers greater re-playability but also helps promote EN through creating a character out of the game’s top-level systems which player feels they have a relationship with.

Figure 1 - AI Storyteller Selection in Rimworld (2013)

Centralised storytellers often used narrative events to create an interesting experience.  The algorithm that controls these events can vary from highly selective, pseudo-random to fully random depending on the game, context or difficulty.  For example, in Rimworld events are pseudo random or random depending on which storyteller has been chosen.  However, in other games storytelling events can be linked to an in-game resource.  For example, if they player has an abundance of crops, the storyteller might try to add tension through a drought or food shortage.  This provides the developers with a way of maintaining balance within the gameplay, which ensures the player is always experiencing Fahraeus’s principle of conflict which is required for EN.  Another advantage of story events is that they ensure Fahraeus’s principles of unpredictability to the situation as well as giving the player the seedling of narrative needed to lay the foundation of EN.

Player Journal

In the recent paper by Kreminski & Mateas (2020) the concept of a transcript was outlined. This refers to a journal that the player can keep about their experiences.  In EN-based games traditional quest logs are likely to lead to ludonarrative dissonance, as the content might not sync to the player’s internal narrative.  Therefore, by giving the player to chance to write their own avoids this problem entirely. However, this concept does go against Fahraeus’s principle of seedlings of prewritten narrative as any such narrative will have to be re-transcribed into the journal by the player.  It should also be noted that journals are not present within many EN-based titles, the exception being Minecraft (2011).  However, this could also be explained by the concept being so new that developers have not had time to incorporate journals yet.

AI Practises within Emergent Narrative Based Games

Hart (2009) provides a solid foundation of AI-based practises within games before examining techniques specific to EN-based games.

Cyclic Scheduling

Cyclic scheduling is an AI methodology that has been used in both non-emergent games, such as Skyrim (2011), as well as emergent games like Prison Architect (2015).  As the name suggests, cyclic scheduling involves regulating AI behaviour through scheduled tasks that repeat on set intervals. A common schedule is the hours in a day.  Therefore, a schedule may include sleeping at night and working in the day (with some free time in-between).  Prison Architect gives the player control over the AI schedule as part of their role as warden of the prison.  This lays the foundation for EN, as it constantly gives players the choice of overworking their staff and prisoners to maximise efficiency or of prioritising the emotions of characters within the game.  The emergent gameplay from this mechanic comes from the characters reacting to their schedule (with unhappy prisoners more likely to riot or disgruntled staff more likely to strike).  However, one common complaint of cyclic scheduling is that it produces rigid, repetitive behaviour (by design) which conflicts with Fahraeus’s principle of unpredictability.   Cyclic scheduling is described in detail by Zhao & Szarfron (2014) where they outlined principles on how to use it to create believable behaviour.

Utility Theory

Utility theory is explained in detail by (Mark 2009) and has also been used in both EN-based games (Zoo Tycoon 2 (2004)) as well as more linear games (Red Dead Redemption 2).  Utility AI works through scoring the viability or cost of each of the available actions and then choosing the outcome that is most desirable in the current context.

Utility theory can take a modular approach to agent behaviour which was outlined Dill & Martin (2011).  Dill further expanded on this during a GDC talk (Dill, Dragert & Humphereys (2018)) where he explains that the advantage of this modular approach is that it allows agents to share certain logic and behaviours while also having logic that is unique to certain agents depending on their role or specialisation.  For example, in a medieval game, only archers require logic for firing bows while all agents require logic that handles pathfinding or universal behaviours such as eating, dying or sleeping.  Utility theory has been proven to work in a variety of games, but its major downside is its complex nature because the algorithm that grades each possible outcome can quickly become complex when it is required to account for multiple possible situations.  A modular approach to utility theory outlined Simonov et. Al (2019) was used to simulate the flow of crowds within  the Olympic Park train station in Sochi during Winter Olympic 2014 but the implementation was outside the scope of this paper.

Goal Orientated Action Planning (GOAP)

GOAP is a very common technique used within storytelling engines.  GOAP was first outlined by Orkin (2006).  In his paper he describes how he implemented the enemy AI for the game F.E.A.R (2005).  He describes GOAP as a simplified version of the STanford Research Institute Problem Solver (STRIPS) from which was outlined by Fikes and Nisson (1971).

In GOAP an agent’s logic can be broken down into two parts; goals selection and then planning an action (or series of actions) to complete that goal.  Actions within GOAP can take either a microlithic or monolithic approach. Macro actions will satisfy a goal on their own, whereas micro actions need to link with other actions to satisfy a goal. This is explained by McManus (2021) who is an ex-Creative Assembly developer and now a game AI educator.   For example, imagine the ‘eat food goal’ has been selected.  In a mono methodology, a single action might contain the logic for calling up the pizza place, placing an order, waiting for delivery, and eating the pizza (all within a single action).  Whereas in a micro methodology each of those steps would be an individual action that needed to be linked together to complete the goal (this is where the planning in GOAP comes from).  The downside of this micro approach is its complexity to program (compared to a macro approach).  However, the advantage is its scalability as each action can be used in a variety of plans.  For example, the wait action might also be used to satisfy the ‘get a taxi’ goal as well as the ‘order a pizza’ goal.

Orkin (2006) outlines some the advantages of using GOAP.  The first being that through GOAP it’s possible to “Decouple Goals and Actions”. This allows characters to choose how to satisfy a goal in different ways, creating more believable and varied behaviours.  This works within the context of EN as it creates unpredictability as per Fahraeus’s recommendation.

The second advantage outlined by Orkin is “Layering Behaviour”.  The example Orkin uses in that an agent might choose the ‘kill enemy goal’ and then switch the ‘dodge goal’ when that enemy points the weapon in the agent’s direction. They can revert to ‘kill enemy goal’ straight after.  And as mentioned previously, each of these goals can be satisfied with many different actions. The result is fluid chain of behaviours that create a response and varied AI.

The final advantage laid out by Orkin is “Dynamic Problem Solving”.  As the agent is constantly taking in new information about the state of the game and choosing new actions.  GOAP agents are robust enough to be placed in new environments while stilling producing believable behaviour.  In my opinion, it’s this ability to create varied behaviour in a wide array of situations that makes GOAP an ideal technique for storytelling engines and EN-based games.  GOAP’s ability to produce believable behaviour was proven by Lindstam & Svensson (2017).  They produced GOAP agents that were perceived as incredibly ‘human-like’ by play testers.

Smart Objects

Smart objects are way of separating behaviour logic from character with a goal-oriented workflow.  Smart objects are a technique used with the Sims’ Franchise that are described by Brown (2020).  Agents will constantly scan their surroundings for smart objects and then choose to interact with the object that best fits their current goal.  The advantage being that it reduces the amount of logic on the character object while maintaining the same level of complexity. By moving the behaviour logic towards smart objects, designers must work with less code in any given context.  For example, if there are no ovens in the current environment, they do not have to worry about behaviour code for cooking as it will not be needed until someone buys an oven.

Another advantage of Sims’ smart objects is that the player can reshape the game’s environment at any point. Therefore, agents need to constantly check for changes to their surroundings and update their behaviour accordingly.  If the behaviour logic was always on the agent, additional checks to see if each action is valid would need to be performed to prevent an agent trying to interact with an object that no longer exists.

Artefact Design

The artefact, that has been designed to test how AI promotes emergent narrative, is a first-person, stealth game where the player takes on the role of a hit man with the goal of killing three targets without anyone noticing.  The game takes place within an exclusive, upper-class mansion filled with wealthy, influential socialites.  These characters are all procedurally generated and thus all have unique names and characteristics.  There is also a centralised AI storyteller component that can alter the simulation through story events.  Due to limited time available for this project and the complexity of the above systems, the focus was on developing a proof-of-concept prototype rather than a complete and polished game.

Initial Design

The artefact was planned as a detective game where the lead character is tasked with finding a murderer who is killing the other characters.  However, during development and playtesting two problems occurred.  Firstly, players would not interact with the simulation and just observed (looking for suspicious behaviour).  The solution was to reward interaction with clues but this uncovered the bigger problem of information design in detective games, which has been documented by GMTK’s Brown (2017).  Instead of spending time on information design (not this paper’s focus) the decision was made to switch to a hitman game.

Gameplay Loop

The gameplay loop is outlined in the below graph.  It starts with a short tutorial which explains that there is a hidden compartment with details on their targets (accessed by straightening a crooked painting).  The player must explore then mansion to find and eliminate their targets.  Any witnesses will panic and go around alerting others and the player must eliminate these witnesses within 30 seconds.  Once the player kills their target, another is generated.  When the player wins the game after they eliminate three targets.

Figure 2 - Gameplay Loop

Features & Mechanics

First Person Gameplay

A first-person perspective was chosen to try and create a feeling of immersion.  The player was given the same movement options as the AI characters, so they naturally blended into the crowd.  This included sprinting but not crouching.

The player is equipped with multiple tools to complete their mission. These include a knife, map, torch and their journal.  However, the most useful mechanic is the ability to talk to the AI characters.  The image below is a design mock-up of what talking to a character looks like from the player’s perspective.  It’s designed to promote EN by communicating unique information about the character as well as what they have been up to recently.  This is intended to give the illusion of them living their own life, independent of the player/gameplay.  The buttons give the player multiple possible ways to isolate the character they are speaking with, a crucial hitman gameplay feature.

Figure 3 - Interface Mock-Up (using Minecraft (2011) as a background)

Goal Based Agents

It was clear from the frequency of goal-based agents in the existing EN-based research, that they should be included.  The specific AI methodology that was chosen was GOAP mixed with cyclic scheduling.  Utility theory was also considered but was not selected due to its complexity over a monolithic GOAP methodology.  Cyclic scheduling and GOAP were chosen to ensure that agents could generate varied and non-repeating behaviours while still maintaining a ‘realistic’ sleep and work schedule.  This was done through disabling GOAP at specific points on the agent’s schedule.  The ‘CharacterBrain’ component was designed to handle this switch in behaviour logic and the flow chart below outlines the design of this system.

Figure 4 - Flow Chart of the Character Brain Class

The priority of goals was inspired by Maslow’s Hierarchy of Needs (Maslow (1943) & Mcleod (2018)) which was also inspired by what Brown (2020) describes within the Sims franchise.  The agents will priorities their needs that are essential for survival like hunger and then only move onto ones that are less focussed on satisfying essential goals like boredom or loneliness once these have been met.  This system combined with the randomly generated CharacterStats class creates varied behaviours with characters who tend to have (similarities?) preferences in their behaviour.

Centralised Storyteller

The game features a centralised entity that can control the simulation through story events; this concept was directly influenced by those mentioned earlier.  This entity has been designed to have the ability to influence the simulation through ‘story events.  The story events are designed to prevent the simulation from becoming too repetitive and to stop the feeling that each of the agents are acting independent of all the others.

Intentionally Ambiguous Dialogue

The ability of agents to communicate was included in the design to give the simulation another layer of complexity.  Having an animation play while characters stand next to each other could be a solution but this would look rigid.  This wouldn’t encourage the player to project meaning onto the conversation.  For these conversations to promote EN, they would need some unpredictability (as outlined by Fahraeus (2016)).   Brown (2020) describes a solution in the Sims where the topics of agent’s conversation is represented by icons that are designed to be intentionally ambiguous.   Brown explains that this ambiguity encourages player projection (especially in relation to emotions) and makes Sims seem smarter than they are.  This is because icons that do not fit the player’s internal narrative are easy to dismiss or, ideally, find an interoperation that does find the EN.   Sylvester (2019) also touches on this concept when he states that he designs graphics to be symbols that represent an abstract concept with a lot of room for interpretation.

Player Journal

A concept taken from Kreminski et al (2020) is the player writing their own journal during the game.  This would have been more effective in the original detective game but it had already been implemented by the time of the change.  Players can write themselves notes but during playtesting this feature was not used extensively.  Most testers ignored the feature entirely (apart from a few who added an entry just to test its functionality) and the remainder used rarely used it (mostly to remind themselves the name of their target). None used it to tell emergent stories.

The first possible explanation is that it is not feasible to stop half through an EN to write about it.  The players who experienced EN were likely too engaged to stop and recount it.  Another explanation is that as there was no reason to use the journal in the context of the gameplay as players didn’t see any point in using it.  In future, the use of an in-game journal should be examined within a context that justifies using one (such as the original detective game).

Incorporating Fahraeus’s Principles for Emergent Narrative

The core principles of most design decisions were based on Fahraeus’s Principles.  This decision was made by concluding that many successful EN-based game designs follow them including Rimworld (2013), Prison Architect (2015) and the Sims franchise.  In addition, many of the other concepts within this field further support his argument (see literature review).  The artefact utilises these principles in the following ways:

Complex Simulation

The heart of the game is the AI simulation. These agents make up the characters in the narrative and can perform a variety of behaviours.

Unpredictability

Unpredictability can occur in many ways. Agents have a variety of actions to satisfy each goal. The story events can suddenly change the current simulation state and the player cannot predict their targets.

Human Factors

The human factor of the game comes from the AI characters.  They are all visually representative of a humanoid character but also have unique properties which model humanity. These include their own name, age, sex, and occupation as well as some emotional predispositions such as bravery, sociability, restlessness and perception.  These create different personalities and was inspired by Aylett (2006) who was inspired by a cognitive model developed by Ortony et al (2011) to simulate character emotions.

Seedlings of Prewritten Narrative

The game starts with a tutorial explaining the objective and how to play. However, to include some prewritten narrative, this tutorial was written from the perspective of the player’s employer.  It gives the player a vague backstory as a starting point for the players internal narrative. The text was kept as vague as possible to keep the player’s imagination constantly active.

Conflict & Dubious Morals

The game is about killing people, so it is expected the players will put their real morality aside.  The conflict in the gameplay comes from the characters suspicion meter.  The conflict occurs because all the characters are trying to out the player and the player is trying to stay incognito.

Level Design

The game takes place in an upper-class mansion and was chosen to implicitly associate the game’s setting with money and power.  It’s designed to encourage the player to think of the possible motives there could be for their wealthy targets to meet such an unfortunate fate.

The main design consideration was to create a space that was small enough for the player to observe the simulation, while at the same time being large enough to allow the player to sneak around.  In existing titles, a ‘fog of war’ mechanic is often used to achieve this and this is present within many EN-based games such as Prison Architect (2015).  However, the mansion was designed so that this mechanic is not required.  Instead, the many walls and closed doors act as the ‘fog of war’ because the player can only ever observe a tiny portion of the mansion at any one time.

The design was inspired by the levels in the Hitman Franchise, which is analysed in depth by Brown (2019) and Black (2019 & 2021).  The main difference between our workflows is the AI design.  In the Hitman games, AI have observable patterns that the player can exploit.  One technique that was borrowed from the Hitman games was to limit the number of rooms with a single exit to encourage exploration and ensure the player does not get trapped by suspicious characters.

Figure 5 - The 2D Level plans made in Illustrator

Many versions of the level were designed on paper.  The final design was recreated in Adobe Illustrator.  These plans were then used as top-down background images during the modelling process in Blender and act as the player’s map.

Overall, the level works well as players found it enjoyable to explore and the many rooms successfully created a fog of war.  The upstairs was utilised far less than the ground floor as characters only sleep and shower there.  Both actions are non-interactive and are called upon quite rarely.  Therefore, when redesigning the top floor, more smart objects could be added to meet the needs of a wider array of goals and potentially make it more important to the gameplay.

Artefact Development

Tools & Software

The project was developed within the Unity Engine (version 2019.4.30f1 - the university’s most recent version).  Both Visual Studio 2019 & Visual Studio Code were used as an integrated development environment (IDE).   Blender 2.80 was used for modelling and unwrapping whereas Photoshop was used for all texturing.

Overall Project Architecture

Figure 6 - Overall Project Architecture

Above, is a diagram of the project architecture from a top-down perspective. This can be broken down into three categories: the player (red), the game controller (green) and the storytelling engine (blue).

The game controller is responsible for handling the logic that stores the game state, including the pause state and the debugging window.

The storytelling engine follows a standard design. It is made up of the centralised storyteller, AI characters, smart objects and world systems.  The world systems include an in-game calendar and day/night cycle.

The player logic is split between a total of twelve classes. These can be broken down into the three categories.  The PlayerUI class holds all the logic for displaying the user interfaces.  The PlayerInput class collects mouse and keyboard data and stores it for other classes to access.  Lastly, the player object represents the rest of player related classes that allow the player to move and interact with the simulation.  The direction of the arrows in the diagram represents the flow of information between the game objects and classes.

Technology Demonstration

Due to the complicated nature of programming a storytelling engine, the first phase of development time was spent on creating a tech-demo that proofed the project’s feasibility with such a short schedule.  The demo contained the simulation of AI agents, centralised storyteller and world systems.  The advantage of this workflow was that if the systems outlined in the design phase of this paper had proved to be too complex in scale, it would have been discovered early when there was still time to change direction.  Fortunately, the tech-demo was a success so the focus was moved to building the demo into a playable game instead of a simulation.  The demo has since been removed from the final artefact due to cloud-storage size limitations.

Figure 7 - Screenshot of the Tech-Demo Simulation

The Use of Inheritance

During development of the tech demo, it was clear that many objects needed unique properties but also had to share many universal ones.  This problem occurred within the story events, character actions as well as later in the player’s tools.  The obvious solution to this problem was inheritance.

Player Systems

Figure 8 - The Entire PlayerInput Class

Communication Between Player Classes

The logic to handle player movement is split across three classes; these include PlayerInput, PlayerMovement and FpsLook.  The first class, PlayerInput, consists of a collection of public variables that are set each frame to the player’s keyboard and mouse input during runtime.     One important change that was made to the PlayerMovement and FpsLook classes during development was switching from the Update() function to LateUpdate().  The reason for this is, Update() is called at the start of each frame whereas LateUpdate() is called at the end of every frame. Therefore, collecting input and processing it both within Update() can lead to situations where the game is processing the input from the previous frame.  This can result in the game ignoring Boolean inputs that only last for a single frame (such as jump or interact).

Figure 9 - Player Movement Code

Player Interaction

The player interaction class is constantly checking middle of the player’s screen for objects they can interact with and this could be a character or smart object.  This is achieved using a ray cast that starts at player’s camera transform and ends 2.5 meters in front of them.  To keep track of what the player is currently looking at, a variable called currentFocus is used.  Once, the player’s focus changes, a function is called within PlayerUI class to display a text prompt about the focus.  If the focus does equal null, the Interact() function can be called which will start the interaction between the player and the current focus.

Figure 10 - Player Interaction Class

Player Hot Bar & Tools

The player has multiple tools to use during their mission and these include, the journal (mentioned previously), a torch, a knife and map of the mansion.  The way the player selects each tool is through a hot bar system (inspired by games like Minecraft (2011)).  Each of the items on the hot bar inherit from the Tool class which makes it possible for the hot bar logic to be an array of tools that can be cycled through using either the scroll wheel or number keys.

Figure 11 - Example of Torch inheriting from Tool

Individual AI Characters

Below is a class diagram detailing the architecture of the individual characters.

Figure 12 - Class Diagram of Character AI

Character Stats

Without ways for the player to tell the different characters apart, the potential for EN would extremely limited.  Therefore, the CharacterStats class was developed to make them unique at the start of the simulation.  The character stats can be divided into two main sections: their basic and ability stats. Basic stats consist of their name, age, sex and occupation and this information is displayed to the player when they speak with a character.   Whereas ability stats are hidden from the player and are designed to give each of the character a varying emotional predisposition.  This is achieved through randomly setting the rates at which the goal parameters increase or decay and this creates variations in agents’ behaviour patterns.  For example, when a character is generated with a high sociability trait, they will end up performing the socialise actions more frequently than agents with a lower score.

Figure 13 - Example of generated character stats

Character Brain

This class was implemented to the specification that was outlined in the previous class diagram.  The logic occurs within FixedUpdate() to save on performance.  Some of the character goals will not update depending on the characters current state; for example, boredom will not increase if the character is asleep.

Figure 14 - Character Brain (Viewed from the Inspector)

Character Actions

The actions classes are attached to the characters and create behaviours that are observable by the player.  There are a total of nineteen actions attached to each character that can generate a wide variety of behaviours (shown within the image above).  These actions have been programmed using inheritance, with each action inheriting properties from the ‘Action_Base’ class.

Figure 15 - Action Base Class

One downside having separate classes for each action, is the inspector becomes cluttered when a character with so many actions, making it difficult to work with.  If there was more time, there are a few changes that could be made.

The first being, to divide the array of actions (on the CharacterBrain) into multiple arrays based on each goal. This would improve the readability of the ‘PickActionFromGoals()’ function and make it easier to make changes to the code.  An Enum also increase the readability.

The second change is grouping actions together into only a handful of classes as well as expanding the CharacterUtility class to handle more of the behaviour logic.  Most actions are actually very similar in architecture and therefore do not need their own individual class.  Almost all actions consist of the following steps:

1. Get the agent to move toward position (usually the transform of a smart object)
2. Wait until the agent has reached their destination
3. Start coroutine to complete the action. This will usually play an animation and change the values of the smart object or character.
4. When the coroutine has finished, disable the action and repeat with a new goal.

Therefore, a single class that takes in parameters could be used to handle the majority behaviours.  This would reduce the amount of code while keeping the same level of complexity in the simulation.  The primary reason that these changes were not made was that they would not change the player’s experience.  The priority during development was always to deliver EN and due to the short development cycle, it did not make sense to make such large changes to the architecture for no gameplay improvement.

Character Utility Class & Pathfinding

The agents within the simulation each contain a NavMeshAgent component which allows agents to use the engine’s built-in navigation mesh system for pathfinding.  This system uses the common A* algorithm.  The CharacterUtility class contains a collection of public methods that handle the pathfinding logic for each agent.  These methods can be called upon by the agent’s action classes on a as needed basis.  The advantage of containing all this logic on a single class became obvious as the project scaled in complexity as a lot of these methods were required by all the characters’ actions.  Containing all this logic in a single class resulted in an easier to read, better structured code that had less repetition within it.

Figure 16 - Nav Mesh within Unity Editor (blue represents walkable areas)

Figure 17 - The Functions within the CharacterUtility Class

Character Animation

Instead of having the code to handle animation embedded with each of the actions, it was much more efficient to have a single class that handles all animation.  The advantage is that all the animation logic can be handled through a handful of public methods that can be called as needed, instead of having to write the same code for each of the nineteen actions.   As the image below shows, the result of this approach is a single class that is easy to read and can be used to handle a variety of animations through just a handful of functions.

Figure 18 - All the code from the CharacterAnimator class

The class above, communicates with Unity’s Animator component which contains all the animation data for each of the animation states.  These states (and their links) are visually represented through a node graph which can be seen in the image below.  This graph is not as complex as it initially looks.  The list of parameters on the left are set through the code in the image above which control the animation state.  The first three are Booleans and are used in variety of animation states whereas the rest are trigger variables.  Each of the animation nodes that are called through these triggers have a link back to idle for when the animation has finished.  Each of these animation triggers will loop their animation until the ‘InAction’ Boolean is set to false.

Figure 19 - Character Animation Tree

Smart Objects

The simulation is scattered with smart objects and these can be interacted with by either the player or the agents.  Smart objects have properties (like Booleans for if the player can interact with the object or if its currently being used by anyone). These variables are useful when checking if it possible to interact with that object.  For example, ‘canUse’ will be set to false while it is being used which will prevent other agents from trying to use the object at the same time.  This was implemented to due to a bug that prevented multiple characters from using the shower at the same time.  Before this change it was possible for groups of characters to all try and fit in the shower at once (resulting in people being trapped and no one being able to start showers as each agent would stop others from reaching the pathfinding destination (the shower’s transform)).

Figure 20 - Example of Smart Object using Inheritance

The major flaw in the smart object architecture is the lack of behaviour logic within the smart object code. Without this code, these are not true smart object in the way the Brown (2018) described them.  However, they do fulfil half of the criteria as they are used to help agents complete their goal. For example, a bored character might interact with the piano or poker table smart object which will satisfy their boredom.

Figure 21 - A character interacting with the Piano Smart Object

Centralised AI Storyteller

As mentioned earlier, the AI storyteller can alter the simulation.  In the final game there are total of three events that can occur. These include a pool party, bar party and a follow event. Other story events were planned but were not included due to time limitations.

Story events are called at random intervals using a coroutine.  Once the coroutine hits finishes the event is called.  When the event has concluded it will disable itself and restart the coroutine, so another story event can occur.  Unfortunately, the possible event that is chosen to run, is also chosen at random instead of each story event having conditions like initially planned.  This change was made due to time limitations.   The storyteller has a list of characters which can be used by the story events as needed.  If a character dies, they will be dynamically removed from this list to prevent errors.

The architecture of story events was inspired the characters actions architecture.  One of the properties is an Enum which keeps track of the event’s state.  The main benefit of this architecture is how easy it is to add more story events to the game (with more time). Play testers found the two-party story events very entertaining (which was mentioned multiple times in the retellings).  The ‘follow event’ successfully promoted EN as players would get worried that the character following them was getting suspicious of them and they would try to avoid them for the rest of the game.

In hindsight, one flaw of the storyteller is that it is does not select the player’s targets (instead it is handled by a stand-alone system called Objectives).  There is potential to further promote EN by having the storyteller handpick targets.  This could lead to situations where the target grows suspicious of the player at a far greater rate than the rest of the characters, giving the illusion they know someone is after them.  The storyteller could also pick targets based on who is most suspicious of the player, which would open another possible way for the player to project backstories and meaning onto their targets.

World System

The classes that make up the world system are Calendar and DayNightCycle and together they create the illusion of passing time.  Calendar provides the simulation with an in-game time and date that is always displayed on the screen.  The code which handles this passing of in-game time is contained within one simple function which can be seen in the imagine below.  This function is called within FixedUpdate() instead of Update() to ensure the speed of an in-game day is not sped up or slowed down by the games frame rate which might change depending on the state of the simulation.

Figure 22 - Date & Time Update Code

Once the time and date has been updated, the user interface in the bottom left of the screen is updated to reflect the new time and date as seen below.

Figure 23 - Update Calendar Interface Code

DayNightCycle uses the current time of day to update the game’s lighting and the code for this can be seen below.  This gives the player a visual representation of the time within the game and helps to immerse them and hopefully further promotes EN.  The lighting of the scene is changed through altering the colour of the directional light (the sun), skybox and fog using three different gradients.  These gradients were part of the lighting pre-set scriptable object that is referenced on the second line of the class.

Figure 24 - The code that changes the game's lighting based on the time of day

Art & Graphics

Unfortunately, the art and graphics did not receive the same attention as the design and programming as most of the development time was spent on AI & gameplay systems.  The major flaw is the lack of sound effects within the game. Fortunately, Sylvester (2019) states that graphics are not crucial in EN based games.  My artefact adhered to his principles outlined and used in Rimworld (2013) as follows:

1. Not Ugly
2. Easily Identifiable
3. Minimal Noise
4. Intensity Hierarchy
5. Fast Implementation
6. Leaves room for interpretation

The game adheres to these six rules throughout, despite not being able to invest as much time in the game’s art as its programming.  During play testing, no players had trouble understanding the art and it didn’t seem to impact the gameplay (some play testers even said they liked the simplistic cartoony style).  No testers mentioned the lack of sound or seemed to have had a diminished experience.  There are many successful games focused on EN that have cryptic and hard to interpret graphics such as the famous Dwarf Fortress (2006).

Figure 25 - Dwarf Fortress (2006) Graphics

Almost all the game’s environment models and props were modelled by hand within Blender. To save time, a low-poly, box modelling workflow was used.  All models use the same colour pallet texture and each of the models are textured using these flat colours.  Some of the models, have been reused from my previous projects (to save time).

Figure 26 - The piano model & colour pallet within Blender

Third Party Assets

Multiple third-party assets were used during development to handle the aspects that are not the project’s focus.  The Basic Motions FREE pack by Kevin Iglesias was used for the character model; some of the animations included in this pack were used for the characters locomotion-based animations.  The rest of animations (for more specific actions) were downloaded through Mixamo. Both rigs from these assets are humanoids so it is easy to switch between animation from both sources.   The icons (used in the players hot bar and during character’s conversations) were downloaded from openmoji.org which is open-source set of emojis. Lastly, some models were downloaded from Sketchfab and were all released under a Creative Commons licence. Full references can be found below.

Evaluation

After development had been completed, the focus shifted toward evaluating the game’s potential to promote EN.  To do this objectively, a play test was conducted.

Methodology

Recently, multiple papers have been released outlining a new method of evaluating EN.  This comes in the form of retellings which is a concept from  Kreminski Et. Al (2019).  Retelling has been further built on by Sych (2020) as well again Kreminski Et. Al. (2022).  This methodology is ‘cutting-edge’ and its proved effective at evaluating EN, it is what was used for the evaluation.

The playtest was carried out with ten participants (none of whom had played it before).  Participants were given an information sheet (see appendix A).  Three of the sessions were conducted online as the players were not near Bournemouth and the rest were conducted on campus.

The each of the ten-playtesting session were structured as following:

1. Participants were given five minutes to arrive, get conformable as ask any questions.
2. The structure of the study was briefly explained (participants were not told they would be writing a story at this point).
3. Participants then played the game for up to 30 minutes.
4. Participants were asked to write a story about the experience. They were told they “Could be creative as they liked and there are no wrong answers” to try encouraging them to be as honest as possible.
5. Lastly, participants were given five minutes to ask questions and check they had not been negatively affected by the study.

Results

To evaluate the retellings, the practise of coding was used.  The chart below shows the coded categories, the frequency and that code’s sentiment.  Each of the positive codes represent one time (or more) when a participant described something in their retelling that did not actually occur within the game’s simulation. This shows the players imagination was stimulated by the game.  The negative codes are both times where the player’s immersion was clearly broken.

The retelling that showed the most positive signs of EN came from participant six.  The story they wrote contained a full backstory about his targets and why they he had been hired to kill them. During the explain of this story, he also embellished his own character’s backstory.  Below is an extract from his retelling (full story can be found under appendix G).

“Before the job I did my research on everyone who was gonna be at the party and these 3 may look like innocent people but are all part of a group of people that run one of the biggest crime syndicates in the world and I guess they are becoming a threat to my employer.”

The participant has clearly experienced EN as all these details have come from the participant’s own imagination and he has elaborated on other in-game events multiple more times through his retelling.  Other participants also contained some evidence of EN (numbers 3, 7, 8 & 9).

It is also important to note that 6/10 participants talked out-loud to the characters during their playthrough.  This is another sign of emergence occurring and it could be argued that the players were clearly immersed enough to speak to the characters aloud. Although one reason for this could be the participants is an observer and wants to fill the silence.   It is unlikely that participants would talk aloud if they had played the game in a more genuine setting.  However, participant six’s playtest was conducted online (they spoke to the characters aloud) and therefore this does show signs of emergence.

Analysis

One of the most positive signs that multiple players experienced EN was the frequency in which players elaborated on or filled in details about their in-game actions. Half of the stories contained some evidence of EN (See appendices for all retellings).  All these stories pointed toward EN through interaction with the characters.  However, only three participants referred to the story events which suggests that this feature needs to be further developed before it has a meaningful contribution to any EN. This could contribute to the low number of different events or the similarity of two out three events.

Another factor that needs to be considered, is each of the participants willingness/ability to experience EN. People are all different and some are far more creative than others and some people have far greater levels of empathy. These are two of the key user factors required for EN.  In future studies that evaluate a game’s EN, another game (that has proven its emergent gameplay) could be used to make comparisons with as a control variable.

Conclusion & Further Works

Upon reflection, the artefact clearly shows potential to promote EN. The evidence of EN often focuses on the AI characters which suggests that the AI techniques used are effective in promoting EN.  This can be attributed to the integration of the wide number of actions available to each character, combined with their randomly generated properties.  The result is characters that have varied behaviours which can be easily differentiated from one another.  However, a higher number and more varied story events are required to ensure the centralised storyteller has a meaningful impact on player’s EN.

Another limitation is the design of the artefact after the project changed direction.  As the focus was on AI, the game should have been designed in a manner that encourages more interaction with the AI characters that make up the simulation.  In the game’s current state, there is no incentive within the game’s mechanics to interact with characters who are not the target.  Instead, the character’s suspicious meters actively encourage the player to avoid them.  Although the game has proven its ability to promote EN, in future more emphasis should be focused on interacting with all the characters within the simulation.  Returning to the detective concept could potentially provide this incentive.

Another, drawback of AI-based games (Treanor et al (2015)) is their complexity to development and the time it takes to effectively plan, implement, and debug these systems.  It could be argued that planning the architecture of these systems is the most important stage of their development.  This is because once a system has started to be developed it can be incredibly difficult to redesign the system without restarting. Therefore, when planning EN-based AI systems it is crucial to have a clear set of desired behaviours.  Due to the large amount of code generated in this kind of project, a good practice would include keeping clean and well-maintained code.

The debugging aspect of this project was especially time consuming as due to the nature of the GOAP agents and several outcomes could occur from the same starting conditions.  This often resulted in running the simulation multiple times to test new or broken features.  Therefore, I would recommend that sufficient debugging tools are always developed when undertaking GOAP-based AI. These tools should include the ability to easily set the conditions for each agent as well as reading them.  This would reduce the time the simulation needs to be run to sufficiently debug the system.

Overall, this project has been success as the artefact proved its ability to promote EN.  In future work, the number and type of story events should be increased.  I would also argue that the incorporation of systemic game design could help further push emergent narrative.

References (Academic & Professional)

1. Hocking, C., 2007. Ludonarrative Dissonance in Bioshock. Click Nothing [online]. Available from: https://clicknothing.typepad.com/click_nothing/2007/10/ludonarrative-d.html [Accessed 4 May 2022].
2. Aylett, R., 1999. Narrative in virtual environments - towards emergent narrative. AAAI Technical Report [online]. Available from: https://www.semanticscholar.org/paper/f4e3728ab77700c1643d33c9a8ac86e2951ba2cb [Accessed 10 Feb 2022].
3. Matt Brown (GDC), 2020. Emergent storytelling techniques in The Sims [online]. Available from: https://www.youtube.com/watch?v=YjuOSgPdtS0 [Accessed 10 Feb 2022].
4. Fahraeus, H., 2016. Emergent stories in crusader kings II [online]. Available from: https://www.youtube.com/watch?v=f1Sc6segX_Q [Accessed 4 May 2022].
5. Kreminski, M., Dickinson, M., Mateas, M. and Wardrip-Fruin, N., 2020. Why are we like this?: The AI architecture of a co-creative storytelling game. In: International Conference on the Foundations of Digital Games [online]. New York, NY, USA: ACM. Available from: https://dl.acm.org/doi/10.1145/3402942.3402953. [Accessed 10 Feb 2022].
6. Hart, E. G. E. C., 2009. A taxonomy of video games and AI. AISB ’09 [online]. Available from: https://www.semanticscholar.org/paper/8abed4ed4500f8ca49057dacffa096aab28ebb62 [Accessed 10 Feb 2022].
7. RimWorld: Contrarian, Ridiculous, and Impossible Game Design Methods, 2019. GDC. Available from: https://www.youtube.com/watch?v=VdqhHKjepiE&t=3035s. [Accessed 4 May 2022].
8. Cavazza, M., Charles, F. and Mead, S. J., 2002. Emergent situations in interactive storytelling. In: Proceedings of the 2002 ACM symposium on Applied computing - SAC ’02 [online]. New York, New York, USA: ACM Press. Available from: https://dl.acm.org/doi/10.1145/508791.509003.
9. Riedl, M. O. and Young, R. M., 2003. Character-focused narrative generation for execution in virtual worlds. In: Lecture Notes in Computer Science. Berlin, Heidelberg: Springer Berlin Heidelberg, 47–56.
10. Riedl, M. O. and Young, R. M., 2005. An objective character believability evaluation procedure for multi-agent story generation systems. In: Intelligent Virtual Agents. Berlin, Heidelberg: Springer Berlin Heidelberg, 278–291.
11. Szilas, N., Marty, O. and Réty, J.-H., 2003. Authoring highly generative interactive drama. International Conference on Virtual Storytelling [online], 37–46. Available from: http://nicolas.szilas.free.fr/research/Papers/szilas_TR_IDT0301.pdf. [Accessed 10 Feb 2022]
12. Louchart, S., Aylett, R., Kriegel, M., Dias, J., Figueiredo, R. and Paiva, A., 2007. Authoring emergent narrative-based games. Journal of Game Development [online], 3 (1), 19–37. Available from: https://researchportal.hw.ac.uk/en/publications/authoring-emergent-narrative-based-games [Accessed 10 Feb 2022].
13. Zhao, R. and Szafron, D., 2014. Using cyclic scheduling to generate believable behavior in games. In: Proceedings of the Tenth AAAI Conference on Artificial Intelligence and Interactive Digital Entertainment. AIIDE’14: Proceedings of the Tenth AAAI Conference on Artificial Intelligence and Interactive Digital, 94–101.
14. Media, C. R., 2009. Behavioural mathematics for game Ai Dave Mark [online]. Karon.io. Available from: http://www.karon.io/Ebooks/Behavioral%20Mathematics%20for%20Game%20AI.pdf [Accessed 3 Mar 2022].
15. Dill, K. and Martin, L., 2011. A game AI approach to autonomous control of virtual characters. Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2011 [online]. Available from: https://www.semanticscholar.org/paper/bcdd2282e110f828c85bf64717a9ec437358cea2 [Accessed 10 Feb 2022].
16. Dill, K., Dragert, C. and Humphreys, T. (G D. C., 2018. Nuts and bolts: Modular AI from the ground up [online]. Available from: https://www.youtube.com/watch?v=IvK0ZlNoxjw [Accessed 10 Feb 2022].
17. Simonov, A., Zagarskikh, A. and Fedorov, V., 2019. Applying Behavior characteristics to decision-making process to create believable game AI. Procedia computer science [online], 156, 404–413. Available from: https://www.sciencedirect.com/science/article/pii/S187705091931141X. [Accessed 11 Feb 2022]
18. Orkin, J., 2006. Three States and a plan: The A.i. of F.e.a.r. Cognitive Machines Group [online]. Available from: https://www.semanticscholar.org/paper/012ef03d0f951092b8645b69aebdbce900ac03e4 [Accessed 10 Feb 2022].
19. Fikes, R. E. and Nilsson, N. J., 1971. Strips: A new approach to the application of theorem proving to problem solving. Artificial intelligence [online], 2 (3–4), 189–208. Available from: https://www.sciencedirect.com/science/article/pii/0004370271900105. [Accessed 10 Feb 2022]
20. McManus, I., 2021. Unity AI tutorial: Goal Oriented Action Planning [online]. Available from: https://www.youtube.com/watch?v=Q7aHXn_LypI [Accessed 19 May 2022].
21. Lindstam, T. and Svensson, A., 2017. Behavior based artificial intelligence in a village environment. [online]. Malmö högskola, Faculty of Technology and Society, Malmö, Sweden. Available from: https://www.semanticscholar.org/paper/a66d9fbb70d03a557c43a3b4acab7dab35ab39e5 [Accessed 10 Feb 2022].
22. Aylett, R., Dias, J. and Paiva, A., 2006. An affectively driven planner for synthetic characters. [online]. Available from: https://www.semanticscholar.org/paper/2786acec7aacb1121e906fa7698f6216d74c8d6c [Accessed 10 Feb 2022].
23. Ortony, A., Clore, G. L. and Collins, A., 2011. The cognitive structure of emotions [online]. Cambridge, England: Cambridge University Press. Available from: https://www.cambridge.org/core/books/cognitive-structure-of-emotions/33FBA9FA0A8A86143DD86D84088F289B [Accessed 10 Feb 2022].
24. Brown, M., 2019. Making Hitman 2’s Best Level [online]. Available from: https://www.youtube.com/watch?v=56iiP2xQn74 [Accessed 18 May 2022].
25. Black, H., 2019. Analysing Every Mission from Hitman 2 [online]. Available from: https://www.youtube.com/watch?v=JI5P8u_c7ig [Accessed 18 May 2022].
26. Black, H., 2021. Analysing Every Mission from Hitman 3 [online]. Available from: https://www.youtube.com/watch?v=DxYqM2zbsFw [Accessed 18 May 2022].
27. Kreminski, M., Samuel, B., Melcer, E. and Wardrip-Fruin, N., 2019. Evaluating AI-based games through retellings. Proceedings of the AAAI Conference on Artificial Intelligence and Interactive Digital Entertainment [online], 15 (1), 45–51. Available from: https://ojs.aaai.org/index.php/AIIDE/article/view/5223 [Accessed 17 May 2022].
28. Sych, S., 2020. When the fourth layer meets the fourth wall: The case for critical game retellings. In: Interactive Storytelling. Cham: Springer International Publishing, 203–211.
29. Kreminski, M. and Mateas, M., 2021. Toward Narrative Instruments. In: Interactive Storytelling. Cham: Springer International Publishing, 499–508. [Accessed 17 May 2022].
30. What Makes a Good Detective Game?, 2017. United Kingdom: Game Maker’s Toolkit. Available from: https://www.youtube.com/watch?v=gwV_mA2cv_0&t=199s.
31. Maslow, A. H., 1943. A theory of human motivation. Psychological review [online], 50 (4), 370–396. Available from: https://psycnet.apa.org/fulltext/1943-03751-001.pdf. [Accessed 17 May 2022]
32. Mcleod, S., 2018. Maslow’s hierarchy of needs [online]. Canadacollege.edu. Available from: https://canadacollege.edu/dreamers/docs/Maslows-Hierarchy-of-Needs.pdf [Accessed 17 May 2022].
33. Hart, E. G. E. C., 2009. A taxonomy of video games and AI. AISB ’09 [online]. Available from: https://www.semanticscholar.org/paper/8abed4ed4500f8ca49057dacffa096aab28ebb62 [Accessed 10 Feb 2022].

References (Third Party Assets)

1. Adobe, 2022. Mixamo [online]. Mixamo. Available from: https://www.mixamo.com/#/ [Accessed 17 May 2022].
2. Daniel Utz & Benedikt Group, 2022. Open Emoji [online]. Available from: https://openmoji.org/ [Accessed 17 May 2022].
3. Iglesias, K., 2021. Basic Motions FREE [online]. Unity.com. Available from: https://assetstore.unity.com/packages/3d/animations/basic-motions-free-154271 [Accessed 17 May 2022].
4. Holhanov, V., 2022. Bar. Sketchfab. . [Accessed 17 May 2022].

https://sketchfab.com/3d-models/bar-842754f23a384d7e86aca94d12aa34ca

5. Wibowo, A. A., 2020. Low Poly Stylized Book [online]. Sketchfab. Available from: https://sketchfab.com/3d-models/low-poly-stylized-book-e8e50b1619c247219a00bde395eaa4be [Accessed 16 May 2022].
6. Alexbreeze111, 2021. Low Poly Torch [online]. Sketchfab. Available from: https://sketchfab.com/3d-models/low-poly-torch-9318bd0b89964845b7130c2326becfa5#download [Accessed 16 May 2022].
7. Brum, N., 2021. Valorant’s knife Low Poly [online]. Sketchfab. Available from: https://sketchfab.com/3d-models/valorants-knife-low-poly-ede1d0f29eda4ade879cdfd125f0a9f5 [Accessed 17 May 2022].

Ludography

1. Studios, L., 2013. Rimworld [online]. Available from: https://store.steampowered.com/app/294100/RimWorld/.
2. Mojang, 2011. Minecraft [online]. Available from: https://www.minecraft.net/en-us/download.
3. Games, B. 12, 2006. Dwarf Fortress [online]. Available from: https://www.bay12games.com/dwarves/.
4. Introversion Software, Double Eleven, Tag Games & Paradox Interactive, 2015. Prison Architect [online]. Available from: https://www.paradoxinteractive.com/games/prison-architect/about.
5. Studios, B. G., 2011. The Elder Scrolls V: Skyrim [online]. Available from: https://elderscrolls.bethesda.net/en/skyrim.
6. Games, R., 2018. Red Dead Redemption 2 [online]. Available from: https://www.rockstargames.com/reddeadredemption2/restricted-content/agegate/form?redirect=https%3A%2F%2Fwww.rockstargames.com%2Freddeadredemption2%2F&options=&locale=en_us.
7. Blue Fang Games, MacSoft, Microsoft Corporation, 2004. Zoo Tycoon 2 [online]. Available from: https://en.wikipedia.org/wiki/Zoo_Tycoon_2.
8. Paradox Development Studio, 2012. Crusader Kings II [online]. Available from: https://www.paradoxinteractive.com/games/crusader-kings-ii/about.
9. Outerlight, 2006. The Ship [online]. Available from: https://store.steampowered.com/app/2400/The_Ship_Murder_Party/.
10. Electronic Arts, 2000 - Present. The Sims Franchise [online]. Available from: https://www.ea.com/en-gb/games/the-sims.
11. Monolith Productions, 2005. F.E.A.R [online]. Available from: https://store.steampowered.com/app/21090/FEAR/.
12. IO Interactive, 2018. Hitman 2 [online]. Available from: https://store.steampowered.com/app/863550/HITMAN_2/.
13. IO Interactive, 2021. Hitman 3 [online]. Available from: https://hitman.com/global/.