Necessity and reincorporation are two views of the same relationship between two events.
It is not sufficient for an interactive drama system to simply provide believable responses to separate player actions. Such an approach may present a very believable virtual world, but it will frequently fail to produce a coherent story that includes the player's diverse actions in that world. Therefore, Marlinspike strives to weave both user actions and authored scenes together to produce a finished story that meets an Aristotelean definition of narrative unity.
More specifically, the events of a finished story can be connected in terms of necessity. That is, if one event must logically precede another, we can say that the first event is necessary for the second event to occur. Another way to look at this same relationship is that if a later event refers back to the contents of an earlier event, then the later event reincorporates the earlier event.
Marlinspike works in terms of reincorporation. It tries to select the next scene to play so as to reincorporate--that is, to narratively build upon--earlier events of the story. When successful, these reincorporations make those earlier events narratively necessary to the finished story.
There are two ways to form reincorporation connections between events in Marlinspike. The first is through a scene's preconditions and hooks: whenever a scene requires or refers to a previous event in its own narrated details, it is considered to be reincorporating that earlier event. The second form of reincorporation occurs through story context triggers: if an earlier scene set a trigger that is involved in casting or recasting the current action, then it means that the earlier scene has some direct relevance to the current action.
We saw each of these connection methods in the earlier Bluebeard example. A scene may have Bluebeard instruct the player not to open a certain closet door. The scene then sets an appropriate trigger to enforce this context. If the player opens the closet, then this trigger produces the DEFY(Bluebeard) sub-event. When this happens, we can say either that the earlier interdiction scene was necessary for the DEFY-ing or that opening the closet reincorporates Bluebeard's interdiction. This DEFY(Bluebeard) action can now serve as a precondition for an enraged Bluebeard scene. By playing this Bluebeard's Wrath scene, the system builds upon the player's action and thus opening the closet becomes necessary to the finished story.
A sequence of reincorporated events like this is called a thread. Threads weave events into a coherent storyline. Every story starts with a beginning scene. This initial thread can be continued by some action building on the context established by this first scene.
However, the player might also start a new thread by performing some unrelated action of high import. As mentioned earlier, every event--whether action or scene--has an import value that suggests how narratively signficant that event is. The current Marlinspike implementation uses import values between 1 and 9. Any event with an import of 4 or higher is significant enough to start its own thread.1
The Marlinspike drama manager can respond to the player and advances the story by choosing the next scene. When a scene plays, it will thread all of the previous events that it can. (Because all of an action's recast sub-events are considered to be part of that event, the whole event is considered to be reincorporated if any of its sub-events is reincorporated.) If these reincorporated events include the last event of only one active thread, the scene simply extends that thread.2 If the events of more than one thread end can serve as preconditions or hooks for the scene, then the drama manager can effectively splice two (or more) threads together into one thread. If the system cannot currently extend the end of any existing thread, it may be forced to fork an earlier thread event, thereby creating a new thread which it will hopefully be able to splice back in later.
This threading behavior is the source of the Marlinspike name, which refers to the splicing and fancy rope work of marlinspike seamanship. This splicing approach also enables Marlinspike to reincorporate significant actions of the player into the story, even when those actions were not related to any preceding events.
In the Figure above, SCENE6 is still pending. If its thread (Thread 1) is not extended before the end of the story, then the story will be poorly-formed, as it contains unnecessary events. However, this evaluation is tempered by the rule that not every action or scene needs to be spliced into a thread, but only those of high import.
As this example also hints, not every Marlinspike story will necessarily be perfectly formed. To operate successfully, the drama manager must be armed with sufficient scenes to reincorporate any player actions of high import. If the implementing game author does not provide these scenes, or if the player is particularly strident about starting new unrelated threads, the resulting stories are not guaranteed to be well-formed. Instead, Marlinspike will do the best it can until it can reach an ending scene.
After each player deed, the Marlinspike drama manager gets a chance to respond by playing a scene. The details of how this next scene is selected are as follows.
The drama manager first polls each scene in its pool to see if the scene can currently play. If all of the scene's preconditions are currently met, the scene returns a list of all the previous events it would reincorporate if it was selected to play at this point. This list includes the scene's precondition events but also any hooks--optional events that the scene will be able to refer to in its narration given the current event history.
The drama manager then scores each scene that can play by summing the following values:
As an example of this scoring process, let's look at the selection of SCENE9 in the previous example.
SCENE9 directly reincorporates ACTION4 and ACTION8. This means the scene extends both Thread 2 and Thread 3, and recursively reincorporates all of the events (material) of those threads: ACTION4, SCENE3, and ACTION2 in Thread 2, and ACTION8, SCENE7, ACTION5, and SCENE1 in Thread 3. This total material includes seven events. The total material might also include any events reincorporated by SCENE9 that are not in any thread (and thus not shown here)--such as certain low import events.
Most of these reincorporated events exist in only one thread, except for ACTION5 and SCENE1, which are part of both Thread 1 and Thread 3. Therefore, the five remaining events--ACTION4, SCENE3, and ACTION2 in Thread 2, and ACTION8 and SCENE7 in Thread 3--form the unique threaded material.
The selection score for SCENE9 would thus be the weight of its total reincorporated material + the weight of the unique threaded material + SCENE9's imperative value. If this total score is higher than than of any other scene that can play, SCENE9 will be selected to play next.
In the prototype implementation of Marlinspike, author imperative and reincorporation can each be switched off. When imperative is off, scene imperative values are ignored while selecting the next scene. When reincorporation is switched off, neither the total reincorporated material nor unique threaded material scores are used during scene selection. In addition, when reincorporation is turned off, scenes should not hook any optional previous events when played. Thus, if both features are turned off, Marlinspike simply selects the next scene randomly from those scenes that have had their preconditions met.
|
Argax Project : Dissertation :
A Rough Draft Node http://www2.hawaii.edu/~ztomasze/argax |
|
Last Edited: 09 Apr 2011 ©2007 by Z. Tomaszewski. |