Chris Crawford on Interactive Storytelling (49 page)

I prefer to use
flat data structures
for sentences. This sentence structure handles the majority of all sentences you’ll need to use in interactive storytelling:

Subject Verb DirObject IndirectObject

Unfortunately, handling the majority of sentences you’ll need to use isn’t good enough; a few special sentence structures always need to be included. They’re rare but essential. Here are a few of them:

Subject Trades X (to) DirObject (in return for) Y.
Subject Tells DirObject (that) (he/she) likes ThirdPerson.

Things really go to hell when you nest clauses:

The sad truth is that language is infinitely extensible, and without recursion, you can never hope to handle every reasonable sentence structure. The only recourse is to constrain the storytelling engine to handle a limited subset of all such sentences. This is one of the most painful concessions you must make to technological limitations. Indeed, it’s so painful that time and again I have returned to the problem of recursive sentence structures, hoping to find a way to make them work. Perhaps you’ll be able to see what I can’t and solve this wretched problem. In any case, my own solution is to add two
secondary objects
(SecObjects) to the sentence structure:

Subject Verb DirObject SecObject1 SecObject2

This structure handles even more of the situations I have found necessary in my engine, but it’s not quite as simple as it appears. The Verb defines the precise meaning of each SecObject, so the sentence “Subject trades SecObject1 to DirObject for SecObject2” would be represented as:

Subject Trades DirObject SecObject1 SecObject2.

The algorithms for the Verb
Trades
must specify that SecObject1 indicates the item given by Subject, and SecObject2 indicates the item given by DirObject.

The same structure is used very differently in the sentence “Subject asks DirObject to give him SecObject2”:

Subject Asks DirObject SecObject1 SecObject2.

Here SecObject1 supplies the Verb that Subject is asking DirObject to perform, and SecObject2 supplies the item to be given. Again, the algorithms specific to the Verb
Asks
must indicate the meaning of SecObject1 and SecObject2 in this context.

Having the Verb provide the context under which SecObjects are interpreted is entirely reasonable; this is certainly the case in normal language. However, it does impose additional expectations on the designer as well as the storybuilder; somehow those interpretations have to be built into the algorithms for the Verb. Moreover, the storybuilder must keep those contextual requirements in mind while using the Verb. Misunderstandings between designer and storybuilder here can be the source of many difficulties.

There’s no reason that you couldn’t use three or more SecObjects; the only problem is that when building a storyworld, you can quickly get lost keeping track of all of them.

What about all those other elements of a sentence, such as time and place?

I attach a number of housekeeping variables to my sentence structures. For example, a variable called
When
records the exact time the Event took place, a variable called
Where
records the Stage on which the Event took place, and several other variables keep track of information required for my Gossip system, which I’ll explain in
Chapter 14
, “HistoryBooks and Gossip.”

The first step in reducing stories to computable form is to reduce options to Verbs and actions to Events. The ideal structure for an Event is a sentence, although some liberties must be taken to make sentence structure easily computable.

DRAMA IS DRIVEN BY MORE
than just Events; the knowledge or lack of knowledge of Events is just as important. If Romeo had known that Juliet had taken a potion to make her appear dead, he wouldn’t have killed himself. Mystery stories always include a pile of facts that different actors provide to the protagonist. Comedies often contrive hilarious situations by giving an actor more or less information than they need. Information, or the lack of it, is central to drama.

As the player and Actors move through the storyworld, they generate Events that sometimes influence future decisions. Therefore, you must keep track of every Event that takes place during a single playing of the storyworld. I call this record a
HistoryBook
. In its simplest form, a HistoryBook is nothing more than a temporal record of Events that have taken place in the storyworld.

This information can be useful in preventing repetitive behavior. If Bob wants to insult Fred by insinuating that Fred’s mother wears military footwear, Bob doesn’t want to diminish the witticism’s power by repeating it. The only way to determine whether a player has already used an insult is to consult a HistoryBook. In like fashion, consulting a HistoryBook can prevent other forms of repetitive behavior.

The HistoryBook can also ensure that an Actor has met various preconditions for carrying out an action. For example, suppose the hero seeks to rescue the princess by finding the error in the corporate books. If he has taken his accounting course, he’ll be able to locate the error; otherwise, the princess is doomed. In programming, the traditional way to handle this problem is to set up a global flag indicating that the hero has in fact taken his accounting course. With a HistoryBook, setting this flag is unnecessary; the software need only search the HistoryBook for the Event in question.

This technique is incomparably more complicated than simply storing a flag!

True, but a flag requires custom code, whereas using a HistoryBook is a general solution. The HistoryBook can record whether the hero took a pottery course, a thermodynamics course, or a Chinese language course. It can record whether he cut down the oak tree, obtained the silver key, or destroyed the dragon’s diapers. A HistoryBook records everything that has happened, so it can keep track of everything that matters. Instead of looking up special-case conditions, the storytelling engine simply searches the HistoryBook. Sure, it costs more machine cycles, but it saves brain cycles—which is more valuable?

The simplest addition to a HistoryBook is including causal information that establishes the sequence of Events in logical form
and
temporal form. This is easily done by working backward; each Event merely records the index number of the causal Event immediately preceding it (the
proximate
cause).

Take a look at an example of a sequence of Events in a HistoryBook (see
Figure 14.1
). The sequence begins with Event #12, Tom spilling soup on Mary at time 20. Mary pokes Tom in the eye (Event #13), and Tom puts a pie into Mary’s face (Event #14).

FIGURE
14.1
: A sequence of Events.

These three actions are simple; the causal Event is simply the preceding Event. But then the action splits. Fido licks the cream pie off Mary’s face (Event #15) while Mary blindly swings a rubber duck at Tom (Event #16). The causality isn’t linear now; the causal Event for Event #15 is Event #14, but the causal Event for Event #16 is also Event #14. Fate’s action (Event #17) is caused by Event #16, but Mary’s action (Event #18) is caused by Event #15. Therefore, you’d need to keep a separate record of the causal Events for each Event in the HistoryBook.

In this example, the record would look like this:

Forward causation is more difficult to record because of its branching nature. Every event in drama has but one causal Event, but it can have several consequent events. It’s technically possible to keep track of forward causation with the proper data structures, but in practice these design contortions are unnecessary; simple brute-force searches of a HistoryBook can run quickly enough, given its small size and the high speed of current processors. For example, to find the consequent Events of Event #14 in the preceding example, you’d simply search through all Events, looking for those with a causal Event #14.