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:
- 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.
-
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 |
-
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