Title: Working Notes

Section: Initial High-Level Story Overview

While there are many minor details added and dropped along the way, here are the main, high-level story events I have long planned to have happen in the Demeter story.  I compiled this list after watching a few horror movies (particularly Night of the Living Dead, The Mist, and Alien) and thinking of their plots in terms of Propp-like story functions.

* Captain: "They're all dead."  (Initial condition/central conflict introduced)
* Argument over what to do.  (Should include issues of belief/reality of supernatural danger; PC should be able to clearly but naturally participate; views and interprersonal conflict should continue throughout remainder of the story)
* The search for more info / Revelation of evidence (Learning full extent and details of the danger/situation; heightened tension)
* Picking off the heroes one-by-one (The cry for help)
* The fallen comrade (Bitten, injured, or even killed; could include PC)
* The hunting party  (Or at least the party that finally breaks from cover, vs. those focused on defense/protection)
* The betrayal/lock out (As seen from either side of the hatch, as either victim or onlooker)
* The tense night (Details depending on supplies/hunger and prior defenses)
* The encounter with Revenant (Could lead to killing it and ending story; or someone is bitten/injured; someone dies; it flees, harmed or unharmed)

Endings include: killing Revenant, suviving long enough to reach the US coast, or dying along the way.



Section: Marlinspike Authoring Tips

The following are issues that were almost system-automated, but proved to need too much human/author supervision.  Therefore, they are enforced only by convention--which is frequently broken when necessary or convenient or just when my attention lapsed while programming.

Some scenes need to be repeated during the course of the story:

This is especially true of reactions.  In terms of story coherence, this repetition often needs to be recognized and acknowledged.  Usually this means tweaking the content of the repeated scene a little, or even hooking/referring back to the last run.  However, this involves a few different issues.  

One is what exactly constitutes a repeat?  Just the same scene occurring more than once, or must all the details also match (including location)?  This will certainly vary by scene.

Then, especially with reactions, a repeat often indicates a thread.  For example, the PC keeps trying the same action on the reacting NPC.  These should not be separate threads, but a single thread.  Furthermore, the thread should extend from the NPC's reaction each time.  And whenever reincorporating or thread building, this should be apparent in the narration to the user.  In the current design, such selection and narration details must be handled by the human author.

Since recognizing repeats mostly affects reactions, there is <DReaction.repeat>.  But it's an issues that can affect other scenes too.


World state is frequently not in sync with story state:

This is most notable with locations.  The _event.loc_ of an action contains the initial starting location.  However, if the player moves during the scene (possibly dragging NPCs along with her), then this location may no longer be relevant when actually processing the details of the action.  Furthermore, recasting and polling scenes' _canPlay_ method also need to consider this.

Getting this right requires intimite knowledge of the order of MS processing--something I still get wrong occassionally even after designing, implementing, and then living with it for 18 months!  
In short:

* action casting and recasting happens before the verb takes effect
* then canPlay()s take effect while <MEventHistory.current>.loc is still the original location and after the world has been updated by all verbs and actions.
* Then the play()s take over as part of a new event in the history with the new event.loc.   Any action recasts of a scene don't take place until after all the play()s.  In addition, since the event tree is normally built recursively by a scene playing any sub-scenes and then adding them as children, sometimes played scenes are not actually in the event tree until after the end of the turn.  (In retrospect, a better convention would have been to add a scene as a child and then play it!)

Most helper methods, such as <MDramaManager.getPresent(list*, loc*)> and the <DNPC> helper routines, therefore take an optional location, rather than always relying on _current.loc_.  However, the author must remember which location to use based on whether writing a recast, canPlay or other rule.

This tangled nightmare (plus inadequacies in current NPC reactions) is a major motivation for MS2.0's "execute as created" approach to event processing.


Scenes should play <NPCs_React> first:

This was not automated for a few reasons.   

The primary reason it is a late addition to the design, and so is part of Demeter rather than Marlinspike proper.  (Originally, NPC reactions were going to handled just like any other scene, but scene selection proved to be too tricky.)  Automating this properly would require overhauling and adding more complexity to the core Marlinspike design.

As only part of Demeter, simply playing this scene first each turn as a separate scene would advance the history so that canPlays would no longer be able to look at <MEventHistory.current>.  (Admittedly, if made part of Marlinspike, canPlays could be called first, then NPCs_React played, and then the selected scene played.)  

This current "manually played reactions" requirement is also a reminder to scenes that certain things may take precedence.  For example, some scenes are rather subdued, and should probably not play immediately after someone was just murdered.  Checking if there are any reactions first encourages scenes to consider this.  Also, they may want to provide some transitional narration if any reactions preceded the scene.  

Remember that scenes should also call <NPCs_React> manually to provide any NPC reactions to scene-internal events (though, sadly, any action recast details won't have actually been processed/executed at the time of the reactions).  Also, when including reactions as part of a scene, the scene should include the reaction reincs as part of its own.  However, the scene should be sure to add at least one more prereq or hook to beat out NPCs_React during scene selection.

Overall, I believe NPC reactions should be automated in MS2.0, but the technical details will be tricky in order to get it right--something I wasn't ready to tackle here in MS1.0.  (See "Managing Reactions" section below for more.)



Section: DM Denial of Verbs

Topic: The Design Choice

In the initial Marlinspike design, I debated whether to allow the DM the option to forbid certain verbs before they happened. 

Arguments for: 
This fit well with the idea of the DM as the ultimate director of the story.  Just as in an RPG, the GM can always say, "No, you can't do that" or "That doesn't work."  

Also, since NPCs are currently puppets of the DM, this would be the only (or, rather, cleanest) way for an NPC to interrupt an action.  For example, it might be nice to have the option for one NPC to stop the PC from attacking a second NPC before it happens.  Even preventing the verb from completing, this can still acknowledge the attempt and build on that attempt.

Arguments against:
One of the cardinal rules of improv is no blocking or "say yes".  The DM and player should be seen as equal creators of the story, with the DM working into the story *whatever* the player can legally do in the world.

In relation to RPGs, generally the GM should only forbid nonsense actions or actions that actually break the rules.  In Marlinspike, the world/verb rules will already prevent such actions of the player.  For example, if a door is locked, the player won't be able to open it.  Thus, if the DM wants to prevent certain story actions, it should just "plan ahead" a little and make such actions impossible to perform in the world.  If NPCs are in the world, adding a simple _react_before_ rule could have them step in and interrupt a verb before it completes.

Finally, this complicates the design.  Before any verb can be executed, the world first needs to determine whether it really is possible (to prevent telling the DM that something happened that ultimately did not).  But then, before actually executing the verb, it needs to tell the DM about it.  The DM then needs to decide whether to allow the verb using only the current state of the world *before* the verb happens.  That is, the DM needs to be able to figure out whether allowing this verb will be helpful or detrimental to the story.

Conclusion:
Uncertain how often I might need to interrupt/stop a PC in the context of an real, working interactive drama, and because I wanted a purity of design where NPCs are entirely subservient/controlled by the DM, I decided to include DM verb denial.

Therefore, I implemented the following order of processing events. CAST means apply all cast and recast triggers.  THREAD means thread those event into the story. SELECT means scene selection (polling all scenes whether they _canPlay_). DO means execute all actions in the event tree. PLAY means play the selected scene.  If an interrupting scene was SELECTed, then the verb would be refused, the threaded scene would be wrapped into an ATTEMPT action, and the DO step skipped.  The interrupting scene could then play, extending the ATTEMPT action thread.

>
>  After action:
>    CAST - THREAD - SELECT - DO - PLAY
>


Topic: The Complications

There are two main, unanticipated issues that then arose during implementation.

Verb Chains:
It turns out that more than one verb can occur during a single turn in Inform.  For example, if the user passes through a latched door, it'd be niced to have the world automatically _Unlock door_, _Open door_, and then _Enter door_ (which actually generates a _Go door-to_). These are 4 separate verbs, each of which needs to be approved by the DM.  

There were two ways to handle this.  One is that each of these verbs should just form its own separate event tree.  This has a certain clarity and simplicity to it, though the DM then needs to (potentially) completely process an event multiple times in a turn.

The other option is that all verbs/actions of the same turn form a single event tree.  While this may seem a bit more tangled at times, it more closely represents the user's experience.  That is, all these event stem from a single command entered by the user.  Also, the DM could process all these events at once at the end of the turn.  This is the direction I took.


World State Changes:
Theoretically, actions only have story-level effects while verbs have only world-level effects.  However, NPCs are caught between story and world.  Thus, actions affect their affinities and other attributes.  However, since DO comes after SELECT, none of these current actions have actually executed yet.  Therefore, the current state of NPCs is actually that of "before the action", rather than "as a result of the action".  This makes DM response much trickier to author.

This is also true of locations.  If the current action involves moving the PC/story focus to a new room, the world state is still in the old location while selecting a scene response. Then the movement occurs, and the selected scene is played in the new location.


Topic: The Wrong Path

The mistake I made was assuming that the DM should process the entire event tree at the end of the turn.  I implemented threads to handle the entire event tree, not to handle sub-trees.  Thus, to avoid having to thread an event, select a scene, and then possibly "unthread" the event if it was interrupted, I decided to only thread at the end of the turn.  (This "unthreading" occurs because threads are formed based on the entire event tree.  If part of that tree is then removed--to be wrapped in an ATTEMPT action--certain thread splices may no longer be true, requiring those threads to be split apart again.)

This led to an implemenation 
of the following process:

>
>  After each action:
>    CAST - SELECT
>
>  At the end of each turn:
>    THREAD(all) - SELECT(again) - DO - PLAY
>

The problems here are 
as follows:

* The current action is not threaded before selection during the turn. 
This means that any interrupting scene still gets a
chance to prevent any verb and so lock the DM to prevent any subsequent
verbs in the chain.  However, during the selection process, such interrupting
scenes are weighted as effectively threading only the current action,
and not any threads that the current action extends.  Essentially, this
simply means that interrupting scenes will generally be selected only if
there are no non-interrupting scenes to be selected for the same action.
(This is why selection is repeated again after threading, to give all 
scenes an equal shot.)

* Nothing restricts an interrupting scene to interrupting only the last verb.
That is, a poorly-written interrupting scene could try to interrupt based on some earlier event in the event tree (though this unlikely).

* If a scene *does* interrupt the action, it currently interrupts the whole tree for this turn.  But some of those verbs were already allowed/processed in the world!

In short, there were a lot of mental deficiencies going on here--most of which were only made clear by the writing of this document!


Topic: The Fix (First Attempt)

So, now that I understand where I went wrong, how do I fix it?  One option is to rip out verb denial altogether, but it's really too late for that.  (See <MS2.0> though.)

Therefore, here is 
a corrected design:

>
>  After each action:
>    CAST - SELECT(interrupters only) - DO
>
>  At end of turn:
>    THREAD - SELECT(normal) - PLAY

* This requires that scenes specifically be InterruptingScenes.  (Before this, a scene be either, announcing whether it was interrupting at the same time it says it canPlay.)

* InterruptingScenes must look only at the _MEventHistory.now_ (a new variable) and must reincorporate that event if they play.

* If an interrupting scene does want to play, only the _now_ event (and its recast subtree) is pulled out of the _current_ event tree and wrapped in an ATTEMPT.  Then the attempt is placed into _current_ instead, the DM is locked, and the interrupting scene plays.

This has the following
consequences:

* Verb chains are still treated as all part of the current event.  However, only the last verb can (should) be interrupted.  When that happens, the event tree reflects it correctly.

* Because uninterrupted actions are DOne as they come in, the world state problem is alleviated somewhat, though still not fully alleviated.  For example, using the previous unlock-open-enter-go door example, a non-interrupting scene playing off the open needs to be aware that the location could now be on the far side of the door!

* Interrupting scenes are still not given equal weighting with non-interrupting.  In fact, instead of being disfavored, interrupting scenes are now given "first pick", and so will always beat out a non-interrupting scene (even if the non-interrupting one is better for the story).  Interrupting scenes don't get to form part of a long thread; instead, they always form a thread of two events: an ATTEMPT followed by the interrupting scene.

* Triggers may expire, thinking they successfully recast an event.  However, that event can then be denied!  This is a pretty serious problem.


Topic: The Fix (Second Attempt)

The problem of falsely-expiring triggers is too troublesome.  
Here's another attempt at a fix:

>
>  After each verb:
>    CAST(including to ATTEMPT) - RECAST - DO(Verb)
>
>  At end of turn:
>    DO(Actions) - THREAD - SELECT(normal) - PLAY
>

* Interrupting is done only through special Interrupting cast triggers.  This means interrupts are certain and immediate; they are not compared to the possibility of continuing the story without an interrupt.  Also, interrupts can only be set for deed/verbs, not actions.  (That is, Blackbeard's servant could be set to prevent the PC from Opening a door, but not from generally DEFYing Blackbeard.)

* InterruptingCasts are checked first, before regular casts, to be sure the Interrupt gets first dibs.

* The interrupting cast must then provide a reference to a scene that can be played in response.  This scene is then polled for canPlay (to see what event it is reincorpating; it can always (and indeed must!) reincorporate at least one event--the ATTEMPTed action) and then played.  [In future, we could consider either a list of potential scenes or else polling the general list of scenes for a better match.]

* Since interrupting locks the DM, THREADing and PLAYing are left for the end of the turn.  SELECT is skipped, since a scene has already been "chosen"

Dropped Alternative (Interrupting Recasts):
I also considered allowing interrupting recast triggers.  In this case, all other recasts would be processed first, to give a complete image of the current event (before interruption).  This tree would then all be wrapped in an ATTEMPT event (which can itself be recast).  

To avoid the problem of falsely-expiring triggers, the list of expiring triggers would be held until the end of the recasting process.  If the ultimate result was an interruption, all the normal expirations are ignored.  But this means triggers can not maintain any more complex internal state than whether to expire or not; even an internal firing count may not be accurate, as some of those may have been on ATTEMPTs.  This is very troublesome for managing State triggers, etc.

However, recasts need to be completed before accurately processing an interrupting recast trigger.  So there's no way to alert a normal recast trigger at the time it fires that it is on an attempt.  And some sort of roll-back mechanism would be a nightmare.  Therefore, no interrupting recasts [which was really a hack anyway; only scenes should be interrupting in the first place!].


Topic: Conclusion

This is somewhat messy, but not too bad.  It moves interrupting closer to the world-level (operating on verbs), but still leaves it as an option should it prove necessary to have it.  If it proves unnecessary, it should be dropped in MS2.0.

(At the time of this writing, I have yet to write a real interrupting scene.)


Topic: Still-Existing Problems

These issues still remain.

* PLAY before scene-DO.  That is, a scene plays (possibly manually adding some recasts to represent NPC actions), then it is recast by standing triggers, and finally all those recast actions are DOne.  This causes a problem for scenes that play other internal/sub scenes in that earlier components do not take effect before later/reaction effects are played.  

Currently, the most noteworthy example of this is in an NPC reply to another NPC: the initial NPC's support/oppose to each listener is not recast to an affront/endear until DO (which was a hack in the first place!).  Therefore, not until after all the sub-scenes have played, does a replying NPC know the full effect of the event she is reponding to!

This problem is highlighted here due to the affront/endear event not even being in the tree yet.  But, for other situations, this issue will be that the event is in the tree but has not had its effect processed yet--for example, one NPC has been affronted by another, but her affinity has not yet been changed by that affront.

This only affects inter-scene events though, and so likely only affects NPC interactions.


Topic: MS2.0

Considerations of what might come to pass
in the future, and various questions regarding such a design:

> 
> After each action:
>   CAST - DO - THREAD - SELECT - PLAY
>

* Could combine CAST and DO, processing/doing each action during CASTing process.

* Actions of NPCs are nearly always story events.  If interrupting at the verb level, how is that handled?  Could be ATTEMPTED(X) with an immediate reaction scene arising from NPC.  [Basically, as MS1.0 is currently designed.]
Difference is interruptions are world-driven, not trigger/story-driven.  Could still reinc/be motivated by earlier events.  All part of moving NPCs into the world, which is a tangled mess of worms discuessed more in <Future: MS2.0>



Section: Managing Reactions

Topic: The Current Design

Managing the mini-scene reactions of NPCs is not going as smoothly as it could.  
Right now, each reaction is loaded in the scene manager like any other scene--except that they are loaded manually in priority order.  

Topic: The Problems

Here are some of the "problems" 
I'm encountering:

* Picking the best primary reaction

This is the reason for manual ordering.  Most reactions incorporate only the current action and so most get the same score.  In MS2.0, it might be nice to have some mechanism to then pick the best one, but, for now, it's just the order that they were loaded into the scene manager that breaks the tie.  For the most part, this works well enough.

* Handling multiple current causes in selection

Right now, scenes don't respond to multiple events in the same current action.  (Some will hook in previous, past instances of the same action, though.)  So, for example, the current action might be both an ASSAULT and a DEFY.  Since the ASSUALT is higher priority than DEFY, only the ASSAULT gets handled.

This problem has another angle: multiple current affronts to the same NPC aren't accumulated when determining a reaction.  For example, some minor ASSAULT might also have some other annoying or defying recasts that, accumulated, would be best treated as some Outraging event but would now only be treated as a Annoying event.

* Playing multiple reactions

It'd be nice to be able to play multiple reactions to the current event.  This is related to (and often an alternative to) the above problem of handling of multiple causes for a single reaction.  For example, an DEFYing ASSAULT should ideally have both of these recognized in the NPC's reaction dialog.

Similarily, it'd be nice to have more than one NPC respond at a time, if appropriate.  For example, it'd be nice to have some chatter from any bystander peanut gallery.  However, I don't want every NPC to react every time.  (That'd be too much chatter.)  And sometimes a major reaction will invalidate a minor reaction.  For example, someone might hit someone or otherwise change the state of the world to make the second person's reaction rather irrelevant or (worse) broken, given the new world state.

* Reactions within scenes

The current plan is that scenes will also incorporate reactions, if necessary, as well as moving the story forward.  However, with no central mechanic for this, it means that each scene is going to have to determine what reactions might be needed and poll each one individually.


Topic: The Solution

I've wrestled with the management of reactions for over a year or more in the Marlinspike design sketches.  The second-to-last design involved a distinction between (Expounding) Scenes and Reactions.  Marlinspike would be able to play one Scene (to forward the action) and as many Reactions as possible each turn.  However, some Reactions would be Significant (as opposed to Light), meaning that only one of these should be played in a turn.  (This handles the problem discussed above of dramatic reactions that change the world state or social landscape.)  Also, Reactions would be different than Scenes in that they would not add triggers to the story state.

However, the details of automating all this social manipulation is tricky.  So, to simplify Marlinspike, I cut this and decided that scenes could just handle these issues internally.  While this is basically working--enough that I don't want to move reactions back up to the Marlinspike level (yet)--I think some sort of centralized reaction processing in Demeter would be a good thing.

When I was explaining to Scott yesterday how Marlinspike works, he suggested responding based on the significance of the affinity change of the previous event.  (Well, I don't think that's exactly what he said, but that's how I've been thinking of it since then.  I'm pretty sure the word "threshold" was mentioned, though.)  Previously, I was thinking of reactions solely in terms of their causal events--that is, ASSAULT or DEFY, not the affinity change resulting from that ASSAULT.  However, the design has drifted a bit so that now ASSAULTs vary by their affinity detail.  (Also, there is the import of events to consider.)

So my current thought is a sort of reaction sub-system.  
Specificially:

* A NPCs_React scene.  

This scene contains all other NPC_XXX reactions.  However, unlike the <MSceneManager>, it does not score reactions in terms of reincorporation.  Instead, it focuses only on selecting reactions for the current event.  

This would fix the problem of handling reactions from scenes: they can all just call NPCs_React scene to handle it.

* NPCs_React manages multiple possible reactions.

It should poll all contained reactions to see which ones canPlay.  Thus, each will return a list of reincs.
NPCs_React can then use this list of lists to prioritize as follows:

First, it should make sure the action/event with the highest absolute detail (affinity change) is reacted to.  [Reacting based on affinity is a better model of NPC behavior.  However, it is slightly counter to the DM's goals, which is to thread based on import.  Ideally, the two will vary in sync.  (In fact, consider this for MS2.0--conflating affinity change and import.)  Since the point of MS1.0 is threading and DM control, lets choose the first reaction based on import instead.]  Okay, highest import.

If there's more than one reaction possible for that event, choose between them in priority/loaded order.  (Note that the chosen reaction might also include sub-reactions in their narration.)

Then, determine whether more reactions can occur.  [I was originally considering a return to some sort of Light/Significant distinction here.  But then I started thinking perhaps a significance score would be better.  But there already is something like that: import!  Therefore, suppose that up to 10 "import"s worth of reactions can be played each turn.  Actually, it'd be better to have more reactions for more important actions and less for minor actions!  Therefore:] Can keep choosing more reactions until the import of the current event (which is that of the highest subevent import) is met or exceeded [possibly with modifier?]. 

[However, import and affinity change can currently vary wildly.  For example, ASSAULT can be a Touch or a Murder.  The import should really vary equivalently too, though.  However, currently the import is in the predicate and so is constant across all actions of that type.  This suggests that I should break up ASSAULT somewhat, so that the import is accurate.  As discussed above, it'd be better for an MS1.0 system to work based on import.]

This should allow one or even two significant reactions or a lot of peanut gallery chatter for major actions; other there might just be a couple comments for minor actions.

Furthermore, to prevent strange potential behavior conflicts, only one reaction per NPC.  So NPC_Reacts should grab the DM.getPresent(true) list of bystander and check off those that have responded (and the PC, of course).  Remember to check off any event actresses in sub-reactions too.  


* NPCs_React could also provide various NPC helper methods for querying the current events.

For example, it'd be nice to have something that finds the NPC with the greatest positive or negative affinity change based on the current event.  (This code is currently already in <NPC_Defends_Other>.)



Section: Reincorporation Algorithm

Topic: The Current Design

Originally, the next scene was selected based on the sum of three factors.
These include:
* the weight of unique (ie, unthreaded) material that scene will reincorporate
* the weight of the total (whether threaded or not) material to be reincorporated
* the import of the current event, if the scene will reincorporate it.

Remember that weight is based on both highest import and number of events in the thread.
For more on this approach, see <MSceneManager.selectNextScene()>.


Topic: The Problem(s)

All the problems encountered so far boil down to this: sometimes scenes that don't
reincorporate much are still better choices to further the story.  This is usually
because a scene provides a necessary reaction to a recent event, because it is 
more "believable" than the alternatives, or because it introduces more story
material to work with in the long run.

Favoring the Most Recent (Current) Event:
The need for consistent, immediate reactions has already been tackled with 
<NPCs_React> and its component reactions, as discussed above in
<Managing Reactions>.  Simply giving weight to the current/most recent event
was not sufficient to ensure reliable reactions.  For one reason, many possible
reactions might reincorporate only the current event, but there still needs to
be a way to manage/select among them.  Also, it's important that one NPC not do all
the reacting, and to control the number of reactions per turn (because frequently
there should be more than one).

Frequently, there is only one scene possible at any given point.  At times where 
there is more than one, they frequently get the same score.  In this case, the
order they were added to the <MSceneManager> breaks the tie.  In this way, I can
control what should play in these cases.

Also, keep in mind that some scenes further the action and don't actually reincorporate
much that has gone before.  Since all scenes need some sort of precondition, however,
this may simply be coming to the current location.  Often, this arrival is the most
recent event when such as scene is then selected.

When a scene does reincorporate the current event, the delicate control based on ordering
in the SceneManager often breaks down.  And frequently the current event reincorporation
seems like a "throw away" reinc just to give the scene some story-level preconditions. 
As an author, I often find I'm wrestling the system itself to control the story in these
situations.  

For this reason, I decided to disable the bonus for reincorporating the
most recent event.


Reincorporation Weight Fails to Select Best Scene:
Yet, even after dropping the current event from the scoring algorithm, there are some
interesting failures.

Here is a good example.  This is from a story segment: the PC is exploring the Zeppelin
while the a GoParty (of one member: Elijah_Roman) is in effect.  The GoParty catches
up with the PC, and the PC decides to wait to see what the GoParty will do.

At this point, there is only one thread...

> ThMgr <#MThreadManager> [size: 1]
> MThread_2 <MThread> [size: 3; weight: 5]
> |* 3=MEvent_7(Mr Elijah Roman: (GoParty_Offscreen)<4>, _, _, Storage Walkway)[reinc:1]>[1.0] <5>
> |- 1=MEvent_4(Mr Elijah Roman: (GoParty_Offscreen)<4>, _, _, Storage Walkway)[reinc:1]>[0] <5>
> |- 0=MEvent_1(nothing: START_STATE<0>, (DST_GoParty), MList_1, Dining Room) <2>


There are three possible scenes that can play...

> #DM-ScMgr: Found 3 potential scenes:
> # * (Evidence_Revealed) <MMiddleScene> <5>: Uniq(0) + Tot = 2
> # * (Pursues_Plan) <MMiddleScene> <3>: Uniq(0) + Tot = 5
> # * (GoParty_Moves_Along) <MMiddleScene> <2>: Uniq(0) + Tot = 6


The event tree for each shows these reincorporations graphically below.

(see notes/Evidence_Revealed.gif)

Structurally, Evidence_Revealed (Elijah notices the corpse on the ground here) scores the worst.
It reincorporates only the starting event (Import: 2),
which has already been reincorporated.  In addition, it leaves the high-import (red) Event 3 (Import: 5)
unincorporated.  (Note that Evidence_Revealed is itself a high-import scene here.)

(Admittedly, part of the problem here is that this scene is reinc-ing the arrival of the PC,
rather than the scene's actress. Also, the scene shouldn't really be playing anyway since 
Elijah saw a corpse on the way here.  Or, at least, it should probably hook that.  But I
don't think the PC saw a corpse, which is what's prompting the scene.  So this is a slightly
contrived example that probably wouldn't appear in practice.)



(see notes/Pursues_Plan.gif)

Pursues_Plan (Elijah grabs the stout hammer available here) scores better because it
reincorporates the actress's arrival here (the end of the single existing thread).


(see notes/GoParty_Moves_Along.gif)

Finally, GoParty_Moves_Along scores even higher because it also incorporates the PC's DELAY.
In this case, this happens to increase the number of events in the resulting thread to 
4, which gives a +1 to the highest import (5), for a total of +6.


However, this produces the opposite order of what I, as author, would prefer.  Story-wise,
it makes more sense that Elijah would first notice a bloody corpse, then notice the hammer,
and then finally leave.


Topic: Potential Fixes

A few different ideas to toss around.


Add the import of the selected scene to its selection score:
An obvious (and easy) fix, this would encourage the playing of important events in the cases
of a tie, but would still allow simpler/"boring" events to dominate if they really tied 
many events/threads together.

The drawback is that this would play high import events that would then themselves need 
to be reincorporated, which would actually give the system more work to do.

Also, this is not a clean fix.  In this example, it brings the various selection scores
to within a point or so of each other.  But this just means minor variations in thread
lengths will tip the selection one way or the other.

Finally, import is a measure of how important the scene should be reincorported later.
This is not the same as how important it is to the play in the first place.  For example,
<PC_Unconscious> has an import of 4: it should be mentioned in some way later, but
it's not a big deal if it's not.  However, in terms of selection, I want this scene selected 
immediately and consistently as soon as it can play.


Shift the burden to author:
In the above example, I found these scenes could be doing a better job listing their preconds.
For example, Evidence_Revealed should be reincing the arrival of its actress to this location
when viewing found corpses.  (However, in the case of a Revenant showing up, actress arrival
may not be relevant.)  

So I could simply argue that more meticulous care to the number and weight of reincorporating
preconditions is needed.  If the author did it "right", then the system would work correctly.

This is dangerous and heavy-handed.  Authoring is already hard enough.  The system is so brittle,
opaque, and difficult to test consistently that this added burden just makes it worse.  And this
doesn't address the basic problem here: there's more than just reincorporation to consider when
selecting a scene.  


Drop the reincorporation criteria:
This authorial-control problem would be solved by dropping the scoring altogether and using only
preconditions. In cases of more than one scene being playable at a time, break the tie by the order 
added to the scene manager.  This gives the most authorial control.

But it also tosses out one of the most important design contributions of Marlinspike!  If
1) the system should build on previous story material, making it essential to the story, and 
2) the way to do this is through preconditions and hooks, then we need this selection criteria.
Otherwise, any reincorporation achieved is simply coincidental, rather than DM-motivated.


Additional variables in selection criteria:
My current MS2.0 sketches include a number of extra dimensions in coordinating reactions and other
components to compose scenes.  One of these--imperativeness--might be relevant here.  This is
simply an author-applied score given to each scene that indicates, if the scene can play, how 
imperative it is that it is actually selected.

This makes the author/system tension explicit: the system can still override the author's 
preference if it can make up the difference in reincorporation weight.


Topic: Conclusion

I know reincorporation is important.  The system is currently using it to build upon past
user actions, as well as past scenes of its own.  

But, through the process of implementing Marlinspike, I've come to realize there is certainly
more to consider when selecting the next scene.  The reaction sub-system issues alone have 
shown this.  Now I've found that, even with regular scenes, some play better than others given
a particular story context.  Frequently this may just an issue of ordering--I want certain
scenes to play first, but ideally would play them all eventually.

Further thought on this should be helpful to the Marlinspike 2.0 design.  Current thoughts on
that have MS2.0 building scenes from reactions and scene components, thus attempting to
balance measures of NPC believability/reaction preference, authorial goals on scene components,
and reincorporation of past material.

But, returning to MS1.0, I think my best fix is to include an author "imperative" rating for
each scene.  (I talked about this briefly with a couple other people, and they argreed that
sounds best.)


Topic: Review

After implementing an imperative measure, I find this is not sufficient to balance the thread 
weight scores.  This problem comes from the relative weight of the reincorpation measure: if
it is too weak compared to the imperative measure, then it will have no effect.  But, as is,
it tilts the delicate balance.

The reason this tilting is upsetting is the reason for the generated reinc scores.  A current
example: when the GoParty returns, there are three potential scenes--the GoParty_Returns, a
Discussion_Starts, and an NPC Pursues_Plan (probably for the inaction plan).  Currently, these
are scoring 11, 13, and 9, respectively, and so a Discussion_Starts rather than the GoParty
first reporting what has happened to it.  

Looking further into where these scores came from, I find it's due to what the scenes have
been written to reincorporate.  Discussion_Starts reincorporates Captains_Message, which 
represents the central conflict of the story and thus has the highest import: 9.  Adding an
imperative of 4 gives 13.  However, GoParty_Returns only reincorporates GoParty_Departs, 
which has an import of 5.  Adding an imperative of 6 gives 11.  And the
departure in turn reincorporates the actions of the PC leaving the passenger gondola... 
but not the first scene.  Thus, Discussion_Starts has an "unfair" advantage.

This brings me back to the earlier point of "Shift the burden to the author".  Formation of
a GoParty should really pull in the central conflict, and then anything that GoParty does
should reincorporate its formation.  This would even out the weightings and give a much
stronger weight to the these "central" story threads when compared to things like a NPC
following an individual plan.

What bothers me on this is the difficulty of authoring this accurately.  It feels 
much too brittle and ad hoc.  Though I suppose it should not be surprising that it would 
be a difficult task to code all the implicit story knowledge the system needs.  For example,
I think it's obvious to us that forming a GoParty is an effect (at least indirectly) of 
the Captains_Message.  But, by failing to include that as an explicit reincorporate,
the MS system does not see it the same way.

A related issue is that reincorporation may not be as necessary for the system's own 
events.  That is, specifying only necessary preconditions, but not all the hooks, and
providing a good imperative measure would still produce a good generated story.  Where 
reincorporation really becomes important, however, is when working user actions into
the story.  This could be achieved structurally by hooks as much as by preconditions.
But, in either case, the original goal of reincorporation was to build on user actions.
In future designs, it may be useful remembering this if reincorporating scenes by the
same mechanism continues to prove troublesome.

For now, I will just have to adjust the the proconditions of the starting scene of each 
state (Discussion, GoParty, etc.).



