Chris Crawford on Interactive Storytelling (10 page)

Three factors determine the degree of interactivity: speed, depth, and choice.

Speed is the simplest of the three factors to understand. At the bottom end of the scale, slow applications destroy interactivity. Three examples demonstrate this point.

The first example is the spreadsheet. VisiCalc was the first spreadsheet for personal computers, and computer historians agree that this program did more to launch the PC revolution than any other. But VisiCalc wasn’t the first spread-sheet—not by a long shot. There were plenty of spreadsheet programs for big mainframe computers, but they were batch-processing programs. You punched your data onto punch cards, submitted your job to the computer center, and then picked up your output the next day. You studied the printouts, made a few changes in your data, punched up the cards, and resubmitted the job. If you were lucky, or you stayed at the computer center until 3 a.m. when nobody else was submitting jobs, you could get your turnaround time down to a few hours, in which case you could run through half a dozen scenarios in one night.

VisiCalc wasn’t as powerful as mainframe spreadsheets; after all, it had to run on a tiny microcomputer. Moreover, a PC’s small screen showed only a fraction of a typical spreadsheet; the “real” spreadsheets at computer centers could print out their results on big sheets of paper so that you could see everything at once. VisiCalc had just one advantage over conventional mainframe spreadsheets: If
you changed a number, it processed the change immediately and presented the results in a flash. In terms of features, display, and overall computational power, VisiCalc was a loser. Its interactivity was thousands of times faster than mainframe spreadsheets, however, and that made all the difference in the world.

The second example is the BASIC programming language, developed at Dartmouth in the late 1960s. A number of languages that emphasized simplicity had been designed for students, but something quite unexpected made BASIC stand out: its interactivity. BASIC was an interpreted language, not a compiled language. Computer languages in those days, and most computer languages today, are compiled. You type up your program, submit it to the compiler (a program that translates your program into machine language), and then run your program to see how it works. The compilation step could take several minutes in the old days, so after submitting your program to the compiler, you would take a coffee break before returning to see how it came out. It probably had a few bugs, so you would fix one or two bugs, submit it again, and go have another cup of coffee. Repeat this process all day long and your eyes were bulging out of their sockets from the caffeine, and you had made only minor progress on your program.

But BASIC is interpreted: It’s designed to be run immediately, without compiling. You type up your program and run it; the results appear immediately. If there are bugs (usually the case in a first-cut program), you make a change right then, and run the program again. This process is so quick and easy that you
never
quit for a cup of coffee; you just sit in front of the computer, lost in intense interaction with it.

As a result, BASIC took the programming world by storm. Within just a few years, everybody was using it to teach students. It’s actually a crummy language, with all sorts of problems, and it teaches bad habits. The single factor of rapid interactivity, however, put it way ahead of everything else.

On a more modern note, the third example is the “World Wide Wait.” Remember how frustrating it was to wait for web pages to download? If you have a broadband connection, do you remember the sense of exhilaration the first time you sat down and worked with fast reaction times? That reduction in turnaround time made a big difference, didn’t it?

So far I have demonstrated only that moderately fast reaction times are better than very slow reaction times. What about the top end, where you’re comparing fast reaction times with moderate reaction times?

Take a simple example: your word processor. When you type, the letters appear on the screen. How much delay is there between striking keys and seeing the letters on the screen? Most of the time, there isn’t much delay, but my copy of Microsoft Word, running on a fairly fast Mac, does bog down when vertical scrolling is required. If my text runs over the line and spills underneath the bottom of the window, requiring vertical scrolling, there’s a slight delay—perhaps half a second—while the screen scrolls. That slight delay is enough to throw off the stride of my typing; I often make typos during that period.

Or how about the task of scrolling from the top of the document to the bottom? If it’s a lengthy document, you can wait a long time while the damn thing slogs through all the pages. My copy of Microsoft Word scrolls through about four pages per second. That’s fast, but it’s not fast enough. I wish it were faster. Don’t you?

Some of the activities performed on computers are mindless: Searching through a few dozen websites to find a bit of information doesn’t take a lot of concentration. A videogame might move at a frantic level, but it doesn’t reach deep into the most important areas of your mentality. Other activities require more mental exertion and hence provide deeper interaction. A game of chess, for example, moves slowly but provides a deeper interaction than a game of tic-tac-toe.

By “deeper,” I mean “penetrating closer to what makes you human.” Computers can easily beat you at tic-tac-toe, but that wouldn’t bother you because tic-tactoe isn’t that important. But what if your girlfriend ran away with a computer? “I’m sorry, Mortimer,” she says, “but you’re just not as exciting, not as sensitive, not as satisfying as R26a here. Sure, he’s dull gray, but in every way that counts, he’s a real man.” Now
that
would strike you in the gut! This is an extreme case, but it serves to illustrate what I mean by penetrating closer to what makes you human.

Many dimensions of depth are available to the artist. Games confine themselves to a few of the simplest modalities of human cognition: hand-eye coordination, puzzle-solving, spatial reasoning, and so forth. For interactive storytelling, however, the foremost cognitive modality at play is social reasoning. The infinite complexity of the dynamics of human social relationships gives the interactive storyteller a bottomless well of material; the problem lies in getting some sort of algorithmic grasp of the problem. Reducing social machinations to mathematical form without compromising their richness, however, requires deftly combining artistic insight and mathematical fluency. This topic is addressed in the discussion on personality modeling in
Chapter 11
, “Personality Models.”

Carl Von Clausevitz, in his monumental work
On War
, noted that battle is to war as cash payment is to business. A businessperson can make deals, write contracts, design and build products, obtain loans, and arrange foreign exchange, but in the end, cash payment is the decisive point; everything else is merely a preliminary to that moment. A general can obtain weapons, train troops, and maneuver around with clever strategy, but in the end, battle is the deciding moment. The same idea applies to the process of thinking: Choice is to thinking as battle is to war. You can philosophize and deliberate all day long, but the end result of all your mental gymnastics has to be a choice of some sort. Your choice might not seem like much of a choice (Do I eat lumpy oatmeal or pickled prunes for breakfast?), but it’s still a choice, and all your mental processes are geared toward making a choice, even in the absence of clear information (When I hear footsteps behind me in the dark alley, do I run or ignore them?)

The quality of any interaction depends on the richness of choices available to the user. “Richness” breaks down into two factors:

The functional significance of each choice

Perceived completeness: the number of choices in relation to the number of possibilities the user can imagine

“Functional significance” means the degree to which a choice satisfies users’ desires, needs, and interests. For example, a word processor could offer a feature that randomly changes fonts and font sizes while typing, but this choice would be useless, so providing it doesn’t improve the interaction at all. A better example comes from those games that offer the player the opportunity to wander all over a huge region—but nothing interesting happens in the huge region. The poor player wastes hours of time exploring a dead space that offers no further opportunities for interaction. Sure, the game offers zillions of choices in terms of where the player might go, but none of those choices is functionally significant.

“Feature bloat” is an example of the reverse of this issue. Consider, for example, the Microsoft Word feature that allows you to add borders and shading to a document. I have
never
used this feature, nor do I expect to ever use it. It therefore represents a choice that has no functional significance to me. From my point of view, this choice is a liability in the program. Every time I consult the Format menu, my eye must glance at this option, and I must make a decision to ignore it. Of course, other users might love the feature, throwing in borders and shading all over the document. For them, this feature doesn’t constitute a liability—it offers an additional choice that they find functionally significant.

For the second factor, the absolute number of choices isn’t important; it’s the number of choices offered, compared to the number of possibilities the user can imagine. If the user has reached the climax of the story and must choose between leaving his girlfriend for the war or shirking his duty, having only two choices doesn’t detract from the power of the interaction; it’s difficult to imagine any other reasonable possibilities.

This brings me to the most important lesson in this book:

Interactivity depends on the choices available to the user.

It is my sincere hope that the font size successfully conveys the importance of this point. In case its significance remains in doubt, I offer a few variations:

The choices available to the user determine the quality of the interactivity.