Re: Higer-order plot abstractions

[Chris Crawford <chriscrawford@wave.net>]

Sorry I'm so late coming into this discussion; I've been swamped with Leonid
work and book editing.

I really like Benja's idea of connections as the foundation of an IS system.
It definitely deserves exploration. My hunch is that, in the end, it won't
get us where we want to go, but it will provide useful lessons. More and
more, I think that IS will require an approach integrating a number of
completely different fundamental components. The Erasmatron started off as a
pure event-driven system, and has evolved to incorporate a number of
elements alien to that system, such as plot points and appointment books.
These are band-aid solutions, and with further work I expect to figure out
how to blend these ideas into the core structure.

By the way, I'd like to offer a little niggle: theoretically, the Erasmatron
can handle any of the problems that have been cited in the discussion. In
reading some of these points, I found myself murmuring, "No, that can be
done with the Erasmatron; you need merely do A, B, C, etc..." The trick, of
course, is not whether it is possible but whether it is manageable.
Theoretically, you can write any program in pure assembly language, but in
practice, any program that provides useful results is too big to write in
assembly. In the same way, the Erasmatron can theoretically handle all the
situations raised, but it would be such an onerous task that nobody would
want to try it. It's rather like the proof published some years ago that a
sufficiently large spreadsheet program could execute any task that a regular
programming language could. Right -- but who'd want to write Quake in Excel?

Getting back to reality, I suspect that we really need to consider a number
of fundamental elements. Certainly the event-driven approach championed by
the Erasmatron is one. Certainly some sort of state-driven approach is
another. I would classify Benja's idea as a kind of state-driven approach,
couched in terms especially conducive to interactive storytelling. Other
possibilities: time-driven (not very promising as the core concept, but
certainly useful as a supporting concept); goal-driven (much work has
already been done here); plot-driven (plot templates assembled into
ever-larger structures; and character-driven (also called agent technology,
this is a combination of the state-driven and the need-driven).

Let's not get into a fight over which of these is the "best" approach. I'd
suggest that the problem of interactive storytelling is, say, a
three-dimensional one, and any single-dimension approach is bound to fall
short. The problem is, there's considerable functional overlap between each
of these different approaches -- and the overlap is neither random nor
symmetric. If you are willing to think of this in terms of vector
mathematics, NONE of these approaches are orthogonal and there's no way of
knowing how many are required to span the true vector space of interactive
storytelling. 

Which leads me to conclude that, in order to actually get off the ground, an
interactive storytelling system must have some carefully-chosen combination
of several of these approaches. It will likely not be an even-handed
combination; it could still have a core that's based on one approach, but
augmented by major contributions from other approaches.

With the Erasmatron, I have an event-driven system ameliorated with a touch
of time-driven stuff. So, what should I put into the Erasmatron to give it
greater dramatic reach?

Benja, I think it would be great if you built your state-driven system, but
you must also include, I think, elements of at least two of the other
approaches. The end result could well prove superior to the Erasmatron.
Unless, of course, I keep evolving the Erasmatron with these ideas in mind.
;-)

One other item: several people have mentioned an idea I call "nested
events". These are clauses inside clauses: "Henry threatens Joe with plan A
if Joe doesn't carry out Plan B." I put a little of this into the Erasmatron
with tale-telling and lies, and I have long been tempted to generalize the
system to permit any kind of nesting. I've never gotten around to fully
implementing it, but I have made a few changes in that direction this year.

Chris