Chris Crawford on Interactive Storytelling (61 page)

In any interactive storytelling system, you’re likely to have five basic types of values: Actors, Stages, Props, numbers, and booleans. Your scripting system should be strongly typed; that is, only Actor-type variables should be allowed in Actor-type script slots, only Prop-type variables in Prop-type slots, and so forth. Moreover, these types should be color-coded onscreen. I use red for numbers, black for booleans, blue for Actors, green for Verbs, orange for Events, pink for Props, and brown for Stages. At the very least, color-coding makes the scripting window fun to read!

How is this menu-driven system used for different modalities of text entry, such as insertion and replacement?

I use prefix keys, such as Ctrl and Alt. The default text-entry mode is replacement. The storybuilder clicks once on any term, and that term is highlighted. Then the storybuilder selects a menu item, and the chosen menu item replaces the selected term. In this system, you don’t use insertion; instead, you use something I call
outsertion
. Outsertion adds a new operator and retains the original selected term inside that operator. For example, if I want to add 10 to the value of
Affection
, I don’t insert an addition sign after the word “Affection”; instead, I
select the word “Affection” and then hold down the Ctrl prefix key while selecting the menu item for addition. The result looks like this:

(Affection[Subject, DirObject] + WhatNumber?)

One warning: Editing systems require heavy use of parentheses to clearly indicate exactly what belongs where. Even when you’re simply adding a group of numbers, parentheses are necessary to keep the editing system workable. The editor inserts the parentheses in direct response to storybuilder actions, so you can get odd-looking expressions such as this:

A nice feature to include is pop-up replacement menus; if a storybuilder clicks and holds on any term, a pop-up menu lists every variable that could replace the selected term. However, these pop-up menus can become cumbersomely long, so I cannot wholeheartedly recommend the idea.

Now it’s common for editors in programming environments to show the range of any enclosing punctuation (parentheses, braces, or brackets). It’s a good idea, and you should probably implement something like it in your editor. I tried a variation on the standard system. Any time a term has been selected, a story-builder can click a button that highlights the contents of any operator, function, or array variable. In other words, if you want to know what something acts on, select it by clicking once, and then click and hold on the Contents button and the contents of that item will be highlighted. It’s easier to pull off than clicking on a skinny parenthesis, and it works quite well.

Another odd possibility is to dispense with horizontal scrolling by allowing
substitution characters
, such as Greek letters. Whenever a line grows too long, a story-builder can select the contents of any portion of the line (using the Contents button described previously) and click the Substitute button, which creates a new line of script containing the selected material and replace that selected material with the Greek letter.

Here’s a before-and-after example:

Before:

After:

β= SQRT(Affection[Subject, DirObject] + Gullibility[You] Inclination[Punch] = Anger[Subject] - β

Why go to all this trouble to replace horizontal scrolling?

Because sometimes lines get so long that it’s difficult to figure out what they mean. Worse, the stuff hanging off the right edge of the window is often ignored and becomes the source of nasty bugs.

Why not simply allow storybuilders to have a wide window?

Because somebody will always build an expression wider than the window.

Seems like a lot of trouble for a tiny problem.

Yes, it probably is; that’s why I list it as “a nice touch” rather than an important feature.

The hand of man is only as powerful as the tool it grasps. Storyworlds are big, complicated structures; attempting to build one with an inadequate development environment is as futile as attempting to bring down a wooly mammoth with a rock. Indeed, the size and richness of the storyworld that can be created is commensurate with the size and richness of the development environment used to create it. Simple tools yield simple products; if you hope to attain true interactive storytelling, you will surely need to build powerful development environments.

I FIRST BEGAN GROPING IN
the direction of interactive storytelling in the early 1980s, while running the games research group at Atari. Of course, at that time, the 8-bit, 1MHz computers we were using were completely inadequate to the task of interactive storytelling, so I wasn’t even thinking in terms of such a grandiose objective. Instead, I wondered if I could design a game about interpersonal interactions. The videogames of the time were all quite simple-minded and impersonal— couldn’t something be done to get some social interaction in games?

My first crack at the problem was a little game I called Gossip, with eight actors: the human player and seven computer actors. Each had a telephone. The player would point to one of the actors (who then became the “interlocutor”) and click to make his or her telephone ring. In a stunning display of technical virtuosity (for the time), the interlocutor would pick up the telephone and say “Air-Ro?” (This was Randy Smith’s clever technology.) Then the player would point to a second actor and click. At this point, the player’s face would alter to show a neutral emotional expression. Pushing the joystick up would change the expression to an friendly smile; pushing it up a second time would elicit a big, friendly smile and vigorous up-and-down nodding. On the other hand, pushing the joystick down would trigger a slight frown; pushing it down a second time would produce an angry glare and emphatic sideways head-shaking. In this manner, the player could express his feelings of affection or disdain for the designated actor.

Having declared his feelings, the player could then watch as the interlocutor declared his own feelings toward that person. They could continue their conversation by sharing opinions of other actors, or they could hang up. Other actors might call the player to express their feelings.

The gameplay was simple: People like people who like people they like. In other words, you could endear yourself to somebody by feigning affection for those he likes. You could also endear yourself by declaring contempt for those he hates. The strategy in Gossip, then, was to tell everybody what they wanted to hear. Of course, if your inconsistencies became widely known, nobody would like you, and you’d lose the game.

Gossip was certainly primitive. I never thought of it as a full game design; instead, it was a design study for a much larger game, Excalibur. The player, as King Arthur, had to retain his knights’ loyalty, but their own interpersonal rivalries drove them apart and could indirectly affect Arthur. If Percival, for example, feuded with Arthur’s brother Kay, Percival’s hatred for Kay would translate into disaffection for Arthur. The player had to monitor these rivalries and occasionally intervene with special goodies for Percival to retain his loyalty.

In 1987 I took another stab at the problem with my game Siboot. By this time, I had realized that language was a major problem because the range of behaviors required of drama demanded a larger vocabulary than could be had with the
simple nonlinguistic input systems used in games. Therefore, with the help of Dr. Christa Hansen, a psycholinguist from Stanford, I developed the concepts of an inverse parser and a graphical sublanguage, discussed in more detail in
Chapter 10
, “Language-Based Strategies.” These components provided the foundation of the game. The game that resulted was unconventional; players used the language to converse with actors and exchange information. The primitive language used in the game was presented to the player as a telepathic language enabling actors from different species to communicate. It wasn’t a commercial success, but is certainly my most creative effort. You can find Macintosh and PC downloads of the game at a number of sites on the web; searching for “Siboot” should get you there.