Chris Crawford on Interactive Storytelling (63 page)

Now let’s go through this mess line by line. The first line is the easiest: You simply say that the inclination to
WithdrawGrumbling
is 2. That fixes the base level; the Actor will take that option unless some other option gets a higher Inclination value.

The second line is a bit more complex; it says that the Inclination to
RunAway
is based on the Actor’s
AngerFear
mood. An Actor with an
AngerFear
mood of 10 will be raging with fury, and Actor with an
AngerFear
mood of –10 will be quaking in fear. An Actor with an
AngerFear
mood of 0 will not be feeling Anger or Fear. Note that you subtract the mood from 1; this means a positive value of the mood (meaning that the Actor is angry) disinclines him to
RunAway
, and a negative value for the mood yields a positive result, inclining the Actor to
RunAway
.

The next line says that the inclination to return the punch is equal to the difference in
Strength
between You (the Actor considering the options) and the Subject (the Actor who just punched You). In other words, if You is stronger than the Subject, You will be inclined to punch him back, but if You is weaker than the Subject, You will be disinclined to punch him back.

The last line is complex. It’s easiest to understand if you work backward, from right to left. “You” has already been explained.
IsSameActorAs
is a boolean test; it asks whether the Actor in front of this term is the same Actor as the one in back of this term. In a more brutal mathematical language, you would simply use an equals sign (
Actor1 = Actor2
), but I designed the Erasmatron scripting language to be understandable without a lot of mathematics.

Prop[Gun].Owner
is a mess. It refers to the Actor who is the owner of the Prop known as
Gun
. It’s a number equal to the index of the Actor who owns the
Gun
. In plain English, it answers the question “Who owns the gun?”

Therefore, the entire expression inside the parentheses (
Prop[Gun].Owner IsSameActorAs You
) asks whether the owner of the gun is the same person as the Actor executing the script. It’s a long-winded way of asking “Does You have the Gun?”

LogicalToNumber
is a function that takes a logical value (“true” or “false”) and turns it into a number (“1” or “0”). This value, when multiplied by 5, yields 5 or 0, depending on whether You has the Gun. In other words, if You has the Gun, the inclination to
DrawAGunOn
will be 5; if You does not have the Gun, the inclination will be 0.

So suppose that the Actor in this case is moderately afraid (
AngerFear[You]
is -3), weaker than the Subject (
Strength[You] - Strength[Subject] = -3
), and has no Gun. Then the results will be as follows:

Inclination[WithdrawGrumbling] = 2
Inclination[RunAway] = 4
Inclination[Punch] = -3
Inclination[DrawAGunOn] = 0

In this case, the Actor will choose to
RunAway
. Hence, the engine will build a plan with the Actor as the Subject,
RunAway
as the Verb, and the previous Subject as the new DirObject.

The Erasmatronic conception of time is, well, mechanical. There’s a central clock, which ticks off one minute with each tick. With each new tick, the engine repeats a lengthy procedure, as explained in
Chapter 16
. The first step in this procedure is searching through the plan list looking for plans that are ready to execute. When such a plan is found, the engine doesn’t immediately execute it; first it checks to make certain the appropriate audience conditions exist for its execution. If so, then the engine executes the plan; otherwise the plan goes to the opportunity list for deferred execution.

Executing a plan is a ridiculously simple matter: the engine moves the plan from the plan list into the HistoryBook, where it becomes an Event. At the same time, it takes the current clock time and stores it in the
TimeOfOccurrence
slot of the Event record. The engine also figures the CausalEvent and stores it in the appropriate slot.

The Erasmatron deviates most from common practice in the area of movement. There’s no map in a storyworld; there are no spatial relationships among locations. There are only Stages, which impose simple spatial relationships on Actors. All Actors sharing a Stage are able to interact with each other freely, but only Actors sharing a Stage can interact with each other. Actors can move from one Stage to any other instantly; there are no travel times. One special Stage, called Limbo, holds Actors who are out of action. No activity takes place in Limbo; putting Actors in Limbo is like banishing them to Siberia.

The engine controls most movement. So long as there’s activity on a Stage, no one is allowed to enter or leave. After the activity dies out, the engine starts to move Actors to other Stages, and new Actors can enter the Stage. For each Actor, the storybuilder specifies his or her
Territoriality
for each Stage. As I explained
in
Chapter 16
,
Territoriality
isn’t a desire to control a Stage, but a proclivity to return to that Stage. For example, a 16-year-old Valley Girl would have a high
Territoriality
value for the shopping mall Stage and a low
Territoriality
value for the pool hall Stage. Males would have low
Territoriality
for the women’s bathroom, and horse lovers might have high
Territoriality
for the stables.

The storybuilder can intrude on this process by entering an
Appointment
in the script for a Verb. An Appointment specifies the time for an Actor to go to a Stage; in moving Actors, the engine gives priority to Appointments.

Gossip in the Erasmatron storytelling engine follows the principles laid down in
Chapter 14
, “HistoryBooks and Gossip.”

There remain a number of minor features in the system. One is
Spying
, which reflects a major difference between drama and real life. In real life, people can, if they wish, speak together, confident that they’re not being overheard. Such is not the case in drama. The two actors lean over the table to each other, whispering their plan to foil the antagonist, and then depart; the curtains behind their table part to reveal—the antagonist! Drama oozes with unlikely circumstances because they allow interesting dramatic convolutions. Sure, it isn’t realistic; this is drama, not simulation.

The Erasmatron storytelling engine permits this kind of behavior. One Actor can be set to spy upon another, and for the next 24 hours, the Spy shadows the Spied-Upon, witnessing everything the Spied-Upon says and does, all without being detected.

Another minor detail is a special data type called Group, which is a set of Actors defined to act as a social unit. For example, a storybuilder might build a Group representing a gang, and then treat the gang as a single object. The leader could exhort the group as a whole, accept the group’s cheers and huzzahs, lead the group into a fight with another gang, and so forth. Group interactions are uncommon in drama; most interactions involve only two people. But a few interactions demand group treatment, so the engine provides for these situations.

The Erasmatron is now at Version 3.2. I am preparing for a major revision of the technology with Erasmatron 4.0. This new version will contain a streamlined personality model, improved facilities for storybuilders to create and tune inclination formulae without requiring expertise in mathematics, and improvements in computations for anticipation.

Complete information on the Erasmatron technology can be found at
www.erasmatazz.com
.

RESEARCH ON INTERACTIVE STORYTELLING
goes back to 1985, when Brenda Laurel addressed the notion in her doctoral thesis. A group of graduate students at MIT began exploring the relationship between narrative and computers in the early 1990s. Agent-based technology drifted toward storytelling issues in the mid-1990s, and Stanford hosted the Interactive Story Systems conference in 1995. That early work was tentative, but people were definitely starting to show interest. Janet Murray published her popular book
Hamlet on the Holodeck
in 1997, describing some of the efforts and possibilities.

Conferences addressing topics related to interactive storytelling were held in Avignon, France, in 2001 and Darmstadt, Germany, in 2003. “Narrative Intelligence,” a collection of academic papers, appeared in 2002. Several dozen research papers on aspects of interactive storytelling have appeared in the past few years. This chapter presents a digest of some of that work.

Interactive storytelling lies on the frontiers of research; accordingly, no common vocabulary or even any consistent frame of reference exists. Every researcher, including me, approaches the problem fresh and concocts whatever schemes and terminology seem right. Bombarding you with this diverse terminology will surely befuddle you; I therefore take the liberty of rephrasing many of these ideas in the terminology I’ve established in this book. In most cases, my rephrasing robs the original work of some of its robustness, so I urge readers to consult the original research work when possible. I have supplied references to many of these works in the endnotes.

First, I want to present a number of major points that touch on many of these research efforts. Most of these research efforts have been prepared for academic consumption, and as such, they cannot be applied immediately to the task of building interactive storytelling systems. Research projects aren’t intended to yield software that can be sold in stores; what matters is to create and develop ideas for what commercial operations call the “feasibility stage.” The goal is not to actually finish the software, but to demonstrate that it could be finished with an adequate expenditure of money and resources. Realistically, one graduate student working for two years can’t be expected to build a working system for interactive storytelling. The previous chapters of this book should have demonstrated the massive and complex nature of any technology for interactive storytelling.

Accordingly, these efforts must be appraised not as working technologies but as speculative exploration of interesting concepts. If you require them to prove their merit with working demonstrations, you’ll inevitably be forced to conclude they just don’t work. A more constructive approach is to merely extract the best ideas and leave it at that.

An apropos aphorism here is “When you’ve got a big enough hammer, everything starts to look like a nail.” A number of these research efforts are attempts to treat interactive storytelling as the perfect nail for the hammer of some well-developed technology from computer science. These efforts pose particular problems for this book because few of you are likely to be familiar with current technologies in computer science. I shall attempt to at least characterize those technologies as the need arises, but sometimes rendering a complete explanation of the idea for nontechnical readers is impossible.

Computer scientists have built a large and powerful set of concepts for solving a wide range of problems. This set of concepts is not just a random pile; they are all interrelated in a complex intellectual structure. Fundamental concepts underlie a structure of ideas that researchers continue to expand and build ever higher. In this way, computer scientists have been able to coordinate the efforts of many brilliant people over the course of decades, establishing an impressive intellectual edifice.