Chris Crawford on Interactive Storytelling (68 page)

This technology was integrated with another technology, Toilet Entertainment Systems, and the result was presented in May 2002 at an exhibition in Gotheburg, Sweden. Users of the public toilets interacted with the technology by choosing among six tiles next to the toilet paper dispenser. The results of their actions were printed onto the toilet paper. No mention was made as to whether the printing technology was inkjet or laser.

Dr. R. Raymond Lang resurrects a line of research that was active in the 1970s: story grammars. This research, carried out in the younger days of computer science, had failed to produce acceptable results and was abandoned in the 1980s. Dr. Lang revived the line of research because subsequent developments in computer science have opened new possibilities.

This research diverges from research on interactive storytelling, as its goal is an engine that can generate stories without player intervention. There’s a long line of such efforts, dating back to TaleSpin, a program James Meehan created for his doctoral thesis in 1976.

Here’s a sample of the kind of output the TaleSpin system could generate:

Betty was famished. Betty wanted to get some berries. Betty wanted to get near the cranberries. Betty walked from her cave down a pass through the valley across a meadow to the bush. Betty took the cranberries. Betty ate the cranberries. The cranberries were gone. Betty was not hungry. The end.

The thrust of this line of research concerned knowledge representation, not storytelling. Computer scientists had realized that what’s called “intelligence” relies heavily on the manner in which knowledge of the world is organized in the mind. They therefore experimented with many ways of organizing information, one of which evolved into the broad field now called
narrative intelligence
.

Lang’s story grammar system, called JOSEPH
¹⁰
, furthers this line of research. Here’s some sample output from JOSEPH:

once upon a time there lived a peasant. peasant was married to wife. one day it happened that peasant quarreled with the wife. when this happened, peasant felt distress. in response, peasant took a walk in the woods. peasant found a pit when he looked under the bush. when this happened, peasant desired to punish wife. in response, made it his goal that wife would be in the pit. peasant tricked wife. wife was in the pit. peasant lived alone.

In storytelling terms, this sample isn’t anything to write home about, but in computer science terms, it’s a step forward. The program is able to calculate emotional reactions to events, calculate actions generated by emotions, and form plans.

The killer problem with all these story generation technologies is that they aren’t designed to be interactive and could not readily be modified for interactivity. The methods used treat the story as a single block of output, not a collection of reconfigurable pieces. The player could perhaps provide initial conditions and watch as the computer generates a story built around those initial conditions, but I don’t see this as a marketable solution.

Perhaps some bright researcher will figure out a way to modify the basic methodology to permit on-the-fly revision of the storyline, thereby making genuine interactivity possible. My guess is that these story generation technologies will not lead directly to interactive storytelling, but that portions of them will be integrated into drama managers for interactive storytelling.

Dat ol’ debbil “plot versus interaction” so haunts the minds of some researchers that their entire approach to interactive storytelling is formulated around the apparent dilemma. Such is the case with the Interactive Drama Architecture that Brian Magerko and John Laird created
¹¹
. Their fundamental idea is to monitor players closely and make corrections when they deviate from the intended plot; their goal is to achieve “balance” between plot and interactivity.

They seem to have ordered their thoughts well; they define a goodly set of terms for their system. They have a Director, who functions as a drama manager; their smallest combinable unit is the beat, which assembles into scenes, which assemble into acts, which assemble into stories. Sad to say, they don’t provide any details of how their system might function. It appears to be a work in progress.

The impressive idea in Stephane Donikian’s DraMachina
¹²
is the notion that the tool defines capabilities. Donikian therefore set out to build a powerful tool for creating interactive storyworlds. This tool doesn’t appear to be built with any particular storytelling engine in mind. Instead, it offers a general way of organizing the many components of a storyworld: the actors, props, stages, scenes, dialogue, and so forth. These components are then organized and output as an XML file that any storytelling engine can read.

“If you can’t beat ‘em, join ‘em” might be the slogan best describing the efforts of Jeff Rawlings and Joe Andrieu
¹³
to build interactive storytelling technology. Instead of attempting to impose a dramatic arc onto the player, their idea is to find a dramatic arc that fits the player’s actions. This is accomplished by means of a
Personal Narrative Agent
(a “drama manager,” in my terminology) who monitors the player’s actions and searches through a set of
Narrative Forms
that serve as templates for mini-stories. The Personal Narrative Agent identifies the Narrative Form that best fits the player’s situations and actions and plugs it into the ongoing narrative. This approach is similar to Figa and Tarau’s, with “Narrative Forms” replacing “story projections” (which I call “Events”).

The Personal Narrative Agent forms hypotheses about the player’s motivations, tests those hypotheses by running test situations past the player, and then acts on the hypothesis best supported by the player’s choices.

The concepts Rawlings and Andrieu describe are impressive, but for the moment they are just that: concepts. As far as I know, they haven’t yet built working software that implements these concepts.

Marc Cavazza and Fred Charles, researchers at the University of Teesside in Britain, have published a number of works presenting important components of interactive storytelling technology
¹⁴
; they appear to be assembling a full suite of technologies for integration into a complete system at some point in the future.

One of their technologies is based on Hierarchical Task Network (HTN) technology. This technology, developed over several decades by computer science researchers, sets up a hierarchy of goals and tasks. At the top of the hierarchy are goals; each one is broken down into subgoals, which are subdivided further and further until they have been broken all the way down to tasks that can be executed.
Figure 19.5
depicts a simple version of this scheme. In this diagram, goals are represented by ovals; tasks that can actually be carried out are in rectangles.

This simple scheme exemplifies the problems I cited earlier in the sections “Hammers and Nails” and “Boolean Thinking.” Decades of research have honed the technology of HTNs to a fine edge; applying this advanced technology to the still-childish technology of interactive storytelling seems a fine opportunity to pursue. The tool, however, shapes the hand of the user, so the boolean thinking implicit in HTNs carries over into interactive storytelling. Although this technology performs magnificently when, say, guiding robots over the surface of Mars, its handling of romantic situations is a little off, as shown in
Figure 19.6
.

Not quite Romeo and Juliet, is it?

HTNs have another flaw: their inability to prepare plans that extend over a long period and interleave with other plans. Realizing this, Cavazza and Charles added another technology to their system: Heuristic Search Planning (HSP). This technology is more powerful, so it shouldn’t surprise you that it makes more
demands on the storybuilder. Specifying relationships among the various story components is a more complicated task with HSP than with HTN; the authors concede that this complexity might be a source of difficulty in recruiting talented storybuilders to use their system.

FIGURE
19.5
: A simple Hierarchical Task Network.

FIGURE
19.6
: The HTN for romance.

The authors have also experimented with using speech recognition for user input; their results indicate that players directly commanding actors does not work well. Instead, they recommend that players use speech input to give warnings, information, or advice to their actors. These inputs can then be integrated with the planning mechanism (the HTN and HSP) to guide the actors’ decisions. Last, the authors have integrated their software with a 3D engine that shows actors moving about on the stages.

The research efforts discussed in this chapter go off in all directions; there are few common elements, although drama managers show up frequently. Several researchers prefer to use the term “beat” where I use the term “Event.” Aside from these components, there isn’t much commonality in the research underway. Chalk it up to the youth of the field. Give it 10 or 20 years and they should have, at the very least, a common vocabulary.

The pace of research into interactive storytelling is so rapid that this chapter will likely be obsolete by the time the book is published. You can keep up with the stampede by consulting Andrew Stern’s excellent index of all things related to interactive storytelling
¹⁵
.

A VARIETY OF EFFORTS ATTEMPT
to use the computer in some fashion that seems kinda-sorta narrative. In this chapter, I discuss some of these efforts and their relationship to interactive storytelling.

In 1976 Don Woods released his greatly expanded version of Will Crowther’s Colossal Cave Adventure, and a genre was born, originally called
adventure games
. Scott Adams created the first version of the game on a personal computer in 1979. He built a general-purpose editing program that made it possible to create completely new games using the same architecture. (Few people know that Rob Zdybel at Atari created a similar tool at about the same time.) Originally known as “adventure games,” this genre has a simple structure. Several dozen rooms are populated by a variety of objects, obstacles, and antagonists. Players see only a textual description of the room they occupy; their goal is to wander through the maze of rooms to reach some desired goal. Player commands are entered with a tiny subset of English. Initially, the parsers in adventure games handled just two-word sentences specifying a verb and an object: “Go north,” “Take book,” “Eat cookie,” and so forth. Later, parsers grew more complex, permitting the use of synonyms (such as “Go north,” “Move north,” “Walk north”) and recognizing extended sentences (for example, “Open door with crowbar”).