How about "situations" as a plot abstraction?

[WFreitag@aol.com]

Laura's observations about the alienness of some aspects of the discussion 
between me, Benja, and Chris (from her perspective as a prose author) got me 
thinking about the whole blind men and the elephant nature of the problem 
once again. Anything sufficiently complex has lots of different valid ways of 
describing it. Sometimes the description most suitable for building the thing 
in question is different from the description most suitable for designing it, 
and yet another description is better for understanding its use.

Realtors and most home buyers, for example, do not describe a house by the 
positions or characteristics of its walls. The walls are a secondary 
consideration, as long as they don't collapse and are sufficiently insulated. 
What they care about is rooms. But to the builder, rooms are an abstraction 
that has little direct relevance. The delivery truck does not deliver large 
prismatic masses of air to the construction site, it delivers two by fours 
and bricks and concrete, which the builder makes into walls and floors and 
roofs.

This is OK because the builder is following a plan. If a builder had no plan 
to follow, and was designing the house on the fly during building, then the 
builder would have to pay far more attention to the idea of rooms. Obviously 
any real builder would do so, since the concept of rooms is pretty easy to 
grasp. But what if a builder paid no heed whatsoever to, had no notion at all 
of, the idea of rooms? The end result would be a meaningless jumble of walls, 
perhaps something like a maze.

Which brings me to the notion of situations in stories. When asked to 
describe a plot very succinctly, most people at least part of the time will 
describe not a series of actions but rather a situation. We see this most 
often in popular pulp. "What's this movie about? It's Bruce Willis trapped in 
a skyscraper with a bunch of terrorists." But all sorts of stories get 
described this way. "Romeo is in love with a girl from an enemy family." 
"Ishmael is on a whaling ship with a captain who wants revenge on the white 
whale that maimed him."

I don't recall much being mentioned about situations in my writing or 
literature courses, or in much of the criticism I've read. The emphasis is 
always on events, actions, developments... the things that plots are "made 
of." Situations are static, usually stereotyped, uninteresting in the 
technical sense, and to the extent that authors need them, they come 
naturally with little conscious effort. Authors don't study situations for 
pretty much the same reason why builders don't study how to assemble rooms. 
It's an abstraction out of phase with where the real work is. Hammer together 
enough walls, and rooms happen by themselves. Plot out enough events, and 
situations happen by themselves.

Except, of course, that they don't. The walls the builder builds have been 
planned in advance specifically so that desired rooms are created. And the 
events an author spins have (usually) been planned in the author's mind 
specifically so that desired situations come about. Creating the events and 
doing it well is the hard part compared with devising situations, but it's 
the situations that make that hard work pay off. Spinning a tale based on 
actions, without an idea of situations, would be a lot like building walls on 
the fly without an idea of rooms. It would also be a lot like Erasmatron.

Chris asked:
>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?

I made a case a ways back for an abstraction I called "conflict objects." The 
idea missed the mark, I believe, because conflicts can be seen as just 
another more complex type of event, while the abstraction that Erasmatron (or 
any other event-based storytelling system, I believe) needs is situations. 
This includes conflict situations, but not all conflicts are situations and 
not all situations are conflicts.

So here, slightly modifying the old conflict object idea, is an operational 
definition for situations in Erasmatron. A situation is like an event. It is 
instantiated like an event, as a reaction to another event, and it has roles 
and can be assigned objects like an event. But instead of happening 
instantaneously and causing reactions like an event, a situation persists 
over time and acts like a plot point. During the time it persists, it causes 
its own built-in "situation update" event to occur at regular intervals. In 
its expected typical usage, the situation update event would be wired to do 
two things: test to determine if the situation has terminated (in which case 
it could terminate the situation object instance), and if not, initiate 
events designed by the author to act upon the situation.

Depending on how used, this mechanism would allow for plot-driven or 
state-driven or (rudimentary) goal-driven approaches within the existing 
Erasmatron event-driven framework. Heck, call it situation-driven if you want 
to make the -driven list longer. No special forward-looking mechanism for 
bringing situations about is included here, but such mechanisms can be 
experimented with once situation objects themselves exist.

The difference between a situation and a state condition is that the 
situation holds all the pertient information about a meaningful circumstance 
in one place. It's like drawing a circle around a set of state elements and 
saying "something important is going on here, something that the characters 
(or the author) will continue to pay attention to." The situation object can 
carry with it (as objects) data that give additional contextual information 
about the condition (such as its cause), and a plan for what the character 
and/or the storyteller might attempt to do about it. Unlike a state condition 
alone (but like an event), a situation is in itself an impetus for action, 
and the contextual information associated with the situation can provide 
guidance for the action to be taken. 

Instead of the customary dramatic examples involving romantic passions and/or 
fisticuffs, consider a really prosaic one: "Dagwood has borrowed a lawn mower 
from Herb." This is brought about, obviously, by the event "Dagwood borrows a 
lawn mower from Herb." The event is over, but the situation persists. As the 
author, I want this situation to motivate certain types of future actions. 
Dagwood will fail to return the lawn mower promptly (as is his nature). After 
a week's time, Herb (given the opportunity to do so) will ask Dagwood to 
return the mower. Thereafter he will ask again at every opportunity, but not 
more than once in any three day period. After two weeks, Herb will become 
increasingly angry at Dagwood and Dagwood will avoid Herb. Dagwood has a 
small cumulative chance of returning the mower at some point (5% chance per 
day) after the first week. Once Dagwood does so, most of Herb's anger at 
Dagwood caused by the incident (75% of it) will dissipate (leaving 25% as 
lingering resentment).

(Of course, I don't want only the characters Dagwood and Herb to do this; 
Dagwood and Herb are filling roles that could be filled by any appropriate 
characters, and the prop borrowed would also be a variable. Some of the 
specific numbers would actually be different for different characters, based 
on personality variables. But for illustration purposes I'll continue to 
consider a specific instance involving Dagwood, Herb, and a lawn mower.)

As Chris has pointed out, the Erasmatron can already do all of this. But look 
at what's required. As a reaction to the event of Dagwood's borrowing the 
mower, Herb plans to ask Dagwood for its return in a week's time. This plan 
gets executed when Herb meets Dagwood, and part of Herb's reaction is to plan 
the next occasion of asking, and to increase his anger at Dagwood. Dagwood's 
reaction is usually nothing except to increasingly change his location 
tendencies to avoid places Herb goes, but there's a random chance he reacts 
by planning to return the mower. If he actually does return it, Herb's plan 
for the next event of asking Dagwood to return the mower is called off (I 
don't know exactly how this would be done but I'll assume there's a way) so 
that chain of events is broken. Also Herb's anger at Dagwood decreases by 75%.

Oops, wait a minute. I don't want Herb's anger at Dagwood to decrease by 75% 
of its current total amount, I want it to decrease by 75% of the amount it 
increased because of this specific incident. That means I have to keep track 
of it seperately somewhere (but where, a custom relationship variable called 
AngerOverBorrowedItem? And what if Dagwood is constantly borrowing lots of 
different items from Herb?), or I have to do some very complex and tricky 
searching of the history book to somehow count up all the anger generated by 
all the relevant events over time.

And consider how much more complex this gets if I also want Herb to 
eventually give up and buy a new lawn mower, after which his anger at Dagwood 
over the incident will slowly decrease... that's just how our pal Dagwood is, 
after all, can't hold it against him forever.

What makes this difficult is that the tangible components of this "situation" 
are scattered in lots of different places. The history book if thoroughly and 
competently searched could reveal that the situation exists because the 
events leading to it are recorded. The possessions state reflects the change 
in possession of the lawn mower from Herb to Dagwood. The relationship state 
reflects Herb's increasing anger. Herb's action plans reflect Herb's 
awareness of and desire to act upon the situation.

A situation object would keep more of this information together in one place. 
The existence of the situation is evidenced by the existence of the situation 
object instance. Herb's and Dagwood's awareness of and desires to act upon 
the situation are represented by the situation update verb, which (as a plot 
point that recurs at intervals) is more flexible, more robust, and easier to 
grasp than a self-perpetuating chain of verbs with long times to plan or 
execute. Herb's anger is tracked by a number object, a variable of the 
situation. Changes are also passed along to the appropriate relationship 
variable so that Herb's anger over the lawn mower can have the appropriate 
effect on their overall relationship, but the local tracking in the situation 
variable allows that anger to be conveniently and correctly reduced again 
when the situation calls for it. In other words, looking at only the 
relationship variable we would know only that Herb is angry at Dagwood, while 
the information embedded in the situation object knows the reason why. 
Another object variable that can be stored conveniently at hand in the 
situation instance is the time at which the borrowing occurred, which is used 
in so many determinations in this particular situation. This avoids having to 
query the history book for that information, which could be difficult and 
might in fact not work properly if the same characters are simultaneously 
involved in other "borrowed prop" situations.

But aside from all the details, an abstraction for situations just seems 
natural, even obvious.* Characters (and fate) react to events, and characters 
(and fate) react to situations. Also, the idea of situations should be as 
understandable to storyworld authors as actors, stages, and props (though as 
always, learning to use them will be tricky).

*Wouldn't be the first time it took me more than two years to think of 
something that, ten minutes after writing it down, seemed obvious.

- Walt