Re: How about "situations" as a plot abstraction?

[WFreitag@aol.com]

Benja writes:

>I do not understand the difference between conflicts/developments and
>situations, yet, as technical abstractions that is. The only difference
>I have been able to observe is that you don't describe situations as
>nested in each other.

Situations is a more general concept. I could only maintain the "all state 
conditions that require resolution are conflicts" principle by holding to an 
extremely broad definition of "conflict." Others resisted that definition, 
distracting from the main issue. A romantic interest can be a very important 
plot situation, but is not (in and of itself) a conflict except under the 
very broadest definitions. Also, there are some situations that don't require 
resolution, but do need to be acted upon. If a character is in high school, 
for example, it might be a good idea for that character to attend classes 
once in a while (something that TV script writers often seem to forget). The 
goal (goals are conflicts, in my uselessly broad definition) of e.g. 
finishing high school may not be part of the story. Or a character might have 
a chronic illness that has effects on the story, without the story having 
anything to do with the character overcoming (or succumbing to, or otherwise 
"resolving") the illness.

I removed the explicit nesting mechanism I'd originally suggested, in part by 
removing the automatic detection of resolution conditions feature. Because 
situations persist over time, they can nest anyway. There's no way to stop 
them from doing so -- that is, one situation can cause events that bring 
about another situation while the first is still in effect, and the new 
situation can change the state in ways that affect or even resolve the 
original one. (A "precursorSituation" function would be handy for more 
explicit nesting, giving a situation access to the object variables of the 
situation, if any, whose situation update verb was a precursor event.) But 
the nesting rules would be up to the author -- for example, a situation could 
give rise to another situation that persisted after the "parent" situation 
was resolved, which would break a purely "nested" model.

>So why is this [borrowed-lawn-mower example] not a conflict? 

This particular example is a conflict. But that distinction is not needed for 
situations, which saves me from having to define "conflict" to make this work.

>And why would it be implemented
>differently?

Differently from what? The "situations" model replaces "conflict objects", it 
doesn't augment them (which would be rather redundant).

>I see a distinction between "state," a relationship that
>does not need to be resolved, and "development," a relationship that
>does need to be resolved. If I had to choose which one to describe with
>"situation," I'd probably put the label on the former. But what you
>describe technically seems to be a relatively straight-forward
>implementation of the latter.

The situation model implements either one. The only practical difference 
between them is the intentions of the author. The expression of those 
intentions is the mechanics of the situation update event. The author decides 
whether or not the situation update event will attempt to bring about 
resolution, and if so how (and even if the attempt is made it may or may not 
succeed). The only universal characteristic of situations is "needs to be 
paid attention to over time."

- Walt