Redcap

Basic Information

PaSSAGE (Player-Specific Stories via Automatically Generated Events) is an interactive storytelling system whose primary goal is to take advantage of the wealth of feedback that the audience of an interactive story provides [1,2].  By automatically learning the preferences of its audience, PaSSAGE aims to maximize the quality of its stories on a person by person basis, providing each player with the particular sequence of events that he or she will enjoy the most.

David Thue created PaSSAGE as his M.Sc. thesis project in 2006, and it is currently the focus of his Ph.D. research. It is implemented in BioWare Corp.’s Aurora Neverwinter Toolset, the software tool used to create the successful computer role-playing game, Neverwinter Nights.  Although PaSSAGE is not yet available to the public, interested writers and/or researchers are encouraged to either visit the project website (http://www.playpassage.com), consult our publications (links below), or contact the authors directly.

Architecture Description

The primary distinguishing features of PaSSAGE are that it learns about its players while they experience its stories, and it allows authors to use what it learns to inform a wide variety of story-related decisions, through a paradigm called "Delayed Authoring" [3].  By allowing Delayed Authoring, PaSSAGE aims to grant its authors the ability to delay their decisions concerning story content for as long as possible, and particularly past the time at which a given player’s story begins.  By waiting to decide about story content until right before the content is needed, authors gain the benefit of having the extra, player-specific information that PaSSAGE has learned during the story so far.  In this sense, PaSSAGE is designed to act as a decision-making proxy for its authors; they describe how a decision should be made for different types of players, and then PaSSAGE carries out their decision once a player’s type has been learned. For example, concerning a particular event in the story, PaSSAGE allows its authors to delay the following types of decisions:

• What should happen?
• How should it happen?
• When should it happen?
• Where should it happen?
• Who should be involved?
• Why should actors act as they do?

PaSSAGE includes three mechanisms for making these decisions as a proxy for its authors: Courses of Action, Triggers, and Role Passing.

Courses of Action: Deciding What and How

When a new event is needed for the story (perhaps to comply with an author-specified schedule), PaSSAGE chooses from a library of potential story events, each of which contains one or more courses of action for the player to take.  Courses of action describe the different ways in which a player might respond to a particular story event, while that event is taking place.  While courses of action are similar to the branches of typical story-tree representations, the main difference between the two is that story-tree branches typically correspond to player action *between* story events, while courses of action correspond to player action *within* story events.  For each course of action, authors must describe the characteristics of the type of players who they expect would enjoy taking it more than the others.  These descriptions are attached as annotations on each event, and then used by PaSSAGE during the story to select events that its particular current player will enjoy.  Once an event begins, each course of action therein becomes available to the player;  allowing players to choose between them is crucial to PaSSAGE’s operation, as such player choices are what allow PaSSAGE to learn its players’ preferences.  Given that PaSSAGE can estimate which of the available courses of action best suits its current player, it is also able to modify the actions of the event (affecting How it occurs) to steer the player toward taking that course of action.  For example, if PaSSAGE learns that a player enjoys combat, then the non-player characters in an event can be made to attempt to start a fight.

Triggers: Deciding When and Where

PaSSAGE’s stories are set in a simulated world, and this allows the occurrence of events to be triggered by various aspects of the current world state.  Triggers monitor the world state, repeatedly testing one or more conditions; each condition describes an aspect of the world state that is necessary for the trigger’s associated event to occur.  In particular, triggers concerning the location of the player or non-player characters can be used to ensure that events only occur at appropriate times.  For example, one might create a trigger to ensure that a robbery-themed event only begins to unfold when the player arrives at the local bank.  If the robbery event were authored to support happening in more than one bank, then PaSSAGE could be used to decide where the robbery should happen, in addition to when. 

Role Passing: Deciding Who and Why

Given a simulated world populated by non-player characters, PaSSAGE allows authors to delay the decision of which characters should play the roles in its events.  Roles in PaSSAGE are similar to scripts received by the actors of a play; they describe the behaviour and dialogue that a character should perform when cast into that role.  By specifying a set of conditions which describe the set of character properties that a given role requires, authors can delay deciding which character should play that role until just before its actions must be performed.  As a result of doing so, PaSSAGE gains the opportunity to choose a character for the role based on the player’s prior interactions with various characters in the world.  For example, a role created to antagonize the player could be filled by a character with whom the player had previously had an unfriendly encounter. 

Story Structure: The Monomyth

To provide narrative structure to its stories, PaSSAGE currently draws from the form of Joseph Campbell’s monomyth, which describes a general sequence of events that makes up a heroic journey [4].  For each phase of the monomyth, PaSSAGE requires a set of events that could potentially occur during that phase; for example, the "Call to Adventure" phase contains events which feature different motivations for a hero (PaSSAGE’s player) to venture out into the world and begin an adventure. 

Telling a Story: The Event Cycle

PaSSAGE’s stories begin with an event from the first phase of the monomyth, "Home", during which the player begins to learn about the story’s setting, and PaSSAGE begins to learn about the player’s preferences.  When the player completes a phase of the monomyth, PaSSAGE chooses the event from the next phase whose annotations best match its model of the player’s preferences, and begins checking that event’s triggers and searching for actors to play its roles.  The event begins when all of the triggers’ conditions are satisfied, at which time the event’s actors assume the needed dialogue and behaviours via role passing.  PaSSAGE hints at its estimated "best" course of action for the player as the event unfolds, and updates its model as the player performs actions in response to the event.  When the current event is complete, the process repeats, until an event from the final phase is selected and the story is complete.

References

[1] David Thue, Vadim Bulitko, Marcia Spetch, and Eric Wasylishen. Interactive Storytelling: A Player Modelling Approach. The Third Conference on Artificial Intelligence and Interactive Digital Entertainment (AIIDE). pp. 43-48. Stanford, California, USA. June 6, 2007.

[2] David Thue, Vadim Bulitko, Marcia Spetch, Eric Wasylishen. Learning Player Preferences to Inform Delayed Authoring. Papers from the AAAI Fall Symposium on Intelligent Narrative Technologies. FS-07-05: pp. 158-161. AAAI Press. Arlington, Virginia, USA. November 9, 2007.

[3] David Thue, Vadim Bulitko, Marcia Spetch. Making Stories Player-Specific: Delayed Authoring in Interactive Storytelling. The First Joint International Conference on Interactive Digital Storytelling (ICIDS): pp. 230-241. Erfurt, Germany. November 26, 2008.

[4] Joseph Campbell. 1949. The Hero with a Thousand Faces. Princeton University Press.

Using PaSSAGE, we adapted the Little Red Riding Hood (LRRH) to fit the structure of Joseph Campbell’s monomyth.  The terms in quotes below (such as "Home" or "Trial") indicate the phases of the monomyth that have been written for so far. 

In the PaSSAGE version of LRRH, Red (as the player) starts off at "Home" and gets "Called to Adventure" (Mother asks her to deliver medicine to Grandma’s house). She then faces a "Guardian at the Threshold" between her world and beyond (meeting the Wolf at the forest’s edge), and overcomes a minor "Trial" along the way forward (picking flowers for Grandma). Upon reaching Grandma’s house, Red suffers an "Ordeal" at the hands of the Wolf, after which she and Grandma are ultimately rescued by the Woodsman, ending the story.

PaSSAGE adds interactivity to LRRH by expanding the set of possible events for each phase of the story, and choosing between them based on its learned model of the current player’s preferences. For example, instead of a mission of mercy (to go help Grandma) as their "Call to Adventure", reward-seeking players might learn of a merchant in the next town who will pay handsomely for the delivery of a load of local goods; instead a mission to pick flowers, a more combative player might find bandits waiting in ambush as their "Trial" to overcome. Furthermore, to dynamically choose which actors should play the roles of the bandits in the forest, PaSSAGE draws from the set of non-player characters in Red’s village, preferentially choosing those with whom Red (again, as the player) had previously established an unfriendly rapport.  Thus far, we have created two alternative events for each phase and five possible story endings, allowing for twenty different experiences in terms of sequences of events, and even more variation when different characters are cast for the events’ roles. Try it out at ICIDS’09!
 

Consider the scene in the Little Red Riding Hood where Red first encounters the Wolf.  In PaSSAGE’s version, one of two different scenes will occur, as selected based on what PaSSAGE has learned about the player’s preferences thus far in the story: either the traditional event (where the Wolf sends Red to find some flowers), or an alternative event (where the Wolf attempts to convince Red to help him capture the Woodsman) will occur.  For the reader’s familiarity, suppose that PaSSAGE selects the traditional event.  The Wolf initially blocks Red’s entry into the forest, and when Red first asks to pass by, the Wolf attempts to delay her.  At this point, she is given two options - to continue to listen to the Wolf’s story (indicating a preference for detailed plots), or provoke the Wolf into fighting her (indicating a preference for combat).  Based on this choice (and others), PaSSAGE learns a bit more about the player’s preferences, and updates its player model accordingly.  Furthermore, this particular section of dialogue includes a mechanism for steering players who prefer combat along the event’s more fighting-oriented course of action.  In the figure below, players who prefer fighting see the character speech and options to respond on the left, while all other players see the content on the right (in our particular implementation, the Wolf is replaced by a Troll).

Overview

Story events for PaSSAGE are created using the Aurora Neverwinter Toolset, the content creation tool that is included with Neverwinter Nights, a computer role-playing game by BioWare Corp.  Required skills for authors include beginner to intermediate level programming skills, and familiarity with using dialogue trees and navigating 3-dimensional environments is beneficial.

Each event in PaSSAGE exists primarily as a collection of scripts and conversations. 

Scripts

Scripts are pieces of program code that describe the courses of action, triggers, conditions for role passing, hints for player steering, and character actions for events. The following script controls the actions that the Wolf (in our case, a Troll) performs when Red provokes him into fighting her: we retrieve the actor playing the role of "guardian" in this event, cancel the player’s current conversation, make the Troll speak a few lines, cause the Troll to attack the player, and then set a flag to record that the combat has occurred.

Conversations

Conversations are collections of lines of dialogue that are organized into a tree; every odd (red) layer of the tree (treating the Root as layer #0) is a non-player character line, while every even (blue) layer contains one or more lines for the player to choose from.  The figure below shows an section of the conversation tree for Red’s first encounter with the Wolf (in our case, a Troll).

Creating an Event

In addition to actor actions and lines of dialogue in conversations, events additionally need three more types of scripts: adjustments to the player model in response to player actions, annotations for each course of action stating which types of player will prefer each course, and specifications of what conditions to check before role passing occurs.

Adjustments to the Player Model

In the figure of the conversation tree above, the highlighted line has been associated with a script which increases the player’s preference toward combat (the variable PM_FIGHT is increased by a large amount).

Annotations for each Course of Action

The figure below shows how the two courses of action ("branches") in the example event are annotated.  In this case, the "Ingredient" branch has been annotated as being very good for players who are Tacticians (who enjoy solving puzzles) and Power Gamers (who enjoy increasing their character’s wealth and power).

Conditions for Role Passing

This figure shows an example of the conditions which must be satisfied by an actor before it may play the role of Threshold Guardian in this event; in this case, it must be a creature in the class "guardian", and it must be closer than five meters to the player before any action will take place.

Final Step: Add the Event to a Set

The final step in creating an event is to add it to one of the event sets that is associated with the phases of Campbell’s monomyth, as shown in the figure below.