Chris Crawford on Interactive Storytelling (65 page)

But this work was done more than a decade ago! It’s primitive because it broke new ground.

You’re absolutely right. The Oz Project is important for the pioneering nature of the work. The project trained a group of researchers who are now at the cutting edge of entertainment software design: Joe Bates himself, Peter Weyhrauch, Phoebe Sengers, and Michael Mateas. The spin-offs from this project testify to its importance: Zoesis, a company attempting to commercialize the Oz technology
(
www.zoesis.com
); the Façade project (described later in this chapter); and additional research efforts.

Barbara Hayes-Roth at Stanford also pounced on agent technology at an early stage and took it in new and different directions. Her company, Extempo Systems (
www.extempo.com
), uses agent technology for training and entertainment software.

The solution you come up with is dictated by the problem you perceive. In designing Experience Management
²
, the authors, Andrew S. Gordon and Nicholas V. Iuppa, start off with the perception that narrative and interactivity are not absolutely incompatible, but tend to work against each other. They see the central problem as establishing a balance between player control (interactivity) and dramatic control (narrative). One other perception dominates their thinking: that a narrative has only one or a few correct endings. For this reason, they see their challenge as confining the player to the preferred storyline.

Adventure game designers have faced this problem for more than 20 years; the standard solution in adventure games is a foldback scheme, as I described in
Chapter 7
, “Simple Strategies That Don’t Work.” If the player insists on going off on a tangent, the designer must somehow return that player to the expected path. Brian Moriarty used and satirized the standard solution in 1986 with Trinity. In this game, the player is at a park and is expected to move in a certain direction. Should the player attempt to move in the wrong direction, blades of grass rise up together and push the player back. It was an absurd solution, but it accomplished its intended effect of keeping the player moving along the correct path.

Gordon and Iuppa rely on foldback, dressed up in high-falutin’ academic language. The example they offer posits that the player is expected to follow his friend Richard into a cafe. Should the player refuse to conform to their expectations, they offer a series of increasingly insistent options to make it clear to the player that he damn well better do what’s expected of him and get his stupid butt into that cafe. As examples, the authors offer:

“As I walk back home, I notice the cafe at the edge of the park and see that Richard is heading in this direction.”

“As much as I try to ignore Richard and head back home, he seems to always be ahead of me, making his way toward the cafe at the edge of the park.”

“As I come around the corner and pass a magazine stand, I see that there is a cover-story article praising the wonderful food at the cafe at the other edge of this very park—just as my stomach begins to rumble with hunger.”

Get the hint, you stupid player?

What’s the difference between this approach and some of the intrusive techniques offered in
Chapter 12
?

This approach is more heavy-handed than the techniques described in
Chapter 12
, “Drama Managers.” See especially the section “Correcting the Player.”

This technology, which the authors christen “Experience Management,” provides a clever model for implementing this foldback scheme. They apply concepts from computer science to formally represent the knowledge implicit in the developing story and to indicate the storybuilder’s expectations for players. Each event in the storyworld must include formal statements defining the key tidbit of knowledge that event represents and specifying the storybuilder’s expectations as to how players should change their knowledge in response to that tidbit. All this knowledge representation then feeds the
predicate logic
(a technical term for logical calculations) that determines how to respond to players’ actions.

All this high-powered computer science technology seems to do nothing more than select which foldback option will be inflicted on stubborn players to enforce proper behavior. The technology doesn’t actually create or compose those foldback options; it doesn’t recognize that the player has deviated from the required path.

You’re being unfair. This technology wasn’t developed to implement a general-purpose interactive storytelling system; it was developed for educational applications. The goal of the system is to get the player to the correct solution for a tricky problem.

True, but even as an educational application, this strategy fails. If the player wants to drive his car off the cliff, designers shouldn’t create guard rails that magically appear and bounce his car back onto the road or magic guardian angels who catch the plummeting car and waft it back onto the road. No, they
should let the car fall to its destruction and tell the player, “See what your stupid decision led to? Wanna try again?” That’s the whole point and purpose of using computers: They let players fail without real-world consequences. Students using an educational application don’t truly understand the material until they see it in both the light and the darkness, the right and the wrong, the success and the failure. So let them fail!

Interactive storytelling is so difficult that any foothold you can get is worth trying. There are so few technologies on which to base your work that it’s worthwhile to examine any relevant technology for its applicability. Elizabeth Figa and Paul Tarau have done just this with WordNet
³
(described in some detail in
Chapter 10
, “Language-Based Strategies”). They have attempted to harness the power of WordNet to build technologies useful to interactive storytelling. Their goal is to build a library of story traces and story projections.

A
story trace
is an abstract reduction of a story, the skeleton of the story, as Figa and Tarau put it. They propose to extract story traces from a variety of stories, using WordNet to deduce the story trace by examining the relationships among the words in the story. This process will yield a library of story traces that can be used as templates against which a developing story could be matched. Thus, as the player plays with the storyworld, a story trace is extracted from the story created so far, and that trace is matched against the templates in the library. The best-fitting template is then used to take the story to its next step.

That next step is what Figa and Tarau call a
story projection
: a fragment of a story that can be treated as a single dramatic atom. Story projections are actual selections of story fragments that fit a given ontology, described as a set of matching rules. They allow a reader to focus on a single aspect of the story seen as a unit—for instance, what happens to a certain character, what takes place at a given location, and so forth. As yet, their work hasn’t reached the stage at which it can generate stories.

As of early 2004, Façade, developed by Michael Mateas and Andrew Stern, is without doubt the best actual working interactive storyworld yet created
⁴
. It combines a number of off-the-shelf software technologies with some brilliant innovations.

Façade is impressive in a number of areas. It offers a 3D first-person view of the stage and actors (see
Figure 19.4
).

FIGURE
19.4
: A screenshot from Façade.

The player is a dinner guest at the home of Trip and Grace, whose marriage is falling apart. It’s a one-act play on a single stage with just two nonplayer characters. This narrow focus is one factor in the success of Façade; by tightly confining the dramatic situation, Mateas and Stern have brought the problem within reach. Trip and Grace are fully realized 3D objects; they can walk around, gesticulate, and display facial expressions. This 3D action by itself is not revolutionary, but its integration with the overall storytelling system is a great accomplishment. To pull it off, Mateas and Stern created A Behavioral Language (ABL), a custom language for controlling bodily movements. This language allowed them to specify stage directions for actors in response to the developing dramatic situation. They also created a natural language processing system for interpreting the player’s typed-in speech and a “reaction decider” language for choosing context-specific reactions to the player’s speech and physical actions.

Moreover, Façade runs in real time. Rejecting the turn-sequenced systems that I and others prefer, Mateas and Stern have tackled the problem of maintaining real-time drama. The construct at the core of their system is called a
beat
. A beat is what I call an Event; it’s a single dramatic atom, although it’s expressed as a sequence of audiovisual steps. For example, the beat that launches the storyworld has Trip open the door and welcome the player. Trip opens the door, steps back, greets the player, and invites entry. All these actions constitute a single beat.

Where turn-sequenced Events simply happen in one fell swoop, a beat takes place over an extended period and can be interrupted. This is closely analogous to my system for hijacking the storyline, although Mateas and Stern have gone further by creating a clever system that keeps interrupted beats on hold while the interruptions are dealt with, and then returns to the interrupted beats or abandons them if they are no longer dramatically appropriate.