anapproachtocollaborativestorytelling · even mentions the need for an entity of interactive drama...

An approach to Collaborative Storytelling

Guilherme António Mesquita Barbas Fernandes

Dissertation to obtain Master’s Degree inComputer and Software Engineering

JúriChairman: Professor José TriboletAdvisor: Professor Carlos António Roque MartinhoExaminer: Professor Isabel Alexandre

October 2011

Acknowledgements

Tinha preparada uma lista com várias pessoas a quem agradecer, desde os meus paisque sempre me apoiaram, aos meus amigos que sempre me motivaram quando me deparavacom um obstáculo, ao meu orientador que teve de me aturar e a muitas das minhas ideiasmesmo quando lhe pareciam muito extravagantes. Mas a verdade é que essa lista estavasempre em constante crescimento e a dada altura a enorme página que me era reservadapara lhes agradecer tornou-se pequena e já não conseguia incluir todas as pessoas que, deforma directa ou indirecta, contribuíram para este trabalho. Como tal...

Obrigado a TODOS

Se se estão a interrogar "será que ele se refere a mim?", podem tomar isso como certo.

Lisboa, November 19, 2011Guilherme António Mesquita Barbas

Fernandes

"Individuals are becoming muchbetter storytellers"

Mike Kasprow

Resumo

Dado o seu enorme potencial, Interactive Storytelling tem sido o tema de muita deinvestigação realizada academicamente em tempos recentes. A promessa de criar umahistória capaz de se adaptar e moldar à pessoa que a está a experienciar é vista comosendo algo possivelmente revolucionário tendo em conta as implicações que isso trariapara uma indústria como a do entertenimento. Contudo, alcançar este objectivo não sefaz de um momento para o outro.

A criação deste tipo de histórias tem sido um grande entrave, desde o início, para autilização deste tipo de histórias . De facto, a maioria da investigação feita tem sido rela-tivamente ao processo de autoria, que apesar de apresentar alguns resultados e indícios demelhoria continua a apresentar-se como uma grande limitação, onde apenas especialistassão capazes de criar este tipo de histórias. Para tentar resolver este problema, apresen-tamos uma nova abordagem: usar o poder da colaboração e trabalho em equipa pararemover as limitações existentes no processo de criação de histórias interactivas.

Como pouca ou nenhuma investigação foi realizada nesta área o trabalho desenvolvidofoi principalmente de criação, de testar novas abordagens usando como base algum dotrabalho desenvolvido para “autoria normal”. Para demonstrar o trabalho realizado foicriado um protótipo chamado StoryColla de um sistema de autoria colaborativa parahistórias interactivas que não requer qualquer tipo de experiência em programação sendopassível de ser utilizado por qualquer autor.

Abstract

Given its enormous potential Interactive Storytelling has been the subject of manyacademic research in recent time. The promise to create a story capable to adapt andmould itself to the person who is experiencing it has several implications specially whenwe are talking about the Entertainment Industry. However, this does not come freely.

The creation of such stories has been a thorn on its paw since its inception. Due to thisfact the lion’s share of investigation has been around the authoring part of InteractiveStorytelling with some results in recent times but still with a very troubled existencewhere only experts are capable of creating stories. The approach taken to solve thisproblem consists in using the power of collaboration and team work to solve the manyissues identified that currently limit the Interactive Storytelling world.

Since there is little to no work in the field of Group Authoring for Interactive Story-telling the work made was mainly of creation, of testing a new approach with some helpfrom the work developed for “normal authoring”. To demonstrate the research’s results aprototype named StoryColla of an authoring collaborative system was created. A pro-totype that not only allows for the creation of Interactive Stories collaboratively it alsodoes not require any type of programming expertise to be used.

Palavras ChaveKeywords

Palavras Chave

Interactive StorytellingAutoria em GrupoColaboraçãoRPG

Keywords

Interactive StorytellingGroup AuthoringCollaborationRPG

Table of contents

1 Introduction 1

1.1 Motivation and Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Proposed Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Concepts 5

2.1 Interactive Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3.1 Branching Trees . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3.2 Foldback Schemes . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3.3 Constipated Trees . . . . . . . . . . . . . . . . . . . . . . 8

2.1.4 Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.4.1 Authoring Requirements . . . . . . . . . . . . . . . . . . . 9

2.2 Group Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Collaborative Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 RPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 GM-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3 Collaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.4 Universalis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.4.1 Currency . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.4.2 Setting the Story . . . . . . . . . . . . . . . . . . . . . . . 15

i

2.4.4.3 Story Components . . . . . . . . . . . . . . . . . . . . . . 15

2.4.4.4 Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.4.5 Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.4.6 Fines and Complications . . . . . . . . . . . . . . . . . . . 16

3 State of The Art 17

3.1 Drama Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Optimization-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2 Planning-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.3 Alternate and Adaptive . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Authoring Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 StoryTec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.2 Prism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.3 Scenejo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.4 Inscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.5 Storytron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.6 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Strategy 25

4.1 Sub-Problems definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Story Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Scene Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.2 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.3 Multiple Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.4 Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.5 Elements Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.6 Final Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Authoring Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Complications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.2 Past Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 View Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5 Prototype Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ii

5 Implementation 35

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3.1 Domain Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3.2 View Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 User Tests 41

6.1 Tests Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Tests Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3 Tests Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3.1 Authoring Requirements . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3.2 Systems tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.3.2.1 Characters/Props/Locations . . . . . . . . . . . . . . . . . 44

6.3.2.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.2.3 Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.2.4 Time and Branching . . . . . . . . . . . . . . . . . . . . . 45

6.3.2.5 Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3.3 Other data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Conclusions and Future Work 49

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A Test Script 57

B Users Survey 61

C Other Implementations 69

D Test Full Results 71

iii

List of figures

2.1 Example of a Branching Trees Strategy . . . . . . . . . . . . . . . . . . . . 7

2.2 Example of a Foldback Strategy . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Example of a Constipated Strategy . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Little Red Riding Hood as an Interactive Storytelling approach . . . . . . . 9

2.5 The Big Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Storytec architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Example of the Scenejo Interface . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Storytron application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Current Scene screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Time as a Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 The Baboon with the Golden Gun . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Monkey Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Story Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.6 Our Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 StoryColla Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Selection of one state within the Locations . . . . . . . . . . . . . . . . . . 37

5.3 Scene Order Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Patu in StoryColla and correspondent XML code . . . . . . . . . . . . . . 38

5.5 Logical Diagram of all Managers . . . . . . . . . . . . . . . . . . . . . . . . 39

v

List of tables

3.1 StoryTec Component Table . . . . . . . . . . . . . . . . . . . . . . . . . . 21

vii

1IntroductionThe underlying goal of all our research is to be “really cool”

John E. Laird [1]

1.1 Motivation and Problem

Given its enormous potential, Interactive Storytelling(IS for short) has been the sub-ject of many academic research in recent time. It takes place between the user and thecomputer and it is precisely that symbiotic relationship, that is built by both, that makesIS so interesting and with so much potential. Whether it is books [2], films [3] or games [4],the connection that is established and the way IS changes the potential of the mediumare all exciting and extremely promising.

When examining in greater detail this area a question presented itself:“Why don’twe see this type of stories more often?” that’s when the Authoring Challenge in IS [5]became apparent. The main limitation found nowadays in the general acceptance ofthis kind of stories has been not in the technological department but more in the wayof how we create this type of stories. In order to solve this problem it was decidedto try and use the benefits and advantages of shifting the creation process from a oneauthor situation to a group. However, some questions arose “How do people tell/createstories in a group/collaboratively?”, “Can we use that mechanism and apply it to IS?”among others. In an attempt to find an answer to these questions we explored existingactivities that already used the group element as an advantage rather than an hindrance.It was during that research that it became noticeable some pen-and-paper RPGs(Role-Playing-Games) where several parallelisms can be drawn with IS (the existence of a GameManager/ Drama Manager is a good example of that). and inclusively some of this RPGsalready have the objective of creating a story collaboratively; for the purpose of this workwe focused mainly on Universalis [6].

Although Universalis was a good starting point, there were some issues related tothe scope of our work. First of all, Universalis is not intended to be used in the contextof Interactive Storytelling, it was only used to create a linear story collaboratively andtherefore could not be used right out-of-the-box ; Secondly, it had some problems directlyrelated to the fact that it was pen-and-paper based, since we are converting it to a digitalformat it would be foolish to not take advantage of that particular detail; And lastly,

2 CHAPTER 1. INTRODUCTION

Universalis was not intended to be used as an authoring tool which meant it was notnecessary for it to comply to authoring requirements previously identified in this field.

1.2 Proposed Objectives

Taking into account all the aspects mentioned in the previous section what we pro-posed to do was create a computer system based on the concept of Universalis capableof not only creating stories collaboratively but Interactive ones as well. In addition, thesystem should also be able to support all types of stories and maintain the delicate balancebetween the authors, preventing a user from monopolizing the entire creation process. Inan attempt to tackle another problem of Authoring in IS it was also decided to try andmake the system not dependent of previous programming experience.

1.3 Contributions

As a product of this work we have created and validated a possible story representationfor IS as well as a method (complying with 5 of the 6 authoring requirements) capableof being used in a group situation able to create from scratch an Interactive Story insaid representation. User tests seem to indicate StoryColla(the prototype’s name) doesnot require previous programming knowledge, one of the great problems found in ISAuthoring.

Since we hope this work will help foster the investigation in this field, some recom-mendations are also made for anyone attempting to take the same route when it comesto authoring for IS.

1.4 Structure

The following paper is organised as follows: it starts by analysing the main conceptsand definitions related to IS and Authoring as well as mentioning some of the history ofthe field. As a foundation for the work forged some exploratory study was made in thefield of RPG in order to ascertain some details in the creation of stories. In the nextsection we carefully analyse the work done so far in the field, again with the focus set onIS and authoring mechanics to better understand what exists in the area and how theyapproached some of the problems that were attempted to be solved in this work.

In order to more methodically accomplish the objectives we set ourselves to, sub-problems were identified and strategies developed to deal with them individually. Theproblems and methods encountered are described in Chapter 4, in this section we alsodefine the structure of our tool and the reasons behind it. In the following Chapter(number 5) we talk about the tools used as well as the architecture of StoryColla and

1.4. STRUCTURE 3

the reasons behind it. After that the user tests are described, the results analysed andcompared to the expectations. Lastly the conclusions gained from this project and possibleenhancements are described.

4 CHAPTER 1. INTRODUCTION

2ConceptsNarrative is the primary form through which we understand and give meaning to our experience

Donald Polkinghorne [7]

During the course of this chapter we will be explaining several concepts and notionsalready present on today’s investigation regarding this subject as it was the basis for thework done.

2.1 Interactive Storytelling

Most of us can remember being told stories when we were young. It may sound strangebut that simple activity has been around since the dawn of mankind. Although primarilyused for knowledge-passing and lesson-teaching, we all know about Little Red Riding Hood[8] along with the message it encompasses, nowadays its role in society has expanded farbeyond its initial scope and has since fixated itself in the field of entertainment, whetherwe are talking about books, games or even movies. Returning to our example about LittleRed Riding Hood being told to a child, it was not rare that along the story sometimes it wasasked “What if...”, representing the decision to take the story into a different course, otherthan the one which was supposed and predicted by the author. This action represents anevoluting point: Storytelling was now interactive.

The person who is being told the story actively takes a part on it’s progression byadding an extra element of enjoyability, however we need to take into account that toomuch freedom is capable of denting the immersion [9]. If there’s no lesson to be learned or ifthe story is too disconnected to make any sense, the person will only experience unrelatedsituations that fail to transmit the emotion and state of spirit desired by the story’sauthor. It therefore falls to the person who is telling the story to somehow circumventthis situation.

2.1.1 Definition

Let’s start by answering an important question: What is Interactive Storytelling?.Although it is used for some time now and some definitions did pop up, the truth is itwas not until 2004 the what is now the accepted definition came to be. Crawford [10]

6 CHAPTER 2. CONCEPTS

defined Interactive Storytelling as a form of digital entertainment in which the user takesthe part of a lead character in a narrative experience. This mean the user “incarnates” acertain character in a fictional world being given the power to take the decisions inherentto the character. This means, for instance, in Star Wars1 it’s up to the user to decide ifLuke should finish his Jedi training in Dagobah to save the Universe or head to the CloudCity to save his friends.

2.1.2 Origins

Interactive Storytelling is first hinted by Bates [11] when he states the need for a storycreation which acts and develops “in the presence of the free-willed and active user”. Heeven mentions the need for an entity of Interactive Drama to keep things in the righttrack. In fact, this idea of having “something”, nowadays called a Drama Manager (DMfor short), controlling the development of the plot is used by almost all the InteractiveStorytelling solutions in existence and has spawned a considerable number of proposedsolutions for this sole purpose.

2.1.3 Strategies

In this section we are going to analyse some of the most common types of strategiesused in IS.

2.1.3.1 Branching Trees

The first efforts on trying to implement an IS system used this as the initial strategy.It consists on predicting what types of choices the player will want to take and organizethe entire story around them [12], creating a state for each choice and making the playernavigate through those same states. This type of strategy has been used several times,inclusive in fields other than electronic entertainment like the book series Goosebumps[13] where the reader would choose from a number of alternatives for the main characterto opt for. If you take a look at figure 2.1, you will notice that the story always startsfrom the same point and each choice made originates a new level. This obviously hasdrawbacks, as the amount of work involved increases exponentially. Let’s suppose thatthe player is only offered 2 choices at each level. With 10 levels, the author will have tocreate 210 = 1024 different states. Add to that the amount of players that only play oncethrough a story-based game and it becomes clear that the work involved does not pay off.That’s why Foldback Schemes appeared.

1Star Wars Episode V: The Empire Strikes Back, Lucasfilm, 1980

2.1. INTERACTIVE STORYTELLING 7

Figure 2.1: Example of a Branching Trees Strategy

Figure 2.2: Example of a Foldback Strategy

2.1.3.2 Foldback Schemes

Foldback Schemes are very similar to the branching trees with one main difference.Instead of each choice generating a completely different state, there are key points wherethe story must pass and although some liberty is given to the player, those points arealways present in the story [14]. A good example of this is the Diablo2 series, in which theplayer is given the chance to explore and roam however he sees fit. However, if he is toadvance through the story there are certain key events that must be triggered in order tomake it possible, resulting in an experience very similar to that represented in the figure2.2.

2Diablo, Blizzard Entertainment, 1997


Figure 2.3: Example of a Constipated Strategy

2.1.3.3 Constipated Trees

This is not exactly a strategy to achieve IS but a way to trick the user into thinkinghe has contributed to the story. In this type of scheme we are presented with a portion ofthe story and are required to complete a task before accessing the next part [10]. This isnot IS since the user has no influence whatsoever on the story. The most classic exampleof this is the Max Payne3 series where the player goes through a linear story defeatingenemies before being given access to the next event of the story. An example of thissystem in figure 2.3.

2.1.4 Authoring

As mentioned on the previous sections, authoring arises several problems and currentlypresents itself as being one of the major problems to Interactive Storytelling. Not onlythe process to create an interactive story is extremely different than creating a linearstory in the lines of Little Red Riding Hood, i.e. instead of a linear story the author mustimagine a virtual place where the story can exist instead of a linear set of actions [15].The creator must also imagine the setting where the action is going to take place. Forexample in figure 2.4, the author must create the town where Little Red Riding Hood isgiven the chance to go. For last, after analysing each type of these systems to control theDrama it becomes clear that to achieve IS the story must be put in terms that the DMmust understand. This however, is not very straightforward for writers whose main focus

3Max Payne, Remedy Entertainment, 2001

2.1. INTERACTIVE STORYTELLING 9

Figure 2.4: Little Red Riding Hood as an Interactive Storytelling approach

is centred through characters’ dialogue. This arises from the very simple fact that, themajority of authoring systems are created for already existing IS architectures and usuallythey derive themselves from debugging tools for those same architectures, as observed in[16].

A good example for this situation exists in probably the de facto IS system untiltoday [10], Façade. Mateas (author of Façade [17]) states that their tools for authoringare not “end-user authoring solutions” mainly because “even expert programmers familiarwith language such as C++ and Java will have to learn new ways of thinking aboutprogramming to program in ABL” [18]. This means the focus of the authoring does notgo towards the story but to the compliance of the story with the rules of the technologyused, which is described by Murray[19] as the author being half-hacker, half-bard.

2.1.4.1 Authoring Requirements

Authoring for IS is extremely different than authoring for classic Storytelling. Time-lines, relationships, the Drama Manager permitted actions and required representationall become necessary in an IS system. That’s why some work has been done to properlyidentify the requirements for a generic authoring system in IS.

McNaughton [20], who used Generative Design Patterns (GDP) to create stories,described the problems identified as being:

• Generality

• Performance

• Coverage

• Evolution

Generality, the pattern must cover every possible solution, performance due to thehigh abstraction level imposed the generated code is generally not very optimized, coverage


to reduce the learning difficulty it must have a very wide selection of GDP, evolution ifthe story changes with time the system must allow for the patterns and code to evolvewith it.

Magerko went farther with his Scribe [21] system, in which he identified six crucialpoints that every authoring tool must adhere to. Generality, the system must be generalenough not to limit the creativity of the author, it must not focus itself solely on adetermined environment or story setting, opposed to what happens with most authoringtools available for the general public, as is the case of [22]. Debugging, due to the complexnature of IS, it’s typical for the tool to offer some sort of debugging or else the entireauthoring becomes chaotic and at some times it could become random as the author hasno idea if what he is creating works or not. Usability, is a sub-area of Human-ComputerInteraction (HCI) study [23] [24] in a field of expertise far greater than IS, this requirementstates that a program must be easy to use and learn. Environment Representation denotesthe space where the action is taking place, the physical location with its entire set of rulesand limitations. Pacing and Timing are a concern in linear storytelling and in IS theygain a new dimension, since actions and events may be preceded by other. Pacing andTiming are a very important part of IS [25] and must be dealt with specifically. Scope is thenecessary authoring for the story: character behaviour, dialogue scripts, world restrictions,etc. must be supported by the application. We will use Magerko’s requirements for theremainder of this paper.

2.2 Group Authoring

Group Authoring has been a subject of much research in Computer Science. The needfor people to work and collaborate together made Group Authoring a necessity insteadof simply an academic research field. Group Authoring has its roots set in collaborativework or collaboration. It was Terveen [26] who coined the definition:“Collaboration is aprocess in which two or more agents work together to achieve shared goals”. In many casesthis approach proves not only to be better suited for the task at hand, but also proves tobe a necessity.

With that in mind, it comes as no surprise that some work has been made regardingthis issue in many fields of Computer Science for instance [27]. If we focus ourselves onstorytelling we find a few examples where group authoring was used. Santoro [28] andValle [29] both used Group Storytelling to extract the knowledge from all the stakeholdersinvolved in the decision process so that in the future, that same knowledge could beaccessed and used to improve their processes. However, its focus is not on content creation,but only on the acquisition of the author’s knowledge. On the other side of the spectrewe have Collaborative Storytelling, which is essentially the employment of the notion ofcollaboration to create a story, in which two or more agents work to achieve a part ofa story. The research done regarding this subject [30] allowed for some concepts to becreated: information sharing, knowledge of group, individual activity and coordination.Information sharing is the way the group communicates, the better the communicationthe better the information flows. Knowledge of group, as the name says, is the knowledge

2.3. COLLABORATIVE STORYTELLING 11

possessed by the group as a whole: the state of the system, what is required to achievethe goal, etc. are information that the users need. Individual Activity is the way eachperson acts within the group, the tasks it performs which may influence directly the workof its colleagues. With this, there is also a necessity that the users organize themselves sothat there are no repeated tasks, precedent tasks are executed earlier than the ones thatdepend on them, etc. all this amounts to the need for coordination amongst the users.

At the moment of the conception of this document no significant work has been maderegarding Interactive Storytelling, which raises the question Is group authoring importantfor IS? From our perspective yes. The most important factors that IS possesses are thatit responds to the player, and that the amount of “freedom” and choices the player isgiven are defined by the author [10]. The author decides if in his story it makes senseto give the player the ability to make that decision, so it is of no surprise then that thechoices presented will be limited by the author’s own tastes. If the author prefers to focusitself on being the good guy, he will inadvertently present better choices and paths for thegood guy route and when it comes to being a bad guy the choices are more likely to seemlacklustre and poor. With several people working together, each with different tastes andideas, more choices can be considered increasing the span of the story and its speed ofconception.

2.3 Collaborative Storytelling

A specific subset of Group Authoring is the so-called Collaborative, in this methoda group of users gather to produce a story as one. Like in Group authoring this methodrelies in the group as a whole to keep the quality of the story as high as possible, howeverthere is a fundamental difference between both: While in Group Authoring the objectiveis to create a story to be experienced by other users, in Collaborative Storytelling theexperience of creating the story is the main goal.

While in Group Authoring each user creates a different part of the story with a certaindegree of autonomy, in Collaborative Storytelling all users are engaged in the same taskat all times which creates a certain redundancy which, in theory, makes the same tasktake longer to be completed.

It should be noted that the work made in this area usually relies on tangible objectsto create the story. Some projects regarding collaborative or group storytelling haveappeared, such as Zuzie [31], PuzzleTale [32], KidPad [33] and StoryMat [34] who useboth tangible objects and the combination between them to create a story. It should benoted that authoring requirements like Generality are not supported since the story ishighly dependent on the items used and the meaning attributed to them, with very fewworks done without that limitation.


Figure 2.5: The Big Model

2.4 RPG

Role-Playing games are a genre of game that usually involve a story where the playertakes part as a character or group and the action/story is usually controlled by a GM(Game Master). As it’s noticeable there are many similarities between IS and RPGs,one may even argue that in its purest form RPGs are interactive stories with the GMadapting the game to better suit the players needs. Therefore, it comes as no surprisethat by analysing some of the concepts and techniques used to improve RPGs we mayget ideas and notions that can be used to similarly improve IS.

2.4.1 Theory

To better understand the mechanics of Authoring work, it’s interesting to see howsomething called the RPG Theory works. The RPG Theory intends to define the methodsused for a GM (an author) when creating ’pen-and-paper’ RPG games to improve on themhaving as basis the characteristics of the type of players participating in the game. Thefirst attempt at this produced the so called Threefold Model [35], which identifies threecritical aspects of RPGs: Game, Drama and Simulation. It then states that the GMcan focus only on one without hindering the others. This definition heated up a lot ofdiscussions at the topic, and although some things could be accepted within it, manycritics mentioned that a good GM should be able to balance between the various aspectsand create a game that would appeal to more than one type of user.

As a result a new model was proposed, GNS (Game, Narrative, Simulation) [36] firstproposed by Edwards in his website The Forge4. It borrows the core concepts from theThreefold Model, and in fact it’s almost the same in the sense that it also only focuseson one type of player. The main difference is that it elaborates further on the notionof conflicts and how the players act upon, when taking a decision for a character. Thismodel was later discarded by the author when he came up with The Big Model [37].

The Big Model attempts to structure the elements of the game experience into anhierarchy, as seen in figure 2.5, and identifies four important components to each Role-Playing session. Social Contract, the way the players interact between themselves will,with no doubt, interfere with every decision. For instance if you do not like anotherplayer, you will most likely tend to disagree with his suggestions while on the other handyou are more propitious to agree with someone you consider a friend. Exploration, as

4http://www.indie-rpgs.com

2.4. RPG 13

the name suggests is the way you explore the game contents (places, characters, events,etc.). In essence Exploration is the act of Role-Playing. Techniques is the way playersact: how they explore and what mechanisms they use to decide a challenge. Ephemera isthe exact happenings during the game, for example, the precise words that players say orthe characteristic of every monster they face. The Creative Agenda, which relates directlyto the GNS model, is what the players hope to achieve during the play-through and isdepicted as being an arrow going through all the aspects mentioned since it involves allprevious aspects.

After our analysis what can we conclude about the RPG Theory? The most importantthing to retain is that no matter the theory proposed, each person has different approachesto a Role-Playing Game and without proper care, these same differences can destroy theexperience for everyone, a notion that must also be applied to the Authoring act.

2.4.2 GM-Based

When talking about classic ’pen-and-paper’ RPGs it’s normal to imagine a group ofadventurers going through a plot created by a GM. The job of the GM is to adapt thestory and the circumstances throughout the development of the story, giving emphasis onwhatever the group is more inclined to appreciate. This type of RPG is highly dependanton the GM. A weak GM will make for a weak experience for the entire group. Dungeons& Dragons [38] and Vampire: The Masquerade [39] are some notable examples of thistype of game.

2.4.3 Collaborative

To overcome the dependence of a GM, some collaborative forms of RPG have comeup. In these schemes the decision and the progress of the story is decided not by a singleperson, but by the group as a whole. Inside the RPG Theory, usually this type of gamesappeal more to players who prefer a narrative approach to a game. In relation to thework being discussed in this document we must mention Universalis[6].

2.4.4 Universalis

As mentioned above Universalis fits extremely well in the scope of this paper, solet’s start by first giving an answer to the question of “what is Universalis?” Mazza andHolmes (the creators) answer by:

• The game where every player is a Game Master

• The game where players can create and populate the world as they desire - as theyplay!


• The game where everything that happens happens because a player wanted it tohappen

• The game where suspense comes from the actions of a player, not from a randomroll

• The game whose plot evolves as you play with no random tables, no rail-roading orscenario books

• The game which requires absolutely no set up or preparation time

• The game where it does not matter if all the players show up on time

As it is clearly seen this is extremely vague in order to explain what is Universalis.It’s precisely this vagueness, this generality that demonstrates why this game was chosen.More than a game, this is a framework, a method for creating quality and interestingstories in a group environment with no restriction regarding the subject, the environment,the characters or anything for that matter.

2.4.4.1 Currency

As it was previously stated Universalis is a Collaborative Storytelling RPG where theobjective is not to win but to create a story. One of the very interesting aspects of thisgame is that in order to maintain balance between the amount of influence each playercan exert in the story it effectively creates an objective and quantitative method to do so.Each player gets assigned an X number of coins in each turn and these coins representwhat the player who possesses them can do. Every action in Universalis to be considereda “fact”, something that for the effects of story really happened, needs at least a coin tobe spent in it. For example:

In this sentence the player who is dictating it has to spend at least 3 coins. One tointroduce the character with the role “cadet of the Monkey Ninja army”, one to give ita name, and other for the location of BananaSplit. If no coin is spent that event is notconsidered a fact but instead a color, something which adds something but does not havethe importance of a fact.

2.4. RPG 15

2.4.4.2 Setting the Story

Now that we have said what Universalis is, and how its currency works let’s describehow a session usually starts. To prevent the story to be extremely fragmented and tocreate a similar goal to all authors, a session begins by defining certain guidelines that willaccompany the players throughout the creation of the story, respectively Story Elements,Social Contracts and Rules Gimmicks.

Story Elements regards the subject, the theme which the story will be based on, aSci-Fi romance, a Dark Ages thriller or a Fantasy adventure this types of decisions mustbe made prior to the beginning of the narration otherwise the story becomes extremelydisconnected and every player will try to pull the story in a different direction. SocialContracts relates to the rules that exist within a certain group. Essentially a SocialContract could be the initial order, any exception that should be made, forbidding real-world events, etc. Rules Gimmick are rules created to deal with specific situations orplayer concerns.

2.4.4.3 Story Components

In Universalis each component of the story whether it is a character, an object (withinthe Universalis universe this is called a Prop) or a location must be described and de-fined. Each story element is defined by the following characteristics: Role, Attributes,Possessions and Name. Let’s return to our example to see how these are applied:

In this excerpt we have exactly one character, one prop and one location. Let’s lookat them closer:

• The character has the name Patu, the role is Ninja, during this scene it gains theattribute stealth and possesses a pair on Nunchucks

• Nunchucks is a prop, it does not have a name, its role is Nunchucks, it does nothave any possession and has the attribute “Made of whipped cream cans”

• BananaSplit is the name of the location, in terms of attributes it only has “Groundcovered by banana peels”. Since it is a location it has no role

It is important to note that for every change in any of this aspects related to a StoryElement it is necessary to spend coins in order to declare them as facts. For example ifPatu was to loose its Nunchucks it would be necessary to spend an amount of coins equalto the importance of the Nunchucks to remove them as a Possession.


2.4.4.4 Creation

When creating a new Story Element the first thing we should define varies accordingto the type of Story Element, if it is a location the first thing we stablish is its name,otherwise the first thing we define is the elements’ role. It should be noted that althoughpossible it is not necessary to give a name to neither a character nor a prop, for instanceif Patu was to fight an enemy soldier, it is not necessary to define that soldier’s name.It can simply be identified by its role. As it has been stated the creation of an elementrequires the spending of coins in order to be definitive.

2.4.4.5 Scenes

Each story in a session of Universalis is divided into Scenes. Each scene is character-ized primarily by:

• Time - the when

• Place - the where

• Events - the what

Each scene also contains actors, elements which interact within the scene and are thetargets(Characters or Props) of the events that occur. With all these aspects combinedtogether we are able to create an entire Scene with its own story, set on its own timewhich happens in its own place.

Prior to creating a Scene it must be decided who gets to define the inherent aspectsof the Scene mentioned in the previous paragraph. To do so each player makes a secretbid and whoever wins it takes control of the scene and is given the power to alter thescene, it should be mentioned that the player who wins the bid must spend, at least, thecoins he used in the secret bid phase.

2.4.4.6 Fines and Complications

In order to maintain the rules of the game, it is possible to penalize each player ina number of coins every time they break a rule, for instance, if it is defined in a SocialContract that no references to Transformers can be made. If a player breaks this rule hecan/should be punished.

It is normal to exist diverging opinions regarding the course the story should followthat is why at any moment it is possible for any player to challenge the person whocurrently has control of the scene and take its place as the narrator of the story. In thiscase it is created a d10 dice pool where every player sides with one of the opposing partiesor remains neutral. After that the dice are thrown and the party with the larger amountof successes wins (a success is a roll between 0-4).

3State of The ArtEmergence is not magic

Chris Crawford [10]

In the next section we are going to analyse several existing systems of the areaspresented in the previous chapter. We start by analysing existing Drama Managers,highlighting similarities and differences between them, while providing a critical analysisof the system. Afterwards we analyse systems created with the purpose of addressing theauthoring problem, again taking a critical approach in order to improve them.

3.1 Drama Managers

Stories are all about passing knowledge and/or information. In an Interactive Story,that knowledge is passed through the interaction with the world, whether it is by witness-ing an event, talking to a Non-Player Character (NPC), etc. Under these assumptionsit is normal to think “why don’t we delegate the responsibility of creating the story to theNPCs?”.

Well, the fact is that although NPCs do have interference with the story in the sensethat they influence the choices and actions of the player, they do not share a common’mind’ and therefore lack the ability to direct the story in the path intended by theauthor. Let’s consider the following situation, the author starts by creating a story thatis intended to transmit back to the player the notion that evil deeds don’t go unpunished.Let’s also consider that we have only two characters, one good, one bad. Every timethe bad character makes a move that is considered incorrect, the good character mightpunish him. Now instead of two characters, let’s suppose we have 150. How do they syncthemselves to show that message to the player? Is the player close to the NPCs whenthat lesson is transmitted? Is the message diminished by some ’non-sense’ the charactermay be attempting to do? Since they are autonomous how can we make sure that the bigpicture depicts what is intended instead of some deviating behaviour from them? Workregarding these questions is still being explored [40] [41] [42] and is still one of the HotTopics in IS.

Given the free spirit of the characters, we can actually have too much freedom, whichcould translate itself into a failed narrative and an even worse experience. The truth

18 CHAPTER 3. STATE OF THE ART

is that without a central mechanism guiding the “Drama”, we are unable to ensure thesoundness and message of the story. This ’central mechanism’ notion relates directly tothe Director described by Laurel[43] and Bates, something to “Dot the i’s and cross thet’s” and keep things going smoothly for both the author and the player. There has beena lot of work done regarding this issue, with several solutions proposed and tested.

3.1.1 Optimization-Based

Optimization-based Drama Managers were the first ones to appear, proposed by Batesin his seminal paper [11]. This model is heavily based in Machine Learning methods. Byusing an evaluation function, the DM analyses the possibles paths taken by the playerand calculates the best trajectory, i.e. the path it sees as being the most suited one.Several implementations of this type of solution have been studied so far, being that thefirst one, known as Search-based Drama Management, is introduced by Bates and laterexpanded by Weyhrauch [44]. It operates by creating a Directed Acyclic Graph (DAG),with the link between nodes representing a temporal limitation(i.e. the nodes that areexpanded first must occur first), which is used to search through the best possible pathto our objective. This concept is very simple and it comes to no surprise that it wasthe first one to appear, as it provides a way for the DM to guide the plot to a desiredstate. However, it is not free of limitations. Since we are performing a search, timedelays are to be expected, another point is that the author content must be converted tonodes and attributed a value for the evaluation function to use. Another problem presentat this time was the re-playability value. Since the author gave a fixed value for eachnode, each time the search algorithm would perform, it would always return the samevalue, making the experience repetitive. To address the replayability problem Nelsoncreated a Declarative Optimization-Based Drama [45] which added a stochastic elementand attempted to maximize not the transition for the next level but the value for theentirety of the ’journey’.

3.1.2 Planning-Based

This type of Drama Managers sets its base upon the roots of AI planning techniquesat different levels of abstraction. Each DM that follows this type of architecture createsa plan to guide the player to achieve its goal. The Interactive Drama Architecture [46](IDA) receives certain key points and creates a plan and pre-conditions that must be kept.Let’s suppose the user requires the help from a NPC to rob a bank later in the game. Anyattempt to eliminate that NPC before he accomplishes his task will result in any numberof “impredictabilities” that prevent such event from happening. Of course this type ofsolution does not go unnoticed by the player which proves to be a major setback. On theother hand Mimesis [47], another example of a Planning-based DM, does not attempt topredict the behaviour of the player. Instead it protects itself solely of the actions that aretaken by the player, which again proves to be extremely intrusive for the person using thesystem, since it suffers from the same limitation that IDA.

3.1. DRAMA MANAGERS 19

Figure 3.1: Façade

A different type of Planning-based Drama Manager is, for instance, Automated StoryDirector [48]. This architecture sets its premises completely opposite to the before men-tioned systems. Instead of focusing the attention on the player, it calculates every possibleway the plan can be ruined and creates contingency plans for it. However, since the contin-gency plans are all pre-calculated, they don’t take into account the profile and specificitiesof the player.

3.1.3 Alternate and Adaptive

Although planning and optimization systems were the first ones to appear, most of theresearch nowadays is made in the direction of alternate methods of drama management.In the case of U-Director [49], instead of using traditional planning, the authors use aDynamic Decision Network (DDN), which according to them, continually selects Story-World actions to maximize narrative utility on an ongoing basis. That is achieved byusing DDN and, at each cycle, update its beliefs of the world and of the user.

To this day the type of architecture that has proved the best results in producingan IS story is the Beat-based one, for which Façade [17] is a good example. A beatstory is composed of three aspects: global plot arc, scenes and beats. In this architecturethe narrative is the result of a series of values applied to properties or relationships (i.e.friendship, hate, boredom) with a beat being the smallest possible variation of those valuesand a scene a story element with preconditions to be satisfied. It’s the job of the DM tochoose the scenes which have the preconditions met and continuously update the state ofthe world using the beats to steer the story through a global plot arc.

As noted on the RPG Theory section, people have different interests when playing agame. Up until now none of the systems mentioned attempts to adapt itself to the player,they only respond to the player’s interactions with the world. Some systems however,attempt to mold to the player in question, by keeping a representation of the existingplayer models and comparing them to the model of the current player. Systems like


Figure 3.2: Storytec architecture

PaSSAGE [50] and C-DraGer [51] attempt to predict which course the story should taketo maximize the experience of that particular user according to its own tastes.

3.2 Authoring Systems

Authoring has been a major problem for IS. In this section we analyse existing systemsthat tackle the authoring problem in IS.

3.2.1 StoryTec

StoryTec [52] is a system whose main purpose is to allow the authoring and creationof IS systems for the end-user. It does so by assuming that IS is extremely complex forjust one tool to create and maintain, and therefore uses a system architecture based onplugged components.

Each of the components is responsible for a part of the story we are creating. Theseare partitioned into 5 elements: Story Editor, Stage Editor, Action Set Editor, PropertyEditor and Asset Manager which are all described on table 3.1. This idea to separatecomponents proves to be well thought as the user can better focus on the action hewants to perform. However, this requires the author to learn how to use each componentseparately as well as how to make them work together, a problem often associated withauthoring tools which adopt the same premise.

3.2.2 Prism

The Prism [53] implements a novel concept regarding IS. Instead of aiming towardsa single model, it combines branching graphs and AI planning into a hybrid solution.The Prism framework divides itself in two categories: the Writer and the Player. Theformer behaves like an authoring tool, while the latter provides the essential feedbackvisualisation of what has been done. After the author finishes inserting the narrative intothe Prism Writer it is then converted to an XML format, referenced by the authors as

3.2. AUTHORING SYSTEMS 21

Component FunctionStory Editor responsible for taking care of the story and

Managing what the author considers to bescenes

Stage Editor Acts like a Level Editor in the sense that itdeals with locations, the where in which thestory is going to happen

Action Set Editor Defines the story logic and actionsProperty Editor Editing propertiesAsset Manager Importing assets

Table 3.1: StoryTec Component Table

a Prism Container, which can then be passed to the Prism Player. The way the storyinput is passed to the writer can be done through three methods: text, mouse pointersand voice.

This type of solution grants an extra dimension to the Interactive Storytelling domain.Instead of simply defining what we want to obtain and filling it with a lot of “stuffing” soit seems better than it is, we can use the Writer to define the general terms of the storywe want to transmit to the player and then “grant” a personality to every character ofthe game, so the feedback and reactions the player gets don’t sound too limited.

3.2.3 Scenejo

Scenejo [54] is an authoring tool whose only focus is the interaction between charactersand the user/player. To achieve such goal the creators set three requirements: authoringwithout programming, emergence, and visualisation. The first part is semi-accomplished,as the author does not necessarily have to program but it still needs to have notions outsideof Storytelling, and if he decides to hardcode a dialogue he will still need to program it [55]and state the character’s traits when they are having a conversation. This also contributesfor the author’s notion of emergence, in allowing to define these characteristics to achievesome sort of response from the player. For the author to have a notion of what are thepractical results of his creation, Scenejo also provides a tool in which a conversation issimulated with the character (as shown in Fig. 3.4), where the face of the character seemsto engage in direct dialogue with the user.

3.2.4 Inscape

The Inscape [56] system acknowledges that one of the most important part of storiesis the emotions conveyed, and that’s exactly what they attempt to accomplish with thisarchitecture. By using what they call an emotion wizard, the author is able to specificallydescribe the mood that the present scene must transmit, along with the personality inher-


Figure 3.3: Example of the Scenejo Interface

Figure 3.4: Storytron application

ent to the characters in the scene. That’s precisely where this architecture fails, becauseits focus is solely on emotions and so the story clearly takes the back stand1.

3.2.5 Storytron

Known for being the brain-child of Chris Crawford, Storytron[57] is a web-basedinteractive application, designed solely for storytelling. In terms of traditional gamemechanics they are non-existent, the system is only used to tell stories and the onlyinteraction made is through dialogue. Although it does not concern itself with traditionalmechanics and only focuses on Storytelling the truth is it still does not fully solve theauthoring problem. SWAT, the application used to create stories for Storytron, still doesnot fully accomplish the time requisite and proves itself to be extremely confusing for anon-programmer author to get started.

1It should be noted that Inscape is an ongoing project still in the beta phase which means theseproblems may not exist in future versions, http://www.inscapers.com/

3.2. AUTHORING SYSTEMS 23

3.2.6 Concluding Remarks

All these authoring tools have been developed to extend the functionality of an alreadyexisting framework or one that’s developed simultaneously with the authoring tool. Noneof them attempts to completely separate the authoring process from a determined system.

This ultimately shows that no matter how many solutions have been proposed, ISauthoring tools are still not user-friendly. Prism [53] attempted to solve this problem byusing voice to input data. This would mean we would only be required to tell the storyto the system. However, this fact is minimized when they say the user still needs to usekeyboard and mouse as not all data can be transmitted only through voice. This requiresthat all the authors using this system must have previous knowledge of the limitations ofthe framework and know what and when to use voice for or use the traditional approachinstead. So, the main problem still remains the same: the author is required to have adeep understanding of how the system works, pushing story creation out of the spotlightwhere it should be.

4StrategyA satisfied customer is the best business strategy of all.

Michael LeBoeuf

In the previous chapters we simply described the current state of affairs and thedirection the research has followed until today. In this chapter we are going to address ourapproach to the problem, and build upon the decision that led us to the final architecture.We start by first defining sub-problems that map directly the objectives we proposed insection 1.2; next we describe how we intended to solve each of the sub-problems andlastly we explain how the architecture of our prototype is capable of supporting both themodel and the method created.

4.1 Sub-Problems definition

Romans had a saying: Divide et impera which translates to “Divide and Conquer”,to achieve our goals that’s the strategy we used. Since the problems we are facing arefar too complex and ambitious to just start testing/solving we need to divide them intosmaller ones to be able to see the “big picture” and in that way to delineate a feasiblesolution. The following sub-problems were the ones we considered critical:

1. Define a model capable of representing Interactive stories

2. Define a method to create Interactive stories in a collaborative context

3. Create a prototype capable of creating Interactive stories in the model defined in(1) using the method created in (2), independent from any DM, capable of beingused by authors with no previous programming experience.

In the next sections we are going to be analysing each of this problems individuallyand in greater detail.

26 CHAPTER 4. STRATEGY

4.2 Story Model

Stories have many representations whether it is only text, images or a combination ofboth the truth is mankind has found ways to share them in several ways. However, when itcomes to Interactive Stories, things are different. Although there are some representationsin existence( [58], [59], [60]) they are typically complex and not friendly for users with noexperience in the field. In order to simplify the Story Model we decided to use the storyrepresentation of Universalis. In Universalis, a story is a group of Scenes, as such it isnot strange that we used that as a foundation for our story. Each scene is then composedby: a location, a set of characters, a set of props and a plot (the other aspects consideredlike Social Contracts and Rules Gimmick only regard the method to create the story) interms of a linear story these points are enough to define an entire script as such they weredirectly ported to our solution. However, when the aspect of interaction is brought tothe table, these features, although still necessary, become insufficient. Some adaptationsneeded to be made in order to be able to represent an Interactive story. In the followingsections we are going to mention some of the changes needed to be made and also describeour Story Model in a greater detail.

4.2.1 Scene Description

In literary theory there are two schools of thought regarding the balance between plotand characters. The first was started by Aristoteles in his work Poetics[61], where he putsthe importance on the side of plot since a tragedy “is a representation, not of men, butof action and life”, in this case it is clear that for him the importance should be placednot on characters but on the Events. The other side in this discussion states that theimportance should be entirely placed in the characters [62] since it is through them thatthe events occur and consequently the story develops.

Figure 4.1: Current Scene screen

In Universalis the importance is kept within the plot and that fact is most visible whenwe are discussing the scenes. The Scenes are the foundation, the building blocks, if youwill, of the story. A Scene is characterized by three main aspects: the Location where ithappens, the Time when it happens and what happens in that Scene (the Plot). We do

4.2. STORY MODEL 27

not consider characters and props on the three main aspects because they can be slottedinside the Plot. By following this logic/model we can clearly see that Characters andProps do not exist outside a Scene, they only exist in a moment in time within that scene.That aspect was exploited to our benefit, in our solution each Character/Prop/Locationis tied directly to a Scene and if, for instance, we intend to add an existing Characterto the current Scene we have to select the Scene that character was associated with toadd it, which allowed for some extra functionalities. For example, if there is a need fora flashback we can import a character from the first Scene it appears and continue thestory from there instead of having to alter the most recent state of the character.

4.2.2 Time

“Order is a feature of all narratives” [63], as such our end result will also containwithin itself an order, not just one by that matter but several, since in Interactive Storiesthe order can be permuted. In fact, Prince [64] stated that “ordering of events in timeis one of the most fundamental characteristic of any story”, for our system this meansthat: “When does this scene occur?”, “Does this scene happen before that one?” are allquestions which every user of our application should be capable of easily answering andaltering if need be.

Our first approach was to solve this problem by setting an actual date down to theseconds where a scene would take place. It was done so by using the open-source libraryjCalendar [65], where an actual calendar was presented to us and we would peg the chosenday. After that to better see where the scene would stand temporally all the scenes werepresented in a Gantt chart such as the one in figure 4.2 using the open source librarytimebars [66].

Figure 4.2: Time as a Gantt Chart

It must be noted that Universalis does not allow for this type of sequencing, the timein which each scene occurs is simply defined by a sentence, for instance “forty years ago”,“last night”. Its meaning is entirely semantic. Although in some cases this is enough toprovide a solid time notion to the reader/user when we introduce the concept of IS thischanges drastically. Monfort [63] has done some research regarding how to order scenesin Interactive Fiction, albeit more focused on the tense used, in his work he separatedthe traditional “order” used in narrative into two distinct ones. One order related tothe absolute time, i.e. if the scene takes place at 5 O’clock in the evening, and anotherinto relative time, if scene X occurs prior/at the same time/after than scene Y. In ourprototype, we opted to use this approach: the absolute time was identified the same way


as in Universalis (by a single sentence), and the relative time was addressed by definingparent and child scenes (this is further explained in the next section).

4.2.3 Multiple Paths

As it was highlighted in the previous sections, Universalis is a framework for creatingstories collaboratively. The stories supported (although varied in terms of subject, type,style) are all linear. That is to say, they do not involve choices, they are pre-determinedand the reader (he/she who experiences the story) takes only a passive role, in whichthere is nothing he/she can do to influence the outcome and path taken to reach it. So, inorder for us to overcome this type of problem, the concept of this game had to be slightlychanged, it needed to be possible for the story to take different paths, how those pathswere chosen was not a concern of this project, the focus was only on creating them. Tosucceed in that task we implemented the Foldback Schemes strategy [14].

In our solution it is possible for the user to define what we call parent and childscenes, that is scenes that either precede or follow the scene we are working on in anarrative experienced by the user. That way we can explicitly tell which comes first andwhich comes after and allow for the author full control over the paths he wishes to makeavailable and in what order.

As you can see the previous scene where Patu uses a stealth technique and spiesoriginates two possible outcomes:

Figure 4.3: The Baboon with the Golden Gun

Figure 4.4: Monkey Business

4.2. STORY MODEL 29

To better allow the edition and creation of such paths it was felt that, if provided,the users would like to have some kind of visual feedback in order to better understandthe time of each scene. This reasoning came from the the belief that it was easier to sortscene times visually than through a list of numbers where many mistakes could be madeinadvertently as there was no real-time feedback to the author.

4.2.4 Plot

Current methods used to obtain Interactive Storytelling all rely on the use of the so-called Drama Manager. As it was also stated it was necessary for the DM to know whichactions are supposed to be happening, to facilitate this job and to easily identify whatactions the DM must focus on we have separated from the usual narrative the events, towhich we called Actions. This not only allows for a greater control of what happens on ascene but it clearly establishes a separation between important facts and events that onlycontribute to enrich the scene (what is commonly called color).

Using our example of the Baboon with the Golden Gun:

“Patu is startled. From the shadows an ominous creature appears, the dreaded Sclupsthe Golden Butt Baboon. Its profile is only comparable to a Giant. “What do you wantfrom my Mountain?” he asks. Terrified Patu cannot utter a word and begins a valiantescape attempt.”

In this case there are only 2 Actions:

• The Golden Butt Baboon appears

• Patu flees

Everything else is represented directly on the characters involved or is not representedat all since the author just added the extra words for narrative purposes and they haveno influence outside that spectrum. We believe it is important to separate this conceptsas it forces the authors to focus on what really is important and to not ramble in excess.

4.2.5 Elements Images

During our test sessions of Universalis something became apparent while observing:most of the times, when creating a character, a prop or a location it is normal to draw asketch of the thing we are creating. To enable this feature on the digital version we haveintroduced the concept of image to every Story Component created which can be alteredto one created by the user.


Figure 4.5: Story Model

4.2.6 Final Result

Having considered all the aspects mentioned through here in addition to the aspects wehave from Universalis we can finally come up with a story model capable of representingour Interactive Story:

• A Story is made of one or more Scenes

• Each Element (Location, Character or Prop) has Attributes, Possessions, possiblya Name and an Image

• Each Scene has exactly a Location, a Time and a Plot (which in turn is made ofActions)

• Each Scene can have several Elements and possibly one or more Parent Scenes

Taking into account all these considerations, our Story Model can be seen at Figure4.5.

4.3 Authoring Method

Once we solved the problem of how to represent an interactive story,our focus shiftedto the process regarding the creation of such stories. Our main idea was, similarly to whathappened with the domain, to start from the Universalis method and from there adapt itto fit our needs. In order to keep the Rules separated from the story this module is inde-pendent from the Domain and all the alterations to the Domain must pass first throughhere, furthermore this module is responsible entirely for the author mechanics, i.e. who

4.3. AUTHORING METHOD 31

has control of the scene, how many coins should be refreshed, managing complications.The process in itself remained almost unchanged with the only alterations being the waycomplications develop, and the ability to change past scenes; the main reason not muchhas changed from the original version is due to our tool also being used for collaborativecreation and to be used in turns which makes the process very similar.

4.3.1 Complications

In its original form complications are a crucial part in the mechanisms and balanceof Universalis. However, since we introduced quite a bit of modification to the StoryModel some minor tweaks had to be made. The main issue that existed with our newapproach is the difference in the order of the scenes. In Universalis the order of theScenes is always the same and there are no variations, with our solution each Scene canbe followed/preceded of several other Scenes.

Before if you did not want the story to go a certain way a Complication was theonly way to prevent this. With our model this no longer occurs, if a participant doesnot wishes the story to unfold in the direction it currently is he only needs to takecontrol of the next Scene and create a different path. This considerably reduces the roleComplications previously had. To accommodate for its new functions we slightly adaptedthe mechanism, in the original version a Complication could have several sides with, forinstance, four different players fighting for four different outcomes. In our version weonly allow for two sides to take the “battlefield” since our Complications mechanism onlyserves as a quality assurance mechanism, it is to be used mainly if the story is goingthrough a really bad path.

Our mechanism allows a player to challenge current narrator and enables each remain-ing player to side with whoever they want. Furthermore, in the end of the challengingphase a dice pool is created and the side which scores more successes(a roll between 1-5) wins. The following example illustrates a possible collaborative interaction, with acomplication:

Player A: “Ok, so I won the bid to control the next scene it’s going to be called:Banana Split!...”

Player B: “No more puns after this... please”

Player C: “Yeah!”

Player A: “...it takes place immediately after the Baboon with the Golden Gun andthe scene starts with Patu peeling a banana and throwing the peel at the floor...”

Player B: “Ok... this has officially gone too far I’m challenging you!”

Player A: “But... but... I haven’t even gotten to the part where he...”

Player C: “... slips in the banana? Yeah, we all saw that coming and it is indeedterrible I’m all for Challenging you!”

Player B: “Challenge initiated I’m willing to put 15 coins so this nightmare stops”


Player A: “My idea is not stupid!! I pledge 20 coins”

Player C: “I pledge 15 coins against you!”

...

Player A: “Yeah I won!”

Player B: “Blast!”

Player A: “First things first, let’s start by changing the name of the scene...”

Player B: “My idea was better...”

In this case Player A had control of the scene, and started by defining a title and atime when the scene would take place. The other authors. considering the ideas proposedand used by Player A were not up to acceptable levels, decided to take matters into theirown hands and Player B challenged for control. After all players placed their bid the rolldecided that Player A was the winner and the control of the scene was passed on to him.

4.3.2 Past Scenes

When first testing one of the first versions of our application it was noticed that mostof the times an error had been made or an event would have been forgotten in previousscenes. To account for the need to sometimes change the past we enabled the player toalter past scenes. However, we did not grant him full control to do so. Although anauthor can alter past scenes, he still spends coins to do so and the coins he spends do notcount for the ones he is obliged to spend from the Bidding Phase.

4.4 View Model

The story is in the Domain, the method used are the rules but how all that is pre-sented to the users has not been mentioned yet. In order to better organize our methodsit was important to make the presentation part one which was easily edited to test severalsolutions. To accomplish that it was decided that should be a main module which accord-ing to the information received from the rules module changed the presentation state, ifwe wanted to change the way a method worked or add a different state we simply neededto call it from the rules and it would automatically call what is presented to the user.

4.5 Prototype Architecture

In order to better modulate and operate our system we divided it into three parts:Domain, Rules and View (as shown in Figure 4.6). Heavily based on the MVC [67]software architecture, our model is designed to enable the test of several solutions withease and to completely separate the story from the method used to create/alter it and

4.5. PROTOTYPE ARCHITECTURE 33

Figure 4.6: Our Model

to visualize it. In order to achieve that result we can tackle each of the sub-problemsindividually simply by modifying one of the parts, the story model is contained withinthe Domain and if we wanted to test any different model we simply needed to change theDomain module. If we intend to alter the balance, the order or basically anything wecan do it in the Rules module, again without the need to change the other modules. TheView basically relates to the display and input of the user, if we wanted a box of anothercolor, a bigger image, anything graphical basically the View module is the one in charge.

5Implementation

A good idea is about ten percent and implementation and hard work, and luck is 90 percent.

Guy Kawasaki

5.1 Introduction

As previously mentioned the work developed on the field of Authoring in IS is, al-though blooming, still insufficient for the objectives we propose. The tools used are noteasily available and most important they are almost all dependent of the DM system theywere created for. For this reasons it was necessary for us to literally start from scratch. Itwas then necessary to choose a programming language/ framework on which to programour prototype. The following solutions were considered:

• OpenFrameworks 1

• Processing 2

• Swing 3

To differentiate between them the following characteristics were considered: Proto-typing speed, ease of use, speed, community size/support and aesthetics. All of theseframeworks proved to be up to the task in allowing us to reach our goals. With its baseon C/C++ OpenFrameworks was the fastest of the bunch however in terms of complexityand prototyping speed it was well below its foes. Processing was extremely pleasant inaesthetic terms, however it lacked both in speed and in community support, although ituses Java under the hood the tools it provides to handle heavy text tasks were consideredinsufficient. On the other hand we had Swing that what lacks in speed and aesthetics itcompensates in prototyping speed, ease of use and community size, also if need be, sinceunderneath it was also Java, we could import the Processing Library for specific use.

1http://www.openframeworks.cc/; accessed 15-June-20112http://processing.org/; accessed 15-June-20113http://download.oracle.com/javase/6/docs/technotes/guides/swing/; accessed 15-June-2011

http://www.openframeworks.cc/

http://processing.org/

http://download.oracle.com/javase/6/docs/technotes/guides/swing/

36 CHAPTER 5. IMPLEMENTATION

In the end we opted for using Swing to create our prototype, since the tool-kits andlibraries made available by the massive community it has made the prototyping phaseextremely fast for simple experiments, also its extensibility and platform independenceproved to be up to the task of what we pretended.

5.2 Functionalities

Since the beginning of our work certain functionalities have been added not only tocomplete our goals in this subject but also to facilitate testing and future work. Regardingthe built prototype the most relevant features are:

Save, Load and Import: This functionality was added to simplify testing. Insteadof creating a new story every time we needed to test a newly implemented aspect we couldsimply load our last session and go from there. This greatly reduced the time necessaryto set up a story and also improved the users’ experience by enabling them to pick up astory at a different time and not by making it indispensable for them to create the entirestory in one-go. Since we were using Java, it was rather simple to implement this functionfor Java already allows to save the state of an application using the Serializable interface,we simply needed to implement it.

In order to make it easier to create sequels to previously created stories, the function-ality of importing the assets of previous stories was added. It was done so by reading froma save file and semi-loading, when an author wanted to reuse an asset from a previoussession he simply needed to specify which one and a copy without extra cost would becreated. Although this aspect was not used it was fully implemented and could be usedin future work.

Figure 5.1: StoryColla Menu

Element state: It was important to find a way to differentiate between the sameelements within a time variation, to do so it was overridden the Java clone function andwhenever an element was added to a Scene, it was not the original element but a cloneof it instead. This was needed because objects in Java are passed through reference thatmeans that when added to a Scene it was always a reference to the same object andwhen we changed one of them, it would be changed everywhere that element was beingreferenced.

Scene Order Visualisation: To enable the authors to view their current time-linewe used the JGraph4 lib. This library allowed us visually present to the authors the

4http://www.jgraph.com

http://www.jgraph.com

5.2. FUNCTIONALITIES 37

Figure 5.2: Selection of one state within the Locations

current state of their story. To do so, we performed a Breadth-First Search [68] at allscenes to define what are the precedents of each one and discover at which “generation”it belongs to (i.e. if it has only parents it belongs to the generation 1, if it has at least 1grandfather it belongs to generation 2 and so on). After discovering the “generation” of allscenes they are drawn to the corresponding layer of that generation, with the connectionbetween them being drawn at one last iteration performed after.

Figure 5.3: Scene Order Visualisation

Export to XML As it was noted on Chapter 1.2 the result of our application wassupposed to be used by any DM whatsoever, to make it possible for this to happen weneeded to export our Domain, i.e. the representation of our story. The lib xmlenc5 wasused to export the story to the XML format and make it possible for anyone who wishesto use it. Although this functionality was implemented it was impossible for us to testsince our work was not done parallel to any DM, which resulted in us not having anymeans to test it.

5http://xmlenc.sourceforge.net/; accessed 15-June-2011

http://xmlenc.sourceforge.net/


Figure 5.4: Patu in StoryColla and correspondent XML code

5.3 Structure

The prototype is structured in modules each one responsible for managing certainfunctionalities, to which we called managers. We have three main Managers responsiblefor the main aspects we identified in our architecture (Domain, Rules, View) and wehave several smaller ones responsible for accessing and modifying specific aspects in theDomain. All managers and respective functions are described below:

ViewManager: What the user sees, everything that is displayed is the responsibilityof this Manager. Further explained in Section 5.3.2.

GameManager: Responsible for the process, it acts as an intermediate between theDomain and the visualisation, it is where the rules are enforced and where the validityof the domain is maintained. This manager is also important because it is our “MainManager”, it is where the View Manager and the DomainManager are kept.

DomainManager: Where the story is kept, any change to the story must go throughhere. It is explained in further detail in 5.3.1.

CharacterManager/PropManager/LocationManager: As the name impliesthis module was in charge of creating/modifying characters.

AttributeManager: An inherent component of every Character/Prop/Location isthe attribute, whether it is the role or simply a characteristic it is necessary to keep amanager coordinating the attributes.

SceneManager: This module is responsible for the story per se. The creation/editionof a scene must all be done through this manager.

ImportManager: This manager was added as a result of adding the functionalityto import elements from previously created stories, its only functions are to store theimported elements and provide access to them.

A logical diagram of all Managers and their relationships can be seen in Figure 5.5

5.3. STRUCTURE 39

Figure 5.5: Logical Diagram of all Managers

5.3.1 Domain Manager

This Manager is responsible for keeping the Story coherent and also to serve as a bridgebetween the other Models and the domain. This Manager has several dependent Managersto better control the underlying story such as the Props, Character and Location Manager.By dividing the functionalities through several managers we are able to maintain all ofthem simple and focused only on small tasks.

5.3.2 View Manager

Until now we only talked about the representation of the story and how to accessit, this manager is in charge of other equally important aspect, to show it to the user.By switching between states the ViewManager is capable of showing what we want theusers to see and also where they introduce their input, making the alterations made tothe interface completely separated from the ones made in the domain.

6User TestsFiction is experimentation; when it ceases to be that, it ceases to be fiction.

John Cheever

Throughout this section we will be describing and analysing the tests we used in orderto establish some conclusions regarding our solution. In the first section we will describewhat we intended to achieve and how we planned to do so. The following section will beused to state our results and critically evaluate them. The complete results of our surveycan be seen in Appendix D.

6.1 Tests Objectives

As stated in section 2.1.4, through his Scribe [21] system, Magerko identified thatwhich he considered to be the six authoring requirements every IS authoring tool mustadhere to. Since our final goal is to have a functional collaborative IS authoring programone of our objectives is to comply to the requirement analysis performed by Magerkowhen possible.

Following the validation through Magerko’s requirements we needed to test the differ-ent mechanics introduced to the system. To do so, we focused on three primary aspects:usability, relevance and adequacy. Usability because it was important to see if the user’sexperience was conditioned by a poor UI design or by the conceptualization of the systemitself. Adequacy to understand if the solutions proposed make sense and are comprehen-sible by the users.

After defining what aspects should be tested it was required to define, in terms ofmechanics, what to test. The tests were focused mainly on the new elements introducedin the system and features considered essential to the system; Respectively:

Images In its original incarnation Universalis does not support images, everything isdone purely by text. However, it was noted during its sessions some scribbles weremade in order to better explain characteristics of different characters. Since thiswas added to our model of an Interactive Story further experiments were required.

42 CHAPTER 6. USER TESTS

Characters/Props/Locations An integral part of our story model, they are the build-ing blocks in which our model stands it comes as no surprise that some testing wasnecessary to validate our model.

Scenes Like the previous point the edition and creation of scenes are essential to ourmodel. Continuing our metaphor while Characters/Props and Locations are thebuilding blocks the Scenes present itself as the foundations where the building blocksmust be used and placed accordingly to maintain order and obtain the desired goal.

Time A crucial point in all narratives the when the story takes place. Considering ourapplication is supposed to create Interactive Stories where this aspect is of majorimportance experimental validation was needed regarding our solution.

Branching When contemplating that the way scenes relate to each other changed dras-tically from the original version it was imperative to assess how did the solutionperformed regarding this pivotal change.

Conflicts When talking about collaborative storytelling this item is often of utmostimportance, the way divergent opinions can co-exist and fall to a consensual solutionor not. This procedure must be tested and validated to ensure the approach takenis able to handle such a task.

6.2 Tests Procedures

Subsequently to the definition of what to test came the challenge of how to proceed tosaid test. In order to eliminate to the maximum the possibility of users being unable tocomplete the tasks proposed before taking part in the experiment all users were subjectedto a 20-minute tutorial where it was explained to them how StoryColla worked and themechanisms made available to them. It was known at the time that this would underminethe tests made to the usability of the system but even so this approach was chosen sinceit allowed for a far more exhaustive assay of all other mechanics and aspects. A script ofthe tutorial can be seen at the Appendix A.

After the tutorial and answer to any question pertaining the use of the system thetest itself could begin. The premise of the test was extremely simple, the users wouldbe provided with a session of StoryColla midway and would be asked to create analternative route. Some conditions needed to be met however, namely:

• Two scene limit

• The creation and edition of a character needed to happen

Both the tutorial and the realization of the tests was recorded in order to betteranalyse and infer conclusions regarding the StoryColla prototype. After the completionof the task the users were asked to answer to a quick survey (shown in Appendix B) where

6.3. TESTS RESULTS AND ANALYSIS 43

questions specifically regarding the aspects we intended to test were asked. The questionsmade were of two kinds: the first the surveyed would state how much he agreed withseveral sentences in a scale ranging from one(completely disagrees) to five(completelyagrees); In the second part of the survey, the user would answer to some open-answerquestions.

6.3 Tests Results and Analysis

We conducted the tests with 17 participants, in a total of 5 groups with ages rang-ing from 21 to 31 years old of both genders. In terms of experience, 29% of the usershad previous experience in the field of IS and 23% had neither experience in IS and inprogramming.

6.3.1 Authoring Requirements

In the following section we are going to be analysing how well does our system bodeagainst the Authoring Requirements identified in 2.1.4.1, to do so a succinct descriptionof each requirement is given and the corresponding questions in the survey are referredfollowed by a brief analysis.

Debugging As stated previously any system used in Authoring must be capable of giv-ing feedback to the author to understand what is wrong with the program and toallow the author to correct its mistakes. In order to test this requirement questionsregarding errors and the info displayed in them were asked, like “Were the error mes-sages clear?” and “Did the error messages helped me recover from the problems?”.In the StoryColla system, in average, users rated the clarity of the error messagesin 3,3 (in a 1-5 range) with an average deviation of 0,8. In terms of usefulness ofthat information 52% of the users considered the information to be insufficient toidentify and recover from the errors that caused them.

Usability Usability is the easiness of use of our system, to ascertain the validity of thisrequirement questions regarding the ease of use were asked, some in general andothers pertaining to each specific mechanic tested, some examples are “Is the systemeasy to use?” and “Was it easy to add an image?”. As a whole 94% of the usersconsidered the usability of the entire system at least acceptable and not experiencedamaging. Concerning the users who had no previous programming knowledge allof them considered the prototype usable and found that in no way it damaged theirexperience significantly, although some problems were identified by them; Such asthe extensive need to use the keyboard which all of them with no exception foundexhausting.

Environment Representation As the name of the requirement states, how the envi-ronment is represented is a critical part of authoring in IS. The method we used to


see if this requirement was fulfilled was by asking question regarding the represen-tation of elements and see what the users thought of that, for instance, “Is the wayhow the elements are represented adequate?” and “Is the way of altering elementsadequate?”. This aspect was the one which got better results. When asked aboutthe Prototype strong points 47% of all users considered the representation of theenvironment and characters the aspect that really stood out. In a scale of 1 to 5,the average given by the users to the adequacy of the representation of elementswas 3,94 with an average deviation of 0,54. In light of the results we can considerthat our prototype managed to support this requirement.

Pacing and Timing relate directly with the temporal time where the story takes placeand the narrative time where the story happens, since this was an aspect where wealtered several things questions like “Is the way the time is represented correct?”and “Is it easy to create a branch in the story?” were asked to analyse the fulfilmentof this requirement. We knew beforehand that this would be a tricky requirementto fulfil, specially considering we did not even tackle the pacing problem. But onlyregarding the time the results are not very uplifting 23% of the users considered theway how we represent time inadequate of extremely inadequate with 52% consideringnot negative but still insufficient. However, 88% of the users considered the graphicalfeedback of the precedence of the scenes extremely useful and 52% of them said theywould prefer if said precedence would be done entirely by graphical means.

Scope The scope directly correlates with the dialogues and actions of the Story, in orderto see if StoryColla is able to meet this requirement questions like “Is the waya Scene is organized adequate?” were asked. 70% of the users considered therepresentation of dialogues and overall presentation of the scene content extremelyadequate.

6.3.2 Systems tested

As stated previously several aspects were tested having as base two metrics:

• Usability

• Adequacy

In the following subsections the results regarding each of the aspects tested will bepresented. Full results of the survey can be found at Appendix D.

6.3.2.1 Characters/Props/Locations

It was mentioned earlier that the best results of our prototype were regarding theelements and their composition, in fact when asked what aspect of StoryColla theythought was the best, 47% stated this aspect clearly stood out among the others. Re-garding Usability all users considered the creation of elements to be easy to do giving a

6.3. TESTS RESULTS AND ANALYSIS 45

with all users giving a classification of at least 4 to the statement “It is easy to create anew element”. Regarding the edit of elements the results were similar with 76% of thesurveyed also giving a grade of at least 4 to the statement “It is easy to edit elements”.When it comes to Adequacy the results were identical to the Usability with the usersconsidering the representation of the elements and methods adequate to the task at hand.

6.3.2.2 Images

Contrary to our belief and what our initial test sessions showed, the use of images inthe process of authoring was not seen as beneficial by the users. Clearly demonstrated bynot a single one of them used the functionality. When asked ’why’ most of them (70%)answered that the limitations inherent to our system (i.e. drawing in a computer) did notmade that a viable functionality. Some users (24%) even stated that the “problem” wasthat scribbling is different than using an already finished image and therefore did not findit useful to use images in our approach.

6.3.2.3 Scenes

Regarding Usability the editing of scenes received a generally positive feedback fromusers with an average rating of 4,24 (standard deviation of 0,79) when evaluating theeasiness of adding elements to the scene. When it comes to editing the scene the resultis a little more disappointing with an average rating of 3,82 (standard deviation of 1,12),when asked why the reason for that all groups except one stated that it took too longto insert new text in the plot section of a scene. When it comes to Adequacy 70% ofthe users said the organization of a scene if very adequate for the purpose of creating anInteractive Story.

6.3.2.4 Time and Branching

Regarding time, the results obtained were extremely disappointing. On one hand 88%of the enquiries said it was extremely easy to alter the time of a scene, on the other hand70% of the users said the system used to represent time was inadequate. When it comesto branching the results were more positive with 64% of the users reporting that it waseasy to create an alternative path to the story with an equivalent percentage stating thatthe method to create alternative paths was adequate. It should also be stated that 88% ofthe users reported that the graphical representation of branching was extremely useful tothe creation of the story with 35% of them stating that the branching should be entirelydone using exclusively the graphical representation.


6.3.2.5 Conflicts

Concerning the Conflicts mechanism 88% of the users reported that this type ofmechanism is important for the creation of an Interactive Story and to maintain balance.Of the users that used the Conflict system 78% said it was easy to use. However, only55% said the system was adequate for its purpose a value we think states directly to thenotion some users reported that a system like that should be more flexible and allow fora greater interaction between the participants instead of only bidding one time, a systemlike in Poker where you can raise was said to be preferred.

6.3.3 Other data

Some other data emerged from the analysis of the surveys mainly on the negative side.Although for the most part the usability of the system was not a problem. The truthis 41% of the users complained about the aspect of the program stating that it shouldbe more appealing and not so work-focused. Another problem that came up frequentlywas the lack of feedback regarding the amount of coins each player had, which was notexplicitly stated at all time. It should also be mentioned that in terms of the methodused to create the story 88% of the users considered the method to be valid and theysaid they would use it to create an Interactive Story if the need arose, unfortunately theresults for the use of the application were slightly less positive with only 64% saying theywould use StoryColla to create an Interactive Story. This seems to validate the methodwe used to create the story but identified several problems relating to our application andits inefficiency to properly implement our method of authoring.

6.4 Guidelines

During the course of this work we have encountered several difficulties mainly becausefew research has been done in this area. Since we consider Group Authoring extremelyinteresting to be applied to IS, in this section we leave some guidelines for anyone whowishes to continue the investigation in this area. First of all the work done involvingthe requirements for Interactive Storytelling is extremely useful and all the requirementsshould be kept in mind when trying to design a system of this sort particularly Pacingand Timing. Why that? Well, in our experience the main problem encountered wasexactly when dealing with that. Although the Foldback Schemes strategy works and iscapable of representing an Interactive Story the truth is there are some limitations whichwere not visible because our system was intended to be used by authors with no previousprogramming knowledge. Another factor is the Pacing one, we would like to give moreadvice on this but approaching this situation is still unclear the only thing we know forsure is that you should conceptualize your system to deal with this issue from the startsince it is a crucial point. In fact, it would be helpful to see the Pacing and Timing astwo different Requirements; although similar they must be addressed separately.

6.4. GUIDELINES 47

One aspect that really helped was using the MVC architecture complete independencebetween modules, since it allowed to test more than one solution rapidly, this becameextremely handy when dealing with the Story Model. The MVC architecture also allow fora distribution of the prototype which I really think would benefit a system like this wherethere is such a great bottleneck in the non-paralleled method, but again the conceptionof the system should be made with that in mind from the start.

7Conclusions and FutureWork

If you cry ’forward’, you must without fail make plain in what direction to go.

Anton Chekhov

Authoring in Interactive Storytelling still proves to be a very serious task. We setourselves to create a tool to be used in a group context capable of fulfilling the require-ments already identified for authoring in IS. After the analysis of our results we can onlyclaim a partial victory in this aspect. Although achieving 5 out of 6 requirements is nottoo bad for a first approach to this type of system, the truth is that the non-complianceto all requirements makes this an incomplete tool by itself. Which is not a failure, butobviously could be better.

In terms of method we got some positive feedback and several users said they foundthe method to be appropriate to create Interactive Stories, however our application failedto reproduce that in a positive fashion. Concerning the previous need of programmingknowledge, tests showed that was not a prerequisite to use StoryColla and it did notinfluence in the usage of it by the specific subset of users. However, users with previousprogramming knowledge and some experience in IS mentioned that in certain aspects,namely the Action Scenes, the level of control should be bigger and it should not be sohigh-level.

Overall, we can consider that our prototype managed to achieve the objectives it setitself to in a first approach to this type of systems where work has been very scarce.However, some improvements should undoubtedly be made.

7.1 Future Work

In order to bring our application to a different level and to improve the limitationswe encountered during the test phase some enhancements can be made. First of all, theusage of only a computer serves as a bottleneck to the creation of the story, this issuewas identified by watching what other users did while one had control of the scene, tocircumvent this steps should be taken to distribute the application and allow for a moreparallel creation of the story instead of a purely collaborative one. That way we couldaim for a more Group Authoring approach instead of a collaborative.

50 CHAPTER 7. CONCLUSIONS AND FUTURE WORK

In terms of functionalities some new ones could be added to improve both the userexperience and the flexibility of the application, like adding a new player midway througha session or removing one that left the creation process. The problems identified inChapter 6 namely the ones related to Timing could be solved by changing our approachto the one used by [69] where some Gantt charts are used, in combination to a methodsimilar to our approach to better represent the scene time. In order to also comply to thePacing Requirement and having as inspiration the same author a system similar to [70]should be used where there is a visual feedback to the narrative arc to better help theauthor.

During the tests it was noted that a common complaint was the writing part, withseveral users claiming to be upset that it would take so much time to transfer the storyfrom their head into the prototype. This can be solved by implementing a Speech-to-Textfunctionality into our prototype. To better ascertain the real potential and weaknesses ofthe StoryColla system some more exhaustive tests should be made. These tests shouldnot only be focused in terms of users but also in terms of Drama Manager compatibility,to see if the results generated by the application are capable of being used in their finalcontext.

References

[1] Laird, J.E., Holenstein, R.: It knows what you’re going to do: Adding anticipation toa quakebot. In: Proceedings of the Fifth International Conference on AutonomousAgents (Montreal, Canada) (Jörg P. Müller, Elisabeth Andre, Sandip Sen, andClaude Frasson, eds.), ACM, Press (2001) 385–392

[2] Packard, E.: The cave of time. Choose your own adventure. Bantam Books (1979)[3] Campaign, M.P.: Choose a different ending. (http://www.youtube.com/watch?v=

JFVkzYDNJqo)[4] Bioware: Mass effect. Videogame (2008)[5] Mateas, M.: The authoring challenge in interactive storytelling. In Aylett, R., Lim,

M., Louchart, S., Petta, P., Riedl, M., eds.: Interactive Storytelling. Volume 6432of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2010) 1–1

[6] Mazza, R., Holmes, M.: Universalis. 3rd edn. Ramshead Publishing (2002)[7] Polkinghorne, D.E.: Narrative Knowing and the Human Sciences. State University

of New York Press (1988)[8] Perrault, C.: Histoires et contes du temps passé, avec des moralités. Contes de ma

mère l’Oye. (1697)[9] Roberts, D.L., Isbell, C.L.: A survey and qualitative analysis of recent advances in

drama management. International Transactions on Systems Science and Applica-tions (2008) 61–75

[10] Crawford, C.: Chris Crawford on Interactive Storytelling (New Riders Games). Num-ber ISBN 0-13-146099-4. New Riders Games (2004)

[11] Bates, J.: Virtual reality, art, and entertainment. In: PRESENCE: Teleoperatorsand Virtual Environments, MIT Press (1992) 133–138

[12] Riedl, M.O., Young, R.M.: From linear story generation to branching story graphs.IEEE Computer Graphics and Applications 26 (2006) 23–31

[13] Stine, R.L.: Goosebumps. Scholastic Publishing (1992-1997)[14] Adams, E.: Fundamentals of Game Design. 2nd edn. New Riders Publishing, Thou-

sand Oaks, CA, USA (2009)[15] Szilas, N., Marty, O., hugues Réty, J.: Authoring highly generative interactive drama.

In: In: 2nd Int. Conf. on Virtual Storytelling, Springer (2003) 37–46[16] Pizzi, D., Cavazza, M.: From debugging to authoring: Adapting productivity tools

to narrative content description. In Spierling, U., Szilas, N., eds.: Interactive

51

http://www.youtube.com/watch?v=JFVkzYDNJqo

http://www.youtube.com/watch?v=JFVkzYDNJqo


Storytelling. Volume 5334 of Lecture Notes in Computer Science. Springer Berlin/ Heidelberg (2008) 285–296

[17] Mateas, M., Stern, A.: Façade: An experiment in building a fully-realized interactivedrama. In: Game Developers Conference (GDC 03). (2003)

[18] Mateas, M.: Authoring in façade. http://www.interactivestory.net/technology/ (2005-2006) [Online; accessed 1-November-2010].

[19] Murray, J.H.: Hamlet on the Holodeck: The Future of Narrative in Cyberspace. TheFree Press, New York, NY, USA (1997)

[20] McNaughton, M., Cutumisu, M., Szafron, D., Schaeffer, J., Redford, J., Parker,D.: Scriptease: Generative design patterns for computer role-playing games. In:Proceedings of the 19th IEEE international conference on Automated softwareengineering, Washington, DC, USA, IEEE Computer Society (2004) 88–99

[21] Medler, B., Magerko, B.: Scribe: A tool for authoring event driven interactive drama.In Göbel, S., Malkewitz, R., Iurgel, I., eds.: Technologies for Interactive DigitalStorytelling and Entertainment. Volume 4326 of Lecture Notes in Computer Sci-ence. Springer Berlin / Heidelberg (2006) 139–150

[22] Carbonaro, M., Cutumisu, M., Mcnaughton, M., Onuczko, C., Roy, T., Schaeffer, J.,Szafron, D., Gillis, S., Kratchmer, S.: Interactive story writing in the classroom:Using computer games. In: In Proceedings of DiGRA. (2005) 323–338

[23] Dix, A., Finlay, J., Abowd, G.D., Beale, R.: Human Computer Interaction. 3rd ed.edn. Pearson/Prentice-Hall, Harlow, England (2004)

[24] Preece, J., Rogers, Y., Sharp, H.: Interaction Design: Beyond Human-ComputerInteraction. Wiley, Indianapolis, IN (2002)

[25] Göbel, S., Malkewitz, R., Becker, F.: Story pacing in interactive storytelling. In Pan,Z., Aylett, R., Diener, H., Jin, X., Göbel, S., Li, L., eds.: Technologies for E-Learning and Digital Entertainment. Volume 3942 of Lecture Notes in ComputerScience. Springer Berlin / Heidelberg (2006) 419–428

[26] Terveen, L.G.: Overview of human-computer collaboration. Knowledge-Based Sys-tems 8 (1995) 67 – 81 Human-computer collaboration.

[27] Hahn, U., Jarke, M., Passau, U., Box, P.O., Gennany, W., Kreplin, K., adler Ag,T., Gennany, W., Pimpinelli, M.F.: K.: Coauthor: a hypermedia group author-ing environment. In: Studies in Computer-Supported Cooperative Work, North-Holland. (1990) 79–100

[28] Santoro, F.M., Brézillon, P.: Group storytelling approach to collect contextualizedshared knowledge, Los Alamitos, CA, USA, IEEE Computer Society (2005) 388–392

[29] Valle, C., Prinz, W., Borges, M.R.S.: Generation of group storytelling in post-decision implementation process. In: International Conference on Computer Sup-ported Cooperative Work in Design. (2002) 361–367

http://www.interactivestory.net/technology/

http://www.interactivestory.net/technology/

7.1. FUTURE WORK 53

[30] Galegher, J., Kraut, R.E.: Computer-mediated communication for intellectual team-work: a field experiment in group writing. In: Proceedings of the 1990 ACMconference on Computer-supported cooperative work. CSCW ’90, New York, NY,USA, ACM (1990) 65–78

[31] Nakamura, Y., Kobayakawa, M., Takami, C., Tsuruga, Y., Kubota, H., Hamasaki,M., Nishimura, T., Sunaga, T.: Zuzie: Collaborative storytelling based on multi-ple compositions. In: ICIDS, Springer (2010) 117–122

[32] Shen, Y.T., Mazalek, A.: Puzzletale: A tangible puzzle game for interactive story-telling. In: Proceedings of the 7th Conference on Advances in Computer Enter-tainment Technology, ACM (2010) To appear.

[33] Hourcade, J.P., Bederson, B.B., Druin, A., Taxén, G.: Kidpad: Collaborative story-telling for children. In: CHI ’02 extended abstracts on Human factors in comput-ing systems. CHI EA ’02, New York, NY, USA, ACM (2002) 500–501

[34] Ryokai, K., Cassell, J.: Storymat: a play space for collaborative storytelling. In:Computer Human Interaction. (1999)

[35] Kim, J.: The threefold model. http://www.darkshire.net/~jhkim/rpg/theory/threefold/ (1998) [Online; accessed 25-October-2010].

[36] Edwards, R.: Gns and other matters of role-playing theory. http://www.indie-rpgs.com/articles/1/ (2001) [Online; accessed 25-October-2010].

[37] Edwards, R.: The whole model. http://www.indie-rpgs.com/archive/index.php?topic=8655 (2003) [Online; accessed 4-November-2010].

[38] Gygax, G., Arneson, D.: Dungeon & Dragons. Tactical Studies Rules, Inc (1974)[39] Rein·Hagen, M.: Vampire: The Masquerade. White Wolf (1991)[40] Louchart, S., Swartjes, I., Kriegel, M., Aylett, R.: Purposeful authoring for emergent

narrative. In Spierling, U., Szilas, N., eds.: Interactive Storytelling. Volume 5334of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2008) 273–284

[41] Cavazza, M., Charles, F., Mead, S.J.: Emergent situations in interactive storytelling.In: Proceedings of the 2002 ACM symposium on Applied computing. SAC ’02,New York, NY, USA, ACM (2002) 1080–1085

[42] Figueiredo, R., Brisson, A., Aylett, R., Paiva, A.: Emergent stories facilitated. InSpierling, U., Szilas, N., eds.: Interactive Storytelling. Volume 5334 of LectureNotes in Computer Science. Springer Berlin / Heidelberg (2008) 218–229

[43] Laurel, B.: Computers as Theatre. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA (1993)

[44] Weyhrauch, P.W.: Guiding interactive drama. PhD thesis, Pittsburgh, PA, USA(1997) AAI9802566.

[45] Nelson, M.J., Mateas, M., Roberts, D.L., Jr., C.L.I.: Declarative optimization-baseddrama management in interactive fiction. IEEE Computer Graphics and Appli-cations 26 (2006) 32–41

http://www.darkshire.net/~jhkim/rpg/theory/threefold/

http://www.darkshire.net/~jhkim/rpg/theory/threefold/

http://www.indie-rpgs.com/articles/1/

http://www.indie-rpgs.com/articles/1/

http://www.indie-rpgs.com/archive/index.php?topic=8655

http://www.indie-rpgs.com/archive/index.php?topic=8655


[46] Magerko, B.S.: Player modeling in the interactive drama architecture. PhD thesis,Ann Arbor, MI, USA (2006) AAI3224692.

[47] Young, R.M.: An overview of the mimesis architecture: Integrating intelligent nar-rative control into an existing gaming environment. In: Working Notes of theAAAI Spring Symposium on Artificial Intelligence and Interactive Entertainment.(2001)

[48] Riedl, M., Stern, A.: Believable agents and intelligent story adaptation for inter-active storytelling. In Göbel, S., Malkewitz, R., Iurgel, I., eds.: Technologies forInteractive Digital Storytelling and Entertainment. Volume 4326 of Lecture Notesin Computer Science. Springer Berlin / Heidelberg (2006) 1–12

[49] Mott, B.W., Lester, J.C.: U-director: a decision-theoretic narrative planning archi-tecture for storytelling environments. In: Proceedings of the fifth internationaljoint conference on Autonomous agents and multiagent systems. AAMAS ’06,New York, NY, USA, ACM (2006) 977–984

[50] Thue, D., Bulitko, V., Spetch, M., Wasylishen, E.: Interactive storytelling: A playermodelling approach. In: In Proceedings of the third Artificial Intelligence andInteractive Digital Entertainment conference (AIIDE07. (2007)

[51] Sharma, M., Ontañón, S., Mehta, M., Ram, A.: Drama management and playermodeling for interactive fiction games. Computational Intelligence 26 (2010) 183–211

[52] Göbel, S., Salvatore, L., Konrad, R., Mehm, F.: Storytec: A digital storytellingplatform for the authoring and experiencing of interactive and non-linear stories.In Spierling, U., Szilas, N., eds.: Interactive Storytelling. Volume 5334 of LectureNotes in Computer Science. Springer Berlin / Heidelberg (2008) 325–328

[53] Cheong, Y.G., Kim, Y.J., Min, W.H., Shim, E.S., Kim, J.Y.: Prism: A frameworkfor authoring interactive narratives. In Spierling, U., Szilas, N., eds.: InteractiveStorytelling. Volume 5334 of Lecture Notes in Computer Science. Springer Berlin/ Heidelberg (2008) 297–308

[54] Weiss, S., Müller, W., Spierling, U., Steimle, F.: Scenejo - an interactive storytellingplatform. In Subsol, G., ed.: Virtual Storytelling. Volume 3805 of Lecture Notesin Computer Science. Springer Berlin / Heidelberg (2005) 77–80

[55] Ulrike Spierling, Sebastian A. Weiß, W.M.: Towards accessible authoring tools forinteractive storytelling. In: Technologies for Interactive Digital Storytelling andEntertainment. (2006)

[56] Balet, O.: Inscape an authoring platform for interactive storytelling. In Cavazza, M.,Donikian, S., eds.: Virtual Storytelling. Using Virtual Reality Technologies forStorytelling. Volume 4871 of Lecture Notes in Computer Science. Springer Berlin/ Heidelberg (2007) 176–177

[57] Crawford, C.: Storytron. http://www.storytron.com/ (2009) [Online; accessed 12-November-2011].

http://www.storytron.com/

7.1. FUTURE WORK 55

[58] Grasbon, D., Braun, N.: A morphological approach to interactive storytelling. In:Conference on Artistic, Cultural and Scientific Aspects of Experimental MediaSpaces (CAST). (2001)

[59] Magerko, B.: Story representation and interactive drama. In: Proceedings of theFirst Annual Conference on Artificial Intelligence and Interactive Digital Enter-tainment (AIIDE-05). (2005)

[60] Magerko, B.: A comparative analysis of story representations for interactive narrativesystems. Artificial Intelligence (2009)

[61] Aristotle, Janko, R.: Poetics. Hackett classics. Hackett Pub. Co. (1987)[62] Scholes, R., Phelan, J., Kellogg, R.: The nature of narrative. Oxford University Press

(2006)[63] Montfort, N. In: Ordering Events in Interactive Fiction Narratives. (2007) 87–94[64] Prince, G.: A Grammar of Stories. Gruyter Mouton (1974)[65] Toedter, K.: jcalendar. http://www.toedter.com/en/jcalendar/ (2010) online:

accessed 16 June 2011.[66] jaret: timebars. http://www.jaret.de/timebars/ (2010) online: accessed 10 June

2011.[67] Burbeck, S.: Applications programming in smalltalk-80(tm): How to use model-

view-controller (mvc) (1987)[68] Russell, S.J., Norvig, P., Candy, J.F., Malik, J.M., Edwards, D.D.: Artificial intel-

ligence: a modern approach. Prentice-Hall, Inc., Upper Saddle River, NJ, USA(1996)

[69] Porteous, J., Teutenberg, J., Charles, F., Cavazza, M.: Controlling narrative time ininteractive storytelling. In: Proceedings of the 10th International Conference onAutonomous Agents and Multiagent Systems (AAMAS), Taipei, ICAPS, AAAI(2011)

[70] Porteous, J., Teutenberg, J., Pizzi, D., Cavazza, M.: Visual programming of plandynamics using constraints and landmarks. In: Proceedings of the 21st Interna-tional Conference on Automated Planning and Scheduling (ICAPS), Freiburg,AAAI (2011)

http://www.toedter.com/en/jcalendar/

http://www.jaret.de/timebars/

ATest Script

Tutorial

<Cumprimentar os utilizadores e agradecer a presença>

Um jogo de Universalis tem por base a influência que cada um consegue exercer sobre a

história. De forma a quantificar a influência que cada um consegue exercer sobre a história

utiliza-se um valor numérico sobre a forma de moedas.

Neste jogo as moedas são usadas para tudo o que influencie directamente a história, querem

criar uma personagem? Gastam no mínimo uma moeda. Aquela espada ficou verde? Mais uma

moeda. Aquela personagem criou uma armadilha para um inimigo? Mais uma moeda, etc. etc.

E assim se processa o sistema monetário nesta aplicação.

Agora que vimos isto, vamos olhar para a primeira Tab onde se lê asset browser, aqui pode-se

ver todas as criações, assim como criar novas ou editar existentes. Vamos começar então por

olhar para o modo como as personagens/props/locais são definidos no StoryColla. Para

fazermos isso precisamos de criar uma personagem.

<Criar personagem no Asset Browser com role soldado>

Como podem ver a pergunta é qual o role da personagem, Ou seja o papel que vai ter, um

soldado, um explorador, um camponês ou outra coisa qualquer. Agora que criamos um

soldado, vamos editá-lo e ver o que o caracteriza.

<Abrir menu de edição>

Como podem ver do lado esquerdo temos os atributos, onde se vê o role como sendo o

primeiro de todos. Agora vamos dar um nome ao nosso soldado.

<Trocar nome do soldado>

Além do role uma personagem pode ter vários atributos/características, por exemplo vamos

supor que o nosso soldado estava a dormir em serviço. Adicionamos o atributo dormir.

<Adicionar o atributo dormir>

<Finalizar e criar a localidade Torre de Vigia>

Além disso cada elemento destes pode possuir outros elementos, por exemplo, um soldado

possuir uma pistola, uma arma, etc.

<Mostrar o menu de Posses e adicionar Torre de Vigia às posses do soldado>

Para finalizar podem atribuir imagens às personagens e ir alterando.

<Inserir imagem do soldado>

Posto isto, vamos ver como se organiza uma história na aplicação. Cada história é composta

por várias cenas muito à semelhança dos filmes.

<Desenhar esquema para explicar melhor>

Entrando em mais detalhe, cada cena é composta por os seguintes elementos:

<Ir fazendo na aplicação enquanto se explica>

Nome, para melhor se identificar uma cena quando comparada com as outras.

<Por o nome de cena de teste na cena actual>

Tempo, onde se passa a cena. “Há muito muito tempo”, “Na segunda sexta-feira do mês de

Março do ano de 1765”, etc. O tempo não está limitado, é somente definido com base numa

frase ficando portanto completamente ao vosso critério.

<Inserir tempo na cena actual>

Precedências, como estamos a falar de histórias interactivas é normal que certos

acontecimentos tenham antecedência relativamente a outros e que se possam seguir vários

caminhos.

<Inserir uma cena filho à cena actual>

Local, onde se passa a cena.

<Definir a localidade importando-a da fase anterior>

Como é óbvio personagens.

<Importar uma personagem criada na fase anterior e criar uma personagem nova>

No nosso caso quando importam uma personagem de uma cena anterior ela é copiada pró isso

qualquer alteração que queiram fazer não vai alterar a personagem original.

Além das personagens também temos objectos, aqui chamados de Props, por exemplo uma

arma.

<Criar um pistola>

Depois por cada cena temos o guião /plot onde definimos o que acontece na cena

<Escrever no guião a personagem A foi acordada pela personagem B e esta deu-lhe uma

pistola>

Por fim, em termos de cenas, pedimos que itemizem as acções de forma a discriminar as

mesmas.

<Por nas acções da cena Personagem B acorda Personagem A e alterar na Personagem A as

características de a dormir para acordada, criar outra acção com Personagem A recebe arma

de Personagem B e alterar as possessions da mesma>

Em termos de Cenas é só isto.

Agora vamos supor que alguém não queria que ele recebesse uma pistola mas sim uma espada

e não conseguiam chegar a acordo. Para essas situações existe a mecânica de complicações

onde um membro desafia o outro e aposta moedas contra ele. Se os outros utilizadores

quiserem podem participar e ajudar a decidir.

<Fazer uma complicação e o jogador que ganha troca a pistola por uma espada>

E pronto, isto conclui o tutorial têm alguma pergunta?

<Responder perguntas>

História

Três porquinhos

Criar um fim alternativo, a partir do momento que o Lobo destrói a casa do porquinhos

BUsers Survey

Perfil Sexo? M F

Idade? _________

Gosta de ler? Sim Não

Gosta de escrever? Sim Não

Tem algum trabalho escrito publicado (seja em jogo, livro, blog, etc.)? Sim Não

Se sim, em quê: ________________________

Tem alguma experiência de programação? Sim Não

Tem alguma experiência na área de Interactive Storytelling, seja a escrever histórias, fazer

jogos, etc?

Sim Não

Tipo de jogo preferido_________________________

Questionário Digital

Diga se concorda com as seguintes afirmações escolhendo um valor entre 1-5 onde 1 significa

“Discordo totalmente” e 5 “Concordo Totalmente”

Geral 1 2 3 4 5

Gostei de usar a aplicação

A aplicação é fácil de usar

Se precisasse de criar uma história interactiva usaria este método

As mensagens de erro foram claras

As mensagens de erro ajudaram-me a recuperar das falhas

Senti que a minha participação importava mesmo quando não tinha controlo da cena

Se precisasse de criar uma história interactiva usaria esta aplicação

Usou imagens para representar elementos?

Sim Não

Se sim:

Imagens 1 2 3 4 5

Foi fácil adicionar uma imagem

O uso de imagens foi importante para a criação da história

A forma como se usa imagens foi adequada para a criação da história

Observações (opcional):

_____________________________________________________________________________

_____________________________________________________________________________

Elementos:

Elementos 1 2 3 4 5

É fácil criar um elemento novo (personagem, prop ou localização)

A forma como se cria um elemento é adequada

É fácil alterar elementos

A forma como se altera elementos é adequada

A forma como os elementos estão representados é adequada


_____________________________________________________________________________

_____________________________________________________________________________

Cenas:

Cenas 1 2 3 4 5

É fácil alterar cenas

A forma como cada cena está organizada é adequada

Ter as acções numa lista ajudou-me a organizar a história

É fácil alterar acções

A forma como as acções estão representadas é adequada

È fácil adicionar elementos a uma cena

O modo como se adicionam elementos a uma cena é adequado


_____________________________________________________________________________

_____________________________________________________________________________

Relativamente ao Tempo:

Tempo 1 2 3 4 5

É fácil alterar o tempo de uma cena

A forma como se representa o tempo é adequada

É fácil criar um caminho alternativo na história

Poder alterar o caminho foi importante para a criação da história

O modo como se criam caminhos alternativos é adequado

A representação gráfica das cenas facilitou na percepção temporal de cada uma


_____________________________________________________________________________

_____________________________________________________________________________

Conflitos 1 2 3 4 5

É importante o sistema ter uma forma de gerir conflitos

Usou o sistema de conflitos?

Sim Não

Se Sim:

Conflitos 1 2 3 4 5

O sistema de conflitos é fácil de usar

O sistema de conflitos é adequado


_____________________________________________________________________________

_____________________________________________________________________________

Questionário Final

Quais os pontos fortes da aplicação?

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

O que mais lhe desagradou na aplicação?

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

Preferiria utilizar este método de criação de histórias no papel? Porquê?

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

Comentários:

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

68 APPENDIX B. USERS SURVEY

COther Implementations

During the implementation of the prototype some functionalities were needed thatSwing did not support natively:

• A Panel in Swing which only element is an image that scales according to thedimensions of the panel

• A Panel in Swing which only contains text and scales it regarding the size of thepanel

The first functionality was somewhat solved by the community. An image was loadedinto a panel, however it never scaled to fit it, it was simply drawn. Taking that as astarting point the original code was altered to automatically resize as needed. The secondfunctionality needed was trickier since there were no solutions available, our method wasto render an image from the text at a very high resolution and then scale it down until itfit our needs. The final result can be checked at: https://sourceforge.net/projects/imagepanel/files/;accessed1-August-2011 where it was made publicly available foreveryone to use and alter as needed.

https://sourceforge.net/projects/imagepanel/files/; accessed 1-August-2011

https://sourceforge.net/projects/imagepanel/files/; accessed 1-August-2011

70 APPENDIX C. OTHER IMPLEMENTATIONS

DTest Full Results

72 APPENDIX D. TEST FULL RESULTS

74 APPENDIX D. TEST FULL RESULTS

anapproachtocollaborativestorytelling · even mentions the need for an entity of interactive drama...

Documents