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

[WFreitag@aol.com]

Chris wrote:

>Walt, the second version of the Erasmatron has a new construct that I
>originally called "clusters", but lately I've been calling it "scenes". They
>are remarkably similar to the concept you describe here. A cluster is a
>collection of verbs defined by the author. Each cluster has its own special
>set of variables. Usually a cluster would consist of all verbs closely
>connected with a single situation. All the verbs in a fistfight, for
>example, or the borrowing and return of a lawn mower. The artist can then
>use those cluster variables in the scripts. However, the system is not yet
>fully implemented -- you can't yet access those cluster variables in the
>scripts.

Okay, this means I had misunderstood the nature of clusters (hereinafter 
scenes). Because they weren't fully implemented in E2a, I had come to regard 
them as being assemblages of verbs organized primarily for portability with 
little effect on functionality.

I take it, then, that a scene is instantiated each time a cluster entrance 
verb is instantiated as an event. (Hmm, digression... maybe continuing to use 
"cluster" or "verb cluster" or maybe "scene cluster" to mean the collection 
of verbs, and "scene" to mean a runtime instantiation... like verbs vs. 
events... would be a good idea.) So if there are several fistfights going on 
simultaneously (say, at different locations) all derived from the same 
cluster, each such scene would have its own instances of the cluster 
variables. Is that right?

If so, then the next question is how long do the scene variables persist? If 
the thread branches into multiple threads within the scene cluster, then does 
the scene end as soon as any one thread reaches a designated scene exit verb, 
or only when _all_ threads in the scene have done so? The latter would seem 
to be more useful. (Or perhaps a scene cluster could be designated as working 
one way or the other? A treasure hunt ends as soon as someone finds the 
treasure, but a gunfight only ends when all armed parties stop shooting.)

If I understand those issues correctly, then scenes are indeed very similar, 
technologically, to what I described as situations. The Cluster Lizard even 
lists plot point verbs (such as DlyPltPnt) among the "Cluster Core" verbs... 
does this mean that it's already part of the plan that each scene instance 
can have its own plot points? (And BTW, what are Xeno Entrance and Xeno Exit 
verbs for?)

The terminology is also very important here. In fact, this may be one of 
those cases where it's more important than the initial details of the actual 
technology. "Scenes" implies chronologically compact and contiguous chains of 
action, while "situations" implies persistent conditions that could give rise 
to action on an occasional and non chronologically contiguous fashion. While 
much of the same technology would serve either purpose, it's likely that the 
functional details will hinge on what the main mental model is supposed to 
be. For example, an update "plot point" verb sounds unnecessary and redundant 
for a "scene", but useful or necessary for a "situation." "Scenes" sound more 
portable; that is, able to be developend and resolved by events from within 
the verb cluster; while "situations" sound less so. While the lawn mower 
example is nicely compact, many situations might be developed and resolved 
largely by Fate instigating events elsewhere in the story space.

- Walt

P.S. As I've done before, some of my recent posts have again misused the term 
"roles" when discussing Erasmatronics. When I said "situations have roles, 
like events do," I was using "roles" to mean the mappings between the event 
and the actors involved in it... that is, the subject, dirObject, and 
actorObjects. A situation object as I described it would _not_ have roles in 
the Erasmatron sense, except for those of the associated update verb. Sorry, 
my bad.