authoring tools for interactive narratives · 2009. 3. 20. · authoring tools for interactive...

Authoring tools for interactivenarratives - an interface design of

a script editor for the pervasivegame Backseat Playground

Angelica Backstrom and Elvira Danell

March 17, 2009Master’s Thesis in Computing Science, 2*30 credits

Supervisor at CS-UmU: Anders BrobergExaminer: Per Lindstrom

Umea University

Department of Computing Science

SE-901 87 UMEA

SWEDEN

Abstract

The frontiers of gaming is constantly moved forward and the pervasive gameBackseat Playground, developed at Interactive Institute is no exception. Thegame experience is created while driving along the road, the story adapts tothe outside environment and according to the player’s interactions with thegame world. To create such an adaptive game world requires a great amountof story content, and to make this process manageable a tool was requested bythe developer team at Interactive Institute. The main challenge of designingsuch a tool is to visualize and structure the special information needed in thiskind of game. This thesis investigates the scope of the game Backseat Play-ground and establishes the requirements for a possible editor. The thesis alsodives into two theoretical parts with close connections to this field: Interactivenarratives and content creation for prevasive game environments.

The creation process of this prototype has involved tasks such as interviewsand script creation to schetches and flow charts and the result is, besides anextentensive pre-study also a semi-functional prototype for demonstrationalpurposes implemented in Flash CS3, actionscript 3.0. This report describesthe complete workflow and the final result of this thesis.

Contents

1 Introduction 3

2 Background 5

2.1 Interactive Institute . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Backseat Playground - the Game . . . . . . . . . . . . . . . . . 5

2.3 The BSP design process . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Problem description . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Interacive Narratives - how do you interact with a story? 11

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Problem description . . . . . . . . . . . . . . . . . . . . 11

3.1.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.3 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Historical overview . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 What is an interactive narrative? . . . . . . . . . . . . . . . . . 13

3.4 Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Interactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Pervasive games and ”The magic circle” . . . . . . . . . . . . . 17

3.7 BSP and the interactive drama . . . . . . . . . . . . . . . . . . 18

3.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Content creation for pervasive game environments 23

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Problem description . . . . . . . . . . . . . . . . . . . . . . . . 24

iii

iv CONTENTS

4.3 Editorial walk-through . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.1 DraMachina . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.2 Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.3 UCreate . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Editor Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 User generated content and the concept of Modding scenes . . 34

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 The project 37

5.1 The pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Interviewing the team . . . . . . . . . . . . . . . . . . . 37

5.1.2 The result of the interviews . . . . . . . . . . . . . . . . 38

5.1.3 Exploring the game world of BSP . . . . . . . . . . . . . 39

5.1.4 The details of the game technology . . . . . . . . . . . . 40

5.2 Results of the pre-study . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Editorial scope . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.2 The potential users . . . . . . . . . . . . . . . . . . . . . 43

5.2.3 Closed and semi-closed editors . . . . . . . . . . . . . . 44

5.2.4 General Requirements . . . . . . . . . . . . . . . . . . . 45

5.3 The design process . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3.1 Sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3.2 Mood board . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3.3 Workshops . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.4 Lo-fi prototypes . . . . . . . . . . . . . . . . . . . . . . . 49

6 The final result - The BSP game editor prototype 55

6.1 Main structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.1 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.3 The Menu bar . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.4 The objects . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.5 The Game Devices . . . . . . . . . . . . . . . . . . . . . 63

6.2 Design guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.1 Match between system and the real world . . . . . . . . 65

6.2.2 Consistency and standards . . . . . . . . . . . . . . . . 66

6.2.3 Visability of system status . . . . . . . . . . . . . . . . . 66

6.2.4 User control and freedom . . . . . . . . . . . . . . . . . 66

6.2.5 Error prevention, recognition, and recovery . . . . . . . 67

CONTENTS v

6.2.6 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2.7 Flexibility and e!ciency of use . . . . . . . . . . . . . . 67

6.2.8 Simplicity and aesthetic integrity . . . . . . . . . . . . . 67

6.2.9 GUI-general guidelines . . . . . . . . . . . . . . . . . . . 67

6.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Discussion 73

7.1 Known issues in the prototype . . . . . . . . . . . . . . . . . . 75

7.2 The future of the editor . . . . . . . . . . . . . . . . . . . . . . 75

8 Conclusions 77

9 Acknowledgements 79

References 83

A Interview questions 85

B Requirement specification 87

vi CONTENTS

List of Figures

3.1 Local interactivity . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Branshing, oriented graph . . . . . . . . . . . . . . . . . . . . . 16

3.3 Non oriented graph . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Architecture of an interactive fiction [16] . . . . . . . . . . . . . 26

4.2 Main window of DraMashina . . . . . . . . . . . . . . . . . . . 27

4.3 Element placement in Scribe . . . . . . . . . . . . . . . . . . . 28

4.4 Story creation in Scribe . . . . . . . . . . . . . . . . . . . . . . 29

4.5 Timeline in Scribe . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.6 Stage Set in UCreate . . . . . . . . . . . . . . . . . . . . . . . . 31

4.7 Story Tree View in UCreate . . . . . . . . . . . . . . . . . . . . 32

4.8 Scenario View in UCreate . . . . . . . . . . . . . . . . . . . . . 32

5.1 The scope of BSP game editor . . . . . . . . . . . . . . . . . . 43

5.2 Early sketches and ideas (1) . . . . . . . . . . . . . . . . . . . . 48

5.3 Early sketches and ideas (2) . . . . . . . . . . . . . . . . . . . . 48

5.4 Inspiration gathered at local design and furniture shops in Stock-

holm. ”How can the menu structuring issue be solved?” . . . . 49

5.5 Various ideas and lo-fi’s of interfaces (1) . . . . . . . . . . . . . 51

5.6 Various ideas and lo-fi’s of interfaces (2) . . . . . . . . . . . . . 52

5.7 Flow chart of the editors functions . . . . . . . . . . . . . . . . 53

6.1 The BSP game editor, main view . . . . . . . . . . . . . . . . . 57

6.2 The di"erent overviews . . . . . . . . . . . . . . . . . . . . . . . 58

6.3 The menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.4 Label 1: The object selector for Group Waters. Label 2: The

”trigger action selector” extracted . . . . . . . . . . . . . . . . 60

vii

LIST OF FIGURES 1

6.5 Label 3: Group selector after the initial trigger object Sea has

been selected. Now other objects can be added and o"sets of

time or distance can be set. Label 4: The selected trigger object

at priority slot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.6 Label 5: Another trigger object Creek is added at priority slot 2 61

6.7 Label 6: The game device Phone at its initial state. Label 7:

Walkie-talkie with Text-to-speech asset added and the ”active

player choice” selected . . . . . . . . . . . . . . . . . . . . . . . 62

6.8 Label 8: The game device Report. Label 9: The game device

Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.9 Label 10: The Sounds asset. This is how sound is added in-

ternally in the Phone or Walkie-talkie device, or directly to the

game when dropped on the work area . . . . . . . . . . . . . . 63

6.10 Label 11: The Walkie-talkie as a local event and with the player

choice active. Label 12: The Walkie-talkie as a local event with

a trigger o"set activated . . . . . . . . . . . . . . . . . . . . . . 64

6.11 Label 13: The Sleep function. Label 14: The Global function.

Label 15: The Label function . . . . . . . . . . . . . . . . . . . 64

6.12 Label 1: User has created The Forest scenario and added a Wood

trigger object with - 20 meters as trigger o"set. Label 2: 20

meters before the trigger object Helena calls and gives the player

some interesting information . . . . . . . . . . . . . . . . . . . . 69

6.13 Label 3: Agent Alpha, one of the agents out in the field contacts

the player by Walkie-talkie, but gets interrupted by a gunshot.

Label 4: The complete Walkie-talkie communication . . . . . . 70

6.14 Label 5: A Globe is dropped to make execution of the rest of

the script global/non-local based. A report from agent Alpha

gives the player information about findings in the forest. Label

6: The complete scenario structure . . . . . . . . . . . . . . . . 71

2 LIST OF FIGURES

Chapter 1

Introduction

There is a new genre of games that introduces ways of using computer power toenhance human experience. The concept of pervasive games is to integrate thecomputer into the environment and use the context to create more immersegaming experiences. The major parts of pervasive games involves invisiblecomputers; augmented reality and an interactive story that includes the playeras an in game character. The biggest problem for this kind of storytelling isthe generation of meaningful story content. As the game emerges the contentgrows exponentially and it can become very hard to overlook the whole pic-ture. Another issue is that the story creator has to be both a programmer anda writer to be able to create this kind of stories. To aid in this process and tosave time and money it is preferable to have some kind of tool that guides thewriter in the creation of the large amount of game content needed, while at thesame time give a good overview of the interactive story.

The Mobility Studio, a research department at Interactive Institute in Stock-holm, Kista has developed a pervasive game prototype called the BackseatPlayground (BSP) where the research edge is to create a game world basedon a car journey. The research team requested a analysis and a concept fora story creation tool that can be used for game content creation, specific forBSP. That request lays as a ground for this thesis.

The aim of this project is to look into the area of pervasive games in gen-eral and the prototype game Backseat Playground in particular while trying toanswer the question; “how can one visualize the creation of a game story wherethe game events are dependent on position and external objects that occurs ina linear yet unpredictable manner along a traveled path.” This involves lookingdeeper into the concept of interactive narratives and content creative tools.The outcome of this project is an idea for a content creation tool for the BSPenvironment. The project results in a semi functional prototype of a graphicaluser interface where the focus lies on structure, disposition and user friendliness.

3

4 Chapter 1. Introduction

The method used in this project has followed the classical design process start-ing with a pre-study including a requirement analysis. The pre-study wasconducted through interviews and gave a technical walk-through of the game.After establishing requirements followed sketching and lo-fi prototyping thatevolved into two di"erent ideas. The final idea emerged and was implementedinto the hi-level prototype that is the result of the project. Throughout theentire project workshops have been used as a common ground for discussionsand decisions.

The structure of this thesis is as follows: chapter 2 will describe the back-ground of BSP and how it evolved from idea to prototype, but also cover theInteractive Institute and the problem description, goals and constraints of thethesis project. Chapter 3 goes deeper into what interactive narratives are andchapter 4 describes the challenges of content creation for these kinds of games.Chapter 5 deals with the work done within the thesis project and chapter6 is a walk through of the result and the editor, explaining design decisionsmade and constraints accepted in the prototype. Chapter 7 discuss the projectand chapter 8 concludes with conclusions made and lessons learned during theproject.

Chapter 2

Background

As this is a rarely new area in game design research, and to give some back-ground into the BSP project and the environment from which it emerged, theactual research project and the concept of BSP will be described in the sectionsbelow as well as the organization of the Interactive Institute. The final part ofthis chapter will deal with the problem description of this thesis and the goalsand constraints of this project.

2.1 Interactive Institute

The Interactive Institute is a experimental it-research institute started in 1998with the focus of combining technology with art and design. At the instituteinput comes from art and design as well as information technology and theresearch borders between art, design and technology, industry and academy. [1]

In 2002 the Mobile Service project, funded by the Swedish Foundation forStrategic Research was started with the aim to ”lay the groundwork for thisnext step, preparing us for the future mobile life” - Hook [2]. Part of this projectis the Mobility Studio lead by Oscar Juhlin, PhD. Juhlin has according to Hook”a strong vision for how to enhance the experience of traveling in cars and othervehicles, transforming the road into an area for novel and truly mobile expe-riences.” [2] and from this vision the BSP prototype has evolved. Within theMobility Studio several gaming prototypes tailored for the highway experiencehas been developed. Games like the Road Rager and Backseat Gaming gavethe team the ideas and tools needed to develop the Backseat Playground. [3]

2.2 Backseat Playground - the Game

“Dave is sitting in the backseat of his parent’s car on the way to visit relativesin a nearby city. The car is moving along a country side road. He looks at a

5

6 Chapter 2. Background

field, a barn and a power line appearing in the distance. His peaceful observa-tion of the surroundings is suddenly interrupted by a crackling sound. He turnshis attention away from the scenery outside and on to the walkie-talkie in hishand. A man’s voice appears over the radio. “Agent Bravo to agent Alfa. Ijust saw your car passing by. We are here at the other side of the golf coursesearching for the robbers. Over!” He looks up and indeed sees a golf course onthe field just behind the barn. He decides to pull out his directional surveillancemicrophone and starts sweeping the surrounding landscape for suspicious ac-tivities. From the forest on the other side of the golf course a couple of birdscan be heard among the trees. Everything else seems to be dead quiet. The sunis disappearing behind the tree line and the landscape is beginning to fill withlong dark shadows. Then suddenly the deafening sound of a gunshot piercesthe quietness. He quickly reaches for the walkie-talkie in order to contact thenearby team of agents over the radio.” [4]

The section above describes a scenario in the pervasive game Backseat Play-ground (BSP). BSP is developed at Mobile Life, part of the Mobility Studioat the Interactive Institute, Kista, Stockholm. The research team has troughiterations of the design process searched for a good interpretation of a pervasivegame embedded in the highway experience.

Pervasive gaming can be explained as ’anywhere - anytime’, or in the words ofMontola: “Pervasive game is a game that has one or more salient features thatexpand the contractual magic circle of play socially, spatially or temporally.” [5],while the highway experience can be summarized as a continuous flow of im-pressions and new situations. This special sensation of motion and contingentencounters that occur whilst on the road are referred to as the highway experi-ence by the team, and is one of the main focal points in the development of BSP.

In the game, the player takes on the role as a field agent manager in a crimeunit with the task to oversee operations with the agents out on the field, as wellas the communication with the head quarter. In the introductory scene of thegame the player learns from a radio broadcast that a burglary has taken placeat the History Museum, where some valuable artifacts were stolen. Withinseconds the phone calls and Helena is introduced to the player. Helena is theplayers connection to head quarter and explains the rules of the game; theplayer has three teams of special agents at his/her disposal, and reports andinformation will come as soon as possible, all through the game, either fromhead quarter or from the agents on the field. The last character to be intro-duced to the player is Ulf. He is the boss at head quarter, and through thegame it becomes evident that his ideas and plans for the investigation doesn’talways follow the “right” path, and a dark mystery twist is unveiled. Will theplayer choose to follow Helena’s ideas or will he listen to Ulf? And so the gameis on.

2.3. The BSP design process 7

2.3 The BSP design process

During the process of creating the BSP prototype, the research team has beenfaced with five issues, where the first four has been given main focus in theimplementation of this project. These issues were to:

– Map game theory to journey experience

– Enable interaction with road objects

– Create experiences based on road objects

– Match game-content to the temporal unfolding of the surrounding road-context

– Account for tra!c safety

Since the game’s researching edge is the interactivity with objects outside ofthe car, one of the main issues was to not claim to much focus on the gamingdevice. Hence the game is based on audio centric interaction. The player hasa set of virtual devices to be able to “explore, reveal and unfold the adventureembedded in the surrounding physical landscape”. The mobile phone and thewalkie-talkie allows the player to interact with the in-game characters. Togive the game that extra touch of “reality”, or link to the surroundings, thecharacters sometimes gives references to geographical objects in the vicinity ofthe car. The directional microphone can be used to investigate the soundscapethat is continuously built around the car as it moves along. The last interactiveparts of the gaming device, except for the radio in the introductory scene, arethe reports that can be sent from any of the in-game character, and the multiplechoices the player can be asked to make when sending agents to one locationor the other.

2.4 Problem description

There are some issues that all pervasive games are struggling with: the contextof the game is unpredictable, and the branching tree can become infinitely largeand has to be controlled somehow. It is very hard to overlook the whole storyif the game is emerging freely. In the special case of BSP, the game brancheswith two choices at a time, and is not an emergent game since the choices onlyalters in which way the goal is reached, they do not a"ect the goal itself. Thechoices only a"ect the conflict between the player, Ulf and Helena. There is apossibility though, in the future, to provide some emergence also in the BSP.As the game looks now, this is not implemented.

BSP is a prototype of a location based pervasive game with a sequential storyunveiling and the research edge is that the game isn’t tied to a specific location.


As BSP is a prototype it has not been fully developed and only a piece of astory is implemented and tested. According to interviews conducted the gamecreators experienced it hard to find a good way of creating meaningful storiesand make them fit into the game environment. They felt the need for somekind of tool to help them and guide them in the story content creation process.As it is a very specific game environment no other tool could fulfill their needs.Existing editors such as UCreate, Scribe and DraMachina, see chapter 4, areall editors for interactive game play, but could not meet all requirements fromthe team. Game Creator, developed by the IperG [6], is a very general toolthat can be used in this type of contexts but the location is always fixed toa specific object in the environment. This is a problem for BSP as the gameneeds to generate story locations depending on the route the car takes. Forexample if a section of the story is set to happen in a church, the game hasto be able to choose another appropriate building if no church comes along,otherwise the story might be too slow or not functioning at all. These other,appropriate buildings are preferably specified by the creator of the story alongwith o"sets such as the passing of objects, crossing lines and entering or leavingareas. The need of a tool showed to be extensive also in the area of coachingcreativity and cooperation across professions, such as programmers, designersand writers. In the case of commercialization of the game the tool is neededfor fast and cheap story creation and a text output of character dialogs to usefor actor recording.

2.4.1 Goals

The main goals of this project are to:

– Get a deeper understanding of concepts such as pervasive games, inter-active storytelling and the BSP game concept itself.

– Get insights of how other editors in this field are constructed and fromthis extract main guidelines to be followed in the creation process of theBSP editor.

– Establish requirements for the future editor

– Identify the user

– Create a BSP editor concept by sketching and making lo-fi prototypesthat will be tested in workshops and finally evolve into a hi-fi flash pro-totype for test and evaluation purposes.

2.4.2 Method

The project initiated with a prestudy that included an extensive literaturestudy along with semi structured interviews with the BSP team members. The

2.4. Problem description 9

second phase consisted of brainstorming, sketching and workshops to generateideas for the interface of the authoring tool. Two concepts were chosen forfurther development and a last workshop was held with the creators and thefinal idea was chosen. The last phase was to build a more or less functionalprototype that could be tested and used as grounds for further discussions ofthe BSP concept, as it is still an unfinished research prototype.

2.4.3 Constraints

Since this is a research prototype for the BSP concept, the game itself is newand not fully tested which makes it impossible to predict the growth of thesystem and design for all possible outcomes. Also the constraint of only lookingin-house gives the project limitations. These limitations are further discussedin chapter 7.The aim of the project is therfor not to build a completely functional editorwith script output, but instead work as a ground for further discussion anddevelopment. The result of the project is a basic functionality prototype withlimited access to the entire design concept. The focus has been on developinga meens to display the general ideas behind the graphical user interface and isnot a completely flawless editor.

Chapter 3

Interacive Narratives - how

do you interact with a

story?

3.1 Introduction

Everything holds a story; we just have to tell it, and why stop there? How aboutinteracting with it? New technology allows us to create stories that take theexperience to another level. We can choose to watch, listen, even feel sometimesand the most exciting of all, we can choose to contribute ourselves. We caninteract with the characters, the environment, and the story development. Thiskind of storytelling is what constitutes interactive narrative also referred toas interactive drama. This part of the master thesis looks into the concept,issues and problems of interactive storytelling and discusses some ideas thatcan contribute to the project of building the BSP game editor. The scope of thisstudy is computer games/pervasive games and it is the interactive narrative ofthese games that is in focus.

3.1.1 Problem description

The interactive narrative holds a paradox; based on the definition of what astory is, the more interactive a story gets the less of a story it is. The biggestchallenge of the pervasive game story creation is the task of combining theinteractivity and the narrativity in a manner that gives the best and the mostimmersive game experience [7]. The aim of this study is to find out what con-stitutes an interactive narrative and what role does the author have in thiskind of storytelling.

11

12Chapter 3. Interacive Narratives - how do you interact with a

story?

Questions this chapter will try to answer are:

– What constitutes an interactive narrative in pervasive games and howcan BSP be described in terms of these concepts?

– What role does the author have in these kinds of storytelling?

– How can we aid the author/game designer in creating interactive story-telling for pervasive games?

3.1.2 Method

This part is mainly based on a literature study of both articles and bookswritten on this subject. Some ideas for discussion are taken from the interviewswith the BSP developing team.

3.1.3 Disposition

The chapter starts with a brief historical overview and continues with a moredetailed description of di"erent concepts in interactive narrative. Chapter 2.3establishes what an interactive narrative is and constitutes from, 2.4 discussesthe authoring and 2.5 defines di"erent kinds of interactivity that can occur inthe scope of interactive drama. In chapter 2.6 the concept of a so called magiccircle, the game arena, is introduced. At the end, in chapter 2.7, 2.8 and 2.9the facts are put in relation to the interactive narrative that BSP provides andthe conclusions important to the project are discussed.

3.2 Historical overview

One might think this is a rarely new idea, but some scientist claim that inter-active storytelling started long before the computer entered the arena. There isa theory that hypothesizes about prehistoric camp fire gatherings where a sto-ryteller entertained his audience with a story without a fixed plot that changedaccording to reactions from the listeners [8]. This theory being true or not,stories have always been told in di"erent ways, adapted to the audience andacted upon, take for example old ancient myths and the religious rituals peopleperformed based on them [8]. Another type of old story interactivity is gamesand old sport events like the Olympiad, which of course are the forefathers totoday’s video / computer games. Role playing games are also a type of inter-active storytelling in the real world. All of these show that interacting with astory is not a new concept, but one have to admit that new technology makesit a lot easier and more accessible to experience di"erent kinds of narrativesand interact with them.

The characteristic of stories is that they are mostly linear, which means that oneevent is followed by another event in a logical, fixed and progressive sequence.

3.3. What is an interactive narrative? 13

Interactivity on the other hand, is always non linear. As you start interactingwith a story you break the linearity, forcing story pieces to be combined inother ways. This concept was also explored long before the computer and digi-tal media became everyday entertainment. Some writers tried to create novelswhere chapters and di"erent parts could be read in random order and still makea continuous story. This randomness gave an essence to the story and madeit more exciting. Some important work was done by the author James Joyce,where he on paper created stories that had a hyper textual type of storyline.Many think of his work as being the precursor to digital hypertext [8], text thatconstitutes of text parts that can be linked in a random order and the readerdecides how the parts will be connected. One good example is the World WideWeb, the most famous hypertextual medium [9]. The concept of hypertext wasinvented by Vannevar Bush in 1945, describing a system that should handledocuments, images etc. and allow the user to view them in a random orderby connecting the parts with links. This system was calles MEMEX (MemoryExtender). This system never got developed but the concept lived and in 1967the first hypertextual system was created [9].

The thing about digital hypertexts is that they have to be programmed. Therehas to be some kind of logical rules for how the pieces of text should relateto the interactivity of the user. Interactive narratives, as referred to in thisstudy, similar to or even being a kind of hypertext therefore needs a computermechanism to exist. Not surprisingly, the area of computer games is the onearena where the concept of interactive narratives is widely used. A game allowsthe player to participate in a story development and contribute to the outcome.Interaction is the essence of game playing. Pervasive gaming takes the conceptto another level, allowing the player to participate as an in-game character,a"ecting not only the outcome but also the other characters development andthe game environment.

3.3 What is an interactive narrative?

So, what is needed to constitute an interactive drama? What separates thegame play from being just a orchestrated story narrated by a machine? Laurelstated in 1986 that an interactive drama “is a first-person experience within afantasy world, in which the User may create, enact, and observe a characterwhose choices and actions a!ect the course of events just as they might in aplay.” [10]

The interactive narrative consists of three components; the author, the com-puter and the user. In an interactive narrative story the author is still presentand plays a very central role. The goal of interactive narratives is to providea story where the user can interact with the elements of the story in his/herway. This new way of writing stories demands a lot from the author.


story?

Most computer aided games are mediums that tell a story and allow theviewer/listener to, in some manner, participate in the story development. Ingames that is said to be pervasive the player acts in the real world as one ofthe characters in the game. The environment and the player a"ect how thegame story looks like and in what way it is told. The real world and its statesare taken into account in the storyline and are enhanced by computer powerand a fictional plot. A player’s choice can a"ect not only the outcome of thegame but also another character’s development and that is what is meant byan interactive narrative, a story that allows interaction. This fact describes thebiggest paradox in interactive storytelling; a story is defined to be linear andstrictly authored but interaction disturbs the linearity and also the authors’authority [7]. There is a displacement of the author’s control, making him/herinto a director rather than a regular storyteller. The more interaction a storyallows the less of a narrative it becomes and the challenge is to combine thesetwo to create an extraordinary game experience.

The interactive narrative can also be classified as a genre of computer gen-erated stories where the user is one main character and the other charactersand events are automated through a program written by the author [7]. Becauseof the inverse correlation between interaction and the narrativity, interactivedrama raises new questions concerning choice and influence. The key issue is tomanage the great amount of choice given and all the possible outcomes of thesechoices. This is the one of the challenges an author of interactive narrativeshas to face.

3.4 Authoring

Szilas [7] proposes a model for creating interactive narratives; he suggests thatbuilding interactive narratives is to deconstruct a story into pieces and thenlet the computer reassemble these pieces according to a users actions. Theauthoring then basically consists of writing the pieces and defining rules forhow to combine the pieces. The larger the size of the piece, the easier becomesthe authoring but it puts limits on the interactivity, as the interactivity occursbetween the pieces. If the pieces are too large there are not too many choicesfor the user. This is what the author calls Coarse Grain Model. [7] An exampleis the game Facade [7] that is built up of so called ”beats”, which basically aremicro scenes. The beats are variable, interwoven, interruptible, which createsinteractivity, but the interactivity is mostly local. This means that the usercan trigger a beat, modify how a beat happens but it does not have an influ-ence on the content of the future beats, because they are already authored inadvance. To enlarge the interactivity one must decompose the story into basicactions. This is called the Fine Grain Model [7]. A system that does that isErasmatron [7] where the drama is built up from a chain of actions calculated

3.5. Interactivity 15

by the system and selected by the user. Each action is a sentence based on oneverb. The plot evolves in the dynamic combination of these actions.

The characters are an important part of a story. We could build intelligent char-acters with a rich cognitive, social and emotional intelligence that maybe wouldproduce an interesting narrative. The traditional game industry is evolving to-wards adding more and more intelligent abilities to the game characters [7].The task is di!cult though, it involves a full modelling of human behaviour ina broad and shallow way. Szilas claims that in AI it has become more impor-tant to build believable rather than realistic characters. They claim that thee"ect a character has on the player is more important than the accuracy of ahuman behaviour. According to Scilaz, it is not given that intelligent agent willprovide an interesting story only by existing and acting in a world. A narrativeis a construction where each action is designed according to the whole. [7] Anarrative is a sequence of events. A sequence is a result of the simulation ofa system. Interacting with a narrative is then equivalent to interacting to asystem that produces stories. Szilas proposes that to e!ciently design inter-active storytelling one has to express the narrative in terms of narrative lawsand make the computer simulate these laws in real time. The issue is to findthe right set of laws.

3.5 Interactivity

Any narrative contains three dimensions; Discourse dimension, story dimensionand perceptual dimension [7]. Discourse dimension means that any narrativeis a discourse; it aims to convey a message to its readers. A narrative is notneutral; there are always actions that are good and actions that can be consid-ered as bad. The narrative is a specific type of discourse that involves a storyand this is the story dimension. The story can be described as a succession ofevents and character actions and is a complex combination of several sequences.Perceptual dimension concerns the question of how a story is perceived by theviewer. How is single sequences organized regarding the duration of time, be-yond the ordering of its elements? How do sequences work together? Why doesone sequence follow a certain route versus another?

Related to the above Szilas distinguishes di"erent kinds of interactivity; Dis-cursive, superposed, branching and destructed [7]. Each one of them explainedbelow.

Discursive interactivity means that the user influences in which way he/sheis given the story but not the story itself. The narrative constitutes of twoparts: the story and the plot. The story is the succession of chronologicalevents and the plot is the succession of events, not always chronological, as


story?

they are told to the audience. The plot is also referred to as discourse and thistype of interactivity occurs at this level.

Superposed interactivity is the kind of interactivity that only has localinfluence on the story. For example when a certain goal is reached the playerhas to solve some kind of puzzle in order to get to the next level. This kind ofinteractivity often requires some kind of skill from the user to trigger the nextpredefined event.

INTERACTION POINTSUCCEEDFAIL

EVENT 2

EVENT 3

END

EVENT 1

Figure 3.1: Local interactivity

Figure 3.2: Branshing, oriented graph

Branching, as it sounds, concerns the kind of interactivity that consists of anumber of player choices. The chain of events becomes a graph where everynode is a player choice. If the graph is oriented, the author can control thevarious paths made available to the user. The main problem of this approach isthat the author must design all possibilities, which grow exponentially with thenumber of nodes. One solution is to cut some branches (deadlocks) or mergesome others. This will reduce the number of possibilities but the user’s choicewill not have an impact on the main storyline. Another solution is to use a

3.6. Pervasive games and ”The magic circle” 17

memory of user’s choice to modify the graph later in the story, which is calledconditional branching. It improves the user’s feeling of having an impact, butit only constitutes a very partial solution to the problem of combinatorial ex-plosion.

Destructured interactivity means that the graphs of events are not ori-ented, allowing various ways of navigating between story events. In that case,except for very particular stories, the causality of the narrative is broken andthe immersion inside the story world is not possible. [7]

Figure 3.3: Non oriented graph

3.6 Pervasive games and ”The magic circle”

One interesting area where the interactive narrative is constantly discussed isthe pervasive game. It is not the focus of this study to explain every conceptof pervasive gaming and the following chapter will therefore only give a briefoverview of the area.

Pervasive games are computer enhanced games that are played in the realworld. Walther [11] defines pervasive games as an over-arching concept thatincludes the following game formats: mobile games that take the location intoaccount in the game rules, locations-based games, ubiquitous games, virtualreality games, augmented reality games, mixed reality games and adaptronicgames. Mainly, these are games that somehow use the real world as a part ofthe game story.

Every game provides a special arena, embedding the player into a, often sur-real, game world. This is a very important part of a game, because it takesthe player somewhere else, to a place where everyday rules do not apply. Itis a playground marked o" beforehand where the game can takes place, i.e.the arena, the card table, the stage, the screen [12]. Actually, this is the goal


story?

of most entertaining mediums, books, movies etc, and this plays a big role inmaking people return to experience more. This special place that a game or abook or a movie creates for the player/viewer is called ”the magic circle”. [12]These are playgrounds within which special rules apply. It is easy to define themagic circle of a regular game, but what constitutes the magic circle of a per-vasive game? Is the place where the experience takes place blurred or scattered?

The real world is the dominating element, the features within are non change-able by the game. The game must alter itself instead. This leads to a defini-tion that the magic circle of pervasive games is scattered across a sample ofthe appropriated environment which are then activated on an interaction tointeraction basis. Each person, in game character, house artefact is pieces ofthe magic circle, having no meaning of their own. [12]

3.7 BSP and the interactive drama

The creators of BSP claim that the scene BSP provides can be an area wherethe issues of interactive narratives in fact can be combined in a good way andthe conflict between interactivity and narration can make sense.

To view the landscape through a driving car is a visually sequential experi-ence that can be compared with a drama in room and movement [13]. So, theoutside view tells a linear story that is combined with the game devices thatapplies fiction on that story and allows the player to interact with it. Eventhough there are no emergence and the characters are not in focus, the BSPprovides an interactive narrative that gives the player an interesting and im-mersive experience. When the characters are important in other games in BSPthere are map objects that stands for creating the game scene (the magic cir-cle). When the game knows exactly where you are and the characters talkingabout the exact house you’re passing, the game is perceived as intelligent andthe immersion is there. The characters are of course also important, as theycarry the interaction in the game and take the story forward, but they are notin focus here.

To classify the interactivity of BSP one can use Szilas [7] definitions describedabove. According to the definition the interactivity in BSP is discursive, be-cause of the order in which the di"erent story events are delivered. The objectsin the landscape dictate which script will play, not the chronological order ofthe story. There is an exception though; some events have to happen in aspecific order to make sense, and therefore some scripts can be locked fromentering the game engine until a dependent script has been played. BSP alsoholds some branching interactivity because of the possibility to make choices.This is today restricted to two choices at a time and the choices does only alterthe way in which the goal is reached, not the goal itself. It is also possible for

3.8. Discussion 19

this kind of game to allow superposed interactivity, forcing the player to forexample solve a puzzle or a riddle to get to another level. This is not imple-mented in the prototype today though.

The magic circle of BSP can be defined as scattered across the landscape andthe objects in the vicinity. As a pervasive game, the BSP makes the real worldinto the game arena. By adding sounds of birds in the woods and people talkinginside houses the game embeds the player in the passing landscape making thegame experience real and creating immersion. The player finds the game to beintelligent, as it knows exactly where you are, and magic as it adds an excitingfictional plot. The nature of this game’s magic circle puts a great demand onthe pacing of the events. If nothing happens for a long time the player losesinterest. Viewing the story of the BSP, it is obvious that it is Szilas CoarseGrain Model that is used. The story chunks is relatively large and each shunkholds quite a lot of information. The story chunks are combined in a way thatis dictated by the traveled path, namely in the way objects are appearing. Thismakes it easier to control the branching and the story development, but resultsin the issue of keeping the story chunks small enough to be as independentfrom each other as possible [7].

3.8 Discussion

Interacting with a story is not a trivial task. It is evident that the two con-cepts; interactivity and narrativity conflicts, but the idea of interacting witha story is very exciting and useful in the world of games. The challenge is tocombine those two concepts in a way that makes sense for the viewer/player.As the players involvement in the narrative grows and the game emerges thebranching of the game tree can become infinitely large. The challenge is to findways to control the emergence without compromising the experience.

Characters are mentioned as one important part of an interactive story. Someclaim the need for intelligent actors to create a fulfilling experience for theplayer. The characters should interact with the player and with each other andpreferably emerge. But is it necessary to allow characters to emerge and dothings without the player being a part of it? There can be cases where charac-ters are doing completely uninteresting things such as going to the toilet, forhours. Does this emergence constitute a good game experience?

It is obvious that this kind of stories puts new demands on the author. Thequestion is if a traditional author is the right person for the task or if the per-son authoring these kinds of stories should hold totally di"erent skills? Thisof course depends on what kind of story it is, how much and what kind ofinteractivity there is. The challenge is to create a story that can be dividedinto small parts that could be put together in a di"erent order. This is not


story?

an easy task though; the story chunks must be of appropriate size and holdenough information to bring the story forward, but not too much, so that theycan be combined in di"erent ways. The author becomes more of a director,trying to design and connect pieces of story rather than creating a continuoustail. It is important for the author to establish the game rules that decide howthe user’s actions should impact on the story. When building a story-intensivegame, there is also the question of how much freedom to give the player. Givethe player too little, and he might feel constrained and disconnected from thecharacter he is controlling. Give him too much freedom, and the progressionof the story might lag or stop all together. The story is dependent on both theauthored plot content as well as the player’s choices in the story.

The scattered nature of the magic circle in pervasive games makes it chal-lengeable to create immersion. This fact makes pacing an important part ofpervasive game. To provide the narrative in a satisfying pace is important forkeeping immersion in a scattered game world. If nothing happens for a longtime the player will become bored and lose interest. If events occur to oftenthe player will have a hard time to focus and find the game too hard. One bigchallenge of game design and authoring of interactive narratives is therefore tocreate a satisfying pacing in order to keep the player interested and focused.

The authors of BSP claim that the game provides an arena where the con-flict of interactive narratives actually makes sense. The journey provides thelinearity of a regular story and the game fiction gives the appropriate amountof interactivity to create a believable interactive narrative experience. Theauthoring of a game story for BSP demands a lot of the author, as for allpervasive games. One problem is to map the objects in the landscape to ap-propriate story chunks that can provide a believable plot. One can never knowin what direction the objects appear and this forces the story parts to be asindependent of each other as possible. But how do you create a somewhatlinear plot if no parts can be dependent? The story chunks have to be be-lievable enough, having appropriate length, involve appropriate characters andhold enough clues to take the story forward. There is also the issue of pacing.If no objects appear for a long time there has to be some events that can occurthat is independent of objects. They have to bring the story forward in someway, without being to crucial for the plot development.

3.9 Conclusion

To answer the first question stated in the beginning of this chapter; in orderto create a good interactive narrative we need characters, a ”playground”, ofcourse a player, a game mechanism an last but not least some kind of storythat can be divided into events and put together in random order decided bythe player and/or the game mechanism. We need to decide how much and

3.9. Conclusion 21

which kind of interactivity to allow in the story. The interactivity decides howthe story should be presented to the viewer/player, how big the story chunksshould be. BSP provides a real world connection through the map objects anda story chunk is connected to each object appearing in the vicinity. This consti-tutes the playground, a scattered magic circle. Most interaction occurs at thecharacter level, through the game device and there is some evolvement of themain characters, through the conflict (see chapter 1, Introduction). But theinteractivity does not really alter the game itself, only how the goal is reached.There is some choice, which creates branching interactivity, but the constraintof two choices at a time controls the growth of the game tree. This fact some-what eases the author’s task of creating stories for the game.

Another main conclusion of this study, and the answer to question two, isthat the role of the author is very di"erent when it comes to interactive narra-tive. The author becomes more of a director, who has to, in some way, controlthe story, how it is told, the characters, their evolvement and the pacing, butstill give the player enough freedom of action. The interesting thing is thatthe writer of interactive narratives has to have good knowledge of how to es-tablish rules for combination of story, interactivity and emergence. This is notan easy task, demanding understanding for how the game mechanism worksand insights into the constraints of technology in relation to the real world. Atthe same time, the author has to know how to create an exciting story in ascattered world, combine pieces into a somewhat continuous story developmentand conclusion.

So, how can we help the author in the process of creating interactive nar-ratives? By giving the author tools that can guide him/her in combining thereal world, the story world and the interactivity a lot of weight can be lifted.The tool should have good visual aid and a structure that gives a full scaleoverview of the whole. To decide the interactivity level one can use Szilas mod-els of interactivity; for more extensive interactivity use the fine grain model(see chapter 2.4), if the interactivity is only local, the coarse grain model isenough. It is obvious that BSP uses a coarse grain model in creating the storychunks. They are not small enough to give the player total control of gamedevelopment and the game story is more linear that in other pervasive games.

The tool created for BSP should guide the author in taking the right decisionsfor all those parts mentioned above and give a good overview of the whole. Itshould give visual aid in how to connect the map objects with the fiction, asthat is the most important part of the game.

In the BSP game prototype, a story world, characters and the game mech-anism are provided. What is further looked into in the following chapters isthe building of this story world. How to practically support and aid the authorin his/her creative process, but still guide him or her in some sense, not to


story?

build worlds to vast or too complex to be able to enjoy from the quick and fastinteractions the highway experience has to o"er.

Chapter 4

Content creation for

pervasive game

environments

4.1 Introduction

Is content creation di"erent for pervasive and interactive games than for ”ordi-nary” games? Do we need special tools to create story material for these newtypes of games, or is content still just content? If the answer to this questionis yes, then what new kind of demands are set on these editors? What sepa-rates them from the regular ones? One can ask how time and space is handledwhen the author doesn’t have full control, or how the context of the game iscontrolled, if it even is.

To give some foundation and ground for discussion three di"erent existingeditors for story creation in this field will be introduced and then later com-pared. Also the phenomena of user generated content and modding will bebriefly touched to shed some light on an alternative user of a tool like this.

The questions that this section will try to answer is: How are the editors forinteractive medias structured, and which are the most important parts? Whatconclusions can be drawn from this comparison and taken into account whendesigning for the BSP media?

This section starts with a problem description to explain the common issuesthat these editors are facing then followed by the editorial walk-through. Afterthese three editors has been looked at more closely, a comparison section willhighlight the similarities and main ideas of the editors. Next follows a sectionabout the modding scene that has evolved through players and communities

23

24 Chapter 4. Content creation for pervasive game environments

online, showing another side and another use of these editors. The last sectionties together the chapter by highlighting important findings and state generalguidelines.

4.2 Problem description

One of the main issues when creating a game with interactivity involved isthe quantities of story material that is needed. [14] [15] All di"erent angles andchoices need to be specified and created. It is simple to see that the data foreven a small chapter in a game can grow in exponential rate when the playeris given the possibility of choice, and this can cause the story plot to quicklygrow out of hand and out of sight for the author. The task of creating thismass of data is given another layer of complexity in terms of the story envi-ronment which today usually demands a programmer or a knowledge expertwith experience of the system to be able to encode the content in the logicalrepresentation needed. Further this author should also have a strong artisticside to ensure the creative and capturing side of the story. [16] [15] [14] Peoplelike this are rare to find, and to broaden the path and open up for less code-friendly authors an editor can support and aid in the creation process.

An editor opens the door for a completely new range of game designers andwriters, since the need for coding can in some sense be lifted from the designer,and even gamers can access and create stories of their own, opening the worldof modding to the game communities. [17]. An editor can also make the gamecreation process more e!cient and hence save valuable time and money for thedevelopers.

Interactive dramas is as previously stated quite a new genre, with influencesfrom both the narrative branch, such as literature, theatre and cinema, andthe interactive branch of video games and virtual reality. [16] To be able tounderstand what is needed when creating such a story, the narrative structurediscussed in chapter 3, needs to be understood.

There are quite a few di"erent game editors on the market today. Someare completely game specific such as the editors for Starcraft, Warcraft andNeverwinter Nights [14] while others have been made for interactive dramas;DraMachina, UCreate and Scribe. A third approach exists where the narra-tive logic is created by artificial intelligence with editors such as Facade andIN-TALE. Since the focus of this thesis is the creation of an editor with user in-teractivity, editors in this field are of highest interest. The editors of ”ordinary”games (Starcraft, Warcraft and Neverwinter Nights) are of course interestingin the way they structure information, characters and objects, but the focusfor this part has been on the editors of DraMachina, UCreate and Scribe.

4.3. Editorial walk-through 25

The question to ask is what di"ers these interactive game editors from themore common ”closed world” game editors? One of the main issues is how tohandle the context of the game, and more precise time and space. In ”closeworld” games these parameters are always known to the author, but in aninteractive drama these parameters can change during the play of the gamedepending on choices made of the player, or changes to the real world wherethe game takes place. Another pararmeter of high interest is how the editorshandles triggers. This due to the fact that object triggers are one of the mainfeatures in BSP, and the structuring of this will be a central part of the pro-totype. How does the editors DraMachina, UCreate and Scribe handle theseparameters and the possible change of them? This is what this section of thethesis will cover, whilst at the same time give insight into how the objects andevents can be structured and characters created in the interactive media.

The di"erent layouts and structures of DraMachina, UCreate and Scribe willfirst be discussed in section 4.3 and then later compared in section 4.4. Section4.5 will briefly deal with the concept of user generated content and moddingto emphasize the user of such a tool and section 4.6 will conclude this chapter.

4.3 Editorial walk-through

In this section the editors DraMachina, Scribe and UCreate will be presentedand in section 4.4 compared and dissected. All editors has somewhat di"erentfocus of what’s important in the narrative and this reflects on their GUIs. Thewalk-through of each editor will highlight and emphasize their independentfocuses, and each section will conclude with a short summary.

4.3.1 DraMachina

DraMachina is an authoring tool dedicated to the interactive fiction and thenarrative elements within this genre. It is ”based on a low level analysis of theelements of fiction, bridging a gap between computer science and structuraltheory applied to literature, myth, and storytelling.” [16] The author is giventhe possibility to first create the story’s atomic components and then link thesetogether, or use the provided general background patterns; structures of timeor drama. The need to automatize information exchange between the di"erentactors in the production team is also an identified issue.

The architecture of an interactive fiction is defined as a bidirectional link be-tween the theatre world and the story world where feedback flows in bothdirections; the audience should react to the narrative (emotional feedback) aswell as the story should react on the actions of the audience (action feedback)and the key elements of a tale is identified as places, characters, roles, relation-ships and actions.


Figure 4.1: Architecture of an interactive fiction [16]

The editor is mainly text based and works with several di"erent levels, or ar-chitectures to let the author write the stories in a low constrained approach.This means that the author can work with periods, acts, scenes or actions andthen tie them together by creating relations between them. The metaphor usedto structure all the di"erent elements are the file/directory, and the logical de-scription is based on a structural analysis of both drama and film morphology.The di"erent directories are found at the left side of the interface, figure 4.2,and they are; Author’s directory, where the author can enter his own refer-ence, the Narration directory where acts, periods, dramatic actions and unitsdescription is entered. In the Objects directory and the Scenes directory thedescriptions of the objects and scenes are found. In the Actors directory de-scriptions and elements related to the description of characters are located. Inthe Dialogs directory the dialog edition that is based on protodialog patternsare found. A new way of handling the criteria or rules that is needed in a storyof this kind is by using the virtual director’s cut. The author can create aset of criteria and these are later used in the virtual director’s cut whenever ainteractive fiction is performed. The director’s cut can for instance change themoods of in-game characters and characteristics of a stage when another char-acter enters the room. This simple mechanism can determine directing patternswithout having specific scripts, easing the load of scrips needed to be produced.

One of the main parts of the DraMachina is the psychological description ofthe characters. The psychological part of the editor is based on the trans-actional theory developed by psychologist Eric Berne. Berne defined in histheory strokes, or units of interpersonal recognition, and this serves as the psy-chological core in DraMachina. Each stroke has an impact of either positiveor negative kind and the e"ect and duration of the stroke can di"er in time.The duration can be in the range of seconds to the entire lifetime of the char-


Figure 4.2: Main window of DraMashina

acter and stretch from happiness to traumatism. Other characteristics thatcan be set to an in-game character are speaking and listening focus, comfortzones to other characters and the normal walking speed and natural languageto mention just a few. Lists of actions that each character can perform andtheir ”personal” biography can be created. In this fashion a genuine charactercan be created and given a individual goal to achieve and strive for. Somecharacters can have the same goal while other’s will end up in a conflict andthese goals can only be reached by performing dramatic actions, which resultsin sequences of more simple actions.

Summary

To summarize DraMachina, it can be said that the main focus lies on deepand vivid characters. The interface structure relies on a file/dir metaphor thatregular computer users can understand and recognize, but the main way tocreate a story is still text based which can become quite tedious for the author,filling endless of grey boxes with text. The di"erent directories gives the authorfull control of the story, but it can become hard to get the full overview as thestory grows. To conclude, DraMachinas goal is to create believable and livingcharacters, and hence the timeline and pace of the game isn’t at the highestof focus but instead given to the characters as manuscripts of how to act andbehave in proximity of others.


4.3.2 Scribe

Scribe is a tool still under development for authoring event driven interactivedrama and is created and tested side by side of the Interactive StorytellingArchitecture for Training (ISAT), but Scribe is still designed with the intent ofbeing more general than to work in only this scope. ISAT is a interactive train-ing architecture for combat medic students, taking them through a 3D gameenvironment while requiring soldier and medical duties. The ISAT approachis that “interactive drama techniques can be used to provide more e!ective andengaging training experiences.” [14]

While creating Scribe, the robustness and usability of the editor was stressed.These active duty scenarios were written and developed by “subject matterexperts”, with typically no programming experience hence the logical partsneeded to be represented in a non-programmer context.

Further, Scribe works with map data to create the game world and this putshigh demands on the editor to work with varying and dynamic environments.

Scribe is divided into three di"erent authoring modes; Element Placement,Story Creation and Debugging, and the author is allowed to flip freely betweenthese. A global change in one of them reflects in all of the other a"ected ar-eas, which lowers the manual labour of the author. The Element Placement

Figure 4.3: Element placement in Scribe

mode gives the author the overview of a 2.5D environment map where the au-thor can place element pieces, i.e. the dynamic content that the trainee will


interact with. A element is anything tangible in the game environment thatinteracts with the trainee, and the elements can be divided into three types;objects, points and zones. Objects are visible elements, points invisible coordi-nates that exists in the game environment and zones are invisible rectangularprisms that can be entered by the trainee. In other words the di"erence canbe explained as points and zones allows the author to organize sections andlocations in the game world while objects represents the tangible elements inthe environment of the game. In the Story Creation the storyline is created.

Figure 4.4: Story creation in Scribe

The structure gives the story the main goals and decides what will occur as thestory progresses. The element pieces configurations are used in this stage of thestory creation process. Logical story statements is made from the visual maprepresentation. Interesting is that Scribe allows for event overlapping, whichmeans that an event can occur while another is still executing, changing theenvironment for the first event. An important part of the Story Creation modeis the possibility to change and alter the time and pacing of the game. Theseparameters are of high importance to create immersion and a believable gamefeeling. The di"erent time functions supported are fixed, random and relative.Debugging in the editor is provided for, which allows the author to quickly testthe engine on di"erent possible scenarios, without having to switch betweendi"erent editors or programs. The debugger simulates how the environmentwill act for the trainee, and the trainee is also simulated, allowing the authorto move the trainee around in the environment and see how the game adapts.


Figure 4.5: Timeline in Scribe

SummaryWhat can be said about this editor is that it strives to let non-coders accessthe world of creating stories. The stories created in this editor has a real lifelink and thus puts a lot of stress on the execution of the game, the pacing andimmersion. The interface is quite clean and gives the author a good overview ofthe part he or she is developing, and the overall structure and how the di"erentparts works together can be seen in the Story Creation mode. The debuggingmode is a quick and e"ective way of letting the author see how the story isgoing to unveil in certain contexts and adds another layer of comprehension tothe story.

Scribe has with this tool managed to open up the field of game creation inhigh stressed real environments to non-programmers, and thanks to the time-line and the possibility to overlap events succeeded in creating deep playerimmersion.

4.3.3 UCreate

UCreate is the creative authoring tool that aims to assist in the creation ofinteractive contents for experiencing systems using interactive setups, locationbased services, augmented reality and mixed reality. The main focus has beento design for already existing systems, but to open up these systems to non-programmers and at the same time shortening production time.[15]

Four di"erent editors make up the UCreate and lets the user create elementsand arrange and embed them in the interactive story. The di"erent editors are;the Story Editor, the Stage Editor, the Action Editor and the Input WiringEditor. The Story Editor structures the story and all the elements with theinternal structure of; The Story that is the root node of the drama and han-dles all the elements, input channels and actions. The story includes a storytree, composed of scenes that can be executed in more than one way, creatingdi"erent scenarios. Each Scene is a logical part of the story and represents achapter of the story. There exists both simple scenes and more complex ones,


Figure 4.6: Stage Set in UCreate

where scenes are intertwined. A scenario is a specific way to execute a storyand is a useful way of designing variations of a story. Transition is a conditionbased trigger that moves the story from one scene to another. The descrip-tion of how an content element is presented in the performance and what theelement “does” is called an Action and the group of actions and their connec-tions are called an ActionSet. A StageSet is defined in hierarchical order andis the configuration of content elements for a specific scene. The last element isthe Asset, such as pictures, sounds, animations, and this is the lowest part ofthe story. To cope with all of these di"erent elements, two di"erent views aresupported by the UCreate. The Story-Tree View shows the static structure ofthe story, of all the scenes and the di"erent scenarios. The metaphor used isthe file/directory as seen in figure 4.6. The Scene Graph View shows all thepossible transitions between the scenes, and transitions are grouped into sce-narios, where each scenario is one possible navigation structure for the story.The di"erent transition conditions are defined in the Action Editor. The StageEditor does the layout of each scene and supports 2D, 3D and a mix of themboth. All the elements placed onto this stage is connected through a containerclass with user interaction methods, which will be linked to the Input WiringEditor. In this editor the user can define the exact use of the external devicesin the story. The interface of this editor is quite graphical and it supports dragand drop of the elements onto the stage. Further all the elements and theirrelationships are displayed in various ways. At a first glance on the interfaceit strikes how much information there is presented to the user at once. Allthe di"erent parts of information is however consistently placed and remains


Figure 4.7: Story Tree View in UCreate

Figure 4.8: Scenario View in UCreate

when changing from one view to the next. Some module specific informationis however changed depending on which view is present. To give the user allthis information at once can make the learning threshold quite steep, but when

4.4. Editor Comparison 33

comprehended, this editor is a powerful and e"ective tool.

Summary

To conclude this part about UCreate, it can be stated that the di"erent viewsall manages di"erent main issues in creating an interactive drama. The story-tree view helps to understand the time and pace of the game whilst the scenarioview links the di"erent scenarios together, and the stage view gives the lowestinformation about the scene: what will the player experience in this part of thegame.

4.4 Editor Comparison

In this comparison summary the common qualities and di"erence of the de-scribed editors will be highlighted while trying to answer how the editors man-aged to “close” the open world that an interactive drama conveys. How are theeditors structured and which are the most important parts? How has pacingand time been taken into account and what are the focus on objects, charactersand events?

From looking into these editors it becomes evident that designing for an in-teractive drama brings forth some new challenges and that the interpretationof the design space becomes a leading issue. Depending on what is identifiedas the most important parts; characters in DraMachina, plot in Scribe anddiversity in UCreate, the editor becomes quite di"erent, as can be seen in thesections above. From how these editors are constructed we can see similaritiesthat they all work in modules; there’s one editor mode for elements, one forplot and so on. They have also all identified the importance of time in the in-teractive drama, but handled this in di"erent fashions, from virtual directory’scut to timelines. Nevertheless, despite the di"erent outcome of the interfacesthe main reason for the creation of these editors has all been the same; liftthe coding from the author, allowing the creation of game to become a moreaccessible space for everyone, in some extent even to the players themselves.

The conclusion drawn from this editor exposition is that the main ideas andissues behind are more or less the same, but the outcome and the interface ofthese specific editors di"er quite a bit depending on modular focus, rangingfrom being text input based to a more drag-and-drop fashion where elementsand assets are dropped onto a stage and altered to fit the story.

To give the author overview of the complete story di"erent approaches havebeen taken, but a tree view, more common as a file/directory metaphor hasbeen used in both DraMachina and UCreate to structure the di"erent parts,and a node/mesh schema incorporated in all of them in varying degree. InDraMachina the node view shows the dialog flow while in Scribe and UCreate


shows how the di"erent scenes are combined.

A final conclusion that can be stated is that the field of interactive dramaand hence the editors that comes with it, is such a new area that no generalguidelines have yet to evolve. Looking at some of the general guidelines forgraphical user interfaces it can be found that DraMachina, though mostly re-lying on text input, still uses a widely and recognized file/directory metaphorthat most users are comfortable with. However, to support the artistic andcreative side of the author, there’s still much work to be done.

Scribe is probably the easiest editor to learn and interact with, due to the factthat there is only two modules to use when creating the story. The ElementPlacement where drag-and-drop of elements are supported onto the stage, con-sistent of a map where the story takes place, and the Story Creation where theproperties of these elements are changed and the story flow created. Debuggingis also a major part in giving the author some insight into what is being created.

UCreate is somewhat a more complex version of Scribe, in the sense that UCre-ate supports both drag-and-drop onto a stage consistent of a map, and thatthere is a Scenario View to keep the overview of the di"erent parts available.UCreate doesn’t support a debugging editor, but instead supports the creationof a much more diverse story flow and in many more ways than Scribe andthe soldier training program. However, this amount of possible creation waysstill makes the editor harder to handle and understand, with all the di"erentparameters constantly visible, it can feel intimidating for the novice user.

Finally it can be said that all these editors still contributes to aid and open thefield for the non-programmers, guiding and helping in keeping the memory loadlow and the structures visible. Working in their separate areas, these editorswill contribute and create vivid interactive dramas, possibly widen the worldof user generated content and modding, but a bridging editor for the whole ofinteractive dramas is yet to be found in any of these.

4.5 User generated content and the concept of

Modding scenes

Who will actually use these editors? Is this just an aid for the sole creator ofthe game or can these editors find their way out to a broader public, changingthe way we play and interact with the game even further? In this part the con-cept of user generated content and the phenomena of modding will be discussed.

User generated content is a concept that has been growing rapidly, from thesolitude of basements in the early 60’s to the chat rooms and communities ofthe twentieth century. If the user generated content is based on already exist-

4.6. Conclusion 35

ing material it goes under the classification of modding.

Modding can be explained as “the participatory practice where amateurs modifyand extend commercially released games with their own creations” [17] and is asub-culture that has grown from the early days of the computer era. Ever sincethe first computer game Spacewar from 1962 saw the light of day, computergames and later console games has been modified and tweaked by the players.

The big break through for the modding scene came with the Commodore 64and Apple II computers and the creation of Internet. This opened up the homesof amateur programmers and started communities for peers, giving them thepossibility to learn and discuss the subject of modding. The first modderstweaked the introductory scenes to their own likings, changing the graphicsand sounds and adding personal tags. Adding this personal label to the “hack”gave the programmer respect in the communities that grew over the internet.Stephen Levy explains the hacker code that emerged as: “an urge to get insidethe workings of the thing and make it better”. From this group a sub-genreevolved, called crackers. These programmers didn’t just stop with a changedintroductory scene, they enabled cheats, such as infinitive lives and removedthe copy protection schemes making the game available for everyone.

This growing culture didn’t go the game creators unnoticed by, and the firstgame that embraced the hackers lifestyle and designed for it was Doom, wholeft their “art assets” available for anyone. However, it was up to the moddersthemselves to develop the necessary tools and spread it through the media.This took place in the early 90’s [18] and since then game producers have be-come even more modder-friendly. The games mentioned in the beginning ofthis chapter, the Neverwinter Nights, Starcraft and Warcraft are just a few.Modding-tools are now bundled to the o!cial games of more or less all games.In 2002, more than one third of the developers provided these tools, and withthe XBOX 360 console it is possible to share ones creations directly over theInternet. However, all is not only well and good within this process. A com-pletely new level of Doom could be created in maybe a couple of hours by adecent programmer, but with today’s level of complexity it can take weeks oreven months. User generated content, however exists in all level of complexityand levels, it’s the modder that sets the standards and rules of the modification.

4.6 Conclusion

So what can be said from all of this? Is content just still content in the contextof interactivity and pervasive gaming? Do we need tools to create?

From what has been discussed in this chapter it is clear to see that the conceptof user generated content in all forms are here to stay. The internet with its


chat rooms and communities makes the spread of knowledge and collaborationeasier, but when looking at the specific needs of pervasive or interactive gamessome sort of aid is to be preferred because of the extensive amount of data thatneeds to be generated and controlled. Useful traits in such and aid is discussedin section 4.4: Editor Comparison, but the main concept of the editors of todayis to open up the field for non-programmers, giving them the means to createstories without having to worry about syntax and code. This is today done bygame specific modulated editors with drag-and-drop features and structuredoverviews, but where the future will take this newly developed field is yet tobe seen. Since the field is still rapidly evolving no general GUI guidelines hasemerged, but looking at these editors and what they have created some state-ments can be made.

When designing an editor for interactive media:

– Visualize the story and how the di"erent parts are connected. (node/mesh)

– Use common and widely accepted ways of structuring the data (fil/dir-metaphor)

– For more novice users or maybe gamers, use a more graphical program-ming scheme (drag-and-drop) rather than straight coding to avoid syntaxerrors

– The editor should strive to only show the parameters that are importantat that stage, to much information on screen can intimidate the noviceuser and raise the learning threshold

– Time and pacing is of high importance in this kind of media. The editorshould support a visual way of tweaking and changing the trigger and/oro"set of the events

These conclusion are drawn from the previous walk-through with a novice userin mind, based on the activities and the wide spread of modding discussedin the previous section. An editor of this kind would serve the purpose at agaming company as well as in the homes of the gamer, spreading the gameand probably enhancing the game’s value due to a higher activity and a biggerarena. More advanced features and a higher level of coding for the expert usercan be achieved in other versions of the editor, but these main features shouldbe supported in all levels and will be taken into account when designing theGUI of the BSP editor.

Chapter 5

The project

In this chapter the project of building the BSP Story Editor will be describedin detail. It is divided in three main parts describing the pre-study, the designprocess and the final result. The pre-study goes into the issues of BSP anddescribes the technical structure of the game. The main user is analyzed andthe requirement specification that lies as a ground for developing the editoris established. The design process chapter focuses on how the practical workof developing the editor is conducted, showing sketches, describing discussionsand decisions made at the workshops. The result part is a chapter about thefinal prototype; the choices made and detailed description of the GUI.

5.1 The pre-study

A big part of this project is the initial pre-study. As this is a fairly new area ofgame research one have to understand the main issues of the overall concept ofpervasive games and the specifics of the BSP. To gain knowledge of the mainarea an extensive literature study has been conducted. The specifics of BSPhas been studied both through practical exploration of the prototype and byinterviewing the team behind the concept. As it is only a prototype there isno information about the game outside of the Interactive Institute. To getinspiration and further understanding of how these kinds of tools work someother existing editors were briefly studied. Editors for interactive gaming werestudied more deeply and a walk-through of these can be found in chapter 4.

5.1.1 Interviewing the team

To get insight into the process of building BSP and what was needed from theeditor, deep interviews were conducted with the team. The team consists offour researchers that are or have been involved in the research project. Eachand every one of them had a di"erent approach to the concept of game cre-ation and had unique demands on the final result. It was therefore important

37

38 Chapter 5. The project

to get insights into each person’s experience to get a full understanding of theconcept, the project and the expectations.

The interviews were designed to be semi structured, which is the best wayif the intent is to capture experience and opinions [19]. A number of questions[Appendix A] were used as a starting point for the discussion, but the subjectswere encouraged to speak freely about their thoughts. One of the purposes ofthis project was to “get it all out of the head” quoting one of the team mem-bers. The interview was recorded and later transcribed to capture as muchinformation as possible. This part of the BSP exploration gave great insightin what was wanted of the editor and where the ideas came from. It also gavesome understanding of what game design process had been used and preferredby the team.

5.1.2 The result of the interviews

The BSP prototype showed to be a very immature concept, still evolving. Eachperson interviewed had his or her own idea of how the prototype should con-tinue to evolve. Some of the things mentioned were character development,Internet communities, and di"erent types of game stories, custom made forlong and short travels and commuting. Another idea for the future of BSPwas to let the players create their own game stories and modify the existingones to fit their own needs. The team talked about adding weather conditions,landscape structures i. e. di"erent kinds of trees, buildings, deserts etc. de-pending on where in the world the game takes place. Also ideas about addingsensors for determining the time of day, if it is dark or light, and make thestory adaptable to these kind of parameters was discussed. The idea of aneditor was one important step towards the future of the game concept, as abig help for generating the large story content needed. It was the generationof story itself that was the key issue in development of the prototype and thebiggest problem. As the team sat down with the task of building a believablestory for the medium they encountered some problems. To quote one of thesubjects ”I felt literally physically sick, we had to force the story out of ourheads”. The great amount of possibilities and the di!culty to overlook andgrasp the whole picture made it hard to come up with an appropriate story.The team had some disputes about where to put the focus and what to startwith, some argued the characters were the most important part and wantedto build stories around them and others argued the objects to be the mostimportant. The story that eventually evolved was an agent story with a super-natural twist, involving werewolves, murder and robbery. The most interestingpart of this story is the conflict between the two bosses where it, as the storyprogresses, becomes evident that one of them is somehow involved in the crimes.

One of the problems with this game medium is that the intervals in whichthe game interacts with the player are short. The car is often traveling in high

5.1. The pre-study 39

speeds making it important to keep the story parts around physical objectsoutside the car short not to block other events from happening. The story hasto evolve through these short encounters which have to hold enough informa-tion and excitement for the player to not lose interest. Another related problemis pacing. As the landscape is uneven in object rate there can be great partsof the journey where no objects of interest triggers actions to happen. Thesegaps must be filled with story parts independent of location to bring the storyforward and keep the player alert and focused.

Another problem the team was facing during the development of the storywas the di!culty to be in an o!ce environment trying to create somethingthat should work on the outside, along a traveled path. To get around thisobstacle the team moved out to the island of Lidingo and drove around forsome time to get inspiration and ideas of di"erent scenarios. This method gavea good feedback on how the story would evolve but it made the story to tiedto that specific place. The issue that arose was to be able to build a gameonly around the map objects that can be general enough to fit most roadswithout losing the connection to the real world. Other problems concernedthe believability of environments and characters, making a whole of the smallparts, sequentiality, rewards and keeping the player focused on the purposeand overview of the design process. Among other technical issues the problemwith keeping score of all variables was mentioned. As the game is built up byhand, with hand written python scripts it is not easy to alter and debug. Ifone variable is changed, all other dependent variables needs to be found andchanged by hand, otherwise the game will fail.

An editor could solve or at least ease all of these problems making the cre-ation of game story more or less automated or at least guided.

5.1.3 Exploring the game world of BSP

To understand the technical parts of the game prototype a study of the under-lying structure was studied. A short game script was created and then testedin a simulation environment. The existing scripts were studied and discussed,broken down into pieces and reassembled. The story engine’s API was broughtinto light and explained and then a new part, The Head Quarter Scenario wascreated.

The creation of this part gave the study important insights of the workingsof both the software, i.e. the game engine and the text-to-speech synthesis andthe hardware like the directional microphone and the gyro. The analysis alsogave valuable insights of the API of the game engine, which parameters thatneeded to be set by the user and which could be more or less automaticallygenerated.


Further information about the technical issues of the game was explored bya practical study.

5.1.4 The details of the game technology

The experience that the game provides is mainly sound based. The player seesthe outside landscape and hears sounds in his/her headphones. To avoid splitattention the graphics of the game is limited. The player is not supposed to lookat the game device; he/she should rather listen and explore the outside view.The sounds can be categorized in di"erent groups; ambient sounds a.k.a. 3Dsounds, communication sounds and tracking sounds. Ambient sounds are usedto create a presence in the landscape. These are sounds of birds singing, dogsbarking, people talking etc. and they are all implemented with the Doppler Ef-fect to enhance the realistic feeling. The communication sounds are the phoneringing or the walkie talkie sound. This makes the player focus on the hardwareand initiates an interaction with one of the in-game characters. The charactersare also sounds; synthetic voices that tells or asks the player what to do andin that way bringing the story forward. Tracking sounds are mainly 3D soundsthat, if captured, can trigger some scenario. These can for example be a phoneringing and if tracked by the player’s game device can trigger a phone con-versation between two robbers for the player to overhear. These conversationsoften holds some clues of information to the story development that can be ofuse later.

The game story consists of several scripts written in python code. The gameengine uses the scripts to create a story around the travel path. The travelpath is defined by a digital map and GPS positioning. The digital map pro-vides the game engine with objects such as houses, churches, lakes, bridges andso on. When the car passes a building or crosses a bridge or is in proximity of alake a so called journey event occurs. These events are used as triggers for thedi"erent scripts. When a script is triggered a game event occurs. Every scripthas a self rating mechanism that decides how important the part is accordingto how rare the triggering journey event is.

A script consists of one or more parts. Every part plays a piece of the mainstory. A part can be local, as to say, tied to a journey event, or global whichmeans no connection to the real world. The global events are important tofill in the gaps between journey events and adds a satisfactory pacing to thegame. Global events are often follow-ups to some local events, but they donot necessary play directly after the connected local event. When a script istriggered it runs until the end of the actual part and if there are more than onepart and parts are independent of each other the next part rates itself againgiving other scripts the chance to intervene. When a game event occurs it locksthe game to this specific script so that no other script can intervene.

5.1. The pre-study 41

A game event can consist of x di"erent player interactions consisting of ei-ther a phone call, walkie talkie call, tracking sound or a report. The phonecalls are from the headquarter and are the communication channel between theplayer and the two executives, Ulf and Helena. There’s a twist to the storysince Ulf and Helena are conflicting characters; if you are listening to Helena’sadvice Ulf will get angry and vice versa. This conflict gives the player a moreactive role of gaming and enhances the gaming experience, whose advice ororders will be followed? The walkie talkie calls are the communication withagents out in the field. The agent characters are not specified as strongly asUlf and Helena and have quite anonymous names. This is done to make thestory more believable. If a very specific character is checking out things in thebeginning of the journey, the player might not find it very believable that sameagent is out in the field miles away from the first position. This can disturbthe immersion which is very important in this kind of game. A tracking soundis a sound that the player hears and can track with the device. If the sound istracked a story part is triggered. It might be an overhearing of a phone call oreaves dropping on someone in a house. These sounds often hold some clues tothe mystery that can be of value when sending out agents to investigate, forexample, a crime place. The report is not as much an interaction as a follow-up, mostly after a phone call from Helena. When the chain of interactions iscomplete and the end of a script has been reached, the engine removes thescript from the queue allowing other scripts to continue the story development.As mentioned before scripts can be dependent on other scripts or script parts.If a script is dependent it is specified in the script code itself and the script willtrigger only if the script it is dependent on has been executed and terminated.This is important when a branching of the story occurs, as certain events causedi"erent outcomes. It may also be that some parts of the story have to occurin a specific order for the s story to be believable.

Another important part of the game experience is the soundscape. It is in-dependent of the scenario scripts and how the story is evolving, but it is ofgreat importance for creating the feeling that it is for real. The sound scapeconsists mainly of ambient sounds i. e. birds singing, wolves howling in theforest, people talking in houses etc. The soundscape runs in parallel with theother game scripts and it places so called 3D sounds at objects along the travelpath to create a more immerse experience.

The story of this game is quite simple compared to classic pervasive games.The big di"erence between BSP and other games in this genre is the way inwhich it connects to the real world. The locations are not fixed and you cannever exactly know what objects that will appear along the path. The designerhas to create believable story content around the objects that the outside worldprovides. There are therefore a conflict between the general and the specific.When building the game it would be preferable to generalize as much as pos-sible, but the generalization takes away the feeling of immersion. If the game


knows exactly what building you are passing the player can get a more realexperience. The focus of this game is not emergence nor is it realistic evolvingcharacters. The focus of BSP is the connection between fiction and the outsideenvironment. As a car travels along a road the scenery outside the windowunveils a sequential story that is used as a base for the fictional story to givethe traveler an enhanced travel experience. The story of BSP does not branchas much as other pervasive games, which often can be branched to infinity de-pending on how the characters evolve and how the player acts. BSP gives theplayer some choices in which direction the story can go, but it does not a"ectthe outcome of the story, it only alters in what way the goal is reached.

5.2 Results of the pre-study

After interviewing the development team some main issues became clear. Thedi!culty to overlook and structure the story building process was one bigproblem they had encountered. An easy way to cooperate cross professionswas another thing they wished for. They also needed a starting point forfurther discussion about how to develop the concept, as it has great potentialto evolve into something bigger and possibly something commercial. It becameevident that this is a very young process. There were a lot of visions aboutwhat it could become and a lot of ideas of how an editor could help developthe concept.

5.2.1 Editorial scope

The new way of combining classical storytelling and user interaction puts newdemands on the writer or game designer. In order to create an exciting perva-sive game one have to generate a great amount of story content. This calls forgood programming skills combined with good authoring skills, a combinationnot so common. An editor can therefore be a helpful tool if it provides a rel-atively easy interface that holds a number of components for creation of thesekind of stories. It has to provide graphical representations of key componentssuch as characters, places, connections and give a good overview of the storythat is created. A tool like this would not only ease the workload and save timeand money, but it would also build a bridge between professions; programmers,designers and writers. It would be easier for di"erent people to cooperate andcreate a story together. It could also create conventions, a kind of standard-ization of the vocabulary and design methods, which could be favourable froma commercial point of view.

There are of course some editors already made for this purpose, but since BSPhas very special demands they cannot completely fulfil the needs. The toolsthat now exist are either too specific or too general to be used for creation ofstory content for BSP. The BSP has very specific demands on the story creation

5.2. Results of the pre-study 43

Figure 5.1: The scope of BSP game editor

as it is built up by objects that appear along the road. It is very importantto keep in mind; first comes the object; then a piece of story content is ap-plied on the object. Other editors, for example UCreate, see chapter 4, relieson the fact that you know your exact position which makes it a lot easier tovisualize a story line relatively the environment and give the designer a goodoverview. In BSP this is not possible as you never know exactly where thecar is going and which objects that will appear along the way. One could ofcourse build a game story specifically for one route, go out there and see forhim/herself what objects that will appear, but it would make the game toospecific and constrained, both for the player and the creator and it would ofcourse take too much time to do that for all possible routes. The main ideaof BSP, and the thing that makes the game ”smart” is the feeling that thegame knows where you are and uses the objects in your close environment tocreate a believable environment [20], regardless of where you are driving. Thisfacts demand that the editor can make an appropriate generalization; it shouldprovide some information about the environment and the objects it contains,but not too much. There is a constant conflict between the general and thespecific. The more specific the story is the more believable it gets, and themore constrained. The question is where to draw the line.

5.2.2 The potential users

There are a number of di"erent user categories included because of the com-plexity of creating such a game. There are often several professions workingalongside to create a meaningful gaming experience and the editor should sup-port this workflow.

The ideal user is familiar with coding and the process of authoring. He/she


knows what an interactive narrative is and how to combine pieces to make agood game story. He/she knows the constraints and the di!culties that can beencountered in the technology and has a creative side when it comes to story-telling. The user is not familiar with the terminology and the specifics of BSP.There are of course very few users that have all of these qualities. Thereforethe main user can be divided into following categories:

The programmer:+ Knows the technology+ Knows coding+ Has a logical point of view and sense for rules- Is not familiar with authoring strategies and storytelling- Is not familiar with the specifics of BSP

The author:+ Knows how to write a story+ Creative in a more artful fashion- Does not have the deeper understanding of the technology- Is not a programmer- Is not familiar with the specifics of BSP

The game designer:+ Knows interactive narratives+ Creative+ Understands the technology on a more superficial level- Lacks the deeper understanding for both the technology and authoring- Is not familiar with the specifics of BSP

The player (user generated content):+ Has a great interest in the game and knows the specifics and the terminology of it+ Has an insight into the story world of the specific game- Uneven programming skills+/- Wants to create more location specific games

5.2.3 Closed and semi-closed editors

To to get inspiration and a deeper understanding of what a content creationtool could do, some of the already existing ”regular” game editors out on themarket were analysed. Despite the fact that these editors all work in a ”closed”world, i.e. the author knows the game world and its limitations, valuable lessonscan be learned. They all have a function of building a game world and mediatea feeling of immersion to the player. The user group is also the same; gamedesigners or gamers, more or less familiar to coding, but with a strong interestof creating a great game.

5.2. Results of the pre-study 45

Another game editor; the Game Creator, created at IPerG, SICS was lookedat more closely. The similarities of this editor and the one needed for the BSPare the fact that the ”playground” for both games are out in the real world.The Game Creator, however is more of a orchestrating tool for live role play.

5.2.4 General Requirements

The interviews together with the technical walkthrough gave the project agood picture of what was needed in the content creation tool for it to fulfill itspurpose. A requirement specification was established as a structured base forthe design process [Appendix B], and the specification is divided into generaldemands, necessary functions and wanted functions. The general demands de-scribes the main purpose of the editor, the necessary functions defines whatwill be the main functionality of the prototype and the wanted functions areto be implemented if there is time or as a guide for future development of theeditor. The main parts of the requirements will be presented below, dividedinto Basic, BSP-specific and Visual, and then further discussed part by part.

The editor is the part of the game that creates the scripts that is used bythe game engine. The scope of the editor is visualized in figure 5.1. It shouldprovide an appropriate object representation that is not too specific nor toogeneral. The designer should be able to use the editor both at the o!ce butalso on location. It should be mainly graphic and give good overviews andprovide relevant short cuts. The editor should support the creative process ofgame design, but at the same time constrain the user in the creation of storycontent. It should guide the user rather than giving him/her free hands. Itshould give the user an overview of the work flow, the story and communicatethe functions that are supported. The main purpose is to provide fast andcheap content creation. The section below lists some of the requirements es-tablished in the process, see transcripts of the interviews for reference and thefull requirement specification for details [Appendix A and B].

GUI Requirements

GUI appearance:

- User friendly- Neutral color and form scheme- Efficient use- Cluster similar information- Use commonly accepted terms and metaphores


Functional Requirements

Basic - the basic features that needs to be supported:

- Dialog input- Chapters- Scenarios- Structure- Creation and adding of characters- Creation and customization of a soundscape- Support of manual editing

BSP-specific:- Pace- Analyze the map and the objects- Trigg the scenes on graphical objects, collected from a geographical db.- Create global events- Create local events- Support simulation

Visual:- Graphic- Overview- Drag-and-drop- Code-view- Short cuts- Help definitions of symbols and names

The basic features that need to be supported are the main parts to build thegame. It is evident that the game creator somehow needs to create charactersand sounds, add dialog to them, build scenarios and structure them in somefashion.

The specific problem this editor needs to solve is to connect these scenarios tographical objects, what that means is to trigger them to happenings in the realworld. These events, connected to specific graphical objects, are henceforthknown as local events. Global events are events not triggered by a specificgraphical object but instead triggered by time or some other action. Theseevents are what can help build much needed pacing in the game.

As mentioned before the main user for this editor is not the coder, nor ishe the writer but someone in-between. The editor should therefore be of moregraphical fashion and preferably support drag-and-drop features to enable cre-ation of content in a fast manner. However, a code-view can let the more code

5.3. The design process 47

friendly creator to tweak the code and create new, not supported parts.

The support the developers lacked was a way to connect the di"erent scenariosand parts to each other, and to let the creator know where he/she was in thestory flow. A good overview of the parts, scenes and scenarios was evidentlyneeded.

Since the projects depth grew with every meeting, exceeding the time pos-sible for this thesis, the focus got shifted from creating a working editor withpython code output to create a graphical user interface, with focus on the mainfeatures of creating the game. The existing idea of an agent game was usedas the foundation for the interface and the goal was to support replication ofthe existing scripts with script dependences and a good overview for the cre-ator. The interface is designed around the existing in-game-devices; the mobilephone, the walkie-talkie and the report. It supports the concepts of global andlocal events, triggers, handles pacing and the soundscape needed in the game.

5.3 The design process

The project mainly supports the classic iterative design process, with a pre-study, brainstorming, sketching, designing, testing/workshops and redesigning.As the project team was constrained to conduct the whole creative process in-side the Interactive Institute, some parts of the iteration was somewhat altered.One important part of the process, that was not done, is testing of the finishedprototype. This is of course something that has to be done in order to furtherdevelop the idea. The testing in this project lays in the workshop activitieswhere sketches and lo-fi prototypes were presented to the team, discussed andre-designed. In this section the design process will be presented, with earlysketches, inspirational mood boards and the workshop results. A flowchart ofthe editors basic functions can be seen in figure 5.7.

5.3.1 Sketches

Some sketches were made to get the concepts and ideas ”on paper” in a quickand easy manner. All from scribbles to more diverse sketches and models werecreated and discussed around. Figures 5.2 and 5.3

5.3.2 Mood board

To look at the problem from another angle and to get influence and ideas fromother areas than the computer/GUI scene while searching for a good repre-sentation of the editors ”look and feel” and general GUI, a day in Stockholmwas spent by visiting interior design- and furniture shops and drinking co"eeat urban cafes. The outcome of this day was the mood board seen in figure 5.4


Figure 5.2: Early sketches and ideas (1)

Figure 5.3: Early sketches and ideas (2)

5.3.3 Workshops

Throughout the project workshops and discussions has been a vital part. Somediscussions involved parts of the BSP team whilst others involved all members.


Figure 5.4: Inspiration gathered at local design and furniture shops in Stock-holm. ”How can the menu structuring issue be solved?”

Sketches and ideas were discussed, questions answered and a final approachfound.

5.3.4 Lo-fi prototypes

As can be seen in the pictures, the idea of multiple windows and some kindof visual programming layout was the main inspiration. The grouping of ob-jects in di"erent categories, map objects, device interaction etc, was also an


idea that was withheld throughout the whole process. Inspiration was gatheredfrom other game editors and programming environments. That inspiration wasa good guide in creating prototypes, keeping the layout ideas realistic and func-tion centered instead of ”beautifully designed but non-functional”.

The prototyping faze started out with a mind map sketch of the whole sys-tem and all relationships inside, figure 5.7. After defining all needed functions,some layout sketches were made in Adobe Illustrator as a kind of brainstorm-ing, see figures 5.5 and 5.6. The idea of making a sketch-brainstorming is toget all ideas out and not get stuck with the ”darlings”. That is why di"erentcolors were used and some alternative layouts were drawn.

Some of the sketches resulted in the lo-fidelity prototypes shown in the picturesbelow. Each prototype layout was then printed on paper before a workshop,”played with” and discussed with the developer team. After each workshop,as the scope grew and functions were altered, some changes were made andfurther evaluated in an iterative manner. The developer team found it easierto discuss and understand the process when they could see graphical sketchesinstead of mind maps and ru" sketched ideas. Figures 5.5 and 5.6 shows agroup of prototypes made by the project team members. The main focus wassymbols, bright colors and a somewhat childish look.

The visualization of story flow as a flow chart was a quite early idea basedon the developers team own documentations of the story parts. They usedthe flowchart as a symbol for how the story evolved and how the game treecould grow according to player choice. The project team found it to be theeasiest and most usable visual metaphor for story development. This was alsodiscussed throughout the whole process and was finally found as the best wayto visualize BSP story content.

The main focus of the prototypes was the visualization of triggers, as this wasthe most important and the most tricky part. The discussion was neverendingconcerning how the map objects should be categorized, visualized and com-bined with story events. After going through totally 5 workshops, the projectteam had a quite good understanding of how to move on. From the early lo-fi prototypes two layouts were chosen, evaluated and finally merged into one.This final layout was then implemented as a hi-fi prototype described in thechapter below.


Figure 5.5: Various ideas and lo-fi’s of interfaces (1)


Figure 5.6: Various ideas and lo-fi’s of interfaces (2)


Start menu

New storySaved storiesTutorial

Theme TemplateGIS-objects

Location:

Object list

Create event

Save event

Lidingö

Church

. . . .

Type of travel

CommuteLong distance

Agent

NameIntroNew scenario/New chapterCharactersSoundsAssetsObjects

New scenario

NameTriggers on:DependenciesCharactersSoundsAssetsObjectsNew eventSaved events

. . . .

Objects

Time

Distance

Characters:

PictureVoiceMoodOccupation

RelationshipFamily-treeHistory

Create new

Sounds

ObjectsSounds

TvHouse

Upload new: Browse

Loop timesPriorityTrack

. . . .

. . . .

Assets:

Create new

PictureSound

. .

Phone. . . .

Ulf . . . .StructuresPhoneWalkieRaport

CharactersSoundsAssetsObjects

Story view

ChapterNameDependenciesNew scenario

PhoneWalkie-talkieReport

IncommingOutgoing

From:

1: Answer:

2: Ignore

Ulf . . . .

To:

1: Answer:

2: Answer:

Ulf . . . .

IncommingOutgoing

From: Ulf . . . .

To:

1: Answer:

2: Answer:

Ulf . . . .

1: Answer:

2: Answer:

Activate player choice

From: Ulf . . . .

Map structure

Figure 5.7: Flow chart of the editors functions

Chapter 6

The final result - The BSP

game editor prototype

The final result of this project is a semi functional prototype that shows themain functionality of the GUI for the future editor. The prototype is con-structed in Adobe Flash with ActionScript 3.0. The focus of the prototype liesin the graphical representation of objects, story building and overview. It isnot a functioning story editor in the sense that it creates python scripts and ithas only limited functionality showing in the GUI. Due to shortage of time andresources the focus lies on the main work area, overviews and object group-ing. It is possible though, with some further development, to create XML filesand translate them into python scripts or create text files with python code.This chapter will explain the di"erent parts of the GUI, the ideas behind themand the technical solutions in more detail. During the design process of thisinterface the guidelines concluding chapter 4 has been taken into account andworked as a base for discussions. In the last part a scenario will show how theeditor can be used in a more concrete way.

6.1 Main structure

To create the vivid and engaging game world gamers strive for, giving theman emerging game experience it requires a high amount of information. Theidea of an editor is to give the author a tool to structure and handle all thisdata, and an important piece in this is the overview and internal structure ofall parts of the story as discussed in the previous chapter.

When creating the BSP game editor inspiration was gathered from both editorswith graphical representations and several di"erent games with special featureslike building and managing teams or worlds. Influences of how to handle thegreat amount of data can also be drawn from film and television where the story

55

56 Chapter 6. The final result - The BSP game editor prototype

evolves in a linear fashion to a set of predefined states [21]. Even though thismodel does not suit this editor completely, it is a good metaphor of how youcan support parts of the linearity of the BSP story. An important inspirationsource was the documentation of the existing BSP story where the scenarioswere represented by flowcharts. This representation became the natural choisefor the scenario visualization in the editor prototype.

The creation of a story for BSP can in some manner be compared with graph-ical programming where you drag and drop objects and create conditions forthose objects. In BSP you create events around map objects. The graphicalobject is the primary entry and then a game event i.e. sound or an interactionis applied on the object. Looking at other game editors and well known de-veloping environments and graphical editors some general conclusions can bedrawn. They all work with the ”multiple windows” view. This means that toolsand objects are grouped and placed in sometimes movable windows around themain work area, which often lies in the middle of the screen. The objects havea drag and drop function and the ”story” is built up in the middle, in the mainwork area. Tree structures are used to give a hint of where in the process theuser is and time lines represent the evolvement of the project. Another goodfeature of ”graphical programming” is the drag and drop function where theuser drags objects into the work area and establishing conditions. The user canalso switch to a code view and edit the code directly. A common representationfound in most of these programmes is the tab structure, where one tab is hold-ing one part of the project. This is a common representation in the computerworld, using the known metaphor of how documents are structured in an o!ce.

One big problem in creating stories like these is to get a good overview both ofthe parts and the whole. Therefore several hours of discussions have been spenton creating good overviews in the editor. Tree structure, tabs, nodes with linksand flowcharts are used to give a representative picture of the story. Every partof the editor will be explained in more detail and discussed from a theoreticpoint of view in the subchapters below. The last sub chapter discusses somedesign guidelines that have been used in the development of the editor.

6.1.1 Disposition

This section describes the main layout of the GUI, the overviews, tab structureand the main work area. Some parts of the text will refer to pictures below.The map objects are categorized and grouped in a bar at the top of the screentogether with the di"erent interaction assets such as phone, walkie-talkie andsounds, figures 6.1 and 6.3. The di"erent scenarios are represented by hori-zontal tabs and the di"erent configuration views by the vertical tabs to theright of the work area. Everything happens in the middle of the screen, alsocalled ”the main work area”. This area consists of the active tab and everytime a tab is clicked the area changes to hold the information of that tab. The

6.1. Main structure 57

Figure 6.1: The BSP game editor, main view

horizontal tabs can be closed and removed, while the vertical are static. Thetree structure shows chapters and scenarios and lies to left on the screen. Thenode overview, showing the scenarios and the internal relationships betweenthem, lies in the right top corner of the screen. These positions are chosen tocreate symmetry in the layout and to give a fast overview. Research has proventhat when a user looks at the screen he/she looks at the top right corner first,and because of this it is good to place important things. [22] In interfaces thatcontain a tree structure, the structure, in most cases, is positioned to the left ofthe main work area and we chose not to argue with that standard as the ideais to give fast access to the functionality of the game and provide fast creationof story content. Some learning threshold is accepted but it should not be toohard to understand, and that is why familiar metaphors and to the user groupknown dispositions are used. To get deeper insights into the di"erent partsof the editor such as the overviews, objects, the drag and drop and aestheticdesign choices these parts are discussed below.


6.1.2 Overview

The pre-study showed there was a problem with grasping the amount of infor-mation that can arise when dealing with story creation in the BSP medium.To get an overlook and fast feedback on what the user are doing and wherein the process he/she is the editor provides three di"erent overviews; chap-ter overview, scenario overview and story overview, see figure 6.2 below. The

Figure 6.2: The di"erent overviews

chapter overview is to the left on the screen and has the structure of a file tree.This is a well known and adopted metaphor for navigating through di"erentparts of a system and was therefore chosen as a representation of the chapterstructure in the editor. The scenario overview, also functioning as the mainwork area, is representing the story parts, scenarios. Each scenario is built upby drag and drop and instantly appearing at the stage in a flow chart. The flowchart metaphor is used because it showed to be the most familiar representa-tion of story among the development team. They also used the flow chart torepresent the existing story of the game on paper. The overall story overviewis represented by nodes and links. Each node is a scenario and if there is a linkbetween two nodes it means that there is a dependence between them. Themain work area is represented by a file structure with tabs. The aim is to usewell known metaphors and graphical representations.


6.1.3 The Menu bar

At the top of the screen there is a horizontal menu bar, figure 6.3. The menubar is the main toolbox of the editor as it holds the objects needed to build upa story. It is divided into four parts; Digital map interaction, Help Functions,Hardware interaction and Assets. To the left in the menu bar the Digital map

Figure 6.3: The menu bar

interaction symbols are located, figure 6.3 (1). This is a list of category symbolsholding the trigger objects. All objects are categorized according to the clas-sifications of the Geographical Information System (GIS) Database used whenimplementing the BSP. The categories presented in this version are; Build-ings, Points of Interest, Grounds, Communications, Woods and Waters, andthe symbols are inspired by the existing agent story with a church to representPoint of Interest and a golf course to represent Grounds. The next section (2)is called Help Functions and holds three symbols; the Label, the Globe and theSleep function, figure 6.11, label 13 to 15. The Label is for parts that need tobe separated by name. The Globe is to start global events and trigger on timeand the Sleep function is to give the game the right pace and feeling to it. TheHardware interaction symbols, figure 6.3 (3) represent the interaction devices;Phone, Walkie-talkie, Report and Radio and the last section is the Assets (4).Here the user finds the Sounds and Text-to-Speech functions. The Sounds canbe used both in the main work area and inside one of the Game Events andthe Text-to-Speech is to give the in-game characters their voice. All the menuitems are dragable, and the user selects the preferred object and drags it onstage to the work area. When dropped onto the stage, the item expands andgives the game designer an inner work area to change accordingly to his or herwishes.

6.1.4 The objects

As mentioned above, the di"erent game scenarios can trigger either on localobjects in the vicinity of the car, or by global events such as time or a decisionmade by the player. It’s time to take a closer look at these local objects. Howare they identified, and how can the game know what will appear in front of thecar? As described in the pre-study chapter, the game itself gets informationabout upcoming objects through a map database. An algorithm calculates


Figure 6.4: Label 1: The object selector for Group Waters. Label 2: The”trigger action selector” extracted

Figure 6.5: Label 3: Group selector after the initial trigger object Sea has beenselected. Now other objects can be added and o"sets of time or distance canbe set. Label 4: The selected trigger object at priority slot 1


Figure 6.6: Label 5: Another trigger object Creek is added at priority slot 2

where the car is and at what speed it is traveling, and then feeds the enginewith upcoming objects. Several scripts are active at the same time, waitingfor a good match. Scenarios have an internal rating of how rare the triggerobject are and how ”important” the specific scene are. To give the scenariosa higher chance of execution, the engine, as it is built now, supports up tonine di"erent trigger objects in three di"erent priorities. The more time thatpasses by, the more priority groups are available, and by this more objectsare accepted as triggers. To visually support this process in the editor theobjects that are provided by the map database are grouped in the six di"erentgroups mentioned above. Each object group is represented by an appropriatesymbol in the menu bar and the symbols have a drag and drop function. Thecategorization have been made according to the existing map database, and isstatic in this version of the prototype, but it should of course be made possibleto add more categories to the list and customize the existing categories. Eachgroup holds a list of all map objects included in it, see figure 6.4, label 1. Foran object to become a journey event in the game it has to be in some wayput in relation to the car. It is defined by actions such as passing, entering,leaving, crossing and in proximity of, figure 6.4, label 2. These parametersare set at the same time as a specific object is chosen. To further handle thescenario trigger, o"sets of time and distance is available to fine tune the trigger


moments. This means that the trigger action can happen before or after theactual moment of passing, crossing, entering or leaving. For example, if youwant something to happen inside the forest you have to set the journey eventto entering or leaving and the distance o"set to either xx meters after enteringor xx meters before leaving. When dropped at the work area, the group symbolexpands a window holding a list of all objects included in that category. Thedesigner chooses one object, sets the o"sets (entering, leaving etc.) and clicksOK. This action opens up a window with slots of three by three, where eachvertical line is a priority group. This outline gives three priority groups of threeobject slots each with the first chosen item already placed in the first slot ofpriority one, figure 6.5, label 4. Here the o"set values of time or distance canbe set and altered, figure 6.5, label 3. The designer can then drag other objectsfrom the object list and drop them in the appropriate slots, figure 6.6, label5. To remove any of the selected objects, the item is simply dragged from itsslot and dropped outside of the slots, and this will make the object disappear.After this process is complete and all parameters are set the object is placed atthe work area/active scenario tab and a square around it appears. This squareframes the object and makes it a part of a flowchart that will evolve into a storyoverview, often a branching tree, growing downwards. The squared frames tellsthat everything that happens in them is tied to the object. As soon as a globeis dropped the frames changes into circles, defining everything that happensafterwards as global events.

Figure 6.7: Label 6: The game device Phone at its initial state. Label 7:Walkie-talkie with Text-to-speech asset added and the ”active player choice”selected


Figure 6.8: Label 8: The game device Report. Label 9: The game device Radio

Figure 6.9: Label 10: The Sounds asset. This is how sound is added internallyin the Phone or Walkie-talkie device, or directly to the game when dropped onthe work area

6.1.5 The Game Devices

The four game devices are quite similar in their internal state. The Phone andWalkie-talkie are similar because of their inner drop functionality, figure 6.7,label 6 and 7. To add actions to any of them assets such as sound or text-to-speech are dropped in the internal drop areas, with a maximum of threedi"erent items. The di"erence between the Phone and Walkie-talkie device arethe initial sound, for the Phone a ring signal is heard, and with the Walkie-talkie the scratching sound of the transmission is heard. A drop box of allthe available in-game characters are positioned at the top of the item area,and at the bottom of this list a short cut to create new characters can befound. If the user selects this option the characters tab gets activated and a


Figure 6.10: Label 11: The Walkie-talkie as a local event and with the playerchoice active. Label 12: The Walkie-talkie as a local event with a trigger o"setactivated

Figure 6.11: Label 13: The Sleep function. Label 14: The Global function.Label 15: The Label function

new character, or editing of any of the existing ones are possible. The Radiohas the option of choosing a male or a female news reporter and then a textbox for the news input, figure 6.8, label 9. The readers voices can be changedin the characters tab. For the last device, the Report, figure 6.8, label 8, theuser has to choose from whom the report is sent, and then a text box for theactual text of the report. All of the devices has a checkbox at the bottom,if the event is the last in the scenario, an active End Part checkbox ends theflow and tells the game machine that the end of the scenario is reached. TheWalkie-talkie has another checkbox; ”Activate player choice”, and this is whatbranches the flow in the scenario and gives the player a choice in the game. Ifthis checkbox is active, two text fields are visible and these are the choices thatis presented to the player whenever a choice has to be made, figure 6.7, label 7.This could for example be the choice of sending a team of agents to investigatea strange sound, or to ignore the sound and let the possible information thatthis action would have given, slip. When pressing OK a branch on the mainarea is created and the point of an arrow decides which part of the flow towork with. figure 6.10, label 11. This can easily be changed by pressing the

6.2. Design guidelines 65

arrow and thus switching the active part. When all the actions are decided inthe device and the ”OK” is pressed, the device is correctly placed in the flowof the scenario. If the action is dependent on a local trigger the framing is asquare, and if it is a global action, it is framed by a circle. For actions that aredependent on some player interaction or local trigger objects an o"set arrow isavailable which branches the flow in the case of a time-out from the player orif the correct trigger objects are not found. figure 6.10, label 12. If the actionis dependent on a local trigger object, the device is placed beside the triggerobject to visualize that dependence, because of this the framing is rectangular.If the time-out o"set is activated, a time input is required from the user, this ishow long the program will try and activate the ”main” flow, and after this thealternative o"set part is activated. The di"erence of the two assets are that theSounds can be dropped both internally in a device and out on the main workarea, figure 6.9, label 10, but the Text-to-speech can only be used internally,figure 6.7 and 6.8, label 7 and 9. If a Text-to-speech is dropped in the mainwork area it instantly disappears. All the di"erent devices and actions addedon the main work area creates a scenario flow in a tree structure. When thedevices are created and the OK is pressed the inner structure implodes and thesymbol is added to the flow. A double click on the item will open the innerstructure again and allow for changes and editing.

6.2 Design guidelines

To create the interface some general guidelines stated by Nielson, [23] werefollowed. These guidelines will be presented and discussed from the interface’spoint of view below.

6.2.1 Match between system and the real world

It is important to identify the user and understand him/her and the interface’sintended use to be able to speak the user’s language. Since our user isn’t ahard core programmer nor a full writer but somewhere in between, the impor-tance of an easy and manageable interface is high. Early in the process it wasdecided not to ask for any manual programming of the user, but instead o"erthe possibility to tweak or alter the code created by the program in a code view.

The language used in the interface is mainly taken from the BSP prototypeand the symbols are inspired by the theme, is quite straight forward and usesfamiliar conceptual models and metaphors. To understand the interface andbe able to work with the software some prior knowledge of the game and itsstructure is needed. This was, however accepted as a learning threshold and tofurther help and guide the user a help function is found at the top right cornerof the interface. With this button activated the di"erent items and symbolsare explained when the cursor is placed over the item. This help function is


not implemented in the 1.0 version.

6.2.2 Consistency and standards

Express the same thing the same way throughout the interface. Consistencyhas been used throughout the interface. All the items are visually presentedin the same way, with the specific symbol of the item in the tab to the rightof the inner structure. All the dropboxes, checkboxes and verification buttonsare placed in the same fashion, and all the menu items are grouped logicallyand consistently placed at the top of the interface so that the user always canfind them. The color coding is used uniformly, connecting the work area withthe menu and the program structure (the di"erent tabs, such as character andsoundscape), and links the di"erent overviews together. The input syntax isuniform in the fashion that a phone call is always generated by dropping aphone item at the work area, and a walkie call always by dropping a walkie-talkie item. The only other way of doing this is by accessing the code view andmanually code the action, this is however not implemented in the existing 1.0version.

6.2.3 Visability of system status

Since the present scenario flow always is visual on the work area the user iskept informed of what goes on and is provided with timely feedback for allthe actions. Of the same reason all the input that has been recived fromthe user is visible at all times and the flow chart indicates the progress ofthe task performance. Further the interface is built on the concept of directmanipulation: visible objects, visible results.

6.2.4 User control and freedom

A certain level of forgiveness is implemented. To delete a scenario the Deletebutton at the bottom left corner is used and to remove any of the devicesor actions in the scenario flow this item is selected and dragged o" the workarea. This action does not however work without flaws and the framing ofthe item should be removed with the item. The scenarios can be closed andreopened by clicking the red cross in the scenario tab and then opened againby clicking the prefered scenario in the Chapter overview. This action also hassome flaws. Within all of the device structures, a cancel button and a ok buttonis presented. Pressing the Cancel does however not remove the item from thework area, this has to be done by dragging it o" the stage, but doesn’t placethe item either. The placeing occurs when OK is pressed. The exits are clearlymarked by using a button always present at the bottom and by highlightingthe cross in the sceario tab with a clearly visible color; bright red. At startupthe user is given an active Intro scenario to start working with. This is tostear the user to create a much needed intro sequence for the player. The user

6.2. Design guidelines 67

has however full control of the actions and can choose to start with anotherscenario if prefered. All the internal structure and the actions are controlledby the user.

6.2.5 Error prevention, recognition, and recovery

In this version error prevention and recovery has not been at the highest pri-ority. However, if any misstages are made, like starting a scenario without anylocal or global trigger, popups and feedback can easily be added to the system.

6.2.6 Memory

Since all of the interface and the manipulation of items at all times are visibleand salient, the user’s memory load is reduced and direct manipulation is sup-ported. In the trigger object option a list of all the sub objects are given andpicked. The drag-and-drop manipulation supports the see-and-point instead ofremember-and-type that is more common in coding.

6.2.7 Flexibility and e!ciency of use

Shortcuts are provided through the interface. It is possible to add or edit bothcharacters, sounds and soundscape, and the user gets transferd to the correctsub-tab and when editing is done, the user is brought back to where ever heor she started from. Accelerators are also provided for with the makings ofstructures. Structures, or templates are parts of a scenario which the user hassaved and can re-use and edit. This is to accelerate the creation of standardparts and common type scenarios. This gives the user the option to speed upfrequent actions, and this makes the system e!cient to use.

6.2.8 Simplicity and aesthetic integrity

The ”look and feel” of the interface stresses a simple and natural dialog witha smooth graphic design, and the information presented appears in a naturaland logical order. Soothing colors of gray is chosen for the background. Tomark out the important stu" a pale orange is chosen as the contrasting color.

6.2.9 GUI-general guidelines

To keep the memory load of the user to a reduced state, a broad and shallowmenu has been created. The di"erent menu parts are separated by a visualline, which enhances the di"erence between the various menu items. Further,the flow of a scenario can become quite large and deep, so some scrolling hasbeen accepted in this version. However, a large amount of scrolling in themain work area is only due to a big and complex scenario with many possibleoutcomes, and this possible outcome is created by the user and should not


be restricted or held back. No scrolling is however accepted when working inany of the internal device structures, this to keep the required memory loadto a minimum. The maximum internal depth is created by the Walkie-talkiedevice when the ”Activate player choice” is active. The maximum number ofresources possible to add, (3) was set by this visual limit/restriction. [24] [22]

6.3 Scenarios

The scenario below depicts how a user creates a scenario in the Backseat Play-ground editor.

Label 1: The user has selected to create a new scenario by clicking on the+ tab at the left of the Intro tab. The user has then named the new scenario”The Forest”. This name can be found both in the node view at the top rightand in the tree view to the left. The user has then dragged a Woods categoryto the work area, selected the object Wood and changed the o"set parameterfor Distance to -20 meters.

Label 2: The user has dragged a Phone to the work area and selected callerHelena. Two Text-to-speech assets have been added where the user has addedinformation to the player.

Label 3: A Walkie-talkie has been added to the scenario and Agent Alphahas been selected as the caller. The user has added a text-to-speech and asounds asset to the Walkie-talkie conversation. The sound selected is the Gun-Shot.

Label 4: A last Text-to-speech asset has been added to the Walkie-talkie con-versation.

Label 5: The user has ended the local based part of the scenario by adding aGlobe to the story flow. The actions followed by a globe becomes global eventsand can be triggered anywhere in the game, they are no longer bound to aspecific trigger object. After this the user adds the report that Agent Alphasends to the player.

Label 6: The complete story flow of the scenario. Note that the scenario statsas a local scenario but changes to a global. This can be seen by the changefrom squares to circles around the events, and by the dotted line starting fromthe Globe.

6.3. Scenarios 69

Figure 6.12: Label 1: User has created The Forest scenario and added a Woodtrigger object with - 20 meters as trigger o"set. Label 2: 20 meters before thetrigger object Helena calls and gives the player some interesting information


Figure 6.13: Label 3: Agent Alpha, one of the agents out in the field contactsthe player by Walkie-talkie, but gets interrupted by a gunshot. Label 4: Thecomplete Walkie-talkie communication

6.3. Scenarios 71

Figure 6.14: Label 5: A Globe is dropped to make execution of the rest ofthe script global/non-local based. A report from agent Alpha gives the playerinformation about findings in the forest. Label 6: The complete scenario struc-ture

Chapter 7

Discussion

In this part of the thesis some general thoughts and reflections will be sharedand discussed, both regarding the process of the entire project itself and thespecified subject investigated. The Interactive Institute is a very creative andfree workplace with little boundaries and high productivity. The institutesinspiriting environments and work areas has provided a stable ground for in-teresting discussions and great ideas, but the lack of boundaries were also chal-lenging at times. Entering into the BSP project in the phase that we did wasan interesting experience. All the big pieces were done and the prototype wasmore or less up for testing, but the story parts were still only fragmental andconsisted of only 8 manually created python scripts that only covered a smallpart of the interactive agent story. The first questions asked was: ”How big canthis story become? How should an presumed editor handle all this data, andwhat kind of data are we talking about? Can it be done?”. From the interviewswe learned and got a deeper understanding of the BSP engine and how it hadevolved, but it also became clear that the demands and focal issues on the edi-tor was as di"erent and varying as the number of persons involved. Due to thisfact, and looking back at the process a stricter project definition would haveeased the stress and limited the workload, making discussions more focusedand workshops more constructive. All information gathered for this thesis areeither published papers on the subject, or retrieved from inside of the instituteand this fact can be argued both in a positive and a negative manner. Due tothe fact that the BSP project is ground breaking in this special field no otherinformation channel can match the level of information that the InteractiveInstitute can give, but at the same time no new inputs can be given when onlylooking in-house.

Looking further into the specifics of this thesis some light on the bounds ofthe project has to be shed. The scope of the initial project ideas was vast,and the first plan was to provide a more or less functional program for storycreation in the BSP environment with python script. The fact that this scope

73

74 Chapter 7. Discussion

was all to big became evident early in the process, and the scope and focuschanged to a semi-functional graphical user interface for the ”main” part ofthe editor, but still with ideas and conceptual sketches for the entire data flowin the editor. The fact that this thesis is conducted by a duo also made itpossible to not only create a conceptual idea with flow charts and sketches,but also implement a prototype. Working in pair also eased the creative partof the work, making workshops and brainstorming funnier and the lowpointsof creativity easier to overcome. An important lesson learned is to documentdevelopment with version numbers and backup frequently. This lesson was sor-ley learned when the final version dissapeared shortley after the demonstrationsession in-house, leaving the last documented version with more flaws than ex-pected. The scope of the thesis matched very well to our thoughts and workingmethods of an interaction designer; all from identifying the users and createconceptual sketches to implementing a prototype for easy presentation of thefinal ideas. In hindsight this can very much be a result of the fact that theboundaries to this project was very loose, giving us the possibility to steer itin whatever direction we choose. The main motivation for this project was toact as a ground for further discussions and creation of the conceptual ideasof what an interactive story can imply. The choice of development tools andwork methods came from the education background that we both share. Ourexperience is that this way of working is a e!cient and good way of conductinginteraction design. The graphical tools used in the development was from theAdobe Creative Suite 3.0 package: Flash and Illustrator. Regarding Flash,we decided to work with actionscript 3.0. This is a new way of structuringthe content in flash by creating classes and objects, and this metond of work-ing has close resemblance with other object oriented programming methods,making the structure easier to work with. Illustrator was used to make fastand destinct sketches and flow charts of the system. To take this prototype tothe next level and further work with the interface an iterative process needsto be initiated where the prototype is tested against the intended user andthen evaluated and re-designed. All parts of the editor also need to be imple-mented as well as all additional features prepared for. In total this project hasbeen good fun and given a lot of ”hands on”-interaction design hours, all frombrainstorming and conducting workshops to deep interviewing and sketching.Guidance has been given from the team at the Interactive Institute, mainlyfrom the entire team, as well as from the university, but the absence of closediscussions and general feedback from the university has left more to ask for.The reality of the world outside of the university also made its presence whenthe duo got employed before the final touches of the thesis was done, makingthe thesis period somewhat outdrawn.

7.1. Known issues in the prototype 75

7.1 Known issues in the prototype

Looking at the requirement list in chapter 5 following requirements are notimplemented in the prototype:

– Creation and adding of characters

– Creation and customisation of soundscape

– Support of manual editing

– Support simulation

– Code view

– Short cuts

– Help definitions of symbols and names

These functions are not implemented due to time shortage and was lifted fromthe scope of the prototype because of their functional rather than structuralnature. The interface is prepared for showing these features, as seen in thebottom right of the interface where tabs for characters and soundscape arefound. The characters tab holds a sketch of the character input and editingbut is not functional. Short-cuts are prepared for in the character dropdownand the help function is found in the top right corner of the edior. Simulationtab is found in the top left. None of these holds any funtionality in this version,but the interface supports their presence.

7.2 The future of the editor

The categorization have been made according to the existing map database,and is static in this version of the prototype, but it should of course be madepossible to add more categories to the list and customize the existing categories.Further the code view discussed should visually support the user by adding asmall icons to the senario structure where the story has been manually edited.A big part of the editor that is not yet implemented is the simulation module.The issue is to connect the created story to the existing simulator. The helpfunction implementation is also left for a future version of the editor.

76 Chapter 7. Discussion

Chapter 8

Conclusions

The question that was asked in the beginning of this project was; ”how can onevisulize the creation of a game story where the game events are dependent onposition and external objects that occurs in a linjar yet unpredicatble manneralong a traveled path”. During the time of this thesis the authors has triedto answer this by extensive research and prototype moduling. The result isa prototype that serves as one possible answer that manages to visualize thefundamental parts demanded by this kind of game play. The main issue tosolve is the fact that the story flow is both linear and unpredicable. The factthat the existing story content is still under development, with only fragmentalinformation provided, makes the question if the editor is up for the challengestill unanswered. The developed editor prototype is a first step towards resolv-ing the issue of visualizing this kind of story development, but to be completelysure about the direction this editor has taken, further trials and iterations haveto be conducted.

The biggest challenge in creating the interface was the structuring of infor-mation. Some distinctions were made and a specific grouping of the objectswas done based on the objects characteristics. This grouping makes it some-what di!cult to categorize new objects that may become valid for example ifthe game is used in another country with totally di"erent architecture and geog-raphy. The solution can be to allow some miscellaneous groups of objects thatcan group objects that doesn’t fit in to the original groups. The assumptionwas made that the chosen groups, woods, waters, buildings, points of interest,railways (and roads) and fields were somewhat general for most parts of theworld. The symbols may be too specific though and this is a part of the resultthat has to be considered and tested in a potential future development.

One of the main purposes of the editor is to give a good overview of the storydevelopment, as the information load is extensive. This is provided throughthree di"erent elements in the interface; the tab structure for scenarios, the tree

77

78 Chapter 8. Conclusions

structure for chapters and the node view for overlooking the dependencies andconnections between scenarios. One drawback of the node view is that it onlyconsiders one chapter at a time. This is a constraint based on the assumptionthat chapters will fallow in a chronological order rather than in some kind oflink mesh. This was the hard part to resolve as there are no other chapters im-plemented yet and no one knows exactly how it would look and how the storyshould evolve chapter vise. The assumption was therefore made that scenariosmay come in an unpredictable order, depending on objects in the landscape,but when some semi-goal is reached the chapter ends and the next begins in asomewhat story like, linear order.

General thoughts about the editor while demonstrating in-house were that itis a good starting point for future discussions, but that some generalisationswere still to be meet, for instance the possibility to add more object categories.The authors still feel that the major parts of the requirements was met by thisversion, but is aware that to bring this editor to a final state the completeset of functions needs to be implemented and the other modules developed.Regarding the visual aspect of the prototype the authors feel that the colorchoices, positioning and structuring of the information and the di"erent gameelements on the screen makes for a user-friendly and balanced interface.

To conclude this thesis and the project as a whole it feels right to mentionthat the project felt valid and relevant. The assignment was a well-matchedinteraction design task even though the scope of the project was vauge andever-growing. The project let the authors test design skills and grips learnedin a creative and open environment while at the same time having rewardingdiscussions and good fun.

Chapter 9

Acknowledgements

We want to thank the Interactive Institute in Kista for an engaging environ-ment, good tutoring and great discussions. A special thanks to the team behindthe BSP concept; Oscar Juhlin, Anton Gustafsson, John Bichard and LiselottBrunnberg. Thanks to SICS for delicious co"ee and interesting seminars.

We also want to thank the beautiful city of Stockholm and the SoFo Cafefor all those days of urban creativeness and inspiration.

I also want to thank my fiance Peter Karlsson for feedback on the designsketches, for giving me insights in how an involved player thinks and for ex-plaining how the game Football Manager works.

- Elvira Danell

79

80 Chapter 9. Acknowledgements

Glossary

Audio centric interaction Interaction mainly based on audio input, 6Augmented reality Augmented reality is a field of computer re-

search which deals with the combination ofreal-world and computer-generated data (vir-tual reality), where computer graphics objectsare blended into real footage in real time, 3

Branching tree A branching tree is a diagram that shows howdi"erent groups of data are related, 7

Closed world game editor The game world can be called closed if the au-thor’s have total control of the game world. Thegame world is well defined (the game doesn’tevolve with AI or user interaction), 18

Emergent gameplay Emergent gameplay is the creative use of a com-puter game in ways unexpected by the game de-signer’s original intent. It commonly appears ascomplex behaviors that emerge from the inter-action of simple game mechanisms, 7

Highway experience A continuous flow of impressions and new situ-ations, 6

Immersion Immersion is the state of consciousness wherean immersant’s awareness of physical self is di-minished or lost by being surrounded in an en-grossing total environment; often artificial., 3

Interactive storytelling A story that allows the viewer/listener/playerto interact with it. The term is frequently usedin the concept of pervasive gaming, 7

81

82 Glossary

Magic circle The special fictional area where a game takesplace and special rules apply, for example thegame board of chess. In pervasive games thiscircle is said to be scattered, 6

Pervasive game Pervasive game, or location-based/enabledgame is one in which the game play somehowevolves and progresses via a player’s location, 3

References

[1] The Interactive Institute. Interactive institute - about us.www.tii.se/node/26, 2008-06-17, 21:03.

[2] The Interactive Institute Mobile Life. Mobile Life - The Mobile ServicesProject. 2004.

[3] The Interactive Institute. Interactive institute - backseat games.http://www.tii.se/mobility/Backseat/backseatgames.htm, 2008-06-17,21:56.

[4] L. Brunnberg. Playing with the highway experience - pervasive games onthe road. Doctoral Dissertation in Applied Information Technology, 2008.

[5] M. Montola. Exploring the edge of the magic circle: Defining pervasivegames. Game Research Lab, DAC 2005 Conference, 2005.

[6] SICS. Iperg. http://www.iperg.org/, 2008-07-18, 15:04.

[7] N. Szilas. A computational model of an intelligent narrator for interactivenarratives. Applied Artificial Intelligence, 21:8, pages 753–801, 2007.

[8] C Handler Miller. Digital storytelling - a creator’s guide to interactiveentertainment. Elsevier Inc., 2004.

[9] Wikipedia.org. Hypertext. http://sv.wikipedia.org/wiki/Hypertext, 2009-02-16, 21:55.

[10] B. Magerko. Story representation and interactive drama. American Asso-ciation for Artificial Intelligence, 2005.

[11] B. Kampmann Walther. Pervasive game-play: Theoretical reflections andclassifications. Center for Media Studies, University of Southern Denmark,2006.

[12] D. Brown Reese. Pervasive games are not a genre! (they are a sub-genre.)atheoretical model for the genre of appropriative games and a technical ap-proach to a singleplayer appropriative gaming experience. Communicationand Culture Georgia Institute of Technology, 2007.

83

84 REFERENCES

[13] A. Gustafsson, L. Brunnberg, and O. Juhlin. Movement and spatial inter-action - inclusion of journey experiences in game play. MobileHCI 2008,September 2-5, 2008, Amsterdam, the Netherlands, 2008.

[14] B. Mendler and B. Magerko. Scribe: A tool for authoring event driveninteractive drama. Lecture notes in computer science, 2006.

[15] S. Sauer, K. Osswald, X. Wielemans, and M. Stifter. U-create: Creativeauthoring tools for edutainment applications. Conference Paper, 2006.

[16] S. Donikian and J-N. Portugal. Writing interactive fiction scenarii withdramachina. Lecture notes in computer science, 2004.

[17] T. Laukkanen. Modding scenes - introduction to user-created content incomputer gaming. Hypermedia Laboratory Net Series 9, 2005.

[18] Wikipedia.org. Doom. http://sv.wikipedia.org/wiki/Doom, 2008-07-22,21:28.

[19] E. Befring. Forskningsmetodik och statistik. Studentlitteratur AB, 1994.

[20] A. Gustafsson, J. Bichard, L. Brunnberg, O. Juhlin, and M. Combetto.Believable environments - generating interactive storytelling in vast loca-tion based pervasive games. Conference ’04 Month 1-2, 2004, Stockholm,Sweden, 2004.

[21] G Hale. Insights into the design of computer entertainment from schemasin film. Springer Berlin / Heidelberg, 2006. 84-92 pp.

[22] J. Preece, Y. Rogers, and H. Sharp. Interaction Design: Beyond Human-Computer Interaction. JOHN WILEY AND SONS, 2007.

[23] C. Wickens, J. Lee, Y. Liu, and S. Gordon-Becker. An introduction toHuman Factors Engineering - second edition. Pearson Education Inc, NewJersey, 2004. 396-404 pp.

[24] D. Norman. The Design of Everyday Things. BASIC BOOKS, 2002.

[25] J. Reid, E. Geelhoed, R. Hull, K. Cater, and B. Clayton. Parallel worlds:Immersion in location-based experiences. HCI 2005, 2005.

[26] S. Bjork, S. Lundgren, and J. Holopainen. Game design patterns. Pro-ceedings of Digital Games Research Conference 2003, 2003.

[27] E. Brown and P. Cairns. A grounded investigation of game immersion.Conference on Human Factors in Computing Systems CHI 2004, 2004.

Appendix A

Interview questions

This interview consists of open questions. You are encuraged to think and as-sociate freely at every question. We would appreciate if you look at the processof how you’ve been working with the project, from the begining till now, whenyou look at it today and in the near future.

You can at any time end the interview or leave out any questions you donot wish to answer.

1. How did the idea of BSP evolve?

2. When did you start working with the concept? From which angle? Story,hardware, locations, GIS-data. What felt relevant at the moment? Doesit have the same relevance today?

3. How did you think about the story in such a game? What do you believeis important in the creation process of the game experience of BSP? Whatdo you think the story should be about? What is suitable for the media?

4. Whats your thoughts about the purpose and the game experience? Thegame is mainly sound based, is that the way to create the right mood, oris there according to you other ways?

5. How would you prioritise the di"erent parts? From the start of the projectand today when you look back/forward?

The objects

The locations

The events

The player choices - the possibilty of branching

The characters

85

86 Chapter A. Interview questions

6. Tell us about your feelings of the contradiction of generalisation vs. speci-fication when designing a story for a medium such as BSP? Is it importantto be able to build general stories or are the specific more interesting, ie.the ones locally bound to a specific place? How would you like to combinethese?

7. Is there, according to you, any limitations in a medium such as BSP? Itmight be best suited for a specific type of story? The speed? Di!culty tohear? General about the di!culty of building a believable story in BSP

8. Whats your thoughts about the mood setting and the game experience?

9. What would you have wished for, during your work with the BPS, thatan presumed editor could have helped you with? What would you askfor in such a tool? What does it need to handle, and what does it not?How would you like the editor to visualize the storys di"erent parts? ie.what kind of overview would you like? Who do you feel would be themain user of such an editor?

10. Is there anything you would like to add? Anything you feel we left out orsomething you feel is important to share? Anything you what to shareabout your work with the BSP?

Appendix B

Requirement specification

Functional specification

General demands

– Provide a structured and ”easy-to-use” interface

– Support a creative work flow but at the same time guide the author inthe systems limitations

– Communicate the systems API

Necessary functions

– Provide an overview of the work at di"erent levels

– Intern overview of the scriptstructure in the form of for instance flowcharts

– General overview in the form of treeview

– General overview in the form of a graph with dependencies betweenscripts

– A timeline

– Provide a player introduction

– Enable the creation of a story

– Enable the creation of scenes/scenarios

– Enable the creation of events

– Be able to separate global- local- or reminder-events

87

88 Chapter B. Requirement specification

– Be able to create communication through a phone, walkie-talkie and areport

– Support verbal location references

– Define the maximum speech lenght

– Character handling that defines characters; including voices and moods

– Support dialog creation with text-to-speech

– Support the defining of pacing (Manage how and in what order the scrpitstriggers)

– Provide templates for story structures

– Provide default values where possible

– Provide lists of, and visualize available objects from GIS-data, and sup-port prioritising among these

– Sound editing/Test of sound

Ambient

Tracking

Global / Local

Dialouges

– Define the players options

– Define script dependencies (rules)

– Allow manual editing of code

– Provide shortcuts in the interface

– Provide information about the di"erent parts, functions and the termi-nology used

Wanted functions

– Define environmental di"erencies like temperature, daytime and season

– Support an online notebook for a deeper character creation process

– Support the creation of a comunity, User Generated Content

– Be able to create family-trees of the characters

– Support the creation of a transition mechanism for script gaps

89

– Provide simulation of the story

– Give a graphical representation

– Support follow-up functions on ambient sounds

– Resourse allocation of in-game characters

– Support storing of additional object details such as color, shape and his-tory

– Support emotional moduling of the characters

– Support additional interaction and challange in the game

– Provide the possibility to define the users journey, begining and end

– Provide dialog timing

– Generate voice manuscripts

– Support di"erent kinds of travels; commute /long distance

– Provide possibility to define reminders, such as ”Keep an eye out for thechurch!

authoring tools for interactive narratives · 2009. 3. 20. · authoring tools for interactive...

Documents