Charles University in Prague. Faculty of Mathematics and Physics BACHELOR THESIS. Tomáš Hromada

Transcription

1 Charles University in Prague Faculty of Mathematics and Physics BACHELOR THESIS Tomáš Hromada Generating Side Quests for RPG Games From Hand-Crafted Building Blocks Department of Software and Computer Science Education Supervisor of the bachelor thesis: Mgr. Martin Černý Study programme: Computer Science Specialization: General Computer Science Prague 2015

2 I declare that I carried out this bachelor thesis independently, and only with the cited sources, literature and other professional sources. I understand that my work relates to the rights and obligations under the Act No. 121/2000 Coll., the Copyright Act, as amended, in particular the fact that the Charles University in Prague has the right to conclude a license agreement on the use of this work as a school work pursuant to Section 60 paragraph 1 of the Copyright Act. In... date...

3 I would like to thank my supervisor, Mgr. Martin Černý, for his thorough support during the writing of this thesis and for all of his advices. I would also like to thank Mgr. Pavel Hrnčiřík, my former high school teacher, who willingly agreed to let me evaluate my thesis on his students.

4 Název práce: Generování vedlejších misí pro RPG hry z ručně vytvořených stavebních bloků Autor: Tomáš Hromada Katedra: Katedra softwaru a výuky informatiky Vedoucí bakalářské práce: Mgr. Martin Černý, Katedra softwaru a výuky informatiky Abstrakt: Počítačové RPG hry často obsahují vedlejší mise, které jsou kratší a nevztahují se k hlavnímu příběhu, a které dávají hráči větší pocit volnosti a více možností na zvolení své vlastní cesty ve hře. Aby tato funkce byla dobrá, je potřeba mít ve hře větší množství vedlejších misí. Nahrazení ručně vytvořených misí těmi generovanými je jedna z možností, jak tento cíl ulehčit, nicméně současné pokusy o generování misí vedly k vytvoření misí jednoduchých a opakujících se. Cíl této práce je prozkoumat odlišný přístup k tomuto problému, a to systém generující vedlejší mise z ručně vytvořených stavebních bloků. Tato práce obsahuje abstraktní popis systému spolu s konkrétní implementací, včetně metod použitých k evaluaci dané implementace. Systém byl evaluován na skupině hráčů, která generované mise hodnotila podobně jako ty ručně vytvořené. Klíčová slova: vedlejší mise, videohra, RPG, virtuální vypravěčství

5 Title: Generating Side Quests for RPG Games From Hand-Crafted Building Blocks Author: Tomáš Hromada Department: Department of Software and Computer Science Education Supervisor of the bachelor thesis: Mgr. Martin Černý, Department of Software and Computer Science Education Abstract: Role-playing games (RPG) often contain side quests - shorter quests not related to the main story, to give the player the feeling of freedom and to let him choose his own path. For this effect to be good, there must be a large number of side quests in the game. Replacing hand-made quests with generated ones is one of the possibilities to make this task easier, however contemporary attempts at generating quests result in the quests being simple and repetitive. This thesis aims to explore a different approach to the problem, a system generating side quests from a set of hand-crafted building blocks. An abstract design and an implementation are described, along with the methods used for evaluating the implementation. The system was evaluated on a group of players, which rated the generated quests similarly to the hand-picked ones. Keywords: side quest, video game, RPG, virtual storytelling

6 Contents Introduction 1 1 Gaming Background RPGs principles and background Different types of RPGs The Quests in RPGs 4 2 Literature Review Video Games and Interactive Storytelling Character Driven Storytelling Story Driven Storytelling Combined Approaches and Existing Projects Quest-Generating Attempts 7 3 Design of the Side Quest Generating System Building Blocks Block Combination Side Quest Generation 9 4 Implementation of the Side Quest Generating System Unity as the RPG World Engine Scene Setup and Hierarchy Building Blocks Implementation Character AI Side Quest Generation and Lifecycle Character Text Loading RPG Mechanics and Game World Assets 17 5 Evaluation and Results Number of Blocks and Possible Quests On Creating the Building Blocks Evaluation Hypothesis Methods Results 21

7 5.6 Discussion 25 Conclusion 28 Bibliography 29 List of Tables 32 List of Figures 33 Appendix A: Contents of the CD 34

8 Introduction Videogames as a media are rising in significance every day. As one of the main source of home entertainment, they take parts in common peoples lives, and are not only limited to the young. We all have something we like or find satisfying, and correspondingly there is a large number of games, fulfilling various personal needs. This thesis focuses on games with characters, stories and player s freedom, and in such games, there are all kinds of motivation behind the objectives. One of the popular motivations is the need to complete a task and receive a reward, because it forms a clear path to player s sense of fulfillment. Such task, or a sequence of such tasks, is usually referred to as quest. They can have various forms and importance in the game, from forming a fun supplement to being the main objective of the game. Games can utilize quests heavily in order to provide a high level of freedom, for example by giving the player an option to choose his own path through the game. One of the ways of achieving this is to have a main story line linked with a linear sequence of quests, accompanied by a possibility to complete some optional quests, not related to the main story, giving the player a chance to train his skills or earn more rewards. These optional quests are called side quests. Creating side quests manually yields the best results, however it can be timeconsuming for the designers. Another option is to generate side quests, for example by using templates or by utilizing solutions from the theory of virtual storytelling. Templates are predefined set of actions into which the designer or the game engine inserts different characters or locations, and while they are easy to use, side quests generated this way tend to be repetitive. An example of game using such system is Star Wars: The Old Republic [1]. Virtual storytelling on the other hand gives us more promising outcomes in exchange for complex implementations and less designer control. The goal of this thesis is to search for a middle ground, aiming at maintaining the design control of the template approach while making the expressive power of the system larger. The rest of the thesis is organized as follows. Chapter 1: Gaming Background describes role-playing games, their mechanics, types and quests. 1

9 Chapter 2: Literature Review describes the state-of-the-art approaches and projects. Chapter 3: Design of the Side Quest Generating System describes an abstract part of my system for side quest generating, along with the prerequisites for an actual implementation. Chapter 4: Implementation of the Side Quest Generating System describes how the side quest generating system was implemented, with its parameters and attributes. Chapter 5: Evaluation and Results describes the hypothesis and the methods of the evaluation, and also discusses the results. 2

10 1 Gaming Background Role-Playing Games (RPGs) are one of the most popular types of videogames. They are divided into multiple subtypes, depending on the context and the motivation behind the game, thus creating a very broad sense to the meaning of role-play. But all of them also share some common properties that make RPGs what they are. 1.1 RPGs principles and background The term role-play originates in the realm of table-top games, and was popularized by the first commercial RPG Dungeons & Dragons [2]. In these games, players describe their characters actions and decisions, and the Game Master, also called the Dungeon Master, describe the outcome of those actions. Apart from videogames and table-top games, the term is also used to describe a Live Action Role-Playing, which is a form of role-playing where players act out, not only describe, their characters actions. The core principles behind role-playing games are that a certain character in the game represents the player and there is a clear list of actions he needs to complete in order to be rewarded and to progress. It is common for an RPG to utilize obtaining new abilities through experience as a form of progress. Another common feature is interacting with items, such as looting and trading. Almost all role-playing games have some sort of combat in them, with monsters, non-playing characters (NPCs) or other players. There are games that strongly focus on the character and the role-playing element, giving the player multiple choices as to what his character might look like or what his attributes can be, such as Skyrim [3] or Fallout: New Vegas [4], and likewise there are games on the border of what can be recognized as an RPG, for example by giving the player only limited options for progress of his character, such as the stamina and muscle training in Grand Theft Auto: San Andreas [5]. 1.2 Different types of RPGs Some of the subtypes the RPGs are divided into are J-RPG, western RPG, action RPG or simulation RPG. Some of these were formed independently, such as J-RPG originating in Japan and western RPG originating in USA, and while they have a common ancestor, they bear different properties. 3

11 For example, J-RPGs are focused on the narrative, usually presenting the player an existing character to control and to follow its progress, while western RPGs focus more on the experience from the game, giving the player the ability to create his own character and choose its own path. Action RPGs centre the experience on the real-time element of the game, giving the player an opportunity to change the course of actions instantly, and simulation RPGs focus more on the tactical skills of the player and the higher level of control. 1.3 The Quests in RPGs There are many different forms actions and quests in RPGs can take. They can be obligatory, forming a linear line for the player to follow on, or it may be up to the player to choose his own path by selecting only a subset of quests he will complete. Note that while side quests are usually found in RPGs, they occur in other genres as well. Far Cry 3 [6], an action-adventure first-person shooter is an example of a game featuring both main quests and side quests yet not being an RPG in its nature. For example, in Assassin s Creed IV: Black Flag [7], the main storyline contains a quest where the objective is to buy a diving bell to dive to the bottom of the ocean to loot treasure. After the quest is done, the possibility to search shipwrecks with a diving bell becomes available as a form of a side quest, but one can continue with the main story quests regardless of the new activity. 4

12 2 Literature Review Related research can be split into five categories: research based around interactive storytelling as a whole, character-driven storytelling, story-driven storytelling, existing projects, and attempts at generating quests. The following sections deal with each of the categories in detail. 2.1 Video Games and Interactive Storytelling Interactive storytelling is a topic tightly related to this thesis, because every quest needs a story, and interactive storytelling can be the instrument to produce them. The core of this concept is the ability of the player to influence the narrative by his actions, and the two main kinds of interactive storytelling are based on who, or what, creates the narrative either the virtual characters in the game, or the story itself. Note that the concept of interactive storytelling is not entirely limited to videogames, although they are arguably the biggest motivation of the topic. 2.2 Character Driven Storytelling In the character-driven subtype of storytelling, the story is not controlled or enforced in any way, but instead is generated by the characters being in the situations and taking actions based on their motivations and subsequent decisions. The possibility to alter the characters decisions by altering the environment or giving them advice was presented [8], with the result of changing the action the character takes, ultimately leading to a change in the ending of the story. An application called FearNot! was created for virtual drama in anti-bullying education [9], with a presentation of an agent architecture. This architecture is based on evaluation and was created to work as a mechanism for generating unscripted narratives. 2.3 Story Driven Storytelling In the story-driven storytelling, the story is seen as a sequence of actions controlled by another entity. When the user makes a difference in the world, either by interaction or the lack of it, the controller takes notice and adjusts the story and its actions, and that ultimately leads to a change of the narrative course. 5

13 One of the methods of implementing the narrative generation is planning, and it is due to multiple factors planning was used as a technology for virtual agents, which eventually evolved into reasoning about virtual actors; it is somehow natural to look at the narrative as a sequence of actions, and actions are ideal for planning; and by using plans, one does keep some key features for user experience, such as the causality between story events [10]. A storytelling system for generating short stories with morals called the Moral Storytelling System (MOSS) was presented [11], focusing on three story elements: action, character and plot and covering each with one functional layer in the system. The output from the system was converted into a text description covering events and characters emotions. 2.4 Combined Approaches and Existing Projects Project exploring how believable agents can be integrated with global story plot in order to build a dramatic world was described [12]. It also presented the smallest units of dramatic value change, so called dramatic beats, from which every dramatic scene can be composed. A framework integrating both story-centric and character-centric storytelling was presented, along with examples of some preliminary examples [13]. It features multiagent system controlling virtual characters in a story and uses partial order planner for generating story paths. Another framework, integrating both story-centric and character-centric storytelling was presented [14], functioning as a coach and a colleague for the designer, encouraging him to look at the stories from different perspectives, suggesting ideas and critiquing the author s ideas. One of the most notable examples of existing interactive storytelling systems is Façade, which is a first-person, real-time, one-act interactive drama [15]. Façade can be categorized both under character-driven and story-driven storytelling, and it is a game based on social interactions. The story progresses through dialogues, with different paths taken based on the affinities between characters, and the player can interact in a way of discourse acts, such as praise, criticism or provocation, and as a reaction, the relations between characters change, thus changing the story. 6

14 2.5 Quest-Generating Attempts A quest classification and design framework was described and created by Jens van de Water by doing extensive research, extracting the core components the quests from existing games have, formalizing a basic framework for designing quests and then describing the ideal uses for the quests his system creates [16]. He indicated that because of the dynamics used in the contemporary games, it would be nearly impossible to use non-dynamic quests, and thus was necessary to generate these quests during the game. Another approach at generating quests is to analyse a large number of quests from existing games, define their structure and shared properties, classify them, and based on this classification create a quest generator. This approach might work, however it requires a large database of quests and their classification [17]. 7

15 3 Design of the Side Quest Generating System There are different requirements that a system with the ability to generate side quests may fulfil. It is common for side quests in RPG games to be fairly short, usually consisting of 2 to 10 actions, and it would be helpful if the system could produce the quests regardless of the number of actions they have. The system should generate large number of different quests, not limiting the designer by their number. As a comparison, there are around 120 side quests in Dragon Age: Origins [18]. Another requirement is for the system to not be fixed on a specified theme, but instead be usable in different scenarios and game themes, such as medieval fantasy or modern space shooter. Last but not least, the system should be easy-to-use and not overburden the designer with complicated algorithms. All of these requirements were taken into consideration when the system for side quest generating was created. The core idea of the system is to pick a subset of all building blocks and link them to form the side quest. 3.1 Building Blocks A building block is a manually created object, representing one or more actions that can happen in the game world. Each block can have various attributes, describing it in the game world. The attributes also bear another purpose they can influence execution of other blocks in the quest. Without similar mechanism, it would be much harder to make different blocks connect to each other. Figure 1: Example of a building block An example of a concrete building block is given in Figure 1. In this block, the player gets an assignment to go to a forest, look for mushrooms on the ground, pick them up and do something with them. 8

16 The designer decides what kind of attributes his building block implementation should have, and the listed attributes are an example of them. This system property addresses the requirement for the system to not be fixed on one game topic. 3.2 Block Combination The blocks are linked together using a successor relation, forming a Directed Acyclic Graph (DAG) with the blocks as vertices. An example of such graph with defined building blocks can be seen in Figure 2. Blocks that are not successors are called start blocks, and blocks with no successors are called end blocks. prepare an omele5e find mushrooms in a forest prepare a riso5o talk with a chef collect onions in a garden add the ingredient to a soup block and cook it deliver an omele5e to a customer Figure 2: DAG of an example set of building blocks, with start blocks (purple) and end blocks (red) Although the system contains a successor relation between the building blocks, it is up to the designer to define the specific relations between blocks. This can be seen in the example set in Figure 2; while there are two blocks that result in picking up an ingredient (mushrooms and onions), only mushrooms are a good fit for an omelette. The combinations of the blocks and their relations are heavily affected by the designer s taste and preferences. 3.3 Side Quest Generation After the DAG of the building blocks is defined, the actual generation of the quests is a simple matter; in fact, it can be done automatically, without any further action from the designer. Every path from a start block to an end block in the DAG forms a potential quest. We randomly pick one of the start blocks and continue the process, randomly picking an edge outgoing from the processed block and using the endpoint block of the edge as a new source for edges, until we reach an end block. The use of 9

17 a successor relation between blocks means that the system can produce quests of different length assuming the blocks are prepared accordingly. Note that while the block picking process performs well, the different quests that the system is capable of producing have different probability of being picked, because not all of the blocks have the same number of ingoing and outgoing edges. This can be fixed by weighting probability of each block being selected by the number of paths from start to end it is part of. As an example, this is one of the possible quests from the set in Figure 2: Talk with a chef find mushrooms in a forest prepare a risotto. In the first block, the player gets to see the chef and talk with him. The chef tells the player that he needs him to go to the forest to pick up some mushrooms, and to return back after he s done. In the second block of the quest, the player goes to the forest and picks up some mushrooms, after which he returns to the kitchen as was assigned by the chef. In the third block, after the player returns from the forest with the mushrooms, another cook might tell him that the chef wants him to prepare a risotto, using the mushrooms he picked up and some other ingredients from the kitchen. It is clear that the public attributes of blocks come to heavy use in this example the first block in the example quest, talk with a chef, needs to know what the player should do, and for that, it might need the action, object and location attributes of the second block (find, mushrooms and forest), and also a location of the third block (kitchen). Similarly, the third block might need to know who was the assigner of the quest (the chef from the first block) and what was assigned (find mushrooms in a forest). The example shows that the attribute sharing is deeply in the core of the system. 10

18 4 Implementation of the Side Quest Generating System This chapter describes the actual implementation of the system generating the side quests. The system is set into a simple RPG game, and the side quests make the whole gameplay of the game. The game has always one side quest in it, and the side quests are completely unrelated to each other. This chapter starts with the game engine description followed by describing different parts of the system. 4.1 Unity as the RPG World Engine I have chosen Unity [19] as the game engine in which I have implemented the simple RPG game and the side quest generating system. In Unity, the game is based around scenes you can have multiple scenes in a game, with each of these having separate data, objects and scripts. The core class in Unity is called a game object, and it can have multiple components these can have visual properties (for example rendering a terrain texture), be responsible for physical simulation (such as a component responsible for handling collisions), or scripts. Game objects can also act as folders in a scene. There are multiple programming languages which can be used with Unity; all the scripts for the side quest generating system are written in C#. Unity provides native tools for rendering and physics, and these were used through the whole project. However, it is up to the designer to provide all the necessary models, animations, artificial intelligence (AI) system and other parts of the game. 4.2 Scene Setup and Hierarchy The whole game is setup in one scene, and there are only couple of root game objects in it: RunScript, Globals, World, Player, Blocks and PredefinedQuests. Figure 3 shows the hierarchy of the scene in closer detail. The RunScript and Globals game objects are what run the actual side quest generation. The RunScript, which gets executed on game start, is responsible for enabling the QuestInitializer script located inside the Globals, and that holds all the useful data and quest helper components, such as the Output (which is responsible for logging events, such as an item was added to inventory ) and QuestLog (which tells the user what the actual quest status is, for example 2/5 items picked ). 11

19 Scene RunScript Globals World Player Predefined Quests Blocks Quest Ini>alizer Terrain Camera Quest 1 Block 1 Output Environment Quest 2 Block 2 Quest Log Block- related Objects Quest 3... Figure 3: Hiearchy of the scene The World game object contains the game terrain and environmental assets (trees, bushes and others), and also the block-related objects. The Player game object represents the player in the game. It contains multiple camera objects, which are used for visual input and for showing additional controls (such as the arrow pointing to the next quest location), and it also has some additional objects for the AI to recognizer the player. The Predefined Quests game object is a folder containing three game objects, each of these being a separate, predefined quest. Those hand-made predefined quests were created for the evaluation of this thesis. And finally, the Blocks game object, also acting as a folder, contains all of the block parent objects in the project. Each of these objects contains one or more Block scripts and can therefore act as different building block in different quests. 4.3 Building Blocks Implementation The Block is a core class of the building block implementation. However, it is not used directly in my implementation, but is merely an abstract class. There are three different subclasses of the Block class: StartBlock, IntermediateBlock and EndBlock. The attributes used in the Block class and its subclasses are: identifier, a string for identifying the block in the system blocklocation, a string with the location of the block blocksubject, a string describing the character of the block blockobject, a string describing the object the block manipulates with blockscripts, a list of Blocks 12

20 blockobjects, a list of block-related game objects that are part of the game world blockaction, string describing the action of the block (such as loot or kill) hastext, a boolean flag telling the system if the block has dialogue or not playerstartposition, a vector describing the starting position of the player Each Block subclass contains all of the attributes above, with the exception of the blockobject attribute, which is not needed in the EndBlock subclass, because there is no other Block after it which might use it, and playerstartposition, which is needed only in the StartBlock subclass. The StartBlock is the class corresponding to the start block node in the block design. Any side quest generated with the system always starts with this block. The IntermediateBlock is a class representing the middle parts of quests, if they have a length of 3 or more. The EndBlock is the class each generated side quest ends with, thus corresponding with the end block node in the block graph. 4.4 Character AI The artificial intelligence in games makes a large part of the experience, and NPC needs to perform actions, usually move and react to some events in the game world. State of the art for this purpose is a NavMesh [20] and Behaviour Tree [21] combination. A Unity plugin called RAIN [22] was used in the project, as it implements both of these techniques. A behaviour tree is a model of a set of tasks, being represented as a tree, with the nodes being the switches or actions. The behaviour trees in this thesis were used for controlling the NPCs movement, dialogues and actions. Figure 4 shows a part of one of the behaviour trees used in the project. Each line represents one node in the tree, and there are two groups of nodes action nodes, such as timer, which waits for defined time before proceeding, move, which tells an entity to move, or expression, which evaluates an expression based on the NPC memory, and decision nodes, for example the SEL, which selects nodes based on their constraints, CON, which execute if their constraint evaluates to true, PAR, which executes its children nodes in parallel, or SEQ, which executes its children nodes one after another. 13

21 Therefore, the behaviour tree in Figure 4 would first start with the selector node, which would choose one of the constraint nodes. If the first one were chosen, the parallel node would execute the sequencer, the waypointpatrol and the mecparam at the same time, which would in return execute the timer, the expression and the move action. Figure 4: A part of a behaviour tree example 4.5 Side Quest Generation and Lifecycle The process for the quest generation is as follows: The Globals object contains an array of start blocks, and the picking of building blocks is being done in the QuestInitializer script. The generation process does not end with picking the blocks. In my implementation, most of the blocks contain dialogue, used for communicating with the player. The dialogue gets loaded into the blocks at runtime, and then each block activates its related objects (stored in the blockobjects attribute), which are needed for the proper function of the block. This is an optional step, and each block handles this internally. Also, the block is reset to a valid initial state, for the case it gets picked for a second time this is solely a matter of implementation. Figure 5 describes the lifecycle of the side quest. The process starts with RunScript enabling QuestInitializer, after which the QuestInitializer assembles the quest. The side quest starts right after it. A start of the quest is registered in the QuestInitializer, and after the side quest gets to the end state, the QuestInitializer stops the quest, activates the RunScript and deactivates itself, thus finishing the play session. 14

22 Figure 5: Quest lifecycle 4.6 Character Text Loading The dialogue for the blocks subjects is loaded dynamically for a couple of reasons: there can be different Block scripts assigned to the same NPCs, thus it would not be possible to set the text directly to the subjects behaviour tree, and the blocks need to access and use other blocks attributes in text. Because the XML format used in RAIN AI s behaviour trees was not very user friendly, a custom format was set up for the purpose of text storing, as it was easier to write the characters dialogues in it. The custom XML format was then transformed to the RAIN AI behaviour tree XML format using a XSLT transformation script. The custom XML format also contains placeholders representing references to other blocks variables, so that they can be referred to in the characters texts, such as $SB_OBJECT$ (the object of StartBlock) or $IB_ACTION$ (the action of IntermediateBlock). They get replaced in the last part of the text loading process. Due to time constraints, this system was concretized on the actual block implementation, only enabling quests of two or three blocks, but it is possible to make more blocks per quest possible, for example by referencing a previous, current and next blocks in the quest. 15

23 4.7 RPG Mechanics and Game World In order for the game to work properly, the role-playing game mechanics needed to be implemented in the system. These include dialogues, picking up items, inventory system, NPC movement, combat, and others. Additionally, a game world was designed for the whole game. The dialogues appear when the player is close enough to the NPC, and this mechanism was implemented using proximity triggers. Each NPC stores its dialogue state, so it is possible to leave the dialogue and return to it later. An example of how text dialogue looks in game can be seen in Figure 6. Figure 6: In-game dialogue Picking up items was implemented similarly to the dialogues, with using proximity triggers, and additionally to this, an inventory system was implemented, handling the addition and removal of items from the player, as well as the graphical representation of the inventory accessible in game. The picking up and storing mechanics were used for multiple different actions in the game, such as destroying and burying items and searching for items in plants or trees. The NPC movement was implemented using behaviour trees, and there are multiple different movements implemented and used in the game NPCs follow 16

24 predefined path, they chase the player following him everywhere, or they run away from the player. The combat was also implemented using behavior trees, and it includes movement, multiple player proximity checks, following the player, firing of the magic missile in the direction of player or using magic to avoid getting damage, as well as animating the characters during all of the actions above. The game world was created using Unity terrain editor followed by applying various terrain textures and adding environmental assets, such as the trees or plants, and also artificial ones, such as the cemetery assets. An overview of the game world is shown in Figure 7. Figure 7: Overview of the game world 4.8 Assets The whole project is setup using free-to-use assets, which are compiled together to form the actual project. All of the models, textures or animation assets were taken from third party sources. Additionally, couple of scripts used for player and camera movement were provided directly by Unity. One of the biggest packs of assets used in the project are the Maelstorm Assets [23], and these were provided for the independent game developers free of charge for any use by the Digital Roar Studios. Characters models and various textures were used from this package. Another large pack of assets is the Huge FBX Mocap Library [24], a conversion of Carnegie-Mellon mocap library. A wide range of character animations was taken from this package, and by manually adding rigs to the models from the Maelstorm Assets using Blender [25], the animations were used with the models. 17

25 The cemetery and linked assets are from a Make Your Fantasy Game Lite [26] pack. Various other smaller model and texture packs were used, mainly found in the Asset Catalog provided by Unity. The full list is enclosed on the accompanying CD. 18

26 5 Evaluation and Results This chapter describes the results that were achieved with creating a set of building blocks and also describes the evaluation of the system. The evaluation focused on players enjoyment and understandability, reasoning that those properties are what we would want form a side quest generating system, and a discussion is held on the evaluation results, providing possible explanations for certain properties of the result data. 5.1 Number of Blocks and Possible Quests The actual DAG created for the system of the building blocks has start blocks, end blocks and the rest of blocks as a possible connection between the start and the end blocks, resulting in two kinds of quests start-end quests and start-middle-end quests. Start blocks Middle blocks End blocks Warrior Sandra is asking the player to eliminate something rotten in this world. Mage Henry asks a favour for a better cause. Priest Peter lost an item. Warrior Sandra gives the player a quest that needs courage. Drunken pirate Josh needs help. Worker Paul has a confession to make. Dark mage Aaron is searching for help. Priest Peter has bad news. Four skeletons make a surprise attack. Dead John is behind mountain with a sapphire. Thief Kate stole topaz. Gold ingot can be found on the beach. Diamonds are hidden in the maple trees. Skeleton is walking behind a magic barrier. There is a logic quest in the cemetery. Enemy magician is on the red sand. A quiz is being held near the beach. Warrior Sandra sells items on a black market. Worker Paul gets saved. Priest Peter refuses to accept items. Dark mage Aaron summons enemy skeletons. Hostile skeleton attacks. Priest Peter sends the player to meditate on top of a mountain. Dark mage Aaron sends the player to destroy items. Mage Henry sends the player to bury a book. Player sacrifices items in a tomb. Table 1: List of all building blocks The total number of building blocks implemented in the system is 25: nine start blocks; eight middle blocks; and nine end blocks. The list of blocks can be seen in Table 1. The average number of outgoing connections is 4 and the number of 19

27 different quests generated using the side quest generation system is 187, and this is also the most basic evaluation of the system to generate a lot of quests from a relatively small number of blocks. The number of valid block combinations is for the start-middle-end quest format and 9 9 for the start-end quest format, making 729 possible combinations in total. That means that approximately 25.7% of all valid block combinations can be generated using the system. Moreover, those 187 quests were generated using 25 blocks, and with one block being a half or a third of a quest, it means that it was possible to get 187 quests for the work of 10, at least in terms of graphical assets and their content. One has to account the additional work that the system requires: making the blocks abstract enough and figuring out their relations, but nevertheless the difference is large. 5.2 On Creating the Building Blocks The hardest part of creating the actual set of building blocks was to figure out the stories for the blocks and their level of abstraction. If the blocks were too concrete, they would have been hard to combine to form the quest, only giving a few possible quest combinations, but if they were too abstract, they would not be interesting for the players anymore. The solution to this problem was to concretize the characters and their story, but keep them simple enough to be easily combined together. After the stories were prepared, the actual implementation of the blocks was simple, as the system is easy to use, and the results were promising. The designer must expect, however, to spend time on testing the building blocks and their relations, as what may appear valid on the paper does not always work in the game. 5.3 Evaluation Hypothesis The main goal of the testing was to show the relation between side-quests generated using the system and hand-picked side-quests. We emphasised on comparing the players enjoyment from playing the side quests, and the level of their understanding if they knew what to do and understood the mission. We hypothesised that the generated quests are similarly enjoyable and understandable for the players as the hand-picked ones. 20

28 5.4 Methods The evaluation was made on students who played multiple side quests, and the session was held during a standard two-hour school lesson in an early afternoon. Each of the students was asked to fill an initial questionnaire, asking about their age, sex and information about their gaming experience. After this questionnaire, the students were asked to play a sequence of 8 quests and to fill a questionnaire asking about their feeling from the game after finishing each of them. From the 8 quests, 5 were generated using the side-quest generating system and 3 were hand-picked. The hand-picked quests were the same for all the participants, however the generated differed and also the order of the quests was randomized. The questionnaire presented after each quest consisted of three to four statements on which the participants expressed their opinions through picking an option from a 5-point Likert scale (strongly agree, partly agree, not agree nor disagree, partly disagree, strongly disagree). The statements were I like this quest, The story was clear, I knew what to do all the time during this mission and This mission was similar to another one I ve already played, with the fourth statement not being presented after the first quest. Along with those statements, two additional questions were posted asking about the players preferences in the quest what they did and did not like in the quest, with options being Story, Characters, Things they did and Nothing, with the option of not picking an answer and specifying something else with text input. 5.5 Results 24 students aged participated in the testing, and from these students, 3 refused to fill the questionnaires or to play at all. Full results of those 21 participants are enclosed in the evaluation.xslx file on the accompanying CD. From the 21 participants, 7 were female and 14 were male, and the majority of participants were 16 years old. The distribution among sex and age can be seen in Figure 5. 21

29 Figure 8: Age and sex distribution between participants male female The results of the first part of the questionnaire can be seen in Figure 9 and Table 2. Based on the results for the statement I like this quest, it can be observed that hand-picked quests were given better score overall than the generated ones, with the generated having the answers more evenly distributed between all of the options. The statements This story was clear and I knew what to do all the time during this mission performed similarly between hand-picked and generated quests, showing that the understanding of the quest and mission was similar both for handpicked and generated quests. The statement This mission was similar to another one I ve already played gained around 57% positive answers for hand-picked quests and 65% positive answers for generated ones. This shows that more than half of all quests was similar to a different one the participant played, with generated ones having a slightly higher number. Hand- Picked Generated Hand- Picked Generated Hand- Picked Generated Hand- Picked Generated I like this quest The story was clear I knew what to do all the >me during this mission This mission was similar to another one I've already played 40% 20% 0% 20% 40% 60% 80% 100% Strongly disagree Partly disagree Not agree nor disagree Partly agree Strongly agree Figure 9: Statement results 22

30 Strongly disagree Partly disagree Not agree nor disagree Partly agree Strongly agree I like this quest (HP) 1.61% 8.06% 9.68% 25.81% 54.84% I like this quest (G) 3.85% 13.46% 12.50% 30.77% 39.42% The story was clear (HP) 3.23% 3.23% 9.68% 20.97% 62.90% The story was clear (G) 4.85% 4.85% 7.77% 24.27% 58.25% I know what to do all the time during this mission (HP) I know what to do all the time during this mission (G) 3.33% 10.00% 5.00% 26.67% 55.00% 5.94% 6.93% 9.90% 30.69% 46.53% This mission was similar to another one I've already played (HP) This mission was similar to another one I've already played (G) 9.26% 12.96% 20.37% 20.37% 37.04% 10.23% 17.05% 7.95% 39.77% 25.00% Table 2: Statement results (G: Generated, HP: Hand-Picked quests) A distribution of answers for I like this quest compared to the order in which the quests were played can be seen in Figure 10 and Table 3. Based on the results, it can be said that the participants responses were affected by the order in the quest sequence, and it seems that the more quests the players played, the more they enjoyed them Strongly disagree Partly disagree Not agree nor disagree Partly agree Strongly agree 0 1st quest 2nd quest 3rd quest 4th quest 5th quest 6th quest 7th quest 8th quest Figure 10: Answer distribution for the "I like this quest" statement after each quest in order 1st 2nd 3rd 4th 5th 6th 7th 8th Strongly disagree Partly disagree Not agree nor disagree Partly agree Strongly agree Table 3: Answer distribution for the "I like this quest" statement after each quest in order 23

31 Figure 11 and Table 4 show the distribution of what the respondents liked and disliked, compared between generated and hand-picked quests. As can be seen in the results, the Story was the most liked category, and most of the participants chose to not specify anything they did not like about the quests. For the hand-picked quests, the Things they did option got higher percent of votes than the Characters, while for the generated quests it was the other way around. 60% 40% 20% 0% 20% 40% Hand- Picked Like Generated Like Hand- Picked Dislike Generated Dislike 60% Undefined Story Characters Things they did Nothing Something else Figure 11: Distribution of likes and dislikes between hand-picked and generated quests Hand-Picked Generated Like Dislike Like Dislike Undefined 1.59% 11.11% 4.76% 13.33% Story 38.10% 7.94% 32.38% 11.43% Characters 15.87% 12.70% 24.76% 11.43% Things they did 23.81% 12.70% 18.10% 15.24% Nothing 20.63% 53.97% 19.05% 41.90% Something else 0.00% 1.59% 0.95% 6.67% Table 4: Distribution of likes and dislikes between hand-picked and generated quests A distribution of likes and dislikes between girls and boys can be seen in Figure 12 and Table 5. It can be observed that boys and girls did not have the same opinions. In general, the male part of the participants was more demanding while the female part ranked the quests more positively. The category where girls were the most negative was Things they did, while the boys ranked all of Story, Characters and Things they did similarly negative. They ranked those categories similarly positive too, while girls focused the most on the Story and Characters, again omitting the 24

32 Things they did. The boys, unlike the girls, also specified what they did not like about the quests through the text field, and these responses can be divided into four cateogires: the quests being too easy, the goal not being interesting enough, a bug in the quest and other responses. Some of the responses were: It wasn t very interesting, The skeleton died after first shot or repeating. 60% 40% 20% 0% 20% 40% Girls Like Boys Like Girls Dislike Boys Dislike 60% Undefined Story Characters Things they did Nothing Something else Figure 12: Distribution of likes and dislikes between sex Girls Boys Like Dislike Like Dislike Undefined 1.79% 26.79% 4.46% 5.36% Story 51.79% 3.57% 25.89% 13.39% Characters 17.86% 1.79% 23.21% 16.96% Things they did 7.14% 14.29% 26.79% 14.29% Nothing 21.43% 51.79% 18.75% 43.75% Something else 0.00% 1.79% 0.89% 6.25% Table 5: Distribution of likes and dislikes between sex 5.6 Discussion Based on the answers of the I like this quest statement in Figure 9 and Table 2, it can be said that the generated quests were close to the hand-picked ones in the evaluation, but the results imply that there is still room for improvements of the system in terms of enjoyment of the quests. The quests goals were clear and understandable, as can be deducted from the results, and while both generated and hand-picked performed similarly for those 25

33 statements, the actual values can be most likely attributed to the implementation of the system, being the limiting factor for these results. The quests were fairly similar to each other, based on the answers, and the most probable cause for this result is the fact that both generated and hand-picked quests were created using the same limited set of blocks, as while the quests as a whole were different, they shared the same blocks, causing the quests to appear similar. Therefore it can be said that these results do not describe the attributes of the system itself and its usability, but more the actual implemenetation of the quests for evaluation, mainly the implementation of the hand-picked quests. The results of the different answers for the I like this quest statement compared to the order may appear surprising, as the answers got more positive more the participants played the quests. If the results would be decreasing instead, it could have been attributed to the fact that the participants were getting bored by playing the game, enjoying it the less they played. However, with those results, it appear that the more the players played the quests, the more they enjoyed them. One of the reasons for this trend might be the fact that some participants played a similar game for the first time, and so the more they palyed, the more they knew how to play it, resulting in a better overall enjoyment from the quest. This means that for a game which the players would play for some time, the generated quests may be still enjoyable and amusing even after multiple iterations. The story being the most liked option from the distributions seen in Figure 11 and Table 4 can be attributed to multiple factors. The fact that the story ranked better than the characters, for instance, is probably because the story elements of the blocks were well thought out, and the characters were not the main focus of the building blocks design. Another reason may be the fact that the story was probably ranked mainly based on the dialogues, while the characters on their appearance, which did not have the same level of quality as the state-of-the-art games have. The story ranking higher than the mechanics and things the participants did in the game is again because the mechanics were not the main part of the side quest generating system, acting more like a supplement to the whole experience, and while there were many different actions the players could do, all of them were quite simple. The characters ranking better than the things the participants did for generated quests and the other way around for the hand-picked quests may be due to the fact 26

34 that generated quests did not have as good mechanics as the the hand-picked ones, but on the other hand they offered wider range of characters to see in the game. When comparing the number of hours played from the entry questionnaire to the sex of participants, the majority of girls said they do not play at all while the majority of boys filled that they play at least 5 hours each week. Therefore, the values for gamers and non-gamers are very similar to the values of boys and girls. Girl participants preferred the story and omitted the things they did, as can be seen in Figure 12 and Table 5, possibly because they do not play games, and therefore they concentrated more on the abstract parts of the quests and not the concerete ones. Also, the quests were probably harder for them, as they did not have as much experience as boys did with the controls and mechanics, and found it harder. This reflects in the results of what the girls did not like too. On the other hand, boys ranked likes across all the parts of the quests evenly, maybe because they had experience with similar games and were able to compare them. Similarly, they disliked all the categories, and not just one as the girls did. One of the factors affecting the results might be the fact that the students were asked to play games instead of regular teaching, and therefore they might gave more positive answers than unaffected participants would. Another affection for the evaluation might have been the chosen quests for the evaluation. An evaluation including quests formed randomly from the building blocks could gave more conclusive results, as these quests would create a base line for the results. Another part that could have been improved are the hand-picked quests, as it would be better if another person would create them, to make the comparison between generated and hand-picked quests more objective. This was not done due to time constraints. 27