http://www2.hawaii.edu/~ztomasze/argax
©2011 by Z. Tomaszewski.
So far I have covered many of low-level details involved in Marlinspike and Demeter. But what of the stories produced by the finished system? This section explores the nature of those complete stories, especially in relation to how they are authored.
A story is primarily a series of events, and so we often think of a story as a sequential, linear, path-like thing.1 And so, when we begin to conceptualize an interactive story--or any story in which choices could have lead to a different series of events--we think of it as a branching tree of possible story paths. There is a single path through this tree structure taken by the actual story, but at each point that a significant choice is made, we can also trace the other potential, untravelled story paths stretching away in different directions.
An interactive story can be explicitly authored this way as a series of choices that produce a branching tree of narrative paths. The Choose Your Own Adventure book series did exactly this. However, this approach does not scale well. If each choice were only binary, and a story includes only ten such choices that each lead to a truly unique outcome, it would be necessary to author 210, or 1024 different story paths!
The scene-based approach used by Marlinspike was meant to overcome the authorial burden of this explicit branching-tree approach. If scenes are modular and can be mixed-and-matched at run-time to produce a story, then the author does not need to compose so many complete stories.
But, even when the story is not generated by explicitly using a branching tree, I find I still tend to think of the resulting structure in a branching-tree way: "What would have happened if the player had made a different choice or performed a different action at this point?" And so elements of this mental framework persisted while authoring Demeter.
First of all, the body of most scenes is a fairly complex series of if statements. Most scenes are so internally complex as it to take several days (about 15 hours of coding) to author and that long again to adequately test all the possible branches.
Authoring Demeter's tutorial further highlighted this. Because most of the tutorial scenes provide a paragraph or two of instruction and then prompt the user to perform a particular action, the bulk of them took only about 20 minutes each. So scenes are not necessarily complex.
The exception to this in the tutorial was Miriam_Acts, a scene in which an NPC responds to what the player did. The point of this scene is that Miriam will try to reclaim her lost novel and then return to bed. There are four different ways this scene can be prompted to play: the PC waits, leaves, says goodnight, or does some action other than looking around or conversing with Miriam. Then Miriam will try to get her book. There are five possible states there: she already has it, the PC has it, it is somewhere she can get it (with a special case for finding it in the toilet), or it is gone (actually flushed down the toilet). Additionally, for any case where the book does exist, it could now be soggy from being in the toilet (three more possibilities). And, if the player has it, he can refuse to give it up when asked (1 more possibility). So this single scene that results in a paragraph or so of text took about 6 hours to write, and over 30 different permutations of its output are possible.
This scene is a better example of a typical scene. It it is also a reminder that many potentially interesting story paths--such as what happens if you put someone else's book into the toilet--are frequently not explored by users. Of the 40 or so of the game sessions I have seen, no player has ever tried this on their own.
So the branching structure remains within scenes. Between scenes, the structure is only implicit. Scene preconditions force a necessary order between certain scenes. First of all, beginning, middle, and ending scenes impose simple limitations on where they can play in a story. Other scenes have logical relationships that require one scene come before another. For example, it is not possible to conclude a discussion before beginning one. The GoParty cannot depart the passenger gondola until after it has been formed. Other restrictions are emergent. Since the player starts in the passenger gondola, and the revenant does not enter the gondola until nightfall, it is not possible to immediately encounter the revenant in the first few events of the story.
As discussed when describing Demeter, these different scene preconditions do produce a general Discussion - Exploration - Waiting story structure. But any particular scene or even one of these stages can be skipped. And it is possible to explore before any discussion occurs.
So one of Marlinspike's design goals was successfully met: The story was not produced as a simple branching tree of story paths. Instead, it is dynamically built at runtime. But the branching tree structure is still evident within scenes. And, as author, I still think of potential stories in this way. For example, when testing all the possible contexts in which a particular scene might play, I still find myself trying to imagine all the possible story paths that could lead to the scene.
So there is a mental switch required when authoring an interactive drama like this. An interactive drama author is definitely not writing a single story, with a single path for the player to follow. Nor is he even writing multiple interwoven stories, where the player's choices lead down different branching paths. Instead, the author is crafting a story space. This is not an easy mental switch to make.
Authoring a "story space" first means that a wide variety of verbs and actions need to be modelled. The author has some control here on what sort of actions he wants to support, though. For example, if the author defines no violent actions, then it will simply not be possible for the player to act violently in the game. However, this can be frustrating for those players that want to try those avenues. Granting such a wide range of options means the PC can then be heroic or indecisive or psychotic or apathetic. This is overwhelming at first as an author, since all these different choices and play styles then need to be supported in the story space in such a way that they can still lead to interesting stories. The means to do this is by authoring scenes that can build on the diverse range of player actions.
Admittedly, not all of these resulting stories may be of equal quality or length. But the focus of interactive drama needs to be on supporting significant player choices and then producing interesting narrative consequences stemming from those actions. To achieve this, the author needs to abandon the notion of any particular story path or required player behavior. This is what I mean by authoring a story space rather one or more story paths. There should be no "best story" in such a space that the player needs to be directed towards.
Although an interactive drama author may need to surrender the notion of a "best story", that does not mean he should also need to surrender all quality control! The author provides the player with potential choices through the actions he defines, and he provides the consequences of those actions through the scenes. It is then the job of the system to provide the best possible consequence to each action in the author's absence. That is, given the author-provided material it has on hand, the system should make the "best decision" in responding to the player at each point in the story.
Implementing Marlinspike and Demeter has shown me that reincorporation is part of this "best decision" as it weaves the consequences into a story. But, as the addition of an imperative value to scene selection shows, reincorporation is definitely not the only factor. As an author, after suffering through the burden of authoring all of the world, characters, verbs, actions, and scenes and then handing the reins over to the drama manager to weave these together in response to a player, it is very disappointing to see the system making poor decisions with the material I have given it. The player is free to act in any way afforded by the system, but the drama manager should be subservient to the author's will!
Discovering what factors besides reincorporation should go into selecting the next scene is important future work. Import of the current action is certainly one aspect. Urgency is another, as many actions need to be responded to immediately. And, when import and urgency of the current action are low, it may be time to introduce new material that advances the story.
This finally brings us to the qualities of complete Demeter stories: complexity, novelty, and well-worn paths.
First of all, testing complete Demeter stories was a nightmare. This arises from the dozens of ways a single scene can play combined with the myriad possible world and story contexts in which that scene could play. Also, many scenes rely on randomness and the contents of the event history to make certain choices. This makes it very difficult to produce reliable or useful unit tests for scenes. Thus, the most reliable way of testing scenes was to quickly play through multiple games up to that scene, possibly after some tweaking of the initial world state--such as characters' initial locations and affinities.
In the process of testing with different initial world states, I would occasionally encounter fringe cases and story contexts that I am not sure are possible to reach through normal play. For example, NPCs with certain plans that result from fearing the revenant will not join the GoParty nor will they come to the rescue of someone attacked in the passenger gondola by the revenant. So I am not sure if they can ever encounter the revenant at all. But I still authored their responses should it happen. Similarly, scenes (should) still work if there are no NPCs left alive, or if there is only one. Yet the chance of this happening--of the PC going on a homicidal killing spree--is fairly low.
Since I authored all the content displayed by the game (except for some of Inform's standard verb responses), I do not often encounter any novelty in the game's output. But, given the combination of complexity, randomness, unexpected player choices, and fringe cases I have since forgotten I even authored, I am still surprised occasionally, especially by certain emergent combinations. For example, although I wrote the reactions of an NPC to eventually attack a violent PC, I was surprised and amused to see the NPCs gang up and beat a particularly violent PC to death.2 Arising from the independent behavior of the NPCs and the revenant, the revenant will pick off members of a divided GoParty. The most memorable surprise for me was learning that it is possible to seduce a married man: Due to his relationship with and high affinity for Irene Winters, Jonathan Winters refuses most romantic advances. But, as part of waiting through the night, he may then still show up later at the player's door with romance on his mind.
In general, novel or unexpected behavior is not desirable as an author. Instead, it is extremely nerve-wracking! It means I have overlooked some combination of scenes or states or have neglected to make explicit some precondition. This is worrisome because most overlooked combinations do not lead to amusing behaviors like those described above. Most of the time they produce illogical behavior or outright errors that generate garbage output or game crashes. So there is a strong authorial tendency to try to constrain these "surprises" as much as possible.
This inability to exhaustively test combined with discovering unexpected combinations means that, even as author, the system still feels somewhat opaque to me. I still don't have a clear conception of the full and exact range of story possibilities. What I desire is a map of all the possible game states. However, Marlinspike was designed to go beyond the branching tree approach required to provide just such a precise mapping of all possible of story paths. So there is a definite tension here between a desire for authorial certainty and the system's complexity and flexibility.
Despite all of the potential fringe cases, most game sessions adhere to a few, well-worn story paths--both in terms of the scenes played and the paths through those scenes. The initial affinities and other states of NPCs prompt those NPCs to make certain consistent choices through the game. Players also tend to make the same choices. In Demeter, they want to be active: They march directly up into the Zeppelin and wander back and forth until they encounter the revenant and then try to kill it. This is fine, but it means most of the other story paths go unexplored. For example, it is possible to woo NPCs or be beaten into submission by them. It is possible to get a well-formed story by doing nothing at all. Some choices are extremely rare. For example, if you stay in the passenger gondola while the GoParty explores and if the other NPCs with you are evenly divided on whether to open the hatch again, you can become responsible for the choice of whether to let the GoParty back in or else betray them to the predations of the revenant.
These fringe story paths still need to be authored so that there is a breadth of potential story and in order to support the full range of possible player actions. So the lesson here is that an author may feel more fulfilled if he can recognize what the most common story path will be. He can then focus a bit more of his attention there by providing more interesting choices along that path. Doing this would in fact divide this path into other less well-travelled paths. Note that this is not necessarily easy, since these "paths" are only emergent features of the finished system at work!
Also, sometimes emergent behaviors need to be tweaked with a eye to the resulting story. In Demeter, the revenant randomly decides whether to act and what to do based on its current health and the number of other characters currently present. That is, if it is injured or if the PC is not alone, the revenant is less likely to appear or to attack. At the time I wrote this, I was favoring the simulated "reality" of how a revenant might actually behave: Just because the PC arrived does not guarantee a sighting. However, favoring the verisimilitude of the simulation over the story lead to a long lull in most stories as players are forced to wander back and forth along the length of the Zeppelin until the revenant finally appears. It seems now that a concession should have been made to the demands of the narrative: the revenant should appear after a certain threshold number of wandering scenes.
|
Argax Project : Dissertation :
A Rough Draft Node http://www2.hawaii.edu/~ztomasze/argax |
|
Last Edited: 23 Apr 2011 ©2011 by Z. Tomaszewski. |