Chris Crawford on Interactive Storytelling (56 page)

True. This problem is dealt with by a variable I call
Territoriality
, which is the degree to which an Actor feels comfortable on a given Stage. Each Actor has a
Territoriality
value assigned to every Stage. For example, Dick has a high
Territoriality
for the baseball field because he hangs out there a lot and a low
Territoriality
for, say, the shopping mall. Jane’s
Territoriality
values for these two Stages might be the reverse of Dick’s. In the same way, Dick’s
Territoriality
for Jane’s shower is zero: He will never go there. Problem solved.

If all the audience requirements are met, the plan pops out of the opportunity list and is executed, at which point it becomes an Event.
Figure 16.3
illustrates this arrangement.

At this point, other Actors consider their roles and react to the Event, as shown previously in
Figures 16.1
and
16.2
. And so the cycle of life continues…

None of these complexities arises in a storyworld with just one Stage. If all Actors share the same Stage, you don’t need to worry about audience requirements or opportunity lists, and
Figure 16.3
is unnecessary. Similarly, if you confine yourself to immediate execution, you don’t need a plan list. If you’re just getting started with interactive storytelling, you might want to defer working on these more complicated problems.

Another dramatic situation that immediate-execution systems can’t handle arises from the use of Gossip (discussed in
Chapter 14
, “HistoryBooks and Gossip”). If a person learns of an Event through Gossip, immediate reaction is impossible. If Mary tells Joe’s buddy Clem that Fred punched Joe, Clem can’t use the Verb
InterveneVerbally
—the Event is long past! However, Clem might still want to react to the event by, say, having a little talk with Fred. This is what I call a
deferred reaction
. In a deferred reaction, the choice is made long after the Event; in deferred execution, the choice is made immediately after the Event, but execution is deferred to a later time.

FIGURE
16.3
: How a plan gets executed.

If you build a storytelling engine with Gossip, you’ll need a system for handling deferred reactions. Fortunately, deferred reactions are, at heart, no different from immediate reactions; they simply use different roles. Therefore, your roles for deferred reactions differ from your normal roles only by a specification that the Actor is not a witness to the Event (that is, not present at its execution).

For example, suppose that Fred Punches Joe and you have defined three roles:
Victim
,
BuddyOfVictim
, and
GirlfriendOfVictim
. They are all immediate reaction roles. Suppose you want to add a role for somebody who hears about the Event through Gossip and wants to admonish Fred to behave himself in the future. This new role,
Gossipee
, can’t take any of the immediate reaction options. It’s a different role that’s considered when the Actor hears the gossip about Fred and Joe. The role includes in its specification a statement that the Actor is not a witness to the Event, but has heard of it through the Gossip process.

Every interactive storytelling engine needs some scheme for sequencing the story’s events. The mechanics of sequencing can be complicated, depending on how much spatial and temporal complexity you permit in your storyworld. The central concept that makes sequencing possible is using roles, which are sets of commands that specify the conditions under which they can be played, the options the role-playing Actor can consider, the factors that influence the Actor’s choice, and any emotional or physical changes that ensue as a direct result of the Event.

THE FIRST TASK FOR ANY DESIGNER
of an interactive storytelling technology is creating an engine capable of generating interesting, robust drama. This is only the first task, however; the designer must also make that engine accessible to the storybuilders who will use it. Accessibility is provided through a
development environment
, a suite of programs that storybuilders can use to create, edit, test, and tune a storyworld. This chapter explains the elements of a good development environment.

Once upon a time, long long ago, software was short and simple, mostly because computers were small and simple. Back in the 1940s, the earliest computers were programmed in binary machine language: lots of 1s and 0s entered with toggle switches. That method, still in use in the 1970s, was fine for tiny programs of a few dozen bytes. As programs became bigger, however, the tedium of entering binary code became overwhelming, so programmers switched to hexadecimal numbers instead of binary. Entering “A9 00” is a lot easier than “10101001 00000000.”

Hexadecimal machine code is fine for slightly larger programs. When writing programs in machine code, however, programmers discovered that a few kilobytes of code was the upper limit. Modifying these programs created all sorts of new bugs. With larger programs, programmers were taking two steps forward and slipping 1.9 steps back.

Next came assembly language, which substituted alphanumeric contractions for hexadecimal. Instead of typing “A9 00,” you entered “LDA #00,” which, as any old-timer can tell you, means “load the accumulator with a value of zero.” Here are two versions of the same code:

Although the two columns represent identical code, assembly code is easier to understand (after you’ve memorized the mnemonics) than machine code.

Assembly language was a big improvement over machine language, and programmers were able to write some fairly substantial programs with it. For example, I led one team that wrote about 50KB of code in assembly language.
Although we weren’t at the upper limit, we could tell that if the program got much larger, our problems would multiply.

At this point, two factors combined to create a demand for something new. First, computers were spreading out into a broader range of uses; these new uses required programs so large that they would be impossible to manage in something as simple as assembly language. One response to this problem was the creation of the C language, a kind of “super assembly language” that enabled programmers to write much larger programs.

The second factor was the need to make computers accessible to people other than programmers. Scientists wanted to write scientific programs without having to hire programmers, businessmen needed a faster way to get the programs they needed, and teachers needed a simple language to introduce students to programming. Three languages were created to meet these needs: FORTRAN for scientists, COBOL for businessmen, and BASIC for students. (At the time, it didn’t look this simple, but this is how things look with 20-20 hindsight.)

As programmers learned more about software and began attempting more ambitious projects, however, programs grew ever larger, and the methods that worked with small programs just didn’t with bigger programs. The classic example is the
GOTO
statement, which tells computers to go to another place in the program and work from there. It’s rather like those step-by-step software installation instructions that say “If your computer already has a floopgoggle, then go to step 5.” This method works fine with short instructions and one or two
GOTO
statements, but with thousands of instructions and scores of
GOTO
commands, you can get totally lost trying to figure out what goes where. Programmers call this type of program “spaghetti code” because the intertwined instructions are just too messy to keep straight. So computer scientists invented languages such as Pascal that had no
GOTO
command and required programmers to use more structured systems. I, like many other programmers, grumbled at the constraints on my freedom (we called Pascal a fascist language), but after using the language we realized it really did make the trains run on time.

By this time, programmers had divided into two groups: systems programmers and applications programmers. Systems programmers worked in assembly language and C, writing the low-level programs that ran computers directly.
Applications programmers worked in high-level languages like Pascal, writing programs that did useful things for paying customers.

Meanwhile, the demands of various special-interest groups continued to grow, and computer scientists realized they needed to provide more than just special-purpose programming languages. They needed to offer something less abstract and generalized, something more narrowly targeted to the particular users’ needs. The appearance of personal computers intensified this problem and created a huge new class of users who weren’t programmers but were willing to pay for software that gave them new capabilities.

For example, VisiCalc, the first spreadsheet program for personal computers, was a simple number-crunching program specialized for dealing with the lists of numbers common in budgets. Although users didn’t realize it, VisiCalc was a programming language; a computer scientist later proved that a sufficiently large spreadsheet program could, theoretically, solve any problem that a regular computing language could solve. But VisiCalc was a narrow-purpose computing language, devoted exclusively to the problems of crunching numbers. Its single-mindedness made it easier to learn, which in turn made it accessible to nontechnical users. Thus, the third major group of computer people (after systems programmers and applications programmers) were created: users who wanted to use computers to organize their work. Applications programmers no longer wrote programs that directly solved problems; instead, they wrote applications (such as spreadsheets) that users could easily program to solve their problems.

The early
adventure game generators
are a more pertinent example of user-level programming. Back in 1976, Crowther and Woods created the classic game Adventure. Its internal structure was simple, requiring more in the way of data than code. By 1979, there were programs that provided an “adventure game engine” along with a “content editor” that enabled anybody to create an adventure game by entering the relevant content data. These adventure game generators required little technical expertise. Nowadays dozens of adventure game generation programs are freely available on the Internet.

Similarly, the early 1980s saw the development of programs that teachers could use for providing educational content to their students. Since then, the concept has been expanded and refined to include level editors for games, character editors for role-playing games, macro editors for photo-retouching programs,
scripting capabilities for word processors, and so on. All such programs have two fundamental components: an engine that runs the system using user-supplied data and a content editor that permits users to enter and edit that data. More elaborate programs include testing facilities that enable users to experiment with variations and quickly see the results. Taken together, this entire system of programs (engine, editor, and tester) constitutes a development environment.