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

[Chris Crawford <chriscrawford@wave.net>]

Sorry I've been so laggard; I have begun a new round of work on the
Erasmatron, partially as a result of this discussion.

> 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?

You have put your finger on the problem that has detained me for some time
now. I had originally planned the cluster system pretty much as you
estimated it to be -- nothing more than a clean way to group verbs together
for export. However, I realized that I could easily add variables, and
"cluster" became "scene". But then I realized that there could be several
scenes going on at once, so I thought that I might set them up as C++
objects. The cluster identification is carried by the verb, not the object,
so it should be easy. However, I am tempted by another, simpler route: the
artist simply puts whatever special variables into secondary objects in the
initiating event, and can then refer to them as HistoryBook items with a
special variable called ThisScene. Thus, if you're deep inside the scene and
you want to reference some stage that is dramatically important to this
scene, you would refer to HistStageObject1[ThisScene]. Although it's very
simple to implement and understand, it might not provide enough storage,
especially because the initiating event could well carry along some baggage
of its own. At the very least, however, it would save the artist the tedious
task of passing along the various secondary objects from one event to a
distant event. Anyway, implementation would require only a single new token,
ThisScene. I'm reluctant to add lots of tokens, as it requires major
reprogramming effort.

> 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 two Xeno's refer to verbs outside the cluster that lead into or out of
the cluster. 


> 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.

I think we should retain both terms, with "clusters" referring to the
groupings of verbs, and "scene" referring to the instantiation.

But now I will throw in a new subject: dealmaking. This has always been an
important component of storytelling, yet the Erasmatron's handling of
dealmaking has never been sufficient to properly tackle the depth of
dealmaking. I think I have come up with a solution, and here is my essay on
the problem:

Deals Yet Again
December 9th, 2001

I am once again struggling with the concept of deals. These are crucial to
the design, yet they seem so difficult. The problem today is that the value
of the deal to each actor must be evaluated at the time of formulation of
the deal -- the offering actor must be able to estimate the other actor's
likely Benefit to the deal. Since the deal is an event, it cannot be
calculated by a simple lookup. For example, what if Actor1 asks Actor2 to
support a proposal to blockade Actor3 in return for Actor1's support for
Actor2 entering the WTO? Actor1 must be able to evaluate Actor2's perceived
cost to support the proposal, and perceived benefit of joining the WTO. This
could get very complicated, as Actor2 would want to evaluate Actor3's
Benefit toward Actor2 for supporting the proposal.

This looks for all the world like it requires a recursive structure. It
would be great if I could do this in the interpreter, but the interpreter is
not re-entrant. So I must figure out a general scheme for doing this from
the engine. But that won't work because the data needed by the first script
(ensconced inside other scripts) won't be available until after that script
has done its job.

Another approach is to build a separate string evaluator into the
interpreter, rather like the macro system currently in use. The problem is,
it would have to preserve all subject-to-change object variables for the
Interpreter object, then restore them. But what are those variables? We know
that it would be restricted to EmotionalBenefit operations, but those in
turn can reference all the other functions.


I just finished speaking with Dave Walker, who wrote the original
interpreter, about the prospects for modifying it to handle this problem.
The scheme we have come up with looks like this: I add three new standard
verbs to the system: Offer1for2; Request2for1; Demand2for1. These three
present choices in the order in which they are to be satisfied, and whether
they constitute a positive deal or a negative deal (e.g., "your money or
your life!"). The custom information for the deal is placed in the secondary
objects, expressed as a plan. The subjects of the two plans are understood
to be the Subject and DirObject of the deal verb; the DirObjects of the two
plans are stored in the ActorObjects, and will likely (but not necessarily)
be the deal participants. The VerbObjects contain the verbs to be executed,
and the other secondary objects can be used to add more detail if that be
necessary.

For example, here's how the script would look for a deal in which Israel
offers to pull its military out of the West Bank in return for an end to
Palestinian violence:

NewSubject[OfferAforB] <= You
NewDirObject[OfferAforB] <= PA
NewActorObject1[OfferAforB] <= PA
NewActorObject2[OfferAforB] <= You
NewVerbObject1[OfferAforB] <= DemilitarizeWestBank
NewVerbObject2[OfferAforB] <= StopIntifada

Here's an even more interesting possibility:

NewSubject[OfferAforB] <= You
NewDirObject[OfferAforB] <= PA
NewActorObject1[OfferAforB] <= PA
NewActorObject2[OfferAforB] <= You
Acceptable <= Keycode27[CandidateVerb]
Desirability <= (Benefit(You, You, CandidateVerb, DirObject) +
Benefit(DirObject, You, CandidateVerb, DirObject))
NewVerbObject1[OfferAforB] <= PickBestVerb(Acceptable, Desirability)
NewVerbObject2[OfferAforB] <= StopIntifada
Acceptable <= Keycode13[CandidateVerb]
Desirability <= (Benefit(You, DirObject, CandidateVerb, You) +
Benefit(DirObject, DirObject, CandidateVerb, You))
NewVerbObject1[OfferAforB] <= PickBestVerb(Acceptable, Desirability)
NewVerbObject2[OfferAforB] <= StopIntifada

Now, this code would require several new functions. The first of these is
KeyCode; it is simply the value of the boolean key stored for the verb.
(Remember keys? There are 32 of them for each verb, each with its own
label.) KeyCode would somehow include the label of the key in the token
name, rather like what I now do with custom traits and custom relationships.
"Benefit" is the next new token, and the most complex to implement. Read the
first relevant line of code as follows: "The Desirability is equal to the
Benefit to You from the Event in which You perform CandidateVerb on
DirObject plus the Benefit to the DirObject from the Event in which You
perform CandidateVerb on DirObject" When executed, this code will pull up
the script for CandidateVerb and perform its own calculation of the
emotional Benefit for that circumstance. That emotional Benefit will be
reduced to a single number by simply adding up the values of all the
emotional changes. Knowing this, I can use CustomRelationship as the
variable to use to express the value of such verbs.

The big unknown is whether I really can get the Benefit function, with its
internal script interpreter, written and working properly. This will mean
nested scripts, which are very tricky.

There remains another problem: what if additional secondary objects are
necessary to specify the deal? For example, what if one actor offers money
in exchange for some service; how is the other actor to include the money in
the calculation? It would be stored in NumberObject1, but that is not
consulted by the function Benefit.

How about a two-step approach? We run the PickBestVerb to obtain the best
verb, and then the offer is augmented by some cash. Thus, the deal is now
stated as "I offer to perform VerbObject1 on ActorObject1 if you, in return,
will perform VerbObject2 on ActorObject2, and give me NumberObject2
dollars." The amount of cash is calculated directly from the value of
Benefit, since the unit of benefit used by Benefit is, of course, the
almighty dollar, as in, "I feel like a million bucks!"

Chris