Argax Project:: Dissertation: A Rough Draft Node

Node Status: COMPLETE

Drama Manager versus the World

The Marlinspike design assumes that there are actions performed by the player character (PC) and scenes played by the drama manager (DM). This PC-centric notion of actions grew from the way Inform works, where the default actor for all deeds is the player. Inform's narration generally assumes this. Thus, in the initial design, deeds and actions would come only from the player; all other world state changes and NPC manipulations would be performed within scenes. This approach quickly became untenable.

State Management

The reason for this is that scenes became a nightmare of state management. For example, if one NPC supports a plan during the course of a scene, that scene would then be obligated to update the affinities of all listening NPCs that were affected by that proposal. This leads to duplicated code between all the scenes in which an NPC supports a plan.

Yet there already exists a SUPPORT action that correctly produces of all these same effects when the PC proposes a plan. Therefore, I very quickly broadened the design so that any character--not just the PC--could be the actor of an action event. However, NPC actions still only occur within the bounds of scenes. Besides reusing the code that produces the action's effect, an NPC's action event can also be added as a sub-event of the scene itself. This is useful in providing a more detailed system view of each internal effect of a scene.

Aside from character state management, scenes also had to update world-level states. The most challenging example of this was directing NPC motion. For example, when the GoParty departs, other NPCs in the gondola come to see them leave. Similarly, if the GoParty is moving without the PC present, it will go to certain rooms in the Zeppelin and then return. Performing this motion is very tricky, though. First, only those NPCs that are conscious and active should be moved. If any doors intervene, they need to be currently unlocked or at least unlockable from the side the NPC is on. The door must then be unlocked and opened (so that the NPC does not appear to teleport out of locked rooms), but only if necessary. Then the NPC needs to move to her intended destination. But this should be narrated (differently) if the NPC is leaving from the PC's location, passing through the PC's location, or arriving at the PC's location. If the NPC never passes the PC during its motion, then her behavior is completely offscreen and should not be narrated at all. If more than one NPC is arriving at a time, it reads better to list this as a single event, rather than narrating each arrival separately. In short, there is a great deal of attention required to tiny details if the author wants to present a consistent and believable world. Consistency is important, since if one scene leaves the world in an illogical state, it can indirectly affect the correct behavior of later scenes.

A partial solution to this headache is to implement well-defined deeds for NPCs. (Demeter did this only partially.) This way, error-checking and execution of NPC deeds in the world can be centralized and controlled in a single code location. It would then be possible to define things like a path-finding script from a source room to a destination room in terms of these deeds. To do this, the performance of these NPC deeds should then be disconnected from their narration so that they can occur silently offscreen when necessary.

A further advantage of having NPCs perform all actions through deeds is that scenes could be authored explicitly in these terms. Every NPC deed would then be explicitly modelled in the resulting story structure as a part of that scene. These deeds could then be recast by the same mechanism that applies to player actions. This is an important next step in the development of Marlinspike in order to ease the complexity of the authorial burden. Such an approach would also open the way to system generation of scenes as scripts of deeds.

Attempted Actions

The drama manager is given a chance to deny any deed performed by the player. This was necessary for such scenes as Impromptu_GoParty and GoParty_Departs. Should the player try to leave the gondola before a GoParty has been formed, the player's Go deed is prevented in the world. This deed is then cast as an ATTEMPT instead of its normal TRAVEL action. Then one of these two scenes plays to explain why the player did not successfully leave the room: because other NPCs entered the room to either join the PC or see him off.

In practice, interruptions of the player by the drama manager are rare. And supporting them means the connection between the world and the drama manager is fairly complex. Before any deed executes in the world, the world first needs to determine whether the deed would be successful. But it must then pause before actually completing the deed to check whether the drama manager wishes to prevent it. The complexity of this approach is a major obstacle to implementing the drama manager as a separate program that communicates with the story world through only a simple software bridge. Another approach is needed--either a way to author stories with no player deed interruptions or else a way to perform those interruptions at a world level rather than through the drama manager.

Related to this, I learned that sometimes even non-interrupted failures are important actions. In the current implementation, only successful (or rather, about-to-be-successful) deeds are reported to the drama manager. This means certain actions--such as trying to open a locked door--are not reported by default, since the world knows that the deed is going to fail (even if the user does not). But this creates a disconnect between the user's input (and thus the user's conception of the story) and the story-level representation of the story. Also, attempts are often important to the story too: In Demeter, attempting to open the command gondola hatch was cast as supporting a certain kind of plan and thus prompted replies from nearby NPCs--even though the underlying Open(hatch) deed was not successful. This change to report deed failures as well as successes requires a bit more complexity--the world would need to report not only the deed but also whether it is about to succeed or fail--but it would be worthwhile in the next version of Marlinspike.

Narration

As suggested in relation to some of the limitations described above, providing accurate, well-formatted, readable narration in this implementation was not particularly easy.

First of all, there is a great deal of detail modelled by the system that is not easy to narrate in text that is explicitly descriptive yet not tedious. This is particularly true when narrating character affinities and story structure connections, which I will discuss in more detail later in this chapter. As an author, this difficulty leads to a feeling of opacity: I have modelled all of these details, but many of them are not apparent to the player.

This is partly due to an artistic choice in how I narrated the game. As author, I wanted a kind of limited, rather than omniscient, narration that portrays the world as the player would experience it if actually there. This was meant to heighten the tension, as appropriate for a horror game. For example, as a player, you may hear a hatch open somewhere offscreen, but you wouldn't know, based on the sound alone, which hatch it was or who--or what!--opened it. An alternative would be to explicitly state these details: "You hear Elijah Roman open the hatch to the passenger gondola." This is certainly more explicit, but it may strain credibility if you cannot see either the hatch or Elijah Roman from your current location. (Also, since these objects are currently offscreen, you cannot refer to them in any typed commands, which leads back to the issue of affordances discussed earlier.)

This explicitness in narration could be extended to also explaining causality, such as "The revenant enters through the door you left unlocked" or "Because he wants to hunt the revenant, John Winters proposes that a search party be formed." This is a tricky balance to strike as author. Such explicitness reduces the opacity I was just lamenting, but it also violates the advice that good narration should show, not tell, the reader what is happening. There does not seem to be a clear answer to this issue.

Finally, narration sometimes needs to be disconnected from the events it describes. As mentioned, frequently NPCs are operating offscreen. These offscreen deeds are often not narrated at all, but sometimes they are narrated in different ways. For example, in Demeter, when an offscreen NPC is attacked by the revenant, the PC will hear the NPC scream. He may also hear the fall of a body or the opening or closing of a hatch. This is quite different narration than would be given for these same deeds if the PC was present to witness them directly. Thus, if NPC deeds are used as a future means of authoring NPC behavior, the narration of those deeds will need to be separately customizable based on the location and condition of the PC.

==>

ToDo

Flow chart for the state management issue?