Chris Crawford on Interactive Storytelling (27 page)

Mathematical formulas are a kind of extended syllogism. The mathematical modeling used in interactive storytelling is the essence of its artistic content.

Quantification does not trivialize the complexity of the human condition. Computers use a different vocabulary than people do (numerical rather than verbal).

Mathematics, more than any other medium, addresses the choices characters make because it delves right down into the process of the choice, not its results.

PEOPLE HAVE BEEN EXPERIMENTING
with interactive storytelling for years, and many approaches have been tried. Some have proved to be failures; I have mentioned a few of them elsewhere in the book. In this chapter, I shall address these examples in more detail.

Everybody seems to make the same mistake when they first approach interactive storytelling: They build a
branching tree
structure (see a simple example in
Figure 7.1
). They start off with a beginning (“Once upon a time, there was a handsome young man…”) and then attach a choice to it (“and he either a) went off in search of adventure or b) stayed home to care for his sick mother”). Then they attach another choice to each of the first choices, then another set of choices to those, and then more choices, and pretty soon they’ve got a huge branching tree that consumed many hours of labor. They’re proud of their work, but when they show it off, nobody likes it because of the heavy workload involved.

FIGURE 7.1:
A simple branching tree structure.

The reason for the failure is easy to understand with a little mathematics. Imagine the smallest, simplest possible structure: Each decision is a choice between just two options and leads to a new situation with a new binary choice. Thus, the first level of choice has exactly two states; the second level has four states, the third has eight, the fourth 16, and so on. Next, say that a productive designer should be able to create a thousand such states—that seems like plenty of work. If you walk through the doubling process, you get to a thousand after just 10 steps. From the designer’s point of view, these 10 steps represent a heavy workload. From the player’s point of view, however, all this work yields a story that’s just 10 steps long. It might read like this:

1. Once upon a time, there was a handsome young man. One day, he set off in search of adventure, and in the forest, he heard a cry and a growl. (Investigate or avoid?)
   
2. He investigated the sounds and found a maiden being held prisoner by an ogre. (Intervene or ignore?)
   
3. He told the ogre to release the maiden, but the ogre challenged him to a quest. (Accept or reject?)
   
4. He accepted the quest and entered a nearby cave. There were two paths: Down one path he could hear water trickling; down the other, he smelled smoke.
   
5. He went down the path that smelled of smoke. There he saw a dragon sleeping; it was clutching the key the ogre wanted, but there was also a sword lying nearby. (Take the key or sword?)
   
6. He picked up the sword. Should he use it to attack the dragon, or take it back and attack the ogre?
   
7. He decided to use the sword to attack the ogre. He went back and confronted the ogre, and the ogre laughed at him and threatened to kill him. (Attack or retreat?)
   
8. He attacked and wounded the ogre, who fell to the ground. The maiden begged him not to kill the ogre. (Kill ogre or relent?)
   
9. He went ahead and killed the ogre anyway. When a drop of blood from the ogre splashed onto the maiden, she turned into an ogre and was very angry with him. (Apologize or kill?)
   
10. So he killed her, too.
    

Not much of a story, is it? Even it were fleshed out with pretty verbal descriptions and embellishments, it’s still skeletal. That’s because real stories have a wide array of decisions. Only a few are dramatically crucial, but a myriad of tiny decisions help define character: the way one character addresses another, the degree of impatience or alacrity with which a character operates, and so on. A real story contains hundreds or thousands of these tiny decisions; this kind of fine detail just isn’t possible in a branching tree.

Some clever people have tried to solve the problem of branching tree designs by rerouting the consequences of decisions. In the previous example, a clever designer might have set up the cave decision in the following way: If the player chooses to go toward the sound of trickling water, he encounters some minor obstacle that deposits him either at the mouth of the cave or in the dragon’s lair. I call this stunt a
foldback
because it simply folds the storyline back to some predetermined path (see
Figure 7.2
).

FIGURE 7.2:
A simple foldback structure.

A foldback scheme does indeed give players more decisions without requiring a lot of additional effort from the storybuilder. Alas, it achieves this goal by mendacity. Consider closely the decision a player faces at the mouth of the cave: He can follow the sound of trickling water or the smell of smoke. That decision has no significance, however, because both choices ultimately lead to the same result. In other words, a foldback merely tricks players into thinking they’re making a
choice. This scheme is fraudulent interactivity; when players discover the fraud (as they inevitably do when they play the storyworld several times), they feel cheated.

People keep coming up with variations on the foldback scheme, such as combinations of foldbacks with branching trees, hoping to find a magic combination that works. There isn’t one. Every single case of foldback renders a player’s decision meaningless. If you have only one instance of foldback in your design, your design is only a tiny bit fraudulent; as you add more foldbacks, you create many more meaningless pathways and add to your design’s overall fraudulence.

Foldback schemes do work in one situation: when internal variables alter as a result of the difference in pathways. For example, suppose that, in the previous story, the player had taken the path toward the trickling water and found a sleeping potion he could use on the dragon, enabling him to wrest the key away from the dragon without being cooked. Therefore, the player would take the path toward the trickling water, get the sleeping potion, return to the main entrance, take the path toward the smell of smoke, disable the dragon, and so on. In other words, the initial choice between the two tunnels becomes meaningful with the addition of the sleeping potion. Going down the smoky tunnel first isn’t as good a choice as going down the noisy tunnel. That’s why this design would be a worthwhile use of a foldback scheme.

But it’s still a stupid situation. How is the player to know the difference between the two choices?

You’re right; it is a stupid situation. I’m trying to keep it simple to avoid burdening the reader with too much stuff at once, okay?

You can generalize the idea of using internal variables to a foldback system by considering the classic videogame PacMan (see
Figure 7.3
).

In
Figure 7.3
, PacMan has reached a junction; he must make a decision to go up, down, or back to the right. In terms of design structure, this is the same situation a player has in a storyworld when confronted with a choice. In this situation, PacMan’s best choice seems to be to go down; going up would probably lead to an encounter with a ghost, and going to the right wouldn’t collect any dots.