Direct Consequentiality

September 6th

Unsurprisingly, the games people would like to see more direct consequentiality of encounters. They want the obvious arrangement in which they can specify that decision A leads immediately and directly to consequence B. I must admit that my current design, in which many decisions all combine to lead to the conclusion, is highly indirect. So perhaps I am swinging too far in the other direction. Nevertheless, I am adamant that the simple-minded logical style of games, in which all actions lead almost immediately and directly to their consequences, is antithetical to the intuitive style that I am trying to build for the player. 

The fundamental structure of encounters is clear: an encounter consists of three components: the opening event and its options; the selection of an option by the player; and the consequences of that selection. The consequences of that selection are confined to changes in the pValues towards the player. However — and this is important — the changes in pValues are never large. Most interpersonal interaction is fairly conventional and does not result in huge changes in pValues. 

The basic structure of encounters does not support branching of any kind. However, there are three mechanisms that permit branching. The first and second are the Prerequisite and Disqualifier elements. These provide “negative branching” in that they can prevent some encounters from taking place. The only mechanism that permits direct branching is the Consequence element. This is attached to an option, and as such permits deterministic navigation of the tree. 

However, nothing in this scheme permits branching dependent upon the consequences of the player’s choices. The pValues that change have absolutely no effect on the path through the tree. This is unacceptable. Therefore, the system needs a mechanism that permits branching dependent upon pValues. Such a mechanism poses a major design challenge. 

The most obvious approach is to carry out the branching in the reactions section, as this is necessarily dependent upon the pValues. This could be accomplished by a simple change in the Encounter Editor. Instead of attaching Consequences to options, they would be attached to reactions. This consumes some screen real estate, but I have already decided to reduce the number of reactions from four to three, which will free up the necessary space. (I’ll also reduce the number of options from five to three.) The resulting window would look like this: