Chris Crawford on Interactive Storytelling (62 page)

In 1991, I decided the time had come to commit myself to solving the problem of interactive storytelling. In the dozen years since then, I have developed and refined a technology for just this purpose. Much of that technology is described in previous chapters. The personality model I developed, for example, is presented in detail in
Chapter 11
, “Personality Models.”

My version of a drama manager I called
Fate
. I have previously mentioned Fate in
Chapter 16
, “Sequencing.” Fate is always given the first opportunity to react to any Event that takes place; this gives Fate the ability to intervene in every situation and bend it in another direction. Fate is my proxy (as storybuilder) in the storyworld, my personal representative. I strive to endow Fate with my dramatic intentions. I also endow Fate with the ability to act independently; once each day Fate is activated and examines the developing story from a global perspective; should Fate identify a need for action, it uses this opportunity to set up that action. I call this mechanism a
plotpoint
.

The engine’s basic structure is described in
Chapter 16
, “Roles and Sequencing.” It’s a reactive engine; every Event occurs as a reaction to some previous Event. Only Fate can initiate Events, using plotpoint powers. It uses Verbs and Events as described in
Chapter 13
, maintains a HistoryBook as explained in
Chapter 14
, and implements anticipatory behavior in conformance with the ideas presented in
Chapter 15
.

In
Chapter 17
, “Development Environments,” I referred briefly to
data types
, a standard concept in computer science, when dicussing the types of variables and functions, such as Actors, Stages, booleans, and so forth. Deep inside the computer, there are only numbers, but to make programming less error prone, computer languages such as C++ implement data typing. At the beginning of each program, the programmer must list each variable used in the program and declare its data type. For example, a simple integer is declared to be of type
short
, which is a number stored in only two bytes of memory. Another data type called
long
is a number stored in four bytes of memory. Text is declared to be of data type
char
, short for “character.” (That’s why I insist on the cognomen “Actor” for virtual characters in the storyworld; it’s too easy to confuse the character “%” with the character “Harry.”) The big idea of data typing is simple: You can’t mix apples and oranges. You can’t use a
short
where you require a
char
, and vice versa. Data typing automatically catches lots of pesky little mistakes that would otherwise cost many hours of debugging time.

The Erasmatron uses exactly eight data types—no more, no less. They are Actors, Verbs, Stages, Props, Events, Groups, Numbers, and Flags. Storybuilders cannot mix these data types together. A command requiring an Actor can be filled in only with an Actor. To make matters even easier, the data types in the Erasmatron are color-coded, as shown in this table:

Color-coding makes it easy to see exactly what’s going on in the Erasmatron.

Roles are defined in
Chapter 16
, “Sequencing.” In the Erasmatron, roles are defined by what I call
reaction formulae
, which are boolean expressions defining the specifications for the role. Here is a simple reaction formula for the role of the victim of a punch:

ReactIf (You IsSamePersonAs DirObject)

This formula reads like a command: “You will react to the Event if you are the same person as the DirObject.” Note that the long phrase “are the same person as” has been compressed into a single word; functionally, it operates as a single relationship.

The concept of a reaction formula becomes useful when you consider complicated contexts, such as the role of the male friend of the punchee who might want to intervene:

This formula reads like so: “You will react to the Event if you are not the DirObject, and you are a guy, and you have plenty of Affection for the DirObject.” As you can see, this form of expression permits storybuilders to specify almost any context.

I described scripting systems in
Chapter 17
, “Development Environments.” In the Erasmatron, every role has its own script that specifies:

The reaction formula, specifying whether an Actor should execute the rest of the script.

Changes in the Actor’s relationship with the Subject of the Event: in other words, that Actor’s emotional reaction to the Event.

Changes in the physical environment arising from the Event, such as the transfer of ownership of a Prop. These changes are normally handled in a role executed by Fate.

The Verb options available to the Actor for reacting to the Event.

The secondary objects (SecObjects) associated with each Verb option. (SecObjects are explained in
Chapter 13
, “Verbs and Events.”)

The inclination formula for each Verb option.

The scripting editor in the Erasmatron uses all the ideas presented in
Chapter 17
, such as color-coded entry, replacement editing, full wording, underlining used as cues, and mouse-driven editing.

Most of the effort in building a storyworld in the Erasmatron goes into creating and tuning inclination formulae. I offer here an example of a set of inclination formulae and how they are handled. The Verb to which the Actor is reacting is
Punch
; the Actor is the DirObject. The Actor has four options:
WithdrawGrumbling
,
RunAway
,
Punch
, or
DrawAGunOn
. The inclination formulae for these options are as follows: