Chris Crawford on Interactive Storytelling (59 page)

Typically, the problem of loopyboobies has two solutions. First, use moods to shut down excessive behavior. The punching raises the
Anger
value quickly and raises the
Fatigue
value more slowly. If your engine is using end-weighted addition,
Anger
rises quickly but soon tops off, and
Fatigue
climbs more slowly. The storybuilder need only include a negative value for
Fatigue
in the inclination formula to ensure that the fighters eventually tire of their battle and give up.

Second, you can make an explicit reference to the HistoryBook. You simply check how many times the contemplated course of action has already been carried out, and then forbid the action if it has already been executed too many times.

Should the storybuilder have responsibility for checking for loopyboobies, or should the engine automatically check for them?

Good question. On the one hand, loobyboobies arise only in special situations, so dumping this responsibility onto storybuilders seems fair. However, it’s possible to build a loopybooby detector into the engine and then assign “loopybooby maximum values” to each Verb. For each Verb, the storybuilder need only specify the maximum number of times the Verb can be executed by one Actor during a specified period. The engine can then enforce this restriction.

Loopyboobies come in many degrees, according to the number of steps they contain. The previous fighting example is a simple two-step loopybooby, but three-step, four-step, and even five-step loopyboobies can be just as embarrassing as two-step loopyboobies.

A
rehearsal
is simply a threadtest that starts at the beginning of the story. It’s the final test of the storyworld; a series of rehearsals should visit every corner of the storyworld. Here’s where the computer shines bright; it can carry out thousands of rehearsals while you’re wasting time in meetings arguing about what color the box liner should be. With the proper design, you can put those rehearsals to good use. The trick is to organize the resulting mass of data into patterns that reveal any weaknesses in the storyworld.

The simplest analysis lists the frequencies of Verb executions. Some Verbs are used more often than others; this list reveals that pattern. In the mathematically ideal design, all Verbs are used equally often, but dramatic considerations have more weight than mathematical symmetry. Verbs with the highest
Import
value shouldn’t occur often, but Verbs with low
Import
can. After all, you don’t want mass murders, meteor impacts, and suicides to be as frequent as salutations, comments on the weather, and suggestions for dinner. This analysis is most useful at the bottom end: Verbs that are never executed are big red flags waving the message that the inclination formulae leading to them are unduly restrained.

The perplexed storybuilder facing the situation of Verbs that are never executed will want to look at the
ComeFrom
data, which are tables of situations in which a Verb is an option. To assemble these tables, the engine must have the capability
to store every decision made—not just which option was chosen, but what options were available. This data enables the engine to build a table for each Verb showing how many times it was an option versus how many times it was chosen. If a Verb is often an option but is never chosen, it’s a simple matter to fix the problem by adjusting the inclination formula. But if it’s
never
an option, the problem lies in a Verb upstream from the deficient Verb.

Here’s an example. Suppose your romantic storyworld never culminates in weddings. For some reason, heroines are not accepting marriage proposals. If you run a ComeFrom analysis, you might discover that the Verb
AcceptMarriageProposal
was an option 27 times, but was never actually chosen. This problem is easy to fix; you merely examine the inclination formula for
AcceptMarriageProposal
and tweak the inclination formula upward a bit. If, on the other hand, the ComeFrom analysis demonstrates that
AcceptMarriageProposal
was an active option zero times, you know that the upstream Verb,
ProposeMarriage
, was never executed. So you turn your attention to
ProposeMarriage
to determine why it was never executed.

A ComeFrom analysis also enables storybuilders to see where a Verb execution comes from: the proportion of Verbs upstream from the Verb in question. Suppose, for example, that the Verb
BurstIntoTears
shows up with an appropriate frequency. Uncautious storybuilders might congratulate themselves on this happy result and leave it at that. However, more prudent storybuilders will examine the ComeFrom analysis and discover, say, that
BurstIntoTears
has two upstream Verbs—
Insult
and
Jilt
—and that every single execution of
BurstIntoTears
resulted from an execution of
Insult
. For some reason, the verb
Jilt
never led to the result
BurstIntoTears
. Clearly, this situation demands further investigation.

You can make the ComeFrom analysis even more useful by ranking Verb executions by relative infrequency of choice. In other words, it can offer the story-builder a list of situations in which a particular choice was rarely or never made. That list might look like this:

BurstIntoTears:   8/38
Insult:           8/29
Jilt:             0/9

On 29 occasions,
BurstIntoTears
was an option of the Verb
Insult
; on 8 of those occasions,
BurstIntoTears
was chosen. On 9 occasions,
BurstIntoTears
was an option of
Jilt
; on none of those occasions was
BurstIntoTears
chosen.

You can extend this process even further. The development environment can be designed to allow storybuilders to tune inclination formulae without understanding any math at all—a development you can be sure most storybuilders will welcome. This magic is accomplished by using linear equations in all inclination formulae. (A linear equation, roughly speaking, is one that takes the form Constant1 × Variable1 + Constant2 × Variable2).

To take the math out of storybuilders’ lives, use ComeFrom analyses that enable them to navigate through the webwork of cause and effect until they find a problem. At that point, you display the output frequency pie chart shown earlier in
Figure 17.2
. The storybuilder selects a slice of the pie and clicks on one of two buttons: Make It Bigger or Make It Smaller. The system then adjusts the coefficients in the inclination formula to implement the storybuilder’s choice. A simple increment or decrement moves the pie chart in the desired direction, but the storybuilder will have to come back and check the results after a subsequent rehearsal.

Why just “Bigger” and “Smaller”? Why can’t the system permit the storybuilder to just set the pie chart to the desired proportions?

That, it turns out, is impossible to do without much more effort. The killer problem is the uncertainty of the values of variables used in the inclination formulae for all the options. Simply increasing a coefficient by, say, 10% will not increase the frequency of choice by 10 percent. The effect of that change depends on all the other coefficients (which you can figure out) and all the variables (which you can’t).

It’s possible to pull off this magic trick by storing all the values for all the variables that led to these results. For example, suppose a storybuilder is attempting to correct the problem with
BurstIntoTears
coming from
Jilt
. The output frequency pie chart looks like
Figure 17.3
.

FIGURE
17.3
: A pie chart for the consequences of the Verb Jilt.

The storybuilder graphically manipulates the pie chart to show the desired percentages. The software could then run a series of tests; each test would calculate the inclination formulae for each set of variable values and determine the statistical results. By altering the values of coefficients, the software could eventually identify a set of coefficients that would yield the storybuilder-specified percentages. This testing would entail an enormous amount of computing—but hey, that’s what computers are for!

A
debugger
is a program that allows a programmer to step through code that’s under development. It shows, step by step, exactly what’s happening, how values are being changed, how the program jumps from one place to another. The best analogy to a debugger would be a DVD player that enables you to step through the movie, frame by frame, but can also fast forward under several conditions. This magical DVD player would be able to fast forward until it came to the next frame meeting any particular condition you care to define. And while it’s at it, a debugger can show you the value of every variable at work at each point in the progress of the story. You can even set a debugger to run until something attempts to change the value of some variable. Programmers consider debuggers essential parts of any programming development environment.

So including a debugger in your own storytelling engine seems appropriate. However, I have doubts about the utility of a debugger for storybuilders. A debugger must show the engine running step by step; to use it, a storybuilder must be intimately familiar with the engine’s operation. This knowledge might be too high a demand to place on storybuilders. On the other hand, a debugger can be an excellent tool for helping storybuilders understand the engine’s operation. You can write all the documentation you want, but until storybuilders see the engine ticking over, its operation won’t be clear.

Threadtesters and debuggers are tricky to program. They require you to sprinkle intervention code all through the engine. Thus, whenever the engine does something that the threadtester might want to know about, you must insert an
If
statement that checks whether the threadtester is running, and if so, control must be diverted to some monitor routine that accumulates testing data.