Argax Project:: Dissertation: A Rough Draft Node

Node Status: ROUGH

Future Work

Theory

Reincorporation did lead to a better internal story structure, but this was not reflected in the reported experience of end users. However, as discussed previously, there are some alternate hypotheses that could explain this lack of effect. Regarding story coherence, the improvements from reincorporation were fairly subtle in Demeter--perhaps too subtle to be measured with the particular survey instruments used here. Regarding agency, story-level agency effects were potentially occluded by the world-level agency problems causes by the affordances of the text-based interactive fiction medium.

Thus, further work should be done to confirm the claims that reincorporation can really improve the story quality and player agency of an interactive drama. One way to do this would be to repeat the study with an improved interface, more extreme differences in reincorporation settings, and/or different measures of player experience. Another would be to run a study using a simple interactive narrative system in which players make explicit story-level choices, as in a hypertext novel or Choose Your Own Adventure story. For a short story, this would be a much simpler system to author. Any positive reincorporation effects found when the player interacts directly at the story level would very likely--though not necessarily--apply to an interactive drama in which the player interacts at the world level.

Marlinspike

Although using reincorporation as the primarily criterion for scene selection proved somewhat disappointing, I feel that Marlinspike still generally presents a solid architecture for further interactive drama research and development. This is mostly due to the contributions just discussed revolving around its verb-action architecture and its explicit story model. Therefore, I plan to continue development of Marlinspike.

The first step here is to re-implement it in a more robust language. In particular, I would like to explore using a scripting language to script parts of the system (such as scene contents) and a logic language to handle such things as recast rules.

This rewrite would provide an opportunity to fix a few internal weak points in the architecture. Some of these are merely small, technical irritants. For example, the event at EventHistory.current should equal EventHistory.indexOf(EventHistory.size()) for looping purposes. But most changes would be important feature additions. One needed feature is a robust searching architecture to quickly form lists of events and NPCs that match certain criteria. Changes in world and characters states should be separately represented from the actions that caused them. It should be possible to determine which characters were present at any given past event.

More generally, the connection between the virtual world and the drama manager needs to be clarified and tweaked. I would like to find a way to avoid the need for the drama manager to explicitly approve every player deed. This will likely require a design in which the author may preempt certain deeds from within the world, rather than having the drama manager deny them after the fact. Also, even attempted deeds should be reported to the drama manager by default, since these often represent important events too. And it needs to be possible to execute NPC deeds offscreen in the world. Once the bridge between the world and story levels has been clarified, I would like to be able to plug the drama manager into different front-end game engines so the same system could be used to manage text-based, 2D, or 3D interactive dramas.

Due to the relative ease of authoring and the positive feedback regarding Demeter's descriptions and narration, I believe that text-based interactive dramas are indeed viable, especially for research and development games. However, a pleasant menu-based interface that indicates which objects support interation and in what ways needs to be developed. This may also be a valuable contribution to the general interactive fiction community.

NPCs need more attention in the Marlinspike design. I believe NPCs can be made more believable, not by increasing their internal complexity, but by focusing on expressing their existing state and offering more fluid ways of interacting with them to change that state. If continuing with a text-based medium, exploring some non-textual means at hinting at NPC states and state changes would likely be valuable. Authoring each NPC separately, rather than pulling from a common pool of responses, would also help.

Continuing a process already started during the implementation of Demeter, the monolithic design of scenes needs to be broken down. Scenes should be authored in terms of their component parts. This suggests a deed-based approach, where NPC behavior is specified in terms of deeds with well-defined effects. One advantage of this would be a clearer, more detailed event history. Another is that NPCs and players would leverage the same casting and recasting rules to actions. Finally, this could lead to a scene-authoring approach that involves scripts of NPC deeds, or even more sophisticated planning for NPCs to reach author-specified story goals. Or NPCs could become more autonomous, suggesting their own potential actions and reactions and the drama manager simply coordinating them within the current scene. In short, rather than remaining as story atoms, I see scenes becoming a framework for a particular segment of the story. Gradually, scenes may even atrophy away, leaving only the more general architecture of deeds, actions, recasts, and story goals.

The scene selection process also needs to be re-examined. Reincorporation is important, but other factors are at work here, such as the need for immediate reaction to some events, as well as a need to move the story forward with new material that is not always directly related to what came before.

In general, I envision a much more modular system where each component--drama manager, scene selection process, front-end game engine, etc--can be independently swapped out to test different approaches. Eventually, authoring tools specific to such an interactive drama system would also be useful. However, it seems premature to design authoring tools when the underlying drama system itself is still evolving.

This project has also clarified my vision of what an interactive drama architecture should be. I see interactive drama as a new creative medium that explores the narrative effects of choices made by an active, roleplaying user. But, ultimately, this experience is authored by a human. This is a long, complicated task. The interactive drama architecture should not then attempt to usurp the role of that author. Instead, it should serve as a tool to extend the reach of the human author, responding to players in the author's absence. It allows the author to craft an experience he would otherwise be unable to provide.

I believe that interactive drama systems should gradually provide the author with more and more tools to work his trade. Artificial intelligence components will be developed to handle more than just selecting the next pre-authored component. Eventually, the author will be able to delegate to the system more and more low-level authoring tasks--such as managing NPC plan executions or giving NPCs the ability to coherently summarize previous events. The author will then be free to focus on his higher level vision.

Marlinspike is but one step in this direction.

ToDo

More vague long-term goals: 1) the ability to test a story space in a controlled and near-exhaustive way (Is this even possible?) and 2) A way to simulate story paths in the drama manager, updating both story and world states in a virtual model, and then "rolling back" or else committing the changes and advancing the current stories.