Chris Crawford on Interactive Storytelling (54 page)

If you don’t like the options I offer, there are two possible interpretations. Perhaps I’m a failure of a storybuilder, lacking the talent to do my job properly. In that case, you should walk away from my work the same way you would walk away from a writer whose novels you don’t care for. The other explanation is that you’re a perverse player who revels in contrariness, in which case I recommend you go write your own damned storyworld and see whether you can provide for every contrary player.

I’ve been using the term “option” in the somewhat loose sense that’s common, but now it’s time to formalize my usage of it. An
option
, for the purposes of this book, is a Verb offered to an Actor as a possible reaction to an Event. Because an Event is most precisely characterized by its Verb, in practice I assign options to Verbs, not Events. When an Event takes place, Actors refer to its Verb to determine their options.

You have two ways to assign options to each Verb:
hard-wiring
and
soft-wiring
. The hard-wired approach is easier to imagine. For each Verb, the storybuilder builds a list of those Verbs that constitute reasonable reactions to the originating Verb. For example, for
InviteToParty
, only three Verbs are reasonable reactions:
AcceptInvitation
,
RejectInvitation
, or
DeferResponse
. The storybuilder lists these three Verbs, and the work is done.

The hard-wired approach does seem inelegant because every single item must be specified by hand. It’s unavoidably tedious, especially with large sets of Verbs. A more elegant solution is the soft-wired approach: programming the storytelling engine to calculate the appropriate reaction Verbs. To carry out this computation, each Verb must be assigned a set of characterizing traits that the algorithm can examine to determine each Verb’s appropriateness for each situation. For example, Verbs could be characterized by such adjectives as violent, physical versus mental, two-party, three-party, four-party, nasty, beneficent, romantic, sexual, angry, sad, confrontational, evasive, intense, and so forth. Each Verb would also have some adjectival specifications for its options. For example, the Verb
DiscoverJulietsBody
would prefer a sad and romantic Verb as an option rather than a confrontational or beneficent Verb.

However, I believe this soft-wired approach is unlikely to work, at least for the short term. There are simply too many factors that must be taken into account to differentiate every Verb from all the others. The range of reactions available in storyworlds is so broad, the Verbs so varied, that only a huge and complicated taxonometric system will suffice for these computations. Someday, perhaps, interactive storytelling will develop to such an advanced level that the soft-wired approach can be made to work. For the time being, given the primitive nature of interactive storytelling technology, prudence suggests deferral.

For now, the hard-wired approach is more practical. To reduce the tedium of specifying Verbs manually, you need to limit the number of reactions available to players. In addition, you don’t want to offer a long laundry list of reactions that would only burden them. You want the reaction list no longer than, say, seven items. In many cases, such as
InviteToParty
, the reaction list will be even shorter. With such a short reaction list, specifying the Verbs manually is simpler than calculating them algorithmically. The subsequent discussion presumes using the hard-wired approach to selecting options.

Although options are assigned to Verbs, there’s the additional constraint that some options are confined to certain Actors. For example, one of Romeo’s male friends, upon discovering Juliet’s inert body, might conceivably have some sort of necrophiliac option, but Juliet’s mother would surely not. Therefore, the options available to an Actor who’s reacting to an Event depend entirely on the Actor.

To put it more visually, here are two lists, Verbs and Actors:

How do you decide which options are available to which Actors?

My preferred solution makes use of
roles
. My use of this term is somewhat similar to its common meaning. A role has four components:

A means for selecting an Actor who can react to an Event

A list of options available to an Actor playing that role

Inclination formulae for choosing the best option

Specifications of physical and emotional changes resulting from the originating Verb

The storybuilder defines roles for every Verb. Each role specifies a dramatic relationship that an Actor might have to the Event in question. For example, if the Verb in question is
Punch
, you could imagine three obvious roles for it:
Victim
,
BuddyOfVictim
, and
GirlfriendOfVictim
. Each role has its own specifications and its own set of options. The first role,
Victim
, is the easiest to specify: The
Victim
is simply the DirObject of the Verb
Punch
. That role might have as reactions such Verbs as
ReturnPunch
,
BreakBottleOverHead
,
Shoot
, or
BackDown
. The next role,
BuddyOfVictim
, is a little trickier. This Actor must be a guy who directly witnesses the event and is a good friend of the
Victim
. Reactions for this role might be
InterveneVerbally
,
IntervenePhysically
, or
Ignore
. The
GirlfriendOfVictim
role is about as complex as the
BuddyOfVictim
role: The Actor must be female, a direct witness of the Event, and romantically attached to the
Victim
. This role might include reactions such as
RestrainVictim
,
BurstIntoTears
, or
ScreamAtAttacker
.

The process by which roles are used is straightforward. When an Event takes place, the storytelling engine goes through all Actors present on the Stage. It tests the requirements of each role against each Actor. If an Actor satisfies a role’s requirements, that role is activated and the engine then considers the reactions available to the Actor. The role contains the inclination formulae for determining which reaction the Actor will choose. After the choice has been made, the storytelling engine need only construct the resulting plan with its Subject, Verb, DirObject, and any SecObjects, and then enter that plan into a plan list. (Plans and plan lists are explained a little later in “From Plan to Execution.”) Last, the engine must implement the physical and emotional changes that arise from this role. For example, if the
GirlfriendOfVictim
role is activated, presumably the Actor would have a negative emotional reaction toward the Subject of the originating Event, which was
Subject Punch DirObject
.

What if an Actor fits several roles for a single Event?

This is a nasty problem. It arises rarely, but when it does, it can produce unacceptable situations in which an Actor responds to a situation in multiple (and perhaps incompatible) ways. For example, suppose you have the Verb
BabyCries
. You want to have a Verb for any women to respond, but you also want to have a Verb for the baby’s mother to respond. However, the mother is both a mother and a woman, so it’s conceivable she would respond twice—first in the role of mother and then in the role of woman. To prevent this problem, you could define the woman role to exclude the mother, but it’s exactly the kind of problem that generates bugs in programming. It will surely generate bugs in storyworlds if left to the storybuilder’s assiduousness. I therefore restrict every Actor to a single reaction; after an Actor finds a role that fits, that Actor abandons all further examination of roles—even if he or she subsequently takes no action.