Computers & Graphics 26 (2002) 13–20
Artists and engineers as cats and dogs: implications for
interactive storytelling
Chris Crawford*
2349 Sterling Creek Road, Jacksonville, Oregon, OR 97530, USA
1. Introduction: the two cultures problem
Forty years ago, the British philosopher Snow [1,2]
warned us of a dangerous trend in Western intellectual
culture: its bifurcation into two warring camps, the
sciences and engineering versus the arts and humanities.
Whereas, previously, these two spheres had intermixed
amicably, they were splitting apart and failing to
communicate. The danger in this, Snow warned, was
that science and engineering give us power, but the arts
and humanities help us understand how to use it wisely.
Snow’s warnings generated considerable discussion,
most of it concurring, but the cultural division between
the two grand genera of Western intellectual tradition
only deepened. Scientists and engineers regard artists as
fuzzy-heads who cannot handle the discipline of
rigorous thinking. Artists dismiss technical people as
gearheads who just do not understand the human
condition. As the chasm between the two widens, each
side’s comprehension of the other wanes. Few artists
understand the simplest concepts of physics, and few
technical people grasp the basics of artistic expression.
Nowhere has the gap between the two cultures been
more destructive to our efforts than with the problem of
interactive storytelling. The problem demands the best
efforts of both artist and programmer, but the cultural
divide between these two has doomed every effort to
failure.
My first lesson in this problem came 6 years ago when
I worked with a brilliant Hollywood scriptwriter in
teaching a course on interactive storytelling. We team-
taught the course, one of us teaching the first 80 min of
the 3-h weekly lecture, and the other taking the last
80 min. Each week, we would meet for dinner to go over
our notes and compare our content. These dinners were
fascinating exercises in mutual incomprehension. Each
of us knew the other to be an expert in his own field, but
*Corresponding author. Tel.: +1-541-899-9150; fax: +1-
541-899-7926.
E-mail address: chriscrawford@wave.net (C. Crawford).
0097-8493/02/$ - see front matter r 2002 Elsevier Science Ltd. All rights reserved.
PII: S 0 0 9 7 - 8 4 9 3 ( 0 1 ) 0 0 1 7 4 - 1
neither of us could figure out what the other was talking
about. We were wise enough to accept the chasm
between us in good humor; neither insisted on the
correctness of their own worldview. I hope our students
appreciated the lesson of our cooperative mutual
incomprehension.
2. The lesson of computer games
The sad history of computer and video games clearly
demonstrates the nature of the problem. Born and raised
by computer programmers, these games have always
been the playground of technical people. The themes
they offerFblood-soaked battles, feats of hand–eye
coordination, and obscure intellectual puzzlesFare just
what the technical people love. But the artists and the
majority of consumers find such entertainments boring
and distasteful. Computer games are now the confined
largely to young males. Women and most mature men
shy away from these games.
Recognizing the magnitude of the problem, games
companies have long sought to break out of the rut in
which they find themselves. One manifestation of this is
the futile quest for ‘‘games for girls’’. The first
expression of this effort was the attempt to make Pac-
Man more appealing to women by putting a pink ribbon
on top of his head and transgendering him to Ms. Pac-
Man. Artists find such an effort pathetically laughable,
but it was the best the engineers could think of.
The attempts continued. A number of companies
attempted to reach non-technical players by producing
text adventures, games without violence or strategy.
However, these games were elaborate puzzles that
ultimately demanded wild guesswork combined with
meticulous logic, a combination that never worked for
non-technical people.
The dawn of multimedia in the early 1990s gave a new
twist to the futile quest. A great many people believed
that the ability to produce beautiful imagery and
digitized sound would make the computer accessible
14 C. Crawford / Computers & Graphics 26 (2002) 13–20
and entertaining to a broad spectrum of players. An
avalanche of brainless product descended upon the
consumer, boasting great beauty that was, alas, only
skin-deep. Customers dutifully laid out money for
products that, they were assured, represented the Next
Big Thing. After sampling these pathetic offerings, the
customers wisely never came back, and millions of
dollars of venture capital money went down the drain.
The programmers were utterly baffled by these
developments. How could anybody not be entranced
by such beautiful graphics, they asked themselves. They
built ever more advanced graphics engines, demonstrat-
ing specular reflection, diffuse reflection, true point
source shading, and all sorts of other mighty feats of
technical prowessFyet the customers just did not seem
to appreciate their accomplishments. The fact that the
images in their games were soulless never dawned on the
engineers. Computer games companies were dominated
by technical people, and artists were relegated to minor
support positions. This lopsided approach guaranteed
that electronic games would never have the spark of life
that animates artistic efforts.
There were a few serendipitous successes. Rob Land-
eros and Graeme Devine, an artist and a programmer,
formed a partnership and the chemistry between these
two was favorable. They built a great product, The
Seventh Guest, a game combining technical excellence
with artistic flair, and the game was a huge hit.
Unfortunately, the chemistry between them failed, their
subsequent products lacked the magic of the first, and
they eventually broke up in frustration.
Failures were more common than successes. Certainly
the most spectacular failure was Rocket Science, a
company launched with much fanfare and even more
money. Rocket Science was to be the perfect embodi-
ment of the marriage between Silicon Valley and
Hollywood. It commanded the top talent from both
communities, it poured money into its products, and it
promoted itself cleverly. Yet, when the first products
emerged from the Rocket Science labs, they were
duds. Rocket Science had committed the same
blunder that all the games companies were making-
Fonly Rocket Science’s version was the mirror image
of the game companies’. Where games companies
put engineers in charge of artists, Rocket Science put
artists in charge of engineers. The artists just did
not understand interactivity, and so Rocket Science
produced games with glorious graphics and pathetic
play. All that money, all that effort, was a complete
waste.
And so today we have an entire industry for
interactive entertainment that has utterly failed to
produce anything of broad appeal or merit. It has
belatedly realized that story, somehow, is important, but
it treats story as a component to be plugged into the
game rather than an end in itself.
3. Case in point: Shrek versus Final Fantasy
A sad and particularly illuminating example of this
attitude was played out for all to see at the box offices of
theaters in the USA when, in the summer of 2001, two
animated movies, both created using computer graphics,
were released. The first, Shrek, was clearly the work of
people from the art side of the chasm. The computer
graphics were made to serve the story. Shrek was a story
first and foremost, told through a medium using
computer graphics. The technical side of the effort was
competently executed, but no grand breakthroughs were
demonstrated. Nobody went to Shrek to see glorious
graphics. They went to see a movie, and they got one.
Final Fantasy, on the other hand, was the cutting edge
of high-performance computer graphics. The graphics
were impressive, all agree. Indeed, the primary selling
point of the movie was the computer graphics. We were
breathlessly told that the heroine’s hair was modeled
with 6000 separate strands. All manners of major
technical advances were demonstrated in the film. This
was clearly the work of technical people; in fact, the
director was a computer game designer. The graphics
occupied center stage of the design; story and character
were secondary considerations.
The results played out clearly in the box office. Shrek
was a huge hit, generating more than $250 million in its
first 12 weeks. Final Fantasy, on the other hand,
bombed; after just two weeks, its box office receipts fell
below those of Shrek and came to a total of only $30
million. The critics were just as scathing as the box
office: they panned the movie for its poor story.
Some might claim that this demonstrates the clear
superiority of the artists, and proves that engineers
should stay out of the entertainment business. I agree
with this conclusionFwith one important proviso: when
a new medium is developing, and the technology is still
in flux, then the engineers must play an important role.
Shrek worked because the artists were content to use
computer techniques that were not state-of-the-art. Our
own field of interactive storytelling is still in its infancy,
and the artists in this field must therefore accept the
difficult task of forging an effective working relationship
with the engineers.
4. How to combine artists with engineers
How can such a relationship be constructed? Perhaps
if we could find individuals who have embraced both
sides of the divide, people who can feel like artists and
think like engineers, perhaps those people could solve
the problem. I agree that such people would be valuable
to any interactive storytelling effort, but I do not think
that they are enough. I consider myself a scientist who
has approached the art of storytelling with respect and
 C. Crawford / Computers & Graphics 26 (2002) 13–20
some appreciation, and I have made much progress in
tackling the problem, but I do not consider my efforts
alone to be adequate. I need specialists from each side of
the divide. Having collaborated with a published
professional novelist, Laura Mixon, I can offer some
thoughts on how to handle the relationship between
engineer and artist.
The central task in managing this relationship is to
establish the dividing line between each specialist’s area
of responsibility. In well-established fields of endeavor,
we have developed clear specifications for each specia-
list. For example, a great many talents must cooperate
to make a movie, yet the film industry has hammered
out a system of rules that assign primary creative control
over certain tasks to certain specialists, with overall
control going to the director. The cinematographer can
contradict the director on certain matters; the sound
specialist can weigh in with strong opinions that
command respect; and actors always have something
to say. But in the newly developing field of interactive
storytelling, we do not have such conventions.
I can offer a vague rule of thumb: any task, rule, or
plan that can be clearly specified should be assigned to
the engineer; anything that defies regularization should
be assigned to the artist. To put it in computer science
terms, the engineers should handle algorithms and the
artists should handle data. This, however, raises a
fundamental issue. Algorithms are the heart and soul of
computing. Data is the mere fodder of computing;
algorithm uses data as a steam locomotive uses coal. An
artist who supplies only data merely shovels coal into
the locomotive; the engineer actually runs the train. If
we grant all the algorithm-making power to the
engineers, then the engineers will always be the driving
force behind interactive storytellingFa prescription
sure to lead to dismal results. Ergo, the artist must
wield genuine algorithmic power.
This prescription runs afoul of artists’ deep-seated
disdain for all things mathematical. Hopelessly en-
tangled in two cultures prejudices, most artists refuse
to learn the mathematical language necessary for
algorithmic self-expression. I am saddened by this
betrayal of the boldness of the true artistic spirit;
perhaps it demonstrates why great artists are as rare as
great scientists. The historical fact is that for centuries,
great artists have mastered technical fields in order to
advance their art. Indeed, in one technical field,
metallurgy, almost all of the technical advances up to
the 19th century were the work of artists. The
mathematics of perspective was invented by the painters
of the Renaissance; the Golden Rectangle and its
associated geometric relationships were the creation of
Greek architects and sculptors. Harmonic ratios were
first explored by musicians.
There is no alternative to the use of mathematics in
this field, for interactive storytelling, unlike conventional
15
storytelling, is interactive, and interactivity is a process,
not a datum. The specification of a process is nothing
other than an algorithm. Artists who wish to creatively
control interactivity must do so by creating algorithms.
How much mathematics must an artist learn? Nothing
more than what teenagers learn in their first year of
algebra: the algebraic properties of addition, subtrac-
tion, multiplication, and division. Square roots are also
useful, but logarithms are unnecessary and trigonometry
is certainly too advanced for work at the current state-
of-the-art of interactive storytelling. I have devoted
considerable effort to reduce the requirements for
algorithmic expression in my own interactive storytelling
system, and I have been unable to find any practical
system that avoids using these basic functions. They
seem to be the irreducible minimum for algorithmic
expression.
It is possible, of course, to eliminate procedural
considerations from the algorithmic concepts required
of artists, and this goes a long way towards simplifying
the problems faced by the artists. Unfortunately, this is
no grand leap forward; it is simply one of the benefits of
object-oriented programming languages. I would cer-
tainly urge all designers of interactive storytelling
systems to take advantage of these benefits.
5. Development environments
I can now propose a framework for cleanly separating
the work of the engineer from that of the artist. That
framework is the development environment built by the
engineer and used by the artist. The capabilities and
constraints of the development environment are defined
and created by the engineer; the artist creates the artistic
work within that environment. This makes the working
relationship between artist and engineer concrete: they
negotiate the feature set provided by the development
environment. Standardized components of the system
are programmed into the development environment by
the engineer; artistic flights of fancy are realized through
the artist’s expressions within that development envir-
onment.
At this point, an extended example will clarify these
points. I built a development environment for my
interactive storytelling engine; it was used by science
fiction novelist Laura Mixon to create a storyworld. The
history of that development environment illustrates the
problems of disentangling the engineer’s work from the
artist’s work.
At the outset, the development environment (herein-
after referred to as the Erasmatron [3]) provided control
systems for defining numerical values of variables such
as Greed, Libido, and Empathy for actors, or Affection
and Trust for the relationships between them. We
quickly learned that the variable set was itself a major
16 C. Crawford / Computers & Graphics 26 (2002) 13–20
cause for discussion. Laura kept asking for more and
more variables to address every conceivable situation.
We added many more variables such as LoveHunger
and Nurturance. Later, we both realized that too
many variables only confuse the artist; we therefore
trimmed the list of variables. This led to long
discussions of the true merits and applications of each
variable, and especially to discussions of overlap among
the variables.
6. The scripting language
The most complicated portion of the Erasmatron is
the scripting language used by the artist to control the
decisions made by the actors. This scripting language is
the algorithmic heart of the Erasmatron, for every story
turns on the decisions made by the actors at each
juncture. The artist requires a scripting language rich
enough to express the nuance of an actor’s decision-
making process, but the artist also needs a simplified
language within his or her grasp. These conflicting
requirements dictated the course of my work on the
Erasmatron.
7. Point-and-click entry
My first decision was to eliminate keyboard input for
the scripting language. The egregious syntactic pickiness
of production languages like C++ surely substantiates
the wisdom of my intent, but most programmers have
difficulty imagining a practical alternative. My solution
was the use of point-and-click editing. Although the
scripting language is expressed on the screen in a textual
format, it is edited keyword by keyword rather than
character by character. Thus, to edit a script, the artist
clicks on a keyword, thereby highlighting it, and then
selects a new keyword from a set of menus, which
replaces the selected keyword. Thus, an initial expres-
sion is expanded from within in a series of steps rather
than composed in its entirety and typed. This type of
entry system is often denigrated as overly cumbersome,
but in our case, it seems to operate quite smoothly. Even
though the system comprises more than 400 different
keywords, they readily sort into intuitively obvious
groupings that become the basis for menus. Assigning
the most frequently used keywords to a special button
bar at the top of the window greatly facilitated the
editing process.
Some readers, familiar with the many syntax-assistant
features built into modern programming environ-
ments, might wonder why a point-and-click editing
system is preferable to a pure text-entry system. After
all, the point-and-click system is undeniably clumsier,
from a tactile point of view, than a text-entry system,
and any intelligence that it can bring to bear can
just as readily be brought to bear in a text-entry
system. What possible advantage can counterweigh the
obvious tactile disadvantage of the point-and-click
system?
The answer lies in which comes first: user input or
application of syntax-evaluating algorithms. In a text-
entry system, the user must be free to type any desired
text; the system applies its syntax-evaluating algorithms
after the user has typed the text. This places the
computer in the role of judge, and the user in the role
of supplicant. The poor, ignorant user hopefully types
his text and submits it to the computer for judgment.
The computer evaluates it and passes judgment: either
the text is acceptable or it is rejected with a dismissive
error message. The user is forced to dance to the tune
played by the computer. This is demeaning, demoraliz-
ing, and demotivating; many users are chased away
from programming by the harsh judgments of such
programs.
In the point-and-click system used in the Erasmatron,
the syntax rules are applied before the user’s input.
Rather than criticize the user for syntax errors, the
Erasmatron simply does not allow the user to make
them in the first place. This requires more extensive
calculations on the part of the software. Whereas the
syntax evaluator in a text-entry editor must judge what
has actually been typed, its analogue in the point-and-
click editor must consider everything that might be
entered. The former routine simply runs down a tree of
possibilities to determine which leaves have been
activated, and then determines the correctness of each
leaf. The latter routine must examine every single leaf in
the tree and obviate those leaves that are inappropriate
in the current context. This constitutes a great deal of
more work for the processor. However, there is little
additional workload for the programmer. Each and
every syntactical rule must be expressed in code, and
therein lies the programmer’s workload. Applying the
syntactical rule, whether it be done few times or many, is
the processor’s workload, and I say, let us keep those
CPUs humming! An idle processor is Murphy’s work-
shop!
One might object that, in a truly rich expressive
environment, the number of choices available to
the user at any given juncture is so great that the
evaluation of all those choices would be prohibitively
slow. My own experience with the Erasmatron puts to
rest such fears; with 400 keywords, the delay imposed
by screen refreshing is a hundred times greater than
the delay due to option evaluation. Moreover, even
natural language does not demand overmuch in this
matter: at any given point in the construction of a
sentence, the user has an average of only about ten
choices that semantically and grammatically fit the
context [4].
 C. Crawford / Computers & Graphics 26 (2002) 13–20 17

8. Screen layout Every variable presented on the scripting screen is

drawn in its characteristic color, leading to a simple
This screenshot (see Fig. 1) illustrates the basic layout visual rule: you can only enter values of the same color
of the scripting editor. as the slot you are editing.
A minor innovation apparent in this screenshot: any Particularly unorthodox is the editor’s refusal to
screen location that is ‘‘hot’’ (i.e., on which a mouseclick permit the creation of any wholly new element by the
will make something happen) is tinted light blue. Why artist; existing elements are expanded or augmented
designers insist on keeping secret which screen objects instead. Should the user make an entry that calls for
are active is a mystery to me. some associated new element, then that new element is
Another important decision was to use strong but automatically created by the editor at the instant it
fixed variable typing into the scripting language. There becomes needed. It has always irritated me that, when I
are eight and only eight data types in the Erasmatron, create a new variable in a C++ program, I must
each with its own characteristic color: remember to enter the same variable in the variables list
at the beginning of the function.
Numbers (red) For example, when the user creates a new role, which
Booleans (black) in turn requires a new script, the editor creates an initial
Actors (blue) script with the minimum content required to function.
Props (pink) When the user adds a new choice to a script, the editor
Stages (brown) creates all the assignments required by that choice and
Verbs (green) inserts them into the script; the artist need only expand
Events (orange) on the minimal entries made by the editor. For example,
Groups (purple) suppose that the artist wishes to edit the inclination

Fig. 1. Script editing display of Erasmatron.

18 C. Crawford / Computers & Graphics 26 (2002) 13–20
formula for a verb:
Inclination½ThisChoiceo ¼ 0
An actor’s inclination to make this choice is initialized to
zero. Suppose that the artist wishes to expand the value
0 to be the affection that the subject feels for the direct
object of the event. Instead of typing ‘‘Affection[Subject,
DirectObject]’’, the artist selects the zero and chooses
the Affection token from the ‘‘Relationships’’ menu.
The editor recognizes the Affection function as dyadic
and replaces it with the two unknown entries:
Inclination½ThisChoiceo ¼ Affection½Who; ForWhom
The underlining indicates that these two variables are
unspecified values, and the editor expects the user to fill
them in with entries. The blue color indicates that they
must be of type ‘‘Actor’’, and the text suggests the
meaning of the values. The artist can now click on these
to edit their values.
9. Poison
Even sterner is my requirement that the engine must
fail gracefully. If the artist has entered values that lead to
non-sensical results (such as a division by zero), or if the
artist has failed to specify values, then the engine does
not crash or halt; it proceeds with the storytelling by
ignoring the tainted calculation and posting a ‘‘poison-
ing’’, which can be reviewed by the artist after each test
run. This eliminates the time-consuming and tedious
sequential correction of minute errors before the
creation can be examined as a whole.
One might rightly wonder how it is possible to ignore
a tainted calculation and proceed with the overall
calculation without in some way generating unreliable
results. In most calculations, if an intermediate result is
invalid, then the entire calculation is ruined and the
program must perforce abandon execution. In the case
of the storytelling engine, every calculation made is
associated with a behavioral option available to a
character; should the calculation screw up, we simply
ignore that option. The story does not crash, it merely
becomes a bit less interesting.
For example, suppose that we have a story in which
the heroine decides to choose a husband. Suppose
further that the person playing the story has somehow
managed to kill off every eligible bachelor. When the
heroine comes to make her choice, the calculation must
fail because there is nobody to choose. The calculation
will therefore be poisoned and the engine will ignore the
possibility of the heroine choosing a husbandFan
entirely rational solution to the problem.
10. Thinking like an artist, not an engineer
Procedural thinkingFthe ability to mentally step
through a program and imagine its behaviorFis a
mental perversion that all programmers must master to
ply their craft, but it befuddles most decent, right-
thinking people. An effective scheme for insulating the
artist from procedural thinking is the conflation of
loops. The Erasmatron offers no looping structures to
the artist. Instead, it offers several ‘‘pick the best’’
functions, such as PickBestActor, PickBestStage, and
PickBestProp. These allow the artist to specify two
selection criteria: a boolean criterion called Acceptability
and an arithmetic criterion called Desirability. With
these two criteria, the function loops through all the
actors, stages, or props and selects the item with the
highest value of Desirability that also has a true value of
Acceptability. The loop is implicit in the function, but
the concept of looping is never imposed on the artist.
11. Use appropriate terminology
The example also demonstrates another useful design
rule: use the artist’s terminology, not the engineer’s. This
demanded special discipline on my part. Time and again
I found myself phrasing concepts in their computational
terminology, thereby imposing my vocabulary on the
artist and deepening her confusion. Ofttimes a small
effort would permit a quick change, such as when I
changed my term thing (for an ownable or moveable
object) to prop. The change required only trivial
modifications to the program, yet made the concept
immediately recognizable to the artist. Of course, the
term script is a happy coincidence of similar meanings.
In one case, the use of theatrical terminology
improved the conceptual clarity of the system. Stages
in a movie have no spatial relationships among
themselves; actors simply disappear from one stage
and reappear on another, without going through the
tedious task of walking down corridors, through doors,
and up stairs. The dramatic laws of physics recognize no
such thing as spatial continuity, yet I was all set to write
detailed algorithms for translating actors through a
spatially continuous universe. By thinking in terms of
stages rather than locations, I improved the storytelling
engine and made its use more easily comprehensible to
the artist.
This was especially useful in the handling of the
scripting system. Rather than explain it as a program-
ming language, I use the theatrical term role to designate
a particular dramatic context and the script assigned to
that concept. Thus, the artist defines for every action the
possible roles assignable to the various participants or
observers to that action. Each actor then consults the
roles in sequence, examining the boolean React if
 C. Crawford / Computers & Graphics 26 (2002) 13–20
expression. If that actor evaluates the React if expres-
sion to true, then the actor executes the rest of the script.
I explain this to artists in the following terms: whenever
an event takes place, there are a number of scripts
associated with that event; each script is in an envelope,
with a rule on front specifying whether the actor should
open the envelope and carry out the script. The script
envelopes are passed around the actors on the stage, and
if an actor finds that he satisfies the requirements to fill a
role, then he plays out that role using its script.
Lastly, the simplest and most direct expression of this
rule was to spell out words. Engineers have a penchant
for rducng xprsns 2 smllst pssbl fm. Perhaps this was
useful in the bad old days of 40-column video displays,
but nowadays such economies save electrons to waste
more precious acetylcholine. DUA! (Do not use
acronyms!) Spell out your expressions!
12. Unbridgibility
Sometimes the chasm between engineer and artist is
simply too wide to be easily bridged. In the Erasmatron,
I created an elaborate and, I blushingly say, quite clever
debugging environment that gave the artist the power to
operate the storytelling engine a single step at a time,
watching its calculations step by step so as to discern the
nature of a problem. In practice, my artist seldom made
use of my beautiful debugger, because it required her to
think in procedural terms. Typically, when she ran into a
serious problem, she would complain to me, and then I
would use the debugger to trace the problem and report
back to the artist. I was never able to correct this clumsy
arrangement, but I have achieved partial amelioration
with an elaborate rehearsal feature. (Note that rehearsal
is a term that storytellers will instantly recognize and
appreciate.) The rehearsal plays out the storyworld
hundreds of times and then reports back with a
compendium of problems. Defining those problems
has been a major task, and continued effort will be
required to expand and improve the detective work of
the software rehearsal agent.
This brings me to a minor observation about agents.
We are all proud of the agents we create, and our chests
swell with parental delight when one of our creations
performs its stuff for our users. The sad truth, however,
is that our agents are still pitiably stupid, and often
create disappointment when our users treat them with
expectations of greater intelligence than they can deliver.
This embarrassing problem is exacerbated by smugly
calling those agents wizards; a wizard is even smarter
than the average person. I therefore chose to use the
term lizards instead, and each of my lizards appears on
the screen in pretty little photo making it quite clear that
this agent is just a stupid reptile (compare Fig. 2). It is
not good enough to deliver maximum power to your
19
user; you must also indicate just how much power you
are delivering. Intelligently manage the perceptions and
expectations of your user.
13. Conflicts between artist and engineer
These examples are in and of themselves unimportant,
and I do not offer them as feats to be emulated by
others. Instead, they provide examples of a style of
software design that helps engineers and artists to work
together. The engineer designs the tool that the artist
uses, and the artist makes requests for feature improve-
ments. I have found that artist suggestions usually fall
short of my ideals. Ofttimes the artist will attempt
software design, suggesting some scheme or idea in its
computational terms. Since most artists are lousy
programmers, these suggestions are often lame, but the
engineer should not dismiss them with the derision that
the ideas themselves deserve. Instead, the engineer
should interrupt the technical description by asking the
artist, ‘‘What are you attempting to accomplish with this
idea?’’ Empathetic probing will often reveal a worthy
idea underlying the atrocious technical suggestion.
For example, at one point, Laura desired to have her
actors attend a party. She wanted to be able to direct
them to arrive at the location of the party at an assigned
time, and proposed a scheme for doing so. Unfortu-
nately, her scheme would have conflicted with the basic
engine architecture, which algorithmically controls the
movements of the actors. I could easily have transferred
the engine’s control of actor movement to her, which in
turn would have required her to specify all actor
motions in all situationsFan onerous responsibility
that would have consumed far too much of the artist’s
time. The solution we hit upon was to give the artist
control of an ‘‘appointment book’’ for each actor, which
in turn was consulted by the engine in moving the actors
about. If the artist did not use the appointment book,
actors moved under the normal algorithms; if she did,
then the actors responded to her dictates. This gave her
the power to control their motions without the
responsibility to specify those motions in all cases.
14. Conclusion
Interactive storytelling demands creative partnership
between engineer and artist. We have possessed hard-
ware capable of handling interactive storytelling for at
least a decade; the reason why we have not yet produced
good interactive storytelling technology lies in our
failure to forge effective creative partnerships between
engineers and artists. I fear that such partnerships
remain out of reach of most engineers and artists.
Engineers must confine their efforts to the creation of
20 C. Crawford / Computers & Graphics 26 (2002) 13–20

Fig. 2. Example screen: user interface for the storyteller with appropriate terminology.

tools for artists, making a good-faith effort to create the
tools that best meet the true needs of the artists; and
they must learn at least some of the artists’ terminology.
Artists in their turn must trouble themselves to learn
algebra; they must endeavor to express their needs to the
engineers as clearly and precisely as possible; and they
must accept the limitations of technology without
blaming the engineers. Most of all, both sides must
overcome their mutual antipathy and approach each
other with genuine respect. Only then will the guidelines
presented here help them cooperate productively.
Readers may find more information on the Erasma-
tron interactive storytelling technology at http://
www.erasmatazz.com [3]. A thorough index of websites
on interactive storytelling and related technology can be
found at http://home.netcom.com/Bapstern/interacti-
vestory.net/links.html [5].
References
[1] Snow CP. The two cultures, reissue of snow’s lecture of
1959. Cambridge: Cambridge University Press, 1993.
[2] http://academics.vmi.edu/gen ed/Two Cultures.html
[3] http://www.erasmatazz.com
[4] Miller GA. The psychology of communication. London:
Penguin Books, 1967. p. 82.
[5] http://home.netcom.com/Bapstern/interactivestory.net/links.
html