I really need to think about deals will be organized. There are several issues here. First is the matter of structuring a deal inside a substory record. Clearly, ThirdObject and FourthObject will specify the two terms of the deal. I suppose that we could have their interpretation implicit in the verb. Three basic forms: 1 verb; 2 thing; 3 obligation.
To evaluate these, we need functions like these:
DealActValue, DealThingValue, DealObligationValue
Now, we can modify the substory record to include just three odd objects: ThingObject, EventObject1, and EventObject2. To transfer an object, use ThingObject. To make a deal, use a special function called CreateFirstDealHalf(dealterms), which returns the event index of a fantasy event created in the HistoryBook. That index goes into EventObject1; then use another special function called CreateSecondDealHalf(dealterms) which returns the event index of a second fantasy event in the HistoryBook; this index goes into EventObject2.
What this leaves out are additional person objects (you can't set up a four-person substory), stage objects (you can't invite somebody to a stage or ask them to meet you at a stage or order them to go to a stage), number objects (you can't specify a particular number of items or days or people).
However, many of these features can be made implicit in the verb. If you want to have a four-person substory, you can probably kluge it with a sequence of substories (e.g. Subject orders DirObject to tell IndObject about EventObject1; the new Subject tells the new DirObject about EventObject1, which refers to the fourth person.) For the meetings, you could simply have the verb be "MeetAtMyPlace" or "MeetAtJoesBar" or some such. The same could be done with goto commands. Remember, we don't need to cover absolutely everything in the substory record; the verb can carry a great deal of the meaning and we can always spawn more verbs. Lastly, the lack of a number object may be a blessing in disguise &emdash; if we allow it, what's the user interface for the player?
Oops, there's another problem. If we use EventObjects, then the sentence translator will have to refer to other events to carry out its interpretation &emdash; not a good idea. This will be particularly difficult with later use of abstract graphics. Therefore, I think we should abstain from this approach.
Here's another approach: we have two "special objects" that are appended to the substory, each with its own field for keeping track of its data type. Most of the time, these special objects are not in use, and are zeroed. However, if the storybuilder wishes to use them, she sets up an equation using them, and the equation sets the datatype of the special object to the datatype of whatever is on the righthand side of the equation. There has to be one other consideration with this method: during the editing process, I have to go back and examine the causal verb to determine the requisite data type. The difficulty here is that the causal substory might not be directly computable, in which case the whole point of the datatyping evaporates.
OK, here's another attempt: what if we pass such parameters directly through the intermediate substories? Thus, the editor can examine the special objects of ThisStory to determine its behavior. The rule, then, is that special objects always pass through unless they are overwritten.
This might work...