The Tin Idiot Manages Drama

A frequently pitched solution for creating truly interactive story is the drama manager, a magical piece of software that shuffles the bits of the story around to ensure a satisfying result.  But this doesn't answer the question so much as push it back a step:  what is a drama manager?  A "drama manager" is a name for a communication problem.  

Just as graphics programmers must understand what visual artists do and need, gameplay and AI programmers must understand the basics of fiction and the power in a name.  We will cast our magicware into terms all of us can understand:  the "author-character".  The author-character counterbalances the player-character, that chaotic force ricocheting within our story's confines.  

Like other non-player characters ("NPCs") that utilize a pathfinding, goal-directed AI, the author-character measures pacing, plot-drops, and player habits to choose goal-attaining actions:  planting props, inciting scenes or events, even whispering into the ears of those same NPCs for a little collusion.  But unlike all the other characters, the author-character is forever invisible and covert, like a Greek god who toys with mortals.  

This simple act of personifying the drama manager carries many benefits.  Communication between the writers who must direct it and the programmers who must build it increases.  Among themselves, programmers often speak of a module that can't "see" some distant variable or can't "grab" an object from some other place. Instituting this use of personified language -- listening in, politicking with modules, mobilizing fifth columns within them -- grants us a common vocabulary for discussing the writer's requirements.  Second, as a character the drama manager is allowed to be idiosyncratic, reducing the need for perfection on programmers while reassuring the writer that we're not building the equivalent of the Hollywood formula for interactive story. Indeed, different games, especially of different genres, may each name their author-character to reflect their unique focus.  Names like "Myrtle" or "Athena" or "Kali" support the game's intention and overall tone, while reassuring programmers that the author-character code from the last game wasn't wrong or broken. Finally, personification supports the cost-cutting measure of code re-use.  By treating the drama manager as just another AI-using NPC (sans audio-visuals), programmers immediately have a pre-existing body of code ready for production.  The only new coding involves the creation of ad-hoc measurements and judgments, with which the writer assists.

Once communication and construction become possible, conciliation remains.  While many people across an organization may have objections to an author-character (by any name), it is only the writer's objections that truly count.  Story is their purview.  The interactive fiction community has debated the various aspects of interactive story for years.  (Without the distractions of real-time action and audio-visuals, there's precious little else to discuss.)  I have collected some of the commonest concerns, and present them now.  

Writers have a pejorative term for the computer:  the tin idiot.  So when asked their opinion of handing off some story construction to the machine, a knee-jerk no shouldn't surprise anyone.  Most people are poor storytellers, and we wish to ask tin-man's help?  Here we must remember the author-character is a counterbalance, not a creator.  

The relationship between writer and author-character much resembles that between scriptwriter and director for a live theater production with improv elements:  the director has a framework he stays within.  Though the author-character can be given myriad tools to work with the player-character, a player determined to wreck the story will likely succeed.  The author-character is damage control.

Frequently brought up second is the most important concern:  closure.  In contrast to the immediate, front-loaded spectacle of audio-visuals, or the mid-range power of gameplay that's bracketed between fumbling experimentation and deterministic mastery, story's power comes late, from the climax and ending. All events have played out, all characters have come to their new resting place, all loose ends are tied up.  And that cannot be overstated:  all loose ends are tied up.  Ensuring proper closure is a case of knowledge management (another candidate for code re-use).  For every idea thrown into the air, it must later be caught, and then reflected upon.  Remembering which balls are in the air, and choosing which balls never to throw, are the primary responsibilities of the author-character.  And this brings us to foreshadowing.

The concern goes thus:  foreshadowing is impossible, for it requires predicting the future.  What foreshadowing in fact requires is understanding "juice".  Juice is a jargon term for the little song and dance that happen when, for example, pushing a button incidentally causes a button-dimpling animation and associated sound effect.  

Juice isn't gameplay -- because it has no long-term effects -- but it does inform the player he has performed an important or at least relevant action.  And when the gameplay effects from an action are particularly deep, obscure, or long-term, they require some particularly potent juice:  foreshadowing.  Together with the foreshadowed event, foreshadowing comprise the arc of the thrown ball.  

For example, our player-character lies to an NPC (executing some sort of player choice, no doubt). The NPC recognizes the lie, but feigns belief and plots revenge.  When our player finally falls victim to the trap, we don't wish him to think the game cheated by giving an NPC knowledge or abilities it shouldn't have.  Foreshadowing -- juice -- is our solution.  Our player inadvertently threw a ball by lying, and the author-character of course immediately scheduled a confrontational scene or two for later, but fair gameplay dictates we offer the player some potent juice, perhaps not at the exact moment of the lie, but surely soon enough so that the player will realize, from the bottom of the trap, that he just fell victim to storied agency.

Our next-to-last concern is this:  goal-directed NPCs will steal the spotlight and/or plot.  Normally, writers carefully direct their characters' actions in order to produce a satisfying story.  But a character infused with AI may not act as needed or even intended.  For example, our wiry knife-throwing antagonist chases our hapless NPC throughout a museum and finally corners her. As he's temporarily out of knives, we get our planned quiet moment and resulting dialogue. But surprisingly, she purposefully topples a priceless Ming vase, grabs one of the resulting sharp shards, and kills him with it. The story ends prematurely. Though we could blame her AI for not playing fair, it doesn't answer the question why a real person in such a situation couldn't do the same.  During the course of revision (a.k.a. debugging), writers sometimes need to modify the motivations or abilities of characters to close such loopholes and incongruities.  Here is no different, save that the characters themselves assist.  

Our last concern has a sense of finality:  all this mucking about with software just takes time away from actual writing.  But interactivity does add something to storytelling:  exploration of new emotional territory.  Though novels and short stories may strive to induce, say, a sense of guilt in their passive reader, they're outclassed by the common dieting book.  Like reading how to play basketball, passivity can only show so much.  Either we play the game, or we have a tin ear for participation.