Redcap

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:

 

 

 

Based on the initial story, the goal is to create an interactive drama where the player plays the Little Red Cap.

In order to achieve high interactivity, the story must be decomposed into small reusable units, that is goals and tasks in the IDtension model. This reusability is essential. For example, if the wolf can disguise himself into the Grand Mother, then the Little Red Cap can disguise herself into the She Wolf, to create an interesting dramatic situation. Similarily, if the wolf can ask Red Cap what she is doing in the forest, the player can ask the same question…

The design consisted in finding a set of goals, tasks and obstacles that could be used (instanciated) in many situations.

The goals implemented in the (unfinished) Little Red Cap story are:

• be at (a place)
• have food
• please grandmother
• know where is (another character)
• know intention (of another character)
• possess (an object)
• look like (another character)
• look oneself
• hunt (a prey)
• get rid of (another character)

To reach each of these goals, one or more task must be created: eat (to have food), offer (to please grandmother), etc.

Obstacles are associated to tasks: "doesn’t like" is considered as an obstacle to "offer", if, for example, Grandmother does not like what the Little Red Cap offers to her.

The most interesting aspect of this scenario is the possibility of disguisement (let another character believe that one is someone else), which is a fundamental aspect of the original story. Unfortunately, this possibility exceeded the current capabilities of the IDtension engine, in terms of knowledge based reasoning and text generation.

IDtension is an Interactive Drama engine without any authoring tool per se. So far, content entering has been performed by the engine’s designers himself (Nicolas Szilas). Here follows the successive tasks that must be performed by the author (AUT) and the IS engineer (ENG), when using the text-based version of IDtension.

Step 1: getting an idea of IDtension.

ENG must provide the author an in depth presentation of IDtension, or AUT must read IDtension ’s papers (Szilas, 2003; Szilas, 2007 – available on request). This introduction must cover the following concepts:

• General goal of IDtension: highly interactive first person Interactive Drama - principle of reciprocity

• Notion of generativity

• algorithmic principle of IDtension: the simulation of narrative – the “mass-spring network” analogy

• General model of narrative underlying IDtension

• Narrative actions

• Goal-task structure

• Narrative effects

• Example simulation

Finally, AUT must of course have played with IDtension as user (demo on "The Mutiny" scenario available on request).

 

Step 2: The setting.

As in many other narrative forms, AUT needs to define the context of the story:

• Where does it take place: a limited number of different places is preferred, because displacements from place to place is not what IDtension is best at. A confined place, such as a train or an apartment is a good choice.

• What are the characters: IDtension is worth handling several characters, like 5 or 6, because it allows more variability in the story. Stories with very few characters should be discarded.

• What is at stake, what are the goals and values of the characters.

• What problems (“conflicts”, to borrow from screenwriting vocabulary) will they encounter

These lines have precise equivalent in IDtension formalism, but in a first phase, especially for the new writer, it is better to start with free text, without formal constraints.

 

Step 3: Describe a scene

AUT should write a scene with characters, including their dialogs. This is a first draft, and probably many of the content will not be finally included, but it guides further authoring. The scene will be described with branching options, even if branching is not explicitely handled in IDtension.

The scene should include motivations of the characters (why they act and react this way).

When AUT will get accustomed to IDtension, s/he will describe the scene in a more structured way, by providing:

• Values: Thematic axis along which each task is morally evaluated. Characters will be more or less attached to the values. Note that values are not simple characters’ attributes, because they allows some judgement.
• Characters: After having decided their names, you must provide the values they will be attached to. Note that if a value exists in the story and a character has not been explicitely attached to this value, then it is considered that the character does not care about this value (attachement 0). Other properties might be useful in some contexts (for example, if being small is a condition of triggering an obstacle). Properties can be discrete or continuous (more or less courageous for example). You must also provide the objects that the character possesses (if relevant for the given scenario).
• Goals: They are the concrete objectives the characters want to achieve in the story. This concept is classical in screenwriting. In IDtension, it is better to have a goal that can be carried out by several characters, to promote the diversity of stories.
• Tasks: they are concrete acts that enable to reach a goal, the mean to reach an end. It is better to have several tasks for the same goal. Tasks must also been thought to illustrate and contrast the values of the story. Reminder: Actions in IDtension are made of tasks, for example encourage someone to perform a given task.
• Obstacles: they are concrete events that make a task fail. They also trigger subgoals: because an obstacle is met, another branch of the story (a goal for the character to aim at) can dynamically open.
   

Step 4: sketching the goal-task structure

From the drafted scene, an initial and minimal structure must be designed. This is a difficult step, because it requires a deep knowledge of IDtension formalism. We strongly recommand this step to be performed by both AUT and ENG. The output is a drawing, such as:

In this drawing is represented several IDtension structural elements organized around a single goal (here "have_food"). Several tasks enable whoever has the goal to reach the goal. But these tasks are hindered by obstacles (red diamonds). Each obstacle has a cause (condition capital letter): when the condition is true, the obstacle will trigger (and make the task fail), with the probability written in red; If the condition is false, it might still trigger, but with the probability written in green. Note that the classical case is "1/0". Note also that these probabilities might be bypassed by the narrative engine, for narrative reasons.

Values are represented by the scale at the left (there could be several values). Some tasks are more or less attached to values, always negatively, meaning that the task violates the value.

There are other data represented in the drawing above that will not be detailed because they are useful for advanced AUT.

There is also a limited amount of data that is not represented in the drawing.

Step 5: program the initial story

First ENG initializes a new story.

ENG, assisted by AUT enters the content into the system, which consists in:

1. an XML file describing the structure. It is equivalent to the drawing mentioned above (but much less readable!). Examples (translated to English for readibility):

For a goal:

    <!–*** Have food ***–>
    <decl_goal>
        <name>have_food</name>
        <importance>1</importance>
        <interested>
            <Character>Shewolf</Character>
            <interest>0.5</interest>
        </interested>       
        <interested>
            <Character>LittleRedCap</Character>
            <interest>-1</interest>
        </interested>
        <interested>
            <Character>Mother</Character>
            <interest>-1</interest>
        </interested>
        <interested>
            <Character>Grandmother</Character>
            <interet>-1</interet>
        </interested>
        <interested>
            <Character>Hunter</Character>
            <interest>-1</interest>
        </interested>                               
        <recurrent>1</recurrent>
    </decl_goal>

This XML declaration of a goal specifies the name of the goal, its general importance for the character who decides to target that goal, the various interest of each character towards that goal (if they are not the actor of the goal) and the fact that the goal is recurrent (once it is reached, it will come again after a certain delay).

For a task:

    <decl_task>
        <name>eat</name>
        <generic_parameter>
            <type>Character</type>
            <name>victim</name>
        </generic_parameter>
       
        <obstacle>not_localised</obstacle>
        <obstacle>believes_not_here</obstacle>
        <obstacle>defense</obstacle>
       
        <association><par_obs>o_localiser</par_obs><par_seg>acteur</par_seg></association>
        <association><par_obs>o_localised</par_obs><par_seg>victim</par_seg></association>
        <association><par_obs>o_believer</par_obs><par_seg>acteur</par_seg></association>
        <association><par_obs>o_absentee</par_obs><par_seg>victim</par_seg></association>
        <association><par_obs>o_defenser</par_obs><par_seg>victim</par_seg></association>
        <association><par_obs>o_attacker</par_obs><par_seg>acteur</par_seg></association>
   
        <starter>Wolf</starter>
       
        <precondition>
            <fact>
                <predicate>Know</predicate>
                <param>actor</param>
                <param><fact>
                        <predicate>Be_at</predicate>
                        <param>victim</param>
                        <param>here</param>
                </fact></param>       
            </fact>
        </precondition>   
       
        <withdrawn_consequences>
            <fact>
                <predicat>Be_at</predicat>
                <param>victim</param>
                <param>here</param>   
            </fact>
        </withdrawn_consequence>
        <added_consequence>
            <fact>
                <predicat>Be_at</predicat>
                <param>victim</param>
                <param>sky</param>   
            </fact>
        </added_consequence>   
       
        <performance_visible/>
       
       
        <reaching_condition>
            <fact>
                <predicat>Savoir</predicat>
                <param>acteur</param>
                <param>victim</param>
            </fact>               
        </reaching_condition>
        <reaching_condition>
            <fact>
                <predicat>Etre</predicat>
                <param>victim</param>
                <param>human</param>
            </fact>               
        </reaching_condition>   
        <reaching_condition>
            <not/>
            <fact>
                <predicat>Be_at</predicat>
                <param>victim</param>
                <param><liste><par>sky</par></liste></param>                   
            </fact>       
        </reaching_condition>   
       
       
        <targetted_goal>have_food</targetted_goal>
       
    </decl_task>

This specifies the name of the task, its parameters, its obstacles, how obstacles’ parameters are matched to tasks’ parameters, who initially knows the existence of the task (starter), its preconditions (beyond the fact of having the corresponding goal in mind), the consequences, the fact that other characters in the scene see the consequence of the task, the rules to attach (and instanciate) the task to the goal, and finally the goal targetted by the task.

The structure also contains the description of obstacles, objects, characters.

 

2. complete the spreadsheet containing all text information, for text generation. Example:

 

infinitive
	neutral
		Eat [victim]
infinitive_victim_speaker
	neutral
		eat me
infinitive_victim_addressee
	neutral
		eat you
infinitive_victim_pdj
	neutral
		eat you
gerund
	neutral
		eating [victim]
gerund_victim_speaker
	neutral
		eating me
gerund_victim_addressee
	neutral
		eating you
gerund_victim_pdj
	neutral
		eating you

 

 

3. Modifying other parameterization files, if needed (for example to add an introduction, change the menu labels, etc.)

 

Then, let’s run the story !

After some authoring bugs corrections, one should have the initial story. Ok, it is basic, but it it the starting point. Now AUT has a better understanding of the process of creation, and can write further.

 

Step 6: content entering

Step 3,4 and 5 can now be repeated. There are a lot of features in IDtension, which requires ENG to be part of the process, until a detailed manual is written.

 

References

• Szilas, N. (2003). IDtension: a narrative engine for Interactive Drama. In S. Göbel  et al. (Eds) Technologies for Interactive Digital Storytelling and Entertainment - proceeedings (TIDSE’03), Darmstadt (Allemagne), 24-26 March 2003.
• Szilas, N. (2007). A Computational Model of an Intelligent Narrator for Interactive Narratives. Applied Artificial Intelligence, 21(8), p. 753-801, Sept. 2007.