Chris Crawford on Interactive Storytelling (58 page)

FIGURE
17.1
: Algorithms without tears.

The two variables selected for this inclination formula are the Actor’s
Anger/Fear
mood and the negative of the Actor’s
Affection
for the Subject. The first motivation,
Anger/Fear
, is somewhat more important than the second motivation because it controls the weighting factors used. Finally, the concept of cruciality versus compensation is a little tricky, but it determines whether the formula’s basic form is additive or multiplicative. Compensatory relationships are additive, and cruciality-based relationships are multiplicative.

Compensation is the easier concept to understand. In the earlier example of a gal choosing a husband, wealth could compensate for good looks, and vice versa. Therefore, she would be just as likely to pick a good-looking poor guy as a wealthy ugly guy—although she’d prefer a good-looking rich guy.

Cruciality is a little more difficult to understand. Suppose, for example, that Actor1 is contemplating an action that might have the side effect of antagonizing Actor2. Actor1 might have reason to fear Actor2’s reaction. In this case, the inclination formula might look something like this:

Inclination[Antagonize] = Irritability[Actor2] × Power[Actor2]

Two factors are at work here, and both are crucial to the question of whether antagonizing Actor2 is an undesirable outcome. The first factor is the degree to which Actor2 might be antagonized by the action; the second is the power that Actor2 has to inflict harm upon Actor1. For example, if Actor2 is a mellow but powerful person, there’s no cause to fear antagonizing him because you know he won’t be antagonized. Conversely, if Actor2 is easily antagonized but impotent to do anything about it, Actor1 need not fear his reaction because he can’t hurt Actor1 anyway. Thus, cruciality means that
both
factors are absolute requirements, but they can intensify each other. Compensation means that
either
factor can drive the decision.

A further simplification is to replace inclination formulae with
attraction formulae
. The difference between these two is simple: An inclination formula is specific to a single situation, but an attraction formula is permanently attached to its Verb.

Consider, for example, the Verb
Slap
. Imagine that a gal might want to slap a guy in two completely different situations. In one situation, he has been overly forward in his affections and she wants to forcefully reject his advances. In the other situation, he has deliberately insulted her and she wants to retaliate. In a system using inclination formulae, each situation would have a different formula for the inclination to slap. The rejection-slap might take into account the gal’s affection for the guy, but the retaliation-slap would not, like so:

Inclination[Slap] = Temper[Gal] – Affection[Gal for Guy]
Inclination[Slap] = Temper[Gal] + HowMuchTheInsultHurt

Thus, inclination formulae can be finely tuned to each specific situation.

An attraction formula, however, would assign an intrinsic basis for the slapping action, meaning there would be one formula for both slapping situations:

Inclination[Slap] = Temper[Gal]

The advantage of this approach is also its disadvantage: It’s a simpler, one-formula-fits-all approach, requiring storybuilders to write one formula just once. But because that one formula must fit different contexts, it’s less dramatically precise.

Canned formulae offer storybuilders salvation from Math Hell, but they don’t address the need for tuning those formulae. I doubt anyone is algebraically nimble enough to perceive all the consequences of a system of formulae as large as those encountered in sets of inclination formulae. In other words, the first draft of the inclination formulae is likely to yield undesirable results. The hero always fights and never flees, even when hopelessly outclassed. The heroine rejects every marriage proposal, no matter how attractive. To deal with these problems, the development environment must provide a tuning system in the form of various testing mechanisms. It’s too much to ask storybuilders to write inclination formulae, play the storyworld, and then go back and adjust the inclination formulae. Storyworlds are too complicated for that kind of simple-minded approach.

I call the first testing mechanism the
quicktest
. It assembles a statistical representation of how formulae behave under a wide variety of situations. Inclination formulae always come in sets (one formula for each option available in that situation). Therefore, if each formula has two variables, a set of formulae with two choices has four variables, a set of formulae with three choices has six variables, and so forth. For example, in a three-choice set with six variables at play, select random numbers for each of the six variables and calculate which inclination formula has the highest result; that tells you which choice would be made under those circumstances. Then note which choice was made. You repeat this process many times, counting how many times each option is chosen. It’s no problem doing it, say, a thousand times because this is precisely the kind of task that computers do well. Then you display the results in a pie chart (see
Figure 17.2
).

FIGURE
17.2
: Pie chart for an imaginary quicktest.

Or you can extend the process by repeating the whole procedure, except this time, set the first variable to the maximum value you have defined for it, and use random values for the other five. That generates another pie chart. Then do the whole thing all over, this time using the middle value of the first variable and randomizing all the others. Do it one more time, using the minimum value of the first variable. Then do this entire three-step process all over again, once for each variable, with one pie chart for its maximum value, one for its middle value, and one for its minimum value. All in all, this procedure generates 18 more pie charts. By examining those pie charts, storybuilders can figure out how well the various inclination formulae work and what adjustments must be made to get results more closely approximating their expectations. Most people will find the quicktest too tedious, but if you’re the statistical type, it might be worthwhile to try.

The Achilles’ heel of statistical testing methods like these is the role that historical elements play. If your inclination or attraction formulae contain terms that refer to the HistoryBook, generating useful statistical calculations is impossible. For example, suppose that a gal’s inclination to slap a fresh guy depends on whether she has already rebuffed him. The inclination formula would include that historical element, which of course can’t exist in a one-shot test such as the quicktest. It’s possible in some cases to force the value one way or the other in the statistical test, but doing this raises a variety of new problems. All in all, the problems of handling historical elements are so great as to make them impractical.

Statistical tests yield results only for theoretical situations: using purely random values for variables or using maximum and minimum values. The actual situation in a real storyworld is never so cleanly theoretical. Moreover, the story-builder might know that the particular corner of the storyworld being tested can be experienced only in certain contexts that presume a narrow range of values for some variables.

For example, suppose you’re testing a storyworld in which a wedding can take place. In this storyworld, it’s pointless to test for situations in which the bride hates the groom. Moreover, the context demands certain relationships, moods, and attitudes of other Actors in the scene. Accordingly, a fair test of the inclination formulae should have those presumptions built in.

Therefore, storybuilders must be able to assign certain contextual values before the test. Moreover, they might want to set values by a variety of logical conditions. For example, they might want a random selection from the entire cast, from only males, from males who are present, from males who are present and are kin of the protagonist, and so forth. This selection can become immensely complex, and it seems unlikely that, in the early stages, storybuilders will want that much control. However, when designing your development environment, keeping this capability in mind for future versions would be prudent.

Storybuilders can also benefit from another kind of testing facility: the ability to start a story going at any point and see how it develops in a variety of situations.
A
thread
is a sequence of Events following a single point in the storyworld. A
threadtest
starts at that single point and generates a thread. It repeats the process many times, building up an ensemble of threads. It then assembles those threads into a single statistical structure showing how the story is likely to develop from the starting point.

But doesn’t that depend on the values of all variables at the starting point?

Indeed it does; therefore, the threadtester should be able to generate values for all those variables. It’s the same problem discussed previously under “Setting the Context.” Some simple capabilities for context-setting might be advisable.

Threadtesting is necessary to expose two nasty problems that can arise in a story-world:

Threadkillers:
These situations terminate the action. An unanticipated situation prevents anything from happening, and so the story simply dies. A threadtester can recognize and record threadkillers and present the results to storybuilders.

Loopyboobies:
Fred punches Joe. This infuriates Joe, who punches Fred back. This makes Fred so angry that he punches Joe again. Joe punches Fred, Fred punches Joe, and it goes on forever because the storybuilder’s inclination formulae don’t take into account that people get tired. A threadtester can recognize and count loopyboobies and warn storybuilders about them.