Automated Structural Analysis of Interactive Narratives

NORTHEASTERN UNIVERSITY

DOCTORAL THESIS

Author: Supervisor: Elin Carstensdottir Dr. Magy Seif El-Nasr

Committee: Dr. Stacy Marsella Dr. Timothy W. Bickmore Dr. Casper Harteveld Dr. Bryan Loyall (External)

A thesis submitted in fulﬁllment of the requirements for the degree of Doctor of Philosophy

in the

Khoury College of Computer Sciences

iii

Declaration of Authorship

I, Elin Carstensdottir, declare that this thesis titled, “Automated Structural Analysis of Interactive Narratives” and the work presented in it are my own. I conﬁrm that:

• This work was done wholly or mainly while in candidature for a research degree at this University.

• Where any part of this thesis has previously been submitted for a degree or any other qualiﬁcation at this University or any other institution, this has been clearly stated.

• Where I have consulted the published work of others, this is always clearly attributed.

• Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work.

• I have acknowledged all main sources of help.

• Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself.

NORTHEASTERN UNIVERSITY

Abstract

Khoury College of Computer Sciences

Doctor of Philosophy

Automated Structural Analysis of Interactive Narratives

by Elin Carstensdottir

Interactive narrative is becoming increasingly popular for entertainment, such as video games and interactive TV, as well as high impact domains such as education, training and health. Designing complex storytelling experiences is a considerable challenge, even for experts. Iterative design is a common design method used across academia and industry that relies on repeatedly building and testing scenarios, using various formative evaluation methods. These testing methods, however, require human playtesters, making the process both time-consuming and resource demanding. Further, our community has yet to develop a way to communicate, evaluate, and compare interactive narratives. In this dissertation, I present a new model for describing and communicating interactive narrative design called Progression Model, which captures the narratives structure from a users’ experience perspective. Further, I present a novel model capturing progression and moment-to-moment interaction in a graph-based representation called Progression Maps. Moreover, I present a new automated system, called Design Assistant, that develops a graph-based visualization of progression in interactive narratives. Results from various studies show the success of the use of Progression Maps and the automatically generated Design Assistant graphs. Specif- ically, the results show that the models and graphs are suitable for novice designers to communicate about their designs; they are easy to understand and suitable for qualitative and quantitative analysis of interactive narrative design.

vii

Acknowledgements

Completing a PhD is a massive undertaking and possibly one of the hardest, most rewarding challenges I have ever faced. I have been incredibly fortunate to have the wholehearted support of my amazing mentors, colleagues, friends, and staff at Northeastern, and having had the love and support of my friends and family who were there for all of it. I’d like to start by thanking my advisor and mentor Dr. Magy Seif El-Nasr for all of her support, guidance, inspiration, and encouragement throughout my PhD journey at Northeastern. Thank you for inspiring me to go out of my comfort zone, wholeheartedly supporting my need to be self-directed in my work, and encouraging me to follow and trust my instincts as a researcher and educator. A big thank you to Dr. Stacy Marsella for all of the encouragement, support and guidance you have given me through the years, as an intern at USC ICT, at Northeastern and as a part of my thesis committee. Thank you Dr. Casper Harteveld for all of the support and collaboration in relation to StudyCrafter and feedback during the development of the work presented in this thesis, Dr. Timothy Bickmore for asking the right questions and making my work better, and Dr. Bryan Loyall whose suggestions and questions have inspired and encouraged me to look further and wider. I got the best possible introduction to research through working with Dr. Hannes Högni Vilhjálmsson at Reykjavik University during my undergraduate studies. Thank you for introducing me to the exciting world of computational media and games research, and for your encouragement and patient support through the years. I have been very fortunate in having been around many incredible current and former faculty and post-docs at Northeastern who have helped me improve my work and supported me in one way or another during my time there. The list is long but I wanted to especially thank Dr. Truong-Huy D. Nguyen, Dr. Gillian Smith, Dr. Seth Cooper, Dr. Alessandro Canossa, Dr. Celia Pearce, and Susan Gold. A massive thank you to Meg Barry and Sarah Gale, who were invaluable and always helpful, and an equally massive thank you to Jane Kokernak for her help with editing this thesis and helping me become a better writer. Thank you to my colleagues in the Computational Media department at UC Santa Cruz who have been incredibly welcoming and supportive as I wrapped up this thesis. To all of my friends in the Playable Innovative Technologies Lab at Northeastern, past and present, you have been an amazing bunch of people to share this journey with. I have been very fortunate to have gotten to experience this with you all. There are so many of you so I apologize if I forgot to include your name here. First, thank you Britton Horn for your friendship, humor and wit, for teaching me how to be sufficiently polite for Texas, and patiently explaining all things America to me. I cannot imagine a better friend and cubicle partner for this crazy time. Thank you So- phie Spatharioti for helping me keep sane, for encouraging my never ending quest viii for quality puns, displaying proper disappointment in sub-par pun quality, and for being an incredible friend. Thank you Erica Kleinman for being a fantastic collab- orator, for the numerous conversations about the contents of this dissertation, your friendship, and quality entertainment material recommendations. Thank you Dan Feng for all of our collaboration and fun conversations through the years. Thank you Nathan Partlan for all of the thoughtful feedback, collaboration, and support you provided in the last stages of finishing this dissertation. Thank you Anurag Sarkar for being a good friend and never failing to cheer me up and make me laugh. Thank you Chaima Jemmali, Sara Bunian, Abdelraman Madkour, Josh Miller, Sabbir Ahmad and the entirety of the GUII lab for many years of fun, inspiration, support, conference shenanigans, and laughter. I have been blessed with amazing friends who provided many distractions, conversations, and support, and without whom this work would not have been possible. In particular, thank you Ting Huang for being the world’s greatest roommate and an incredible friend. Thank you Sarah, Leni, and Susan for your unwavering friendship, generosity, kindness, and endlessly inspiring fabulousness in all things. Thank you Nada Nadji for keeping me laughing, for keeping me silly, and for drag- ging me outside into the world to have fun and eat good food. Thank you Eva Sigurbjörg, Birna Rún, and Angela Nazarian for being incredible and true friends despite the distance and the time apart, and for always being there. I want to thank all of my amazing family who have always supported and helped me regardless of what I chose to do, and finally, but most importantly, I want to thank my wonderful parents and sister for all of their love and kindness, for their understanding and humor, for giving me strength, and being unrelentingly supportive in every conceivable way. This dissertation is for you. ix

Contents

Declaration of Authorship iii

Abstractv

Acknowledgements vii

1 Introduction1 1.1 Building Player-Centric Interactive Narrative...... 3 1.1.1 Lack of a Common Lexicon...... 4 1.1.2 Interactive Narrative Design Abstraction...... 4 Design Example: Papers Please...... 5 Design Example: The Wolf Among Us...... 6 1.1.3 Narrative Progression...... 8 1.1.4 Challenges in Interactive Narrative Design...... 9 1.1.5 Design Methods and Authoring for Interactive Narrative.... 10 Challenges posed by Formative Evaluation Techniques..... 11 Authoring Challenges...... 12 1.2 Automating Design Support and Analysis for Interactive Narrative.. 14 1.2.1 Automated Design Support in Digital Games...... 14 1.2.2 Narrative Generation...... 15 1.2.3 Visualization and Automated Playtesting of Digital Games... 15 1.3 Thesis Statement and Research Questions...... 16 1.3.1 Contribution Statement...... 18 1.4 Chapter Overview...... 20

2 Tools and Models for Interactive Narrative 23 2.1 Models of Interactive Narrative Structure...... 24 2.1.1 Graph Based Models...... 26 2.2 Interactive Narrative Design...... 27 2.2.1 Interactive Narrative Design Tools...... 30 2.3 Structural Analysis and Player Experience...... 30 2.3.1 Modeling and Analyzing Game Design...... 32 2.4 Summary and Discussion...... 34 x

3 The Progression Model 37 3.0.1 Lack of a Common Ground Vocabulary...... 38 3.0.2 Progression...... 39 3.1 Building the Model...... 40 3.1.1 Game Selection Criteria and Description of Analysis Set.... 40 3.1.2 Methodology...... 42 3.1.3 Interlude: Diegesis and Interaction Design in Interactive Nar- ratives...... 43 3.2 A Descriptive Model for Narrative Progression...... 44 3.2.1 Overview...... 44 3.2.2 Structure...... 44 3.2.3 Interlude: Structure Modularity...... 48 3.2.4 Progression Mechanics...... 48 Progression Mechanic Types...... 48 Goal Directed Mechanics...... 52 3.2.5 Interlude: Patterns of Structure and Progression Mechanics.. 53 3.2.6 Interlude: Perception of Structure...... 55 3.2.7 Interaction...... 57 Input...... 57 Input Mapping...... 57 Feedback...... 58 3.2.8 Presentation...... 58 Delivery...... 58 Framing...... 59 3.2.9 Action Set...... 60 3.3 Discussion...... 60

4 Progression Maps 63 4.0.1 Graph-based Representation...... 63 4.0.2 Elements of Interaction and Interactive Narrative Design.... 64 4.1 Model Deﬁnition and Design...... 66 4.1.1 Interaction Units...... 66 4.1.2 Hierarchy...... 67 4.1.3 Node Types...... 69 Information Presentation...... 71 Player-Facing Interaction...... 75 System-Facing Interaction...... 79 Properties...... 79 4.1.4 An Illustrative Example...... 80

5 Qualitative Evaluation of the Communicative Capabilities of Progression Maps 85 5.1 Perspective...... 85 xi

5.2 Study of Progression Maps Suitability for Design Communication... 87 5.2.1 Methodology...... 87 Narrative Game Selection Criteria...... 87 Participants...... 88 5.2.2 Pilot Study and The Interaction Cartographer’s Manual.... 88 Narrative Game: The Wolf Among Us...... 89 Methodology and Analysis...... 89 5.2.3 Structural Analysis Study...... 91 Narrative Game: Long Live the Queen...... 92 Methodology...... 93 Analysis...... 94 5.2.4 Results...... 94 Map Similarities...... 94 Map Differences...... 96 Perspective and Communicative Function...... 99 Conclusion...... 101 Limitations and Future Work...... 102

6 The Design Assistant 105 6.0.1 Computational Model of Progression Maps Architecture.... 105 6.0.2 Development of the Design Assistant...... 108 6.0.3 Building the Design Assistant Graph...... 109 6.1 Narrative Construction Tool: StudyCrafter...... 111 6.1.1 StudyCrafter’s Authoring Tools...... 112 6.2 Mapping System: StudyCrafter Mapping System...... 113 6.2.1 Development of the Mapping System...... 113 6.2.2 Direct Mappings...... 113 6.2.3 Mapping Complex Nodes...... 115 Dialog Nodes...... 117 Event Nodes...... 117 Automation of Complex Node Mapping...... 118 6.2.4 Interpretation, Ordering, and Presentation in the Mapping Sys- tem Development...... 119 6.3 Design Assistant: StudyCrafter Design Assistant...... 121 6.4 Future Implementation with Other Narrative Construction Tools... 124

7 Evaluating the Implementation of Design Assistant for StudyCrafter 127 7.1 Evaluation...... 127 7.1.1 Focus Group Methodology...... 128 7.1.2 Usability Study Methodology...... 129 7.1.3 Results...... 131 Focus Group...... 131 Usability Study...... 133 xii

7.2 Discussion...... 135 Limitations...... 138 Improvements for the Assistant...... 138 Conclusion...... 138

8 Conclusion 141 8.1 Interactive Narrative Design Abstraction...... 141 8.2 Automated Structural Analysis...... 144 8.3 Contribution...... 146 8.4 Limitations...... 146 8.5 Broader Impact...... 149 8.5.1 Computational Design Analysis...... 149 8.5.2 Playtesting...... 150 8.5.3 Game Development and Production...... 151 8.6 Future Work...... 152 8.7 Closing Words...... 153

A UML Representation - Progression Maps 155

B Illustrative Example - Progression Map 157

C Walkthrough of Long Live The Queen 159

D Recruitment Questionnaire 161

Bibliography 163 xiii

List of Figures

1.1 The immigration booth interface from Papers Please...... 5 1.2 The interface for the player for dealing with daily expenses in Papers Please...... 6 1.3 The dialog interface in The Wolf Among Us...... 7 1.4 An example of a QTE interaction in an action sequence in The Wolf Among Us...... 8 1.5 An example of a simple interactive narrative ﬂow diagram. Each circle represents a choice that the player has to inﬂuence and progress the story. Each choice gives the player two possible options to select from, which then leads to the next choice, and so on. The number of paths that need to be created and accounted for in terms of authoring grow exponentially the more a player is allowed to choose. The red path represents one possible path through the story. Each path needs to be internally consistent and coherent...... 13 1.6 Overview of the work conducted for and presented in this dissertation. 19

3.1 The Progression Model consist of 5 factors: Structure, Progression Me- chanics, Interaction, Presentation, and Action Set...... 45 3.2 Linear Structure...... 46 3.3 Branching Structure...... 46 3.4 Foldback Structure...... 46 3.5 Broom Structure...... 47 3.6 Hidden...... 47 3.7 Opportunistic Structure...... 47 3.8 An example of Progression through Choice through Selection in The Wolf Among Us. The player progresses by selecting a choice from the menu on the screen...... 49 3.9 An example of Progression through Choice through Performance in The Stanley Parable. The player progresses by moving their avatar through one of the doors, effectively making a choice by performing it. 50 xiv

3.10 An example of Progression through Scripted Scenarios in Papers Please. During the scripted event that occurs (an NPC jumping the fence) the player must choose to shoot the NPC or the "man in red". Successfully completing this scripted event (by shooting one of them) is necessary to continue with the game, while choosing to shoot the man in red can result in an immediate ending to the game...... 51 3.11 An example of Progression through Discovery in Her Story. The player must search for keywords in the database and watch the videos that come up as results. Progression is contingent on ﬁnding new keywords in the videos...... 52 3.12 An example of Progression through Resource Management, a type of In-Game System, in Black Closet. The school and council have reputation gauges, and the girls have energy gauges. How full or empty these gauges are will determine what types of choices the player is allowed to make...... 53 3.13 An example of Progression through Task Completion, a type of In- Game System, in Final Fantasy 15. The player must complete a series of updating tasks in a quest chain in order to progress to the next part of the game’s story...... 54 3.14 An example of Progression through Combat, a type of In-Game Sys- tem, in Undertale. The player is able to make a number of choices in the combat menu that will determine the outcome of the battle and inﬂuence the ending of the game...... 55 3.15 An overview of all games in the sample. Each game in the sample was categorized in terms of its structure and narrative progression mechanics respectively. Notable, strong subtypes for Choice and In- Game System mechanics are categorized as well...... 56

4.1 Progression Maps consist of three abstraction levels: Level 1 maps the Interaction Units alone as a graph, a more detailed level 2 breaks those IUs down into more detailed nodes, and the most granular and detailed is level 3, where level 2 nodes are broken down further to capture more detail...... 67 4.2 An example of an Progression Map, automatically constructed from a simple interactive narrative built in StudyCrafter (see Chapter6 for details). The simple scene has a waiter asking the player character what they would like to eat, and showcases each of the second layer nodes. Due to space constraints the picture shown is not in sufﬁcient quality. For a better-quality rendering, see AppendixB...... 81 xv

4.3 A still from the scene as it is presented to a player in StudyCrafter. This is the layout that corresponds to the map shown in 4.2. The player character is the male presenting character in the blue shirt to the left of the scene, sitting down and facing the waiter...... 82

5.1 The portions of each of the three maps that represent selecting the "Ac- counting" class for Elodie to take. Though there are some differences in details, the general patterns and represented elements are similar. It is clear that all three maps are showing the same interaction...... 95 5.2 The portions of each of the three maps that represent process of clicking to progress the dialogue text. Map 3 included additional system interaction not related to advancing the text, while map 2 used a shorthand notation to represent the interaction. Map 1 contained elements of both approaches...... 97

6.1 The Progression Model has 5 conceptual constructs. The Progres- sion Maps are a more concrete representation of 2 of those constructs, speciﬁcally Interaction and Presentation. A Design Assistant Graph is a Progression Map that has been automatically generated with a De- sign Assistant architecture, from a narrative construction tool. In this chapter we will discuss how Design Assistant Graphs were built from StudyCrafter projects...... 106 6.2 The Design Assistant Architecture. The architecture can be adapted to any existing narrative construction tool. Using a tool speciﬁc representation consisting of layout, script, and meta data for a project, it is passed into a mapping system, which formats the tool representation into a MapGraph which contains a graph representation of the tool. Finally, the MapGraph is processed by the Design Assistant in order to generate a Design Assistant graph, an applied Progression Map... 108 6.3 The class diagram for the Design Assistant Representation, built on the Progression maps...... 109 6.4 The algorithm for building the Design Assistant Graphs...... 110 6.5 The Main Project Screen...... 111 6.6 The Layout Editor Screen...... 111 6.7 The Script Editor Screen...... 111 6.8 The Playtesting Screen...... 111 6.9 Examples of the Main Project Screen and the three authoring tools included in StudyCrafter. The StudyCrafter Project depicted here was created by participant U-P3, in the usability study described in Chap- ter7...... 111 xvi

6.10 A lamp screams. In StudyCrafter, a Dialog node can be associated with a layout element and displayed as a speech bubble associated with the element. The StudyCrafter Project shown created by participant U-P3, in the usability study described in Chapter7...... 118 6.11 A partial script graph from the project depicted in 6.7...... 123 6.12 A partial Design Assistant graph from the same project, corresponding to the script graph shown in Figure 6.11...... 123 6.13 An example of a fork, generated from one of the projects described by Partlan et al. (Partlan et al., 2019). The edges out of the fork are annotated with their corresponding condition identiﬁers...... 124

7.1 An example of the numbering scheme that participants agreed was distracting and unclear. In this figure the first two Event nodes are labeled 8 and 9 respectively, followed by three possible Feedback nodes labeled 64, 11, and 55 respectively. The numbering scheme corresponded to the StudyCrafter script graph nodes which did not correspond to the Progression Map layout...... 132 7.2 An example of a fork, generated from one of the projects described by Partlan et al. (Partlan et al., 2019). The edges out of the fork are annotated with their corresponding condition identifiers...... 136

8.1 The Progression Model consist of 5 factors: Structure, Progression Me- chanics, Interaction, Presentation, and Action Set...... 142 8.2 The Progression Map nodes and their relationships...... 143 8.3 Visualizations of a single scene from 3 different StudyCrafter Projects. The Progression Maps show at a glance how the interaction ﬂow of each scene differs in terms of size and complexity...... 144 8.4 The Design Assistant Architecture. The architecture can be adapted to any existing narrative construction tool. A tool-speciﬁc representation consisting of layout, script, and meta data for a project, is passed into a mapping system that formats the tool representation into a Map- Graph, which contains a graph representation of the tool. Finally, the MapGraph is processed by the Design Assistant in order to generate a Design Assistant graph, which is a form of an applied Progression Map...... 145

A.1 An UML representation of Progression Maps, capturing the relationship between the interaction unit, which is the highest abstraction node (level 1) and the set of level 2 nodes it can contain...... 156

B.1...... 158 xvii

List of Tables

4.1 The Progression Map nodes grouped by map level, along with their corresponding properties. A corresponding UML diagram can be found in AppendixA...... 68 4.2 Hierarchy Levels...... 69 4.3 The Progression Map Node Deﬁnitions...... 70 4.4 Node Types and Properties...... 76 4.5 Properties - Deﬁnitions and Example Values...... 80

6.1 The Design Assistant’s Representation: Applied Progression Map nodes as class-like objects, containers, with attributes. Game Objects are graphic, visual elements like the characters (including the player character), objects, environmental features, and interface elements such as buttons. Game State is a representation of the mechanical and narrative state of the game world. The Game State is represented can be represented in various ways, but must at least consist of a pair of Game State IDs to identify which part of the game state is being referenced, with corresponding logic statements that evaluate to a Boolean value. Note: All Options are explicitly presented in the Design Assistant, while this may not be true for other Progression Map representations...... 107 6.2 The mapping from StudyCrafter nodes to the Design Assistant’s representation. When there are sequences of nodes they are represented as "IU.Node + IU.Node + ...". The mapping process is either direct, i.e. it did not require human intervention to map and it was possible to map direct between the MapGraph and the Design Assistant representation, or complex, i.e. required human intervention and interpretation to map due to its functionality or presentation not being fully captured in the MapGraph. Nodes were connected according to the temporal structure provided by the tool representation. The possible properties of each Design Assistant node are described in table 6.1, and are derived on a case by case basis from the meta data from the tool representation...... 114 6.3 The properties for the StudyCrafter Design Assistant...... 122

C.1...... 159

xix

Dedicated to Bryndís, Carsten, and Guðrún. The absolute best.

Chapter 1

Introduction

Stories and storytelling are at the center of human cognition. Throughout the cen- turies, stories have remained one of the primary tools humans have used to preserve and communicate knowledge, disseminate cultural values, and to entertain one another, as evidenced by the large literary contributions of various civilizations across the world and across time. The plays of ancient Greece, the poetry of ancient China, and the sagas of Viking-age Iceland are only a few examples from this rich corpus of stories and methods of storytelling humanity has collectively accumulated. The importance and lasting power of ancient folklore and stories is evident in their continued power to inspire audiences well into the present day. Traditionally, storytelling mediums such as books have been preserved as non-interactive, largely static objects, outside the dynamic interactive spaces of theatre and oral storytelling, where human actors and narrators can adapt the narrative to please the audience. Computation brought with it increased opportunities to further interactive storytelling experiences and allow the audience to choose for themselves in real time, without outside intervention, what elements of the narrative they do and do not want to explore. This makes interactive narratives, such as those found in video games, distinct from other forms of storytelling media as they rely on and require player interaction to be experienced properly (Aylett and Louchart, 2003). Early and formative digital applications such as Multi-User Dungeons (MUDS) (Bartle, 2004) and parser based interactive fiction like Zork (Infocom, 1977) compelled players to explore the stories and world building they contained, and their effects and design lessons are still felt in modern day interactive narrative experiences and games. At the time of writing, interactive narratives in games have evolved to offer a great variety of different types of interactive storytelling, from character-driven experiences such as in The Wolf Among Us (Telltale Games, 2013), to the complex, highly branching, and mechanically afforded role-playing experiences provided by games like the Witcher 3: Wild Hunt (Red, 2015). The aim of this work is to address interactive narrative broadly, but this dissertation will primarily focus on video game narratives, which can be considered a sub-category of interactive narratives. The term ‘interactive narrative,’ when applied to video games, refers to a digital artifact rather than an analog game, other 2 Chapter 1. Introduction types of systems, artifacts, or methods of storytelling. In the context of this dissertation, interactive narrative is understood as the product of merging story and player interaction with an interactive narrative artifact, for example, a video game and its story. More specifically, an interactive narrative requires a player to interpret and narrate a story based on the story content that they consume, in addition to the interaction dynamics that arise from the artifact’s mechanical systems as the player makes choices about the story and experiences unfolding of the narrative events. Video games have a varying degree of emphasis on storytelling, from as little as using narrative only as a basis for abstracted visual representation for gameplay, to prioritizing the story to the degree that interaction and mechanical design becomes minimal. Many critically acclaimed narrative-focused games, such as Papers Please (Pope, 2013), fall on the midpoint of on this spectrum, and often feature designs where the mechanical elements of the games complement or emphasize elements of the story. Providing thematic emphasis through thematically complementary mechanical experience, or emphasizing characterization of a player avatar/character by affording only a particular set of actions or choices for the player to choose from are common design choices in such games. Video game narratives feature several additional facets that impact the overall player interpretation and experience of the story. A storyline with a plot and characters provides context for the player, but mechanics and other in-game systems such as movement controls and the behavior of the enemies provide context as well. These in-game systems also include the interface, spatial layout, audio design, and overall visual design. As such, a player is provided with a large stream of perceptual data that presents the overall context and affordances that impact how the player will interpret and understand the story within the context of their overall game experience. For example, while not a part of the plot, a player might get lost on the way to an objective and interpret this as a challenge that becomes as much a part of the experience and story of the game as the designated plot event. Interactive narrative thus cannot be considered as bound only to an artifact that affords an interaction, rather, it is produced through that interaction and the dynamics it affords. Interactive narrative is in this sense an instance of an experience as narrated by a player, as afforded by an interactive narrative artifact such as a video game. From its origins as an academic discipline, interactive narrative research has grown into its own field with its own conference: ICIDS. The expansion of interactive narrative research in tandem with its popularity as a medium has led to the application of interactive narrative to fields such as education, training and health. Significant examples includes SOLVE (Socially Optimized Learning in Virtual Envi- ronments) (Miller et al., 2011), a health intervention for AIDS prevention; the Immer- sive Naval Officer Training System (INOTS), a role-playing environment for leader- ship and human resource counseling skills (Campbell et al., 2011), and storytelling to assist in cross-generational reflection of physical exercise for families (Saksono and Parker, 2017). Further examples of relevant work include applications for education 1.1. Building Player-Centric Interactive Narrative 3

(e.g. (McQuiggan et al., 2008; Jemmali et al., 2018; Garneli, Giannakos, and Cho- rianopoulos, 2017; Marsh et al., 2011)) and social or personal skills (e.g. (Marsella, Johnson, and LaBore, 2000; Aylett et al., 2005; Si and Marsella, 2014; Yannakakis et al., 2010)). The focus of building these kinds of narrative driven applications for high impact domains like education is often player-centric, i.e. prioritizing the player’s experience and taking into account the player’s goals, capabilities, and progression. This process requires careful consideration of the learning experience and how to create the engagement required to sustain the player’s attention so that the player reaps the beneﬁts implemented within the design. Retention and user experience, and the impact of narrative has been both studied and discussed in previous work (Martey et al., 2017; Rowe et al., 2011; Jemmali et al., 2018). Similar care is required for other high-impact interactive narratives outside of academic circles. There are many games that offer engaging player-centric narrative experiences that blur the lines between education and entertainment. These can range from the widely popular classic The Oregon Trail (Don Rawitsch, 1985), which is set during the US Westward Expansion of 1878, to the commercially successful Assassin’s Creed franchise (e.g. (Ubisoft, 2007; Ubisoft, 2009; Ubisoft, 2014; Ubisoft, 2018)), which recreates historical settings with abundant detail, to the atmo- spheric and critically acclaimed Never Alone (Games, 2014), which acts as a means of both introducing and preserving the art and stories of the Alaskan Inu’piak tribe. Further, interactive narrative experiences that are meant exclusively for entertainment are massively popular and critically acclaimed, and have only been increasing in size, variety, and depth in recent years, as evidenced by the complexity and scope of games like The Witcher 3 (Red, 2015) and Red Dead Redemption 1 and 2 (Rockstar San Diego, 2010; Studios, 2018).

1.1 Building Player-Centric Interactive Narrative

Creating player-centric interactive narratives for applications in high impact domains poses a significant challenge for designers and researchers alike. The artifact needs to be designed in such a way that its design arguably fits within the paradigms and constraints posed by the research goals, questions, and methodology guiding its development. Moreoever, its design needs to be documented so it can be replicated by others for scientific validation, and to serve as the basis for communication during development across stakeholder groups as diverse as programmers, designers, and researchers. Design documentation further helps support reporting of evaluation findings, as it can provide the identification and impact of elements within the design on the player’s experience and performance/behavioral outcomes. 4 Chapter 1. Introduction

1.1.1 Lack of a Common Lexicon

In existing work on integrative narrative and applications utilizing it, design is often left undocumented, or is documented insufficiently, resulting in the inability to replicate the project’s design and experience. Lack of documentation for interactive narrative is, in part, due to the field of interactive narrative research’s relative new- ness; it has not yet settled on a standardized lexicon that can be used to describe common concepts (Koenitz et al., 2010; Koenitz et al., 2011; Szilas et al., 2012). In some cases, terms and concepts are used in passing as though a common definition is understood. However, one or more definitions could be applied to each term, and elements could be understood differently by different researchers from different dis- ciplines, and even among different sub-sets of communities within the broader field of interactive narrative research (Thue and Carstensdottir, 2018). Due to this lack of a common vocabulary, describing and comparing different interactive narrative designs and experiences becomes problematic, as there are no frameworks that currently encapsulate all elements of interactive narrative design. Different definitions of common terms in use within different subsets of the same field will make important differences implicit between existing works in interactive narrative. Thus, forming accurate impressions of terms, approaches, and design is difficult without knowing precisely what construct(s) or concept(s) a given term is meant to convey across two related works (Szilas, Boggini, and Petta, 2011; Szilas et al., 2012). Such confusion diminishes the impact and progress of the field as a whole, hinders collaboration, and the recruitment of new researchers to the field.

1.1.2 Interactive Narrative Design Abstraction

While this disagreement over definitions does cause issues for research and its potential impact, this lack of a common vocabulary has not prevented designers from successfully designing and implementing interactive narrative in games in ways that ensure players understand their role and impact on story progression. Examining critically and commercially successful narrative driven games and their design by grounding the analysis within the player experience can help researchers take the first step toward establishing a vocabulary to not only describe the narrative design, but also to inform further study in the field. The first step is to recognize how designers have successfully created engaging interactive narratives for games. Of particular note is how designers establish design conventions and interaction patterns which serve as effective communication to guide player expectation and indicate the scope of the player’s influence within the narrative. Interaction patterns here refer to sequences of one or more action- feedback loops (player takes a single action and observes the feedback) which are used consistently across contexts to represent the same type of interaction and give a contextually consistent result. This type of communication through design is particularly notable in the context of genre design conventions. Certain game genres have 1.1. Building Player-Centric Interactive Narrative 5 established very particular design patterns, and conventions comprising of those patterns, around their narrative design, narrative progression, and gameplay. As an example, below are a number of prevalent design conventions that aid in story progression in particular. Role-playing games (RPGs) and action games like Final Fantasy 15 (Enix, 2016) and the Assassin’s Creed franchise (e.g. (Ubisoft, 2007; Ubisoft, 2009; Ubisoft, 2014; Ubisoft, 2018)), have specific quest markers on in-game maps and language descriptions that indicate which quests and in-game activities are related to the story progression specifically and which ones are not, and how progressing the story might impact the story world. Visual novels like Long Live the Queen (Hanako Games, 2012), and story-focused games such as The Wolf Among Us (Telltale Games, 2013), Life is Strange (Dontnod Entertainment, 2015), and Oxenfree (Night School Studio, 2016), are framed in terms of the player choice shaping and impacting the story progression. These games establish interaction patterns to ensure that the player understands and can reason about the impact that their choices might have on the story. These two types of story progression patterns can also be combined, as they are in The Witcher 3 (Red, 2015) where choices made during quests and various activities have long and short term consequences on the progression of the story.

FIGURE 1.1: The immigration booth interface from Papers Please.

Design Example: Papers Please

In the aforementioned Papers Please (Pope, 2013) the player is asked to step into the role of an immigration officer in a dystopian, fictional Eastern-European coun- try. The player is presented with an immigration booth interface (fig. 1.1) where 6 Chapter 1. Introduction their only choice is to deny or allow entry to people that attempt to cross the coun- try’s border. This is combined with resource management gameplay where, after each in-game day, the player has to manage resources to keep their in-game family alive and housed (fig. 1.2), before progressing the story to the next day in the booth. These simple and consistent interaction patterns provide the player with clearly established rules for progression and context for their interaction. In the context of the story experience, interaction patterns relating to resource management, which require consideration of long term strategies, are juxtaposed by sequences of small choices. In these seemingly isolated instances, the player only has a binary choice of either approval or dismissal. These small choices made within the confines of the immigration booth have long term consequences, most prominently related to the amount or resources available at the end of the in-game day, impacting progression. This requires the player to engage with the ethical questions surrounding their position as an immigration officer. Faced with various ethical dilemmas within the confines of the booth, from the seemingly simple and humane, like re- uniting lovers and family members by looking the other way, to larger choices, like deciding on whether or not they will participate in either supporting the authoritar- ian state in which they live, or risking their in-game family by joining the rebellion fighting against it.

FIGURE 1.2: The interface for the player for dealing with daily expenses in Papers Please.

Design Example: The Wolf Among Us

In the aforementioned The Wolf Among Us (Telltale Games, 2013) the player is asked to step into the role of Bigby Wolf, the big bad wolf from fables like Little Red Riding Hood and the Three Little Pigs, who is now a sheriff and chief law enforcement 1.1. Building Player-Centric Interactive Narrative 7 ofﬁcer to a community of fable characters living clandestinely in New York City during the 1980s.

FIGURE 1.3: The dialog interface in The Wolf Among Us.

After starting the game the player is presented with a screen that states that the game will adapt to the choices the player makes and be tailored to the way they play. This device frames each choice as having an impact on the story. The player is then shown a short cut-scene where Bigby enters into a conversation with another character and is presented with a choice menu (ﬁg. 1.3). The player is presented with a visual count-down timer during which they can choose from 4 dialog options, explicitly presented as part of the menu, and the option to stay silent, which is activated by not selecting a dialog option within the time limit. These dialog options can also contain actions, which are presented differently from spoken options by framing the text with brackets. This is the interaction pattern used for conversations with characters. Upon selecting a dialog option, the player will see Bigby enact this option and then see the other character’s response. Occasionally the game will display a message that states the character will remember Bigby’s reaction, which is presented as being a part of the game system, rather than the story world. This is presented a neutral system statement, indicating that there has been an update in the character’s memory or state which will impact future interactions the player has with that same character. This dialog selection interaction pattern is the primary method of story progression for the player. There are additional interaction patterns in The Wolf Among Us which also progress the plot: non-dialog choice patterns and action sequences. Non-dialog choices are not timed and are presented differently and clearly differentiated in terms of potential plot impact. These non-dialog choices are presented in a graphically bold style and the player is required to pick between two options before the plot can proceed, demonstrating the signiﬁcance of the choice and reinforcing that the player should 8 Chapter 1. Introduction

FIGURE 1.4: An example of a QTE interaction in an action sequence in The Wolf Among Us. consider their options carefully beforehand. Investigative scenes leading to a plot significant conclusion feature multiple options which can be selected in any order and are scattered through the game world environment. Only some of these options will trigger the conditions for Bigby to reach a conclusion which will move the plot forward. Action sequences are often used to depict fights between Bigby and other characters in the story. These sequences primarily consist of Quick Time Events (QTEs) where the player is prompted to a provide a sequence of inputs, such as pressing a button, in order to progress the scene (fig. 1.4). The events or outcome may vary depending on the player’s performance i.e. which buttons they pressed and their reaction time. If the player’s performance during the QTE is sufficient, the story will progress. In the context of the story experience, the interaction patterns are broadly choices that the player has to make on Bigby’s behalf, and revolve around managing the expectations of other characters and the consequences of Bigby’s choices. The action scenes occur in moments where Bigby, for various reasons, has no option but to use force. This design choice ties thematically with Bigby’s identity as the big bad wolf, which the other characters remain cognizant of throughout the game’s story.

1.1.3 Narrative Progression

When examining interaction design for interactive narrative, player progression is the central focus. Progression can take many forms. In terms of interaction design, it refers to how progression is deﬁned as interaction, how that interaction reveals 1.1. Building Player-Centric Interactive Narrative 9 new story information or new context for existing information, and how such interaction is connected together to make sequences of narrative events. For example, comments on the player’s choices through dialogue delivered by non-playable characters (NPCs) is a progression mechanic if the dialog reveals new information which progresses the plot or otherwise notably advances events. In the previous examples of choice based games such as The Wolf Among Us (Telltale Games, 2013) and Life is Strange (Dontnod Entertainment, 2015), progression occurs as a result of every choice the player is offered, whereas in role-playing games where the story is more abstracted from the overall game experience, such as in Final Fantasy XV (Enix, 2016), what is deﬁned as being story related progression is explicitly marked. Story progression serves various purposes in modern video game design from conventional story progression to indication of a world state change, and can be presented in a variety of ways. However, within the set of interaction patterns established in each game, story progression is always signaled to the player in some way.This is done in order to communicate clearly that the player will not be returning to the previous scenario and is pursuing new content or interaction directly based on or related to the plot of the story as it has been experienced by the player so far. Fur- thermore, progression is often described in alternative ways, through the notion of graph-based structures that represent the ordering and interconnected nature of the story content and the structural manner in which the player is able to navigate through it.

1.1.4 Challenges in Interactive Narrative Design

The examples described thus far have all been of best practices, where designers have successfully established interaction patterns that match the player’s expectations and gameplay experience. More often than not however, such success is challenging to replicate across different interactive narrative experiences and genres, even for experienced designers. Many of the examples previously discussed, such as those relating to story progression design conventions for different genres, have in many cases been established after decades of game development and across multiple games. While arguably successful, this iterative process is resource intensive and has taken decades of dedicated industry efforts to establish. Many of the patterns which have been established however, are not conducive for all interactive narrative experiences, and do not provide a suitable general abstraction through which such patterns can be described. In addition, without a suitable abstraction, it is difficult to discuss interaction patterns without referring to their context within an artifact, which in turn can confuse and confound the description of the pattern. Experienced designer often have difficulty successfully communicating design knowledge and patterns, without resulting to describing individual elements, systems, and mechanics from particular games or artifacts. This method relies on the person with whom the designer is communicating sharing this knowledge and per- fectly understanding the context that is being referred to in order to extrapolate the 10 Chapter 1. Introduction same information to arrive at the same conclusion. This kind of communication is common within the broader community of video games which includes everyone from designers and researchers to players, but poses significant restrictions which are becoming more apparent as the medium matures and the number of games that are available increases exponentially every year. It requires a shared set of references which requires all parties to have played or be familiar with the same set of games to be able to establish the design convention, as well as having similar mental models of the designs, which are formed based on their own individual experiences. If the same type of conversation were to be held about the specifics of other mediums, for example film, the equivalent conversation would require both parties to have seen the same set of films in order to be able to discuss elementary things like different types of cuts, lighting, framing, and audio design. In order to establish a reliable manner to describe and communicate interactive narrative design to create better player-centric interactive narrative applications, we need to establish a suitable abstraction of interactive narrative design, and a model that permits its design to reported on and replicated. For communication, there is an additional consideration: level of required expertise. While a suitable abstraction for interactive narrative design needs to capture the interaction design in as much complexity as possible, it should ideally use a data structure that is intuitive for designers of various skill levels to understand and visualize. It should establish a common language and visuals that are simple enough for novice designers to understand and use, yet powerful enough for varied and detailed design work, such as in-depth interaction pattern design and diagnosing player experience issues. This requirement is also relevant to design communication within the research community, where novice designers with specialized knowledge often participate in development but lack the design intuition more experienced designers have developed, and are often in charge of reporting, leading to important design features and implications being overlooked.

1.1.5 Design Methods and Authoring for Interactive Narrative

Designing complex interactive storytelling experiences is a considerable challenge for experts and novice designers alike. Successful experiences require signiﬁcant design skill, even when the designer is aware of successful design patterns and mechanics as discussed in previous work and previously discussed game examples. In the absence of a generalized design abstraction, designers and researchers have proposed several methods that can help guide designers through the design process. The most notable and widely used of these methods is iterative design (Hunicke, LeBlanc, and Zubek, 2004). Iterative design is a method that relies on a designer repeatedly building and then testing scenarios, using various formative evaluation methods, to improve the scenario (Fullerton, 2018). Many academics and practitioners have emphasized the use of this approach, including Tracy Fullerton in her book 1.1. Building Player-Centric Interactive Narrative 11

Game Design Workshop (Fullerton, 2018) and the authors of the Mechanics, Dy- namics Aesthetics model (Hunicke, LeBlanc, and Zubek, 2004) that has been used and cited by many professional game designers. Formative evaluation techniques used in iterative design include methods such as playtesting, which can be augmented with methods as varied as expert evaluation, heuristic evaluation, data-driven reﬂection, and retrospective think-aloud and player interviews (Isbister and Schaffer, 2008). These methods are not only meant to target standard quality testing, such as looking for errors in either the software or the player experience, but to test new designs and evaluate players’ overall experience and their proximity to the intended effect of the design. Many researchers have proposed such methods for different aspects of game design, including interactive narrative design (Tanenbaum et al., 2010).

Challenges posed by Formative Evaluation Techniques

Formative evaluation techniques are conducted with the expectation that they are be used by the designers as part of a reflective design practice, and that the information they produce is used to improve the design over the course of the next iteration or the span of many iterations. This process currently requires design expertise and skill in interpreting the data provided by the evaluation. The challenge in interpreting the data lies both in interpreting player reactions and responses to different stimuli within the design, as well as accurately attributing these player responses to each of the specific design elements and mechanics within the game. In addition, the challenge of effectively communicating these conclusions to the designers and developers responsible for the respective elements remains, as does helping them figure out solutions to those issues. This process is rife with possible errors, particularly in the case of interactive narrative, which is difficult to differentiate from its presentation and close connections with existing interaction patterns, mechanics, and design affordances. These problems stem largely from the lack of a generalized design abstraction that would allow the designers to reflect on their design, identify potential errors whether through reflection on the design itself or through formative evaluation methods, and then effectively and accurately communicate to others what the problem is and where it lies. Further complicating matters is that these formative testing methods require human playtesters and experts, whose recruitment and employment can be time- consuming and resource demanding. Each iteration requires the developers and designers to run a new set of evaluations, which becomes a challenge as most of these methods require a fresh group of playtesters for each iteration to prevent learning effects and bias. Recruiting new playtesters for every iteration may be cost prohibitive for most developers, especially for novice designers with limited resources or connections. Further, novice designers may need to perform many iterations before achieving a satisfactory experience due to inexperience with both the design process and playtesting. Such heavy dependence of human playtesters thus poses 12 Chapter 1. Introduction a significant challenge for game development, and in particular novice designers seeking to implement and test multiple iterations of their design. In terms of applications for high impact domains, this dependence is similarly concerning as many projects are driven by researchers that are subject matter experts in the domain but lack the video game and interactive narrative design experience, and would be more likely to require more iterations to accomplish their work both due to their lack of design expertise and the inherent complexity and challenge involved in translating a theoretical approach and research goals into a successful interactive experience.

Authoring Challenges

Another set of core challenges for interactive narrative design lie in content authoring, i.e. the writing and creation of the story content and planning of this content so that it remains coherent and engaging throughout the experience. This complex and resource intensive process has been discussed by various researchers (Tanenbaum et al., 2010; Szilas, Marty, and Réty, 2003; Koenitz, 2015; McCoy et al., 2010). The most notable of these content authoring problems, in the context of this dissertation, is the "authoring bottleneck" where the exponential demand for content exceeds the production capabilities of a single human author (Tanenbaum et al., 2010). Consider that a designer needs to provide content for all possible story paths that the player is allowed to explore. This content also includes acknowledgement of the player’s choices, which might not be directly linked to the story path, for example talking to an NPC. Let’s simplify and assume that the designer is making content for a branching narrative, where each action or choice that the player makes advances the plot. This means that each choice creates a number of paths that correspond directly to the number of choices that the player is allowed to make. If the designer gives the player as few as 2 or 3 options each time they make a choice, 2 choices, with 2 options each, will result in 4 possible paths and 5 choices with 2 options each will result in 32 possible paths. The number of paths that need to be accounted for in terms of content grows exponentially the more a player is allowed to impact the story, along with the variety of options they have to do so. As an illustrative example, consider building an interactive narrative based on the story of Little Red Riding Hood. In the beginning of the story Red Riding Hood is told to visit her grandmother in the forest and bring her a basket of food. The author might want to give the player a chance to have Red Riding Hood refuse her mother here and in her place, her mother would need to go visit her grandmother and the story would end. If Red Riding Hood says yes, the player might potentially choose the food she brings, the path she takes, and what she does while on that path. Each choice bringing a different permutation of the sequence of events in the story. For example, if Red Riding Hood meets the huntsman in the forest early, because the player took time to prepare a speciﬁc type of food and then chose a speciﬁc path, she can tell the huntsman about the wolf in time to stop him from eating her grandmother. Each possible choice, for each type of food, every turn in the road, and 1.1. Building Player-Centric Interactive Narrative 13

FIGURE 1.5: An example of a simple interactive narrative flow diagram. Each circle represents a choice that the player has to influence and progress the story. Each choice gives the player two possible options to select from, which then leads to the next choice, and so on. The number of paths that need to be created and accounted for in terms of authoring grow exponentially the more a player is allowed to choose. The red path represents one possible path through the story. Each path needs to be internally consistent and coherent. every distraction the author allows the player to explore presents a unique narrative path which needs to be authored and accounted for in order to lead to a satisfying and coherent conclusion. Ensuring quality and coherency for each possible narrative path is therefore a very challenging task. This problem is not eliminated through application of more reactive architectures, that in most cases require human authored content. The social game PromWeek (McCoy, Treanor, and Samuel, 2012), for example, utilized over 5000 human-authored social rules (McCoy et al., 2013), a complex and time consuming task. Understandably, this scale of content is hard to author and that is partially because it is near impossible for a human author to be able to effectively keep track of all possible paths, choices, and connections between them. As a result, work in the field has produced some solutions for narrative structure visualization (see Chapter 2 for a more detailed discussion), but those primarily focus on the content, and not on other aspects of the interactive narrative experience such as interaction dynamics, nor their design. The design of interactive narrative is therefore facing a variety of challenges to its continued evolution. The most prominent of these is the difficulty in communicating and describing narrative design due to the lack of generalized design abstraction. This in turn hampers the visualization of interactive narrative design in context, in- hibiting authors and designers from effectively managing, authoring, evaluating, and reflecting on their design. Furthermore, the current set of methods used as a part of the iterative design process require recruitment of human playtesters in order to be able to give objective assessment of the design and provide information of potential player experience issues. This is not only very cost-prohibitive for smaller 14 Chapter 1. Introduction teams and independent developers, but suffers from the same communication challenges previously discussed.

1.2 Automating Design Support and Analysis for Interactive Narrative

A generalized design abstraction is key in order to make automated design visualization and analysis possible. Automating visualization and analysis of interactive narrative would offer a cheaper, faster, and more accessible alternative to human playtesters in the initial iterative stages of the design process. Here automated design visualization and analysis refers to automating the process of generating an abstracted design structure from an existing digital interactive narrative, visualizing it, and providing diagnostics of that abstracted structure. Providing such a visualization would provide an instance of the design that could be reviewed and reﬂected on in real time, and the abstraction would provide a way to surface only those elements that relate to the parts of the design that would be of interest. It would allow for more immediate way of representing and communicating the design, as it would eliminate the need for starting the process by establishing a common ground on which the communication takes place, followed by using subjective experience and external examples to describe issues or changes. Using the abstracted design as a basis for analysis and diagnostics would also provide a basis for comparison, identify broken paths, inconsistencies, and lack of crucial design features such as feedback or deviation from established interaction patterns.

1.2.1 Automated Design Support in Digital Games

Augmenting the iterative design process using automated analysis and visualization in this manner could theoretically help reduce the number of iterations and resources required. The use of automated methods to augment the iterative design process for digital games, has been called for by researchers in the field (Eladhari, 2002). In general, this dissertation posits that such an emphasis on automated methods could similarly improve interactive narrative design. In the same manner as interactive narrative, digital games have a content creation bottleneck. However, the two differ slightly in terms of where the challenges lie. For interactive narrative, the challenge lies not only in content but in coherency, structural complexity (which includes managing and planning narrative impact over the entirety of the experience), and multiple levels of story authoring considerations in terms of character arcs, plot, theme, and so on. All of these elements pose considerable and complex structural design and authoring challenges, exponential growth of content demand, and as a process, is resource-intensive. Digital games have similar problems in that they also require coherent and structurally complex content, 1.2. Automating Design Support and Analysis for Interactive Narrative 15 which in addition needs to be usable, coherent for movement and in-game systems, and balanced in order to deliver engaging play. Within the domain of digital games, researchers have made significant efforts to address content creation issues through the field of procedural content generation. The most successful examples of this work have been within the area of level design (Togelius et al., 2011; Summerville et al., 2018b; Park et al., 2019; Shaker et al., 2012). While there are inherent differences between interactive narrative design and the design of game levels, this is a promising indication that if a suitable design abstraction is found, it can be utilized to provide a basis not only for analysis but potentially for generating interactive narrative design.

1.2.2 Narrative Generation

Efforts for generating narrative have been around since the dawn of the ﬁeld (Ryan, 2017) but these efforts are predominantly focused on generating stories rather than interactive experiences. Recent efforts have focused on generating narrative content for interactive narratives through crowd sourcing methods (Feng et al., 2016; Guz- dial et al., 2015), informed in part by story generation systems such as SayAnything (Swanson and Gordon, 2008) and the Scheherazade System (Li et al., 2013). How- ever, these approaches have so far focused on populating the narrative with coherent actions, and evaluations of their generated output have mainly been in terms of their variety and coherency in relation to each other. The creation of successful stories require more than just coherency. Stories also need to be interesting, believable, contain engaging and believable characters, and in the case of interactive narratives, be playable and engaging on those terms, as well as containing engaging interaction design. Current content generation methods have yet to achieve these aims and the authoring bottleneck for interactive narrative is remains largely unsolved at the time of writing.

1.2.3 Visualization and Automated Playtesting of Digital Games

Within digital game design, the last decade has seen researchers develop visualization and automated testing tools for games and game design (Holmgard et al., 2018; Keehl and Smith, 2018; Guckelsberger et al., 2017; Isaksen, Gopstein, and Nealen, 2015; Dormans, 2011; Liapis, Yannakakis, and Togelius, 2013; Smith, Whitehead, and Mateas, 2010; Baldwin et al., 2017; Cook and Raad, 2019). Automated playtesting refers to building gameplay agents that can play through the game. Their behavioral data can then be used for data driven evaluation of the design, possible patterns of player behavior, and player experience issues that can only be identified during gameplay. All of this work can be viewed in context with the success of the field of procedural content generation, which has produced multiple effective systems and methods for content generation but has thus far lacked the means through which to evaluate and analyze the generated content. This is partially due to the sheer 16 Chapter 1. Introduction amount of content generated, but also due to the field being in an ongoing state of establishing and agreeing on suitable methods, metrics, and central concepts. The design abstractions of level design used within the field of procedural content generation mainly fairly simplistic and rely on simple movement systems that can be found within platformer games like Super Mario Bros., and dungeon-crawlers and rogue-like games which rely on robust movement, item, and resource management gameplay. Furthermore, these types of games often rely on coherency in their framing and central hubs through which players can select and enter levels. This results in a type of game that features a large variety of different levels without having to maintain overall coherency between them, coherency which is integral to successful interactive narrative design. Therefore, while the work on visualization and automated playtesting for digital games shows immense promise, it has not been applied to interactive narrative, which has an additional set of design considerations and complexity. However, automated playesting indicates that the use of design abstraction to visualize design and computational methods to analyze it is a viable and promising method for supporting designers using an iterative design process.

1.3 Thesis Statement and Research Questions

Building better player-centric narratives requires determining a suitable design abstraction on which to base models, analysis, design visualization and communication, and automated design support tools. Using such an abstraction will enable us to build design support tools that can automatically analyze and visualize the design of existing interactive narratives.

“Research Question 1 (RQ1): How to develop an interactive narrative design abstraction, which is suitable for developing a computational model for design analysis and visualization, while maintaining sufﬁcient descriptive and communicative ﬂexibility for novice designers, and how can such an abstraction be applied?”

A suitable design abstraction for interactive narrative design needs to capture the interaction design in as much complexity as possible, and to use a data structure that is intuitive for designers of various skill levels to understand and visualize, in addition to being computationally robust enough to be derived from an existing design using automated analysis. The abstraction needs to capture design and interaction structures relevant to the player experience that can serve as a base for various analysis methods, and to provide a conceptual basis for making sense of the analysis. It should ideally be usable in as many steps as possible during the design process such as planning and layout, prototyping and story-boarding of the experience, design documentation, and play-testing. Finally, the abstraction should be simple enough to allow designers to communicate and visualize their designs effectively, quickly and clearly identifying elements of interests. 1.3. Thesis Statement and Research Questions 17

In this dissertation I show that by abstracting interaction design from interactive narratives, with a focus on progression, it is possible to build both qualitative and quantitative methods of capturing, analyzing, and visualizing interaction design. I show how Progression Maps, a graph-based model of moment-to-moment interaction design for interactive narratives, is used as a computational model for an automated structural analysis tool, where the process of generating an abstracted design structure from an existing digital interactive narrative is automated and the abstracted design structure is visualized. I demonstrate that Progression Maps are suitable for novice designers to communicate effectively about their designs, are easy to understand, and are suitable for qualitative analysis of interactive narrative design, demonstrating its potential for design analysis and prototyping for interactive narrative design

“Research Question 2 (RQ2): Can we build a generalized architecture for building automated structural analysis tools for interactive narrative, where the design is abstracted from an existing artifact and visualized?”

The first condition for an automated structural analysis tool, is an appropriate design abstraction that can be instantiated as a computational model. Using this computational model, it is possible to derive a structural abstraction of the interaction design of an existing artifact. The challenges posed by this lie in the translation between the model and the representation used by the artifact itself. Using the abstraction as a guide, it will be possible to determine how to conduct this translation, which has thus far not been achieved due to the lack of an agreed upon lexicon and generalized approach to interactive narrative design. To automate a mapping where the design is abstracted into the structural representation of the computational model, there are additional challenges that need to be considered, such as whether structures and elements within the authoring tool can map directly onto the model, or whether they require human intervention to construct mapping rules. Once this mapping has been established, the tool will be able to derive the abstracted interaction design structure directly from an existing artifact, and visualize it for the designer. Given the current state of the field, it is more viable to develop an architecture and methodology to build such tools so that other designers and researchers can implement their own, rather than focus on building a stand-alone design tool. This would allow for broader adaptation for different authoring tools, and would potentially encourage others to expand and develop further design abstractions and models that would be suitable for different interactive narrative experiences. The design process and the nature of the design can vary greatly across interactive narratives and video game genres, such as adapting or changing existing authoring tools, or creating new ones from scratch. Both stand-alone and built-in tools would likely require a similar amounts of adaptation in order to map the representation from the authoring system onto the representation used by the analysis system. While this 18 Chapter 1. Introduction would mean that an analysis system would have to be adapted to fit each tool, it would likely yield more targeted results than using a stand alone system, and is therefore more likely to be utilized during development. Generating a design representation from an authoring tool and then running it through a separate system would be more resource intensive than an in-system analysis tool which would be able to generate the representation faster and in the context in which the design process and development is taking place. As part of developing suitable design abstraction and design assistance architecture, I outline a number of requirements that I want the design assistance tool to abide by and will use these requirements as a roadmap that I will address within each chapter of this dissertation. The four major requirements of the tool guided by the research questions above are: the representation chosen by the tool needs to (1) represent an abstracted view of the underlying structure and progression, (2) enable designers to communicate and reflect on the design, (3) be generated automatically, and (4) allow designers to diagnose issues of the design In this dissertation I will show how Progression Maps are used for automated structural analysis as part of the Design Assistant tool for StudyCrafter Harteveld et al., 2017, using the Design Assistant architecture. Structural metrics, based on Progression Maps, can be used to derive information about what kind of player experience the narrative affords (Partlan et al., 2018).

1.3.1 Contribution Statement

To address RQ1, I conducted a study to examine interaction design in terms of progression and player experience in commercial narrative-focused digital games. Based on the ﬁndings of this study, the Progression Model was developed. The model consists of 5 conceptual categories to describe interactive narrative design: Structure, Progression Mechanics, Interaction, Presentation, and Action Set. Of those categories, Interaction and Presentation were suitable for a more targeted and detailed representation. Those 2 categories were then used to develop a graph-based representation of interactive narrative design called Progression Maps. Progression Maps are a descriptive model of moment-to-moment narrative interaction, as opposed to the more qualitative and abstract Progression Model. To evaluate whether Progression Maps are suitable for design communication, an in-depth qualitative study was conducted to evaluate its communicative capabilities as a model. The study showed that the maps are suitable for this purpose and that it had an effective design abstraction for analysis. To address RQ2, I needed to determine whether the Progression Maps could be used for automated generation of existing interactive narrative artifacts. The Design Assistant Architecture was proposed as a ﬁrst step towards achieving this, showing a cohesive approach to how such automated generative systems can be built for narrative construction tools. 1.3. Thesis Statement and Research Questions 19

Study Evaluation of Prog. Map Progression Maps Communicative Capabilities

Study Progression Model Interaction and Progression in Commercial Games Design Assistant Architecture Design Assistant Graphs

StudyCrafter Design Assistant

Study Evaluating StudyCrafter Design Assistant

FIGURE 1.6: Overview of the work conducted for and presented in this dissertation.

The Design Assistant Object representation was derived from the Progression Map representation, resulting in a computational representation of the maps. The Design Assistant graphs are automatically derived by the Design Assistant architecture. In this way, we have a variation of Progression Maps, in the form of Design Assistant graphs. The Design Assistant architecture was implemented for Study- Crafter (Harteveld et al., 2017), a citizen science platform that lends itself well to the creation of interactive narratives, providing a simple visual scripting language, numerous character models, environments and objects for designers to use. Finally, two evaluation studies were conducted on the StudyCrafter Design As- sistant, examining the usability, readability, design abstraction, and communicative capabilities of the Design Assistant graphs, which are a variation of Progression Maps. These two studies are grouped as one in fig. 1.6. These are the two major contributions of this dissertation: Addressing RQ1: The Progression Model is the first descriptive model of interaction design for interactive narratives. It’s central focus is to capture interactive narrative design in terms of how it relates to story progression and player experience. It is used for qualitative analysis and instantiated as a computational model. Addressing RQ2: This dissertation presents the first automated structural analysis architecture for interactive narratives, the Design Assistant Architecture. The architecture is intended to be built on top of existing tools, making it suitable for use across a number of narrative construction tools. In addition, this dissertation 20 Chapter 1. Introduction presents the first interactive narrative models built on a player-centric view of narrative progression that specifically captures interaction design.

1.4 Chapter Overview

• Chapter 1. - Introduction In this chapter, I introduce the topic, motivate the work and situate it within the work done previously in the area of interactive narrative. The chapter also outlines the research questions, the thesis statement, and the contribution to the ﬁeld.

• Chapter 2. - Tools and Models for Interactive Narratives In this chapter, I give an overview of the current state of the ﬁeld in terms of tools and models used for interactive narratives, and discuss their suitability for design communication. Finally, I will discuss various analysis methods that have shown potential for linking structural analysis and player experience outcomes.

• Chapter 3. - The Progression Model In this chapter I present the Progression Model, a descriptive model of interaction design for interactive narratives. Its central focus is to capture interactive narrative design in terms of how it relates to story progression and player experience. The model was developed through multiple iterations of thematic analysis of player experience write-ups generated from playing a large set of critically recognized and notable interactive narrative games. Unlike previous work, the model does not consider the content such as plot and characters, nor the meaning of the text, and instead focuses primarily on how information is presented and perceived by the player in relation to progression. This chapter establishes the theoretical underpinnings and motivation for the Progression Maps, one of the central contributions of this thesis, and establishes the basis for their approach to interaction design abstraction.

• Chapter 4. - Progression Maps Building a graph based representation of interactive narrative will allow us to build a computational representation of interactive narrative interaction. Such a model will enable us to create automated design support tools for interactive narratives, provide the basis for interaction design diagnostics such as metrics, and facilitate communication between designers through visualization. In this chapter, I present Progression Maps, a graph-based, descriptive computational model of moment-to-moment interaction design, meant to capture narrative progression interaction from the perspective of the player. This chapter outlines the model, and discusses its elements and hierarchy in detail. 1.4. Chapter Overview 21

• Chapter 5. - Qualitative evaluation of the Communicative Capabilities of Progression Maps Models of interactive narrative design, computational or otherwise, should be usable for design communication if they are to be used directly in design assistance tools. This includes being suitable for creating layouts and drafts of interaction design at any stage of the design process. In this chapter, I report on a study evaluating the communicative potential of the Progression Maps, and thus addressing requirement (2). During the study, participants described the interaction design of the same parts of an interactive narrative game using the Progression Maps. The results of the study indicate that the maps are capable of capturing critical narrative paths reliably across participants while also communicating the perspective and emphasis of the cartographer.

• Chapter 6. - The Design Assistant Progression Maps have shown potential to allow for effective communication in both capturing interactive narrative design, as well as the cartographer’s perspective, where the maps are built by hand. In this chapter I describe how the Progression Map representation was developed as a computational graph- based model called Design Assistant and how it was implemented within StudyCrafter where it automatically derives Progression Maps equivalent De- sign Assistant graphs from existing StudyCrafter projects, thus satisfying requirement (3). I discuss the choice behind using StudyCrafter as the ﬁrst design tool to implement the maps, how the maps were derived from the underlying representation of StudyCrafter’s scripting editor, and how the maps’ abstraction and visualization reveals more detailed information about the design than is found in the scripting editor.

• Chapter 7. - Evaluating the Implementation of Design Assistant for Study- Crafter In this chapter I demonstrate the suitability of the Design Assistant’s design abstraction and communicative function for use by novice designers, thus showing how the work satisﬁes requirements (1) and (2) as well as (4). I report on two studies where the Design Assistant, as implemented and visualized in StudyCrafter, was evaluated in terms of its usability, perceived usefulness, and readability, focusing on novice designers. The results show that the De- sign Assistant provides a suitable design abstraction that is understandable and recognizable by novice designers, and easy to follow and read, making it suitable to facilitate communication regarding interactive narrative design.

• Chapter 8. - Conclusion and Future Work In this dissertation, I have addressed research questions 1 and 2 and proposed and demonstrated the usefulness of an abstracted computational model of interactive narrative design, called Progression Maps, that captures the structure of narrative progression based on interaction. Furthermore, I have also 22 Chapter 1. Introduction

developed an automated visualization system of this model, called Design As- sistant, that is able to automatically generate visual graphs of the structural elements of interactive narratives to be used for qualitative and quantitative analysis of the underlying design. The Progression Model, the Progression Maps and the Design Assistant are the ﬁrst steps towards the larger goal of addressing how to automate player experience evaluation for interactive narratives for mixed-initiative design tools and automated playtesting in a manner that would be transparent to designers, and allow them to reason effectively about their design. Lastly, I discuss possible applications of the work presented in this thesis, as well as discussing the implications of this work for the Interactive Narrative community more broadly. 23

Chapter 2

Tools and Models for Interactive Narrative

Academic analysis of interactive narrative has been a field of research, dating back at least to the 1980s and Brenda Laurel’s work on Neo-Aristotelian theory of interactive narratives. (Laurel, 1986). There are indications that research efforts might have started earlier, one example being computational narrative generation, which has been found to date back as far as the 1960s (Moriarty, 2015; Ryan, 2017). The field of interactive narrative research as grown and matured since, and scholars in the field have developed theories and models to better inform our understanding of the design and construction of interactive narrative applications, as well as how they are experienced in games and various other contexts, including education (including (McQuiggan et al., 2008; Jemmali et al., 2018; Garneli, Giannakos, and Chorianopoulos, 2017; Marsh et al., 2011)) and social or personal skill training (including. (Marsella, Johnson, and LaBore, 2000; Aylett et al., 2005; Si and Marsella, 2014; Yannakakis et al., 2010)). While interactive narrative, as a field of research, has yet to see a consensus within its community on a common vocabulary to capture and communicate effectively about interactive narrative design (Koenitz et al., 2010; Koenitz et al., 2011; Szilas et al., 2012), the field has produced a variety of tools, models, and approaches to interactive narrative design, generation, and analysis. In terms of emphasis, the field of interactive narrative can be broadly divided into two categories of approaches: system-centric and player-centric. System-centric approaches focus more on the computational and engineering problems of narrative generation, and on dynamic interactive story and drama systems. While some of the works that fall under this category discuss and account for the player, they do not explicitly include a player model or use player interaction as the driving component of their system, focusing instead on managing the player’s interaction and impact on the story. One example of system-centric work is the Scheherazade System (Li et al., 2013). Player-centric approaches focus on accommodating the player first, incorporating player models, and building systems to accommodate their experiences; such systems include experience managers (Thue et al., 2007) and emotion-model 24 Chapter 2. Tools and Models for Interactive Narrative driven drama systems (Seif El-Nasr, 2005). Both approaches share similar graph- based data structures for modeling the interactive narrative itself, and, despite their differences, share similar design goals in terms of producing an engaging, coherent, and personalized experience for their audience. Many of these systems are technically complex to author for, and the field has responded by developing better authoring story tools, best practices, and authoring approaches to interactive narrative; however, many of these tools focus on story content and often do not account for the impact of interaction design and structure on their design, nor how such narrative construction tools are used for design communication within teams. It remains an open area for interactive narrative, and interaction design has not been incorporated into such authoring tools. In terms of player experience, structure has been linked to player agency and engagement in interactive narrative, but interaction design has been largely unex- plored and left out of design tools and analysis. Recently, work examining structural analysis and its links to player experience (Szilas and Ilea, 2014) has shown promise as a method of analyzing player experience in terms of the structure of narrative design itself. In this chapter, I give an overview of the current state of the field in terms of tools and models used for interactive narratives. I will discuss their suitability and use in design communication and computational modeling as it relates to how they might be used for automated design and authoring assistance for interactive narrative. I also discuss various analysis methods for interactive narratives that have shown the potential of linking structural analysis and player experience outcomes.

2.1 Models of Interactive Narrative Structure

Models and approaches to modeling interactive narratives have taken many forms. Prior work has studied various aspects of the design of interactive narrative, including: how the narrative should be represented (Magerko, 2005), how the user should be incorporated (Mateas, 2000a), how to author it (McCoy et al., 2010; Szilas, Marty, and Réty, 2003; Mateas, 2000a), and whether it is compatible with gameplay (Juul, 2001; Frasca, 2013; Jenkins, 2004), to name a few. A significant amount of work has been focused on developing computational models to adjust narrative content based on the players’ interaction, such as for interactive narrative systems (Magerko and Laird, 2003; Mott and Lester, 2006; Seif El-Nasr, 2004; Thue et al., 2007; Young and Riedl, 2003), drama systems (Mateas and Stern, 2003), and experience managers (Thue et al., 2007). Many of these systems use AI planning techniques to maintain consistency and coherency of the plot and character actions. For some of those systems (e.g. (Magerko and Laird, 2003; Mott and Lester, 2006; Young and Riedl, 2003)), the focus is to maintain the plot of the story, guide the user within the experience, or dynamically alter the plot to fit the user’s actions. The player is thus often modeled in terms of their actions and whether they are in violation of the plot, not how their 2.1. Models of Interactive Narrative Structure 25 interaction and story progression is structured and conducted, how they experience and understand the story, nor how it is presented visually. One notable exception was Weyhrauch’s work, where story progress (e.g. activity flow and momentum) and how players experienced it (e.g. thought flow, perceived options, and manipulation) were modeled in a computational evaluation function to guide an interactive narrative as it evolved (Weyhrauch, 1997). The model was not intended nor used as a tool to facilitate or improve authoring or design processes. Notable player-focused work includes models of the player’s knowledge of events (Rowe and Lester, 2010), cognitive state such as goals, beliefs, and emotional state (Mott and Lester, 2006), and personality (Seif El-Nasr, 2004; Thue et al., 2007). These models were used by researchers and designers to adjust narrative and elements of an interactive narrative experience. However, despite explicitly modeling the player, this work does not examine the interplay and dynamics of the player’s interaction with the narrative on a granular level such as presentation of choices and actions within the narrative, what information is given to the player and when, and the structure of the story, to name a few elements. There are two exemplary works that do account for narrative presentation and/or user participation: IDtension (Szi- las, 2003a) and the multimodal interactive narrative applications of Cavazza et al. (Cavazza et al., 2003; Cavazza et al., 2007). Story structure is often used to model narrative and has been discussed within a variety of narrative related sub-fields. The most notable and widely used models have been those presented in relation to hypertext structures and graph-based representations of interactive stories (e.g. (Millard et al., 2013a; Bernstein, 1998; Lindley, 2005)). Graph-based structures are commonly known and used by researchers, designers, and players alike. These structures are identified and discussed in terms of patterns, such as linear and branching, which are commonly used to describe the structural pattern of narrative progression in games. Other influential fields of study that have been used to inform discussion of story structure for interactive narratives include narrative theory (e.g. (Mateas, 2000b; Wei, 2011), see also Louchart and Aylett’s discussion on the topic (Louchart and Aylett, 2004)), AI driven interactive narrative models and systems, (e.g., (Riedl and Young, 2006; Magerko, 2005)), and literature, in terms of the direct structuring of the text itself (Barthes and Duisit, 1975) and the plot structure, such as the Hero’s Journey model (Campbell, 2008) and Propp’s Morphology of the Folktale (Propp, 1968). Of these various approaches to describing and discussing story structure, the most prevalent and frequently used are graph-based structures. These types are so well known that they are a well established part of the video game player community vernacular. Players without any design knowledge use them to describe their experiences with game narratives, specifically in terms of interaction and narrative progression. For example, a game is said to have a linear story if the story is pre- scripted and the player has no control or impact on its content. Alternatively, a game is said to have a branching story if the player’s choices are taken into account 26 Chapter 2. Tools and Models for Interactive Narrative and impact the events and progression of the story. Branching refers to affording the player the opportunity to explore different paths of the tree/graph of the story and its plot. Thus, graph-based structures are not only a model that has been influential in academic work, but is also a frequently used and familiar part of player discussion of interaction and progression for interactive narrative.

2.1.1 Graph Based Models

In previous work, game narrative structures have often been described or modeled using graph theory concepts, such as nodes, links between nodes, and link constraints, borrowing the hypertext conceptualization of narrative fragments that are interconnected with "hyperlinks," or edges, that can be navigated to reveal a larger narrative. Graph-based representations, such as plot points and story graphs, are frequently used to refer to structure in work relating to AI-based interactive narrative systems and drama managers (e.g. (Kelso, Weyhrauch, and Bates, 1993; Riedl and Young, 2006; Magerko, 2005; Sharma et al., 2010; Weyhrauch, 1997; Mateas and Stern, 2004)). Analysis of game narratives also makes use of graph-based representations, such as Wei’s structural analysis of narrative interaction in Heavy Rain (Wei, 2011). Further, graphs have become widely known and used as metaphors for interactive narrative structure by practitioners, researchers, and audience alike, as previously discussed, to describe and conceptualize the player’s impact and agency within the story. Bernstein (Bernstein, 1998) proposed several design patterns for hypertext-based interactive narrative, in some cases using the language of graphs to explain them. Bernstein describes a number of patterns observed in published hypertexts, noting the well-known and widely used “tree” and “sequence” structures. These two patterns correspond to what is today referred to as Linear and Branching structure types (see Chapter3). While he discusses a number of structures, this work is specific to hypertext and does not discuss structure in the context of digital games. Bernstein does put focus on user interaction when defining and describing the patterns, but specifically in the context of how they can convey meaning and story content. Lindley (Lindley, 2005), building on Eladhari’s work (Eladhari, 2002), further taxonomized such structures, beginning to explain how they could be represented as graphs. Lindley presents an overview of a model for describing interactive narratives, where interactive narrative structures are described as being on three levels: atomic graph level, high topology level, and node substructure level (Lindley, 2005). Further, Lindley makes the argument that graph theory terms can provide more precise interactive narrative structure descriptions, emphasizing that higher level structure terms than those provided by graph theory might be more meaningful in terms of how a player would interact with it. However, this taxonomy was not sufficient to enable operalization of concepts that would allow for a computational implementation, which would enable it to be used more widely and effectively for example for design and analysis. For instance, Lindley defined “nodal” structures as connected 2.2. Interactive Narrative Design 27 graphs that may “be more specific depending on their particular form,” offering no means of further disambiguation necessary for more granular analysis. Millard et al. (Millard et al., 2013b) defined three specific structures in terms of graphs. They propose a unified conceptual model of location-based hypertext, which extends the standard mechanics of structural hypertexts, and included narrative transitions. In addition, they propose three structural definitions for location- aware narrative structures: Canyons, Deltas, and Plains. Canyons refer to a linear narrative structure, Deltas, a branching tree structure, and Plains “a collection of nodes that are all accessible and can be accessed in any order” (Millard et al., 2013a), also referred to as “Open” narrative (Hargood et al., 2016). This model, hereafter referred to as the CDP model, was then used to analyze and identify a number of sculptural patterns in location-based hypertext narratives (Hargood et al., 2016). Seven patterns were identified, including parallel threads, gating, and foldback. Some of these patterns were noted by the authors to overlap with those described by Bernstein; one such example was split-join or foldback (Bernstein, 1998). The work explored location-based interactive narrative experiences in terms of hypter- text structure, and the user’s interaction with the hypertext application is described in terms of a transition function and requires the user to physically move to a designated location. However, the CDP model does not account for how such an interaction is designed, the specifics of the presentation of the story content to the player, nor mechanisms of the transition. It does not discuss structural properties beyond how they relate to the transition function. Further, the model only used the three structures (Canyons, Deltas, and Plains) to describe all forms of plot. The model was therefore limited in terms of its expressiveness and suitability for detailed analysis of the narrative interaction from the point of view of the player. Ashwell (Ashwell, 2015) and Short (Short, 2016) each explored smaller-scale structures, with examples in graph form. However, these were not exhaustive models, nor were they generalized into algorithms for detecting and analyzing such structures computationally. Neither model is operationalized: they do not explain the structures in computational terms to enable automated analysis. Perhaps more importantly, they did not specify the components or types of the nodes. They were assumed to operate on the plot structure, divided into nodes, but the elements and descriptions of the node types were unspecified.

2.2 Interactive Narrative Design

The study of interactive narrative combines narrative theory, theater, psychology, and other ﬁelds (Murray, 1997; Mateas, 2000a; Seif El-Nasr, 2007, e.g.). Under- standing how best to design an interactive narrative, balancing authorial burden, authorial intent, and player experiences, is still an open research problem (Roth and Koenitz, 2017). 28 Chapter 2. Tools and Models for Interactive Narrative

Traditional narratological approaches to narrative analysis do not directly lend themselves to computational modeling. This gave rise to the development and use of existing narrative models to bridge the cap (e.g. the Neo-Aristotelian approach (Mateas, 2000a)) and later saw more frequent use of a bipartite model of narrative. The bipartite model of narrative posits that stories can be modeled in terms of story, as in content, and discourse, as in how the content is communicated to the audience (Young, 2007). The model is far more suitable for narrative generation and A.I. approaches than traditional narrative analysis, and presents a theoretical framing and approach to computational interactive narrative analysis. Historically, a dispropor- tionate focus has been put on the story elements like plot and characters, with work on the discourse side, which requires more player-centric approaches only recently starting to be widely studied in the community. This focus on story is partially the result of the field’s focus on one of the core problems of interactive narrative research: the authoring problem. Content creation and development for interactive narrative is resource-intense and prohibitive in terms of scope, and has been identified as a significant problem facing the interactive narrative research community. It has been discussed by various researchers (Tanenbaum et al., 2010; Szilas, Marty, and Réty, 2003; Koenitz, 2015; McCoy et al., 2010) and has a number of names such as the authoring bottleneck (Tanenbaum et al., 2010), and the content creation problem (Feng et al., 2016). Fundamentally, the problem occurs when the exponential demand for content exceeds the production capabilities of a single human author (Tanenbaum et al., 2010). As an illustrative example, for branching narratives, the designer needs to provide content for all possible story paths in the graph that the player might explore, as well as acknowledgement of their choices. Giving the player as few as 2 to 3 choices each time they are allowed to interact will result in the exponential growth of the number of possible paths that need to be accounted for as the content grows and the player is allowed, more and more, to impact the story. Ensuring quality and coherency for each possible narrative path is therefore a very challenging task. This problem is not eliminated through application of more reactive architectures, which in most cases require human-authored content. The social game PromWeek (McCoy, Treanor, and Samuel, 2012), for example, utilized over 5000 human-authored social rules (McCoy et al., 2013), a complex and time-consuming authoring task. To address the issues with content creation, it is worth noting the efforts that have been made in procedural content generation (PCG), which aims to create game assets and content procedurally in order to minimize the design burden and lower production costs. Examples of this can been seen for specific aspects of game design, such as for level design (Togelius et al., 2011; Summerville et al., 2018b; Park et al., 2019; Shaker et al., 2012). Further, several researchers have built tools to support game designers with AI-enabled functionality. The most relevant of these efforts 2.2. Interactive Narrative Design 29 have focused on “mixed-initiative” design, in which game designers and computational systems take turns leading the creation process (Liapis, Yannakakis, and To- gelius, 2013). This approach has required representation and analysis of the designs. Tanagra used rhythm-based analysis of levels to enable designers to fill in gaps automatically (Smith, Whitehead, and Mateas, 2010). Sentient Sketchbook employed a metrics-based analysis of physical level design for real-time strategy games (Liapis, Yannakakis, and Togelius, 2013), and EDDY did so for dungeon-delving games, with a focus on visualizing patterns (Baldwin et al., 2017). Karth and Smith (Karth and Smith, 2019) later suggested a constraint-based level design tool that would use visual examples to mediate communication with a designer. These tools, however, have primarily enabled visual level design, i.e., design of the physical environment and space, not focused on interactive narrative or other forms of player experience analysis. Recently, there has been work on procedural content generation of narrative content for interactive narratives through crowdsourcing methods (Feng et al., 2016; Guzdial et al., 2015), informed in part by story generation systems such as SayAny- thing (Swanson and Gordon, 2008) and the Scheherazade System (Li et al., 2013). However, these approaches have so far focused on populating the narrative with coherent actions, and evaluations of their generated output have mainly been in terms of its variety and coherency. The creation of good stories require more than just coherency. Stories also need to be interesting and believable, contain engaging and believable characters, and, in the case of interactive narratives, be playable and engaging on those terms. Current content generation methods have yet to achieve these aims, and the authoring bottleneck problem remains largely unsolved as of this writing. To help focus and further efforts for PCG methods, researchers in the game design field have started to look into the development of visualization tools or automated testing tools for games (Holmgard et al., 2018; Keehl and Smith, 2018; Guck- elsberger et al., 2017; Isaksen, Gopstein, and Nealen, 2015; Dormans, 2011; Liapis, Yannakakis, and Togelius, 2013; Smith, Whitehead, and Mateas, 2010; Baldwin et al., 2017; Cook and Raad, 2019). However, these methods do not translate to interactive narrative; thus, no work, to my knowledge, has developed visualization tools or automated design testing tools for interactive narrative. Further, there are currently no complete models or frameworks within the field of interactive narrative that describe the interface, as well as the specifics of the interaction dynamics between design elements and narrative content within a video game context in a generalized way, without being explicitly associated with a particular meaning or artifact. Such models and frameworks exist for games, notable examples include Game Feel (Swink, 2008) and Operational Logics (Mateas and Wardrip-Fruin, 2009). Game Feel (Swink, 2008) focuses on the specifics of the player input and feedback loop that apply specifically to games and offer sufficiently granular means of analysis. Operational Logics (Mateas and Wardrip-Fruin, 2009) offers a higher level view, 30 Chapter 2. Tools and Models for Interactive Narrative a theory that categorizes families of game design elements. Computational models for specific logics have been proposed by Osborn (Osborn, 2017). However, none of these frameworks target interactive narrative design specifically and, furthermore, are not always applicable to player interaction in interactive narratives.

2.2.1 Interactive Narrative Design Tools

Interactive narrative often requires complex and intensive authoring to track and maintain the narrative through many potential choices and interactions. As discussed earlier, the authoring bottleneck is caused by the resource demanding process of having human authors create and manage the large narrative space required to produce sufficient amount of content to allow the player flexibility in an interactive narrative. Authoring tools can assist designers in building a coherent, satisfying narrative by representing and visualizing the design appropriately. A good tool can organize important information, reducing the need for designers to keep separate, complex mental or physical models. Branches, choices, and other player interactions are sources of complexity and may benefit from helpful, clear representation. Au- thoring tools that can automatically assist the designer in representing and reflecting on their design could prove valuable in aiding their analysis of these experiential aspects of their work. There are both commercial and academic tools available for the purpose of designing interactive narratives. Commercial tools such as Twine (Klimas, 2009) and Ren’Py (The Ren’Py Visual Novel Engine 2019) are among the most popular tools for authoring narrative-focused experiences, providing structure and enabling designers to create complex narrative-focused games. Spirit AI’s Character Engine (Short, 2019) has begun to expand the possibilities for interactive narrative design by moving beyond dialogue trees, enabling designers to provide structured knowledge representation and employ natural language processing. Tools developed within academic circles for research purposes include recent tools such as Villanelle (Martens et al., 2018) and StoryAssembler (as well as its precursor) (Garbe et al., 2014; Garbe et al., 2019) which have sought to provide usable, flexible tools for moving beyond simple dialogue trees, including efforts to visualize the potential structures and results of generative interactive narrative. Few of these tools, however, have used automated analysis to aid authors in designing narratives. Those that have, such as StoryAssembler, visualize only portions of the potential interaction space. None have developed formal, computational models that can claim to comprehensively represent interaction affordances and results in a player-focused manner.

2.3 Structural Analysis and Player Experience

Player experience in interactive narrative has been widely studied for various constructs such as player agency (Tanenbaum and Tanenbaum, 2010; Wardrip-Fruin et 2.3. Structural Analysis and Player Experience 31 al., 2009; Thue et al., 2011; Cardona-Rivera et al., 2014; Fendt et al., 2012; Day and Zhu, 2017), and engagement and immersion (Douglas and Hargadon, 2000; McMa- han, 2003; Brown and Cairns, 2004; Dow, 2008; Schoenau-Fog, 2011; Bormann and Greitemeyer, 2015; Colás et al., 2017). This work has usually operated at the level of holistic measurement of player experience, rather than at the level of detailed representation of each interaction, which would provide more opportunity for nuanced analysis of individual design elements and structural impact. Calls for further study (Koenitz et al., 2016; Szilas, 2003b) of player experience in interactive narratives has argued for and demonstrated the importance of considering the player more closely when designing and producing interactive narrative experiences (Cavazza et al., 2003; Cavazza et al., 2007; Klimmt et al., 2010; Milam, Seif El-Nasr, and Wakkary, 2008; Szilas and Ilea, 2014; Szilas, 2003b). There has been an increase in work, especially over the last decade at the point of writing, exploring and measuring player experiences for interactive narratives. Of particular interest is work that has focused on computational analysis, and particularly on structural analysis (Klimmt et al., 2010; Szilas and Ilea, 2014; Vermeulen et al., 2010). It is important to note that structural analysis is promising as it allows for an understanding of interactive narrative design, as a simplification the design and the narrative. Deep analysis of the content and meaning of interactive narrative, and stories in general, remains exceedingly difficult to do computationally, as it requires knowledge of context, language, culture, authorial style, and more. All of which are difficult to reliably model and represent computationally. In the context of this work, structure is conceptualized as the organization, flow, choices, interactions, and other elements that do not rely on a deep understanding of the culturally-informed meaning of the text. As a result, narrative structure can be modeled through the interaction that it allows and the ordering of the content that it contains, which presents a far simpler model and understanding of an interactive narrative. Focusing on attributes specific to structure, and conceptualizing it as a commonly used data structure like graphs, presents a viable computational representation. In this context, automated systems and analysis can be produced that provides information that can augment and complement an expert’s understanding of plot, characters, dramatic arcs, and other content, without running into the complexities of its parts which remain a challenge still, at the time of writing. A step towards building computational techniques for interactive narrative structure is to define and operationalize metrics for structural analysis. Metrics provide a concrete set of measurements to quantify and simplify interactive narrative structure. However, this subject has not been widely researched. There are very few examples of clearly defined structural metrics or automated analyses for interactive narratives. One such example is the work of Szilas and Ilea (Szilas and Ilea, 2014), who defined a small set of metrics for player interaction and choice, and conducted 32 Chapter 2. Tools and Models for Interactive Narrative a preliminary user study to measure emotional responses such as experiences of en- joyment, curiosity, and suspense (Vermeulen et al., 2010), which are related to narrative theory (Roth and Koenitz, 2016). Using these metrics, Szilas and Ilea (Szilas and Ilea, 2014) found connections between structure and player experience, finding cor- relations with player experiences of flow states and positive emotions. While their work does offer insight and objective evidence of how structural design analysis can be used, it also demonstrates that it is possible, through structural metrics, to derive structural properties that can then be correlated with player experience evaluation survey data. In the IRIS network and subsequent work, researchers have begun to more directly extract and separate metrics of player experience in interactive narrative (Roth, Vorderer, and Klimmt, 2009; Vermeulen et al., 2010; Roth and Koenitz, 2017). These metrics are promising, but they do not yet propose a fully computational, operationalized model of interactive narrative that would enable their proposed measurements and support designers. Initial applications of the work reported in this dissertation and previous work (Partlan et al., 2018) was used to develop such a representation to measure and expand on the “objective metrics” proposed by Szilas and Ilea (Szilas and Ilea, 2014). Work on user experience evaluation frameworks and metrics (Klimmt et al., 2010; Roth and Koenitz, 2016; Szilas and Ilea, 2014) does not explicitly incorporate the impact of design elements on the interaction design of the artifact itself, such as feedback, input, and progression mechanics. Studies on exploring structure as it relates to agency have been done (Fendt et al., 2012). Further, Bernstein’s description and definitions of different structure types in hypertext and interactive fiction, and how they relate to specific understanding or experience of a narrative (Bernstein, 1998), are another example of how structure and design combined are argued to impact the player experience. However, this work does not present a generalized framework vis a vis player interaction in interactive narratives in games, has not offered comprehensive frameworks for describing the design, nor presented objective evidence of how agency is affected by such designs.

2.3.1 Modeling and Analyzing Game Design

Outside of interactive narrative, researchers have performed formal modeling and analysis of game design. One of the most comprehensive such efforts is the development of Operational Logics, a theory that categorizes many families of game design elements (Mateas and Wardrip-Fruin, 2009). To operationalize these logics, Osborn (Osborn, 2017) has since proposed computational models of specific logics. Computational analyses of game design have employed graphs, such as Petri nets (Araújo and Roque, 2009; Lee and Cho, 2011) and Bayes nets (Guzdial and Riedl, 2018). Petri nets, however, quickly become too complex for manual analysis. Guzdial and Reidl work using Bayes nets (Guzdial and Riedl, 2018), focuses 2.3. Structural Analysis and Player Experience 33 on physics-based interactions extracted from gameplay videos, for machine learning and game generation, and this does not necessarily support manual analysis nor interactive narrative. Bakkes and Dormans (Bakkes and Dormans, 2010) proposed modeling mission design and physical level layout as two related graphs, but their work applied specifically to physical level layouts and was primarily generative. They did not deeply explore models of player interaction, design metrics, or how to interpret existing designs into graphs. Other researchers have developed programming-language-based models of game design, such as the Player Intent Language (PIT) by Martens and Hammer (Martens and Hammer, 2017), Gemini by Summerville et. al. (Summerville et al., 2018a), and the Video Game Description Language (VGDL) by Schaul (Schaul, 2013). The Video Game Description Language (VGDL) expresses a variety of 2D, arcade-style games in a single language (Schaul, 2013). However, this work does not explicitly represent interaction opportunities and their results for player experience in a designer- friendly manner. It also does not include sufficient constructs for representing interactive narrative structure. Player Intent Languages (PIL) (Martens and Hammer, 2017) and Gemini (Summerville et al., 2018a), similarly, represent aspects of game design in language or constraint-based forms, encapsulating some player interactions and attempting to model their meanings. These focus on arcade-game-like interactions rather than on interactive narrative. Moreover, these languages have not been comprehensively evaluated in terms of their usability, thus it remains to be seen whether constraint and language-based representations are usable by game designers. Others have explored graph-based representations of game design, though rarely with a focus on interactive narrative. Petri nets provide a detailed model for certain game mechanics (Araújo and Roque, 2009), although they are difficult to use for higher-level interactions. Recently, Cook and Raad (Cook and Raad, 2019) developed a similarly low-level graph-based model for a broader set of game mechanics; however, their model, Hyperstate Space Graphs (HSG), is not yet tested for usability, nor does it explicitly represent interactive narrative elements. Several efforts have been made to translate Petri nets to incorporate narrative elements of game design, such as by Brom and Abonyi (Brom and Abonyi, 2006), Lee and Cho (Lee and Cho, 2011), and Cabioch et al. (Cabioch et al., 2019). These models operate at a higher level, however, to describe the plot of the story, and thus do not explore interactive elements such as player input, nor how that input leads to specific feedback. To my knowledge, none of these efforts have been tested for usability by designers looking to analyze the interactive affordances and player experiences of their designs. Relevant to the work presented in this dissertation is prior and current work by researchers exploring automated playtesting, in which AI agents play through games either in their original form or in simplified simulations (Holmgard et al., 2018; Keehl and Smith, 2018; Guckelsberger et al., 2017; Isaksen, Gopstein, and 34 Chapter 2. Tools and Models for Interactive Narrative

Nealen, 2015; Dormans, 2011). Building automated playtesting requires operationalizing the design of the game in terms of interaction and gameplay so that it can be computationally modeled. While not focused on narrative, it does provide understanding of how models for automated design evaluation can be built and how simulation of player behavior for interactive narratives might be developed. Also relevant is prior work that has sought to visualize and analyze game design in an automated fashion (Liapis, Yannakakis, and Togelius, 2013; Smith, Whitehead, and Mateas, 2010; Baldwin et al., 2017; Cook and Raad, 2019). Similar to automated playtesting, this work offers insight into how design in an interactive space can be analyzed and visualized effectively. Likewise, this work did not focus on narrative- based interaction in games or interaction affordances, such as user choices, feedback, or the mechanisms of narrative changes as inﬂuenced by the system itself rather than players’ choices. Taking these design elements into account, however, is important as a way to evaluate the players’ agency and experience (Ryan, Rigby, and Przy- bylski, 2006), which is important for interactive narratives (Roth and Koenitz, 2017; Wardrip-Fruin et al., 2009).

2.4 Summary and Discussion

The field of interactive narrative has produced a significant body of work focusing on studying interactive narrative experiences and their design, as well as AI systems to generate stories and provide dynamic and engaging interactive dramas with autonomous characters. However, many of these systems are technically complex to author for. While the field has responded by developing better authoring story tools, best practices, and authoring approaches to interactive narrative, many of these tools focus on story content, and often do not account for the impact of interaction design and structure on their design, nor how such narrative construction tools are used for design communication within teams. The field has produced several notable models and approaches for interactive narratives, but they have so far not addressed interaction design in detail, nor its impact on player experience. While there is understanding of this phenomenon in the research community and among interactive narrative designers, evidenced by the considerable body of critically and commercially successful narrative-driven games and work on design impact and game mechanics, this knowledge has not been formalized, incorporated into interactive narrative design tools, nor discussed in terms of what design abstraction would be best suited for analysis for such applications, design communication, and use in the interactive narrative design process. Graph-based approaches to modeling narrative have been widespread across the field of interactive narrative research, making it a suitable data structure for visualization of interactive narrative design. In addition, it is a computationally sound and well-researched data structure. For both of these reasons, graph-based structures would be well suited for a interactive narrative model. Graphs have been used 2.4. Summary and Discussion 35 both directly and as metaphors for the various discussions and interpretations of interactive narrative structure. Structure has been associated strongly with central interactive narrative player experience constructs like player agency, but such associations have been mostly posited in theoretically supported work. The association not been sufficiently studied to provide empirical support to either accept or refute such statements. Re- cent work has shown that structural analysis of interactive narratives correlate with player experience measures, indicating that structural analysis is one possible avenue of research to explore such questions. In addition, structural analysis requires formalized models of interactive narrative design, which combined with structural analysis will make automated design analysis for interactive narratives a possibility. However, currently the field has not produced any formalized representations or models that can be used to computationally model interaction design, the player experience, nor the dynamics between them.

Chapter 3

The Progression Model1

In this chapter, I present the Progression Model, a descriptive model of interaction design for interactive narratives. Its central focus is to capture interactive narrative design in terms of how it relates to story progression and player experience. It provides designers and practitioners with a common lexicon to describe and analyze interactive narratives in terms of the elements that make up the interaction design. The model was developed through multiple iterations of thematic analysis of player experience write-ups, generated from playing a large set of critically recognized and notable interactive narrative games. A particular focus was put on analyzing how the mechanisms were constructed and connected to properties of the structure in which it was embedded, and deriving patterns thereof. Unlike previous work, the model does not consider the content of the narrative, such as plot and characters, nor the meaning of the text, and focuses primarily on how information is presented and perceived by the player in relation to progression. This chapter establishes the theoretical underpinnings and motivation for the Progression Maps, one of the central contributions of this dissertation, by establishing and emphasizing Progression as a frame for interaction. It also emphasizes the importance of how communication between designer and player is structured, by emphasizing how common ground communication between designer and player is designed. Lastly, it establishes the basis for the Progression Map approach to interaction design abstraction, by supplying the first abstraction and set of elements for the Map’s initial versions. In this chapter I will first briefly discuss the need for descriptive models for interactive narratives (see Chapter2 for a more detailed discussion), and why narrative progression was chosen as a central concept. I will then present the methodology used to build the model and discuss the set of games analyzed. I will then describe the current version of the model in detail and each of its 5 conceptual categories required to describe interactive narrative progression. Finally, I will discuss the limitations of the model and how it serves as a stepping stone towards more quantitative models of interaction design.

1The work presented in this chapter was done in collaboration with Erica Kleinman. 38 Chapter 3. The Progression Model

3.0.1 Lack of a Common Ground Vocabulary

Interactive narratives are widely used, often in combination with game mechanics, in a variety of digital game applications. It has increasingly been incorporated into education (Jemmali et al., 2018; Garneli, Giannakos, and Chorianopoulos, 2017; Marsh et al., 2011), and is used in serious games and intelligent tutoring systems, where learning is contextualized within the narrative (Mott and Lester, 2006). For such high impact and sensitive domains, especially if the goal is to examine the impact interactive narrative may have on the player, the narrative design and story interaction should be described in such a way that it can be replicated by others, examined, and studied in detail. However, often the design of the interactive narrative experience is left undocumented or documented insufficiently such that its narrative experience cannot be replicated. This lack of documentation is, in part, due to the field of interactive narrative research not yet having settled on a lexicon that can be used to describe common concepts (Koenitz et al., 2010; Koenitz et al., 2011; Szilas et al., 2012). Due to this lack of a common ground vocabulary, describing and comparing different interactive narrative designs becomes problematic. There are no frameworks that currently encapsulate all elements of interactive narrative design. At the same time, this lack of a common vocabulary has not prevented designers from successfully designing and implementing interactive narrative in games in ways that ensure that players understand how they can impact and progress the story. Examining critically and commercially successful narrative-driven games, and deriving interaction patterns from their design, can help researchers take the first step toward establishing a vocabulary, not only for how to capture and describe the narrative design, but also to inform further study in the field. For this purpose, I argue that it is beneficial to examine interaction in narrative games using communication, and how it is used to establish common ground (Clark, 1996) between designer and player.. While common ground has been extensively investigated and applied within Human-Computer Interaction (HCI) in a variety of domains (e.g. (Kiesler, 2005; Convertino et al., 2008; Birnholtz et al., 2005; Baker et al., 1999; Holler and Wilkin, 2009)), to my knowledge, it has not been used to investi- gate interactive narrative. Interactive narrative games and applications are suitable for such an analysis, as they are, at their core, meant to communicate a particular narrative from their designers to a player. Their primary function is to establish a story world the player can experience. Central to experiencing an interactive story world is understanding the mechanisms the designer has provided the player to explore the story. In other words, how the designer enables the player to progress the story. Chapter 3. The Progression Model 39

3.0.2 Progression

While there are many schools of how narrative is constructed and understood, many assume that narrative is, for the most part, composed of a sequence of events that are understood to form a whole, which is, in turn, understood to be the plot of the story. Progression refers to the moments when one event has concluded and another one is presented as starting, whether that be through a book, film, theatrical performance, or oral storytelling. Interactive narratives do provide additional dimensions for the audience, they require participation in a manner that other storytelling media, traditionally, have not. This participation means that each "reading" of the narrative can differ from player to player. Because their actions might differ, their understanding of the context and characters (which likely differs for all manner of storytelling, due to individual differences and cultural factors) might impact their choices differently. As a result, interactive narratives can offer a more personalized story experience than their non-interactive counterparts. In interactive narratives, the player primarily obtains narrative information through interaction, and information that is delivered alongside interaction to contextualize it. In this sense, whenever the player takes an action through which new information is gained, or as a result of which the player perceives a significant, permanent change in the game’s story world, the story has progressed. This makes progression more granular and contingent, not only on the player’s understanding of their actions within the narrative and the context of its story-world, but on the player’s broader understanding of how the interactive narrative application/artifact functions, how it operates mechanically, and what previous knowledge of such artifacts the player brings with them to the experience. As a result, while progression in interactive narratives can be considered in terms of traditional narratological plot progression and character development, it must also be considered in terms of how it progresses the player’s own understanding of their actions, experience, and how they relate to the interactive narrative they are experiencing and actively participat- ing in. In this sense, interactive narrative players can be seen as embodying the reader as conceptualized in reader-response theory, in literary criticism, where the reader is recognized as an active agent who’s interpretation and understanding of the work constructs it’s meaning (Bleich, 1975; Harkin, 2005). This is important, especially in relation to how progression is to be defined. If progression is not defined as being as granular as new information being delivered to the player in response to their action, it is abstracted in terms of its content (such as plot, story events and character actions). While this is an important and valid approach, it does not address or encapsulate the granularity required to study the impact individual actions and information will have on how the player understands and interprets the narrative. If new information is delivered to the player, the player will consider, interpret, and update their understanding of the narrative in terms of their previous understanding and individual and cultural context. This might be a major update, or a very minor one. It could even be disregarded if the information 40 Chapter 3. The Progression Model is not deemed relevant, however, it will occur regardless of whether the story progresses in terms of its plot or not. While no two players can be considered to be exactly the same, and will perceive or interpret events and actions in the same way, there is the argument that there are likely to be commonalities in what information is considered new, and how this will factor into the context of particular stories and understanding thereof. However, there is currently no empirical evidence that has examined this in sufficient granularity in the context of interactive narratives. An effort to address this will require descriptive models, and models that are granular enough to capture interaction design at this interaction level. Further, for future empirical research on the topic, progression should be considered as granularly as possible to allow for nuanced analysis, as the understanding and inclusion of elements between players is likely to differ. As a result, progression is not just a central concept and concern for interactive narrative design, but also to understand how it is experienced, understood, and studied.

3.1 Building the Model

The model was built across several separate iterations of thematic and qualitative analysis. Each iteration used either the entire list, or a sub-set, of games described in section 3.1.1. These efforts either used the same methodology to generate data on different sub-sets of games (Carstensdottir, Kleinman, and Seif El-Nasr, 2017; Carstensdottir, Kleinman, and El-Nasr, 2019), or used that same methodology to analyze particular design patterns, like rewind mechanics (Kleinman, Carstensdot- tir, and El-Nasr, 2018). Further, the model was also updated to reﬂect further insights gained through using it to study narrative phenomena like diegesis (Klein- man, Carstensdottir, and Seif El-Nasr, 2019). In this section, I will only discuss the thematic analysis methodology that the bulk of the model was informed by, as the additions made to incorporate diegesis were complementary to the already established model, it’s factors and components. All these components however will be presented in the full description of the model, see section 3.2.

3.1.1 Game Selection Criteria and Description of Analysis Set

Games for the sample were required to meet a selection criteria. They were required to be narrative driven games, where the narrative experience was the focus, and recognized as such commercially, critically, or academically. The games were required to have a single-player mode, so that a single player could experience the entirety of the story as intended. All exclusively multiplayer games were excluded as a result. Games were required to feature explicit story content, and as a result, games that featured emergent narratives, such as simulation games, or games that relied on environmental storytelling that required interpretation, were excluded. The sample was initially formed from a convenience sample of games that ful- filled the criteria. As more games were considered for the sample, the games were 3.1. Building the Model 41 considered based on whether they were adding additional variety to the sample in terms of production level and design features. This was in order to get as diverse and expansive a set of games as possible, to represent the kind of interactive narrative experiences that had been successful and well regarded as examples of interactive narrative design. Production quality ranged from AAA commercial titles from large studios, like Square Enix and BioWare, to smaller independent developers and single creator teams from both the industry such as Hanako Games and Lucas Pope, as well as academic work, from Michel Mateas and Andrew Stern among others. Design features included the more abstract story structure, story delivery, and interaction design methods. While this method undoubtedly leaves out narrative games worthy of study, starting such an exploration with a set of games known for strong story focus, with a lot of variation in production values and storytelling methods, will be sufficient for the purpose of constructing an initial descriptive model, which is capable of being updated and reconfigured as more games and analyses thereof are incorporated. The final sample chosen for analysis consisted of 22 games. These were:

• Facade (Mateas and Stern, 2012)

• The Stanley Parable (Galactic Cafe, 2013)

• The Wolf Among Us (Telltale Games, 2013)

• Long Live the Queen (Hanako Games, 2012)

• Oxenfree (Night School Studio, 2016)

• Her Story (Barlow, 2015)

• Gone Home (The Fullbright Company, 2013)

• The Novelist (Hudson, 2013)

• Final Fantasy XV (Enix, 2016)

• To the Moon (Freebird Games, 2014)

• Undertale (Fox, 2015)

• Black Closet (Hanako Games, 2015)

• Papers Please (Pope, 2013)

• Zero Escape: Virtue’s Last Reward (Chunsoft, 2012)

• Prom Week (McCoy, Treanor, and Samuel, 2012)

• Persona 4 (Atlus, 2008)

• Dragon Age: Inquisition (Bioware, 2014) 42 Chapter 3. The Progression Model

• Heavy Rain (Quantic Dream, 2016)

• Nier: Automata (Games, 2017)

• Life is Strange (Dontnod Entertainment, 2015)

• Doki Doki Literature Club (Salvato, 2017)

• Save the Date (Paper Dino Software, 2015)

3.1.2 Methodology

For each of the games, player experience data was collected from recordings of a single researcher describing her interactions with each game throughout each playthrough; As recommended by Aarseth (Aarseth, 2003) in order to keep the experiences consistent. The researcher in question possessed extensive experience with playing narrative games, but focused on experiencing each game through the eyes of a new user. No cheats or walkthroughs were allowed or used. The researcher recorded herself describing her interaction with each game throughout each playthrough. She reg- ularly paused the game and took notes on the interactions she had. During such points, she reflected on the following questions: Did I, as a player, progress the story? How is my current interaction related to the story and the story progression? How was this interaction presented to me? Upon completing a playthrough of each game, the researcher transcribed the recordings. Those comments were then combined with the observation notes into a single document. All games in the sample were played until the end or for at least 10 hours, similar to previous studies of the same sample. 10 hours was deemed sufficient to experience most of the interaction design paradigms required to progress the story, as it is unlikely that new progression interaction paradigms would be introduced to the player after the initial phase of the story was completed. Games were commonly played for 10 hours and not completed due to time constraints, for example Dragon Age: Inquisition and Zero Escape: Virtue’s Last Reward were both extensive in size and infeasible to finish within a reasonable time. Alternatively, Black Closet posed a different challenge as it utilizes procedural and randomized narrative elements as a part of its progression, making it difficult to complete in a reasonable time frame, as its puzzles are not easily solvable, requiring extensive re-playing. Data on each game was analyzed using a qualitative thematic analysis approach similar to (Moura and El-Nasr, 2015). The data was analyzed through an iterative process by two researchers. First the researchers listed and categorized all the interaction elements present in the data. They then further analyzed those elements to identify recurring themes and patterns. This was done by first categorizing the elements into broad major themes, and then identifying related elements and sub- themes for each category. 3.1. Building the Model 43

3.1.3 Interlude: Diegesis and Interaction Design in Interactive Narratives

Establishment of story world is of crucial concern to any interactive narrative en- deavor regardless of format. Whether it is through establishing a common ground for live action role play, a set of rules for a card game, or constraining the range of action relevant to an ARG, the player needs to have a clear sense of where the story world begins and where it ends. The player’s awareness of the story world boundary allows them to reason about what knowledge they can apply to their interaction within the world. Players will approach a story world, and formulate hy- potheses about its boundary, from multiple points of view, depending on what inferences they have access to as a result of previous experiences, whether that be from other games or the real world. If a story world boundary is not well established or blurred, the player will rely on previous experience to guide them. Previous work has established that players can transfer inferences from a game to the real world (Rosenberg, Baughman, and Bailenson, 2013), making the study of how story world boundaries are established and maintained through design of significant importance in the study of, not only interactive narratives, but broadly for how people transfer and apply knowledge between games and the real world. For digital games, such story world boundaries are often blurred. Menus, interfaces, and in-game systems, elements outside the defined frame of the story world, are often used to facilitate narrative interaction and communication, while simultaneously acting as a gateway between the player and the story world (Jørgensen, 2012). While interacting with them, the player will try to understand and reason about which actions will impact narrative progression (Carstensdottir, Kleinman, and El-Nasr, 2019). For the player, differentiating between elements within and outside the frame of the story world becomes even more complex when elements outside the conventional frame of the game world, such as the file system of the computer, are used to progress the narrative. Designers need to be able to communicate to the player where the boundaries of the story world lie and what actions exist within it. In non-interactive media, specifically film, such boundaries, and the navigation thereof, are discussed and defined in relation to diegesis. There are multiple definitions of diegesis in different mediums. Theater, as far back as ancient Greece, used the terms "diegetic" and "mimetic" to refer to narrated and enacted stories, respectively (Segre and Meddemmen, 1980; Berger, 1994; Neumeyer, 2009). By contrast, previous work in literature and film discusses diegesis in a manner similar to theories of fabula, where there is a distinct separation of the world of the story as it exists, and the events of the story as they are presented (Bunia, 2010; Gorbman, 1980). Within the medium of film, specifically, the concept of diegesis is concerned with establishing a universe within which the events of the story occur (Neumeyer, 2009; Winters, 2010; Sandifer, 2011; Gorbman, 1980). Previous work in games and diegesis have shown the potential of the film studies 44 Chapter 3. The Progression Model approach in which the focus is on the division and relationship between the audience and the storyworld (Ryan, 2001; Klevjer, 2002; Crick, 2011; Rutter and Bryce, 2006). However, existing work has also illustrated that the film studies approach on its own is not enough to account for the interactive nature of games (Jørgensen, 2007; Ryan, 2001; Ferri, 2009). Building on film studies, in previous work (Klein- man, Carstensdottir, and Seif El-Nasr, 2019), me and my co-authors expand the existing understanding of diegesis to account for interactivity. Using previous work and the Progression Model, then called Interaction Model for Interactive Narratives (Carstensdottir, Kleinman, and Seif El-Nasr, 2017; Carstensdottir, Kleinman, and El- Nasr, 2019), we expanded the Progression model to form an initial approach for analyzing diegesis in games, from the perspective of how players perceive what their diegetic action set is and how the narrative can be progressed. In the context of this thesis, diegesis is understood similar to film theory, there being a separation between the software window of the story world of the game, and the non-diegetic world of the audience (its player(s)), and its apparatus (the computer that runs the software). We use the user experience (UX) feedback loop, in combination with the Progression Model, to guide our understanding of where and when an interaction and its consequence or results, are diagetically located. In this context, a UX feedback loop is when the player observes the story world, considers the information available, and builds a plan of action. The player attempts to take action, in accordance with the plan, and once their action has been performed, the player observes the impact on the story world, and the loop repeats. Analyzing diegesis in this way allows for distinguishing between what information is available to the player and what is presented, and how that relates to what kind of diegetic impact a particular action might have. Distinguishing between these steps is necessary in order to reason about and design narrative progression, as it will allow more concrete understanding of when an action is and isn’t considered a part of the story.

3.2 A Descriptive Model for Narrative Progression

3.2.1 Overview

The analysis efforts have resulted in 5 factors or categories, that together form the model. These are: Structure, Progression Mechanics, Interaction, Presentation, and Action Set. See ﬁgure 3.1 for an overview of the whole model.

3.2.2 Structure

In previous work, as discussed in Chapter2, game narrative structures have often been described or modeled using graph theory concepts, such as nodes, links between nodes, and link constraints. Graph based representations, such as plot points and story graphs, are frequently used to refer to structure in work relating to AI based interactive narrative systems and drama managers e.g. (Kelso, 3.2. A Descriptive Model for Narrative Progression 45

FIGURE 3.1: The Progression Model consist of 5 factors: Structure, Progression Mechanics, Interaction, Presentation, and Action Set.

Weyhrauch, and Bates, 1993; Riedl and Young, 2006; Magerko, 2005; Sharma et al., 2010; Weyhrauch, 1997). Analysis of game narrative also makes use of graph based representations, for example, Wei’s structural analysis of narrative interaction in Heavy Rain (Wei, 2011). More formally, Lindley presents an overview of a model for describing interactive narratives, where interactive narrative structures are described as being on three levels: atomic graph level, high topology level, and node substructure level (Lindley, 2005). Further, Lindley makes the argument that graph theory terms can provide more precise interactive narrative structure descriptions, but makes the point that higher level structure terms than those provided by graph theory might be more meaningful in terms of how a player would interact with it. Like previous work, here structure refers to the graph-based layout of the narrative content of an interactive narrative. In other words, how the events of the narrative are arranged to allow for navigation between story and gameplay segments. Different structure types refer to different arrangements of events. Players can proceed from one node of the story to the next through the use of narrative progression mechanics. Six different computational story structures were identified in the game 46 Chapter 3. The Progression Model sample. In this section these structure types are defined, and their modular nature discussed. Some of the structure types presented here have also been found and defined in previous work.

FIGURE 3.2: Linear Structure

Linear (figure 3.2) refers to a story structure with a single possible start and end point. More specifically, if only one path is traversable, i.e. if all narrative events are in a fixed and unchangeable order, it is a Linear structure. Linear stories frequently feature variations in flavor text, but story events always occur in the same order. Lack of replayability is a drawback of Linear structures but alternatively, they offer cohesive and controlled narrative experiences. Examples include To the Moon (Freebird Games, 2014) and Final Fantasy (Enix, 2016).

FIGURE 3.3: Branching Structure

Branching (ﬁgure 3.3) structures offer variance in narrative events by including multiple diverging paths from each narrative event that are distinct from other paths in the structure. Branching therefore lends itself well to replayability. However, they are complicated to build as they require careful monitoring for content consistency, which is difﬁcult as the structure grows exponentially. Examples include The Stan- ley Parable (Galactic Cafe, 2013) and Zero Escape: Virtue’s Last Reward (Chunsoft, 2012).

FIGURE 3.4: Foldback Structure

Foldback (ﬁgure 3.4) refers to structures where events can branch out in response to player input, but eventually converge back to a single event. It can also be iden- tiﬁed by repeated and consistent modules of isolated branching. This allows the narrative to feature variation, but controls expansion. However, variation is limited 3.2. A Descriptive Model for Narrative Progression 47 and it can become noticeable to the player through multiple playthroughs. Exam- ples include Oxenfree (Night School Studio, 2016) and The Wolf Among Us (Telltale Games, 2013).

FIGURE 3.5: Broom Structure

Broom (ﬁgure 3.5) features a primarily Linear structure with multiple Branching story endings. This is distinguished from Branching structures as the majority of the story features a Linear structure and branches only to provide variation in the end. Similar to Foldback, limits in variation can be noticed upon multiple playthroughs. Examples include Undertale (Fox, 2015), Papers Please (Pope, 2013) and Persona 4 (Atlus, 2008).

FIGURE 3.6: Hidden

Hidden (ﬁgure 3.6) refers to narratives that are broken up and dispersed within the experience. Narrative segments have no explicit paths between them, and the player is meant to assemble the story throughout gameplay. While replayability can be limited due to the ﬁnite amount of story content, the structure provides the player with a high degree of control in terms of how they experience the narrative. Exam- ples include Gone Home (The Fullbright Company, 2013) and Her Story (Barlow, 2015).

FIGURE 3.7: Opportunistic Structure

Opportunistic Story (ﬁgure 3.7) refers to structures that utilize dynamic processes to structure their story content. These methods and structures can vary greatly depending on how they are designed and implemented. This variation requires 48 Chapter 3. The Progression Model more extensive analysis which is outside the scope of this paper. For more detail on Opportunistic story structures, refer to the two examples identiﬁed as using this structure: Facade (Mateas and Stern, 2003) and Prom Week (McCoy et al., 2011).

3.2.3 Interlude: Structure Modularity

Modularity here refers to compositions of structure types, and how they are used. The analysis indicated that structures in narrative games are highly modular, and often contain more than one type of substructure for different narrative events. How- ever, there generally is a strong overarching structural pattern of how the narrative is progressed through or organized. One example of this can be seen in The Wolf Among Us, which has a Foldback structure for the main story events but features short narrative sequences with Hidden structure. In the context of this work, these patterns that serve as the main structural type are referred to as the overarching structure of the narrative. This overarching structure can be understood as representing a generalization of the level of inﬂuence the player ultimately has on the story progression. For example, an overarching Linear structure can contain Branching substructures that may provide variation in how events are presented, but they will not impact or change the progression of the narrative events in any way. In other words, the narrative events will always occur in the same order for all players, regardless of the different paths within the Branching substructures. Since the overarching structure is Linear, and the story events will always progress the same way independent of variation provided through substructures, the player will likely see the story structure as Lin- ear if playing through the story more than once. As a result, overarching structure can be understood as a variation of a mental model a player has of the story structure, which they can use to reason about the inﬂuence of their actions on the story.

3.2.4 Progression Mechanics

Narrative mechanics describes the rules and patterns that allow a player to interact with the narrative of a game and traverse its structure. As previously discussed, here the focus is speciﬁcally on mechanics that allow the player to progress through the story (i.e. narrative progression mechanics). Other game mechanics such as combat, puzzle solving or resource management were included in the analysis only when relevant to narrative progression.

Progression Mechanic Types

Five different progression mechanic types were identified in the game sample, some of which, like Choice and In-game Systems, have sub-types. In this section, these progression mechanic types are defined, and their modular nature discussed. Progression through Choice refers to mechanics that allow players to progress in the story by making a direct choice, which can be augmented by additional variables, 3.2. A Descriptive Model for Narrative Progression 49 such as timers. These mechanics often focus on allowing the player to make a sin- gular decision with implied ramifications for each choice. This enables the player to reason about the design intent behind the choice. As such the player can construct a mental model of there being a branching possibility, as supposedly the ramifications of the choice are not trivial and offer different paths through the story. These mechanics generally fall into two distinct categories: selection, and performance. Choice through selection refers to when a player selects a choice explicitly, such as through a menu, chart or dialog box. It often features very explicit and direct presentation. The action of making a choice is presented to the user and the user is unable to progress until a choice has been made (whether that be due to inaction or direct action). Ox- enfree (Night School Studio, 2016), The Wolf Among Us (Telltale Games, 2013) and Long Live the Queen (Hanako Games, 2012) feature choice through selection. Choice through performance is when the player “performs” the choice, for example through input mapping or game mechanics. Choice through performance is more often presented less explicitly, relying more on environmental, contextual, input mapping, and interface elements to imply that there is a choice to be made and how it should be performed. However, for this subtype, Choice is not necessarily displayed clearly and in such a way where there is no doubt about what options are available to the user, despite the player being aware that the initiated action will progress the narrative in some capacity. The Stanley Parable (Galactic Cafe, 2013), Undertale (Fox, 2015), and Papers Please (Pope, 2013) all feature Choice through performance. The Stanley Parable requires avatar movement to make a choice. In the latter two, the player must use the interface to “perform” the act of the choice they wish to make. For Undertale it is done through combat, and Papers Please utilizes the passport control booth interface.

FIGURE 3.8: An example of Progression through Choice through Se- lection in The Wolf Among Us. The player progresses by selecting a choice from the menu on the screen. 50 Chapter 3. The Progression Model

FIGURE 3.9: An example of Progression through Choice through Per- formance in The Stanley Parable. The player progresses by moving their avatar through one of the doors, effectively making a choice by performing it.

Progression through Scripted Scenarios refers to mechanics within scripted events where the player must perform a designated action in order to progress the story. This is often presented through interactive cut-scenes or moments of narration that require the player to follow a strict, pre-scripted interaction. This establishes a clear role for the player and stipulates that they should follow the interaction the designer has implemented closely in order to progress. The Wolf Among Us (Telltale Games, 2013), Life is Strange (Dontnod Entertainment, 2015) and Heavy Rain (Quan- tic Dream, 2016) allow the player to progress the narrative through use of quick time events (QTEs), where they are prompted to provide input, such as pressing a button, in order to progress the scene. The events or outcome of a scene may vary depending on the player’s performance during the event i.e. which buttons they pressed and their reaction time. Progression through Discovery refers to mechanics where the player must lo- cate story content in order to progress the story. In many cases progression through discovery is achieved with other game mechanics centered on search, exploration, and investigation. For example, Her Story (Barlow, 2015) has players progress the story by providing a search engine interface where the player was given visual indicators to track their progress. Gone Home (The Fullbright Company, 2013) has players progress through navigation and interaction with objects that included story content. Two other games featured Hidden as a substructure for select scenes. The Novelist (Hudson, 2013) featured scenes where the player must uncover pieces of the story before being allowed to progress. The Hidden structure and the discovery mechanics unlock/reveal the choices that then progress the story. The Wolf Among us (Telltale Games, 2013) featured a mandatory investigation scene where the player 3.2. A Descriptive Model for Narrative Progression 51

FIGURE 3.10: An example of Progression through Scripted Scenar- ios in Papers Please. During the scripted event that occurs (an NPC jumping the fence) the player must choose to shoot the NPC or the "man in red". Successfully completing this scripted event (by shooting one of them) is necessary to continue with the game, while choosing to shoot the man in red can result in an immediate ending to the game. was implicitly given the experience of exploring a Hidden structure to gain information before progressing the story. Doki Doki Literature Club (Salvato, 2017) treats its own code as a space in which the player can search for new story content. Manipu- lating and deleting certain files will allow for different scenes to be unlocked, and is required to progress the game. Progression through In-Game Systems refers to mechanics where the player must interact with in-game systems, such as combat or resource management, in order to progress the story. There were three notable sub-types of this progression mechanic. First, is Progression through Task Completion. This progression type in- volves explicitly assigning the player a task where story progression is contingent on its completion. This often includes traveling to specific locations, character interaction, combat challenges, item location, etc. that requires interaction with a separate existing in-game system. Final Fantasy 15 (Enix, 2016) makes heavy use of this story progression mechanic as do To the Moon (Freebird Games, 2014) and Persona 4 (Atlus, 2008). In Final Fantasy 15, story progress in certain cases requires defeating a certain number of enemies or a designated boss. In To the Moon, task completion requires traveling to a designated location. This is the primary means of narrative progression and source of interaction within the game; and an example of how Pro- gression through Task Completion can add interactivity to Linear stories or story segments that would otherwise feature no interaction. Other subtypes were more specific to a particular system type. Resource management was used for progression in Papers Please (Pope, 2013), Black Closet (Hanako Games, 2015), and Long Live the Queen (Hanako Games, 2012). As an illustrative example, in Long Live the Queen 52 Chapter 3. The Progression Model

FIGURE 3.11: An example of Progression through Discovery in Her Story. The player must search for keywords in the database and watch the videos that come up as results. Progression is contingent on finding new keywords in the videos. the player is required to increase their character’s skill levels in order for them to progress in the story. A skill level is gained by deciding what the character studies over the course of the week, time being a limited resource required to do so. Cer- tain branches of the story can be accessed or missed automatically if specific skills are or are not above a designated level, rather than by choice. The player is made aware of this through skill check notifications during scenes. Progression through Combat was only observed in Undertale (Fox, 2015), where strategies and outcomes of battles influenced its branching endings.

Goal Directed Mechanics

Each of the four mechanic groups presented here have strong affordances for a specific set of goal directed behaviors. Progression through Choice directs the user towards decision making and evaluating and comparing projected consequences. Pro- gression through Scripted Scenarios requires the player to follow a script, making their performance in following said script paramount. Progression through Discov- ery is a set of mechanics all focused on exploring and locating story content. Progres- sion through In-Game Systems requires the user to think about progression in terms of their interaction with dynamic systems. Thus, each type of progression mechanic can afford the user with different, but strong indications of the manner in which the designer expects them to reason about their progression through the story, and, more generally, about their interaction and impact on the story world. Further, by introducing a specific type of progression, the designer is not only indicating their intent, but also constraining the behavior of the player to a specific goal directed behavior. As an illustrative example, Her Story (Barlow, 2015) features a simulated 3.2. A Descriptive Model for Narrative Progression 53

FIGURE 3.12: An example of Progression through Resource Manage- ment, a type of In-Game System, in Black Closet. The school and council have reputation gauges, and the girls have energy gauges. How full or empty these gauges are will determine what types of choices the player is allowed to make. computer desktop where the player is able to interact with a ﬁctional video archive through a search engine style interface. This constrains the player to searching for keywords in order to ﬁnd the next piece of the story. This quickly communicates that search is the only progression interaction available to the player.

3.2.5 Interlude: Patterns of Structure and Progression Mechanics

A few strong patterns emerged for each of the individual connected graph structure types. Branching structures were always featured with Progression through Choice. This is not unexpected, given that a Branching structure lends itself well to afford the player the option of exploring different actions for the same set of narrative events. Foldback, likewise, is always featured with Progression through Choice, but it seems to feature more variety in terms of both progression and structure composition. Specifically, it featured segments of Progression through Discovery afforded by a Hidden structure. This can be seen in the investigation scenes in The Wolf Among Us, where the user is allowed freedom to explore an environment but can only progress once a specific observation has been made. Similarly, the search for character related items in The Novelist, used to unlock choices to progress, shows an example combination of both Progression through Discovery and Choice, where the latter is dependent on the former. Similar to Foldback, Broom was always featured with Choice. It also heavily featured In-game System progression, specifically Resource management. When considering that Broom is a composite structure that features a primarily linear structure which branches for endings, it is not surprising that it is seen featuring In-game 54 Chapter 3. The Progression Model

FIGURE 3.13: An example of Progression through Task Completion, a type of In-Game System, in Final Fantasy 15. The player must complete a series of updating tasks in a quest chain in order to progress to the next part of the game’s story.

System progression, as this can provide sufficient variation in interaction within the story to engage the player during its Linear segment, while exploring long-term consequences in the Branching endings. Undertale, for example, features a Linear story structure for most of the game, but the player’s actions and treatment of characters, specifically during combat situations, during the Linear section will play a large part in determining which path, and which of the Branching endings, they will be allowed to explore. Task completion was featured in both games that featured a Linear structure (Final Fantasy XV and To the Moon), but differed in both variety and complexity. As an illustrative example, in Final Fantasy XV the player is presented with a large variety of tasks and quests, such as collection quests (defeat X amount of enemies and collect items that are dropped once they are defeated), battles (complete a battle with or defeat a particular enemy), and going to specific locations. Whereas To the Moon primarily required going to locations and activating puzzles. In-Game Systems is the broadest category in terms of mechanical variety, and there are multiple ways of accomplishing the translation of conventionally non- narrative game mechanics to story progression. Resource management gameplay, as a determinant of story progression, featured prominently. Time management was featured in Long Live the Queen, Persona 4, Black Closet, and Papers Please. In both Long Live the Queen and Persona 4, the player has time periods throughout the day in which they may choose an activity to partake in. These activities raise the player character’s stats which will, in turn, affect how they are able to progress the main story. In the case of Persona 4, leveling social links and becoming closer to characters will affect their efficiency in battle and unlock additional side and main story options and content. Papers Please and Black Closet mix time management with the balancing of additional resources such as income and stamina, all of which 3.2. A Descriptive Model for Narrative Progression 55

FIGURE 3.14: An example of Progression through Combat, a type of In-Game System, in Undertale. The player is able to make a number of choices in the combat menu that will determine the outcome of the battle and inﬂuence the ending of the game. will affect whether or not the player is able to make certain decisions and progress down their respective narrative branches.

3.2.6 Interlude: Perception of Structure

Identifying story structure in a narrative game can prove a difﬁcult undertaking for researchers, as well as players, as the presence (and presentation) of progression mechanics can imply structural properties without them being present. For example, the presence of a choice can imply that there will be branching outcomes simply because there is a decision with different consequences to be made before the story can progress. Thus, it stands to reason that a player will, if presented with a choice, expect the story to have some type of a Branching structure. In this sense, by offering the player a choice the designer is establishing this as a common ground. Thus, if Progression through Choice is used in combination with a non-Branching structure, it can be expected that the player will expect their choices to have effects on what they think is a Branching story due to the presence of a choice. However, the structure does not support this as it does not allow for any variation in terms of the ordering of narrative events. This violates the player’s expectation and understanding of the design. Awareness of this perception effect, as a possible result of the choice of a progression mechanic for a particular structure, is important, as it serves the purpose of establishing how the designer has built ways for the player to understand how to progress the story. More generally, this perception effect can apply to many combinations of structure and progression mechanic types. 56 Chapter 3. The Progression Model

FIGURE 3.15: An overview of all games in the sample. Each game in the sample was categorized in terms of its structure and narrative progression mechanics respectively. Notable, strong subtypes for Choice and In-Game System mechanics are categorized as well.

How a structure designation is determined by players has not been established in the literature. Individual differences, such as previous experience, genre knowledge, expectations, and what the player will and won’t count as a part of what they perceive to be the main story, or their version of it, will likely be among the factors that will impact structure perception. Further, the player’s own narrative might not include pieces of the story as it was intended, or include salient moments deemed relevant to their interpretation and understanding while not being a part of its designated story content. Examples could include side-quests and emergent system interaction. As a result, the structure types described in this chapter, while valid and supported through being consistent with previous work and findings in the field, might be seen and interpreted as being applied incorrectly to games by various players who might have experienced the games differently than the researcher whose experiential data was used to analyze the games here. It is not the purpose of this study to dictate what structure a game’s narrative does or doesn’t have, for it is against its purpose and theoretical grounding principles. Here, it is used to illustrate how interaction dynamics, and design of interactive narratives, can be described through the overarching structures and sub-structures of particular narratives, as perceived by one researcher. This model is meant to serve as a contribution to the broader discussion of how the field of interactive narrative, which is currently lacking a common 3.2. A Descriptive Model for Narrative Progression 57 vocabulary, can describe and consider interactive narrative design from various an- gles and point of view. Finally, the strong patterns of how structure types and progression mechanics are paired imply that there exists design conventions and best practices in regards to how to structure narrative progression for particular structures. Additionally, it may imply that some structures afford and pair better with particular kinds of progression mechanisms than others. In either case, it does imply that designers need to consider which progression mechanics are most suitable to the structure they plan to use, and if that mechanic is recognizable to players as being a mechanism that progresses the narrative.

3.2.7 Interaction

This category includes elements that relate to how a player is performing an interaction, and what type of information is delivered to them in return. This is meant to refer to interaction on a level similar to Game feel (Swink, 2008), and be very granular. It includes input, input mapping, and feedback. Note that the presentation of all of these elements is kept in a separate category. In the context of this work, these elements are discussed in terms of how they relate to story progression.

Input

Input is the means by which the player is able to interact with the story. It speciﬁ- cally refers to the physical actions taken by the player in the real world that results in an action or interaction within the game world. These actions include: typing, button pressing, and mouse or joystick aiming. Input is required in order to bring about both gameplay and narrative progression, and will result in a mapped action or execution of a mechanic depending on the mapping, situation, and the input performed. An example is the act of pressing the “w" button in The Stanley Parable in order to move the player avatar. However, the act of “walking” that the avatar performs is a mapped action and not input.

Input Mapping

Input mapping here refers to an in game action, event, movement, dialog choice or any activity that is initiated by the player, through input. In other words, it speciﬁ- cally refers to the action that comes about as a result of the input performed by the player. Examples can be seen in the quick time events in Heavy Rain, where the press of a button or rotation of a joystick is mapped onto a variety of actions such as jumping or punching, and in Papers Please where the movement of a mouse is mapped to the action of handing over papers. 58 Chapter 3. The Progression Model

Feedback

The manner in which the game/narrative informs the player about the impact of their actions, choices, and other changes within the game, as a result of their input. It was observed that the presentation of the feedback, regardless of form, could highlight or obstruct the underlying structure of the story and that it can either be immediate or delayed. In this study, the focus was on narrative relevant and related feedback. Three feedback types were observed: story, progression and system feedback. Story feedback is delivered to the player in response to an interaction which has impact on the story in some capacity. It was used to inform the player that their interaction had impacted the story, had an effect on the story world, or to deliver additional content such as character or plot information. This feedback type was primarily delivered in three ways: character responses, cut-scenes, and notes. Progression feedback refers to any information that is delivered to the player about their progression through the story or quests. It is primarily used to give explicit, quantitative information about story progression, i.e. what the player has done and/or needs to do in order to advance or achieve a goal. This is often done through either numerical values, visual indicators on Maps, or progress bars. Ex- amples of Progression feedback include the quest trackers in both Dragon Age and Final Fantasy XV, the evolving story map in Zero Escape: Virtue’s Last Reward, and the video database in Her Story. System feedback is meant to convey information about game-system changes or updates to the player. In the data set, system feedback was most frequently observed in combination with progression through choice mechanics and used to imply the impact of a particular choice on an underlying game system. Examples include character relationships or attitudes towards particular subjects, as seen in Dragon Age: Inquisition, Oxenfree, and The Wolf Among Us. In these instances, interface elements were used to indicate the presence of a system, which was not always directly observable by the player.

3.2.8 Presentation

This category includes elements that refer to presentation of the narrative in terms of how it impacts the interaction, speciﬁcally those related to delivery, i.e. perceptibly of elements and information, and framing i.e. narrative framing as it pertains to diegetic framing of the interaction which might impact how the player will reason about their actions.

Delivery

Which can also be understood as patterns relating to perceptibly, refers to how games presented opportunities to interact with the story. Two themes emerged during analysis: explicit interaction and implied interaction. Explicit interaction refers to patterns of interaction where a clear, exhaustive, and direct presentation of a choice or story related interaction is provided to a player. Games observed to have 3.2. A Descriptive Model for Narrative Progression 59 had this presentation pattern often used menus, charts or dialog options to present choices, or audio/visual cues to present opportunities for interaction within the game environment. This kind of presentation seems to be more prominent for games that rely more on exploration of choice consequences, such as the dialog choices in The Wolf Among Us. Implied interaction refers to interaction possibility or choice being presented through the design affordances of the interface. Design affordances are deﬁned as a relationship between the properties of an object and the capabilities of the agent that determine just how the object could be used (Norman, 2013), i.e. the design of an object implies how it is used. Design affordances of the interface can be used to convey the range of choices and opportunities for interaction available to the player. An example of this is the search engine interface of Her Story, and the choices of The Stanley Parable where the player can go through the doors in front of them, or turn back and go through the door from whence they came, though that is not highlighted or indicated by the game’s narrator.

Framing

Here, framing refers to the story information that the designer builds into the experience that can be used by the player to reason about what actions are and are not available to them. It contains two sub-categories: diegetic awareness and diegetic location. Diegetic awareness refers to the extent to which characters that exist within the game narrative are aware of the boundary between the diegetic (story world) and non-diegetic spaces. For example, Noctis in Final Fantasy 15 (Enix, 2016) is not aware of the non-diegetic world beyond the story, nor that the story world exists as a diegetic space within that world. Thus, he has no diegetic awareness. By contrast, the Pods in Nier: Automata (Games, 2017) are aware of the player and speak with them directly. As such, they do have diegetic awareness. Diegetic location refers to the metaphorical positioning of narrative entities in relation to the boundary between the diegetic and non-diegetic spaces. In other words, whether the entity is located inside or outside the ﬁction of the game. The people you interact with in Pa- pers Please (Pope, 2013) are positioned strictly within the diegetic world of the story, thus they have a diegetic location. By contrast Monika, in Doki Doki Literature Club (DDLC) (Salvato, 2017), and Flowey, in Undertale (Fox, 2015), are both able to manipulate elements of the apparatus that support their games, such as editing ﬁles or closing windows. At the same time, both characters exist and are able to interact within the diegetic world of the narrative. Thus, both characters can be categorized as having a trans-diegetic location, or a location that exists both in the diegetic and non-diegetic. Notably, a character’s awareness does not necessarily correspond with their location. Despite their diegetic awareness, the previously mentioned pods from Nier (Games, 2017) exist exclusively within the story world and are unable to cross the boundary. This means that their location is strictly diegetic. 60 Chapter 3. The Progression Model

3.2.9 Action Set

This category is the set of actions available to the player. It contains two components: presented action set, the action set that can be inferred from the affordances of the interface and information from the story world, and implemented action set, the "actual" set of actions that the player has access to in relation to what can progress the narrative. Both have sub-components that refer to the set of actions available to the player within the story world, the diegetic action set, and the set available to the player outside of the story world, the non-diegetic action set, which could be within the apparatus or outside of it. If the mapping between the presented and implemented action sets is sufficiently overlapping, the player is more likely to perceive their set of actions to be the same as, or close to, the "actual" set of available actions, which allows them to more accurately reason about the narrative and their place in it. This is especially important in games that transcend the diegetic boundaries, and allow interaction with the apparatus to influence and progress the narrative. For example, Doki Doki Literature Club (Salvato, 2017) invites the player to manipulate files in order to progress the narrative, but the game does not explicitly articulate the exact limitations it poses on file manipulation and how that potentially impacts narrative progression. As a result, many players continuously manipulate irrelevant files in the hopes of finding new outcomes. While this may be a deliberate design choice, clear communication about available action is the key to allowing players to reason about how they can pursue their goals in game.

3.3 Discussion

The Progression model is a qualitative, descriptive model, built to contribute to the development of a common vocabulary in the field of interactive narrative. More broadly it allows interaction design for interactive narrative to be discussed more concretely amongst both researchers and practitioners, serving as an abstracted design description and a communication tool. It is built to prioritize the player’s perception of their experience, and how common ground communication between the designer and the player is established from that perspective. The primary focus of this work was examining how this has been accomplished in commercial games, and how designers of critically and commercially successful narrative games design and implement progression interaction in their games. It should be noted that there is some overlap and stronger connections between certain factors. For example Interaction and Presentation both function on a different abstraction level than the other 3, with Action Set, Structure, and Progression Mechanics operating more as a set of patterns or sequences that are formed by the elements that are discussed in relation to Interaction and Presentation. In this context, the model can be considered to be in at least 2 layers of abstraction. One is a lower tier layer consisting of the Interaction and Presentation factors, which can be 3.3. Discussion 61 used to describe more granular interaction, like input, feedback, presentation of information, and actions taken by mapping input. The other is a more abstract layer, consisting of the Structure, Progression Mechanics, and Action set factors, which considers these elements in terms of design patterns and graphs, and can be constructed using the more granular interaction elements. There are limitations to the model. A key thing to note is that the model represents results of the analysis of a relatively small sample of games. As such, the results should not be seen as accounting for all possible structures, progression mechanics, or interaction design elements in video games. For example, several structures described in previous work are not found in the data set, such as “Parallel Threads” as described by Hargood et al. (Hargood et al., 2016), and “Counterpoints” as described by Bernstein (Bernstein, 1998). In addition, the analysis is dependent on the experiences of a single researcher, and thus does not include multiple perspectives or interpretations for each point in the dataset. Further, focusing explicitly on more concrete elements of how progression interaction is designed, in the form of what elements were observable and how they were presented and interacted with, reduces and potentially eliminates much additional information from the experiential data collection that enriches and contextualizes much of the interaction design from the data. The most obvious ramifications of this is that important design considerations, such as visual- and auditory presentation of story content, feedback, input mapping, etc. are considered and do inform the analysis, but are not described in detail as part of the results. Same goes for the story content itself. Consequently, it is important that it be acknowledged that there are additional variables within these findings, and thus within the model, which were not identified or discussed, that pertain to the specifics of how progression is presented to the player, the dynamics of how progression occurs as a function of both the structure, mechanisms, and other factors that are used to allow the player to interact with the story. This is a constrained context given the rich nature of narrative, and will be considered and hopefully addressed in future work. The biggest limitation of this model is that it cannot be implemented as a computational model in its current form, as it requires qualitative analysis to be usable. However, it does feature several promising elements that, combined in a separate model, would be a much more viable candidate for a computational representation of interaction design. Of its two abstraction levels, it’s more concrete one does have an approach to breaking down interaction. The model assumes that progression happens granularly, and will be changing as new information is encountered, depending on the individual player’s mental model of the story and how the interaction design will help them impact it. It further makes the assumption that these granular elements together form patterns of interaction design that are recognizable and operate on a graph based structure that allow the player to navigate the story content. These elements together served as the foundation, upon which Progression Maps were built. Progression Maps are discussed in Chapter4.

Chapter 4

Progression Maps

Building a graph based representation of interactive narrative design will allow us to build a computational representation of interactive narrative interaction design, which in turn will enable us to create automated design support tools for interactive narratives, and provide the basis for interaction design diagnostics such as metrics. Further, such a design abstraction will help facilitate communication between designers through visualization. Progression Maps are one such model: a graph- based, descriptive computational model of moment-to-moment interaction design for narrative progression. In this context, progression is deﬁned as interaction that reveals either new story information or information that is meant to provide new context. Examples of progression include cut-scenes and dialog delivered by a non- playable character (NPC) to the player that reﬂects the player’s actions. The model is intended to capture the structure and manner of the player’s progression, as it is presented through interaction design. In this chapter I will begin by discussing the design choices made in regards to the data structure chosen for the model, as well as its elements and composition. I will then describe the entire model, starting with its nodes and properties, and describe a small example to illustrate how the nodes form a simple Progression Map for a small project made in StudyCrafter. Finally, I will discuss the abstraction level hierarchy of Progression Maps, that can be used for various analytical and design purposes.

4.0.1 Graph-based Representation

Graph-based structure representation offers several advantages. It offers a well- known and researched computational data structure, and more importantly, graph- based representations have historically been one of the most popular and widely used data structures, as well as metaphors, in representing interactive narrative since the ﬁeld’s conception. Graph-based abstractions have been used for purposes ranging from static story and plot graphs, to graphs that are dynamically assembled via planning, to design representation and metaphors used in the humanities, and by designers to discuss and conceive of new methods of storytelling. See a more detailed discussion of graph-based models for interactive narratives in Chapter2. 64 Chapter 4. Progression Maps

One reason for the popularity of graphs within the interactive narrative community is that graphs are well suited to capture ordering and connections between narrative events and design elements representing them. They allow designers to visualize the various paths of their narratives and consider story progression in terms of traversal upon satisfying node constraints. They allow for recursive representations where each node can be thought of as a graph in and of itself, allowing designers further modularity in how they chose to design their narrative structures, and enabling them to differentiate more accurately between content and interaction. Further, it allows them to draw conclusions about story content and outcomes of interactions in context of the entire structure, rather than being contained to one linear path. The bigger the graph, the more challenging it will be for human designers to retain an accurate mental model of all of its content. Visualization can assist designers in this respect, and graphs lend themselves well to that task. Finally, graphs are well known computational data structures, and allow for a straightforward conversion to a computational format, permitting the designer the ﬂexibility of constructing graphs qualitatively by hand, computationally via software, or directly via code, using one of many graph libraries available. Graph structures are therefore uniquely suited as a representation to meet the goals set forth in this dissertation. They are well-suited as a base representation for an abstraction of interaction design for interactive narratives as a domain, accessible and suitable to design communication across different stakeholders, as well as being a widely known computational data structure that can be analyzed in a transparent manner.

4.0.2 Elements of Interaction and Interactive Narrative Design

The Progression Model is currently, to my knowledge, the only model for interaction design for interactive narrative. It was developed through multiple iterations, blending terminology and theoretical approaches from design frameworks like MDA (Hunicke, LeBlanc, and Zubek, 2004) and Game Feel (Swink, 2008), with structural Hypertext approaches (Bernstein, 1998; Millard et al., 2013b), interaction models in HCI e.g. (Beaudouin-Lafon, 2000), and qualitative player experience analysis of acclaimed interactive narrative driven games (Carstensdottir, Kleinman, and Seif El-Nasr, 2017; Carstensdottir, Kleinman, and El-Nasr, 2019). The most salient elements relating to interaction dynamics were grouped together in the model into the Interaction and Presentation factors, which together represent the set of elements that symbolize how interaction is conducted and presented from the point of view of the player in an interactive narrative. For a more detailed discussion on the Progression Model, and its individual constructs and elements, see Chapter3. The elements of the model were named using common and widely understood game design and HCI vernacular. For example, Feedback, Events, Input, and Options are all familiar abstract terms, widely in use across the game design Chapter 4. Progression Maps 65 community, and are defined in the context of the maps to specifically apply to a design intent for a particular element, on an abstraction level that is slightly more abstract than that found in Swink’s Game Feel framework (Swink, 2008). The abstraction level of the Progression Model is that of a player action loop, where the player observes the game world, considers a plan of action, takes an action, and then observes the updated state of the world. Feedback and Events, both of which fall under Presentation, are both meant to capture the information delivered to the player, the story world’s state update, regardless of format. Options represent actions within the story world, and Input the physical input and mapping onto in-game actions of any kind. However, these elements are not sufficient to conceptually describe interactive narrative design. While they are generally applicable to any type of interaction design description, they do not offer more abstract structures that are needed for more complex designs common to modern interactive narrative designs and to convey what interaction is relevant for progression, such as offering a frame of what elements belong to which aspects of the design, what story content is meant to be delivered when and in relation to which specific action, as well as clearly describing more complex mechanical functions, such as timers and automated branching, which are common design patterns. In the field of interactive narrative, the concept of a narrative beat has been studied and is well known as having been one of the central units of the interactive drama Facade (Mateas and Stern, 2005). Beat symbolizes the smallest unit of dramatic action, in the theory of dramatic writing by McKee McKee, 1997. Beats act as narrative units, each consisting of an action/reaction pair between characters. Mateas and Stern, 2002. Borrowing this approach, interaction can be conceptualized in similar terms, as a unit of interaction, where each interaction opportunity is similar to a single beat or unit of interaction. Despite being smaller in scope than a narrative beat, this approach allows the interaction to be shaped, designed, and extended however the designer wishes, while containing and considering the interaction design elements within one conceptual frame. Based on this approach, Interaction Unit was defined as a super-node, with Interaction Point being the central node around the unit was organized. The choice of the term "point" here is meant to reflect the use of plot points as a terminology, a commonly used concept in interactive narrative technologies, albeit vaguely defined (Thue and Carstensdottir, 2018). Two other Pro- gression Map nodes described in this chapter, Forks and Constraints, are repurposed terms from software engineering and computer science terminology. Forks are also a reference to The Garden of Forking Paths (Borges, 1948), a short story by Jorge Luis Borges, that has served as inspiration to the field of hypertext and interactive fiction. 66 Chapter 4. Progression Maps

4.1 Model Deﬁnition and Design

Combining a graph representation with the abstracted design elements results in a computational model where the various narrative paths available to the player are clearly differentiated, with each of the corresponding elements capturing the flow of either outgoing information from the game itself, or incoming information from the player, as stipulated and constrained by the graph. As a result, Progression Maps focus on what information is presented, when, and how the interaction is structured in terms of how the player is able to influence the story progression. A map represents the full set of possibilities of player interactions within an interactive narrative, for the portion of the narrative interaction that is being mapped. As such, it can be used to closely examine individual interaction opportunities or capture the flow of an entire interactive narrative experience. Each map contains nodes that represent an interaction design element. These elements are deliberately named to describe their purpose in the interaction design in terms of their purpose within the design and the player experience, rather than their specifics for individual narratives. In this section, I define the components of the Progression Maps model in detail and illustrate how they interconnect. Further, I give a demonstration of how the maps can be used for analysis, using an example Progression Map generated from a StudyCrafter project using the StudyCrafter Design Assistant, presented in Chapter6.

4.1.1 Interaction Units

Interaction units (IUs) are the most encompassing node type in Progression Maps and the highest-level interaction node. Each IU corresponds to one interaction opportunity that is available to the player, and can therefore also be considered a container node that encompasses all design elements that belong to their interaction opportunity. IUs can be used to map out the space abstractly in terms of what interaction is present and available to the player. Its main purpose is to link together relevant lower level design elements that make up a specific interaction opportunity, that might be scattered or have presentation of relevant information deliberately delayed. An example of this is when feedback for a particular action or choice is delayed until later, but directly references the interaction when presented to the user. For example, in Long Live the Queen (Hanako Games, 2012) the player does not receive any feedback on their choices affect the titular future Queen until the game notifies them whether or not the player character has passed a skill test during non-interactive sequences. This non-interactive sequence might occur immediately, or even at the end of the story, due to the skill tests being invisible to the players. Marking the feedback as belonging to a particular interaction point during the design process, will help guide designers towards identifying what elements influence what interaction contexts. 4.1. Model Definition and Design 67

FIGURE 4.1: Progression Maps consist of three abstraction levels: Level 1 maps the Interaction Units alone as a graph, a more detailed level 2 breaks those IUs down into more detailed nodes, and the most granular and detailed is level 3, where level 2 nodes are broken down further to capture more detail.

It is important to note that some IUs may not be fully connected to a graph, if they are connected at all. This occurs when the interaction design allows the player numerous interaction opportunities, without constraining them to a specific ordering. This would often be the case for dynamic structures such as interactive narrative and drama systems built using AI and planning methods (Mateas and Stern, 2003; McCoy et al., 2011). It is particularly significant for specific types of interactive narrative genres in games, such as classic point-and-click games using Hidden structures (see Chapter3 for further discussion on structures), where the content is scattered throughout the game environment for the player to discover and assemble. In these instances, the mapping should indicate bi-directional relationships to all interaction units through a centralized interaction unit that captures how the player has entered into that interaction context.

4.1.2 Hierarchy

Progression Maps have three abstraction levels, going from high abstraction and low level of detail for each node (level 1), to low abstraction and high detail (level 3). In this thesis, almost all discussion of the nodes in the maps are of level 2 nodes. Unless otherwise speciﬁed, level 3 nodes are referred to as types. Level 1 has the highest abstraction and only includes Interaction units, as they are highest abstraction element available. This level shows at a glance the number of interaction opportunities available to the player, and how they connect, but without incorporating further detail about how they are designed. This allows a top down 68 Chapter 4. Progression Maps

Level 1 Level 2 Level 3 Properties Interaction Unit Interaction Point Interaction Perceptibility Narrative Element Format Option Trigger Perceptibility Narrative Element Format Event Cosmetic Diegetic Event Format Mechanical Diegetic Event Cosmetic Non-Diegetic Event Mechanical Non-Diegetic Event Narrative Element Feedback Cosmetic Diegetic Feedback Format Mechanical Diegetic Feedback Cosmetic Non-Diegetic Feedback Mechanical Non-Diegetic Feedback Narrative Element Fork Deterministic Fork Variables Random Fork Boolean Statements Constraint Discrete Perceptibility Systemic Variables Boolean Statements Format Input Mapping Method Narrative Element Value

TABLE 4.1: The Progression Map nodes grouped by map level, along with their corresponding properties. A corresponding UML diagram can be found in AppendixA. view at the structure of the narrative, as described in Chapter3. Level 2 nodes are non-typed interaction nodes, 7 in total (Event, Feedback, Interaction Point, Option, Constraints, Input, Forks). Each contains their corresponding types, which become full node types at level 3, and the properties associate with both abstraction levels. Level 3 nodes are typed interaction nodes, such as Cosmetic or Mechanical Diegetic Events, Interaction, Trigger, Mapping, Deterministic Fork, and Discrete Constraints. See the full list in table 4.4. These nodes can be understood as representing more specific interaction design elements and variants that are contained within the non- typed, level 2 nodes. As a result, the level 3 nodes can be understood as being expanded versions of level 2. For example, an Input level 2 node might correspond to several mapped inputs, each described through a corresponding low-level map node. Each node type has properties, which are applied to nodes on medium and low abstraction levels only. To maintain coherency and consistency throughout the maps, all medium and low-level units need to be labeled with the unique ID of their corresponding interaction unit, so their groupings can be easily identified for analysis. The levels can be applied to one or more interaction units in a map, or applied universally to all units, provided that the abstraction level for each interaction unit is internally consistent. This theoretically allows the maps to be rendered in various levels of detail depending on what units of the map is of interest to the one using it, allowing the maps to be rendered in a manner best suited for the task at hand. 4.1. Model Definition and Design 69

Level number Description 1 Described in terms of the interaction unit alone. The unit should be labeled by its unique ID, and connections with other interaction units through the Options contained within that unit should be represented with edges. All elements of the units should be obscured so that the unit can be considered to represent an individual opportunity without further speciﬁcation. 2 Described in terms of 7 nodes, with labeled types and properties as appropriate for each node. Each node is labeled with its corresponding interaction unit ID. Nodes: Event, Feedback, Interaction Point, Option, Constraints, In- put, Forks 3 Described in terms of the different types of the 7 nodes from level 2, a total of 17 nodes. Each node is labeled with its corresponding interaction unit ID. Nodes: See list in table 4.4

TABLE 4.2: Hierarchy Levels

Therefore, when it comes to choosing which level to render the maps in, the renderer will have to consider what abstraction level is best suited to the task at hand, and the preferences and priorities of those whom the map is meant to be used by. For example, while level 3 has the most amount of detail, such a speciﬁc view is not always required or needed at different stages of the design process or during testing. One possible instance would require a detailed analysis of a particular interaction for the purpose of determining the cause of a user experience issue. In this case, rendering the units at level 2 or 3 would be warranted, but only for the units of interest. Rendering all of the possible units in the map for that scene or game would be superﬂuous. For further, and more detailed, discussion on how to build Progression Maps see Chapters5 and6.

4.1.3 Node Types

Each IU can contain several different nodes. Here I will discuss seven of them: Events, Interaction Point, Options, Feedback, Forks, Constraints, and Input. The nodes each represents intent of a design element within the design, rather than being spe- ciﬁc to a particular design element or pattern. This is meant to reduce complexity for a reader, but also allow for easy transmission of design intent in the maps, which would allow the designer to quickly pinpoint an interaction of interest and focus on the interaction itself, rather than its components, which can be altered and swapped out depending on the designer’s goals. Basing the node types on intent further allows the designer or cartographer to take a step back and consider the design from a more user experienced focused perspective. The nodes can be categorized into three distinct groups: Information Presenta- tion, Player-Facing Interaction, and System-Facing Interaction. Information Presen- tation includes Events and Feedback, both of which refer to the same type of information, namely information that is delivered and presented to the player as part of 70 Chapter 4. Progression Maps

Node Deﬁnition Name Events Static, non-interactive information that is delivered to the player, regardless of their actions within the game world. Interaction An opportunity for interaction within the game world, which is Point available to the player. Option An interaction possibility that a player is given as a part of an interaction unit. Feedback Static, non-interactive information that is delivered to the player, and is directly related to, or caused by, an action initiated by the player. Forks Hidden conditional branching, where the narrative branches are automatically activated depending on a conditional check of some state or variable. Constraints Any element and condition that constrains the player’s ability to take action during an interaction, but do not automatically activate and are dependent on player action. Input The physical action taken by the player in the real world which results in an action in the game world.

TABLE 4.3: The Progression Map Node Definitions their narrative experience. Such information can include environment changes, notification, text, menus, progress bars, character behavior and dialog, and cut-scenes, to name a few. These two nodes differ only in terms of how they relate to the player, i.e. if this is information which is delivered independently or dependent on the player’s actions. See 4.1.3 for further discussion. Player-Facing Interaction includes Interaction Points, Options, Constraints, and Input. These nodes refer to elements that describe how an interaction is structured for the player, and are all available and possibly observable by the player. Interaction Point and Option combined represent an interaction opportunity and the action it affords, and are the only required elements to represent an interaction; are as a result, these are the only two elements required to form an Interaction Unit. Constraints and Input both concern the further specifications of how the interaction can be performed by the player. See 4.1.3 for further discussion. Lastly, System-Facing Interaction includes one node in the current version: Forks. Forks refer to story level branching which is not explicitly presented to the player. While the player might become aware of actions or states of the game impacting a branching moment, later on or with more knowledge of the game, this is not guaranteed. For further discussion, see 4.1.3. Each node has different types, as well as properties. Properties are descriptive characteristics, specific to each node, which capture relevant detail about its design. There are currently six properties that apply to different nodes. One example of a property is Perceptibility, which a property of Interaction Points, Options, and Con- straints. It refers to whether an element is perceptible to the player or not. This can be interpretive, see section 4.1.3 for a discussion on how this impacts Events and 4.1. Model Definition and Design 71

Feedback, respectively. Perceptibility, as a property, has two values: Hidden and Perceptible. For Option nodes, this denotes whether a particular Option is perceivable to the player, or hidden in some way and not directly observable. Progression Maps, as a model, has three abstraction levels. These are to differentiate between the level of detail required to describe the Interaction Units (IUs) in the map. The abstraction levels can be used for individual IUs, or for the entire map, which allows the cartographer to create the most suitable map for the analysis task at hand. For the purpose of simplifying the presentation of the maps in this thesis for a clearer presentation, and discussion thereof, all interaction nodes will be described from level 2, which consists of the seven node types outlined earlier. Their sub-types and properties will all be listed and discussed as being properties of a node, however, these sub-types are what is referred to as level 3 node types. Each level 2 node type divides into the sub-type nodes, allowing level 3 to feature more speciﬁc design intent and describe elements in more nuanced detail while still relating the design to the level 2 nodes. This abstraction hierarchy and how the three abstraction levels can be used is discussed in section 4.1.2.

Information Presentation

Events and Feedback nodes fall under Information Presentation. These node types both describe information that is delivered and presented to the player as a part of their narrative experience, for example through design elements like progress bars, notifications, character appearance, character statistics, and text and character dialog audio. Their definitions overlap apart from one important detail: in what causal context they are perceived to be delivered by the player. Events are defined as follows: static, non-interactive information that is delivered to the player, regardless of their actions within the game world; feedback, alternatively, delivers information to the player that is directly related to, or caused by an action initiated by the player. This is an important distinction for several reasons. The context and order in which the information is delivered to the player matters in terms of how that information is understood as a part of the story on one hand, and understood as part of the interaction on the other. For the former, sequence of story information will control how the story and its plot is understood, as context between events and sequences there events are a significant part of storytelling and discourse in particular. For the latter, it is important for the player to observe whether an action taken had any impact on the game and/or the story, and if it did, in what capacity and to what extent. This information is necessary for the player to both understand what kind of impact they can have on the story, and what the interaction paradigm set by the designer stipulates regarding the impact of actions. This allows the player to make strategic decisions about having an impact on the game world and interacting with the story. This is particularly important for progression, as the player needs to be able to realize which actions will progress the story, and when the story has been progressed. 72 Chapter 4. Progression Maps

This small difference between Events and Feedback is therefore quite significant. If the player receives information that they do not perceive to be caused by them, they will likely assume that is delivered by the system regardless of their actions. As a result, information perceived as caused by the system is less likely to be considered as relevant as the player considers their actions going forward. This can cause several potential types of issues, such as obscuring when progress in the story has been made or what it is caused by. One possible example of this is Heavy Rain (Quantic Dream, 2016). Its story is meant to progress seamlessly and branch without the player realizing, in order to provide a movie-like experience. However, the branching has been notably difficult to decipher by the average player, as the interactions that cause progressions are not consistent and the causes of branching are deliberately hidden from the player. This can cause players to take actions that have consequences they did not intend, and while it is a fully acceptable design choice, it can cause problems for specific players that are motivated by exhaustive exploration of branching possibilities when playing narrative games. If the player receives information that they perceive as being caused by them, they are more likely to consider it and factor it into future interactions as it will become a part of their mental model of how they can influence the game. This is particularly important when narrative progression in interactive narratives is considered, as it establishes the mental model of progression interaction and causal relationships for design patterns that inform how the player reasons about their interaction and the game as a whole. The difference between Events and Feedback is particularly relevant when examining what happens when the player plays through the same story multiple times. Repeated playthroughs of the same story will reveal information to the player about the underlying function and structure of the game, as they explore the game’s possibility space and its story structure. Making different choices in different playthroughs will reveal more about the conditions of the progression, the story structure, and the extent to which the game’s systems impact the story. The more the player understands about the context in which the information is delivered to them, the more they will know about what information is delivered due to their own actions, and what is not. For example, in the Wolf Among Us (Telltale Games, 2013), a player unfamiliar with the TellTale 1formula might play through the game and believe that most of the information they received in response to their actions was feedback, as the characters reacted to the dialogue choices appropriately, acknowledging the player’s choice. However, upon a second playthrough, where the player might decide on a different approach, they will see that the outcomes of various scenes remain largely the same as those encountered with their original, and significantly different, approach. This would lead them to re-evaluate what information was in fact a result of their actions, as multiple times, the information between playthroughs remained the same. As such, much of the information previously perceived to be feedback, would become an event. This kind of a process is very common for players of interactive narratives, in 4.1. Model Definition and Design 73 part due to authoring limitations. The requirement for completely unique content for every possible playthrough of a pure branching narrative would result in a com- binatorial explosion of possible outcomes. Further, each possible branch and each outcome of a branch would require hand authoring in most cases, and a rigorous consistency and quality check to maintain the narrative quality overall. As a result of the game and the narrative having a limited number of possibilities when it comes to narrative structure, the player will re-evaluate their assessment of the narrative and the information delivered to them, over the course of multiple playthroughs. In this way, if the maps are to be used to describe a playthrough, it can be used to understand how the player understands the information provided to them, and how this changes over time, and over different playthroughs. Perception is highly varied and dependent on each individual player. Thus, what one player might perceive as feedback, another might understand as events. This makes the importance of identifying how information is perceived in relation to the interaction very important in the broader scope of how player interaction is studied. For further discussion of how perception and perspective can impact the player experience, see Chapter3. Broadly, information presented to users as part of interaction design can be considered as falling along at least two axes, in terms of its Cosmetic to Mechanical impact, and Diegetic to Non-Diegetic framing, respectively. The Cosmetic to Mechanical axis denotes the type of impact the information has, which falls into being either player-facing changes which impact presentation of the story and world state, or system-facing changes which impact the mechanical world state as it relates to the gameplay systems. Specifically, cosmetic information refers to observable cosmetic changes in the environment, or other elements within the environment or interface. For example, changes in color or shape of elements in the environment, or changes in character appearance, character animations, or color on game menu buttons changing when hovered over by a mouse. Mechanical information refers to observable changes in gameplay systems, most often observable through their in-game interfaces or elements that represent aspects of those gameplay systems and mechanics within the game. For example, information conveyed through game menus, progress bars, notifications, and character statistics screens or head, up display (HUD) menus denoting the characters’ skill or health levels. The Diegetic to Non-Diegetic axis denotes whether the information presented is within the diegetic scope of the game and its story or not. In other words, whether or not the information is considered to be a part of the story world by the player. The establishment of the story world is a crucial concern for any interactive narrative designer, regardless of its format. Establishing a clear diegetic boundary for the

1TellTale Games is a game studio that established itself as one of the premier adventure game and storytelling developers in the industry. They are best known for their episodic, story focused games. These games featured very similar design patterns, structure, and storytelling styles, to the point where it became widely recognizable by players, copied by other studios, and turned into memes. The Wolf Among Us is one of many games that they produced. TellTale Games closed in October 2018 but was later revived in August 2019 by different owners. 74 Chapter 4. Progression Maps storyworld allows the designer to establish common ground between themselves and their players. The player’s awareness of the story world boundary allows them to reason about what knowledge they can apply to their interaction within the story world, and when they are impacting the story progression and when they are not. For digital games, such boundaries are often blurred. Menus, interfaces, and in- game systems, elements outside the defined frame of the story world, are often used to facilitate narrative interaction and communication, while simultaneously acting as a gateway between the player and the story world (Jørgensen, 2012). Incorporat- ing this concept directly within the framework will allow designers to communicate their intention regarding these elements in their design, which will allow quality assurance testers, playtesters, and other designers to reason about whether their diegetic framing is clear, and whether it is likely to cause any issues for players. Understanding what constitutes a diegetic framing for interactive narratives and games poses a significant challenge, and will not be discussed further in this chapter. For a more detailed discussion on diegesis in games, and how it can be analyzed in relation to player interaction, see the section where I describe how diegesis was incorporated into the Progression model in Chapter3. For reference, I will be using the conceptual approach described there to discuss diegesis in relation to the maps. For details, please see Chapter3. Diegesis is in this thesis is defined as the frame and contents of the story world that is presented to a player, confined within the software window that the interactive narrative and/or game is presented within. A diegetic boundary, like film, denotes that there exists a conceptual story world frame that distinguishes it from the apparatus. Diegetic elements exist, or originate from sources, within the story world, while non-diegetic elements come from outside of it (Kleinman, Carstensdottir, and Seif El-Nasr, 2019). For Progression Maps, diegetic feedback, or a diegetic event, refers to whether the information they represent are visible to other diegetic entities, specifically, changes that occur within the diegetic space of the storyworld, and is observable by the characters within it. For example, a player’s dialogue choices in The Wolf Among Us (Telltale Games, 2013) are observable by characters within the game as being the answers of Bigby, who is the player-controlled character. Bigby’s answers are the result of a player choice and are thus diegetic feedback. Non-diegetic events or feedback, alternatively, refer to changes that occur outside the diegetic space of the game. As a result, non-diegetic information is often presented either in the non-diegetic interface, such as Doki Doki Literature Club’s use of game menus (Salvato, 2017), or system notifications in Long Live the Queen (Hanako Games, 2012) that notify the player of failed statistics checks. To keep the iteration of the maps as simple as possible, feedback and events for non-diegetic actions outside the game which have an impact on the diegetic space of the game are not included in the Progression Maps at this time. An example of this, from Doki Doki Literature Club, is when the player is required to manipulate computer files outside the game in order to impact the progression of the narrative. A 4.1. Model Definition and Design 75 character within the game will be aware of the player taking this non-diegetic action and comment on it in the game. This particular case requires further information to capture in its entirety in the maps. For more on this topic, see discussion in the previous chapter on Progression model (Chapter3. It is important to note that the information, as discussed in this chapter, is deliberately focused on observable elements of the game, the story, and its interface, which can be directly related to and presented in context with an individual instance of interaction, i.e. an individual interaction unit. However, there is a significant amount of additional information presented to the player that does not fall into this category. This information includes design elements relating to, for example, environmental information or other sources that originate within the game world, such as environment layout, environmental animations, idle animations of characters, sound-scapes and background tracks etc.. While it can provide context to an interaction, it is excluded from this iteration of the maps. The reason for this choice is that most of this information is not presented as being directly impacting or resulting from an interaction. Information that is presented as being either consistent or repeated over significant period of time, thus indicating that it is not going to be affected by or associated to an action by the player, is considered in the context of this thesis to be meant for enforcing environment believability, character believability, or atmosphere, to name a few probable design goals. It is not clear to what extent this type of information informs and contextualizes interaction specifically, as this has not been studied empirically for interactive narratives to my knowledge, but it is clear that it does impact and inform interpretation of player experience to some degree, for example, through immersion. Previous work has studied related topics, such as the impact of non-diegetic sound such as soundtracks and audio effects on player experience (Jørgensen, 2007; Kromand, 2008; Jørgensen, 2011), and close readings for games and interactive stories informing models of player agency (Tanenbaum and Tanenbaum, 2010). Future work will require the maps to expand its definition to incorporate this information, as knowledge of the impact of these factors on interaction is increased.

Player-Facing Interaction

The most expansive of the three node categories, Player-Facing Interaction, includes the following nodes: Interaction Point, Options, Constraints, and Input. Collectively, they capture how an interaction is structured, how it is made available, whether it is observable, and how to perform it. Interaction Point and Option represent an interaction opportunity, and the action that the opportunity affords, respectively. The two nodes are the only required nodes to form an interaction unit. Interaction Point, by itself, represents an opportunity for interaction within the game world, which is available to the player. It serves as the frame for the interaction, both to serve as the center for the interaction to denote the ordering design elements, but also to describe information that is directly relevant 76 Chapter 4. Progression Maps

Node Type Type Definition Properties Event, Cosmetic Information given through cosmetic changes in the Format Feedback Diegetic environment, and other diegetic elements. Examples: Environment, Character Appearance Event, Cosmetic Information given through cosmetic non-diegetic el- Format Feedback Non- ements. Diegetic Examples: Notifications, HUD Text, Game menus, Character stat screens Event, Mechanical Information given through mechanical diegetic ele- Format Feedback Diegetic ments Event Examples: Resources, Character stats, Character abil- ities Event, Mechanical Information given through mechanical non-diegetic Format Feedback Non- elements Diegetic Examples: Check list, Progress bar, Number compar- Event isons Event, Narrative Information specific to the story and its content. Format Feedback Elements Examples: Characters, Dialogue etc. Interaction Interaction An interaction opportunity in the game world. Perceptibility, Point Examples: When a dialog menu appears Format Interaction Narrative Any narrative element required to capture narrative Perceptibility, Point Elements or game specific aspects Format Examples: Elements relating to presentation or specific game mechanic functionality Option Trigger A state that determines whether a single option has Perceptibility, been chosen by the player. Format Examples: Menu Selection, Move to Position, Object interaction, Inactivity, etc. Option Narrative Any narrative element required to capture narrative Perceptibility, Elements or game specific aspects Format Examples: Elements relating to presentation or specific game mechanic functionality Fork Deterministic Branching is decided in a deterministic manner. Variables, Examples: Conditional branching based on a Boolean Boolean State- variable, for example if a player has visited a location ments or not Fork Random Branching is decided in a randomized manner. Variables, Examples: Randomized element, like a lottery the Boolean State- player participates in ments Constraints Discrete Mechanical elements that are isolated and specific to Perceptibility, the local scope of the interaction unit and has no con- Variables, sequence outside that scope. Boolean State- Examples: Timer ments, Format Constraints Systemic Mechanical elements that are related to an external Perceptibility, game system and are determined by elements outside Variables, the interaction unit. Boolean State- Examples: Resource system-based elements such as ments, Format skills, points etc. Input Mapping An action within the game world, and within the Method, Value game world’s diegetic scope, that comes about as a result of input performed by the player. Examples: Moving towards a target, interacting with an object, drawing a sword, Giving a gift, etc.

TABLE 4.4: Node Types and Properties 4.1. Model Definition and Design 77 or framed as being a part of the interaction itself. As such, describing an interaction point generally becomes difficult, as interaction opportunities tend to be highly dependent on individual games, stories, and even genres which tend to have well established conventions to present interaction points, for example, as quest markers, a map, a list, or a set of dialog options. As such, the interaction point is left as simple as possible to allow sufficient flexibility, should the cartographer choose a specific formatting. Currently, interaction points only have two types: Interac- tion and Narrative Elements. Interaction is the opportunity itself, which describes whether the opportunity is perceivable by the player and what the format of any information relayed in relation to the interaction is. Narrative Elements are meant as a blank slate and stand for any narrative elements that are required to capture narrative, game, or interaction specific aspects of the design intent that is being described in the map. These can be included as often and in as many variations as required. These can be particulars regarding presentation, dialogue, or other content. Nar- rative elements are officially included as types for Events, Feedback, and Options, but could in theory be applied wherever the cartographer needs additional nodes to capture a specific design intent or element that the other nodes do not capture at this time. Option represents an interaction possibility that a player is provided with as part of an interaction unit. Only one Option is required for the unit to be functional, but there can be as many Options as there are interaction possibilities. For example, for a dialog menu with four dialog choices, the number of Options for that interaction unit would be four. The Wolf Among Us has a similar four choice dialog menu, but has a hidden fifth choice which is to remain silent. Therefore, the Options would be five for that interaction unit. Options can also present as actions, such as drawing a sword or navigating a player avatar to a particular location. In addition to Narrative Elements, discussed in the previous paragraph and meant to encapsulate information that is specific to the interaction design being described, Options have a type called Trigger. Trigger is a state that determines whether a single Option has been chosen by the player, such as selecting something from a menu, moving to position, interacting with an object, inactivity, and so on. In other words, the state that the player needs reach in order to communicate their intention of having that Option as their choice so that they may advance the interaction. In the previous example from The Wolf Among Us, the Option for remaining silent is triggered by allowing a timer, displayed prominently, to run out. This timer starts counting down immediately as the dialog menu is presented to the player, while a cut scene plays out in the background. This timer is an example of a Con- straint. Constraints refer any element or condition that constraints the player’s ability to take action during an interaction, but do not automatically activate (or are baked into the interaction by default) and are dependent on player action. Constraints can be either Discrete or Systemic, both defined as its types. Discrete refers to mechanical elements that are isolated and specific to the local scope of the interaction unit and 78 Chapter 4. Progression Maps have no consequences outside that scope. The Wolf Among Us example mentioned earlier features a Discrete Constraint, as the timer only applies to an individual interaction unit, and has no ramifications or impact outside of that one unit. Systemic refers to mechanical elements that are related to an external game system and are determined by elements outside the interaction unit. Example of such elements include resource systems such as skills, points, or in-game currency. Examples of this type of constraint include requiring the player to spend points in order to select an Option, needing to pay a character for information, or by requiring the player to have reached a particular skill level in order to be allowed to select an Option, for instance by needing a certain charisma level in order to convince a character to co- operate with the player’s goals. As such, Constraints might be hidden away from the player, might require conditional rules or checks, and might be presented in a variety of different formats, or a combination thereof. Input refers to the elements required to perform the physical input that allows the player to select or enact an Option, in other words, what physical actions the player needs to take in the real world, which is then mapped onto an action that is performed within the game. As such, Input can be understood as a mapping of an input onto an action, and includes input methods documenting the device that the player needs to use for providing input (e.g. controllers, keyboard, mouse etc.) and input values denoting what values are received from the device (e.g. moving the joystick up, moving the mouse onto a target and clicking). As a whole, a mapping can then be understood as an abstract action that includes the components that the player needs to perform. For example, in order to perform an action such as moving to a specific location in a game like Portal (Valve Coroporation, 2007) that falls under the first person shooter (FPS) genre, the player needs to move the mouse, which maps onto the field of view, and then push down an arrow key which will move the player avatar in the direction of the field of view. The player will then release the arrow key once a desired location is reached. Input often plays an important role in framing and informing interaction in games, and interactive narratives are not exempt. A notable example is Brothers: A Tale of Two Sons (Starbreeze Studios, 2013). In the game the player takes control of two separate player characters, the titular two brothers, and in order to do so, the player must control each brother with one hand. The game is meant to be played with a controller in order to facilitate this interaction more smoothly. The player will have to adjust to having two elements to move around the screen, using separate hands, as the player progresses the brothers’ search for a cure for the deadly cough which is plaguing their father. Close to the end of the game, the elder brother dies, leav- ing the younger brother, and the player, with an empty space, quite literally in the player’s case, as they make their way back home with the cure. The hand the player used to control the elder brother is now left without any activity, and the player continues controlling the little brother as before. This input mapping quite viscer- ally reminds the player that an irreplaceable loss has been suffered, and makes the 4.1. Model Definition and Design 79 struggles of the younger brother as the player steers him home all the more palpable, as the player navigates the path back with one brother, one handed. This is just one example of how much of an impact input can provide to an experience, and as such, it is very important that it be accounted for and considered carefully in context with any interactive narrative experience.

System-Facing Interaction

The only node categorized as System-Facing, in the current version of the Progres- sion Maps, is Forks. Forks are used to represent hidden conditional branching, where the narrative branches are automatically activated depending on a conditional check of some state or variable. As such, they refer to story level branching that is not explicitly presented to the player. Forks has two types: Deterministic and Random. The types specify whether the automated conditional branching is decided in a deterministic manner, i.e. according to a conditional statement, comparison of values, logical statement, or similar, or whether it is set randomly. An example of a Fork that is decided deterministically can be found in Long Live the Queen (Hanako Games, 2012), where the game will perform character skill checks during narrative scenes to determine branching. The player is notified of this through Mechanical Non- diegetic Feedback, specifically through notifications of Skill Check being successful or a failure. The presence of this feedback does indicate that there is an underlying functionality which is reacting to the player’s actions, in this case, their choices of classes that the titular future Queen must attend. In this particular game, the Forks are conditional on the character skill check and made noticeable, but that is not required to be the case. Examples of a completely hidden Fork include randomized assignment to a particular team within a game, or assignment to a particular feedback depending on answers to a previous action. Forks, despite being defined as hidden from the player, can become perceivable to the player. This can happen either upon observation of a playthrough, or several playthroughs, where the player can observe outcomes of choices and how they lead to different outcomes. For instance, a player might become aware of certain actions in the game impacting whether or not they are given access to further dialog choices with a particular character. As such, Forks can be observed and accounted for by players, without being explicitly presented, visually or otherwise.

Properties

Properties are descriptive characteristics of nodes that capture distinguishing details of the interaction element. An example of properties is the Perceptibility property for Option nodes, capturing whether or not the element is perceptible to the player, which is also a property of Interaction, Triggers, and the two Constraint types nodes. The property has two values: Hidden and Perceptible. This means that a node with this property can be either perceivable to the player, or hidden in some way and not 80 Chapter 4. Progression Maps

Property Deﬁnition Example Values Name Format Information sources that de- Video Cut-scene, Dialogue, liver story related content. Audio, Animation, Narra- tion, Environment changes, Menu choice. Perceptibility Whether an element is per- Hidden, Perceptible ceptible to the player. Variables Elements that determine Location, Previous IUs com- which branch of the fork is pleted, under certain condi- activated. tions, Character stats Boolean State- The logical conditions that if(condition) {Do(act)} ments use variables to determine which branch is activated. Method The type of input device, Mouse, Keyboard, Game or format of input, that the Controller, Touch interface, player provides the game. Motion interface. Value The value provided by the in- Mouse click, Mouse move- put device to the game. ment, Keyboard key pressed, Keyboard key released, Game Controller joystick movement, Game Controller button press, Touch location, Gesture recognition, etc.

TABLE 4.5: Properties - Definitions and Example Values directly observable. Another example of a widely applied property is Format, which captures what type of information sources are delivering story related content. It has one of the widest varieties of values, ranging from video cut-scene, audio, and narration, to environment changes. New properties should be added by the renderer should the need arise, as the properties used in the maps (see the full list of currently defined properties in table 4.5) are only specified for the most generalized elements needed to capture an interaction design and perception thereof.

4.1.4 An Illustrative Example

For a more detailed example, let’s consider a short and simple part of an interactive narrative where the player has to select a dish to order from a waiter at a restaurant. The player is given a choice of one of three dishes. If the kitchen has fish available, the option of having fish is made available to the player, but the player will always have a choice of either pasta or chicken, in addition to the fish. If a fish is selected, the waiter might comment on the fish being fragrant and ask the player whether they would like to reconsider their choice. This particular scenario was implemented in StudyCrafter and the Progression Map was automatically generated using the StudyCrafter Design Assistant (see Chapter6 for details). The Progression Map of 4.1. Model Definition and Design 81

FIGURE 4.2: An example of an Progression Map, automatically constructed from a simple interactive narrative built in StudyCrafter (see Chapter6 for details). The simple scene has a waiter asking the player character what they would like to eat, and showcases each of the second layer nodes. Due to space constraints the picture shown is not in sufﬁcient quality. For a better-quality rendering, see AppendixB 82 Chapter 4. Progression Maps

FIGURE 4.3: A still from the scene as it is presented to a player in StudyCrafter. This is the layout that corresponds to the map shown in 4.2. The player character is the male presenting character in the blue shirt to the left of the scene, sitting down and facing the waiter. the scenario can be seen in figure 4.2, and the scene, as it is initially presented to the player, can be seen in figure 4.3. The scenario starts with a chain of Event and Input nodes. Specifically, it starts with an Event node, representing the waiter asking the player character what they would like to order. The player is required to provide input, shown in the Input node to be a mouse click, to progress. The following Event node has the player character ask what the waiter would recommend, and again a similar Input node follows and requires a mouse click to advance. The final Event node of the chain shows the waiter telling the player about the three possible dishes. Following this is the first Interaction Point of the scene, where the player is presented with a choice from the menu. Two Options are presented to be always available to the player, pasta, and chicken. The third Option, presented in the map as being first from the left, is subject to a constraint. The Constraint node stipulates that the following Option requires the variable fish to be True in order to be displayed. All three Options have corresponding Input nodes, as all three have different locations on the screen, however, all Input nodes require a mouse to move to the target location, i.e. the part of the menu that has a button corresponding to the Option, and click on that target button once in range. As shown in the map, all three Input nodes can potentially lead to the same Feed- back node. Both the pasta and chicken Options will give the player the same Feed- back node, where the waiter commends the player character on their great choice. For the fish Option, however, there is a Fork that randomly determines what Feed- back node is presented to the player. The Feedback node, shown in the map to be the 4.1. Model Definition and Design 83 left one after the Fork, has the waiter ask the player character whether they’d like to reconsider their choice due to the fragrance of the fish dish in question. The other possible Feedback for the Fork is the same for the pasta and chicken Options, where the player character is commended for their great choice. Both Feedback nodes lead to separate Input nodes that both require a mouse click to advance the player to the end.

Chapter 5

Qualitative Evaluation of the Communicative Capabilities of Progression Maps

Models of interactive narrative design, computational or otherwise, should be usable for design communication if they are to be used directly as design assistance tools, including being suitable for designers to build by hand for creating layouts and drafts of interaction design at any stage of the design process. In this chapter I discuss why it is important to factor in the perspective of the cartographer, how it affects the maps they construct, and how awareness of it can help establish a common ground for design communication. I then report on an exploratory study evaluating the communicative potential of the Progression Maps. The study had participants describe the interaction design of the same parts of an interactive narrative game using the Progression Maps. The study results indicate that the maps are capable of capturing critical narrative paths reliably across participants, while also communicating the perspective and emphasis of the cartographer.

5.1 Perspective

It is important to recognize that analysis and communication about interaction and dynamics are subject to human biases and bound to a particular perspective. Pro- gression Maps are no exception. In acknowledging this, we are not judging the maps as being somehow incorrect, not capturing the design, or unusable, but acknowledging that they reveal a snapshot of a perspective of a stakeholder in the experience. Recognizing this subjective view as being inherently a part of any kind of description and communication about design allows for more nuanced analysis, and for more in-depth comparisons of the various maps, such as the structural analysis of Long Live the Queen (Hanako Games, 2012) in this chapter. Perspective and perception are important considerations in the study interaction dynamics, in any form. Similar to how a choice of phrase indicates a point of view, or a stance, of the one who expresses it, the choice of interaction design and resulting dynamics indicates a perspective on part of the designer. The same applies to Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 86 Progression Maps the player who experiences and interacts with it, and then attempts to describe it. A player will perceive interactive narrative and interpret interaction in a manner that might not match that of the designer. Their description is bound to their own perspective, and what they choose to include in this description is indicative of what they perceived as being important and relevant to their overall experience. Therefore, the study of interaction design in interactive digital narratives requires awareness and consideration of several different perspectives, as elements of the system can differ greatly depending on who is meant to capture and describe them. Capturing interaction design from the system level will differ if the perspective is that of a designer who is focused on dynamics and what they believe the player will see, versus that of a programmer, who might not be aware of the overall design and lacking knowledge of the visual design elements or animations, but having full knowledge of all possible actions and outcomes. Capturing interaction design from the perspective of a player is more complex, as there are at least two possible perspectives to consider: that of the player, and the cartographer. If the two are one and the same, that would convey the most accurate description of what the player believes they are interacting with, documenting what they perceive to be relevant and present for them to consider as a part of the interaction. If the two are separate, and there is an external observer that does the mapping, it is from their perspective and their reasoning about the player’s experience that the map is created. This can be both a positive and a negative: the cartographer might see elements that the player missed and thus accurately identify usability and player experience issues but might not catch what the player considered. These different perspectives might be more prominent if the maps are done by hand. However, it is important to note that procedurally deriving Progression Maps from an existing narrative artifact, does not eliminate the problem of perspective. The method of map construction is subject to the perspective of the one who implemented the procedure used to match Progression Maps to the representation of the artifact that is meant to be mapped. Perspective cannot be avoided, just as descriptions and abstractions will always, in their nature, be reductionist. The perspectives previously discussed are not an exhaustive list of the different perspectives that play into the interactive narrative design. There are many more. Recognizing the multiple perspectives of different stakeholders in describing and communicating about the design, from story writers to back-end programmers, is a ﬁrst step towards establishing common ground between different roles. As a result, the ﬁrst step of building a Progression Map, the cartographer should always identify their goals and motivation, and acknowledge their own perspective as playing a part in their mapping process. These factors impact what the cartographer will deem relevant to the design, and as a result what will be incorporated into the mapping. 5.2. Study of Progression Maps Suitability for Design Communication 87

5.2 Study of Progression Maps Suitability for Design Com- munication

In order to establish the communicative ability of Progression maps for interaction design, a structural analysis study was conducted to explore whether the maps were specific enough to allow a small team to describe the same interaction design in such a way that it could be recognized and discussed. More specifically, the goals of the study were to check whether the maps a) were used similarly to describe the same salient game loops and/or critical narrative paths and elements in order to show the communicative power of the maps, b) were readable and understandable across a small analysis team when constructed by hand, thus showing consistency in human interpretation and use of the maps, and c) whether they reflected previous experience and background of the individuals on the team. In this section I discuss the study design, methodology, and analysis plan, as well as the pilot that was conducted to test the methodology, study materials, and analysis methods.

5.2.1 Methodology

Narrative Game Selection Criteria

For the purposes of this study there were a specific set of constraints that the games would need to meet: simplicity, reliable game walkthroughs, and element variation. Participants in the study are required to build Progression Maps of the interaction design of the game by hand. In order to build the maps, the participants would need to either draw them on paper or use drawing or diagram software. In order to limit the time required of each participant, only a part of the game is considered for mapping. Therefore, the chosen narrative game has to not only fulfill and match the aforementioned constraints but match them for the entire sub-section of the game considered for mapping. To maintain consistency and ensure that all participants map the same exact parts of the narrative, participants were required to follow the same walkthrough. Narra- tive games, like most conventional games, often have established fan communities that work together over longer periods of time in order to fully map and explore everything the game has to offer. For narrative games, this is often the full mapping of the story’s narrative content and what paths lead to what outcomes. Choosing an established narrative game with a community that has completed a full mapping of its content would therefore be the most desirable, as those games would already have established and tested walkthroughs available on community-run websites. In order for walkthroughs to be followed reliably, the interaction design needs to be sufficiently simple to allow reliable replication across all participants, while at the same time offer variation in terms of both mechanics and presentation of information across the entire segment of gameplay. For this to hold, the interaction design needs to be explicitly presented to avoid confusion. As a result, games that feature Choice Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 88 Progression Maps through Performance progression were excluded, and preference given to games featuring Choice through Selection. This is a deliberate choice. The goal of this study is to evaluate the communicative function, rather than the map’s reliability when it concerns how consistently and reliably it captures the same content across different individual cartographers, which is the subject of future work.

Participants

The study had three participants, each familiar with the Progression Maps model. The participants had differing levels of experience with narrative driven games: One an expert narrative game player, one of medium expertise, and one with low expertise. All were experienced video game players and had knowledge of narrative and game design patterns. Each participant’s approach to the mapping also corresponded to different roles within a design team, one as a designer, one as a playtester, and one as a programmer. The same set of participants participated in the both the pilot and the main study. The participant sample was not expanded, as participant recruitment proved a challenge and ended up not being viable. This was due to the extensive time commitment and effort that participation in the study required, and compensation not being seen as sufficient. The reason for this is that the study required a significant time commitment of its participants. Participants would be required to both play an extensive part of a game and then map them, likely requiring several hours of time, in addition to requiring the participants to play the game repeatedly. Further, participants would be required to participate in in-person group sessions with other participants to justify and discuss their maps in detail. These meetings would further require several additional hours of time commitment. The small set of participants does limit the study’s impact, as three participants is not sufficient to make any substantial claims about its results. The study is in part a qualitative usability study using software design walkthrough, and while it not far off the acceptable number for a usability study, which is five participants (Nielsen and Mack, 1994), it is still too small to make any generalized claims. However, it is sufficient for an exploratory study to show possible impact and indications of the extent of the readability and usability in terms of communicative power, in order to evaluate its viability for further studies. The addition of more participants would have allowed for a more comprehensive look at how the maps could have been communicated across multiple different teams, and/or larger teams. This will be explored in future work.

5.2.2 Pilot Study and The Interaction Cartographer’s Manual

A pilot study was run before the main study, in order to test both the study protocol and the analysis approach. In addition, it was meant to test and improve the Inter- action Cartographer’s Manual (ICM) usability for the mapping process. The ICM 5.2. Study of Progression Maps Suitability for Design Communication 89 contains all deﬁnitions relating to the Progression Map model, as well as mapping rules such as rules regarding naming and numbering of nodes, potential ordering of nodes, their hierarchical connections, and other resources for the mapping process.

Narrative Game: The Wolf Among Us

The Wolf Among Us (Telltale Games, 2013) was chosen for the pilot study. The game is an episodic narrative-driven mystery and adventure game, played from a third person perspective. The player takes control of Bigby, the big bad wolf from fairy tales such as Little Red Riding Hood and the Three Little Pigs, who serves as a sheriff in a underground community of fairy tale and fable characters in late twentieth century New York. The game has a Foldback structure for main story events, but features short narrative sequences with Hidden structure that correspond to investigative scenes, and short Branching character dialogue sequences. It features three types of progression mechanics: Choice through Selection for main story events and character dialog, Progression through Discovery for its investigative scenes, and Scripted Scenarios where the player needs to provide specific input via quick time events (QTEs) in order to progress. Its Choice through Selection mechanics are either done through four to five Option Interaction Points that are constrained with timers, which is enforced during the interaction by the characters involved in the scene being presented as becoming visibly more agitated or uncomfortable the longer the player remains in- active. One of the options is always inactivity, which is not explicitly presented. The player is notified of this interaction pattern in the first interaction through System Feedback, in the form of a HUD notification. The Wolf Among Us fulfills all three criteria laid out. It has a well-defined Choice through Selection progression mechanic that is explicitly presented, an established community with walkthroughs available, and features variations in terms of feedback presentation and time constraints placed on the choices. It features a Foldback structure overall, which indicates minimal branching with high variation in feedback. Further, The Wolf Among Us has a well-known and established interaction design style, shared across most of its developer TellTale’s catalogue of narrative- driven games.

Methodology and Analysis

Each participant was required to produce an Progression Map using the third and most detailed abstraction level of the Progression Map hierarchy (see Chapter4 for details), meaning they were instructed to use the third level group of nodes in order to create the map. These nodes were described in the ICM. The participants were required to work independently, and not consult with each other or reference individual mapping choices they made. No discussions of individual maps or layout took place until after all three maps were completed. Each participant was required Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 90 Progression Maps to play the game using a mouse as an input device and play the game on a personal computer, either a desktop or a laptop. This was done in order to keep the input devices consistent across participants. Participants were instructed to create maps from the perspective of a player that had played the part of the game being mapped at least three times previously, to account for knowledge of branching points for dialog and action options. Further, they were instructed to include all game mechanic interactions encountered. For the Pilot study, it was decided that participants would map the entire Pro- gression Map the first three Interaction Units that they perceived after starting the game. Participants would most likely perceive their three first interaction units as the first three dialog interactions the player has as Bigby with Mr. Frog, as these are the first three actions the player is presented with in the game. If an element in the ICM did not capture important interaction elements, in the view of the participant, they were instructed to define a Narrative Element to capture the interaction in question. These elements were added to the maps exclusively for coding purposes. This setup was chosen to both examine whether it would be viable to do such a detailed and extensive mapping for the main study, as well as to explore the Wolf Among Us’s variety of Event and Feedback presentation for each different Option. After completing the mapping, the participants assembled in a group, and all three maps were analyzed and compared. The analysis process used was a combination of software design walkthrough, augmented with cognitive walkthrough elements (Polson et al., 1992; Blackmon and Bainbridge, 2004; Nielsen and Mack, 1994). This approach was chosen specifically due to the similarities Progression Maps share with software modeling languages such as UML (Rumbaugh, Jacobson, and Booch, 2004) meant to visualize software architecture design. Progression Maps are similarly meant to represent an abstracted representation of the interaction design as it is implemented within the game. Using a software design walkthrough approach allows the participants to walk through all three maps together, and to compare and contrast them in the context of the game segment that they are all meant to describe. Augmenting this process with a cognitive walkthrough elements means that participants were asked questions about the process they went through as they used the Progression Maps as a model to describe specific elements, in order to evaluate whether the participants found the model easy to use, whether it was in fact capturing what they meant to, and where it was lacking. Thematic analysis was used to identify themes and consistent descriptions for Narrative Element to determine if new nodes were needed and whether definitions were sufficiently clear. This was used to augment the results from the cognitive walkthrough element further. First, the participants laid out their individual maps for each of the three units. They then directly compared the use of different nodes and how they were interconnected and ordered by their respective cartographer. After completing this first 5.2. Study of Progression Maps Suitability for Design Communication 91 step, comparisons were listed, and participants discussed each disagreement or am- biguity in detail. Each participant was required to justifying their own mapping choices and then compare their choice to that stipulated and described in the ICM. At this point, all Narrative Elements used to capture various interaction elements were analyzed individually and then as a whole. Thematic analysis was used to group narrative elements based on the design phenomena its respective cartographer meant to capture . After this process was complete, the results were used to update the Progression Maps representation (see Chapter4, adding new node types and properties. The updated version of the Progression Maps was then used to update the ICM, and included further clarifications for naming conventions and more detailed definitions of existing node types. Narrative Elements had originally been included as a blank node for mapping purposes only, in order to allow for flexibility and to identify gaps and perceived limitations of Progression Maps as a representation. The node was meant to serve as a blank slate that could be used at will, should the participants want to modify and add elements. Adding such a node would allow them to create or modify nodes as they saw fit when they did not find the definition of the existing nodes suitable or applicable to what they wanted to capture about their target artifact. The participants reported Narrative Elements as being highly useful, and it was therefore officially added as a third level abstraction node type, accessible as a type for second level nodes. The analysis of these node types further introduced Constraints as a node type, and helped refine of the definitions of Forks, Input, and Interaction Points. The methodology and analysis methods for the main study were updated to reflect the findings of the pilot. The main shift in the methodology was moving away from full mapping for a particular game segment, where every Option of every Inter- action Unit would need to be captured and described. Participants reported that the size of the maps were difficult to manage if using exclusively third level nodes for the whole map. Instead, it was decided to focus on a single game walkthrough, as if the maps were capturing a single playthrough from a player. For analysis, it was decided that thematic analysis should be applied structurally to identify common graph patterns and node ordering, especially where Narrative Elements, Events, and Feedback were prevalent.

5.2.3 Structural Analysis Study

The aim of the main study was to study whether the maps were used to describe the same or similar central elements of the design, whether they were understandable when individually created maps, created by hand, were used to communicate across a small team, and ﬁnally whether the maps communicated something about the cartographer’s perspective, such as previous experience and background/role on the team. Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 92 Progression Maps

The study used the updated ICM, with all additional nodes and reﬁned deﬁ- nitions. Further, another game, Long Live the Queen (Hanako Games, 2012) was selected in order to ensure that any conversation and comparison of maps of The Wolf Among Us would not affect the new round of Maps.

Narrative Game: Long Live the Queen

Long Live the Queen (Hanako Games, 2012) is a branching visual novel and role- playing game that follows the titular Queen Elodie, as a young princess in training, where the player must keep her alive until she turns 15 years old and is able to be crowned queen. The game features story segments which the player reads through, which occasionally feature Choice through Selection progression. Further, these segments can also feature automated branching that is dependent on whether Elodie’s various statistics meet specific requirements. This branching can lead to an end to the story where Elodie is killed if her statistics are not high enough. Elodie’s statistics, representing her knowledge and skill set, and mood, can be impacted through resource management mechanics, specifically time and mood management. The player is given control of Elodie’s schedule for weekly lessons and weekend activities. Her weekly lessons including selecting from topics like econ- omy and trade, military and foreign affairs, physical skills such as reflexes, music, magic, and court manners, to name a few. Based on those lessons, the player is able to raise Elodie’s statistics, which will impact how she handles various issues during the story segments. The player is notified of whether Elodie passed various skill checks during these segments, both to indicate whether their level was satisfactory to proceed, but also to indicate the existence of alternative paths through the story. Similarly, for Elodie’s mood, the player is allowed to choose a weekend activity that alters her mood. Her mood is represented to the player as four emotion axes, representing eight different moods total in addition to three moods that appear under specific circumstances. The state of Elodie’s mood will impact her performance during her weekly lessons. For instance, when learning Royal Demeanor, she will get a performance boost if she is in a "yielding" mood, whereas she gets a penalty to her performance if feeling "willful". For class and weekend activity selection menus (the framing for the game’s resource management gameplay), where the player is given many interaction opportunities, participants were instructed to only map the interaction performed, omitting any other options. However, this did not apply to dialog or action choices that were mapped in full. The game features simple input and interaction design during its story segments, allowing for simplified structural comparison when contrasted against to The Wolf Among Us in regards to story content, but features more complex mechanical and interface elements that are required for resource management gameplay. Further, its feedback differs from that of the Wolf Among Us, providing a variety of different formats, timing of, and means of delivery. For example, Long Live the Queen does not feature time constraints, nor share the same overall structure type as The Wolf 5.2. Study of Progression Maps Suitability for Design Communication 93

Among Us, being Linear as opposed to Foldback. These structural differences are important, as they help minimize conceptual overlap between the maps that might result from similar interaction designs. This ensures that the maps require signiﬁ- cantly different considerations when they are constructed. The games are also similar enough that the changes to the ICM from the pilot study would be relevant in the full study. Thus, Long Live the Queen provides a varied and rich action space, while maintaining a similar level of interaction design complexity as The Wolf Among Us, making it a suitable game for the main study.

Methodology

As in the methodology described for the pilot in section 5.2.2, the method for the study was a combination of a software design walkthrough, augmented with cognitive walkthrough elements. Each participant was required to produce a map of a section of the game using the third and most detailed abstraction layer and include all relevant game mechanic interactions encountered. Mapping was required to be from the perspective of a player that had played the game at least three times previously. Participants were required to work independently, as they did before, not consulting or discussing their maps with each other until all were completed. As previously, participants were required to play the game using a mouse as an input device and to play the game on a personal computer in order to keep the input device and presentation apparatus consistent across all maps. In order to contain the size of the map, a single game walkthrough was used, representing a single possible segment of a playthrough by a player experienced with the game. The segment of the game played by participants followed a walkthrough taken from a fan community-run website 1. Mapping began after the "Start Game" option had been selected and stopped at the menu selection containing a "Visit Ju- lianna" option, for in-game week three. The full script for the walkthrough can be found in appendixC. Participants were given the latest version of the ICM to use during the mapping process. If a they did not ﬁnd the applicable element within the ICM to capture what they believed to be relevant to describe the design, they were instructed to use Narrative Elements as a makeshift node which they were then able to customize as needed. Participants were not given any strict instructions on how they should approach their mapping, but they were given the recommendation of ﬁrst playing the segment through and taking notes on their perceptions before attempting to map it. It was also recommended that they try to have the game in front of them as they mapped it, for accuracy.

1http://longlivethequeen.wikia.com/wiki/Basic_Walkthrough Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 94 Progression Maps

Analysis

The maps were analyzed through a similar iterative qualitative analysis process as the pilot. First, direct structural comparison was used, where node and interaction unit composition and ordering for all three maps were directly compared and contrasted. The criteria for this comparison was first discussing the organization of interaction units used for the maps, then identifying the units and determining what interaction within the game they were meant to describe. This is done for all the maps. Then the individual units were compared directly in terms of which nodes were used, what those nodes were meant to represent, and how those nodes were ordered. Similarities between maps were determined based on whether the same node types were used to describe the same design elements and patterns, and whether the ordering was the same. Further, if there were differences, the causes of those were determined, and then the similarities were re-evaluated based on whether the differences were minor, conceptually similar, or major, conceptually, and structurally in disagreement with other maps. Thematic analysis was applied to the maps’ the use of Narrative Elements like in the pilot. These steps produced a document listing structural similarities, differences, and ambiguities to guide the following steps. Thematic analysis techniques were applied to the structural comparison findings of each of the maps to identify common graph patterns and node ordering and group conceptually similar patterns and nodes together. For both thematic analysis steps, participants were required to participate in its initial stages. They were first asked to read each other’s maps, discuss and compare them, justify their choices, and articulate what they believed to be similarities and differences between them. Finally, participants were asked about their views on the communicative function of Progression Maps within the design process and whether they believed the Progression Maps were suitable to communicate to others about interactive narrative design.

5.2.4 Results

Patterns of similarities and differences were found during the analysis.

Map Similarities

The three maps exhibit similarities in several respects. Speciﬁcally, they are mostly similar in terms of their use of the node types, the structure of their critical paths, and their levels of granularity. Use of Node Types: In most cases, each map generally represented the same interaction design using similar nodes, with similar meanings. For instance, all three maps always represented dialogue as Events or Feedback nodes, usually picking whether to use Events versus Feedback appropriately based on whether or not the dialogue resulted from player input. The maps each included Input and Options to represent the player’s choices and actions at Interaction Points. 5.2. Study of Progression Maps Suitability for Design Communication 95

FIGURE 5.1: The portions of each of the three maps that represent selecting the "Accounting" class for Elodie to take. Though there are some differences in details, the general patterns and represented elements are similar. It is clear that all three maps are showing the same interaction.

The maps often employed the same third-layer node specializations. Cosmetic vs. Mechanical Feedback and Events were used consistently by all three cartographers to describe the same phenomena. For example, all maps represented dialogue and scene changes as Cosmetic Diegetic Events (or Feedback when appropriate). Similarly, notifications and menu transitions appeared as Cosmetic Non- Diegetic Events or Feedback, while stat changes were represented as Mechanical Non-Diegetic Events or Feedback. This indicates the reliability of the ICM to generate a mutual understanding of the meanings behind the Cosmetic and Mechanical labels and the reliability of Progression Maps to account for, accommodate, and represent the differences between such elements. The maps often used Diegetic and Non-Diegetic in similar ways, as well. All three participants considered dialogue to be Diegetic, whereas they marked menus for class selection, as well as notifications and progress bars, as Non-Diegetic. The maps differed on this point in some cases, but some of those differences were due to copy-paste errors, and others could be resolved by discussion after the study. Structure of Critical Paths: All maps generally structured the critical paths of the interaction (those interactions required to complete the walkthrough) similarly. All three maps included the linear dialogue segments and represented each piece of dialogue (distinguishable as pieces of text separated by transitions in game) as their own nodes, connected to each other. These were typically considered Events except when they came after an Interaction, in which case they were represented by Feedback nodes. Again, this distinction was consistent among all three maps. Similarly, aside from minor internal ordering differences, discussed later in this chapter, all three maps mostly used and connected Mapping, Trigger, Interaction, and Option nodes similarly to form Interaction Units. For example, all three maps represented a key in-dialog choice interaction within the game as an Interaction node Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 96 Progression Maps with three distinct paths branching out of it, each consisting of multiple Mapping nodes and a single Trigger node, followed by Feedback nodes. Finally, Forks were represented similarly and consistently within all three maps. All representations included Event nodes before the Fork, and Boolean statements and notes of the character stat value being checked. Similarly, nodes that came after the fork were marked as Feedback of the appropriate type (Diegetic/Non-Diegetic and Mechanical/Cosmetic). Participants represented both traditional branching dialogue interactions as well as delayed branching based on prior choices and stats. Both types of interaction can be mapped as separate elements that are capable of dif- ferentiation upon review of the maps, allowing for a more granular understanding of the structure of the overall interaction. These distinctions were also recognizable and understandable between different cartographers, as demonstrated by the consistent patterns of Interaction and Fork nodes in the three maps to represent the same events. Levels of Granularity: The maps were consistent in the level of granularity and detail that was documented for each interaction unit, seen in the similar number of nodes used to represent key paths, as discussed previously. All three maps represented the fine details of various Interaction Points, such as the class selection menu characteristic to the game. There, participants mapped the selection of the first option in this menu similarly, using an Input Mapping node for the mouse movement and click to select the button (though two participants separated the movement and click, whereas one mapped only the click), followed by a perceptible Trigger node for the selection itself, followed by Cosmetic Non-Diegetic Feedback for the appearance of the sub-menu. They then repeated these for the other menu interactions, with the appropriate feedback, in a linear sequence. All similarly mapped the same Cosmetic Non-Diegetic Feedback of button highlights after selecting categories and classes. Figure 5.1 shows an example of part of these similar structures for selecting the Accounting class. This observation illustrates the use of Progression Maps to represent granular elements of interaction in a detailed manner across different members of a team. It also demonstrates the ability of the maps to generate and support a consistent understanding of how such granular details should be represented.

Map Differences

The analysis of the Maps also revealed several repeated differences between maps. In many cases, these were relatively minor differences, for instance in the phrasing of Format property values. In some other cases, the differences were more systemic and signiﬁcant. Areas of Focus: The primary source of signiﬁcant differences between maps was in their areas of focus. Map 3 contained more systemic diagrams of side-interactions that were unnecessary for the critical path of gameplay. For example, this map included detailed diagrams of each menu option to reveal more information about 5.2. Study of Progression Maps Suitability for Design Communication 97

FIGURE 5.2: The portions of each of the three maps that represent process of clicking to progress the dialogue text. Map 3 included additional system interaction not related to advancing the text, while map 2 used a shorthand notation to represent the interaction. Map 1 contained elements of both approaches. Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 98 Progression Maps the current speaker, to fast-forward through the dialogue, and to get more information about Elodie’s moods and skills. The other maps ignored these extra menu items, opting to focus on the primary story-relevant interactions. This can be seen in Figure 5.2. In addition to including more interaction options, map 3 also included details of constraints on interaction, furthering its systemic detail. For instance, it included constraints on the appearance of the "Done" button to complete the selection of classes for Elodie to take. Map 2, on the other hand, was more successful in capturing all possible branches of dialogue and story interaction, depending on the player’s choices of stats and activities. This map diagrammed all the possible story branches in the final scene mapped, an encounter between Elodie and a snake for which the outcome depends on several prior choices. The other maps included only the path provided by the walkthrough for this scene. Narrative Elements versus Properties: Another primary difference between the maps was in when and how they defined new Narrative Elements and properties. Each map had a different method of noting which option, branch, or text various Progression Map nodes were related to. In map 2, new Narrative Elements specified the text of each menu or dialogue option and the Boolean statement for each branch from a Fork. Map 1 also defined Narrative Elements for menu option text, but not for Forks. Map 3 defined no new Narrative Element nodes, instead adding new properties to Trigger options for their text. This sort of difference also appeared in dialogue Feedback and Event nodes. Map 1 defined new properties for the combination of character dialog and an image of the character, whereas map 2 included the name of the speaking character as part of the Format property. Finally, the maps sometimes included extraneous annotations that were not defined within the Progression Maps framework. Map 2 represented sequential dialogue from the same character by indicating the number of separate utterances with an extra number badge next to the node. Map 3 indicated the "True" or "False" value associated with a branch from a Fork with a similar annotation next to the edge and added comment-like annotations of the speaking character and a portion of their dialogue. Map 1 added a similar annotation above perceptually separate sections of the map, which it also grouped visually in columns. Minor Differences: There were three other types of minor differences between the maps: which Events/Feedback/Inputs were noted, node types (Feedback versus Events and Cosmetic versus Mechanical), and ordering. In some cases, one map would note extra separate Events, Feedback, or Input that were combined or missed in other maps. For instance, two maps included music changes, but one did not. Two maps split mouse movements and clicks into separate Input nodes, but another usually did not. In some cases, maps also differed in which parts of the game they considered Events versus Feedback, or Cosmetic versus Mechanical. These were sometimes legitimate differences in perception, and sometimes proved to be copy/paste errors. Overall order of the maps was mostly similar, but they differed 5.2. Study of Progression Maps Suitability for Design Communication 99 in some cases in minor ordering within an Interaction Unit. For instance, map 1 tended to put Trigger nodes before the Inputs that would cause them, whereas the other two reversed this. None of these minor differences caused significant legibility problems in reading maps generated by the other participants.

Perspective and Communicative Function

Participants all agreed that they found the maps to be suitable for communicating how they experienced the design and that it allowed them to discuss and articulate why they approached and conceptualized certain design elements and patterns in specific ways. These findings echo previous expert evaluation work done on the communicative and descriptive capabilities on an earlier version of the maps implemented as part of the StudyCrafter Design Assistant (Partlan et al., 2019). The results of this study lead to two primary insights in regards to the map’s communicative function. First, while the maps produced by different cartographers will inevitably have differences, specifically in how details are formatted, the similarities between them can shed light on the most salient elements of an interaction from the player’s perspective. Second, the differences between the maps can illumi- nate how particular cartographers perceive an interaction, and what elements they perceive as important and relevant to describe them. This second takeaway reveals the value of Progression Maps in creating concrete illustrations of the ways in which particular people perceive interactions. Progression Maps Describe Perspective: The three maps produced are each rep- resentative of their cartographers’ approaches to mapping the game. The similarities between maps show that salient interaction patterns are consistently described, as all three maps contained similar patterns in the types and sequences of nodes used to represent the interactions in the critical gameplay path. For example, all three maps included Forks followed by Non-Diegetic Feedback to signify the character stat checks that branch the narrative. As another example, the similar structures shown in Figure 5.1 are clearly representing the same interaction. Each map represented these interactions at similar levels of granularity, a standardization encouraged by the clear definitions of third-level Progression Map nodes. Even when the maps differ in formatting or in defining new elements, these choices can still reveal critical elements of the interaction. As mentioned in the results, one difference between the maps was in how they chose to represent the name of the classes selected for Elodie’s studies. One map represented these as new parameters in the Trigger nodes, whereas the other two defined new Narrative Ele- ments to show the names. Despite the differences, all maps recognized the Boolean statement as a detail important enough to be worth including. Thus, the need to define new nodes or parameters for an interaction highlight it, even if the details of those new definitions vary. Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 100 Progression Maps

Though there will naturally be differences between cartographers’ maps, the similarities between the maps revealed the most critical, and most perceptible, elements of the interaction being mapped. In addition, despite differences in formatting, these similarities are clear and recognizable. Thus, it can be concluded that the Progression Maps are mutually intelligible, and the mapped interactions are recognizable by others familiar with the game in question. Progression Maps Reveal Players’ Perceptions: Not only are varied maps still mutually intelligible between cartographers, they also reveal the differing values and experiences between those cartographers and their interactions with the game. For instance, the participant who created map 3 had the least prior experience with the game, and with visual novel-style games in general. This participant tended to notice the minor details of extra potential interactions. They included every possible information button about each character, each optional menu in the class and weekend activity selections, as well as every fast-forward opportunity. This participant did not, however, map every branch of the final encounter with a snake in the gardens, opting to describe only the path provided by the walkthrough. These choices, to carefully map every unnecessary interaction in some places, but not to explore outside the walkthrough in the later scenes, may reveal several things about the cartographer. Because they were experiencing this game for the first time, they wanted to explore and understand the history of, extra information about, and current states of the various characters. They did not, however, have the full picture of which options to manipulate to achieve every path through the snake encounter, nor even to know how many paths existed. The participant who created map 2, on the other hand, had significantly more experience with Long Live the Queen and other similar visual novels. They ignored the extra informational options entirely, but chose to map nearly every path in the snake scene. This latter participant’s focus on the branching narrative over the time-consuming but ultimately irrelevant informational options shows how this prior experience shaped their ability and desire to interact with these parts of the game. Similarly, this participant was the only one of the three who chose to omit the Click to Continue interaction from their Progression Map. This, again, was due to their previous experience with the game, and with visual novels in general, which influenced their perception of the game, and affected what aspects of interaction they did and did not notice or deem significant. These examples illustrate the usefulness of Progression Maps as a tool for understanding how players perceive the nature of a given interaction within a game. For a designer, this might reveal how different players would potentially choose to ignore or explore particular interactions. For participants, it could be used to determine what factors (such as previous experience with a game or genre) affect the ways in which certain elements of interaction are perceived or not. The Importance of Documentation: In this study, the participants commented 5.2. Study of Progression Maps Suitability for Design Communication 101 on the flexibility of Progression Maps. While the stylistic freedom of the maps enabled each participant to use the representation according to their preferences and perceptions, it led to some significant differences between the maps. The clarity and specificity of the ICM helped to keep the maps mutually intelligible, but the manual intentionally allows for some stylistic differences and choices that may differ between participants. The manual is helpful documentation, but it is not sufficient to capture every detail of a particular cartographer’s approach. The participants discussed how, if they had been collaborating on designing a single game, it would be important for them to communicate and document their stylistic choices and come to a consensus on design, and that Progression Maps would be useful for such discussions. This applies to such points as the differences in when various participants chose to define new Narrative Elements versus adding properties to existing nodes. Each new Narrative Element and property should be documented and defined in a mutually accessible document, perhaps as an adden- dum to the ICM. Some participants also chose to add extra annotations and information outside the standard Progression Map definitions, such as noting the text of a particular dialogue as an extra annotation above the map, or annotating each branch of a Fork with the value of the condition that would cause that branch to execute. These stylistic choices should also be documented in team settings, or even when publishing a Progression Map for public viewing. This form of collaborative norm-building is similar to that required in programming or design teams. It is reminiscent of style guides, wikis, or other communication mechanisms for teams working on other creative projects. In this context, it is worth considering whether Progression Maps should be standardized in future work, and moved further toward standardized modeling languages like UML, or kept flexible so that they can be defined as needed, for each team’s specifications. Both approaches have their pros and cons. Flexibility in the representation would allow for more adaptive and design process friendly maps, however, if used for communication across different teams, or even different organi- zations and stakeholders, it is worth considering the downsides of too much adaptation that would move the maps away from a centralized and clearly defined model. Such a move could cause misunderstanding and inconsistencies, as maps would be used across teams, in which case a standardization would be preferred.

Conclusion

This study of Long Live the Queen demonstrates the Progression Map’s ability as a model to capture salient interactions at a granular level. Further, the maps create concrete depictions of the interactions, enabling discussion and communication of design choice and insights that are foundational for design communication. The maps allow designers to identify critical elements and communicate about the shared experiences of interaction between cartographers and the ways in which their Chapter 5. Qualitative Evaluation of the Communicative Capabilities of 102 Progression Maps experiences differ due to their own particular biases, levels of experience, and focuses, which enables more informed analysis later on in the design process. Because Progression Maps are clearly defined, these differing results were reported to be intelligible and meaningful between cartographers, and allowed them to surface and reason about them. Individual differences in perception, then, can be revealed and understood through the use of Progression Maps. These results show that Progression maps are a suitable interactive narrative design abstraction, and that it has sufficiently descriptive and communicative flexibility for designers, addressing core parts of RQ1 ("How to develop an interactive narrative design abstraction, which is suitable for developing a computational model for design analysis and visualization, while maintaining sufficient descriptive and communicative flexibility for novice designers?"). Further, it shows that Progres- sion Maps can be used to abstract the interaction design of an existing artifact and visualized for analysis, as all the designers could recognize and reason about each other’s maps without explanation from the original cartographer. This shows that Progression Maps are a suitable model to build a generalized architecture for automated structural analysis, and that it can be used for abstracting and visualizing design from an existing interactive narrative, addressing some of the requirements mentioned in RQ2 ("How to build a generalized architecture for building automated structural analysis tools for interactive narrative, where the design is abstracted from an existing artifact and visualized?").

Limitations and Future Work

While high in descriptive power, the process of building Progression Maps by hand is labor-intensive, complex, and time consuming. The higher the interaction complexity, the more detail is required to capture it completely and build the map. This is especially relevant to the third Progression Maps abstraction layer, which provides the greatest level of detail and was used in this study. The labor-intensive, time consuming mapping process resulted in compromises on what information was deemed sufficiently important to map. This limits the usefulness of Progres- sion Maps for mapping a large game in its entirety by hand, but they are sufficient and well-suited for close examination of shorter lengths of gameplay and specific interaction design patterns. Mapping larger sections, or the entirety of a game, is more suitable to the first or second abstraction levels, which do not require the same level of detail as the third. This can assist in detecting patterns of interaction which can then be explored in more detail by the third level mapping process. Progression Maps are designed to be flexible enough as a model to enable the cartographer to choose the most appropriate approach for their particular game and purpose. For this study, participants built the maps using generic graphing tools, suitable to UML and similar diagrams used for presenting software design. This led to some friction, due to the mismatch between the tools’ capabilities and the needs of the Progression Maps. Titles and properties had to be entered by hand, and ensuring 5.2. Study of Progression Maps Suitability for Design Communication 103 a clear layout was laborious. This led to copy/paste errors and inaccuracies in the final maps, which were identified during the initial walkthroughs with participants. More robust tools for Progression Maps could significantly improve the speed and accuracy of the cartography process. Such tools could enable the mapping of more complex games. Partial or complete automation, presented in chapter6, could further enable a more viable generation of Progression Maps for entire games. How- ever, automation could be error-prone, and may not reveal the same cartographer- specific biases and individual differences as manual mapping. Thus, full automation may not be the most effective approach for Progression Maps if they are to be used to analyze particular player experiences. One potentially interesting option might be to provide mixed-initiative tools for interaction cartography, and tools that are better suited for direct documentation for playtesting or documentation of observations about a player during studies.

105

Chapter 6

The Design Assistant1

Progression Maps have shown potential to allow for effective communication in both capturing interactive narrative design, as well as the cartographer’s perspective, where the maps are built by hand. I have already shown how Progression Maps can be used through qualitative mapping of a game space in Chapter5. In this chapter, I will describe how Progression Maps can be automatically generated from an interactive narrative construction tool or software, deriving and visualizing important details of the structure of the narrative and its interactions with the user. I will call this system and computational representation the Design Assistant. Further, I will discuss an implementation of this computational model in one such interactive narrative tool: StudyCrafter (Harteveld et al., 2017). I will further show how the De- sign Assistant can be used to automatically derive Progression Maps from multiple StudyCrafter projects. I discuss the choice of StudyCrafter as the ﬁrst design tool to implement the maps, and how the maps were derived from the underlying representation of StudyCrafter’s scripting editor. I will give an illustrated example of how the Progression Maps’ abstraction and visualization reveals more detailed information about the interaction than are found in StudyCrafter’s script editor, which is the result of how StudyCrafter presents certain nodes when the project is interacted with by a player.

6.0.1 Computational Model of Progression Maps Architecture

Each narrative construction tool such as Twine (Klimas, 2009), StudyCrafter (Harteveld et al., 2017), and Ren’Py (The Ren’Py Visual Novel Engine 2019), will have its own tool- speciﬁc representation which encapsulates how the design is structured within the tool. This representation is often unique to the tool itself and thus will require a mapping rule to reﬂect how it can be transposed into a format that is compatible with the Design Assistant’s representation. In order to accomplish that, a mapping system is required to map the tool’s own representation maps onto Design Assistant’s object representation (i.e. Progression Maps). This requires creating a MapGraph representation, a graph of temporal transitions of Progression Map Events in the game created in the tool, from which Inter- action Units and the particular rules and system constraints can be mapped onto the

1The work presented in this chapter was done in collaboration with Nathan Partlan. 106 Chapter 6. The Design Assistant

FIGURE 6.1: The Progression Model has 5 conceptual constructs. The Progression Maps are a more concrete representation of 2 of those constructs, speciﬁcally Interaction and Presentation. A Design As- sistant Graph is a Progression Map that has been automatically generated with a Design Assistant architecture, from a narrative construction tool. In this chapter we will discuss how Design Assistant Graphs were built from StudyCrafter projects.

Design Assistant’s object representation. Some of these mappings will require the consideration of a human expert to construct mapping rules for the mapping system, such as those observable during run-time, which are not a visible or modifiable part in the tool’s editor. Finally, the Design Assistant uses the MapGraph representation to construct a Progression Map of the game created by the tool by traversing the graph and constructing each node. It should be noted that in some cases "Scene Data" and thus "Scene Graphs" are not going to be a part of the tool’s representation, or a construction that fits into its design paradigm. These can be omitted if they are not suitable or can be changed to reflect other ways in which the tool might segment its narrative. It is called Scene here in reference to StudyCrafter’s scene structure. In this dissertation, I will not discuss how to build a generalized mapping system, since this will be tool specific, focusing on StudyCrafter. I will discuss the development of a mapping system for StudyCrafter more at length later in section 6.2.1. Chapter 6. The Design Assistant 107

Node Name Parent Attributes Class Interaction Unit None Interaction Unit ID Interaction Point Interaction Perceptibility: Enum{Hidden, Partially Unit hidden, Presented} Format: Enum {Menu, Action} Option Interaction Format: Enum{Menu Choice, Video Cut- Unit Scene, Dialogue, Audio, Animation, Nar- ration, Environment Changes} Trigger: List{ InputID, ...} Content: Text Events Interaction Type: Enum{Event, Feedback} Unit Format: Enum text, animation, audio Actor: ActorID Feedback Event Type: Feedback Input Interaction Method: Enum{inputDeviceMouse, Unit InputDeviceKeyboard, InputDeviceCon- troller, ...} Value: Enum{Click, ButtonPressed, But- tonUp, ButtonDown, JoystickMovement, D-PadPress, ...} Target: Game ObjectID Constraints Interaction Variable: GameStateID Unit Value: true/false Forks Interaction Type: Enum{Deterministic, Random} Unit Variable: GameStateID, List of {{NodeIU, GameStateID, Value} ... } Start None Start Node ID End None NextScene: List{Start Node ID, ...}

TABLE 6.1: The Design Assistant’s Representation: Applied Progres- sion Map nodes as class-like objects, containers, with attributes. Game Objects are graphic, visual elements like the characters (including the player character), objects, environmental features, and interface elements such as buttons. Game State is a representation of the mechanical and narrative state of the game world. The Game State is represented can be represented in various ways, but must at least consist of a pair of Game State IDs to identify which part of the game state is being referenced, with corresponding logic statements that evaluate to a Boolean value. Note: All Options are explicitly presented in the Design Assistant, while this may not be true for other Progression Map representations. 108 Chapter 6. The Design Assistant

Layout Script Meta Layout Script Meta Data Data Data Graph Graph Data

Scene Scene Data Graph

Tool Specific Representation MapGraph

Narrative Progression Mapping System Design Assistant Map Construction Tool

Mapping Prog. Map Rules Algorithm

Temporal Structure

FIGURE 6.2: The Design Assistant Architecture. The architecture can be adapted to any existing narrative construction tool. Using a tool speciﬁc representation consisting of layout, script, and meta data for a project, it is passed into a mapping system, which formats the tool representation into a MapGraph which contains a graph representation of the tool. Finally, the MapGraph is processed by the Design Assistant in order to generate a Design Assistant graph, an applied Progression Map.

6.0.2 Development of the Design Assistant

The Progression Map representation was discussed in detail in Chapter4, and 3 abstraction levels were outlined for it. Each level indicates the level of detail that the map encapsulates; 1 being the least and 3 being the most. The first level consists only of Interaction Units (IUs), the second level expands each IU to include more detailed nodes (7 types in total), and the third level expands each of the second level’s 7 nodes further to capture more detailed elements of the design (17 node types in total). To computationally derive a representation of narrative structure, the Design As- sistant was developed to generate maps at the Progression Map’s second level of abstraction. This choice was made for several reasons. First, the higher-level abstraction (level 1) is too high to give us more information on the design details to make the tool useful for design diagnosis. The third level is too detailed, as it captures information that is very important, but also hard to generalize or automatically represent. For example, while it is relatively straightforward to derive information about interaction and possible actions from an interactive narrative tool, the details of those actions are more difficult to capture automatically. Determining whether an interaction is cosmetic or mechanical, and whether it is or diegetic or not, are not usually part of the representation of the tools used to construct the narrative, and Chapter 6. The Design Assistant 109 may be interpretative, requiring a designer to encode it. Further, for this first implementation of the Progression Maps, it was decided to not delve into natural language processing, qualitative analysis, or designer coding or labeling. This limited what types of nodes and information we can glean from the tool itself and focuses it on structural analysis. For this level of abstraction, there are several constructs which will be represented in the Design Assistant system. These constructs are represented as objects. Figure 6.3 shows these objects and their relationships. As shown in the figure, the objects are: Interaction Unit, which contains several objects: Interaction Point, which maps to a choice or event at which the player may take action, an Option, which represents the choice or the action itself; Event, which is a dialogue utterance, action, or sound that is not dependent on the player’s actions; Feedback, which is an event describing a dialogue utterance, animation, or sound that follows from the player’s actions; Input which represents the physical actions the player must take; Fork which represents automated branching corresponding to the if-statement script node; and Constraint which corresponds to the conditions built player choice script nodes. These objects match the purposes of their corresponding nodes in the Pro- gression Map conceptual model, as described in the chapter4, apart from the Start and End nodes. The attributes for each of these objects map to the attributes described in table 6.1.

FIGURE 6.3: The class diagram for the Design Assistant Representa- tion, built on the Progression maps.

6.0.3 Building the Design Assistant Graph

Constructing the Design Assistant Graph (a Progression Map) requires a graph of temporal transition incorporating all possible actions, inputs, and design elements 110 Chapter 6. The Design Assistant

FIGURE 6.4: The algorithm for building the Design Assistant Graphs. relating to the progression and interaction design for the game (a MapGraph) from a mapping system. To build the Design Assistant graph, the Interaction Points are identified, and from there each Interaction Unit is formed, populated, and connected to other units, in accordance with the MapGraph. More specifically, and as described in the algorithm 6.4, when processing the MapGraph, with a depth-first approach, if the node is identified as an Interaction Point an Interaction Point node is constructed, and for each Option identified as being a part of the Interaction Points corresponding Interaction Unit (to which all the nodes are assigned when they are created), an Option node is created. For each Option node, each corresponding Input required to enact each option is identified, and for each one an Input node is created. For each Input, if there is a constraint on that Input, assign a Constraint property to the In- put node. If the node is not an Interaction point, it is either an Event or Input. If the node is an Event, its exact type is determined based on its temporal placement. If the Event is preceded by Input, Option, or Fork, then it is information delivered in response to a player action and a Feedback node is created. If the Event is preceded by Input, Option, Feedback, and the node’s type is available, then it is a Fork. Whether the Fork is deterministic or random will be determined through meta data from the 6.1. Narrative Construction Tool: StudyCrafter 111

FIGURE 6.5: The Main FIGURE 6.6: The Lay- Project Screen out Editor Screen

FIGURE 6.7: The Script FIGURE 6.8: The Editor Screen Playtesting Screen

FIGURE 6.9: Examples of the Main Project Screen and the three authoring tools included in StudyCrafter. The StudyCrafter Project depicted here was created by participant U-P3, in the usability study described in Chapter7 tool. If neither is the case, the node will remain an Event. If the node is Input, then a corresponding Input node is created. This is repeated, using a depth-ﬁrst search, for the entire graph until it has been populated in full, at which time the entire graph is returned. The MapGraph is assumed to contain all edges between nodes, and the completeness of the graph is contingent on the completeness of the narrative construction tool’s MapGraph. If the Design Assistant Graph is to be used for structural analysis, the graph might be required to be either a fully connected and/or directed graph to fulﬁll the requirements of analysis algorithms, but this will be on a case by case basis and should be post-processed accordingly before it is used for automated structural analysis.

6.1 Narrative Construction Tool: StudyCrafter

StudyCrafter (Harteveld et al., 2017) is a game-based platform meant for the creation of small-scale social science experiments. It provides a visual scripting language and scene layout editor, as well as art and graphical design assets, enabling designers to build games or experiments with minimal knowledge of programming. Its format lends itself well to short interactive narrative creations, and it has been used to create short interactive narratives for previous work (Partlan et al., 2018). 112 Chapter 6. The Design Assistant

6.1.1 StudyCrafter’s Authoring Tools

StudyCrafter contains three authoring tools that can be used to create a StudyCrafter project in the form of a small game, interactive narrative, or a small-scale social science experiment. The three tools are a layout editor, a script editor, and a Playtesting tool. The layout editor (fig 6.6) contains a variety of graphics and art assets, such as backgrounds, characters, objects, and user interface (UI) and head-up display (HUD) elements such as buttons, on-screen text objects, and progress bars. The script editor (fig 6.7) provides the player with a node-based visual scripting language, laid out for the player in a graph-like format, where the player can use and connect various node types to create the game mechanics and interaction functionality that they want. Each node corresponds to either a design element that the player is not able to modify, such as dialog and choice nodes which correspond to visual text boxes that are displayed on top of the layout, as defined in the layout editor, or it corresponds to a functionality that is either directly connected to an element within the scene (which the player needs to insert using the layout editor) or other functionality such as if-then statements, sounds, events, and custom functions. In addition to the nodes, players can manipulate variables either as part of the "Set Variable" node, within other nodes, or directly in the variable tap which is accessible at the left side of the script editor interface. The variables can be used either globally as a data structure such as integers and Booleans, or as an object variable. The Playtesting tool (fig 6.8) runs the project according to the current state of the project. It can be used at any time by the player to test their project. The player can switch between the tree tools as they see fit, or return back to the main project screen (fig 6.5) where they have an overview of the entire project. Each StudyCrafter project consists of scenes, with each scene corresponding to one layout figure with elements and one script editor script. To link individual scenes together, the player can use End notes, where they can select what existing scenes they want the player to progress to through a drop-down menu. In this way, the player can construct larger projects modularly through connecting individual scenes, which allows the player to re-use their scenes in various ways should they choose. StudyCrafter’s format lends itself well to short interactive narrative experiences. The main reason for this is its scripting language, whose graph-based structure and node types affords structures and progression mechanics commonly used in visual novel designs and simple branching narratives (see Chapter3 for further discussion on structures and progression mechanics). The nodes used are mainly identical in function to common design elements for visual novels, particularly the Choice, Di- alog, and if-then statement nodes that are all key components of traditional branching interaction designs. Further, StudyCrafter shares similarities with other design tools used for interactive narrative that also feature visual graph-based presenta- tions, such as the hugely popular Twine. StudyCrafter’s simple and easy to use interface, coupled with the suitability of 6.2. Mapping System: StudyCrafter Mapping System 113 its scripting language to building short interactive narratives, while maintaining similarities with existing design tools, make it a good candidate for the first implementation of the Progression Maps, as it would allow for an efficient way to collect data from designers, while also being simple and approachable enough for novice designers to use and create small narratives within a short amount of time. In addition, its similarities, from the perspective of design abstraction and structure, to existing tools and design patterns of common interactive narrative genres will be a good test to gauge the suitability of the Design Assistant Architecture for narrative construction tools.

6.2 Mapping System: StudyCrafter Mapping System

In this section, I discuss how a Design Assistant was developed and built for Study- Crafter. Following the representation and algorithm discussed above, I begin by describing the process required in order to systematically undertake the adaptation and tuning of the mapping rules and building of the Design Assistant Graphs.

6.2.1 Development of the Mapping System

In this section, I discuss how a mapping system for the Design Assistant was developed based on StudyCrafter’s tool representation. Following the representation 6.1 and algorithm 6.4 discussed previously, I describe the process required to systematically undertake the mapping and tuning of mapping rules to build the Design Assistant Graphs. In order to build the mapping between the MapGraph and the De- sign Assistant object representation described in table 6.1, there were two types of mappings performed. First were the 1:1 mappings where a StudyCrafter node was mapped directly to a Design Assistant object/node. Direct mappings were possible based on the MapGraph for all but two of the StudyCrafter nodes. Those nodes were special cases, where the interaction information they represented were not present in the script graph which served as a container for both script and metadata for Study- Crafter in the MapGraph and required that they be mapped by hand. Each node in the Design Assistant graph has a set of attributes derived from the tool representation, and are assigned an Interaction Unit ID.

6.2.2 Direct Mappings

Most of the mappings required were straight forward 1-to-1 mappings from a Study- Crafter script editor node to a Design Assistant object node. They were derived directly from the script data. IU.Interaction Point was constructed for each StudyCrafter.PlayerChoice and StudyCrafter.Event node, the only two ways the designer can incorporate interaction in the StudyCrafter script editor. 114 Chapter 6. The Design Assistant

StudyCrafter Node Design Assistant Mapping Mapping Process StudyCrafter.PlayerChoice IU.InteractionPoint + Direct for each StudyCrafter.PlayerChoice.Choice => IU.Option StudyCrafter.Event IU.InteractionPoint + IU.Input Complex StudyCrafter.Action IU.Event || IU.Feedback Direct (Type location dependent) StudyCrafter.Dialog IU.Event || IU.Feedback + IU.Input Complex (Type location dependent) StudyCrafter.Sound IU.Event || IU.Feedback Direct (Type location dependent) StudyCrafter.If-Then IU.Fork Direct StudyCrafter.EndScene IU.End Direct StudyCrafter.Start IU.Start Direct

TABLE 6.2: The mapping from StudyCrafter nodes to the Design As- sistant’s representation. When there are sequences of nodes they are represented as "IU.Node + IU.Node + ...". The mapping process is either direct, i.e. it did not require human intervention to map and it was possible to map direct between the MapGraph and the Design Assistant representation, or complex, i.e. required human intervention and interpretation to map due to its functionality or presentation not being fully captured in the MapGraph. Nodes were connected according to the temporal structure provided by the tool representation. The possible properties of each Design Assistant node are described in table 6.1, and are derived on a case by case basis from the meta data from the tool representation. 6.2. Mapping System: StudyCrafter Mapping System 115

IU.Option was constructed after IU.Interaction Points constructed for Study- Crafter.PlayerChoice, corresponding to the list of choices in the StudyCrafter.PlayerChoice node. IU.Input are formed after IU.Option nodes, when the player must select an option to continue the scenario. IU.Fork is built from StudyCrafter.If-Then node. Their out-edges are annotated with the related condition. IU.Constraints are currently used only to indicate cases where certain options are hidden behind a condition on a StudyCrafter.PlayerChoice node. IU.End maps to StudyCrafter.EndScene node, and IU.Start to StudyCrafter.Start. IU.Event is constructed for StudyCrafter.Action, and StudyCrafter.Sound, and in addition they can be constructed if there is a caption for an IU.InteractionPoint constructed from a StudyCrafter.PlayerChoice node. IU.Feedback is constructed in the same way as Events.

6.2.3 Mapping Complex Nodes

Two of the StudyCrafter script nodes required further attention as there were no direct mappings that accurately captured their functionality. In the case of Study- Crafter.Dialog nodes, it required additional information to describe as its full functionality and presentation was not fully captured in the script data or any part of the tool representation. For StudyCrafter.Event nodes, they were undoubtedly representing an interaction opportunity, but they did not present the player with any explicitly presented Option equivalents. To ensure that both nodes were fully mapped, an exhaustive mapping process was conducted on all nodes to ensure (a) the accuracy of the mapping, and (b) that both StudyCrafter.Dialog and StudyCrafter.Event nodes would be captured in full. The mapping process was as follows:

1. List all StudyCrafter node types and data used to create the projects, this would be from both the script editor and the layout editors.

2. For each StudyCrafter node type, examine:

(a) In the script editor, how can the node type be modiﬁed by the designer, and what can the designer add to the node itself? (b) In the layout editor, what are the layout elements that are available to the designer to use with which script node? (c) In the Playtesting tool, how is the functionality, as deﬁned in the script and layout editors, presented to the player as it is running as an interactive experience?

3. For each StudyCrafter node, describe how it is presented to the player, identifying every element and their sequence, and augment this description with the information from the script and layout editors. 116 Chapter 6. The Design Assistant

4. Match elements and sub-sequences, and their role, functionality, and presentation, to Progression Model node types, as applicable.

5. For each single StudyCrafter node, match all possible Design Assistant nodes and sequences thereof to determine whether all possible design variations afforded in the script and layout editors have been captured.

6. Construct the Progression Maps, based on the StudyCrafter script graph, here called script graph. For each StudyCrafter node, identify what the corresponding element or sequence of elements represent for that particular node given its properties and connections in the overall graph, and then connect it as appropriate with the patterns the following nodes represent.

• Note that design and constraint affordances come in to play here. Presen- tation or Input might be fixed in a particular manner for a player, and not modifiable by the designer, so these design elements and constraints will have to be defined statically, often as part of a sequence.

In order to get an overview of the scope of the range of elements that would need to be considered, step1 required listing all StudyCrafter node types and data that can be used to create a project, both in the script and layout editors, the two editors where the designer would be able to modify and add elements to their design which would impact the interaction. Once the full scope was determined, in step2, each node type was examined to determine how it could be modified within the script editor, what data it could potentially use from the layout editor, and how it was presented and interacted with in the Playtesting tool. This resulted in the first iteration of identifying potential mappings between StudyCrafter and Design Assistant object nodes, most of which were directly mapped nodes. For example, Interaction Units would be centered around Choice and Event nodes, which each represent a different type of interaction opportunities and design patterns. Dialog nodes, Action, and Sound would all map onto Events and Feedback in some form, as they were meant to present information in some capacity, and If-Then would map directly onto Fork. This examination also meant taking note of how and where input would be modified or defined by the designer. In step3, it was determined how each of the nodes were presented and interacted with, and how this matched with the elements that were allowed to be modified in the script and layout editors, such as how and whether input was included directly or indirectly in the script editor in the same way it was utilized in the Playtesting tool. One example of this is the Dialog node’s requirement of a mouse click to progress to the next node, which was not specified in the script editor. In step4, the sequences of how each node was presented were examined, and then used the Progression Map nodes to map each StudyCrafter node by hand to capture the sequences and patterns each represented. These could range from a single node to a larger graph. Then for step5, the overview knowledge from step1 was used to examine whether all StudyCrafter nodes an all 6.2. Mapping System: StudyCrafter Mapping System 117 their variations were represented and update either nodes or graphs as needed to ensure that all variations were represented with a corresponding Design Assistant node or sub-graph. This was done through a mixed approach, where test projects were used to construct various maps which were then examined, as well as through manual checking. As a final step (step6), these Design Assistant nodes and graph equivalents of StudyCrafter nodes were passed along with the MapGraph, in order to construct the Design Assistant Graph nodes. The full mapping can be seen in table 6.2 and the construction process is discussed in section 6.3.

Dialog Nodes

StudyCrafter.Dialog nodes are used to represent information via text, which is added and modified by the designer. The presentation of the text can be modified directly, appearing as a text box by default, or when associated with a layout element, such as a character or object, can be presented as a speech bubble, or a thought bubble, displaying as connected to that element when it appears. However, other than information nodes such as StudyCrafter.Action, which has associated input or function that the designer can modify, StudyCrafter.Dialog has no apparent or modifiable manner in which the designer can customize how the player progresses within the script editor. Thus, it was not possible to directly derive it from the script graph since the graph did not have a complete representation of its function and presentation when interacted with by a player. Since StudyCrafter.Dialog has a modifiable presentation of information, which would be either represented as an IU.Event or IU.Feedback node depending on its location, and a fixed click-to-continue input, its information node (IU.Event or IU.Feedback) should be followed by a single IU.Input node describing the mouse and click as required interaction to progress. The StudyCrafter node in this manner corresponding to a sequence of two Design Assistant nodes.

Event Nodes

StudyCrafter.Event nodes function similar to triggers for isolated chains of Study- Crafter nodes, which are triggered by a single input from a player, or after a speciﬁc amount of time has passed. They are not directly connected to the main connected script graph, apart from the chain they serve as the trigger for. This kind of functionality does not map directly to existing Design Assistant nodes, as this is an interaction opportunity, which Interaction Point corresponds to, but it does not represent an Option to the user. As a matter of fact, StudyCrafter.Event nodes can represent a chain of animations, mechanics, and other interaction, which is triggered by input, which is not explicitly presented to the player as a part of StudyCrafter.Event node in the script editor. Their function and existence can be presented through alternative StudyCrafter nodes or Layout elements such as text boxes, but they are not a part of the node itself. 118 Chapter 6. The Design Assistant

FIGURE 6.10: A lamp screams. In StudyCrafter, a Dialog node can be associated with a layout element and displayed as a speech bubble associated with the element. The StudyCrafter Project shown created by participant U-P3, in the usability study described in Chapter7

To more accurately reflect StudyCrafter.Event nodes and their functionality, it was decided to forgo an IU.Option node for its mapping, and represent it as an IU.InteractionPoint followed by an IU.Input, rather than representing the IU.Option between the two as it would be for a StudyCrafter.PlayerChoice node. This goes against how Interaction Units are defined within Progression Maps, where each unit is defined as containing one Interaction Point and one Option each. However, this is allowed within the Design Assistant representation to increase flexibility. There are two reasons for omitting IU.Option in this case for StudyCrafter.Event. Study- Crafter.Event does not explicitly present an Option equivalent to a player and are hidden unless instructions about the interaction they represent are presented to the player. This can be in a manner that is not associated directly with the interaction opportunity or how that is presented. In addition, having IU.Option included between the IU.InteractionPoint and IU.Input had too much visual clutter and presented no additional information that was not already encapsulated in the IU.InteractionPoint and IU.Input sequence.

Automation of Complex Node Mapping

Automating the mapping for more complex nodes, making it more targeted and comprehensive, is possible through allowing the mapping system full access to the tool’s source code. For both complex mapping cases, it was a question of how to identify and process input. For StudyCrafter.Dialog, automation would have been possible if the transition input required to progress the node, as deﬁned in the tool’s 6.2. Mapping System: StudyCrafter Mapping System 119 source code, had either been accessible, or processed into being part of the tool’s representation. For StudyCrafter.Event, it was a more subjective representation preference, deciding to represent it as literally in terms of its function as possible. In theory, this process might also be automated, if the nodes are examined, and their progression function deﬁned (if absent). If there are multiple actions accessible at that time as part of the function, those should be represented as an IU.Option, followed by the appropriate IU.Input, but if not, it could be directly represented with IU.Input, as it is currently. While other tools such as Ren’Py might have a similar structure, and omit click to continue input from their representation, other tools such as Twine might not, but differ in other ways and omit different design structures or functionality. Open source tools like Twine are more open and will allow much greater access to their code base than others, which will in turn allow for much better mapping potential and accuracy in the Design Assistant graphs. However, in cases where the tool source code remains inaccessible, or only partially accessible through an application programming interface (API), it might require that some mapping be done qualitatively to compensate. As such, the development of a mapping system is possible across different narrative construction tools, but might require varying amounts of subjective mapping, in which case a generalized and comprehensive mapping approach, such as the one described earlier in this section, should be developed and used.

6.2.4 Interpretation, Ordering, and Presentation in the Mapping System Development

Each iteration of the Design Assistant is dependent on the tool on which it is built. The design affordances of the tool itself, and the constraints it poses to designers, will affect how the Design Assistant representation needs to be adapted. Concretely, these will primarily be in terms of how the Design Assistant nodes can be applied and defined in the context of the tool, as well as how the graphs will be built, as ordering and sequences of nodes are deliberately not explicitly defined for the Pro- gression Maps to allow cartographers more freedom. Additionally, adaptation will likely require additional improvements to how the maps are visualized in order to improve their readability, on a tool by tool basis. For StudyCrafter, several modifi- cations had to be made in order to better match the underlying tool and to visualize it more effectively. Adapting most StudyCrafter script nodes was relatively straightforward, as described earlier in this section (6.2.1 to 6.2.3), as it was decided to match how their interaction and information was presented to the player rather than limit the graphs to how they were defined within StudyCrafter’s script editor. This would have the Design Assistant graphs match how the player would experience and encounter 120 Chapter 6. The Design Assistant the interaction and the information. In this context, the question of how to order IU.Input and IU.Option nodes in relation to each other came up, as they differ from the two StudyCrafter nodes that afford interaction and are the base for IU.Interaction Points (StudyCrafter.PlayerChoice and StudyCrafter.Event). It was decided that IU.Options should always come before IU.Input nodes for StudyCrafter.PlayerChoice nodes, as the player is required to observe the choices (IU.Options) before they can provide their input. StudyCrafter.Event nodes required more extensive consideration, which is discussed in greater detail section 6.2.3. As previously stated, ordering is not strictly defined, nor meant to be enforced for Progression Maps as a conceptual model, to prioritize flexibility for the cartographer. As a result, there are no defined guidelines for how to go about connecting the nodes in the Design Assistant, which is meant to rely on temporal structures from the tool itself. Ordering becomes an issue, for example, in cases where elements are not directly connected to other components, as in the case of StudyCrafter.Event nodes which do not have direct edges to other things in the map. In this case, Study- Crafter.Event nodes were connected to the graph as indirect edges, shown as a broken line in the generated map. Other Design Assistant nodes where this might have been useful included IU.Constraint nodes that might potentially impact several different nodes and thus would require indirect edges to represent. IU.Constraints were implemented in a simplified format for this version of the StudyCrafter Design Assistant, in accordance with the current iteration of the Design Assistant representation. This was due in part to the complexity that Constraints conceptually represent in terms of how they are identified when they are not explicitly made clear. Constraints were identified as being presented through StudyCrafter.PlayerChoice nodes that can be modified to only present choices given a Boolean statement. More complex constraints, such as use of variables in various different nodes in combinations with StudyCrafter.If-then (IU.Fork) nodes and how this impacts playthroughs, is the subject of future work. Additional choices pertaining to interpreting what functionality was or was not to be considered a node, relied on similar reasoning relating to more accurately capturing the presentation used by the tool, and improving the readability of the maps. It was decided that a click-to-continue progression that was used most notably with Dialog nodes, and discussed in a previous section, would be interpreted as IU.Input rather than an IU.Interaction Point and IU.Input sequence. The reasoning for this was the click to progress to the next node interaction was trivial and the automated choice of progression for most of the StudyCrafter nodes. In addition, it is considered trivial progression in commonly used interactive design patterns in narrative driven games, such as dialog progression in visual novels. As a result, it was decided to reflect that there was an IU.Input required to progress, but that this was not a notable interaction opportunity, and to represent all click-to-continue interaction that were part of nodes as an IU.Input node which was attached at the end of the sequence of Design Assistant nodes representing the remainder of the StudyCrafter 6.3. Design Assistant: StudyCrafter Design Assistant 121 node. StudyCrafter.PlayerChoice nodes presented a similar issue, as they contain an option in the script editor to present information to the player as the choice is presented. According to the definition of Progression Map interaction points, they should contain all information related to the interaction opportunity they represent. In this case, it was decided to represent this information as IU.Event nodes to divide between the information presented and the interaction point visually in the graph. The reasoning behind this was that the designer would have a more expanded view of the information that they included. This is interpretive, and this information could just as well have fit within the IU.InteractionPoint as a node property, but given that the goal of StudyCrafter is to support novice designers, prioritization was given to a more expanded view of what was included in the design. Prominent improvements to readability through improving visualization included the addition of labels on IU.Fork out edges to identify which condition in the Fork each edge corresponded to, and the addition of a content property for IU.Option nodes to identify and label which part of the StudyCrafter.PlayerChoice node was being referred to in the map. Lastly, there was the question of how best to procedurally identify which information should be categorized as either an IU.Feedback or IU.Event node. The distinction between the two is subtle and should be considered carefully for each case and context. These are node types that build on and are meant to reflect perception and previous experience and will therefore not be able to reflect the view of all players at all times. As a result, when constructing Design Assistant graphs, it is important to keep in mind that whether something is categorized as an IU.Event or IU.Feedback is likely to reflect the perception and perspective of the cartographers that implemented the Design Assistant and the Mapping System, rather than any particular other set of players. For StudyCrafter, it was decided to represent information until the first IU.InteractionPoint in a scene using IU.Event nodes, as the player would likely either be aware or suspect that this information was not personalized to or impacted by their action, since they had not provided any information or input yet. After the first interaction point, all information would be categorized as IU.Feedback nodes and assume that it would be likely that the player would believe that the information was personalized to them. This was a safer assumption than attempting to arbitrarily or randomly decide when something would or would not be considered an IU.Event after the player had started to interact with a StudyCrafter project.

6.3 Design Assistant: StudyCrafter Design Assistant

To create the Design Assistant graph for each scene, the temporal structure is derived from the MapGraph; in StudyCrafter speciﬁcally, it is derived from the script graph, and then an algorithm 6.4 was used to derive the graphs. For StudyCrafter, each Design Assistant graph corresponds to one scene. Each node is populated with 122 Chapter 6. The Design Assistant

Node Name Parent Attributes Class Interaction Unit (IU) None Interaction Unit ID IU.InteractionPoint Interaction Perceptibility: Enum{Hidden, Presented} Unit Format: Enum {menu, object, text box, un- known} IU.Option Interaction Format: Enum{object selection, menu Unit choice, or text input} Trigger: List{ InputID, ...} Content: Text IU.Events Interaction Type: Enum{Event, Feedback} Unit Format: Enum Sound, text, character speaking, character thinking, visibility toggle, animation Actor: ActorID Content: Text IU.Feedback Event Type: Feedback IU.Input Interaction Method: Enum{mouse or keyboard} Unit Value: Enum{EnterText, Click, MoveAnd- ClickTarget, PressKeyDown, ReleaseKey, PressAndReleaseKey} Target: Game ObjectID IU.Constraints Interaction Variable: GameStateID Unit Value: true/false IU.Forks Interaction Type: Enum{Deterministic, Random} Unit Variable: GameStateID, List of {{NodeIU, GameStateID, Value} ... } Conditions: EnumCondStatement, ... IU.Start None Start Node ID IU.End None NextScene: List{Start Node ID, ...}

TABLE 6.3: The properties for the StudyCrafter Design Assistant. attributes in accordance with the Mapgraph data, which contains the script, layout, and other meta data required. See a detailed overview in table 6.3 As an illustrative example, figure 6.11 shows the script graph from the same scene as the one from the project shown in figure 6.9. In this scene, the script graph shows that a character animation plays, a female character moves away from a screaming lamp, followed by the player being given a choice; depending on the choice, a different animation will play, moving the male player character either to the lamp, or turning them around to ignore it. The script graph does not clearly indicate how the details of the interaction are going to be presented to the player, or which action node is in response to what choice. The corresponding Design As- sistant graph, depicting the same design and shown in figure 6.12, shows how the first action, in which the character “female2_sit_green” moves to a specific position, 6.3. Design Assistant: StudyCrafter Design Assistant 123

5: Event

Script: 13 - action Format: Animation Actor: female2_sit_green Content: MoveTo

6: Input

Script: 13 - action Method: mouse Value: Click

7: InteractionPoint Units: 7 Script: 14 - choice Perceptibility: True Format: Menu

8: Option 10: Option Units: 7 Units: 7 Script: 14 - choice Script: 14 - choice Format: menu choice Format: menu choice Content: knock over lamp? Content: pretend nothing happened 13: action actionTarget: female2_sit_green actionName: MoveTo action_x-position: -340 9: Input 11: Input action_y-position: -50 Units: 7 Units: 7 action_time: 2 Script: 14 - choice Script: 14 - choice advance_mode: OnClick Method: mouse Method: mouse Value: MoveAndClickTarget Value: MoveAndClickTarget

14: choice 12: Feedback 15: Feedback choiceType: simple Units: 7 Units: 7 speaking: False Script: 17 - action Script: 20 - action choices: 17~~knock over Format: Animation Format: Animation lamp?~~True~~none~~true~-~20~~pretend nothing Actor: male2_sit_yellow Actor: male2_sit_yellow happened~~True~~none~~true~-~ advance_mode: OnClick Content: MoveTo Content: Flip

13: Input 16: Input Units: 7 Units: 7 17: action 20: action Script: 17 - action Script: 20 - action actionTarget: male2_sit_yellow Method: mouse Method: mouse actionTarget: male2_sit_yellow actionName: MoveTo actionName: Flip Value: Click Value: Click action_x-position: 80 action_vertical: False action_y-position: -50 action_horizontal: True action_time: 2 advance_mode: OnClick advance_mode: OnClick

FIGURE 6.12: A partial Design Assistant graph from the same project, FIGURE 6.11: A partial corresponding to the script graph from the script graph shown in project depicted in 6.7 Figure 6.11 124 Chapter 6. The Design Assistant is expanded into an Event. The Event is followed by a “tap to continue”-style In- put. Then, the player has a choice to either knock over the lamp, or to pretend that nothing happened. The choice node is expanded into an Interaction Point with a Format of “Menu,” since the player must select from a menu of options. Next, these Option nodes are enumerated, followed by the Input (of Value “MoveAndClickTar- get”) required to activate that particular option. Finally, the resulting actions are represented as Feedback nodes since they are caused by player interaction. They are followed by Inputs for their tap-to-continue behavior.

1: Fork

Script: 7 - if Type: deterministic Conditions: 36: {Character} == 0 38: {Character} == 1 40: True Variables: Character

Fork: 36 Fork: 38 Fork: 40

2: Event 21: Event 23: Event

Script: 36 - action Script: 38 - action Script: 40 - action Format: Animation Format: Animation Format: Animation Actor: Larry Actor: Daphne Actor: Daphne Content: Visibility Content: Visibility Content: Visibility

FIGURE 6.13: An example of a fork, generated from one of the projects described by Partlan et al. (Partlan et al., 2019). The edges out of the fork are annotated with their corresponding condition identi- ﬁers.

Not shown in this example of the Progression Map are Start, End, Fork, and Constraint nodes. These nodes look similar to the nodes shown, but with properties as described previously in this chapter. An example of a Fork node and its annotated edges, from an unrelated project, is shown in Figure 7.2.

6.4 Future Implementation with Other Narrative Construc- tion Tools

The Design Assistant is a ﬂexible, abstract architecture that can be implemented across different narrative construction tools. Its implementation as a StudyCrafter Design Assistant is a proof of concept which shows its objective can be achieved. The Design Assistant relies on a graph-based structure, a common representation 6.4. Future Implementation with Other Narrative Construction Tools 125 and data structure already in wide use in the professional design and academic communities. Graph-based representations are already serving as a representation for commonly used tools like Twine, and further, they are common in game design tools. A couple of examples can be found in Unreal Engine 4 (Sweeney, 2014), a popular video game engine. These are the behavior tree editor and blueprint editor, both of which are node-based scripting editors. While behavior trees focus on building on game AI agents, the blueprint editor is a generic scripting language for game logic. Thus, it can be argued that the underlying data structure and representation of the Design Assistant architecture is compatible to build analysis representations on top of existing tools. Further, any player experience can be visualized as a sequence, as actions the player takes will be taken in a sequence of some sort. This raises the possibility of building the Design Assistant graphs based on such sequences, regardless of the tool chosen. In order to do so, playtraces could be either recorded or constructed, and then linked together with the design elements which were interacted with during the playthrough at any given time, and from there, build out the interaction design and the Design Assistant graph. This addition to the architecture will be explored in future work. While it is not within the scope of this dissertation to discuss the construction of a generalized mapping system, it is worth noting that the mapping process will require human intervention. It is not clear how much domain knowledge and specialization building the mapping rules requires, or how complex the task is. For a smaller design platform like StudyCrafter, it is a manageable task for a single expert or small team, and does require a basic knowledge of the inner workings of the tool itself, knowledge of how to use it, and familiarity with how it is used by its target audience. Thus, it stands to reason that it is not a trivial task. It requires a speciﬁc set of skills such as knowledge of the tool both as a designer and as a programmer, and experience and knowledge of how it can be used for design and how others have used it. However, this is not a particularly rare skill set, and would be relatively straightforward to gain for any current design tool, with a more complex tool requiring more extensive study than a smaller, simpler one.

127

Chapter 7

Evaluating the Implementation of Design Assistant for StudyCrafter

In this chapter I demonstrate the suitability of the Progression Map’s design abstraction and communicative function for use by novice designers. I report on two studies, a focus group and a usability study, where Progression Maps, as implemented and visualized within the StudyCrafter Design Assistant (the Assistant), were evaluated in terms of their usability, perceived usefulness, and readability, focusing on novice designers. As this is the ﬁrst evaluation for this new design analysis tool, formative evaluation is more suitable in order to examine the nuances of how the tool and the maps were perceived and used. That coupled with the small number of participants recruited for the studies (7 for the usability study, 4 for the focus group), resulted in both studies being analyzed qualitatively. Given that low number of participants are recommended for both focus group and usability studies (Nielsen and Mack, 1994), this was deemed to be acceptable as a ﬁrst evaluation of the tool. The results show that Progression Maps provide a suitable design abstraction that is understandable and recognizable by novice designers, and participants understood conceptually complex node types like differences between Event and Feed- back nodes, as well as Forks. Participants found the maps easy to follow and read, making it suitable to facilitate communication regarding interactive narrative design.

7.1 Evaluation

Two studies, a focus group and a usability study, were conducted in order to evaluate the Progression Map’s design abstraction and communicative function. Specif- ically, the studies were meant to evaluate the suitability of the Progression Maps and its visualization capabilities for novice designers. A focus group study was conducted to collect information on how novice designers think about and analyze interaction in interactive narrative games, and in that light, how they would assess usability, readability, and perceived usefulness of Progression Maps as a conceptual framework that would allow for a gauge of how well the conceptual abstraction was 128Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter understood. A usability study was then conducted to directly assess the readability of the maps and the utility of the StudyCrafter Design Assistant (The Assistant). Both studies were conducted in the Human Factors Lab at the University of Houston-Clear Lake (UHCL), using StudyCrafter (version 2.3.5.) and the Assistant described in section6. None of the researchers who conducted either study were directly involved in the development of either StudyCrafter or the Assistant. Further, none were involved with the development of the Progression Maps model. They were given information about the rendering and elements thereof, but only as it per- tained to the design tool, not the underlying theoretical approach. For both studies, the researchers informed participants that they had no personal involvement with the development of the tool and that any feedback would not affect them personally in any way.

7.1.1 Focus Group Methodology

The role of the focus group study was to both gain information about how novice designers would think about and analyze interaction in interactive narrative games, and how, subsequently, they would assess Progression Maps as a conceptual framework for that purpose. Further, it was meant to explore the novice designers’ conceptual understanding and ability to read the analysis generated by the tool. Additional goals included understanding whether they could identify key points of interaction within an interactive narrative. Participants were recruited from the campus and community population of UHCL. Their suitability was determined through a screening survey (see AppendixD), where they were asked about their age and their experience with video games, interactive narrative games, and StudyCrafter as a platform. After the survey 5 participants were recruited, and all had experience with playing video games. For the final focus group, 4 participants were present, 3 male and 1 female. Of those, 3 had previous experience with StudyCrafter as a platform, and 1 had no experience. This sample size is lower than is normally recommended for usability (Nielsen and Mack, 1994), and thus the results here are not to be considered alone. Together with the usability study, however, these evaluations can provide insights on the usability of the proposed model (see discussion in 7.2). Three research staff were present for the study. Two acted as moderators, and one took notes on the conversation. The moderators sat on opposite ends of the group, while the note-taker sat away from the group in the corner of the room. The note taker and moderators collected notes in a collaborative document. A moderator script was used to ensure consistency and guide questions. The focus group schedule was presented to participants upon arrival. Partici- pants were asked to provide consent and told that the session would take one and a half hours. Once consent was given, the focus group started with a 45-minute session, starting with a moderated discussion on interactive narrative gaming. This 7.1. Evaluation 129 was designed to assess the participants’ understanding of this type of gaming experience and to determine what they valued in interactive narrative design. This discussion served to prime participants for the main activity of the session, which was the creation of their own individual rendering of a snapshot of an interactive scene within a game. They were asked to design a visualization that would allow a player to identify where they are in the scene in terms of interaction and the different outcomes that were possible in the scene. They were given a large piece of paper and writing tools to render the scene. Further, they were explicitly asked to consider interactions, such as dialogue, actions, player choices, and endings. After they had finished their rendering, they were asked to hand their rendering over to another person within the group, who was then asked to explain it to the rest of the group. After the explanation was complete, the participant who created the rendering would confirm or deny the explanation and clarify their rendering if necessary. Participants then took a 15-minute break, after which they engaged in a 25- minute assessment of output generated using the design tool. StudyCrafter was introduced to the participants, and a short scene was created for the participants by a moderator. Then, the Assistant was introduced as a new feature for the platform, and the moderator displayed the Assistant’s rendering of the scene. This was displayed on a large screen to ensure that participants were able to clearly see all the elements of both the rendering and the StudyCrafter scripting interface. Partic- ipants did not interact directly with either the StudyCrafter scene or the Assistant. They were handed print-out versions of the rendering and asked questions about their previous rendering. They discussed the analysis in terms of higher-level interaction in a language that was deliberately kept different from the rendering. For instance, the moderator asked participants to identify action points, decision and dialogue points, and storyline pathways. To conclude the session, participants filled out a debriefing questionnaire to assess their attitude towards the Assistant.

7.1.2 Usability Study Methodology

The usability study was meant to directly assess the usability and readability of the Assistant, and how it would support interactive narrative design in its current state. This was to more directly evaluate both the abstraction and the communicative function of the maps, through more direct and concrete interaction, and a design task. Participants were recruited from the campus and community population of UHCL. Participants were required to have experience with playing games and to be novice interactive narrative or game designers. After being recruited, participants were asked to fill out a screening survey (see AppendixD) to determine whether they met these criteria. A total of 7 participants were recruited, 6 male and 1 female, all with a familiarity with interactive narrative games. Because usability studies do not require a large number of participants, with five being the recommended number (Nielsen and Mack, 1994), we deemed seven as sufficient for this study. Participants were from varied employment backgrounds, and none had experience as a professional 130Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter game designer. All participants rated themselves as being advanced or expert video game players, declaring good familiarity with a variety of different genres. None of the participants had used or were familiar with StudyCrafter as a platform. Each participant was seated in front of a PC with a dual monitor setup. A moderator was seated close to the participant, with a note-taker seated slightly farther away. The participant, led by the moderator, interacted directly with StudyCrafter and the rendering from the tool. The participant saw but did not interact with the tool interface directly. A moderator script was used to ensure consistency across all participants. Upon arrival, participants were introduced to the moderator and note-taker, and asked to provide informed consent, after which they were given instructions for the session and asked to complete a pre-session survey to provide demographic information, game experience, and familiarity with StudyCrafter. Due to none of the participants being familiar with StudyCrafter, all participants were given instructions and demonstration on how to use the platform. All participants were able to overcome design challenges and successfully execute their tasks during the introduction. After familiarizing themselves with StudyCrafter, participants were shown and asked to interact with a simple interactive scene, and provided with two types of analysis: rendering of the scene through the script graph, a close representation of StudyCrafter’s scriptor interface rendering of the scene (produced by the Assistant) (A1), and a Progression Map rendering from the Assistant (A2). Participants were asked a series of questions that encouraged them to compare the A1 rendering and the scene they had played. Then participants were shown and asked to interact with a more complex scene and provided with a rendering of just A2. Participants were asked to compare the A2 rendering to the scene they had played. After which they were asked a series of questions that encouraged them to compare the two renderings of the game they had played, such as “How do the two analyses relate to each other”, “Were either of these analyses helpful overall?”, and “Was one more helpful than the other?” Upon completing the comparison tasks, participants were given 10 minutes to create the most complex scene that they could in StudyCrafter. They were given creative freedom, but were instructed to:

• Create an environment

• Add at least two characters to the scene

• Have one character move across the screen

• Have two characters interact or have a dialogue with each other

• Have the player make a choice

• Add one more element of their choice 7.1. Evaluation 131

• End the scene

After this design portion, and after the moderator had made sure the scene was able to run without errors, participants were given a short break. Then, they were shown the Assistant. They were shown how the tool was used to generate a rendering of the scene they had created. Both the script graphs and the Progression Maps were displayed on a large screen, separate from the StudyCrafter window. At this time, participants were asked how the analysis related to the scene they had just created, and if it was mapped out in a way that they understood. After that, participants were asked to identify how the script rendering of their scene, within StudyCrafter, related to the two renderings from the Assistant, if there was anything missing or unclear about the analysis, and how the two representations differed. They were then asked whether the analysis was helpful overall, and whether they wanted to provide additional feedback. Finally, each participant was asked to answer a debrieﬁng questionnaire about their attitude towards the tool, about its clarity and usability, and about their general suggestions for improvement.

7.1.3 Results

Focus Group

In the first moderated discussion, participants showed a clear understanding of narrative-heavy gaming across a variety of genres and platforms. Participants indicated that, for them, an abundance of choices, interaction points, and general cus- tomizability were the most important elements in their interactive narrative experiences. When asked to render a snapshot of a narrative scene from a game of their choosing, participants struggled. The choice of scenes to render came from games spanning a variety of genres, including Dark Souls (darksouls) and Mortal Kombat 11 (mk11). When rendering the scenes, the participants had difficulty explaining the interaction without drawing it using a very literal interpretation, similar to a snapshot picture of environment, character, and element placements to represent a moment either in a playthrough or in the story, or describing the graphic elements, such as head-up display (HUD) elements displayed on the screen. In the second session, after being shown the scene in StudyCrafter and the rendering produced by the Assistant, all participants rated the helpfulness of the analysis a “4” on a 5-point scale. In terms of usability and readability, all participants agreed that the rendering was simple and well organized and was suitable to provide large scale analysis. One participant commented that the map “looks good and I understand it - it does not look like a mess, it’s organized” (FG-P2). In terms of usefulness to design, two out of the four agreed that it would be helpful with troubleshooting their design, and two out of the four agreed that it would make it easy for them to trace back events. Describing the Progression Maps as being “not over- flowing with detail” (FG-P1) and “simple” (FG-P2), with one participant stating that 132Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter they liked “having a big overview of what is happening” (FG-P3), further describing the maps as being “helpful with troubleshooting designs” (FG-P3).

FIGURE 7.1: An example of the numbering scheme that participants agreed was distracting and unclear. In this ﬁgure the ﬁrst two Event nodes are labeled 8 and 9 respectively, followed by three possible Feedback nodes labeled 64, 11, and 55 respectively. The numbering scheme corresponded to the StudyCrafter script graph nodes which did not correspond to the Progression Map layout.

The participants identiﬁed shortcomings in readability. All participants agreed that the node numbering that was included for all node types was distracting. The numbering scheme corresponded to the StudyCrafter script graph nodes which did not correspond to the Progression Map layout, and thus did not make logical sense to the participants in the context of the maps. Participants commented that “the numbering is confusing” (FG-P1) and “the numbers should restart” (FG-P4). They suggested that color coding would make the map easier to read (“I need color coding for [nodes] if I am looking at it from a high point, I don’t know what’s in the boxes. I need colors” (FG-P3)), and that arrow direction was not always clear (“Ar- rows might get too confusing.” (FG-P1)). Two out of four said that they wanted the maps to differentiate between interaction that was perceivable to the player and that which was not (“make clear where there is back end generated and what is front 7.1. Evaluation 133 ended” (FG-P3)). Only one node type in the model represents system-facing interaction: Forks. Notably, that was the only node type that caused confusion in terms of terminology, with all 4 participants not being initially certain what it referred to. After the concept was deﬁned and explained, participants understood it. However, they did not see the name as suitably descriptive and one participant commented on its visualization (“forks on lines, what are those?” (FG-P1)). In the debrief questionnaire, all participants indicated that they would use the tool in their design process, rating its usefulness on average as 8/10 (7,8,9,8). How- ever, all stated during the second session that it would be cumbersome if it were a separate program from StudyCrafter (as it currently is), and that it would need to be integrated directly into the platform for effective use (with two participants describing it as being “cumbersome” (FG-P3, FG-P4) if it wasn’t), and to provide real-time feedback (“You want to see it as you are building it, live as you are going” (FG-P4), “If I make a chance I want to see it here, I would toggle back and forth)” (FG-P3)). Finally, all participants envisioned the tool as being useful outside of interactive narrative design, with one indicating that it would be good for “planning out other interactive tasks like handling an emergency.” (FG-P1).

Usability Study

In the first comparison tasks (Part 2, task 1 and 2) all participants understood that both the script graph and the Progression Map were the same scene that they had observed. In both cases, six of the seven found them to be appropriately mapped and understandable. When asked how the two renderings of the same scene related to each other, participants described the script graph as an overview in comparison with the Progression Map (“A2 is more detailed, A1 is an overview” (U-P4)). Participants understood that they showed the same information, and identified the Progression Map as significantly more detailed, showing deeper understanding of relationships between elements, and mapped better than the script graph (“They are the same, just more details on the second one [A2]” (U-P7), “[A1] is like reading spark notes, the [A2] like a novel” (U-P1)). One noted that the Progression Map was, as a result, more complicated to understand (U-P6). In terms of usefulness, six of seven participants agreed that both renderings were helpful overall, where four rated the Progression Map as more helpful than the script graph, two rated them equally helpful, and one found the script graph more helpful. When asked to provide additional feedback, three of the seven noted that A2 was more complex than A1. For the second task (part 3), after completing the creation of a scene, all participants understood that the Progression Map they were shown was of the scene they had created and found it to be easy to understand. At this point, six of the seven stated that they found the Progression Maps helpful, and agreed that they found them straightforward and helpful with advanced designs. They commented that they would want the tool to have a filter to show only information what the 134Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter designer needed, and that the map would be most helpful if generated during the design process so that it could be accessed as they were building. In the debriefing questionnaire, participants noted that the Progression Maps laid out complex scenes well and clearly (“I enjoyed how clear everything was displayed” (U-P3), “When it came to complex scenes with the randomization of choices, it was nice to have all processes and actions laid out.” (U-P2)), broke down the design elements in a manner that was easy to follow (“I liked that it broke down tasks. It made it very easy to follow the script.” (U-P5)), made it easy to understand the flow of choices and events in the scenes (“I liked the direct flow it displayed.” (U- P3), “Seems like a simple path to understand the flow of choices and events” (U-P6)), and allowed them to gauge the directionality of, and lengths of paths between, elements (“I was able to see where objects were moving to and how long it takes to get there” (U-P7)). They also noted that the tool itself was simple to use (U-P1). Participants found that the Progression Map presented too much information (“lots of information in each choice box especially” (U-P7)), and that it required more clarification in terms of what design elements it was referring to within StudyCrafter. They also mentioned this in regards to visual clutter in the rendering of the maps. Most notably, all participants agreed that the language and terminology used was easy to understand, and that the Progression Map was clearly laid out in terms of how elements connected and how the information was organized (“It’s easy to tell how the info is organized and connects” (U-P2), “It was all clear to me.” (U- P3), “Language is clear, easy to understand.” (U-P7)). On average, the script graph (StudyCrafter script node data based on its editor) was scored 6.9 out of 10 on usability. It was found to be easy to read and participants said it looked good when the scene was simple (“It looked good for simple things.” (U-P3)), but that it provided no additional value (U-P4), its information was too general (U-P5), and it was visually cluttered (U-P4, U-P7). For the Progression Map, participants scored it a 7.4 out of 10 on usability. Its vertical layout was seen as good, and the Progression Maps were perceived as more helpful than the script graph for more complex scenes (“I enjoyed the attention to detail. It would help me in recreation more than A1.” (U- P3)). However, as a result of this complexity, it was deemed to need improvements in terms of its layout (“There needs to be a more efficient format for complex scenes” (U-P5). All participants agreed that they would use the Assistant if it were available, especially for more complex scenes, as it was easy to use to verify design intention for the interaction and to troubleshoot the design (mentioned by two out of seven, “I would because it seems like a very useful tool for troubleshooting specific tasks in narratives” (U-P5), “yes, easier to go through, and verify each piece is going to do what I want instead of having to go through the entire game” (U-P7)), especially if they intended to make more complex scenes (mentioned by four out of seven, “Actually yes, if I was creating complex [narratives]” (U-P4), , “yes, but because it is very easy to use” (U-P6), ). 7.2. Discussion 135

To improve the Progression Maps, participants suggested some readability changes, such as changing the fonts, simplifying the node layout, and ensuring that the text within the nodes was centered. One participant offered suggestions that were specific to the data structures present within StudyCrafter. The only comment on the representation itself was a suggestion to rename the Fork node to Branch (U-P5). No- tably, none of the participants had difficulty understanding the Fork node concept, indicating the name as a possible cause of confusion. Participants indicated that it was helpful to see the overall picture, which allowed them to follow different paths. They also said that the separation between Inputs and Events was helpful. However, the amount of detail available in the analysis created a level of difficulty that some participants found challenging to overcome. To this effect, some suggested different formatting, such as color coding or different font formats. Further, participants indicated that switches between vertical and diagonal flow created difficulty in reading the maps. All said that they would find the model useful if it were incorporated into interactive narrative systems.

7.2 Discussion

Overall, participants had little issue with understanding the different nodes in the map and what design elements they were meant to represent. They made no comments or requests for clarification of the representation, indicating that they found it intuitive and straightforward, and that the maps’ abstraction was suitable to their design task. Further, they appeared to understand differences between conceptually similar, perception-dependent node types like Events and Feedback. Participants understood the Progression Maps as a representation of the StudyCrafter projects they were shown in almost all cases (and in all cases when the maps were within a design context), adding to the support of their design abstraction being composed of relevant elements to interactive narrative. Additionally, participants stated that the maps were showing details of the design. One described the script graphs as an overview, but the Progression Maps as “more detailed, but in a good way.” (U-P4). The only exception to understanding the Progression Model representation were Fork nodes, notably the only node type that represents system-facing interaction. They are often used to offer a more seamless experience for branching narratives where the intention is to not have the presence of a branching choice disrupt the user experience by requiring interaction during a high-stakes moment. This is a more advanced design pattern than novice designers would have been likely to start out with. However, the participants who commented on Fork nodes, when given the clarification of the term, seemed to find the name Fork confusing, rather than the concept. This indicates that a name change to something more likely to be familiar for novice designers, such as hidden branching, or simply branching, might be more suitable. 136Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter

Participants reported finding the Progression Maps more useful than the script representation, that the former make it easy to understand the scene and its layout, and that they are mapped out appropriately and easy to read. However, they comment on some difficulties in understanding the maps. Rather than stemming from the abstraction or the nodes conceptually, these difficulties seem to be caused by elements that relate directly to the visual complexity of the maps. The maps are visualized in a flat layout, which shows the entire scope of the interaction possibilities in the scene. The visual complexity of the maps increases as the number of nodes in the maps increases. This will make the maps for large scenes harder to parse. Partic- ipants suggested inclusion of features that would allow collapsing and expanding nodes and interaction units, so that only interaction units of interest would be shown in full detail. These feature suggestions are in line with other comments that indicate that they had difficulty in processing the amount of information included in the nodes. In addition, some of the information was not being sufficiently contextualized to assist them. Primarily, participants commented on confusion about the node numbering scheme, which was generated in an order based on the corresponding script graph. An example of this numbering scheme, for Fork edges, is shown in Figure 7.2.

1: Fork

Script: 7 - if Type: deterministic Conditions: 36: {Character} == 0 38: {Character} == 1 40: True Variables: Character

Fork: 36 Fork: 38 Fork: 40

2: Event 21: Event 23: Event

FIGURE 7.2: An example of a fork, generated from one of the projects described by Partlan et al. (Partlan et al., 2019). The edges out of the fork are annotated with their corresponding condition identiﬁers.

In addition to collapsible nodes and interaction units, participants suggested search features, detail and summary features, and a visibility toggle for information that they perceived to be relevant or not. All of these features will be considered in 7.2. Discussion 137 future versions of the tool, but it is notable that none of the major issues reported by participants in either study were directed at the Progression Maps conceptually as a model. Participants generally did not comment on whether or in what way their design impacted the player experience. This is not surprising, given that all were novice designers. Further, they likely did not have time to reflect on the player experience during the study, as they were not directly prompted to do so. Both studies found that participants reported the Progression Maps to be recognizable representations of their own and others’ StudyCrafter games, which indicates that the basic elements, aside for the naming of Forks and numbering of nodes, were understandable and self-explanatory. Difficulties emerged when it came to the visualization, as well as its static form, which did not enable the participants to interact with and search the maps as they described wanting to do. Overall, these results indicate that the elements of the Progression Maps are conceptually appropriate for novice designers, and that improvements from previous versions of the maps and implementations thereof have been successful in improving issues identified in previous work by Partlan et al. Partlan et al., 2019. Future work should aim at improving readability and increasing interactive functionality for the designer. There are several results that support the claim that the Progression Maps are suitable to communicate about interactive narrative design, and that they can be used to discuss the player experience. The participants, all of which were unfamiliar with Progression Maps before the study, had little to no issue understanding the representation, as well as the visualization, despite visual clutter, making minor to no comments or requests for clarification, indicating that it was found to be intuitive and straightforward for novice designers. Further, participants understood conceptually complex node types, and the differences between them, which can serve as a foundation for common ground reasoning. Although this is a positive indicator, further studies are required to explore and test this more concretely. Finally, our results indicate that participants saw the Progression Maps as containing more information than a direct visualization of a StudyCrafter script. Par- ticipants described the maps as giving them a simple way to follow the flow of the player experience, commenting: "When it came to complex scenes with the randomization of choices it was nice to have all processes and actions laid out." (U-P4); "[The script graph] is like reading spark nodes, the [Progression Maps] like a novel." (U- P1). The Progression Maps were described as enabling "deep understanding and [the map] was significantly more detailed [than the script graphs]." (U-P2). This might indicate that the maps are perceived by these novice designers to contain more information than just the script, and that, because of this direct analysis of player interaction, they as designers have access to more analysis tools. Further research is needed to empirically determine what information they believe they are gaining from the Progression Maps and how they would use it. This will be explored in future work. 138Chapter 7. Evaluating the Implementation of Design Assistant for StudyCrafter

Limitations

The studies presented here were both qualitative, with a small sample of participants who were culturally homogeneous and had, on average, high video game playing experience. As such, the model’s use has not been evaluated for all groups of novice designers. In particular, it would be highly relevant, in light of the results, to examine whether novice designers with limited video game experience would similarly ﬁnd Progression Maps as accessible and easy to understand. Further, the tasks given to participants in the studies focused on analysis and evaluation of the model, and while the usability study did contain a constrained design task, it did not represent a real life task where the designer needs to make an engaging experience for real players. As such, this study did not assess the long- term suitability of the model. Future work will need to explore the use of the model in more complex, longer-term design tasks, with different groups of researchers and practitioners, to further evaluate the model’s value to the design process.

Improvements for the Assistant

As discussed previously, participants expressed several points of confusion and ideas for future improvement for both the model and the Assistant. For instance, they reported non-sequential numbering as inconsistent and confusing. This appeared to be due to numbering that related Progression Map elements to nodes in the script graph. Notably, the IU ID numbers were not confusing. These concerns will be addressed in future work. To help alleviate any remaining confusion, and to introduce new terms such as Forks, providing scaffolding, such as examples, manuals, and in- tool instructions, will be provided in future to assist participants in understanding the terminology and use of the maps. In addition, participants suggested visual improvements to allow the nodes to be differentiated at a glance. Simple changes, such as different shapes, colors, font sizes, and formatting, would all be helpful improvements here. In future work, those parameters will be changed to improve readability. Finally, and unsurprisingly, the results indicate that designers’ tolerances for visual and informational complexity will vary. Participants expressed preferences for layout (horizontal or vertical), and the amount of information visible at any given time. Participants also requested that the tool be made more interactive, with functionality allowing them to abstract, ﬁlter, or choose information that is presented. These improvements are another fruitful avenue for future work.

Conclusion

The results of these studies suggest that participants ﬁnd Progression Maps to be understandable, with little trouble understanding the phenomena represented by each map node. The only node type that they had issues with was the Fork, but with its name rather than the concept. Further, conceptually similar nodes like Events and 7.2. Discussion 139

Feedback were correctly understood as similar, except in their relation to player interaction. Participants understood Progression Maps to represent an in-depth analysis of the projects used and created in the studies. They gave higher ratings for the usability of Progression Maps than for a script graph rendering of the same scenes. As a result, Progression Maps can be said to be suitable as a model and basis for visualization of interactive narrative design for novice designers. They might therefore also be of use to experienced designers, which will be explored in future studies.

141

Chapter 8

Conclusion

In this dissertation, I focused on the development of abstraction models that can be used to visually analyze interactive narrative structures in an effort to enhance the design and user experience within an interactive narrative. In doing so, I have addressed the two main research questions introduced in the introduction. In this conclusion, I will ﬁrst start by discussing the contributions of this dissertation in relation to these research questions and will then move on to discuss limitations and future work.

8.1 Interactive Narrative Design Abstraction

Research Question 1 (RQ1): How to develop an interactive narrative design abstraction, which is suitable for developing a computational model for design analysis and visualization, while maintaining sufﬁcient descriptive and communicative ﬂexibility for novice designers, and how can such an abstraction be applied?

To address RQ1, I conducted a study to examine interaction design in terms of progression and player experience in commercial narrative-focused digital games. From this study, I developed the Progression Model, a descriptive model of interaction design for interactive narratives, through iterative thematic study of commercial interactive narratives and narrative-driven games. (see fig. 8.1). The central focus of the Progression Model is to capture an abstraction of interactive narrative design as it relates to story progression and player experience. It is the first descriptive model of interaction design for interactive narratives, and as such a central contribution of this dissertation work. The Progression Model further established the theoretical basis for Progression Maps, and their approach to interaction design abstraction. Progression Maps are a graph-based, descriptive model of moment-to-moment interaction design, meant to capture narrative progression interaction from the perspective of the player. The different Progression Map node types are shown in fig. 8.2. The model can be represented computationally due to its graph-based nature and thus can serve as a basis on which to build a computational representation of interaction design within interactive narratives. Such a model will enable us to create 142 Chapter 8. Conclusion

FIGURE 8.1: The Progression Model consist of 5 factors: Structure, Progression Mechanics, Interaction, Presentation, and Action Set. automated design support tools for interactive narratives, provide the basis for interaction design diagnostics such as metrics, and facilitate communication between designers through visualization. The Progression Maps provide visualization where the various narrative paths available to the player are clearly differentiated based on story progression, with each of the corresponding elements capturing the flow of information, either outgoing from the game itself, or incoming from the player, as stipulated and constrained by the graphs. Further, the Progression Maps can be used to compare different narrative designs at a glance (see fig. 8.3), showing how the interaction flow can differ in terms of scale and complexity between different designs. In this way, Progression Maps represent what and when information is presented to the player, in addition to how the interaction is structured in terms of impact on story progression. To evaluate whether Progression Maps are suitable for design communication, an in-depth qualitative study was conducted to examine the communicative capabilities of the maps. The study demonstrated the ability of the Progression Maps as 8.1. Interactive Narrative Design Abstraction 143

FIGURE 8.2: The Progression Map nodes and their relationships. a model to capture salient interactions of an interactive narrative at a granular level. The Maps can be used to create concrete depictions of the interaction design, enabling discussion and communication of design choices and insights that are foundational for design communication. The Maps allowed designers to analyze and identify critical elements of an existing design. Further informing the analysis was how the Progression Maps enabled designers to communicate about a shared experience and the ways in which their experiences differed due to their own biases, experience level, and professional focus. Despite the Progression Maps being produced by hand and differing both in their formatting and ordering of elements, the maps were sufﬁciently deﬁned so that differences were reported to be intelligible and meaningful between participants, facilitating surfacing and reasoning. This further demonstrated how the Progression Maps might reveal individual differences and biases in perception, and how they can be surfaced and understood through the mapping process. 144 Chapter 8. Conclusion

FIGURE 8.3: Visualizations of a single scene from 3 different Study- Crafter Projects. The Progression Maps show at a glance how the interaction ﬂow of each scene differs in terms of size and complexity.

These results show that Progression Maps are a suitable interactive narrative design abstraction, and that they have sufﬁciently descriptive and communicative ﬂex- ibility for designers, addressing core parts of RQ1. Furthermore, the results show that Progression Maps can be used to abstract the interaction design of an existing artifact and visualized for analysis, as all the designers could recognize and reason about each other’s Progression Maps without explanation from the original cartographer.

8.2 Automated Structural Analysis

Research Question 2 (RQ2): Can we build a generalized architecture for building automated structural analysis tools for interactive narrative, where the design is abstracted from an existing artifact and visualized?

Addressing RQ2, I demonstrated how the Progression Maps can be used for automated generation of existing interactive narrative artifacts. The Design Assistant Architecture (seen in ﬁg. 8.4) was proposed as a ﬁrst step towards achieving this, showing a cohesive approach to how such automated generative systems can be built for narrative construction tools. I described how Progression Maps can be automatically generated from an interactive narrative construction tool or software, deriving and visualizing important details of the structure of the narrative and its 8.2. Automated Structural Analysis 145

Layout Script Meta Layout Script Meta Data Data Data Graph Graph Data

Scene Scene Data Graph

Tool Specific Representation MapGraph

Narrative Progression Mapping System Design Assistant Map Construction Tool

Mapping Prog. Map Rules Algorithm

Temporal Structure

FIGURE 8.4: The Design Assistant Architecture. The architecture can be adapted to any existing narrative construction tool. A tool-specific representation consisting of layout, script, and meta data for a project, is passed into a mapping system that formats the tool representation into a MapGraph, which contains a graph representation of the tool. Finally, the MapGraph is processed by the Design Assistant in order to generate a Design Assistant graph, which is a form of an applied Progression Map. interactions with the user. This system and computational representation is the De- sign Assistant. In addition, I presented an implementation of this computational model in one such interactive narrative tool: StudyCrafter (Harteveld et al., 2017). I showed how the Design Assistant can be used to automatically derive Progression Maps from multiple StudyCrafter projects and how the maps were derived from the underlying representation of StudyCrafter’s scripting editor. Two evaluation studies conducted on the StudyCrafter Design Assistant examined the usability, readability, design abstraction, and communicative capabilities of the Design Assistant graphs, which are a form of Progression Maps produced by the Design Assistant. The studies suggest that novice designers find Progression Maps to be understandable, with little trouble interpreting the phenomena represented by each map node. Conceptually similar nodes like Events and Feedback were correctly understood as similar, except in their relation to player interaction. Only one node type, Fork, was identified by participants as being confusing, but that was due to its name, rather than its conceptual abstraction, which the participants had no difficulty understanding. Participants understood that Progression Maps represented an in-depth analysis of the projects used and created in the studies. They gave higher ratings for the usability of Progression Maps than they did for a script graph rendering based on the StudyCrafter representation of the same scenes. As a result, 146 Chapter 8. Conclusion

Progression Maps can be said to be suitable as a model and as a basis for visualization of interactive narrative design for novice designers. Progression Maps might therefore also be of use to experienced designers, which will be explored in future studies.

8.3 Contribution

This dissertation makes two major contributions to the field of interactive narrative research. First, I present the Progression Model, the first descriptive model of interaction design for interactive narratives. Its central focus is to capture interactive narrative design in terms of how it relates to story progression and player experience. The Progression Model is used for qualitative analysis and instantiated as a computational model. Second, this dissertation presents the first automated structural analysis architecture for interactive narrative design, the Design Assistant Architec- ture. The architecture is meant to be built on top of existing tools, making it suitable across a number of narrative construction tools. Further, this dissertation shows the first interactive narrative models built on a player-centric view of narrative progression, with a specific focus on capturing interaction design.

8.4 Limitations

There are a few limitations to the work presented in this dissertation which I shall discuss below. First is the applicability of the Progression Maps to different genres and types of narrative experiences, particularly narrative experiences that are not, at first glance, structured in a manner that compliments a graph-based representation. These experiences include, most notably, emergent narratives, as well as narratives that utilize hidden structures or opportunistic structures. As an illustrative example, emergent narratives, as the name suggests, emerge from systems within the game world interacting. Forms of these interacting systems can include narratives that are generated without input from the player, generated as a result of an input from the player, or even generated as a series of events that is later narrated by a player to others. Emer- gent narratives are rarely authored and are not designed to be a pre-determined sequence of specific interactions. The current version of Progression Maps, which is framed around progression interaction specifically, does not have a defined way of representing distributed, interconnected events like those present in emergent narratives. While such a distributed structure might already be assumed for certain elements within Progression Maps, which will be discussed later in this section, the Progression Maps do not have a defined manner in which to do so. However, emergent narratives and narratives which have distributed story events that do not conform to a graph-based story structure can still be described using Progression Maps, albeit through the lens of player experience. Although the Progression Maps 8.4. Limitations 147 would not describe the narrative’s entire interaction possibility space, they can be used to record playtraces of individual player experiences. A playtrace here refers to a recording of a player’s behavior and actions during a game play session. A single playtrace corresponds to a single session. Using Progression Maps in that manner, it is possible to document each interaction the player has with the emergent narrative as a new interaction unit. Each unit can describe what the player believes their options are at that given moment in time, document the information presented to the player before and after the interaction, as well as input the player provides. This would result in a Progression Map with a linear structure, but it would capture what the player believes to be their action space within each interaction unit they encounter nonetheless. On the topic of structural assumptions within Progression Maps, it is worth noting that the current version of the Progression Maps does not explicitly address certain design assumptions. Mainly, the assumption that they have, or might require, a multi-layered construction of more than one Progression Map to fully capture certain design, and how these layers seem to be assumed for certain node types without being defined. The most notable example of these assumptions is linked to the Constraints node type. Constraints nodes correspond to any element or condition that constrains the player’s ability to take action during an interaction, but these elements do not automatically activate (or are baked into the interaction by default) and are dependent on player actions. Constraints are either discrete or systemic. Dis- crete refers to mechanical elements that are isolated and specific to the local scope of the interaction unit and have no consequence outside that scope. Systemic refers to mechanical elements that are related to an external game system and are determined by elements outside the interaction unit. (See Chapter4 for a examples and further discussion). Within this definition, especially for Systemic Constraints, lies the assumption of an interlinked graph structure that dictates and informs conditions within and across interaction units. This layer, which I will call the Constraints layer, has not been explicitly defined nor explored in relation to Progression Maps. Due to the dissertation specifically targeting novice designers, Constraints, which can be considered part of an advanced set of design patterns, did not appear in the designs they provided for the evaluation study. In addition, while the artifact in the design communication study did contain such constraints, they were not surfaced in the maps which were produced in the study. This lack of surfacing may denote that that the segment of the narrative which was studied did not show nor contain an explicit example of Constraints as defined in the context of Progression Maps. This assumption will be explored and expanded upon in future work. The assumption of further hidden layers within the Progression Maps poses an interesting set of questions; not just whether there are additional assumptions that have not been identified within Progression Maps as a model, but also the manner in which interactive narrative design abstraction should be considered. The complexities of interactive narrative, both within its design and as an experience, require 148 Chapter 8. Conclusion multiple structures that are related while being internally connected to be considered. Interaction design, as captured by Progression Maps, is an example one such structure. However, these structures also include plot and character arcs, dialog, narrative impact, and constraints, along with many others. These additional components fit together to make up the entirety of the design. Most are already known in the field and some have been abstracted and even visualized using graph-based structures, such as plot graphs (Thue and Carstensdottir, 2018). Further study is required in order to determine how these layers fit together. Exploring how existing work can be constructed as an additional layer in a multi- layered approach to narrative design would allow for a fascinating approach to creating graph-based design abstractions for a broader set of interactive narrative design elements and considerations. One example of how these layers could potentially be combined is by creating a mapping between interaction design as represented by Progression Maps and an abstracted representations of story content such as plot. This example merges interaction design and story content, which is represented in existing literature by a rich body of work. In regards to the Design Assistant architecture, it is worth noting that the mapping process will require human intervention. At this stage of development, it is yet not clear how much domain knowledge and specialization building the mapping rules requires, or how complex the task will be. For a smaller design platform like StudyCrafter, the mapping process is a manageable task for a single expert or small team, although it does require a basic knowledge of the inner workings of the tool itself, knowledge of how to use it, and familiarity with how it is used by its target audience. Therefore, it stands to reason that the mapping process is not a trivial task. It requires a specific set of skills such as knowledge of the tool both as a designer and as a programmer, and experience and knowledge of how it can be used for design as well as an awareness of how others have used it previously. However, this is not a particularly rare skill set, and it would be relatively straightforward to gain for any current design tool, although scaling up with the complexity of the tool would require more extensive study than that which was conducted for the dissertation. The studies that were used to evaluate the claims of Progression Maps are all qualitative and have a small sample size of participants. These participants are culturally homogeneous and had, on average, high video game playing experience or interactive narrative design experience. As such, the Progression Maps have not been evaluated for designers above the novice level, nor demonstrated as being effective over a large population. In addition, the tasks given to the participants in all studies focused on analysis and evaluation of Progression Maps, and while one study did contain a constrained design task, it did not represent a real life task that required making an engaging experience for a real player. As such, the long term suitability of the model has not yet been tested. These shortcomings will be explored in future work, to further evaluate the value and function of Progression Maps as a part of their design process. 8.5. Broader Impact 149

At this early juncture, however, the results are promising and an indicator of the suitability of the Progression Maps, rendering them deserving of further study, particularly as interactive narrative and its structural analysis has not been widely studied in the context of interaction design and player experience. As such, no golden standard or means of comparison exist at this time in order to assess the suitability and efﬁcacy of the Progression Maps compared to other models. While it is my hope that future research efforts will provide additional models and frameworks that can serve as comparisons, there are available none at the time of writing.

8.5 Broader Impact

This dissertation presents foundations on which a large variety of work can be produced. This work could include further development of structural metrics, and studies surrounding their connections with player experience, which is the subject of previous work (Szilas and Ilea, 2014). The Progression Maps already provide a nuanced, detailed, and operationalized framework for interaction design, lending themselves well to heuristic examination and empirical experimental work. Progression Maps could potentially enable and afford a much broader set of design functions and applications than those addressed directly within this dissertation; in particular the 3 domains of computational design analysis, in-person playtesting, and game development and production, which I will discuss in further detail.

8.5.1 Computational Design Analysis

Progression Maps can be used for generating design analytics, such as structural metrics, for existing narrative designs. Structural analysis and metrics were implemented as part of the StudyCrafter Design Assistant and the analysis of the metrics, as well as clustering of a corpus of StudyCrafter projects, is presently in progress. The analysis is based on similar methodology to an early version of a subset of those metrics, based on an earlier version of the Progression Maps Partlan et al., 2018. With further reﬁnement, these metrics can be used to generate descriptive data of the characteristics of the design and sub-sets thereof. This could then give produc- ers and designers immediate feedback and indicate potential structural problems, such as a lack of feedback and the excessive presentation of information, colloqui- ally referred to as "exposition dumping". Another promising use of Progression Maps is their potential as a tool for playtraces. As discussed earlier in this chapter, a playtrace refers to a recording of a player’s behavior and actions during a game play session. Progression Maps can be used to document and record player behavior during a play session. Playtraces and recording player behaviors is already standard industry practice, and it is relatively straightforward to record all of a player’s actions and behaviors within a game. Pro- gression Maps would provide a different angle and abstraction through which such 150 Chapter 8. Conclusion behavior could be recorded, thus relating more directly to story progression and interaction design. Progression Map playtraces can also be used for a variety of applications for playtesting, see section 8.5.2 for a more detailed discussion.

8.5.2 Playtesting

There are significant opportunities for using Progression Maps and the Design As- sistant Architecture as a foundation for automated design diagnostics for player experiences in interactive narratives, which can further serve as a basis for automated playtesting functionalities. As previously discussed, playtesting for interactive narrative, as well as for game design in general, is both expensive and time consuming. It requires multiple, engaged, and skilled human workers, and is vital to the success and quality of the tested design. However, playtesting is not always feasible, especially for smaller teams with fewer resources. Automating playtesting would significantly cut down production costs and time. It would allow designers to perform rudimentary playtesting in order to detect larger flaws faster and cheaper, which would enable more targeted playtesting sessions with smaller sets of players. Playtesting without the presence of human players requires a mechanism capable of either simulating or predicting player responses to the game world. One of the preconditions for such mechanisms is the development of a representation of both its design and the available player interaction, in order to record player behavior and reason about player responses. For player experience a logical approach could in- volve taking the point of view of the player and considering only what is presented to them Progression Maps and the Design Assistant object representation provide such a model. Building a simulation or prediction models for player responses can then take the form of prediction models that make use of statistical or machine learning approaches to predict the probability of an outcome given a particular data set. However, if such a prediction model is not coupled with a visualization that is readable and usable by human designers, its findings risk being misinterpreted, leading to the wrong design elements being emphasized. Future work aiming towards automating playtesting should ensure that its mechanisms are transparent and easily understood by the designers that may utilize it in their design process. Automated playtesting, when coupled with the Progression Maps, has the potential to have a much broader impact outside the realm of games. For example, Pro- gression Maps could be used as a part of a data driven iterative approach to model players and player experiences in relation to interaction design. This has broader implications for the field of Human-Computer Interaction, such as Intelligent User Interfaces and User Modeling. Progression Maps can also be used as foundation upon which additional cognitive processes related to interactive narrative experience can be explored, such as narrative understanding and meaning construction, which has already been studied and discussed within the interactive narrative and game design communities in the context of mechanics as metaphor. Progression Maps offer an operationalized model that can be used for empirical studies, as they 8.5. Broader Impact 151 can demonstrate how the design changes in response to different conditions. This model could allow for more targeted experiments and studies of player perception, understanding, and mental model construction. Progression Maps, when used for design analysis and recording playtraces, afford a variety of applications related to in-person playtesting, which can in turn be applied within academic research. As previously discussed, Progression Maps can be used to record playtraces and capture player behavior during narrative interaction and progression. This can be done automatically, as previously discussed, or manually by an observer during a playtest or academic study. Furthermore, documenting and describing a design beforehand can also function as a map that the observer (or researcher) can use to explore, identify, and mark design elements and patterns of interest. This would also help observers identify where dynamics of interaction unit(s) of interest are being affected, and where changes are needed. Progression Maps can thus be used as a method for standardizing observations, and to help identify player experience issues relating to specific elements, which in turn can help ensure consistency throughout the development process. Alternatively, Progression Maps can also be used as a tool for self-reporting. Giv- ing players an opportunity to describe their experiences using Progression Maps can potentially help reveal their mental model of the design, and identify what they did and did not perceive as a part of different interaction units and patterns. This approach could be used as a formative evaluation method by itself. Furthermore, it can be used to supplement other information to get a nuanced and detailed picture of the kind of experience an interactive narrative game affords at a given moment. For example, combining information about design intention, actual player behavior, and the player’s mental model which impacted said behavior. Using the same model and format allows for direct comparison of all 3 of these elements, allowing for the comparison of the intention, the behavior, and the perception for the same design and experience. This could be done by collecting a map from designers which represents the design of the narrative as they intended it to be (or believe that their artifact delivers), a playtrace of the player’s actual behavior during interaction, and then after the session have the player map out what they perceived their interaction and progression to be. Following the above example, Progression Maps could enable analysis and increase the richness and nuance of the data itself, resulting in an analysis that contains deeper contextual information about the interaction dynamic than what a simple behavior log can provide.

8.5.3 Game Development and Production

The potential applications of Progression Maps to game development and production are numerous, and encompass the aforementioned methods and considerations discussed in the two previous sections. In addition to facilitating design communication through visualization and standardized representation, Progression Maps 152 Chapter 8. Conclusion can potentially be used to surface and identify user experience issues in early development. This is due to the player-centric focus of both the visualization and the process of building the Progression Maps. Progression Maps also have potential to be used during pre-production for sto- ryboarding and prototyping. By using Progression Maps, designers could not only present the story layout and content, but simultaneously include information about the ﬂow and presentation of story as it will be interacted with and experienced by the player. This application of the Progression Maps has strong potential to be valuable to larger development teams with multiple stakeholders. Larger teams can contain stakeholders from areas like marketing and sales. These stakeholders are in all probability design novices but nevertheless need to be able to comprehend and evaluate the experience in order to determine its viability and understand the designers’ intended vision. In addition, Progression Maps would provide a quick and low-ﬁdelity way of drafting the key aspects of the experience, so that production of interactive prototypes, or non-interactive storyboards, would not be required as early in the development process as is common industry practice. This could potentially save developers resources and time, which would allow them to design, iterate on, and pitch ideas faster and more effectively.

8.6 Future Work

In the immediate future, I plan to implement improvements to the StudyCrafter De- sign Assistant, and then conduct further studies with the goal of fully exploring and evaluating as the full impact of the Design Assistant. Moreover, visualization and readability issues require improvement, as per study ﬁndings (see Chapter5). Such improvements would allow for a better evaluation and improve usability and readability of the Design Assistant Graphs, in addition to access to more StudyCrafter projects and targeted data collection. This work is currently in progress. Further implementation of the Design Assistant is planned for other narrative construction tools such as Twine (Klimas, 2009). Future work will focus on expanding and formalizing both the Progression Model and the Progression Maps. As previously discussed, there are underlying design assumptions and affordances of the Progression Maps model that were not explicitly included in the current version documented in this dissertation. Further evaluation is needed on the suitability and usability of the Maps as a basis for design communication and design visualization. Also needed is an exploration of the Progression Maps’ applications for more elaborate and complex interactive narrative design. This dissertation targeted novice designers, and future work will focus on more experienced designers, and on how Progression Maps can be incorporated and visualized in the context of their work and design process. Lastly there are a large variety of possible applications and use cases of Pro- gression Maps both for game design and development, research, playtesting, and 8.7. Closing Words 153 formative evaluation as discussed previously. There is also the possibility of using the Maps as a pedagogical tool for teaching interactive narrative design. In future work, I will aim to explore these various applications and expand both models and the Design Assistant architecture accordingly.

8.7 Closing Words

Stories are one of the most useful tools that we as humans have access to. Their study will enable us to not only understand ourselves better, but also improve communication with each other across cultures, languages, and identities. Interactive narrative, as a part of the virtual world we now inhabit as much as our physical one, is an important part of such study and exploration. The ﬁeld of interactive narrative, broadly, still has signiﬁcant developments to be made, which necessitates further agreement by the community on a shared vocabulary, methods, and practices. It is my hope that this dissertation in conjunction with my future work on the Progression Maps, will in time become part of the shared vocabulary for interactive narrative research.

155

Appendix A

UML Representation - Progression Maps 156 Appendix A. UML Representation - Progression Maps

FIGURE A.1: An UML representation of Progression Maps, capturing the relationship between the interaction unit, which is the highest abstraction node (level 1) and the set of level 2 nodes it can contain. 157

Appendix B

Illustrative Example - Progression Map

An example of an Progression Map, automatically constructed from a simple interactive narrative built in StudyCrafter (see Chapter6 for details). The simple scene has a waiter asking the player character what they would like to eat, and showcases each of the 2nd layer nodes. Due to space constraints the picture shown is not in sufﬁcient quality. This example was ﬁgure 4.2. 158 Appendix B. Illustrative Example - Progression Map

FIGURE B.1 159

Appendix C

Walkthrough of Long Live The Queen

The walkthrough used in the study described in Chapter5. The segment of the game played by participants followed a walkthrough taken from a fan-community run website: http://longlivethequeen.wikia.com/wiki/Basic_Walkthrough. Mapping began after the "Start Game" option had been selected and stopped at the menu selection containing a "Visit Julianna" option, for in-game week 3. The full script for the walkthrough can be found in table C.1 below. Classes and Weekend Activities were chosen through Menu selection. Actions labeled as "Choose:" were Choice through Selection (see Chapter3 for deﬁnition) type progression during story scenes.

Week Classes Choices Made That Week Weekend Activities 1 Accounting Talk to Your Father Accounting

2 Accounting Choose: Let her stay Visit Julianna Accounting

3 Trade Choose: Hold still Visit Julianna Trade

TABLE C.1

161

Appendix D

Recruitment Questionnaire

Thank you for taking the time to respond to our survey. This (focus group/usability test) will take place within the next week at the University of Houston-Clear Lake. The survey will be used to determine your eligibility to participate in this (focus group/usability test). This will take roughy 1 hour and 30 minutes of your time. Please take the time to answer each question. We value your privacy and your answers to this survey will be strictly conﬁdential and ONLY be used for recruiting purposes. Demographic Background

1. What is your age? (Open-ended response)

2. What is your employment status?

• Full Time • Part Time • Student • Retired

3. What is your background in/What is your major? (Open-ended response)

Gaming Background

1. Do you play video games?

• Yes • No

2. How would you describe your level of experience with video games?

• Novice (not much experience) • Intermediate (comfortable with several gaming tasks) • Advanced (very comfortable and knowledgeable concerning many gaming tasks) • Expert (extremely comfortable and knowledgeable concerning most gaming tasks) 162 Appendix D. Recruitment Questionnaire

3. Please select all types of games you partake in:

• Multi-Player (including online) • Simulation/Sandbox • Advenure • Strategy • Sports • Role-Playing • Puzzle • Action/Combat/First Person Shooters

4. Are you familiar with Interactive Narrative games?

• Yes • No • Unsure

5. Have you played StudyCrafter before?

• Yes • No • Unsure 163

Bibliography

Aarseth, Espen (2003). “Playing Research: Methodological approaches to game analysis”. In: Proceedings of the digital arts and culture conference. Araújo, Manuel and Licinio Roque (2009). “Modeling Games with Petri Nets”. In: Breaking New Ground: Innovation in Games, Play, Practice and Theory - Proceedings of DiGRA 2009. Ashwell, Sam Kabo (Jan. 2015). Standard Patterns in Choice-Based Games. URL: https: //heterogenoustasks.wordpress.com/2015/01/26/standard-patterns-in- choice-based-games/ (visited on 10/18/2017). Atlus (2008). Persona 4. [Playstation 2]. Aylett, R. S. et al. (2005). “FearNot! – An Experiment in Emergent Narrative”. en. In: Intelligent Virtual Agents. Ed. by Themis Panayiotopoulos et al. Lecture Notes in Computer Science. Springer Berlin Heidelberg, pp. 305–316. ISBN: 978-3-540- 28739-1. Aylett, Ruth and Sandy Louchart (2003). “Towards a narrative theory of virtual reality”. In: Virtual Reality 7.1, pp. 2–9. Baker, Michael et al. (1999). “The Role of Grounding in Collaborative Learning Tasks”. In: Collaborative learning: Cognitive and computational approaches 31, p. 63. Bakkes, Sander and Joris Dormans (2010). “Involving player experience in dynamically generated missions and game spaces”. In: Eleventh International Conference on Intelligent Games and Simulation (Game-On’2010), pp. 72–79. Baldwin, A. et al. (Aug. 2017). “Mixed-initiative procedural generation of dungeons using game design patterns”. In: 2017 IEEE Conference on Computational Intelli- gence and Games (CIG), pp. 25–32. DOI: 10.1109/CIG.2017.8080411. Barlow, Sam (2015). Her Story. [Digital Game]. Barthes, Roland and Lionel Duisit (1975). “An introduction to the structural analysis of narrative”. In: New literary history 6.2, pp. 237–272. Bartle, Richard A (2004). Designing virtual worlds. New Riders. Beaudouin-Lafon, Michel (2000). “Instrumental interaction: an interaction model for designing post-WIMP user interfaces”. In: Proceedings of the SIGCHI conference on Human factors in computing systems - CHI ’00. New York, New York, USA: ACM Press, pp. 446–453. ISBN: 1581132166. DOI: 10.1145/332040.332473. Berger, Karol (1994). “Diegesis and Mimesis: The Poetic Modes and the Matter of Artistic Presentation”. In: The Journal of Musicology 12.4, pp. 407–433. 164 Bibliography

Bernstein, Mark (1998). “Patterns of hypertext”. In: Proceedings of the ninth ACM conference on Hypertext and hypermedia: links, objects, time and space—structure in hypermedia systems: links, objects, time and space—structure in hypermedia systems. ACM, pp. 21–29. Bioware (2014). Dragon Age: Inquisition. [Playstation 4]. Birnholtz, Jeremy P et al. (2005). “Grounding needs: achieving common ground via lightweight chat in large, distributed, ad-hoc groups”. In: Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, pp. 21–30. Blackmon, MH and WS Bainbridge (2004). “Cognitive walkthrough”. In: Encyclope- dia of human-computer interaction 2, pp. 104–107. Bleich, David (1975). Readings and feelings: An introduction to subjective criticism. Ur- bana, IL: NCTE. Borges, Jorge Luis (1948). “The Garden of Forking Paths”. In: Ficciones. Editorial Sur. Bormann, Daniel and Tobias Greitemeyer (Aug. 2015). “Immersed in Virtual Worlds and Minds: Effects of In-Game Storytelling on Immersion, Need Satisfaction, and Affective Theory of Mind”. en. In: Social Psychological and Personality Science 6.6, pp. 646–652. ISSN: 1948-5506. DOI: 10.1177/1948550615578177. Brom, Cyril and Adam Abonyi (Jan. 2006). “Petri Nets for Game Plot”. In: Narrative AI and Games Workshop, AISB. Vol. 3. Brown, Emily and Paul Cairns (2004). “A grounded investigation of game immersion”. en. In: ACM Press, p. 1297. ISBN: 978-1-58113-703-3. DOI: 10.1145/985921. 986048. Bunia, Remigius (2010). “Diegesis and representation: Beyond the ﬁctional world, on the margins of story and narrative”. In: Poetics Today 31.4, pp. 679–720. Cabioch, Thomas et al. (2019). “Timing Interactive Narratives”. en. In: Conference on Games. Campbell, Joseph (2008). The hero with a thousand faces. Vol. 17. New World Library. Campbell, Julia et al. (2011). “Developing INOTS to support interpersonal skills practice”. In: 2011 Aerospace Conference. IEEE, pp. 1–14. Cardona-Rivera, Rogelio E et al. (2014). “Foreseeing Meaningful Choices”. In: Pro- ceedings of the Tenth Annual AAAI Conference on Artiﬁcial Intelligence and Interactive Digital Entertainment (AIIDE 2014). AAAI, p. 7. Carstensdottir, Elin, Erica Kleinman, and Magy Seif El-Nasr (2019). “Player interaction in narrative games: structure and narrative progression mechanics”. In: Proceedings of the 14th International Conference on the Foundations of Digital Games. ACM, p. 23. Carstensdottir, Elin, Erica Kleinman, and Magy Seif El-Nasr (2017). “Towards an Interaction Model for Interactive Narratives”. In: Interactive Storytelling. ICIDS 2017. Lecture Notes in Computer Science. Vol. 10690 LNCS. DOI: 10.1007/978-3- 319-71027-3_24. Cavazza, M. et al. (2003). “User interaction in mixed reality interactive storytelling”. In: The Second IEEE and ACM International Symposium on Mixed and Augmented Bibliography 165

Reality, 2003. Proceedings. IEEE Comput. Soc, pp. 304–305. ISBN: 0-7695-2006-5. DOI: 10.1109/ISMAR.2003.1240732. Cavazza, Marc et al. (2007). “Madame Bovary on the holodeck: immersive interactive storytelling”. In: Proceedings of the 15th international conference on Multimedia, pp. 651–660. DOI: 10.1145/1291233.1291387. Chunsoft (2012). Zero Escape: Virtue’s Last Reward. [Playstation Vita]. Clark, Herbert H (1996). Using language. eng. Cambridge [U.K.] ; New York: Cam- bridge University Press. Colás, Joaquim et al. (Dec. 2017). “Interaction and Outcomes in Collaborative Story- telling Systems: a Framework, a Field Study, and a Model”. en. In: Computer Sup- ported Cooperative Work (CSCW) 26.4-6, pp. 627–662. ISSN: 0925-9724, 1573-7551. DOI: 10.1007/s10606-017-9290-0. Convertino, Gregorio et al. (2008). “Articulating common ground in cooperative work: content and process”. In: Proceedings of the SIGCHI conference on human factors in computing systems. ACM, pp. 1637–1646. Cook, Michael and Azalea Raad (2019). “Hyperstate Space Graphs For Automated Game Analysis”. en. In: Conference on Games. Crick, Timothy (2011). “The game body: Toward a phenomenology of contemporary video gaming”. In: Games and Culture 6.3, pp. 259–269. Day, Timothy and Jichen Zhu (2017). “Agency Informing Techniques: Communicat- ing Player Agency in Interactive Narratives”. In: Proceedings of the 12th Interna- tional Conference on the Foundations of Digital Games. FDG ’17. New York, NY, USA: ACM, 56:1–56:4. ISBN: 978-1-4503-5319-9. DOI: 10.1145/3102071.3106363. Don Rawitsch, R. Philip Bouchard (1985). The Oregon Trail. [Digital Game]. Dontnod Entertainment, (2015). Life is Strange. [Digital Game]. Dormans, Joris (2011). “Simulating mechanics to study emergence in games”. In: Workshops at the Seventh Artiﬁcial Intelligence and Interactive Digital Entertainment Conference. Douglas, Yellowlees and Andrew Hargadon (2000). “The Pleasure Principle: Immer- sion, Engagement, Flow”. In: Proceedings of the Eleventh ACM on Hypertext and Hypermedia. HYPERTEXT ’00. New York, NY, USA: ACM, pp. 153–160. ISBN: 978- 1-58113-227-4. DOI: 10.1145/336296.336354. Dow, Steven P. (2008). “Understanding user engagement in immersive and interactive stories”. PhD thesis. Georgia Institute of Technology. Eladhari, Mirjam (2002). “Objektorienterat berättande i berättelsedrivna datorspel”. In: Object Oriented Story Construction in Story Driven Computer Games”). Yayınlan- mamı¸sYüksek Lisans Tezi. Enix, Square (2016). Final Fantasy 15. [Play Station 4]. Fendt, Matthew William et al. (Nov. 2012). “Achieving the Illusion of Agency”. en. In: Interactive Storytelling. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg, pp. 114–125. ISBN: 978-3-642-34850-1 978-3-642-34851-8. DOI: 10 . 1007/978-3-642-34851-8_11. 166 Bibliography

Feng, Dan et al. (2016). “An Active Analysis and Crowd Sourced Approach to Social Training”. In: ICIDS. Springer, pp. 156–167. Ferri, Gabriele (2009). “Interpretive cooperation and procedurality”. In: Computer Games between Text and Practice", E| C 5. Fox, Toby (2015). Undertale. [Digital Game]. Frasca, Gonzalo (2013). “Simulation versus narrative: Introduction to ludology”. In: The video game theory reader. Routledge, pp. 243–258. Freebird Games (2014). To the Moon. [Digital Game]. Fullerton, Tracy (Aug. 2018). Game Design Workshop : A Playcentric Approach to Creat- ing Innovative Games, Fourth Edition. en. A K Peters/CRC Press. ISBN: 978-1-315- 10430-0. DOI: 10.1201/b22309. Galactic Cafe (2013). The Stanley Parable. [Digital Game]. Games, Platinum (2017). NieR: Automata. [Digital Game]. Games, Upper One (2014). Never Alone. [Digital Game]. Garbe, Jacob et al. (2014). “Author Assistance Visualizations for Ice-Bound, A Com- binatorial Narrative”. en. In: Foundations of Digital Games, p. 7. Garbe, Jacob et al. (2019). “StoryAssembler: An Engine for Generating Dynamic Choice-Driven Narratives”. In: Garneli, Varvara, Michail Giannakos, and Konstantinos Chorianopoulos (2017). “Se- rious games as a malleable learning medium: The effects of narrative, gameplay, and making on students’ performance and attitudes”. In: British Journal of Educa- tional Technology 48.3, pp. 842–859. Gorbman, Claudia (1980). “Narrative ﬁlm music”. In: Yale French Studies 60, pp. 183– 203. Guckelsberger, Christian et al. (2017). “Predicting Player Experience Without the Player.: An Exploratory Study”. In: Annual Symposium on Computer-Human In- teraction in Play. CHI PLAY ’17. New York, NY, USA: ACM, pp. 305–315. ISBN: 978-1-4503-4898-0. DOI: 10.1145/3116595.3116631. Guzdial, Matthew and Mark Riedl (2018). “Automated Game Design via Concep- tual Expansion”. In: Fourteenth Artiﬁcial Intelligence and Interactive Digital Enter- tainment Conference. Guzdial, Matthew et al. (2015). “Crowdsourcing Open Interactive Narrative”. In: The 10th Int. Conf. on the Foundations of Digital Games. Hanako Games (2015). Black Closet. [Digital Game]. Hanako Games, Spiky Caterpillar (2012). Long Live the Queen. [Digital Game]. Hargood, Charlie et al. (2016). “Patterns of sculptural hypertext in location based narratives”. In: Proceedings of the 27th ACM Conference on Hypertext and Social Me- dia. ACM, pp. 61–70. Harkin, Patricia (2005). “The reception of reader-response theory”. In: College Com- position and Communication, pp. 410–425. Harteveld, Casper et al. (2017). “Design of Playful Authoring Tools for Social and Behavioral Science”. In: IUI’17 Companion. Limassol, Cyprus: ACM Press. Bibliography 167

Holler, Judith and Katie Wilkin (2009). “Communicating Common Ground: How mutually shared knowledge influences speech and gesture in a narrative task”. In: Language and cognitive processes 24.2, pp. 267–289. Holmgard, C. et al. (2018). “Automated Playtesting with Procedural Personas with Evolved Heuristics”. In: IEEE Transactions on Games, pp. 1–1. ISSN: 2475-1502. DOI: 10.1109/TG.2018.2808198. Hudson, Kent (2013). The Novelist. [Digital Game]. Hunicke, Robin, Marc LeBlanc, and Robert Zubek (2004). “MDA: A formal approach to game design and game research”. In: Proceedings of the AAAI Workshop on Chal- lenges in Game AI. Vol. 4. 1. Infocom (1977). Zork. Isaksen, Aaron, Daniel Gopstein, and Andrew Nealen (2015). “Exploring Game Space Using Survival Analysis.” In: Proceedings of the 10th International Conference on the Foundations of Digital Games (FDG 2015). Pacific Grove, CA, USA: ACM. Isbister, Katherine and Noah Schaffer (2008). Game usability: Advancing the player experience. CRC press. Jemmali, Chaima et al. (2018). “Educational game design: an empirical study of the effects of narrative”. In: Proceedings of the 13th International Conference on the Foun- dations of Digital Games. ACM, p. 34. Jenkins, Henry (2004). “Game Design as Narrative Architecture”. In: First Person: New Media as Story, Performance, and Game. Ed. by Noah Wardrip-Fruin and Pat Harrigan. Cambridge: MIT Press. Chap. Game Desig. Jørgensen, Kristine (2007). “On transdiegetic sounds in computer games”. In: North- ern Lights: Film & Media Studies Yearbook 5.1, pp. 105–117. — (2011). “Time for New Terminology?: Diegetic and Non-Diegetic Sounds in Com- puter Games Revisited”. In: Game sound technology and player interaction: Concepts and developments. IGI Global, pp. 78–97. — (2012). “Between the game system and the fictional world: a study of computer game interfaces”. In: Games and Culture 7.2, pp. 142–163. Juul, Jesper (2001). “Games telling stories”. In: Game Studies 1.1, p. 45. Karth, Isaac and Adam M. Smith (2019). “Addressing the fundamental tension of PCGML with discriminative learning”. In: Proceedings of the 14th International Conference on the Foundations of Digital Games. ACM, p. 89. Keehl, Oleksandra and Adam M Smith (2018). “Monster Carlo: an MCTS-based Framework for Machine Playtesting Unity Games”. en. In: 2018 IEEE Conference on Computational Intelligence and Games (CIG). IEEE, p. 8. Kelso, Margaret Thomas, Peter Weyhrauch, and Joseph Bates (1993). “Dramatic presence”. In: PRESENCE: Teleoperators & Virtual Environments 2.1, pp. 1–15. Kiesler, Sara (2005). “Fostering common ground in human-robot interaction”. In: Robot and Human Interactive Communication, 2005. ROMAN 2005. IEEE Interna- tional Workshop on. IEEE, pp. 729–734. 168 Bibliography

Kleinman, Erica, Elin Carstensdottir, and Magy Seif El-Nasr (2018). “Going Forward by Going Back: Re-defining Rewind Mechanics in Narrative Games”. In: Proceed- ings of the 13th International Conference on the Foundations of Digital Games. FDG ’18. Malm, Sweden: ACM, 32:1–32:6. ISBN: 978-1-4503-6571-0. DOI: 10 . 1145 / 3235765.3235773. Kleinman, Erica, Elin Carstensdottir, and Magy Seif El-Nasr (2019). “A Model for Analyzing Diegesis in Digital Narrative Games”. In: Interactive Storytelling. ICIDS 2019. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg. Klevjer, Rune (2002). “In Defense of Cutscenes.” In: CGDC Conf. Klimas, Chris (2009). Twine. URL: https://twinery.org/. Klimmt, Christian et al. (2010). “The empirical assessment of the user experience in interactive storytelling: construct validation of candidate evaluation measures”. In: Technical Report. Koenitz, Hartmut (2015). “Design Approaches for Interactive Digital Narrative”. In: Interactive Storytelling. Ed. by Henrik Schoenau-Fog et al. Cham: Springer Inter- national Publishing, pp. 50–57. ISBN: 978-3-319-27036-4. Koenitz, Hartmut et al., eds. (2010). The ICIDS 2010 Workshop Towards a Shared Vocab- ulary for Interactive Digital Storytelling. Springer Berlin / Heidelberg. — eds. (2011). The ICIDS 2011 Workshop Towards a Unified Theory for Interactive Digital Storytelling: Classifying Artifacts. Springer Berlin / Heidelberg. Koenitz, Hartmut et al. (2016). “An Integrated and Iterative Research Direction for Interactive Digital Narrative”. In: Interactive Storytelling. ICIDS 2016. Lecture Notes in Computer Science. Vol. 10045 LNCS. Springer, Cham, pp. 51–60. ISBN: 9783319482781. DOI: 10.1007/978-3-319-48279-8_5. Kromand, Daniel (2008). “Sound and the diegesis in survival-horror games”. In: Au- dio Mostly 2008. Laurel, Brenda (1986). “Toward the design of a computer-based interactive fantasy system”. PhD Thesis. The Ohio State University. Lee, Young-Seol and Sung-Bae Cho (June 2011). “Context-Aware Petri Net for Dy- namic Procedural Content Generation in Role-Playing Game”. In: Computational Intelligence Magazine, IEEE 6, pp. 16–25. DOI: 10.1109/MCI.2011.940618. Li, Boyang et al. (2013). “Story Generation with Crowdsourced Plot Graphs.” In: Proc. of the 27th AAAI Conf. on Artificial Intelligence. Liapis, Antonios, Georgios N. Yannakakis, and Julian Togelius (2013). “Sentient sketchbook: Computer-aided game level authoring”. In: Proceedings of ACM Conference on Foundations of Digital Games, 2013. Lindley, Craig A. (2005). “Story and narrative structures in computer games”. In: Developing Interactive Narrative Content. Ed. by Brunhild Bushoff. sagas/sagasnet reader. Munich: HighText Verlag. Louchart, Sandy and Ruth Aylett (2004). “Narrative theory and emergent interactive narrative”. In: International Journal of Continuing Engineering Education and Life Long Learning 14.6, pp. 506–518. Bibliography 169

Magerko, Brian (2005). “Story representation and interactive drama”. In: Proceedings of the First Annual Conference on Artiﬁcial Intelligence and Interactive Digital Enter- tainment (AIIDE ’05), pp. 87–92. DOI: 10.1.1.85.1793. Magerko, Brian and John Laird (2003). “Building an interactive drama architecture”. In: First International Conference on Technologies for Interactive Digital Storytelling and Entertainment, pp. 226–237. Marsella, Stacy C., W. Lewis Johnson, and Catherine LaBore (2000). “Interactive pedagogical drama”. In: International Conference on Autonomous Agents: Proceedings of the fourth international conference on Autonomous agents. Vol. 3, pp. 301–308. Marsh, Tim et al. (2011). “Fun and learning: Blending design and development dimensions in serious games through narrative and characters”. In: Serious games and edutainment applications. Springer, pp. 273–288. Martens, Chris and Matthew A. Hammer (2017). “Languages of Play: Towards Se- mantic Foundations for Game Interfaces”. In: Proceedings of the 12th International Conference on the Foundations of Digital Games. FDG ’17. New York, NY, USA: ACM, 32:1–32:10. ISBN: 978-1-4503-5319-9. DOI: 10.1145/3102071.3102096. Martens, Chris et al. (2018). “Villanelle: Towards Authorable Autonomous Charac- ters in Interactive Narrative.” In: INTWICED@ AIIDE. Martey, Rosa Mikeal et al. (2017). “Testing the power of game lessons: The effects of art style and narrative complexity on reducing cognitive bias”. In: International Journal of Communication 11, p. 22. Mateas, Michael (2000a). “A Neo-Aristotelian Theory of Interactive Drama”. In: Pro- ceedings of the AAAI Spring Symposium on AI and Interactive Entertainment. — (2000b). “A neo-aristotelian theory of interactive drama”. In: Working notes of the AI and Interactive Entertainment Symposium. Mateas, Michael and Andrew Stern (2002). “Towards integrating plot and character for interactive drama”. In: Socially Intelligent Agents. Springer, pp. 221–228. — (2003). “Façade : An Experiment in Building a Fully-Realized Interactive Drama”. In: Game Developers Conference Game Design track. Vol. 2, p. 82. DOI: 10.1.1.14. 6176. — (2004). “A Behavior Language: Joint action and behavioral idioms”. In: Life-Like Characters. Springer, pp. 135–161. — (2005). “Structuring Content in the Façade Interactive Drama Architecture.” In: AIIDE, pp. 93–98. — (2012). Facade. [Digital Game]. Mateas, Michael and Noah Wardrip-Fruin (2009). “Deﬁning Operational Logics”. In: Proceedings of DiGRA 2009. Rockstar San Diego (2010). Red Dead Redemption. McCoy, J. et al. (2010). “Authoring game-based interactive narrative using social games and comme il faut”. In: Proceedings of the 4th International Conference & Festival of the Electronic Literature Organization. McCoy, Josh, Mike Treanor, and Ben Samuel (2012). Prom Week. [Digital Game]. 170 Bibliography

McCoy, Josh et al. (2011). “Prom Week: social physics as gameplay”. In: Proceedings of the 6th International Conference on Foundations of Digital Games - FDG ’11. New York, New York, USA: ACM Press, pp. 319–321. ISBN: 9781450308045. DOI: 10. 1145/2159365.2159425. McCoy, Joshua et al. (2013). “Prom Week: Designing past the game/story dilemma.” In: Proceedings of the 13th International Conference on the Foundations of Digital Games, pp. 94–101. McKee, Robert (1997). “Substance, structure, style, and the principles of screenwrit- ing”. In: McMahan, Alison (2003). “Immersion, engagement and presence”. In: The video game theory reader 67, p. 86. McQuiggan, Scott W. et al. (2008). “Story-Based Learning: The Impact of Narrative on Learning Experiences and Outcomes”. en. In: Intelligent Tutoring Systems. Ed. by Beverley P. Woolf et al. Lecture Notes in Computer Science. Springer Berlin Heidelberg, pp. 530–539. ISBN: 978-3-540-69132-7. Milam, David, Magy Seif El-Nasr, and Ron Wakkary (2008). “Looking at the Inter- active Narrative Experience through the Eyes of the Participants”. In: Interac- tive Storytelling. ICIDS 2008. Lecture Notes in Computer Science. Ed. by U Spierling and N Szilas. Vol. 5334 LNCS. Springer, Berlin, Heidelberg, pp. 96–107. ISBN: 3540894241. DOI: 10.1007/978-3-540-89454-4_16. Millard, David E et al. (2013a). “Canyons, deltas and plains: towards a unified sculptural model of location-based hypertext”. In: Proceedings of the 24th ACM Confer- ence on Hypertext and Social Media. ACM, pp. 109–118. Millard, David E. et al. (2013b). “Canyons, deltas and plains: towards a unified sculptural model of location-based hypertext”. In: 24th ACM Conference on Hypertext and Social Media. ACM, pp. 109–118. Miller, Lynn C. et al. (2011). “Socially Optimized Learning in Virtual Environments (SOLVE)”. In: Interactive Storytelling. Ed. by Mei Si et al. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 182–192. ISBN: 978-3-642-25289-1. Moriarty, Brian (Nov. 2015). I Sing the Story Electric. New York University. URL: http: //ludix.com/moriarty/electric.html. Mott, Bradford W. and James C. Lester (2006). “U-director: A Decision-Theoretic Narrative Planning Architecture for Storytelling Environments”. In: Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems - AAMAS ’06. New York, New York, USA: ACM Press, pp. 977–984. ISBN: 1595933034. DOI: 10.1145/1160633.1160808. Moura, Dinara and Magy Seif El-Nasr (2015). “Design Techniques for Planning Nav- igational Systems in 3-D Video Games”. In: Computers in Entertainment 12.2, pp. 1– 25. ISSN: 15443574. DOI: 10.1145/2701657.2633421. Murray, Janet (1997). Hamlet on the Holodeck: The Future of Narrative in Cyberspace. New York, NY, USA: The Free Press. ISBN: 978-0-684-82723-0. Bibliography 171

Neumeyer, David (2009). “Diegetic/Nondiegetic: A Theoretical Model”. In: Music and the Moving Image 2.1, pp. 26–39. Nielsen, Jakob, Robert L Mack, et al. (1994). Usability inspection methods. Vol. 1. Wiley New York. Night School Studio (2016). Oxenfree. [Digital Game]. Norman, Don (2013). The design of everyday things: Revised and expanded edition. Basic Books (AZ). Osborn, Joseph C. (2017). “Operationalizing Operational Logics: Semiotic Knowl- edge Representations for Interactive Systems”. In: Proceedings of the Twenty-Sixth International Joint Conference on Artiﬁcial Intelligence, IJCAI-17, pp. 5199–5200. DOI: 10.24963/ijcai.2017/759. Paper Dino Software, (2015). Save the Date. [Digital Game]. Park, Kyungjin et al. (2019). “Generating Educational Game Levels with Multistep Deep Convolutional Generative Adversarial Networks”. In: 33rd Proceedings of the International IEEE Conference on Games. Partlan, Nathan et al. (Nov. 2018). “Exploratory Automated Analysis of Structural Features of Interactive Narrative”. In: Proceedings of the 14th AAAI Conference on Artiﬁcial Intelligence and Interactive Digital Entertainment. Edmonton, AB, Canada: The AAAI Press, Palo Alto, California. Partlan, Nathan et al. (2019). “Evaluation of an automatically-constructed graph- based representation for interactive narrative”. In: Proceedings of the 14th Interna- tional Conference on the Foundations of Digital Games. San Luis Obispo, CA: ACM, p. 100. Polson, Peter G et al. (1992). “Cognitive walkthroughs: a method for theory-based evaluation of user interfaces”. In: International Journal of man-machine studies 36.5, pp. 741–773. Pope, Lucas (2013). Papers, Please. [Digital Game]. Propp, Vladimir (1968). Morphology of the folktale. eng;rus. 2nd ed. Austin: University of Texas Press. ISBN: 0292783760. Quantic Dream (2016). Heavy Rain. [Playstation 4]. Red, CD Projekt (2015). The Witcher 3: Wild Hunt. [Digital Game]. Riedl, Mark O and Robert Michael Young (2006). “From linear story generation to branching story graphs”. In: IEEE Computer Graphics and Applications 26.3, pp. 23– 31. Rosenberg, Robin S, Shawnee L Baughman, and Jeremy N Bailenson (2013). “Virtual superheroes: Using superpowers in virtual reality to encourage prosocial behavior”. In: PloS one 8.1, e55003. Roth, Christian and Hartmut Koenitz (2016). “Evaluating the User Experience of Interactive Digital Narrative”. In: Proceedings of the 1st International Workshop on Multimedia Alternate Realities. AltMM ’16. New York, NY, USA: ACM, pp. 31–36. ISBN: 978-1-4503-4521-7. DOI: 10.1145/2983298.2983302. 172 Bibliography

Roth, Christian and Hartmut Koenitz (2017). “Towards Creating a Body of Evidence- based Interactive Digital Narrative Design Knowledge: Approaches and Chal- lenges”. In: Proceedings of the 2Nd International Workshop on Multimedia Alternate Realities. AltMM ’17. New York, NY, USA: ACM, pp. 19–24. ISBN: 978-1-4503- 5507-0. DOI: 10.1145/3132361.3133942. Roth, Christian, Peter Vorderer, and Christoph Klimmt (Dec. 2009). “The Motiva- tional Appeal of Interactive Storytelling: Towards a Dimensional Model of the User Experience”. en. In: Interactive Storytelling. Lecture Notes in Computer Sci- ence. Springer, Berlin, Heidelberg, pp. 38–43. ISBN: 978-3-642-10642-2 978-3-642- 10643-9. DOI: 10.1007/978-3-642-10643-9_7. Rowe, Jonathan P. and James C. Lester (2010). “Modeling user knowledge with dynamic Bayesian networks in interactive narrative environments”. In: AIIDE’10 Proceedings of the Sixth AAAI Conference on Artificial Intelligence and Interactive Dig- ital Entertainment. AAAI Press, pp. 57–62. Rowe, Jonathan P et al. (2011). “Integrating learning, problem solving, and engagement in narrative-centered learning environments”. In: International Journal of Ar- tificial Intelligence in Education 21.1-2, pp. 115–133. Rumbaugh, James, Ivar Jacobson, and Grady Booch (2004). Unified Modeling Lan- guage Reference Manual, The (2nd Edition). Pearson Higher Education. ISBN: 0321245628. Rutter, Jason and Jo Bryce (2006). Understanding digital games. Sage. Ryan, James (Nov. 2017). “Grimes’ Fairy Tales: A 1960s Story Generator”. In: 10th International Conference on Interactive Digital Storytelling. Ed. by Nuno Nunes, Ian Oakley, and Valentina Nisi. Vol. 10690. Lecture Notes in Computer Science. Fun- chal, Madeira, Portugal: Springer, Cham. DOI: 10.1007/978-3-319-71027-3_8. Ryan, Marie-Laure (2001). “Beyond myth and metaphor”. In: consultant 1983, p. 91. Ryan, Richard M, C Scott Rigby, and Andrew Przybylski (2006). “The motivational pull of video games: A self-determination theory approach”. In: Motivation and emotion 30.4, pp. 344–360. Saksono, Herman and Andrea G. Parker (2017). “Reflective Informatics Through Family Storytelling: Self-discovering Physical Activity Predictors”. In: Proceed- ings of the 2017 CHI Conference on Human Factors in Computing Systems. CHI ’17. Denver, Colorado, USA: ACM, pp. 5232–5244. ISBN: 978-1-4503-4655-9. DOI: 10. 1145/3025453.3025651. Salvato, Dan (2017). Doki Doki Literature Club. [Digital Game]. Sandifer, Philip (2011). “Out of the Screen and into the Theater: 3-D Film as Demo”. In: Cinema Journal, pp. 62–78. Schaul, Tom (2013). “A video game description language for model-based or interactive learning”. In: IEEE Conference on Computational Inteligence in Games (CIG). IEEE, pp. 1–8. Schoenau-Fog, Henrik (Nov. 2011). “Hooked! – Evaluating Engagement as Contin- uation Desire in Interactive Narratives”. en. In: Interactive Storytelling. Lecture Bibliography 173

Notes in Computer Science. Springer, Berlin, Heidelberg, pp. 219–230. ISBN: 978- 3-642-25288-4 978-3-642-25289-1. DOI: 10.1007/978-3-642-25289-1_24. Segre, Cesare and John Meddemmen (1980). “A Contribution to the Semiotics of Theater”. In: Poetics today 1.3, pp. 39–48. Seif El-Nasr, Magy (Jan. 2005). “Desktop 3-D Interactive Drama - Applying Design Principles from the Performance Arts”. In: — (June 2007). “Interaction, narrative, and drama: Creating an adaptive interactive narrative using performance arts theories”. In: Interaction Studies 8, pp. 209–240. DOI: 10.1075/is.8.2.03eln. Seif El-Nasr, Magy Seif (2004). “A user-centric adaptive story architecture: borrowing from acting theories”. In: Proceedings of the 2004 ACM SIGCHI International Conference on Advances in computer entertainment technology. ACM, pp. 109–116. Shaker, Noor et al. (2012). “Evolving levels for super mario bros using grammatical evolution”. In: 2012 IEEE Conference on Computational Intelligence and Games (CIG). IEEE, pp. 304–311. Sharma, Manu et al. (2010). “Drama management and player modeling for interactive ﬁction games”. In: Computational Intelligence 26.2, pp. 183–211. Short, Emily (Nov. 2016). Small-Scale Structures in CYOA. URL: https://emshort. blog/2016/11/05/small-scale-structures-in-cyoa/ (visited on 10/18/2017). — (Mar. 2019). Memory and Knowledge for Characters. en. URL: https://emshort. blog/2019/03/05/describing-a-procedurally-generated-world/ (visited on 09/18/2019). Si, Mei and Stacy C. Marsella (Jan. 2014). “Encoding Theory of Mind in Character Design for Pedagogical Interactive Narrative”. In: Adv. in Hum.-Comp. Int. 2014, 10:10–10:10. ISSN: 1687-5893. DOI: 10.1155/2014/386928. Smith, Gillian, Jim Whitehead, and Michael Mateas (2010). “Tanagra: A Mixed-initiative Level Design Tool”. In: Proceedings of the Fifth International Conference on the Foun- dations of Digital Games. FDG ’10. New York, NY, USA: ACM, pp. 209–216. ISBN: 978-1-60558-937-4. DOI: 10.1145/1822348.1822376. Starbreeze Studios (2013). Brothers: A Tale of Two Sons. [Digital Game]. Studios, Rockstar (2018). Red Dead Redemption 2. [Digital Game]. Summerville, Adam et al. (2018a). “Gemini: Bidirectional Generation and Analysis of Games via ASP”. en. In: AIIDE 2018, p. 7. Summerville, Adam et al. (2018b). “Procedural content generation via machine learning (PCGML)”. In: IEEE Transactions on Games 10.3, pp. 257–270. Swanson, Reid and Andrew S. Gordon (2008). “Say Anything: A Massively Collab- orative Open Domain Story Writing Companion”. en. In: Interactive Storytelling. Ed. by Ulrike Spierling and Nicolas Szilas. LNCS 5334. Springer Berlin Heidel- berg, pp. 32–40. ISBN: 978-3-540-89424-7 978-3-540-89454-4. Sweeney, Tim (2014). Unreal Engine 4. URL: https://www.unrealengine.com (visited on 10/24/2019). 174 Bibliography

Swink, Steve (2008). Game Feel: A Game Designer’s Guide to Virtual Sensation. Burling- ton, MA: Elsevier, p. 377. Szilas, Nicolas (Sept. 2003a). “IDtension: a narrative engine for Interactive Drama”. In: Technologies for Interactive Digital Storytelling and Entertainment. — (2003b). “IDtension: a narrative engine for Interactive Drama”. In: Proceedings of the Technologies for Interactive Digital Storytelling and Entertainment (TIDSE) Con- ference. Ed. by Göbel et Al. Frauenhofer IRB Verlag, pp. 187–203. Szilas, Nicolas, Thomas Boggini, and Paolo Petta, eds. (2011). The ICIDS 2011 Work- shop on Sharing Interactive Digital Storytelling Technologies. Szilas, Nicolas and Ioana Ilea (Nov. 2014). “Objective Metrics for Interactive Narra- tive”. en. In: Interactive Storytelling. Lecture Notes in Computer Science. Springer, Cham, pp. 91–102. ISBN: 978-3-319-12336-3 978-3-319-12337-0. DOI: 10.1007/978- 3-319-12337-0_9. Szilas, Nicolas, Olivier Marty, and Jean-Hugues Réty (2003). “Authoring Highly Generative Interactive Drama”. In: Virtual Storytelling. Using Virtual RealityTech- nologies for Storytelling. Ed. by Olivier Balet, Gérard Subsol, and Patrice Torguet. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 37–46. ISBN: 978-3-540-40014- 1. Szilas, Nicolas et al., eds. (2012). The ICIDS 2012 Workshop on Sharing Interactive Dig- ital Storytelling Technologies. Tanenbaum, Karen and Theresa Jean Tanenbaum (Mar. 2010). “Agency as commitment to meaning: communicative competence in games”. In: Digital Creativity 21.1, pp. 11–17. ISSN: 1462-6268. DOI: 10.1080/14626261003654509. Tanenbaum, Theresa Jean et al. (2010). “Authoring Tangible Interactive Narratives Using Cognitive Hyperlinks”. In: Proceedings of the Intelligent Narrative Technolo- gies III Workshop. INT3 ’10. Monterey, California: ACM, 6:1–6:8. ISBN: 978-1-4503- 0022-3. DOI: 10.1145/1822309.1822315. Telltale Games (2013). The Wolf Among Us. [Digital Game]. The Fullbright Company (2013). Gone Home. [Digital Game]. The Ren’Py Visual Novel Engine (2019). URL: https://www.renpy.org/ (visited on 09/18/2019). Thue, David and Elin Carstensdottir (2018). “Getting to the Point: Resolving Ambi- guity in Intelligent Narrative Technologies”. In: Proceedings of the 11th Workshop for Intelligent Narrative Technologies. Thue, David et al. (2007). “Interactive Storytelling: A Player Modelling Approach.” In: AIIDE, pp. 43–48. Thue, David et al. (Jan. 2011). “A Computational Model of Perceived Agency in Video Games.” In: Proceedings of the Seventh AAAI Conference on Artiﬁcial Intel- ligence and Interactive Digital Entertainment. Stanford, California, USA. Togelius, Julian et al. (2011). “Search-based procedural content generation: A taxonomy and survey”. In: IEEE Transactions on Computational Intelligence and AI in Games 3.3, pp. 172–186. Bibliography 175

Ubisoft (2007). Assassin’s Creed. [Digital Game]. — (2009). Assassin’s Creed II. [Digital Game]. — (2014). Assassin’s Creed Unity. [Digital Game]. — (2018). Assassin’s Creed Odyssey. [Digital Game]. Valve Coroporation (2007). Portal. [Digital Game]. Vermeulen, Ivar E. et al. (Nov. 2010). “Measuring User Responses to Interactive Sto- ries: Towards a Standardized Assessment Tool”. en. In: Interactive Storytelling. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg, pp. 38–43. ISBN: 978-3-642-16637-2 978-3-642-16638-9. DOI: 10.1007/978-3-642-16638-9_7. Wardrip-Fruin, Noah et al. (2009). “Agency Reconsidered”. In: Proceedings of DiGRA 2009. Wei, Huaxin (2011). “Analyzing the game narrative: structure and technique”. PhD thesis. Simon Fraser University. Weyhrauch, P. (1997). “Guiding Interactive Drama”. PhD thesis. PA: School of Com- puter Science, Carnegie Mellon University. Winters, Ben (2010). “The non-diegetic fallacy: Film, music, and narrative space”. In: Music and Letters 91.2, pp. 224–244. Yannakakis, Georgios N. et al. (2010). “Siren: Towards adaptive serious games for teaching conﬂict resolution”. In: Proceedings of ECGBL, pp. 412–417. Young, R Michael (2007). “Story and discourse: A bipartite model of narrative generation in virtual worlds”. In: Interaction Studies 8.2, pp. 177–208. Young, R. Michael and Mark Riedl (2003). “Towards an architecture for intelligent control of narrative in interactive virtual worlds”. In: Proceedings of the 8th international conference on Intelligent user interfaces - IUI ’03. New York, New York, USA: ACM Press, pp. 310–312. ISBN: 1581135866. DOI: 10.1145/604045.604108.