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.

Decision-theoretic goal-based agents are used for modeling each character in the story, with the character’s motivations encoded as the agent’s goals. Each agent has multiple and potentially competing goals, e.g. keeping safe vs. keeping others safe, that can have different relative importance or preferences. Thespian agents have recursive beliefs about self and others, e.g. my belief about your belief about my goals, which forms a  "Theory of Mind".

The "Theory of Mind" capacity enables the agents to reason about others when making their own decision, and thus makes them "social characters". To make the agents’ behaviors more human-like and socially aware, Thespian models social normative behaviors and emotion. By default, Thespian agents act following norms, unless they have other more impressing goals.

When deciding what to do, a bounded lookahead policy is used by the agents. They project limited steps into the future, considering not only their own actions, but also other characters’ responses using their mental models of other characters, and its responses in return. The agents choose the action that receives the highest expected reward to proceed. Thus, they act both true to their motivations and in reaction to the status of the interaction.

For example, in the scenario shown above, the wolf will react to Red differently depending on whether there is somebody else close by, and who is that. The wolf will choose different actions when the hunter is near and when the woodcutter is near, because the wolf has different mental models about these two characters.

The user is also modeled using a Thespian agent based on the character whom the user takes the role of. In modeling the user, not only the goals of the user’s character are considered, but also the goals associated with game play. This model allows other agents to form mental models about the user the same way as about other characters and the director agent to reason about the user’s beliefs and experience.

Plot Design

Thespian provides a proactive directorial control approach, which coordinates the agent’s behaviors without breaking their motivations for reaching the author’s desired affects. Its director agent projects into the future for detecting potential violations of the author’s directorial goals, which is expressed as partial order or temporal constraints on key events in the story. An event can be either an action from a character or a state of a character including the user. An example of directorial goal is given below.

orders = [[“Wolf knows Granny’s location”, “Wolf eats Granny”], [“Wolf eats Granny”, “Wolf eats Red”]]

earlierThan = [“Wolf knows Granny’s location”, 10]

laterThan2 = [“Wolf knows Granny’s location”, 10, “Wolf eats Granny”]

earlierThan2 = [“Wolf eats Granny”, 3, “Wolf eats Red”]

If the director agent detects a potential violation, it explores alternative methods for tweaking the characters’ behavior and to reach the directorial goals. The director agent takes a least commitment approach to coordinating the agent-characters. During the interaction, the director agent maintains a space of character configurations consistent with the characters’ prior behavior. Each of these configurations is equally valid in the sense that they will all drive the character to act in exactly the same way up to the current point of the interaction. When a future violation of the plot design is predicted by the director, it constrains that space so that the rest of the configurations will drive the agent to act in a way that eliminates the violation. In this way, from the user’s perspective the characters are always well-motivated and the user can interact freely with them.

http://people.ict.usc.edu/~meisi/Red/LRRH%20Examples.htm

Authoring Interface I:

For authors who are comfortable writing codes, the agents can be directly coded. For example, following is a definition of an agent, including its horizon and depth of reasoning, actions, state features, goals and beliefs.

classHierarchy['NormAgent'] = {
    ‘horizon’:3,
    ‘depth’:2,
    ’state’:{\
             ‘init-norm’:0.00000000000000001,
             ‘resp-norm’:0.00000000000000001,
             …
            ‘being-greeted’:0.0,
             …
            ‘conversation’:0.0,
             },
 
   ‘actions’: {’type’:'XOR’,
                 ‘key’:'type’,
                  ‘values’:[{'type':'literal','value':'greet-init'},
                    {'type':'literal','value':'greet-resp'},
                  ...
                 'base': {'type':'XOR',
                         'key':'object',
                         'values':[{'type':'literal','value':'cha'},
                                   ],
                         },
                },
    ‘goals’:[\
                {'entity':    ['self'],
                                  ‘direction’: ‘max’,
                                  ‘type’:      ’state’,
                                  ‘key’:   ‘init-norm’,
                                  ‘weight’:    .5},

                 {’entity’:  ['self'],
                                ‘direction’:'max’,
                                ‘type’:’state’,
                                ‘key’:'likeTalk’,
                                ‘weight’:.1},

             …
    }}
 

Authoring Interface II:

Alternatively, the author can use a graphic interface for defining the agents.

All the components defined in the above example can be inputted through this interface.

Authoring Interface III:

Finally, project specific format for text input can be defined. Part of the agent modeling is done within Thespian (in the code that supports the interpretation of the text input), the author only need to change a few parameters for defining the agents.For example, below is a text file that define two agents who negociate with each other. The two agents have differnt goals in terms of how much they care about themselves vs. care about the other person’s experience. They may also have different beliefs about the other person’s goals.

To further faciliatate authoring, Thespian can simulate potential users’ behaviors and generate all the potential interaction paths.

An additional program is developped in Unity game engine to help the author view and edit the paths, as well as supply surface sentencs to the dialogue acts.

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.

1. Letting go of the idea to reproduce the original story.
2. Trying to implement some of the physical and psychological processes that one can believe to drive the LRRH world and its characters.

The following describes the small story world that was created for the LRRH authoring workshop at ICIDS ‘08. We followed an iterative authoring cycle, using the LRRH story as inspiration for authoring decisions made along the way. The idea is also to use feedback of the simulation as further inspiration for new content.

We created three character agents to play the roles of Little Red Riding Hood (Red), Grandma, and Wolf. To enable a tight feedback loop between authoring and simulation outcomes, we started with a simple and minimal design of a story world (e.g., one goal and actions that can achieve it, so that the planner can turn these actions into a goal plan). The initial setup of the story world contained the goal (and accompanying actions) to bring a cake to Grandma. To enable the expression of this goal, a small story world geography was authored (a path from Red’s house to the forest, and from the forest to Grandma’s house) along with some actions (to skip from one location to another, and to give something to someone). This world is depicted here (images created by hand):

First cycle

A predictable story "emerged" during simulation: Red skipped to the forest, then to Grandma’s house, and gave her the cake. We chose to author content so that Grandma would eat the cake, and also wanted to enable Wolf to eat the cake, by stealing it. So we added a goal to eat something, and an action to take something from someone else. To enable justification of this goal, we added an event to become hungry.

Second cycle

In the simulation, both Grandma and Wolf could not adopt any goals: for them, the preconditions for available goals did not match the initial state of the story world. So they attempted to justify goals (out-of-character) by selecting the event to become hungry. On her way to Grandma, Red met Wolf, who had adopted the goal to eat something and took the cake from Red. However, since Red still wanted to bring the cake to Grandma, she took back the cake from Wolf. Wolf still wanted to eat the cake, so again took the cake from Red. This "cake fight" continued until Red skipped to Grandma’s house before Wolf managed to take the cake from her. Then, a similar situation occurred with Grandma who did not know that Red was going to give her the cake. Because she was hungry, Grandma took the cake from Red. This also happened to solve Reds goal that Grandma had the cake. Now Red had no more goals to adopt, so she selected the event to become hungry and adopted the goal to eat something. This caused Red to take back the cake from Grandma, and eat it herself.

Some of this behaviour was expected, some was surprising and inspiring (e.g., Red could be an assertive girl), and some was undesired, resulting from a domain underspecification: only mean persons take something from someone when it does not belong to them; nice people ask. Furthermore, if the cake can be taken away from Red without the possibility of taking it back (e.g., if Red is not mean), a response is needed to this event. We chose to have Red cry as a plausible dramatic response for little girls.

So in the implementation phase, we added a framing operator that can endow a character to be mean; we further chose that only one character in the story world can be mean. We added a "cry" reactive action, triggered by someone taking something from a character without the character’s consent. We chose to constrain the crying reactive action trigger so that it is only applicable to little girls (although it would be fun if the wolf would cry too if someone stole something from him).
 
Third cycle

In the simulation, Wolf framed himself to be mean (out-of-character, using the framing operator), so that he could plan to take away the cake from Red. After this mean action from Wolf, Red started crying. This was as expected. As authors, we considered how the simulation might continue at this point. Red might go to Grandma to seek support. In revenge, Grandma might poison a cake and feed it to Wolf. We considered how this might open up possibilities in the simulation for the cake to be poisoned by Red in an attempt to poison Grandma in case Red happens to be the mean one (an idea was to add a goal specifying that mean characters try to poison others). Wolf might be allowed to satisfy his hunger by eating Grandma, or by following Red and eating them both. Red might be given the option to be distrustful and avoid interaction with Wolf. 

We only implemented one of these ideas. We added a goal to seek support and added speech actions for Red to tell Grandma what happened, and to ask her what to do. We also added a goal for Grandma to avenge her granddaughter by poisoning the wrongdoer, and actions that allowed a goal plan. Grandma baked a cake, poisoned it, went up to the wolf and gave him the cake. The wolf, being hungry again, ate it and died. Red and Grandma lived happily ever after.

Rather, we conceive of the creation process in The Virtual Storyteller as a continuous cycle of writing content, seeing what the system makes of this content, and coming up with new ideas. An authoring paradigma that has proven useful is to not only correct the system if it is not doing what was expected (’debugging’), but also to accept that the system may take the space of potential stories in directions not initially considered (’co-creation’) [1].

In this process, it is considered important to maintain a tight feedback loop between the steps, making small, incremental changes to the content. Furthermore, it is considered important to actively consider whether certain content can be reused in other situatons. This helps create density of the space of stories.

Content to be created

What needs to be created for a particular story domain? Let’s consider the simple case in which we re-use domain-independent parts of the character models (such as event appraisal and action planning) for a new story domain. In this case, authoring consists of a set of knowledge representations:

This knowledge is currently created as a combination of RDF/Turtle syntax (setting), RDF/OWL knowledge edited in the Protégé tool (ontology) and Prolog files (goals, actions, etc). Eventually we would like to have a tool that supports authoring, for instance by presenting pre-defined fields, checking syntax and semantics, providing visual organisation of the content, and checking interrelatedness of content (e.g. actions that can be strung together in a plan but also, e.g., finding goals that can never occur).

Example setting

Example of the setting of the LRRH world (in RDF/Turtle):

# Little Red Riding Hood
:red
    a   red:LittleGirl ;
    swc:at      :reds_house ; 
    swc:has     :birthday_cake ;
    swc:owns    :birthday_cake ;
    rdfs:label  "Little Red Riding Hood" .

# The forest   
:forest
    a   red:Forest ;
    rdfs:label "the forest" ;
    .

# Path from Red’s house to forest
:forest_path1a
    a   swc:Path ;
    swc:from    :reds_house ;
    swc:to      :forest ;
    rdfs:label  "the path leading to the forest" .

Example action

Example action for taking something from someone (in Prolog): 

  action_schema([
    type(red:'TakeFrom'),
    arguments([agens(Agens), patiens(Patiens), target(Target)]),
    duration(1),
    preconditions([
        % Two different characters and a location
        condition(true, [
            rule(Agens, owlr:isNot, Target),
            rule(Agens, owlr:typeOrSubType, swc:'Character'),
            rule(Target, owlr:typeOrSubType, swc:'Character'),
            rule(Loc, owlr:typeOrSubType, swc:'Location')
        ]), 
        % Agens (who executes the action) is mean
        condition(true, [
            fact(Agens, swc:hasAttribute, red:mean)
        ]),       
        % Target has the thing
        condition(true, [
            fact(Target, swc:has, Patiens)
        ]),
        % Agens does not own the thing (otherwise, this is TakeBack)
        condition(false, [
            fact(Agens, swc:owns, Patiens)
        ]),
        % At the same location
        condition(true, [
            fact(Agens, swc:at, Loc),
            fact(Target, swc:at, Loc)           
        ])    
    ]),
    effects([
        % Agens has the thing
        condition(true, [
            fact(Agens, swc:has, Patiens)
         ]),
         % Target no longer has the thing
         condition(false, [
            fact(Target, swc:has, Patiens)
         ])
    ])
  ]).

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 storyworld (character, setting, etc.):  the Little Red Riding Hood history. The Little Red Riding Hood, the mother, the grandmother, the wolf, the hunters, a wood between the two houses, a cake and a little pot of butter.

The player is cast as the Little Red Riding Hood and act within the time and space of the fictional world of the Little Red Riding Hood history.

Three possible narratives :

- N1: Folk tales: based on Grimms’ narrative. The Little Red Riding Hood walks through the woods to deliver food to her sick grandmother. The wolf wants to eat her, and goes to the grandmother house. A hunter help her to kill the wolf.

- N2: Fairy tales: a witch put a spell on the little Red Riding Hood. She has one day to marry a prince otherwise she will become a dwarf. The wolf, who is a princess that was put a spell, fells in love with the Little Red Ridding Hood and try to seduce her. Finally the Little Red Riding Hood gives a kiss to the wolf that becomes a wonderful prince. They get married, etc.

- N3: Action tales: the Little Red Ridding Hood wants to kill the wolf. The wolf escapes and meets hunter that protect him against the Little Red Riding Hood. The Wolf encounter Grandmother, take her as hostage, and there is a final fight. The Little Red Riding kills the wolf.

Each narrative follows a basic structure:

1- Introduction

2- The task

3- Encounter with the Wolf

4- The two ways

5- The Wolf and the Grandmother

6- Arrival of Little Red Ridding Hood

7- First dialogue

8- Second dialogue

9- Conclusion