An Interesting Question of Design Style

Here’s an interesting problem: how best to communicate historical data across Events? For example, suppose that I have the following sequence of Events:

A request deal B
B what do you want? A
A want B promise no attack
B want A bead
A agree B
???

How does A decide what to do to fulfill his part of the deal?

Method 1
The method I have traditionally relied upon utilizes the HistoryBook. Actor A reacts to the Event “A agree B” and looks at the CausalEvent of ThisEvent to read that B wants a bead. Actor A therefore delivers a bead.

This method suffers from a tendency to produce poison when the ReactingActor looks back for some item in a CausalEvent that doesn’t exist. For example, ReactingActor could look for a bead in the Event “B want promise no attack” and find nothing — which triggers poison. However, poison only serves to invalidate the option, which in fact is precisely how it is designed to operate.

Method 2
This is a method I used heavily with Erasmatron. Every single element that might be used in future decisions is put into a WordSocket. Thus, the sequence of Events above would carry the following information with them, like so:

Screen Shot 2015-01-07 at 11.35.07 AM

As each value is entered during the interaction, it is carried downward for later use. The trick that makes this possible is that those values don’t have to be displayed; they can be carried with the Event without being shown to the player. 

The difference between the two methods is that the first method requires careful calculation of exactly how many steps back in the history sequence one must go to get to the correct causal event containing the required information. On the other hand, Method 2 requires that each of many WordSockets be filled with the previous value. 

The real question here is, which method will be easier for beginners to learn?