Redcap

Thespian is multi-agent framework for authoring and simulating interactive narrative.

Egri Lajos has strongly argued for the importance of characters in traditional narratives. His view of narrative — of rich, well motivated, autonomous characters as a creative spark to the author, and is nevertheless constrained by the author’s goals for the plot — serves as inspiration to the approach taken in Thespian. Specifically, a two-layer system is used for simulating interactive narrative.

At the base is a multi-agent system comprised of goal-oriented autonomous agents that realize the characters of the story. A key aspect of this layer is the richness of the agent design that provides motivations, emotions, theory of mind and social norms. The agents in this layer autonomously interact with each other and the character controlled by the user, thereby generating the story.

Above this layer is a director agent that proactively redirects the characters when it foresees future behavior of the agents will endanger the author’s plot design, which can be seen as group goals for the multi-agent system. A key aspect of this layer is that the director agent has access to models of the agents and user. It uses these models to assess whether plot goals are achieved as well as redirect the characters.

In addition to the two-layer simulation system for interactive narrative, Thespian also contains off-line authoring processes to facilitate the author in the design of characters.

The Virtual Storyteller is a story generator based on principles of emergent narrative [1]. There is no predetermined plot; autonomous Character Agents are used to simulate the ‘lives’ of characters in a story world. This yields a particular event sequence (the fabula) that can then be used as a basis for generating and presenting a narrative text. A Character Agent can be replaced by an interface for human participation.

One of the goals of the Virtual Storyteller project is to serve as an experiment in emergent narrative authoring [2]. Authoring here means writing character models and supplying specific actions, goals etc. for a particular story ‘world’. We investigate how an author may think and work to end up with the content and processes that make up such a world.

What is particular about the Virtual Storyteller in comparison to other character-centric approaches, is that it also pays attention to the role that virtual characters can play as "drama managers" of their own stories, inspired by improvisational acting [3]. To this end, the Virtual Storyteller provides support for some out-of-character mechanisms (i.e., mechanisms at the story level). Most notably, the characters in the Virtual Storyteller can justify the adoption of new character goals and support the creation of plans for their goals, by selecting story world events (which are unintentional at the character level) and by filling in the details of the story world setting during execution [4].

The Virtual Storyteller source code is available from SourceForge. More information can be found on the Virtual Storyteller homepage.

Our architecture is based on two components: an Interactive Storytelling rendering and an Interactive Storytelling controller.

The controller aims to manage the unfolding of the history by taking into account the player actions and according to the structure of the narrative pre-defined. The controller is based on a computational model of Interactive Storytelling: Linear Logic. We adapt Greimas analysis to the constraints of Interactive Storytelling.

Greimas was the first to develop narrative formalism as an abstract formula to represent an action (narrative program). He proposed to define an action as a transition from one state to another state where the subject gains or loses an object (conjunctive or disjunctive narrative program).

Linear Logic has been introduced by J.-Y. Girard as a restriction of classical logic. Unlike classical logic, Linear Logic is not used to determine whether an assertion is true or not but rather the validity of how formulas are used (and then consumed) when proving an assertion. Linear Logic is well suited to derive a computational model to partially ordered problems with resource sharing.

The main connector of Linear Logic are:

• ⊸: Implication (imply), express the possibility of deduction. Example: 2€ ⊸ trawberries . Means that I can give 2 € to buy strawberries.
• ⊗: Multiplicative conjunction (times), a set of resources (not ordered). Example: strawberry ⊗ strawberry . Means that there are two different strawberries (strawberry ⊗²)

• ℘: Multiplicative disjunction (par). Example: strawberry ⊗² ℘ strawberry ⊗⁵. Means that there is two set of strawberries (one belongs to Alice and the other one to Bob for instance)

• ⊕: Additive disjunction (plus), external choice. Example: strawberry ⊕ raspberry . Expresses a choice (external to the process). The player can choose strawberry or raspberry 

• &: Additive conjunction (with). Example: strawberry & raspberry . Expresses a choice (internal to the process). The game can choose strawberry or raspberry 

• ⊢: Turnstile, separate the left part (antecedent) and the right part (consequent) of a sequent. Example: D , D ⊸ E ⊢ E Linear implication express the possibility to produce a copy of E by consuming a copy of D AND a copy of D ⊸ E 

A sequent of Linear Logic expresses all the possible narratives of a story. Each narrative corresponds to a proof of the sequent (Proving a sequent consists in rewriting the sequent by making a substitution of the formulas in order to have an initial sequent). As the proof is not unique, we can deduce various narratives.

The following sequent: A, C , D , A ⊗ C ⊸ B ⊗ C , D ⊸ E , E ⊗ C ⊸ F ⊗ C ⊢ B ⊗ C ⊗ F; gives the following proof graph (simplified to the substitution of the linear implication).

It is then possible to compute a sequent by using Petri nets. It has been proved that there is an equivalence between a sequent of Linear Logic and a Petri net (with some restrictions). A token player algorithm is then used to compute the model of Interactive Storytelling.

The goal of the ‘Scenejo’ project is to provide an experimental platform for ‘Interactive Digital Storytelling’, which can be used to experience emerging dialogues or conversations between a number of virtual and human actors. Scenejo connects several A.L.I.C.E. chatbots in a conversational loop of turn taking, which is controlled by a software component called ‘Dramatic Advisor’.

Each virtual actor is modelled as a chatbot, which connects to a meeting point. From the perspective of the meeting point, a human actor (user input) is treated the same way as input from chatbots. For each turn, the meeting point receives ‘acts’ by every actor (bot or user). In the current version, these acts are verbal utterances generated by the chatbots or the user. The dramatic advisor selects one of these acts to be played and sent back to all actors, who then can react and step into the next turn.

By text-chat via a standard keyboard, users can join in the conversation at any time. The system has been tested with a prototype learning game finished in 2007, called the "Killer Phrase Game". The human actor (user/player) has the role of the moderator in a debate between two virtual actors, in which the main challenge is to react upon so-called ‘killer phrases’ uttered by the bots.

Currently the system is not directly downloadable, but the developers are working on a downloadable version. The tool in the recent finished version (of 2007, running the ‘KillerPhraseGame’) is available on request by first contacting the developers. http://www.scenejo.org . The architecture and the authoring process have been described in some papers: Here, and here.

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.

Enigma is an experimental platform for collaborative authoring of the behaviour of autonomous virtual characters in interactive storytelling applications. It originated from our experience in creating character driven interactive storytelling applications like FearNot! [1] in the EU FP6 project ECircus without any supporting authoring technology. The main idea is to overcome the bottleneck of knowledge acquisition that exists in generative interactive storytelling systems through a combination of crowd-sourcing and machine learning.

A client application which can be run directly from the browser allows contributors, who are invited by a principal author (PA) to create/tell a little story within a predefined story universe, e.g. the Little Red Riding Hood Universe. Every story that gets created within this client application will be submitted to a server where many of these stories are collected and processed by machine learning algorithms to infer generative character models that can be used to drive a virtual actor within an interactive drama. These virtual characters can also run in the background while a story is created in the client. This allows the characters to make suggestions at certain points in the story (more about this in [2] and [3]).

User-friendliness of the authoring client is deemed very important if many contributors are expected to be mobilised. Although the end goal is the creation of a database of symbolic story knowledge, we assume that providing this knowledge ex- and implicitly in the process of telling stories will be easier for invited contributors than editing it directly. We however still have to verify this hypothesis through a series of experiments.

For the same reason (user friendliness and appeal) we have decided against a purely text based tool. Instead we opted for visualisation through a comics generation system [4]. Originally we planned to use a 3D graphics authoring interface, but later found that the comics system is a better choice. Using it allows us to have a thin authoring client (The comics are generated on the server side, a URL to the generated picture is returned) that can be easily distributed. Also, we need to represent event sequences within the authoring tool. With the way they are structured (1 panel = 1 event), comics provide a good mechanism for doing that. Finally this form of visualisation allows for uncomplicated graphics content generation independent of any specific tools (characters are represented by a series of annotated head and body pictures, scenes are simply panoramic pictures). Below is a screen shot of the client’s main editing window:

Combined with ontology of characters’ feelings, our latest work on character-based affective Interactive Storytelling aims at reconciling both generation and visualisation philosophies and uses a real-time Heuristic Search Planner (HSP) [Bonet and Geffner, 1999] to generate characters’ actions consistent with their psychology and allowing anytime user interactions [ACII2007] [AAMAS2009].

[Bonet, B., and Geffner, H.: Planning as heuristic search: new results. In: Proceedings of the European Conference on Planning (ECP’99), pp. 360--372 (1999)]

Our authoring environment (as shown above) has been developed subsequently to our proof-of-concept prototypes of emotional planning for IS. Its rationale was to support the authoring of a complex planning domain, by checking its completeness and its consistency. However, since this authoring tool was an interface to the narrative formalism itself [TIDSE06], and that the narrative formalism determined entirely the interactive narrative, it became a candidate for a more generic approach to authoring and authoring methods [ICIDS08]. The integration of new modules could support the collaboration between authors and developers in designing an interactive narrative.

The authoring tool is available for download here and its user documentation is downloadable from here. Note that it requires the Microsoft .NET Framework Version 2.0 Redistributable Package to work, which you can download from here.

IDtension is an Interactive Drama engine and system, designed to provide long term solutions to the problem of combining narrativity and interactivity. More information, including publications, are available at www.idtension.com. A beta version is available, upon request to N. Szilas.

IDtension is based on a narrative-centered goal structure, second order narrative predicates and a model of the user. The architecture of the narrative engine is as follows:

Events are display in the "Theatre" either in a text mode or in a 3D engine (customization of Unreal Tournament 2004). In the 3D case,a Behaviour Engine is also used to tansform high level actions into a set of sequential or parallel low level animations.

Actions are selected according to an innovative history-based interface:

The Cyranus-platform is an authoring framework for conversational interactive storytelling, developed within several projects. For instance, it was employed within the EU-project art-e-fact, “Virtual Humans with Social Intelligence” (a German-US research project commissioned by SAP research), partly within the German research project Virtual Human, and others.

One of the museum aplications that were build with the Cyranus-platform is depicted in the following figure:

One of the requirements of development of the Cyranus-platform was pragmatism. In particular within the art-e-fact project, we had fixed dates for displaying results as working and stable museum installations, so too risky technological experiments were out of question. Thus, the core architecture and the technologies chosen were conservative, and challenging features were built on top of the conservative choices.

The conservative choices were (a) a hierarchical architecture with a central control unit (“Narrator”), with only limited autonomy of the subordinate parts, (b) a directed graph was not the only control module, but it was always available, and (c) for chatting with the keyboard, a chatterbot (ALICE) was adapted.

Innovative features were built on top of these choices. Concerning the authoring process, the most interesting and fruitful development was to allow other control methods to activate states. The hierarchies of the Statechart were employed to encapsulate the range of action of these other control strategies. Thus, it was possible to use an arbitrary number of control strategies in parallel. In practice, we have employed mostly forward-chaining as an alternative.

If the directed graph was employed together with another control strategy, within a composite state of a Statechart, then a delegation chain took place: If the graph could not handle an event, it was handed over to this other control strategy.

With this system, it was possible (i) to combine branching stories with (ii) highly interactive sections displaying (iii) quite intelligent behavior, and (iv) to integrate some state-based chatting with stimulus-response-style chatting.

Concerning the authoring process, another important implication was that the Cyranus-platform allowed for a simple start of the authoring process, employing the directed graph, and then enabled a migration and addition of other control strategies, as the story idea evolves.

The architecture of the platform is as follows: