Robust and Authorable Multiplayer Storytelling Experiences

Mark Riedl, Boyang Li, Hua Ai, and Ashwin Ram

School of Interactive Computing

Georgia Institute of Technology

Atlanta, Georgia 30308

{riedl, boyangli, hua.ai, ashwin}@cc.gatech.edu

Abstract

Interactive narrative systems attempt to tell stories to

players capable of changing the direction and/or out-

come of the story. Despite the growing importance of

multiplayer social experiences in games, little research

has focused on multiplayer interactive narrative expe-

riences. We performed a preliminary study to deter-

mine how human directors design and execute multi-

player interactive story experiences in online and real

world environments. Based on our observations, we de-

veloped the Multiplayer Storytelling Engine that man-

ages a story world at the individual and group levels.

Our ﬂexible story representation enables human authors

to naturally model multiplayer narrative experiences.

An intelligent execution algorithm detects when the au-

thor’s story representation fails to account for player be-

haviors and automatically generates a branch to restore

the story to the authors’ original intent, thus balancing

authorability against robust multiplayer execution.

Introduction

An interactive narrative system attempts to engage players

in a story under the conditions that the players’ behaviors

and actions can directly impact the direction and/or outcome

of the story. That is, interactive narratives balance meaning-

ful choices by players against the coherence and quality of

the resultant narrative experience as dictated by a human

author. A drama manager (Laurel 1986) is one common

approach to balance the competing requirements of player

agency and authorial intent. A drama manager is an omni-

scient agent that observes the story world and directs non-

player characters (NPCs) in order to bring about the human

author’s intent in the face of uncertainty resultant from a rel-

atively under-constrained interactive player.

A vast majority of interactive narrative work has focused

on single-player experiences. However, there are a number

of multiplayer environments that can beneﬁt from what we

know about interactive narrative. For example, an Alternate

Reality Game (ARG) is an interactive narrative that uses the

real world as a platform, layering a ﬁctional world over the

real world. ARGs place high demands on human game mas-

ters and, as such, are limited in scale until games can be man-

 2011, Association for the Advancement of Artiﬁcial

aged autonomously (Barve et al. 2010). Multiplayer train-

ing simulations in online worlds and the real world can also

beneﬁt from experience management (Raybourn et al. 2005;

Niehaus and Riedl 2009). In addition to multiple participants

in the interactive narrative, it is also desirable for each par-

ticipant to experience different narrative arcs within a larger

narrative structure and to be manipulated into cooperative or

adversarial situations. That is, a drama manager must maxi-

mize the value of each individual player’s experience while

also maximizing the overall narrative experience.

In the work reported here, we asked experts on multi-

player alternate reality games to create and manually run

two interactive multiplayer alternate reality experiences us-

ing human confederates in the place of non-player charac-

ters. Based on our observations of the creation and execution

of the story, we derived the following set of properties that

multiplayer interactive narratives should possess:

• Multiplayer differentiability. Multiple players can partici-

pate in the same game and have potentially distinct narra-

tive experiences.

• Authorability. The human author can easily articulate how

different players experiences should unfold.

• Robustness. The system should be able to handle situa-

tions where the authored story does not provide guidance

on how to alter the narrative experience in response to

unanticipated player behaviors.

One of the core challenges in the development of an in-

teractive narrative is determining how much the drama man-

ager must rely on pre-authored story content from the human

author. On one end of the spectrum, we have Choose-Your-

Own-Adventure novels, in which a tree of plot points is com-

pletely pre-authored. On the other end of the spectrum, a

generative drama manager (Riedl et al. 2008; Young et al.

2004) constructs the story from scratch based in response to

the behaviors of the player. Other approaches such as that

used in the successful FAC¸ ADE (Mateas and Stern 2003) in-

teractive drama attempt to strike a balance. We observe that

as the story world includes more players and affords greater

expression to the players, the ability of the human author to

predict and control player behavior—especially when multi-

ple players can interact with each other outside the control of

the experience manager—decreases, requiring greater gen-

erative power. We cast this as a tradeoff between authorabil-

ity and robustness in the face of multiplayer differentiability.

We present an authorable narrative representation and

drama management execution process that lends robustness

to story progression in circumstances where players perform

behaviors unanticipated by the human author. Our represen-

tation is a specialization of Colored Petri Nets (Jensen 1996)

that models an interactive narrative as a process in which

multiple players ﬂow from scene to scene. Our execution al-

gorithm monitors for situations in which the Petri Net fails

to account for player actions and automatically constructs

new story branches to restore the Petri Net. In the remainder

of the paper we situate our approach in the context of related

work, brieﬂy describe the preliminary study with expert al-

ternate reality game directors that informed our approach,

and describe the representation and execution algorithm for

the Multiplayer Storytelling Engine (MUSE).

Related Work

Drama management, an approach to interactive narrative,

employs an intelligent and omniscient agent able to mon-

itor the virtual world and intervene in the world to ensure

coherent story progression while simultaneously providing

the player with a large degree of freedom to act. These inter-

ventions are typically instructions to non-player characters

(NPCs) to engage with the player in a certain way, but may

also physically change the world. Riedl et al. (2003) cate-

gorize player actions in interactive narratives based on how

they affect the story the drama manager intends to tell:

• Contingent: An action performed in line with the author’s

expectations, thus progressing the story.

• Consistent: An action that changes the world in a way that

neither assists nor hinders progression of the story.

• Exception: An action that alters the world in a way that

hinders story progression by making a future player or

NPC actions illegal or nonsensical.

All drama managers are dependent to some extent on

knowledge provided by the human designer, which may in-

clude large fragments of story, primitive actions to be as-

sembled at run-time, and/or rules on how to handle excep-

tions. The body of drama management work can be de-

scribed in terms of a spectrum of knowledge requirements

running from author-intensive to generative, with associated

pros and cons. Author-intensive approaches have consider-

able authorial burden for any signiﬁcantly large story world

(Bruckman 1990) but can be highly effective. Generative

drama managers can respond to a greater range of player be-

haviors but require story generation capabilities that are not

yet at the level of human storytelling competency. Space pre-

cludes an in-depth review of drama management techniques;

we note the most relevant work.

Balas et al. (2008) use hierarchical Petri Nets so that au-

thors can completely manually construct and execute com-

plex, branching plot structures. As with all heavily authored

approaches, success is dependent on the authors’ ability to

account for all possible exceptions at every point in the nar-

rative. A common approach that strikes a middle-ground is

to author plot graphs that specify ordering dependencies

between possible plot points coupled with some form of

search to construct a policy for how and when a drama man-

ager should intervene (Weyhrauch 1997; Nelson et al. 2006;

Sharma et al. 2010). The FAC¸ ADE interactive drama (Mateas

and Stern 2003) also uses numerous hand-authored plot

points and character behavior decompositions coupled with

intelligent plot point and behavior selection. We note that the

greater the extent that a drama manager relies on human-

authored content, the greater the conﬂation of robustness

with authorability, as the system is only as robust in so far

that the author is able to anticipate all exceptions.

Generative drama management, in contrast, utilizes a nar-

rative generation system to construct novel story sequences

whenever the player performs an exception (Riedl, Saretto,

and Young 2003; Young et al. 2004; Barber and Kudenko

2007; Riedl et al. 2008; Porteous and Cavazza 2009). Many

generative drama managers represent story as partial-order

plans and use a planner to generate and/or adapt the story

plan when necessary. Partial-order plans, in the case of sto-

rytelling systems, are graphs of events (or scenes) where arcs

capture causal and temporal relations. Partial-order plans

have been found to be good representations of narrative for

interactive systems for the following reasons: (a) partial or-

dering supports the parallelism of action that can occur in

stories; (b) the causal relations tracked by partial-order plans

are useful in identifying and handling exceptions; (c) causal

structures may correlate to certain aspects of aesthetics (Tra-

basso and van den Broek 1985); and (d) plan reﬁnement al-

gorithms can easily modify the existing story structure with

new scenes, thus implementing a form of continuous plan-

ning in response to player exceptions.

The IN-TALE (Riedl et al. 2008) system is a gen-

erative drama manager that starts from a pre-authored,

non-branching narrative plan and automatically generates

branches to handle exceptions. Our work is similar to IN-

TALE in that we also start from an authored narrative speci-

ﬁcation; however, we start from a pre-authored structure that

captures branching and accounts for different narrative arcs

for different players, thus accounting for authorability, ro-

bustness, and multiplayer differentiability.

Historically, drama management has focused on single-

player experiences. Winegarden and Young (2006) extended

the MIMESIS generative drama manager to account for mul-

tiple, distinct stories executing in the same environment.

Their work only considered load balancing between “story

servers” that may occasionally interfere with each other, but

didn’t consider the problem of managing multiple players

in the same narrative experience. Thus a novel contribution

of our work is an approach that speciﬁcally caters to mul-

tiplayer environments with the goal of using story to create

rich social interactions.

Preliminary Study

We conducted a preliminary, informal study to explore the

problem of multiplayer interactive narrative. We recruited a

director/screenwriter—an expert at crafting multiplayer al-

ternate reality games—to write two multiplayer stories that

would engage a half dozen people periodically over several

hours. He was encouraged to use whatever visual represen-

tation he felt appropriate to capture his design.

The director created the stories as graphs, where each

node represented a scene, a general description of the type of

activity that those present in a particular place would engage

in such as meeting a character or stealing an item. Scenes

were meant to be able to unfold in many different ways and

have many different outcomes. Edges between nodes acted

as ﬁlters selecting which players would progress to which

subsequent scenes. Thus, players had the potential to expe-

rience different sub-stories. We also note that the director

used early scenes to “matchmake”—to cluster players into

groups—using lots of conditional edges and optional scenes,

and used later scenes to create periods of competition and

cooperation between groups of players.

As in the study by Kelso, Weyhrauch, and Bates (1993),

participants were recruited to play the game and confederate

actors assumed the roles of NPCs. The human director, with

the help of assistants, manually gave instructions to NPCs

based on the story graph. Each story was run ﬁve times over

the period of a week with different participants each time.

Space prevents further details in this paper; however, we

made the following relevant observations:

1. Despite the best efforts of the director to predict different

ways scenes could occur, exceptions happened.

2. The director responded to exceptions by creating new

scenes on the ﬂy that, when possible, restored the play-

ers to the pre-authored scenes by the shortest reasonable

means.

3. In circumstances where the director deemed it too difﬁcult

to restore players to the pre-existing scenes, the director

authored new chains of scenes that skipped pre-authored

scenes and rejoin the story at a later point in the graph or

to bring the story to an early resolution.

Based on our observations of the human director during

the preliminary study, we developed the Multiplayer Sto-

rytelling Engine described in the next section for manag-

ing multiplayer differentiable experiences in online or real

world story environments.

The Multiplayer Storytelling Engine

The Multiplayer Storytelling Engine (MUSE) combines

human-authored story content and a robust generative exe-

cution process that handles exceptions that are unanticipated

by the human author. The representation for story content

must support multiplayer scaling and be easily authorable

by designers without requiring programming or manipula-

tion of complicated AI structures such as plans. To achieve

robust execution, the representation must support the ability

for an AI system to recognize and autonomously respond to

exceptions by dynamically generating a new branch to the

story structure. Thus, the approach behind MUSE is a col-

laboration between ofﬂine human storyteller and an online

AI system.

Story Representation

We represent multiplayer interactive narratives as a variation

of Colored Petri Nets (CPNs) (Jensen 1996), where places

are scenes, tokens are players, and transitions encode the

“ideal” progression of individual players through the scenes.

We chose the CPN representation because of ease of author-

ing branching story structures (Balas et al. 2008) as well as

similarity to the graphical construct devised by the director

in the preliminary study. The representation of players as to-

kens emphasizes a player-centric philosophy to storytelling,

allowing the author to determine how individual players ﬂow

through a story structure. This is more expressive than a tra-

ditional branching story in that it can capture both branching

and parallelism; different players can be engaged in different

scenes at the same time.

While Petri Nets can represent many different types of

processes, a Petri Net assumes that all faults in a process

are handled with transitions. The preliminary study demon-

strated that even experts cannot make fault-free narrative

structures in worlds that allow a high degree of player ex-

pression and agency. Consequently, we modify the CPN rep-

resentation with information that allows an intelligent exe-

cution engine to dynamically modify the network structure

to handle unanticipated exceptions.

We represent a scene as a tuple hm, A, B, P, Ei where:

• m is the minimum number of tokens required to execute;

• A is a list of NPC agents that will participate in the scene;

• B is the body, the set of instructions to team surrogates;

• P is a set of predicates describing conditions in the world

that must be true prior to execution; and

• E is a set of predicates that will become true if the scene

executes successfully.

Unlike traditional CPNs, scenes do not execute until a mini-

mum number of tokens are located at the scene and the pre-

condition predicates are satisﬁed by the current world state.

Transitions dictate storytelling logic by determining

which scene each player token should experience next based

on what happened in the prior scene. That is, instead of im-

plementing scene applicability constraints (which are han-

dled by the scenes themselves), transitions act as a ﬁlter on

tokens. Transitions are thus constrained to be of the form

, s

, P, Ci where s

and s

are the originating and ter-

minal scenes respectively, P is a list of players (or “any”)

in scene s

to test, and C is a (possibly empty) list of pred-

icates referencing players in P that will be tested against

the current state of the world. For example, a transition may

select players that have, in the course of a scene, agreed to

help a particular NPC (e.g., the condition agree(player?,

npc?) is true), while another will select the opposite.

Figure 1 shows an example Petri Net for a MUSE story;

for clarity, it is simpler than that from the preliminary study.

There are eight players, who are tasked with solving a puzzle

in the ﬁrst scene. The transitions on the ﬁrst scene sort the

players based on those who solve the puzzle and those who

do not. The ﬁrst half of the network engages the players in a

set of tasks that matchmake the players onto teams aligning

with a pirate, a witch, and a navy captain. The remainder of

the scenes bring the teams together in various cooperative

and competitive conﬁgurations. Note the use of transitions

to separate teams after they come together for joint scenes.

Teach

magic

Recruit

swabby

Join

witch

Test

swabby

〈*, solve-puzzle〉〈*, ~solve-puzzle〉

〈*, magic〉

〈*, ~magic〉

Join

pirates

Black-

mail

Conscripted

by navy

〈*, hired〉

〈*, ~hired〉

Trick

pirates

Steal navy

treasure

〈*, swabby〉

Find curing

amulet

〈*, magic〉

Discover

curse

Resolution

Hunt

pirates

〈*, navy〉

〈*, swabby〉

Figure 1: An example Petri Net story. Circles are scenes,

tokens are players, and boxes are transitions.

Story Execution

When a scene meets a minimum threshold of tokens, it is

marked ready for execution. Unlike typical executions of

CPNs, execution does not occur immediately. Instead the

system veriﬁes whether the preconditions of “ready” scenes

hold for the current world state. This step is critical be-

cause the Petri Net models the author’s ideal progression but

the world may actually have changed in ways unanticipated

by the author; e.g., not captured by an explicitly authored

branch. There are two reasons this can happen. First, players

change the world in unanticipated ways. Second, scenes may

“fail”—they terminate without achieving all their effects.

The scene veriﬁcation step proves that a scene can exe-

cute because its preconditions are true in the current world

state or can be made true given the current world state. If the

proof fails, the execution engine must take drastic measures

to reconcile the Petri Net with the state of the world so that

player experiences can continue. The story execution algo-

rithm is given in Figure 2; the core parts of the algorithm,

scene veriﬁcation and story repair are described below.

Scene Veriﬁcation Once a scene is ready, MUSE veriﬁes

that scenes meet their applicability conditions by building a

partial-order plan comprised of new scenes not in the Petri

Net. In this sense, a sound and complete plan is a proof that

any given scene can be executed barring any further unan-

let plan ← the empty plan

let state ← current world state

while true do

Wait for a scene to terminate

Remove terminated scenes from plan

state ← UpdateWorldState()

if there are exceptions then

plan ← Repair(plan, state)

UpdatePetriNet()

if there are scenes ready then

foreach scene s

∈ Ready do

Add s

to plan

let p

new

← Plan(plan, state)

if p

new

6= ∅ then

foreach s

in p

new

with no scenes ordered

earlier do

StartExecuting(s

)

plan ← p

new

else

plan ← Repair(plan, state)

Figure 2: The scene execution algorithm.

ticipated changes to the world. Scenes ready for execution

are placed into the plan, which may be empty or a complete

plan from a previous iteration, and the planner in invoked to

attempt to ﬁnd a sound and complete partial-order plan. If

an exception has occurred, then the current world state will

not support the preconditions of one or more ready scenes,

requiring the planner to instantiate new scenes that bridge

between the current world state and the new scenes.

We use reﬁnement search (Weld 1994) to construct the

plan. A reﬁnement search planner takes a plan (empty or

otherwise) and searches for a sequence of modiﬁcations that

restores the soundness of the plan. In particular, a plan is not

sound if it has an open precondition ﬂaw—a precondition of

a scene is not supported by the current world state or by the

effect of another, temporally prior scene. A data structure

called a causal link, denoted s

−→ s

, records when precon-

dition c of scene s

is satisﬁed by an effect of scene s

(or

the initial state).

The scenes from the Petri Net will wait until all of its pre-

conditions are met by the executing plan. Scenes inserted by

the planner may involve players directly or may be main-

tenance scenes in which NPCs are directed to change the

world “behind the scenes,” for example having an NPC re-

place a missing prop. When newly planned scenes include

players, token locations are not adjusted, they remain in

place with the understanding that any other planned scenes

are meant to restore the applicability of the original scene.

The process of adding new scenes lends robustness to the

authored story. By instantiating scenes to bridge between

the unexpectedly modiﬁed world state and scenes from the

CPN, the system is effectively authoring new branches to

the story module. Thus the MUSE execution algorithm aug-

ments the author’s intentions by returning the world state to

one intended by the author so that the story can continue.

Story Repair Scene veriﬁcation is a process whereby

changes to the world state impact scenes as they become

ready. When a plan is in existence, further exceptions can

also derail the plan; players can cause changes to the world

state that will negate causal links in the plan.

Instead of rebuilding the plan from scratch, we use the

following plan repair approach adapted from Riedl et al.

(2008) to remove elements of the plan that are no longer

necessary due to world changes and to graft new scenes

into the plan that restore plan soundness. This process is a

form of continuous planning, which is, on average, more ef-

ﬁcient than replanning from scratch and less likely to pro-

duce dead ends—executed scenes that never build toward

the story conclusion.

First, we distinguish between scenes added to the plan by

the Petri Net, S

Petri

, and scenes instantiated by the planner,

Plan

. There are some number of exceptions, represented as

causal links no longer supported by the current world state

and the scenes they point to. The system applies each of the

following repair strategies in sequence until one returns a

sound plan.

1. Remove the threatened causal links. Invoke planner to sat-

isfy the now unsatisﬁed preconditions.

2. Remove the threatened links, the threatened scenes, and

any scenes in S

Plan

that are only on causal chains leading

through threatened scenes. Invoke the planner to satisfy

any unsatisﬁed preconditions that result.

3. Remove the threatened links, the threatened scenes, and

any scenes in S

Plan

or S

Petri

that are only on causal

chains leading through threatened scenes. Invoke the

planner to satisfy any unsatisﬁed preconditions that result.

Advance tokens in any scene in S

Petri

that were removed.

The ﬁrst two strategies attempt to return the world state to

one that supports the author’s intended story ﬂow.

The third strategy handles the case, as seen in the prelim-

inary study, where authored scenes are bypassed. A scene in

Petri

is removed if its effects are preventing other scenes

in S

Petri

from becoming provably executable due to unan-

ticipated changes in the world. If a scene in the Petri Net is

bypassed, what happens to the tokens located in that scene?

The tokens must be relocated at another scene. The execu-

tion engine simply forces the tokens to transition to subse-

quent scenes. Tokens can always move due to the constraints

we impose on transition structure. Forcing tokens to transi-

tion will result in one or more subsequent scenes in the Petri

Net becoming “ready.” It is likely that those scenes will have

preconditions that cannot be satisﬁed by the current world

state which will be handled by scene veriﬁcation and sub-

sequent calls to the story repair mechanism. Strategy 3 is

analogous to creating a new branch in the CPN, duplicating

human directors’ last-ditch efforts to save the story.

Scene Execution A scene is executed when it has a mini-

mum number of tokens and all of its preconditions are satis-

ﬁed by the current world state. That is, there is a valid exe-

cution plan and there are no scenes temporally ordered ear-

lier. It may be the case that more than one scene executes in

parallel, which is allowed as long as there are no shared re-

sources (NPCs, items, players, etc.) between parallel scenes

(Knoblock 1994). If there are shared resources, then one is

randomly selected to go ﬁrst and the others are put on hold

until the ﬁrst completes.

From the perspective of the execution system, scene ex-

ecution means a message is sent to the NPCs participating

in the scene. In the case of our preliminary study, NPCs

were human confederate actors, however they could be au-

tonomous agents. Implementation of autonomous character

agents is beyond the scope of the paper, but agents built

on reactive teleological frameworks such as those used in

FAC¸ ADE (Mateas and Stern 2003) and IN-TALE (Riedl et

al. 2008) are most appropriate.

Scenes terminate when an adjudication routine—usually

built into the NPCs—believes that all the effects of the scene

have been achieved. Scenes may also be terminated when the

adjudication routine believes that one or more of the effects

will not be achieved. This is tantamount to failing the scene.

Authoring

Petri nets, with the constraints we impose, provides a de-

gree of ﬂexibility for authors to express their creativity with-

out requiring authors to conceptualize their story designs as

partial-order plans. A Petri Net does impose some structure

onto the creative process in terms of breaking the story into

scenes and transitions. We found this to be similar to the way

our expert director preferred to break up the interactive mul-

tiplayer experience to account for different narrative arcs for

players. The Petri Net, as we have formalized it, allows the

author to think about the story experience from the perspec-

tive of the players and the sequence of scenes players will

encounter. The Petri Net formalisms also enables branching

and scene alternatives, as shown in Figure 1. The execution

system will handle the cases where exceptions are not caught

by pre-authored transitions.

For robust execution, MUSE authors must also provide a

domain theory, a description of how the world can change.

In this case, the domain theory is a set of extra scene tem-

plates that, like scenes in the Petri Net, provide precon-

ditions and effects in the form of predicates. These extra

scenes are instantiated during scene veriﬁcation and story

repair as means of restoring the Petri Net.

We trained the director from the preliminary study

to author interactive narratives using the MUSE rep-

resentation, consisting of a Petri Net of scenes and a

domain library of extra scenes. The human director

authored highly speciﬁc scenes in the Petri Net (e.g.,

distract-guard-and-crack-safe (thief:Ethan,

players?, safe1, guard:Chris)) and general scenes

for the domain library (e.g., steal(thief ?, players?,

object?, owner?)), where question marks denote variables

to be bound when the plan is created. The general nature

of the domain library created by the director suggests

reusability in the sense that many distinct MUSE stories

could be authored alongside the same domain library. The

only requirements for this is consistent use of predicates.

Finally, an initial state must be provided that describes the

characters, places, and objects speciﬁc to the MUSE story,

as well as relationships between them all. These are used

when instantiating general scenes. An ontology of generic

proposition types enables authors to construct and describe

unique entities in predicate terms that match the precondi-

tions and effects of scene templates in the domain theory.

The initial state is another way in which reusability of the

domain is achieved; when scenes are the same, many stories

can be told about different characters, places, and objects.

Conclusions

The MUSE approach was developed to directly address the

core requirements of multiplayer differentiability, authora-

bility, and robustness for multiplayer interactive narratives in

online or real worlds. In particular, we modeled the way the

expert director/storyteller focused on individual player tra-

jectories through a space of scenes in alternate reality games.

We note that stories can, and will, derail in multiplayer

real and online environments affording rich player expres-

sion. Robustness of the interactive narrative experience can

thus be achieved through a partnership between human au-

thorial ability and an intelligent system capable of restor-

ing authored scenes to executability. Given a robust drama

manager using our story representation, an drama manager

can provide players the ability to express their agency—

including the ability to perform actions that may derail the

story—while managing individual narrative experiences and

the overall group social experience. Multiplayer experiences

will continue to grow in importance. For these systems to

scale, they must allow authors the ability to craft engag-

ing experiences for all players, individually and collectively,

without reducing players’ abilities to be expressive.

References

[Balas et al. 2008] Balas, D.; Brom, C.; Abonyi, A.; and

Gemrot, J. 2008. Hierarchical petri nets for story plots fea-

turing virtual humans. In Proc. of the 4th Conference on

Artiﬁcial Intelligence and Interactive Digital Entertainment.

[Barber and Kudenko 2007] Barber, H., and Kudenko, D.

2007. Dynamic generation of dilemma-based interactive

narratives. In Proceedings of the 3rd Conference on Arti-

ﬁcial Intelligence and Interactive Digital Entertainment.

[Barve et al. 2010] Barve, C.; Hajarnis, S.; Karnik, S.; and

Riedl, M. O. 2010. Wequest: A mobile alternate reality

gaming platform and intelligent end-user authoring tool. In

Proceedings of the 6th Conference on Artiﬁcial Intelligence

for Interactive Digital Entertainment Conference.

[Bruckman 1990] Bruckman, A. 1990. The combina-

torics of storytelling: Mystery train interactive. Unpublished

manuscript.

[Jensen 1996] Jensen, K. 1996. Coloured Petri Nets: Basic

Concepts, Analysis Methods and Practical Use, volume 1.

Springer, 2nd edition.

[Kelso, Weyhrauch, and Bates 1993] Kelso, M.; Weyhrauch,

P.; and Bates, J. 1993. Dramatic presence. Presence: The

Journal of Teleoperators and Virtual Environments 2(1):1–

15.

[Knoblock 1994] Knoblock, C. 1994. Generating parallel

execution plans with a partial-order planner. In Proceed-

ings of the 2nd International Conference on Artiﬁcial Intel-

ligence and Planning Systems, 98–103.

[Laurel 1986] Laurel, B. 1986. Toward the Design of a

Computer-Based Interactive Fantasy System. Ph.D. Disser-

tation, Ohio State University.

[Mateas and Stern 2003] Mateas, M., and Stern, A. 2003. In-

tegrating plot, character, and natural language processing in

the interactive drama Fac¸ade. In Proceedings of the 1st In-

ternational Conference on Technologies for Interactive Dig-

ital Storytelling and Entertainment.

[Nelson et al. 2006] Nelson, M.; Mateas, M.; Roberts, D. L.;

and Isbell, C. L. 2006. Declarative optimization-based

drama management in interactive ﬁction. IEEE Computer

Graphics and Applications 26(3):30–39.

[Niehaus and Riedl 2009] Niehaus, J., and Riedl, M. O.

2009. Scenario adaptation: An approach to customizing

computer-based training games and simulations. In Proc. of

the 2009 AIED Workshop on Intelligent Educational Games.

[Porteous and Cavazza 2009] Porteous, J., and Cavazza, M.

2009. Controlling narrative generation with planning tra-

jectories: the role of constraints. In Proceedings of the 2nd

International Conference on Interactive Digital Storytelling.

[Raybourn et al. 2005] Raybourn, E. M.; Deagle, E.; Men-

dini, K.; and Heneghan, J. 2005. Adaptive thinking and

leadership simulation game training for special forces ofﬁ-

cers. In Proceedings of the 2005 Interservice/Industry Train-

ing, Simulation and Education Conference.

[Riedl et al. 2008] Riedl, M. O.; Stern, A.; Dini, D. M.; and

Alderman, J. M. 2008. Dynamic experience management

in virtual worlds for entertainment, education, and training.

International Transactions on System Science and Applica-

tions 3(1):23–42.

[Riedl, Saretto, and Young 2003] Riedl, M. O.; Saretto, C.;

and Young, R. M. 2003. Managing interaction between

users and agents in a multi-agent storytelling environment.

In Proceedings of the 2nd International Conference on Au-

tonomous Agents and Multi-Agent Systems.

[Sharma et al. 2010] Sharma, M.; Onta

on, S.; Mehta, M.;

and Ram, A. 2010. Drama management and player model-

ing for interactive ﬁction games. Computational Intelligence

26(2):183–211.

[Trabasso and van den Broek 1985] Trabasso, T., and

van den Broek, P. 1985. Causal thinking and the representa-

tion of narrative events. Journal of Memory and Language

24:612–630.

[Weld 1994] Weld, D. 1994. An introduction to least com-

mitment planning. AI Magazine 15:27–61.

[Weyhrauch 1997] Weyhrauch, P. 1997. Guiding Interactive

Fiction. Ph.D. Dissertation, Carnegie Mellon University.

[Winegarden and Young 2006] Winegarden, J., and Young,

R. 2006. Distributed interactive narrative planning. In

Proceedings of the 2006 AAAI Spring Symposium on Dis-

tributed Plan and Schedule Management.

[Young et al. 2004] Young, R. M.; Riedl, M. O.; Branly, M.;

Jhala, A.; Martin, R.; and Saretto, C. 2004. An architec-

ture for integrating plan-based behavior generation with in-

teractive game environments. Journal of Game Development

1:51–70.