HOW TOOLS SHAPE THE GAME AUTHORING PROCESS
Bachelor Degree Project in
Media Arts, Aesthetics and Narration
30 ECTS
Spring term 2020 Jimmy Brunnberg
Supervisor: Rebecca Rouse Examiner: Ran Zhang
Abstract
This study aims to answer how Interactive Digital Narrative authoring tools shape the authoring process. Any tool or software shapes the way its users interact with it, oftentimes without the user even knowing it. It is therefore important to understand how these processes work when talking about authoring tools for IDNs, as they will inevitably shape its output.
Three authoring tools were selected, those three being TextureWriter, Scrivener, and Twine. A standardized Game Design Document was created, and four participants were recruited to use those three authoring tools to adapt said Game Design Document. A focus group was conducted after the participants had used their tools for a fair amount of time to ascertain their authoring process experience. In the end, the participant using Twine did not attend the focus group, prohibiting evaluation of that tool.
The results showed that there are a number of previously unknown ways in which the two evaluated authoring tools shape the game authoring process: Fundamental structure, temporal structure, spatial structure, presentation structure, mechanics of interaction, and multimedia inclusion. The results also showed a strong correlation between a master narrative and in how the authoring tool limited the author.
Keywords: Authoring tool, Authoring, IDN, Game Writing, Master Narrative
Table of Contents
1 Introduction ... 1
2 Background ... 2
2.1 What Makes an Authoring Tool? ... 2
2.1.1 What Makes IDN Authoring Different From Traditional Authoring? ... 3
2.2 Shaped by Technology ... 3
2.2.1 Technology Shaping IDN Authoring ... 4
3 Problem ... 6
3.1 Method ... 6
3.1.1 Authoring Tools ... 8
4 Implementation ... 11
4.1 Identifying Typical Tropes ... 11
4.2 Creating an Original Design Idea ... 12
4.3 Creating a Design Document ... 14
4.3.1 Streamlining the Design Document ... 14
4.3.2 Filling Out the Template ... 16
5 Evaluation ... 17
5.1 Study Preparations ... 17
5.2 Focus Group ... 17
5.3 Results ... 18
5.3.1 Scrivener ... 18
5.3.2 TextureWriter ... 19
5.4 Analysis ... 20
5.5 Conclusion ... 21
6 Concluding Remarks ... 23
6.1 Summary ... 23
6.2 Discussion ... 23
6.3 Future Work ... 25
References ... 26
1 Introduction
While there has been a debate around narrative in video games (from here on just “games”) for a long time – what its place is, how much of a game is narratively driven, and more (Aarseth 2012) – there is no denying that some modern games utilize narrative to shape their playing experience. An example of such a game is Naughty Dog’s The Last of Us (2013), which won numerous awards for its interactive storytelling alone (see for example Writers Guild Awards 2019; BAFTA 2014). If AAA titles make heavy use of narrative, it brings into question what the construction of such a narrative experience within a game entails. Even if one was to ignore the narrative aspect of a game, its mechanics, setting, and theme must be reasonably authored to convey it prior to development; else, the development team has no foundational knowledge of what the game they are developing is or what it aims to become (Salazar, Mitre & Olalde 2012). It is also important to understand the limitations of adapting game from literature, and how games rely on such a text, in a similar manner to how films rely on screenplays (Flanagan 2017). Therefore, the pervasiveness of authoring, coupled with the desire to create narrative experiences within games, bequeaths a motive to find techniques and tools with which to author narratively driven games effectively.
Interactive digital narratives (IDN), such as games, interactive fiction, and hyperfiction is a relatively young area of research, and as such has many gaps to fill, none less important than the other (Koenitz 2010; Koenitz 2017). How IDN authoring tools and techniques differ and how they shape the authoring process is not yet fully understood and is where this research latches on to explore further. Game writing – or, writing for games, as opposed to writing interactive fiction or fully playable artefacts – is also included under the banner of IDN and is the primary lens I will be using to look at IDNs throughout this paper.
2 Background
While authoring tools for games exist, there are few publicly available (Green, Hargood &
Charles 2018). Those available are diverse in several ways, one of the most important ones being how they structure the authoring process and what their output is (Green, et al. 2018;
Shibolet, Knoller & Koenitz 2018). Game engines and game creation tools that have a focus on code or creating mechanics are sometimes clustered into the realm of IDNs (see for example Shibolet et al. 2018). For the purpose of this research, those tools are not included in the use of the IDN terminology, as the primary focus here is on narrative and writing. There is also the issue of whether bias in the creation of authoring tools has an impact on their usability and therefore affects authoring. This section will subsequently delve deeper into these areas without getting tangled up in specific tools, but rather the underlying functionality of them and their implications.
2.1 What Makes an Authoring Tool?
Authoring tools for games is not one big homogenous group of software, so it is crucial to taxonomize and define the corpus to understand their differences in both usability and expected output (Shibolet et al. 2018). Shibolet et al. (2018) defines an authoring tool for interactive digital narratives (IDN) as software that meet the criteria of (a) being independent of other software in the creation of IDNs; (b) the software makes the creation of IDNs easier and/or more effective; (c) is or has been actively used for IDN creation. With these criteria, they categorize a tremendous amount of software that could be construed as authoring tools for IDNs. They divide the authoring tools into two main groups: Fully self-contained, and Partially-generative and non-generative. Fully self-contained are tools that produce an IDN artefact as an output, and Partially-generative and non-generative are tools that need externally produced assets in some sense to become an artefact (Shibolet, et al. 2018). In addition to these two main categories, the authors compartmentalize the tools further into sub-groups and “sub-lists” based on criteria such as purpose, quality, platform, level of automation, and more.
Green et al. (2018) create a taxonomy of game authoring tools in order to break down the differences and likenesses of their user experience. They found that there are three structural categories in how each tool facilitates authoring. They are as follows: Form-based, Graph-based, and Text-based. Form-based tools present the user with forms, often tailored to specific game engines, where data directly tied to the underlying game system supplements story content. Graph-based tools visualize narrative through a graph, where each node in the graph holds narrative content. Text-based tools are essentially text editors with some added functionality on the side for integration into an IDN format.
2.1.1 What Makes IDN Authoring Different From Traditional Authoring?
Traditional authoring of narratives, such as literature authoring, has extensive and thorough methods and concepts with which to comprehend its output and use, as developed through millennia of formal research. Models such as the narrative arc have been heavily used in the construction of literature, and its analysis. IDNs, and their authoring, with its unique properties, may not necessarily be subject to the same models, or if they are, not in the same manner (Koenitz 2015). In contrast to this, several researchers have applied literary theory to the authoring of IDNs: Green (2018) attempts to use Russian formalism, specifically Vladimir Propp’s Morphology, as a basis for an authoring tool explicitly targeted toward game authoring; and Bizzocchi, Nixon & DiPaola (2014) uses the idea of a narrative arc to analyze and design game narrative; researchers within the field of IDN and its authoring use the term narrative arc as an implicit module of all narratives they are considering, with no apparent disassociation from its original meaning (see for example Sullivan, et al. 2008; Bizzocchi, et al. 2014; LeBlanc 2006).
Temporality in classic narrative forms is closely controlled by the author, making it a linear authoring experience even if the narrative’s story is non-linear. In an IDN, time may be experienced differently depending on which branches a reader travel through, making authoring a task consisting as much of structuring as of wording (Bolter & Joyce 1987). This line of thought is corroborated by Klimmt et al. (2012) in that authoring for interactive storytelling includes dynamically structuring narrative units. Adding to that, they claim that authors must share authoring with the reader, referring to the fact that a reader chooses how to interact with the system and, as such, is part of the authoring process. This leads to a notion that authoring tools must be innovative in their design to allow narrative units to be easily manipulated, created, and structured (Klimmt et al. 2012). Time in game narratives may also differ from time in which the player experiences them. Event time, or how time in the narrative passes, may be paused, slowed-down, sped-up, or real-time, while play time, or how the player experiences the game (and narrative) is consistently real-time (Juul 2004).
2.2 Shaped by Technology
It is in many ways apparent that technology shapes societies, infrastructure, and policies, with only a mention of the printing press or the nuclear bomb illustrating that fact quite vividly (Herrera 2003). What is perhaps not so apparent is how small or mundane tasks are shaped by technology, and to what extent (Leigh Star 1999).
Star (1999) highlights the importance of finding the master narrative in infrastructure – the driving self-appointed centrist voice of the design within. An example of a master narrative in this context would be bandages labeled “Flesh colored” that is a single non- adaptive color appropriately named only to people of particular skin color (Leigh Star 1999).
An example of a master narrative in infrastructure is highlighted by Winner (1980) as he describes Robert Moses’ work of designing and developing massive engineering projects in New York in the mid-20th century. Moses designed the Cross Bronx Expressway to have low overpasses to deny buses from driving under it, practically making public transit impossible from one side to the other. This meant that poor people, mostly minorities, who disproportionately used public transit to get around and were disproportionately located south of the expressway, had diminished opportunities to travel north of the expressway (Winner 1980). Winner uses this example to illustrate that technology does indeed have politics, as even political-agnostic feats of architectural engineering have consequences (in this instance intended such), which are political (Winner 1980).
Politics of technology may extend to interaction between international political agents, where the capacity for interaction between system and user, or user and user through a system, is regulated through narrowly designed templates — in essence, creating formulaic approaches with which to interact. The ensurance of apoliticalness of these formulas is arbitrary at worst and subject to yet another subjective inquiry at best (Herrera 2003).
Even the format of communication has an impact on use. Both email and instant messaging, although mostly freeform in their textual use and expression, have shaped communication between people. Acronyms, emoticons, sharing images, and hyperlinks, as well as the tacit privatization and exclusivity of communication has molded the user experience implicitly (Schrum & Benson 2002).
2.2.1 Technology Shaping IDN Authoring
Malazita (2018) argues that the underlying technology inherent to the game engine used in the development of the game BioShock Infinite (2013) limited the design of further releases in its series of episodic add-ons. These limitations shaped a sequence of gameplay away from its developers’ ambitions to such a degree that the resulting artefact shared very little with its original intent (Malazita 2018). The physics engine, the part of the game engine that determines how physical objects react with each other in the game, is based on Newtonian physics. The “normal” physics clashed with the developers’ vision and ambition for a new main character in a playable add-on to BioShock Infinite (2013), which included being able to bend space-time and travel/summon other dimensions (Malazita 2018).
To put the above in other terms, a master narrative existed in the software used to develop the game. The politics embedded in the design of the game engine were so powerful even the developers’ own intent was circumvented and undermined. This exemplifies a concept of embedded politics nearly always serving the dominant power structure in the space (Leigh Star 1999), which in this case meant that the physics engine could not accommodate behavior outside the domain of Newtonian physics.
Authoring tools for interactive stories may offer different tiers of creative flexibility, ushering users to model their stories in a myriad of ways. However, formats tend to conform and settle into regularities when larger clusters of authored works are analyzed (Garzotto, Herrera & Fernando 2010). This is consistent with the notion of a master narrative which effectively shapes the authoring process (Leigh Star 1999).
Kitromili, Jordan & Millard (2018) explores an initial set of IDN authoring tools to determine how writing tools shape interactive stories and observe four areas that may do so.
Their research is based on adapting one interactive story (interactive fiction) into two different authoring tools (none of which was used to create the original artefact). The four areas of friction they observed were: Rewinding and Revisiting, Definition and Description of Locations, Text Delivery, and Navigational cues. Below is an explanation of each of these.
Rewinding and Revisiting are separated, as revisiting means to revisit a location or narrative object, and rewinding means to rewind the user’s history of choices in order to experience a previous location or narrative object. The critical distinction here is that revisiting keeps the current state of the game or story that the user is currently on, while rewinding also rewinds the state (Kitromili et al. 2018).
Definition and Description of Locations differ in that authoring tools offer different ways in which to allow the user to progress through the story. Some use descriptive text to offer the user hyperlinks with which to navigate, others use cardinal directions, and some use GPS coordinates, plotted on a map. The differences infer that the steps the author must take in
order to convey the spatiality of their story are highly influenced by the authoring tool used (Kitromili et al. 2018).
Text Delivery is how narrative content is delivered to the user, specifically in which ways it is possible to do so in each authoring tool. Some authoring tools may have only one method of delivery (i.e., go to a node, read the node), while others have more complex systems in place (i.e., after ten seconds, the user receives a note, and another node appears) (Kitromili et al.
2018).
Navigational cues are hints, however obvious, to the user that some particular piece of narrative content will cause progress in the story. With some authoring tools, such navigational cues are inherent to the system and easily discovered by users, while in others, they are non-existent or are not inherent but possible to emulate.
3 Problem
The field of IDN authoring is distinct from neighboring fields of study such as literature authoring in several ways. Narrative structure and time management are as important as the wording of dialogue or prose, and this requires different techniques to be utilized in the creation of IDNs than in traditional narratives. What techniques to use is not entirely clear- cut, and authoring tools made to aid in the authoring process use different approaches to solve the problems at hand. It is therefore necessary to evaluate the authoring tools in the creation of IDNs to not only see if and how they solve the problems of structure and time, but how their design inevitably shape the authoring and its result (Koenitz 2017). The output of an IDN authoring tool is important in the sense that it is what the toolset provided by the tool has been designed to produce. I.e., the output is the result of the authoring tool’s functionality. In the same vein, looking at the functionality of an authoring tool, and in the ways content can be manipulated, authored, and created within the tool itself has the advantage of giving an insight into why the output is how it is. To look at authoring tools from the authoring process first also has the advantage of realizing potential within the tool to present its content through itself; in other words, to consume the content from within the authoring tool, instead of from the output of the authoring tool. Since this research is focusing on looking at IDN authoring tools through the lens of Game Writing – or writing for games (as opposed to writing interactive fiction, for example) – this perspective of consuming content through tools is an important one to look at. This is the first reason why the authoring process will be the focus of this study, and not the output of the authoring tools. The second reason revolves around the adaptation itself: If we do not look at the authoring process, it is difficult, if not impossible, to determine how aspects of the adaptation source were translated, and why – or why they weren’t translated.
IDN authoring tools are made to make the process of authoring IDNs easier or more effective, but design biases are inevitable, whether intentional or not. Design biases in authoring tools may therefore also shape the authoring and its resulting output. Those biases being uncovered and made transparent is beneficial to further general research, but also to the specific tool and its users.
The question being researched is: How does TextureWriter, Scrivener, and Twine shape artefact creation when adapting a game design document?
3.1 Method
Under the pretence of answering the question of how, in effect writing, is shaped by authoring tools, it is ultimately unreasonable to delegate the responsibility of evaluating the tools to anyone other than the writer. With that in mind, a qualitative approach where the process of IDN artefact creation is documented and evaluated by the writer is appropriate.
A game design document following the proposed standard set forth by Salazar, et al.
(2012) will be created as a basis for the rest of the research. Three to six participants will be recruited to access one each of the three authoring tools in question and asked to adapt the game design document in said tool. Ample time will be given to participants to create an artefact in their designated authoring tool, after which a semi-structured interview in the form of a focus group will take place. A focus group is a way to elicit qualitative statements and reactions, not constrained to ‘yes or no’ answers (Longhurst 2003), to bias in design by users of the tools. The participants will be recruited from a pool of Game Writing students, as familiarity with theme is important for conversation to be informative and qualitatively
digestible (Longhurst 2003). The focus group discussion will be maintained by a set of predetermined questions all aimed at investigating any relationship between authoring tool design and differences in output (artefacts). Though the questions will be predetermined, some malleability as to which questions to ask, when to ask them, and how must exist in order to satisfy the social, informal nature of a focus group discussion (Longhurst 2003). To ensure accurate and detailed data collection, the focus group discussion will be audio recorded.
In order to satisfy the ethical guidelines put forth by Vetenskapsrådet (2017), several actions and considerations will be taken in both presenting the research to potential participants, and in conducting the research. They are as follows: Potential participants will be made aware of the intention of the research, how it will be conducted, their role in it, as well as of any personal information that may be collected; The personal information collected will consist of the audio recording that will take place during the focus group; Potential participants will be made aware that participation is not mandatory and may be voided at any time by their own volition; Choosing to not participate or to discontinue participation during the research will not result in retribution, and potential participants will be made aware of this; Any data collected from the research will not be used outside of his specific research.
Extending the research of Kitromili et al. (2018), this research aims to adapt a video game design document into three authoring tools to determine if their observations hold true, and what other observations can be made under these new set of circumstances.
Understanding what gets lost in translation (or adaptation) from game design document to authoring tool artefact might also bring insight into the opposite. How emblematic narrative scripts serve as a foundation to games and what is gained or lost along the way from text to game is something often overlooked (Flanagan 2017).
In more simplified terms, this research will:
• Create a game design document artefact
• Recruit Game Writing students to adapt the above design document into Scrivener, TextureWriter, and Twine
• Discuss the adaptation process and output with the Game Writing students in a focus group setting.
3.1.1 Authoring Tools
The three authoring tools to be used are Scrivener (2019), TextureWriter (TW) (2020), and Twine (2019). Scrivener is a non-generative tool used for script creation in many different areas. While Text-based, Scrivener has many features akin to those found in Form-based authoring tools, and features a “cork board,” which functions as a notation board (see figure 1).
Figure 1 Scrivener’s cork board feature.
TW is a Fully self-contained authoring tool, which could be presumed to be a Graph-based authoring experience and was developed to be an in-between of the two tools used by Kitromili et al. (2018) in their initial research. TW has a “text-forward” approach to authoring, putting emphasis on the content of the narrative nodes more-so than their structure (compare figure 3 and figure 4, for example). TW also has forms tied to the underlying system, adapting an all- around hybrid shape.
Figure 2 The main authoring interface of TextureWriter.
Figure 3 The “Pages” view of TextureWriter.
Twine is a graph-based fully self-contained authoring tool that exists as both standalone software and an online tool. Its interface is simple, yet underlying tools allow more advanced users to create their own mechanics through code.
Figure 4 Twine’s main interface showing the story graph.
4 Implementation
For a design document to be of any value in this endeavor to evaluate game writing software, it must resemble a typical game design document (GDD). Schell (2015) argues that a “typical”
GDD does not exist, and even goes so far as to say that it will never exist since games are so diverse. However accurate that may be, there are enough commonalities between the majority of games that including some (or most) of those commonalities will, by definition, create something typical, or archetypical. The first part was then to identify common game-tropes in order to copy these commonalities. The second, to apply them in an original game design. The final part was to put them into the GDD template created by Salazar et al. (2012).
4.1 Identifying Typical Tropes
The goal of this section is not to find the most typical or the most middle-of-the-road game design tropes. Instead, it is to identify enough of them to, in later sections, be able to piece together what could be a game that does not stand out as something atypical or out of the ordinary. It is essential to not be extraordinary or underwhelming in the game design to give a somewhat fair baseline from which to determine how and where the IDN authoring tools shape their outputs.
Based on Björk & Holopainen’s Patterns in Game Design (2004), a database of common game design tropes was set up (gdp3 2020). This database makes finding common tropes easy, as we only need to look at a few games and look up the tropes (or patterns) used in them. Undoubtedly, there are hundreds of tropes that apply to each game, and to limit the search only a few prominent characteristics of each game will be taken into consideration.
The first game used in this search for tropes was Counter-Strike: Global Offensive (Valve Corporation 2012) – a massively popular multiplayer shooter. Two patterns found here that feed off each other are Tactical Planning and Gain Information. The latter meaning to let the player discover new information in a game of imperfect information, and the former meaning to use whatever information the player has at hand to plan their moves tactically.
The second game was Kingdom Come: Deliverance (Warhorse Studios 2018) – a singleplayer adventure roleplaying game. This game’s broad scope made it difficult to determine which ones were the most prominent, and so a discrete selection of two that were somewhat prominent was made. Guard is a pattern meaning that there is a guard (commonly a soldier) guarding some sort of crucial object or area, hindering the player from getting to it.
Pick-ups are essential in many roleplaying games since they extensively deal with the player picking up distinct objects like weapons and armor for later use.
The third and final game looked at was Phantom Doctrine (CreativeForge Games 2018) – a strategic spy-thriller where the player controls a network of spies. Optional Goals are defined as goals that are non-essential for the player to succeed overall. Avoiding enemies is another prominent feature, and as such, the pattern called Evade, which means precisely, that fits well.
4.2 Creating an Original Design Idea
The common game patterns found above were examined, and a focus on Evade and Tactical Planning as the core focus of the game idea, as they seemed to synergize well (i.e., plan your route to avoid enemies). This focus led to the basic idea of the player controlling a character’s movement to direct them to an end goal, all the while avoiding enemies. The idea grew to be a tactical isometric game akin to X-COM: Enemy Unknown (Firaxis Games 2012) or Commandos 3: Destination Berlin (Pyro Studios 2003) (see figure 5 and 6, respectively), but with a different theme. The theme would be a medieval world plunged into literal darkness by
“Night People,” who blocked their access to daylight. The otherwise sunny and bright world was invaded by the Night People and remained occupied. The player will control an uprising of rebels, who are trying to bring sunlight back to the darkness and by doing that oust the Night People.
Figure 5 A screenshot from X-COM: Enemy Unknown (Firaxis Games 2012),
showing a regular combat sequence.With this groundwork laid out, it was a matter of including the other patterns in ways that made sense in this framework. Guard was automatically created through the setup of the previous patterns, in that the player has a goal (to reach the end of the level), and enemies are guarding that goal, hindering the player from reaching it. Thematically, the enemies could now be literal guards – medieval soldiers patrolling and standing guard – to emphasize the trope further. To fit Gain Information into the game design, exceptional measures needed not to be taken as ways to circumvent the guards that were not explained to the player by the game may be learned through watching the guard’s patrol schemes. However, to make the pattern more explicit, a shortcut was added. Text being the only medium through which to explain the game design made it challenging to keep track of the potential flow of the game. As such, a sketch of a game level – or mission – was made (see figure 7). This sketch allowed for better visualization when trying to fit each pattern into the game. The shortcut mentioned before was blocked off in order to satisfy the Pick-ups and Optional Goals patterns, as now, to get by it, an item had
to be picked up and brought there first, creating both an optional goal and a required pick-up for that goal.
While these design decisions satisfy the patterns derived from the games above, and the product would likely qualify as a somewhat typical game, it lacked depth. Depth may not be necessary from a mechanical point of view in order to classify something as a game, but from a thematic and narrative point of view, depth creates emotional context (Ip, 2011). To expand on the idea of depth, another playable character was created, besides the protagonist, and to not have two identical characters, they were each given a unique ability. Including these abilities into the design gave rise to new dynamics and demanded many new points of interaction in the game, increasing depth. In order for a character to not be caught out in the open while the player was interacting with the other character, hiding spots were introduced where no enemy could see them.
Figure 6 A screenshot from Commandos 3: Destination Berlin (Pyro Studios
2003), showing the main game sequence.Figure 7 A rough sketch of what a game level (“mission”) looks like, as seen from
above.4.3 Creating a Design Document
The GDD template provided by Salazar et al. (2012) is based on applying an SRS (Software Requirements Specification) approach to a standard game design framework called MDA (Mechanics, Dynamics, Aesthetics) created by Hunicke, LeBlanc & Zubek (2004). While the aesthetics of MDA was initially meant to include the description of player experience (Hunicke et al. 2004), Salazar et al. (2012) detaches player experience from the aesthetics-part and applies it as a standalone part of the design process.
4.3.1 Streamlining the Design Document
As Schell (2015) points out, a GDD serves two purposes: remembering the design and communicating it to others. The purpose of this paper is to communicate the design idea to game writers, to ultimately evaluate IDN authoring tools, and as such, as much information as possible must be maintained regarding the design. At the same time, being too verbose, to the point of creating red herrings for what should be included in the game writers’ adaptation, would be unfortunate. Considering that, it was decided to only include one mission in the design document. Building on this, several parts of the GDD template were removed to further streamline the necessary information given to the participants of the study. While Salazar et
al. (2012) make no effort to point out that all sections of the template must be filled out (or, indeed, the opposite), I will list the sections removed and the reason for removal here below:
Objectives to be achieved by the game – this section was removed as it is unnecessary to explain any potential commercial viability the finished game might have.
Game justification – this section was removed for the same reason as above.
Player characteristics – this section was removed for the same reason as above.
Business constraints – this section was removed for the same reason as above.
D[e]tailed business constraints – this section was removed for the same reason as above.
Target platforms – this section was removed because it has no impact on a game that will not be made. No special considerations have to be made for the target platform.
History summary – this section was removed as any history of the development of this game design is present in this paper, and wholly unnecessary for the participants to know about.
Initial scope – this section was removed as it is unnecessary to explain any development-specific logistics the game may require.
Assets list – this section was removed for the same reason as above.
Technical constraints – this section was removed for the same reason as above.
D[e]tailed technical constraints – this section was removed for the same reason as above.
Constraints and assumptions – this section was removed for the same reason as above.
Assumptions – this section was removed for the same reason as above.
Document references – this section was removed for the same reason as above.
Attachments – this section was removed for the same reason as above.
Missions/levels/chapters Flow – this section was removed as only a single mission would be in the design document, and as such, nothing would exist before or after it.
Other Missions/levels/chapters elements – this section was removed as there are no other elements than those described in the other sections.
Special Areas – this section was removed because there are no special areas.
Game log elements – this section was removed because no log will be kept of score or progress while playing the mission. Any potential log-keeping happening to keep track of progress between missions are out of the scope for this particular design document.
Game log elements visual – this section was removed for the same reason as above.
Game world elements – this section was removed because outside of the core gameplay, there are no elements at all.
Other elements – this section was removed for the same reason as above.
Game world elements visual – this section was removed for the same reason as above.
Other elements visual – this section was removed for the same reason as above.
Game world elements sound – this section was removed for the same reason as above.
Other elements sound – this section was removed for the same reason as above.
Special areas visual – this section was removed for the same reason as above.
Special areas sound – this section was removed for the same reason as above.
Missions/levels/chapters sound – this section was removed because the mission does not have any extraordinary soundscape as opposed to the rest of the game, and it has already been described in sufficient detail.
Interpersonal gameplay – this section was removed because the game is single-player only and, as such, cannot describe gameplay between players.
Game learning – this section was removed because teaching the player to play the game is outside the scope of this particular study and not something the participants should try to adapt.
4.3.2 Filling Out the Template
Much of the template created by Salazar et al. (2012) requires inputting data in an SRS- manner, specifying technical requirements in as much detail as possible. That is, however, also broken up with sections where such a technical specification is not feasible. Salazar et al.
(2012) admit that improvements to their template include attaching practical examples to complex systems. This improvement was considered and applied in some situations where the text could get overly technical or complex, especially when describing contextual interactions between player characters and interactive objects. Other areas that did not require an SRS- input were ones of theme, narrative, genre, and aesthetics.
Using Burn & Carr’s definition of video game genres (2006) as a base, the genre of the game was defined as an isometric tactical adventure, to capture both gameplay-specific and thematic features.
Narrative was explored in the design document, mostly in terms of backstory and premise. Narrative progression, goals, or development were not touched on as much. While narrative was included, it did not mesh with any of the technical categories of the template, and as such, it was not tied to progression, objectives, rewards, or challenges of the game design, nor was it anything more than implicit in the player experience section.
In the sections of SRS-input, there was quite a bit of overlap, which was subsequently removed – there was no need to describe the outcome of a player interacting with a guard when it had already been described somewhere else. If anything, maintaining a document with significant overlap would require rework, the reduction of which was one of the goals of creating the design document template (Salazar et al. 2012). Overlap still exists, however. To reduce overlap, as little as possible was written in the overview sections while still getting the point across, to then further explain it in a more detailed section. E.g., while typing Drew’s Core game elements section, his appearance remarks were kept minimal, in order to expand on them later in the Aesthetics section. The finished GDD can be seen as Appendix C.
5 Evaluation
This section will assess the implementation of the study, starting with how the participants of the study and focus group shaped the discussion, and therefore the results. This to explain deviations from the original intent of the study in the gathering of results. The results of the focus group will then be presented before moving on to an analysis and summary of those results.
5.1 Study Preparations
Dozens of Game Writing students at the University of Skövde were asked to participate in the study, from which four students agreed to take part. Two participants were assigned TextureWriter, while the other two were assigned Twine and Scrivener, respectively. The study aims at evaluating three different IDN softwares. With four participants, two participants are forced to use the same software. The primary reason for not choosing Twine as the software to be evaluated by two participants is: as Game Writing students at the University of Skövde, Twine has been used extensively throughout their education. As such, they are more likely to already have a broad knowledge about it, diminishing the value of undertaking a new creation process in it. After Twine was ruled out, Scrivener and TextureWriter were both valid options.
As points about each remaining software’s virtues and weaknesses were considered, they were ultimately ruled to not have any effect on the outcome of the software selection, as to hold a neutral standpoint and allow the results to speak for themselves. TextureWriter was then selected in a coin toss.
Unfortunately, the participant who entered the study and was selected to use Twine did not complete the study. This means that any results gathered about Twine are purely based on the other participants’ comparisons and comments regarding it.
5.2 Focus Group
The focus group of three participants and a moderator was conducted over a Voice over IP (VoIP) solution called Discord (Discord Inc. 2020), where participants used microphones to discuss and answer questions synchronously. The discussion was kept just below one hour in length to reduce any potential fatigue of the participants. To start off, the participants were introduced to what the subject of the focus group would be, after which the ethics of the study were explained and topics such as their anonymity were brought up. The participants were asked if they were comfortable being recorded, and having their first name used during the discussion if it was changed and anonymized in the transcripts, to which everyone agreed. The discussion was from then on recorded and questions were asked.
To facilitate the discussion, questions by the moderator were kept open to allow for a wider interpretation and to allow the participants a broad scope of interaction. In addition, any comments or remarks made by the moderator were instead narrow to allow participants to more clearly agree or disagree. The principal expectation of outcomes from this focus group were to derive the participants’ use of their software, how they approached the problem of adapting the design document, as well as what they felt about the output of their work.
The recording was transcribed (see Appendix A), and participants were marked as “A,” “B,”
and “C,” respectively, with B and C having used TextureWriter, and A having used Scrivener.
The moderator was marked as “J”. The original transcript being in Swedish, as participants were all speaking Swedish, a translation into English had to be made to effectively communicate the results (Appendix B). The translation was kept as close to the original as possible, with a few exceptions: (a) if the original transcript held peripheral meaning not clearly communicated through words and instead added in post-script clarification brackets, it was translated as if clearly communicated (for example, compare the “[Twine]” post-script addendum to Appendix A, page I and Appendix B, page XIII); and (b), if keeping it like that ruined any apparent original intent (for example, compare “i princip” in Appendix A, page II and “basically,” in Appendix B, page XIV).
5.3 Results 5.3.1 Scrivener
The participant who used Scrivener explained the software as akin to Microsoft Word, a popular word processing software. The participant said they thought of the software as a way to simplify the handling of documents, and that its strength was to handle a lot of smaller documents. They emphasized that the software was very good for this application, and that organization was a large part of why it was good. The participant valued being able to open several documents at once to look at and scroll through while writing. In addition, the participant valued being able to bring in outside material like research and inspirational images on the side, in order to look at them while writing in another document.
The participant would describe a Scrivener project as a network of nodes. However, they underline that connections between the nodes are not navigational in nature. The participant discussed several times how they thought of the process within the software to resemble “a lot of post-it notes,” in particular when referring to the software’s corkboard feature (see figure 1). They said that feature provided a good overview. The participant also praised the tree-like structure of any documents added to the project, saying that exploiting its hierarchical traits were especially useful.
The participant argued that a functionality in Scrivener that lets users merge several documents together was useful in that it allowed a writer to combine several of these “post-it notes” into one reading surface. The participant said that this was a good way of reading through a full dialogue, were it comprised of several different bits.
The participant explained that they focused on using Scrivener as a tool to write a script for the characters, as opposed to adapting game mechanics from the design document. They felt that there was no room to create a game in Scrivener, as there lacked a layer of interaction, and that Scrivener may only be used to create scripts or text-material for a game. Instead, the participant focused on creating only a story. When asked about why they did not regard Scrivener as a viable option for making an interactive narrative, they clarified that while there are ways of connecting documents, they are very cumbersome, and there is no way to enforce a hierarchy or particular flow through those connections. The participant also gave the software’s output as a reason for not being an interactive narrative, as the output when exporting a project from Scrivener results in a single text document.
The participant expressed that the several ways in which information, in the shape of text, images, sound and other materials, could be presented was very conducive to the authoring process. They also said they thought of this as beneficial for collaborations as each creator is
able to easily discover changes. They did not view the creation process within the software as interactive or as a means to create interaction – they viewed it as a work space for creating scripts.
The participant did not structure their project in regards to time passing in the game. They reasoned that the only way to indicate time passing in Scrivener is through text.
The participant leveraged the parts they thought were useful in the software and as such created many smaller documents that represented each character and described their interactions. They felt that the most difficult thing in adapting the game design document into Scrivener was the software did not allow for mechanics to be implemented. The participant thought that writing longer texts, or for games with a lot of fragmented story pieces, Scrivener was a great tool, since you are able to merge pieces together in order to get a good view at what one playthrough might look like to the player. They said that they used this technique of dividing when adapting the design document because it was a smooth and easy way of working.
5.3.2 TextureWriter
Participant B found the creative process in TextureWriter to be similar to that of Twine, in that nodes are created, and links between nodes are then explicitly set up by the author. B found the interactable phrases created to link nodes with each other to be very similar to those in a game and replicated the behavior of interaction in the game design document well.
Both participant B and C agreed that TextureWriter is fundamentally a network of nodes, fairly similar to Twine, although nodes are known in TextureWriter as “Pages”. The participants using TextureWriter also agreed that the overview of pages was difficult to work with and was confusing at times, as pages changed position and could not be manually manipulated.
Participant C meant that this made it more difficult to write branching narratives and as such limited the use of TextureWriter to the authoring of linear narratives. The navigation between nodes was not always easy to create, explained participant B, as linking several pages to one common page was difficult. The player, or reader, of the output created by TextureWriter, does not implicitly have an overview over the “playing field,” clarified participant B, and authored explicit links were the only way to navigate between pages. Participant B expressed a desire for including images to represent the playing field and serve as an interactable map but explained that this was not possible in TextureWriter. C echoed B’s sentiment in saying they were forced to describe to the player where characters were through text, instead of through better means. B instead focused in on the viewing perspective presented in the game design document, saying that the isometric perspective was impossible to recreate in TextureWriter.
Participant B and C discussed how flags could be used to create puzzle games based on item fetch mechanics, meaning that a flag is set to true or false in one page, which subsequently leads to another page responding differently than previously. This, they meant, was one of the few mechanics available to them in TextureWriter, and as such they were limited in the types of interaction they could make. They viewed TextureWriter primarily as a means to create an IDN, and not as a means to write a script. They conceded that scripts may be written with the tool, yet making it playable (and in turn, transforming it into an IDN), would be effortless.
Structuring the narrative was a recurring theme of discontent in the discussion regarding TextureWriter. Both participants agreed that structuring the nodes in the overview, structurally linking pages together, and structuring by time were all difficult. Participant C expressed their dismay over the fact that TextureWriter does not have any functionality to allow modeling behavior over time, by saying that it was extremely difficult to keep track of where the player/reader was supposed to be located, and where any potential guards could be at that moment. C said they would have liked to have a sense of time passing, but that it was not accommodated for by the software, and as such they could only express it strictly through text. Participant B agreed and added a comparison to Twine, in which timers exist to model behavior over time, expressing a desire for similar behavior in TextureWriter.
Creating content in TextureWriter was simple and nice, said participant C, saying that the lack of coding made it easier to simply write in TextureWriter when compared to Twine. Participant B thought the interactable phrases was a great feature, saying that it allowed for more dynamic texts to be written when compared to the static links of Twine. C agreed.
B felt that giving the player/reader hints or cues about how to navigate through the narrative could be done in two nonexclusive ways. One being that the author gives hints through text, which B found to be not fun, and the other being which order the interactable phrases appear at the bottom. B said that interactable phrases appear in the order the author decides, from left to right. Since reading is often done from left to right (in the context of the culture in which the discussion took place), placing the phrase the author wants to guide the player towards on the left could be considered a hint or cue, B explained.
5.4 Analysis
While all three authoring tools in question were considered to be based on nodes, there was a difference in how strict the connections between the nodes were. Scrivener did not have an explicit way of maintaining a hierarchical flow between nodes, and any connections that could potentially be made were in addition to the implicit navigational interface provided by the software. Scrivener could therefore be used to create scripts and game writing documents, but struggle to create interactive narrative, since such a narrative would rely on the software itself providing the means of interaction between documents. TextureWriter, on the other hand, only has connections between nodes when explicitly created by the author, instead struggling to give the reader an effective overview. Neither Scrivener nor TextureWriter included the type of connections between nodes that were most conducive to authoring an adaptation of the given game design document.
Structure of narrative was a large point of discussion among the participants, and it exists in several different layers. The first layer is the overall structure of narrative nodes and their presentation. Where Scrivener has several different views to visualize a project efficiently, with a corkboard of “post-it notes” and a tree-view, TextureWriter has one unwieldy overview representing the nodes and their navigational connections. Another layer is temporal structure. Neither Scrivener nor TextureWriter has any tools for structuring their projects with event time in mind, something that the participants concluded would have been useful when trying to adapt the game design document. A third layer of structure comes in the shape of spatiality, where location of objects, characters and interactions are used as pillars on which to build a narrative. One participant alluded to needing a graphical map-interface to
represent spatiality, while another bemoaned the difficulty of representing the player’s (and guard’s) position. A fourth layer of structure is in the presentation of the content. One participant regarded TextureWriter as easier to write in when compared to Twine, due to the exclusion of code. Participants found very little functionality with which to format content within nodes. Scrivener has the ability to merge documents temporarily to allow the author to access the full length of a specific run of documents at once, while TextureWriter does not.
Mechanics of interaction differ between Scrivener, TextureWriter, and Twine. Twine offers support for authors to create their own behavior through code, while Scrivener offers nothing of the kind, and the only mechanics offered are those embedded in the software while authoring. TextureWriter offered the participants dynamic text additions and flag- manipulation for true or false-statements. For these reasons, Scrivener was seen by the participant exclusively as a work space for creating scripts, while TextureWriter was seen as limiting in its ability to sustain different types of game designs.
Including reference material into the project throughout authoring and having effective means with which to view it while not disturbing the workflow exists in Scrivener. The benefit of the first part of this is unclear, since including reference material in the authoring software itself at face value has little advantage over simply storing it outside of the authoring software environment. Any added value would come from the latter part in the above statement, in which the reference material is included in the author’s workspace without disturbing the authoring process. However, inclusion of multimedia into the output of the authoring program was thought of as highly desirable by the participants for other reasons (for example, see the above section about spatial structure). There was a consensus that images serve a purpose in the authoring process, and for the purpose of presentation to a reader, to convey information otherwise difficult to communicate through text.
5.5 Conclusion
Due to the exclusion of Twine in the focus group discussion, the original research question posed cannot be answered. Even though some results regarding Twine was gathered by the remaining participants, they are at best second-hand accounts based on the participants’ own thought experiments. While the original research question cannot be answered in full, the remaining authoring tools and the results gathered from their use still form valid conclusions.
The areas shaping content created by authoring tools that were suggested by Kitromili, et al. (2018) have all been proven to also be areas of contention in TextureWriter and Scrivener. In addition, several new areas of concern have come to light from this study.
Narrative structuring has many layers that are important pieces in development of interactive narrative, below follows a list of each layer and a description.
Fundamental structure refers to the way in which an author can view and control the network of narrative nodes they are working with. While both TextureWriter and Scrivener provides a way of manipulating the overarching structure, TextureWriter’s method of doing so is encumbering and imprecise. TextureWriter’s fundamental structure is represented through a network of pages with explicit connections (see figure 3). This structure cannot be directly manipulated by the author. Scrivener has by design several methods of evaluating and manipulating its overarching structure. In Scrivener, an author may choose to switch fundamental structure from a hierarchical tree-view to a corkboard of what could be described as “post-it notes” (see figure 1); these structures can be manipulated at will by the author.
Temporal structure is the ability to manipulate and view the event time of the narrative in order to structure narrative nodes on a timeline. The absence of temporal structure is an egregious lack in Scrivener and TextureWriter, specifically. Neither of the evaluated tools had any support for structuring nodes or content in a temporal manner.
Spatial structure is how the placement of objects, characters, and interactions may be structured in the authoring process. Interactive narrative often includes spatial abilities that the reader may deploy in order to further the experience. This became an apparent structural need when the participants attempted to solve a mechanical problem of where the player was situated at any one time.
Presentation structure refers to the author’s ability to structure content within nodes, in order to either present to the reader, or to accommodate the authoring experience.
Mechanics of interaction determine how limiting an IDN authoring software is in its ability to adapt to different genres or styles of interaction or game. In both TextureWriter and Scrivener, there is no support for implementation of any custom behavior. In TextureWriter, the participants were limited to interactable phrases and by boolean flags in creating content. In Scrivener, the participant had no access to any interaction mechanics in its output, and limited to the navigational features inherent to the software while in development.
Multimedia inclusion has the ability to unlock avenues of authoring difficult or even impossible to attain through text or interaction alone. Sound, images, and video may all have a role to play in what is possible to attain while authoring for a game. A participant requested the ability to use interactable images to enhance the authoring process, and another lauded the inclusion of multimedia as something very useful.
The notion of a master narrative, as coined by Star (1999) was surprisingly obvious to all the participants in the study. This despite the fact that they had a hard time articulating what created the environment from which they could derive that master narrative. Scrivener was described as a script-writing software, while TextureWriter was described as software for creating linear interactive fiction. At the same time, confusion as to what adapting a game design document entailed could be seen, as participants struggled to convert features of the game design document into their designated software. The master narrative of the IDN authoring software they were using quickly steered their paths, and they ended up creating a script and linear interactive stories, respectively. This suggests that authoring tools shape the game authoring process so profoundly that it is nearly impossible to deviate from the authoring tool’s master narrative, even if a conscious effort is made to circumvent or ignore it.
6 Concluding Remarks
6.1 Summary
The goal of this study was to evaluate three different IDN authoring tools in order to discern how the tools’ design affect the authoring done in them while adapting a game design document. This study extends the research first conducted by Kitromili, et al. (2018).
TextureWriter, Scrivener, and Twine were chosen as the three authoring tools, and four participants were recruited to use one each of these tools to adapt a game design document.
Two participants used TextureWriter, while one used Scrivener and the last used Twine. The participant using Twine did not participate in the last step of the study, and as such the goal set forth in the problem section could not be fully met.
The game design document followed a strict guideline in order to effectively communicate a game idea to the participants, while they were given ample time to adapt parts of it into their given authoring tool. Three participants completed the work and took part in a focus group to discuss their authoring process. The three participants did not include the participant who used Twine.
The results were hampered by the exclusion of Twine, yet they show that there are several ways in which the inclusion, or lack, of features in IDN authoring tools – specifically TextureWriter and Scrivener – shape the process in a substantial way. The differences observed by Kitromili, et al. (2018) were all observed to some degree in the evaluated authoring tools. In addition, six other areas were recognized as shaping the authoring process.
Structure has several connotations in the authoring of IDNs, and four different substrates of structure were identified as problematic: Fundamental structure, or how nodes or networks of nodes are represented and manipulated; Temporal structure, meaning how narrative nodes may be structured by event time; Spatial structure, meaning how the location of objects, characters, and interactions may structure the narrative; Presentation structure, or how the author is presented with its work surface. In addition to structure, two other areas were identified as shaping the authoring process: Mechanics of interaction, meaning how the author’s access to interaction behavior, or access to creating their own methods of interaction, shapes their authoring process; and Multimedia inclusion, or to which degree the authoring tool allows multimedia to be used to add to the authoring and end user experience.
The results also show that the degree to which authoring tools shape the game authoring process is considerable. Authors may actively try to subvert the tool’s master narrative but will find doing so to be exceedingly difficult and will probably fail in doing so.
6.2 Discussion
Below follows a discussion of the study’s parts, reflecting on how it was put together and conducted to better the understanding of its strengths and weaknesses. It will argue for how the results of the study may bring more clarity to the somewhat sparse area of academia surrounding Game Writing and IDNs.
6.2.1 Method
The chosen method of producing a game design document artefact, recruiting individuals to adapt it into different authoring tools produced results. Those results were useful in answering the question asked by the study. Through this perspective, one could argue that the method was therefore not only adequately valid for this study, but a good choice. However, some of the pros of using a focus group, as laid forth by Breen (2006), were not properly taken advantage of, and guidelines were also not followed. Breen argues that focus groups should be used when the social context of the situation may be exploited in order to generate new ideas, and that if looking for personal experiences, one-on-one interviews should instead be prioritized (2006). Since the study looks at personal experience and asks participants for their own process, and the need for one-to-one comparisons between authoring tools is non- existent, it may have been wise to conduct the interviews in a one-on-one setting. On the other hand, information gained by the moderator from comments during the focus group were used to further investigate topics, which could not have happened in one-on-one interviews.
Breen (2006) says that a moderator adding questions on top of each other should be avoided, as it could be considered confusing. This error was made on several occasions during the focus group interview. It was made due to moderator inexperience and can most likely be improved.
In addition, Breen (2006) proposes that a pilot study should be conducted, in order to sharpen the questions asked and for the moderator to be better at directing the discussion to where it needs to go. In a perfect world, a pilot study would have been conducted in this case, although with limited time, and most of all a limited pool of potential participants, it can be argued that it would have been difficult to put one together.
As with most qualitative research, the weak link is oftentimes the researcher themselves, and such may also be the case in this study. My own bias may have influenced the analysis of the results, or even the questions asked, or comments made in the focus group. While I took precautions such as writing out general statements and questions before the focus group took place, to see them as objectively as I could and change them if necessary, there is no guarantee of objectivity. In fact, there is almost certainly a guarantee of the opposite. Nevertheless, I would believe that the subjectivity that exists is negligible in the face of the analysis and end results.
The most troubling part is that one of the three authoring tools was not represented in the final focus group. The size of the group of participants was simply too small to accommodate for any potential fall-off. It should have been larger.
6.2.2 Contribution
This research sits on top of work made by Kitromili, et al. (2018), as to expand on a question asked by Koenitz (2017). It is meant to serve as a springboard into an exciting new area of IDN research, where the authoring process is taken into consideration. The contribution this study makes to that part of academia is of several concerns regarding the future-proofing of IDN authoring tools. The first step to any problem is recognizing there is one, as the famous quote goes, and the second step must undoubtedly be to describe the problem in detail. How would one otherwise arm themselves with the correct ammunition to fight the problem. This study describes problems with IDN authoring software. It doesn’t intend to solve those problems, or even point fingers as to why they exist, but it does lay them bare for people to be aware of, going forward.
Hopefully, the results of this study can fuel industrious authors and creators to invent and create methods and software with which to solve these problems. That could lead to authoring taking up a larger role than before in the business of Game Writing, as authoring software becomes more viable for each and every type of IDN.
6.3 Future Work
Upscaling the research done here could lead to more breakthrough insights into what an authoring tool is able to do, and what it is not able to do. More participants, longer authoring time, and therefore more perspectives colored by more experience in the subject. It is also important to remember that one of the authoring tools this study aimed at evaluating was not properly evaluated, and as such, further research with that tool, and other authoring tools, may also bring more insights into authoring tools as a whole.
It is also viable to conduct a similar study with other foundational adaptation material. A design document following another standard, or a game design document of a wildly different genre. These changes in material could very well lead to interesting results.
An interesting thought is if experience in the creation of IDNs in specific authoring tools (i.e.
proficiency), bears any meaning when discussing limitations of said authoring tools. If another study were to be conducted with the inclusion of Twine, it may be very possible to see a discussion take place where mechanics of interaction are not mentioned as a potential pitfall.
The ramifications of that in terms of what could be determined as an authoring tool shaping its output, and the author shaping the output, would indeed be a fascinating thought to delve deeper into.
References
Aarseth, E. (2012). A Narrative Theory of Games. Proceedings of the international conference on the foundations of digital Games, pp. 129-133.
BAFTA (2014). Games in 2014 | BAFTA Awards. [Online]
Available at: http://awards.bafta.org/award/2014/games [Accessed 11 02 2020].
BioShock Infinite. (2013). [Game] Irrational Games.
Bizzocchi, J., Nixon, M., DiPaola, S. & Funk, N. (2014). The Role of Micronarrative in the Design and Experience of Digital Games. DiGRA '13 - Proceedings of the 2013 DiGRA International Conference: DeFragging Game Studies, Volume 7.
Björk, S. and Holopainen, J. (2005). Patterns in game design (Vol. 11). Hingham: Charles River Media.
Bolter, J. D. & Joyce, M. (1987). Hypertext and creative writing. Proceedings of the ACM conference on Hypertext, pp. 41-50.
Breen, R. L. (2006). A Practical Guide to Focus-Group Research.
Journal of Geography in Higher Education, 30(3), pp. 463-475, DOI: 10.1080/03098260600927575
Burn, A. and Carr, D. (2006). Defining game genres. Computer games: text, narrative and play, Polity Press, Cambridge, UK, pp.14-29.
Commandos 3: Destination Berlin. (2003). [Game] Pyro Studios.
Counter-Strike: Global Offensive. (2012). [Game] Valve Corporation.
Discord. (2020). [Software] Discord Inc.
Flanagan, K. M. (2017). Videogame Adaptation. In: T. Leitch, (ed.) The Oxford handbook of adaptation studies. New York: Oxford University Press, pp. 441-456.
Garzotto, F., Herrero, E. & Salgueiro, F. (2010). One Tool-Many Paradigm: Creativity and Regularity in Youngsters’ Hyperstories. In: R. Aylett, et al. (eds.) Interactive Storytelling. ICIDS 2010. Lecture Notes in Computer Science, vol 6432. Berlin, Heidelberg: Springer, pp. 44-49.
gdp3 (2020)
http://www.gameplaydesignpatterns.org [Accessed 2020-04-14]
Green, D. (2018). Novella: An Authoring Tool for Interactive Storytelling in Games. In: R.
Rouse, H. Koenitz & M. Haahr, (eds.) Interactive Storytelling. ICIDS 2018. Lecture Notes in Computer Science, vol 11318. Cham: Springer International Publishing, pp.
556-559.
Green, D., Hargood, C. & Charles, F. (2018). Contemporary Issues in Interactive Storytelling Authoring Systems. In: R. Rouse, H. Koenitz & M. Haahr, (eds.) Interactive
