Chris Crawford on Interactive Storytelling (41 page)

FIGURE
11.2
: A simple S-curve for stimulus-response relationships

To do this, you replace simple addition and subtraction with “end-weighted” addition and subtraction. End-weighted addition looks like this:

End-weighted subtraction looks like this:

There’s an additional requirement: The increment or decrement can never exceed the
MaxValue
or
MinValue
. In other words, your increment can never be greater than 1.00, nor can your decrement be less than -1.00.

Here’s an example of how end weighting works in practice. Suppose you start with an initial
Affection
of 0.00 and a maximum value of 1.00, and then carry out end-weighted addition of 1.0 five times. With simple addition, adding 1.0 five times would yield a result of 5.0, but with end-weighted addition, the results look like this:

This algorithm ensures that the result always stays under the maximum. It also ensures that every increment to the value has some effect, however tiny it may be.

Building a personality model can be a huge task, but it’s only the beginning. A personality model by itself is useless; the whole point of personality modeling is to equip Actors with the means to make reasonable, understandable decisions.

Decisions are choices between options. You don’t decide “27” or “banana”; you decide to execute one option or execute a different option. You might decide to buy 27 screws, or you might decide to eat a banana, but remember that the real options are the verbs: buy and eat.

Therefore, designers must create a system that links the personality model to the verbs. This linkage takes place through mathematical statements (the “inclination formulae” I’ve mentioned in this and other chapters) that use personality and relationship variables to make choices. One way or another, a personality model must eventually feed its numbers into some sort of mathematical formula that makes decisions. This is a more difficult problem than personality modeling.

To get a clear idea of the difficulties involved, I challenge you to concoct your own personality model. The personality model I have presented in this chapter is certainly not the best possible model, but it reflects my personal artistic sensibilities. There are plenty of other perfectly reasonable personality models, so try your hand at creating one. Remember the basic goals: completeness, conciseness, orthogonality, and tight behavioral linkage. How well can you meet them? The result of your work should be a list of all the variables used in the model, with
complete descriptions of their behavioral implications, as I have done earlier in this chapter.

When you’re done, evaluate your model with the following questions:

How many variables does my model use? (The fewer, the better.)

What kinds of behaviors can’t be discriminated by my model? For example, can it decide whether the girl should kiss the guy passionately or just normally? Can the variables it offers be used to determine whether the sidekick will stand by the hero at the moment of truth, or bolt and run?

If a storybuilder were using your model, would it always be obvious in any situation which variable should be used, or can you imagine situations in which the storybuilder might be torn between two related variables? Might the storybuilder feel a need to use lots of different variables in some complicated mess?

Is your model fine-tuned for a particular type of storyworld, or is it a general-purpose model that could be used in all storyworlds?

Building personality models is the least formidable of all the challenges in interactive storytelling. It’s not difficult to design a simple personality model, but optimizing one demands considerable finesse. The requirements of completeness, conciseness, orthogonality, and tight behavioral linkage are impossible to satisfy to perfection; designers must make difficult compromises to optimize personality models.

A MAJOR MENTAL LEAP REQUIRED
to understand interactive storytelling is the realization that it concerns storytelling, not story. The most common mistake of beginners is to think in terms of “story plus interactivity.” As I have explained earlier, a story is a data structure, and you cannot interact with data; you can only interact with a process. Story is data but storytelling is process. Therefore, we must always think in terms of storytelling, not story.

Storytelling implies a storyteller; interactive storytelling presumes the existence of some kind of algorithmic storyteller built into the software. That storyteller might be called an engine, a system, or an agent, but the term most commonly used is drama manager. Quite a few schemes for interactive storytelling rely heavily on this concept, although the specific implementations of drama managers vary.

Brenda Laurel pioneered this concept nearly twenty years ago with her 1986 doctoral dissertation on the potential of computers in theater. She used the term “Playwright” instead of “drama manager”, but her approach laid the groundwork for all subsequent drama managers. Dr. Laurel prepared a list of thirteen basic functions that a Playwright must be able to carry out. Because she was blazing new trails, she sought completeness of coverage rather than economy of definition; her list therefore contains considerable overlap in its entries. With hindsight, we could probably boil the list down to perhaps five or six more abstract entries. Here is her list of required functions
¹
:

1. Model the plot in progress.
   
2. Specify the formal characteristics of upcoming events.
   
3. Change the storyworld.
   
4. Modify the goals of actors.
   
5. Access proposals for future actions of actors.
   
6. Simulate these proposals to determine their impact on the plot.
   
7. Evaluate the results of the simulations.
   
8. Mandate future events.
   
9. Formulate the script for the next event.
   
10. Direct the actors.
    
11. Control its own operation.
    
12. Remember past events.
    
13. Learn from past results.
    

Sadly, Laurel didn’t offer any ideas for how these functions would actually be carried out; it’s a wish list, not a plan. Still, her work represents the first major attempt to consider the problems of interactive storytelling. A number of researchers have accepted the challenge of actually building this technology, although nowadays they use the term
drama manager
to refer to a software agent that oversees story development and somehow guides it in desirable directions.
Chapter 19
, “Research,” offers a description of this research work.