Chris Crawford on Interactive Storytelling (50 page)

Drama seldom relies solely on the direct experience of actors; often crucial dramatic information is communicated indirectly through the statements of intermediary actors. Sometimes this technique is used to heighten the dramatic impact or to give the recipient of information the freedom to declare a reaction to the event by describing it in judgmental terms. Any adequate interactive storytelling system must provide for transmitting information among Actors. I refer to information transmission systems as
Gossip
systems. Such systems are inescapably complicated. I shall first outline the procedure used in the Gossip system of my own interactive storytelling technology; then I shall discuss some of the finer points and possible variations on the basic structure.

When an Event takes place, it’s recorded in the HistoryBook. A limited number of Actors are privy to the Event: usually those who populate the Stage on which the Event takes place. This is reflected in an array labeled
IKnow
that I attach to the Event data structure. Whenever an Actor witnesses an Event, the
IKnow
flag for that actor is set to
true
. But that’s not all—the Actor also keeps a list of the juiciest bits of gossip, called the
headline list
. There’s no reason you couldn’t make the headline list for each Actor long enough to include every single Event he or she is privy to, but in practice such thoroughness would be wasteful. Most Actors need only 10 or 20 Events as grist for gossip. I suppose you could get away with only one Event for use in Gossip, but I think it prudent to keep more to ensure that an Actor doesn’t run out of material to gossip about.

Each Event in the headline list is prioritized according to its
Import
(the value assigned to each Verb specifying the degree of dramatic intensity associated with carrying out the Verb). For example, the
Import
of an insignificant Verb such as
ChatWith
might be only 1; the
Import
of a sensational Verb such as
Murder
might be 10. The engine can then sort Verbs in the headline list by their
Import
values, with higher
Import
values placed at the top of the headline list. If a new Event has a higher
Import
value than the lowest Event in the headline list, it replaces that Event.

A headline is not a story; it’s the peak event of the story, the most salient event in the story. Having established which headline to reveal, the storytelling engine must then flesh in the Events that are dramatically proximate to the headline. For example, if a newspaper headline is “John Shot Tom,” it won’t do to simply announce that fact—readers will demand to know the events that immediately preceded and followed the headline. In a storytelling system, that sequence of events is what I call a
Tale
. Thus, you require an algorithm that can isolate Events surrounding the headline from the overall list of Events in the HistoryBook.

By itself, this task isn’t particularly difficult. You start at the headline Event’s entry in the HistoryBook, working backward through the causal chain of Events. You stop when there’s a temporal or spatial break in the Tale. In other words, you keep stepping backward in the HistoryBook until you reach a causal Event that took place on a different Stage or a long time ago. For example, suppose you
have the headline Event “John Shoots Tom” and the following Events just before it in the HistoryBook:

Tom enters the bar.

John beats Dick in the poker game.

Gus orders a whiskey from the barkeep.

Tom orders a sarsaparilla from the barkeep.

John makes fun of Tom.

Tom ignores John.

John confronts Tom.

Gus moves out of the way.

Tom shoves John.

John punches Tom.

Tom hits John over the head with a whiskey bottle.

John shoots Tom.

It’s not difficult to step backward from the headline Event to the Tale’s initiating Event: “Tom enters the bar.” Nor is it difficult to skip over the events involving the poker game and Gus. The resulting Tale is clear:

Tom enters the bar.

Tom orders a sarsaparilla from the barkeep.

John makes fun of Tom.

Tom ignores John.

John confronts Tom.

Tom shoves John.

John punches Tom.

Tom hits John over the head with a whiskey bottle.

John shoots Tom.

Stepping forward from the headline Event to trace its consequences is trickier business because there can be several consequent Events. Consider the following sequence of Events subsequent to the shooting:

John shoots Tom.

Dick draws gun and jumps behind bar.

Jane screams for help.

Tom dies.

John laughs over Tom’s body.

Dick shoots at John.

Jane screams for help again.

John shoots back at Dick.

Dick ducks under cover.

Jane cries over Tom’s body.

John shoots at Dick again.

Dick shoots John.

John dies.

The process of Tale construction creates a new and particularly difficult problem for which I have developed no ideal solution. What happens if the gossiping Actor is unaware of the entire Tale? For example, what if Mary walks into the bar just after Tom orders his sarsaparilla? Worse, what if she walks into the bar just as John shoots Tom? Her version of the Tale is incomplete. Yet Mary does indeed know about the headline Event, so no other Actor will be tempted to tell her the complete story.

My solution is to lock the Stage doors while any activity is taking place onstage, so that nobody can enter or leave until the activity has died down. This solution is the most dramatically reasonable one; in stories or movies, you rarely see a character wander in or out of a scene in the middle of some important action. However, this solution imposes a severe and arbitrary constraint. What if John tries to escape from the bar but can’t leave because Jane is still crying over Tom’s body? That’s a silly situation.

Another solution is to permit Actors to witness only fragments of a Tale, but fill in the empty portions automatically after the action ends. For example, if Mary walks into the bar just as John shoots Tom, she watches the action unfold and then, after the activity in the bar stops, she’s magically made aware of the Events preceding the climax she witnessed. It’s as though she asked the others present “What happened before I walked in?” and they filled her in.

Another troubling situation is exemplified by this familiar story:

Fiona tries to grab the arrow in Shrek’s butt. Shrek evades her. She lunges for the arrow and Shrek jerks away; the two topple to the ground, Fiona on top of Shrek. Donkey enters the stage. Donkey sees Fiona on top of Shrek and draws incorrect conclusions as to the reason for Fiona sending him away.

Here, Donkey’s entrance partway through the tale is central to the dramatic meaning. Later in the movie, Shrek reaches the windmill just in time to hear the end of Fiona’s confession to Donkey and completely misinterprets the meaning of her words. Clearly, partial knowledge of a Tale can be of great dramatic utility. Unfortunately, most cases of incomplete knowledge lead to chaos, not drama. I haven’t succeeded in devising a scheme for winnowing the dramatic from the chaotic.

The end result of all these calculations is a headline list for each Actor and a means for constructing a Tale for each of those headlines. The next task is to start moving the gossip around—that’s when the fun begins!

There are several ways to initiate Gossip. It could be an autonomous process, driven by the engine. If an Actor has nothing better to do, the engine searches for a likely Gossip-mate. It could be prioritized according to the Gossip’s value; an Actor who has just come across a particularly juicy item of Gossip sets aside low-priority plans and scurries off looking for somebody to regale. It could also be a consciously chosen course of action: An Actor must actively declare an intent to Gossip in order to do so.

With the Erasmatron, I chose to make Gossip an autonomous process for all actors. It happens automatically, like breathing. I did so because I found that presenting options to Gossip was a tedious burden on the player. Gossip in the Erasmatron system is automatic, requiring no action on the player’s part.

Before you can build a Gossip system, you need to come up with a model of why people gossip. I could get into a lot of psychology here, but remember, this is drama, not real life; the goal is not to model reality but to come up with a dramatically useful model of gossip.

Therefore, the primary purpose of a Gossip system is to move information through the cast of Actors. Information is interesting only so long as some people know it and other people don’t; after everyone knows it, gossip’s dramatic value evaporates.

An Actor is motivated to share Gossip by its value to the listener. If I tell you a choice bit of gossip that interests you, your attitude toward me will improve. You’ll trust me more because I have taken you into my confidence by revealing the gossip, and you’ll feel more affection toward me for granting you this small boon. And you’ll likely heighten your estimate of my overall power because you’ll believe I have access to all manner of useful information. From my point of view, sharing gossip is advantageous.

But Actors must share their information parsimoniously. Giving information to a blabbermouth guarantees that the information will quickly spread through the cast, robbing the original source of the value of telling it directly to other Actors. The ideal situation from the original source’s point of view is to inform the least loquacious Actors first, and then spread the news further. The blabbermouths should be the last ones to know; that way they can’t steal the originating Actor’s thunder.

A secondary consideration is the degree of affection the originating Actor holds for the listener. Affection motivates the originator to spill the beans.

The Gossip process begins when an Actor enters a Stage. The entering Actor considers in turn each Actor on the Stage, evaluating the desirability of gossiping with him or her. This decision turns on such factors as the trust and affection the entering Actor has for other Actors. The loquaciousness of the Actor under consideration is also a factor, as mentioned in the preceding section.

The entering Actor chooses the most likely Actor with whom to Gossip, and then determines whether that Actor is good enough to share information with. In other words, the first calculation establishes the
relatively
best Actor of all the others on Stage, and the second calculation decides whether that Actor is good enough in
absolute
terms to be trusted with Gossip. The first calculation depends on the other Actor’s characteristics; the second calculation depends on the entering Actor’s loquaciousness. Gabby Actors share information with anybody; actors with low loquaciousness are less likely to do so.