My next task is the creation of a better facility for testing and analysis, and the very first subtask is the creation of better labels for these activities. I need terms that communicate to the storybuilder, not programming terms. I like the term rehearsal, and shall definitely use it, but exactly how is a matter of some confusion. There are two basic levels of testing and analysis: a context-free level in which we narrowly test a particular verb, and a general or global level that includes context. This latter should probably be called rehearsal; so what do we call the lower form of testing? I suppose that I shall call it a check. Now to define these two.
A check is specific to gSelectedVerb. It assumes no context, previous behavior, or background. Everything that is necessary for gSelectedVerb to calculate its weighting equations must be supplied in the check itself. This requirement may be too stringent to fulfill in all cases; therefore, we need a means of dealing with cases in which it is impossible to supply all relevant detail.
What details can be supplied? Clearly Subject, DirObject, and the additional objects (other than the Event Objects) can be supplied. Let us assume that only this data is available for the check.
The check will be carried out by direct recourse to the interpreter. We will not go through the planning, scheduling, and execution process; instead we will simply concoct an atom and present it to a procedure similar to ReactToNews. Thus, we'll see only a set of consequence outputs.
What are the inputs, precisely? They are the members of the storyatom, which must be specified by the storybuilder in a dialog box. Since we're talking about a statistical process here, we'll need several kinds of specifications. The default case will look like this:
Subject: Anybody
DirObject: Anybody
CharacterObject1: Nobody
CharacterObject2: Nobody
ThingObject1: Nothing
ThingObject2: Nothing
VerbObject1: NoVerb
VerbObject2: NoVerb
EventObject1: NoEvent
EventObject2: NoEvent
StageObject1: NoStage
StageObject2: NoStage
Now, what other options should be available to the storybuilder? Let's start with character specifications:
Nobody, Character#, AnyMale, AnyFemale, Anybody
The other specifications will have to be NoXXX, XXX#, and AnyXXX.
Now then, how will role activation be addressed? The only way, it seems to me, is to assume the role activation and proceed. In other words, the storybuilder must provide a value for gSelectedRole and the software will assume that the role has been activated. This has implications for the input process, though, because the logical conditions implicit in the role activation equation must be respected. Thus, for example, if this is a romantic verb presuming that Subject is male and DirObject is female, we can't just activate it with any combination of characters. Still, I think that this is the storybuilder's responsibility, and we can certainly make it possible.
Another input parameter will be the number of tests to perform; the storybuilder can decide whether she wants to expend more time to get a closer look at low-probability events.
OK, so the storybuilder specifies the input parameters, and then presses the RUN CHECK button. What's the output look like? The primary output will be an array of numbers for the consequences, showing the distribution of consequence results. We could make this a bar chart similar to what we have for the expectation values.
We could augment this with a list of the actual outputs, that is, a comparison of what went in with what came out. It would take the form:
Fred punches Joe. Joe runs away crying from Fred.
John punches Mary. Mary blows John's head off.
Jane punches Tom. Tom calls Jane a bully.
But I don't think that this does much for us.
Now, what about showing changes in state variables? I don't think this is necessary. After all, the state changes themselves are guaranteed to happen if the role is activated; the only interesting data here would be changes in the emotional relationships. All changes would be directed towards Subject, so we have only a handful of dimensions to worry about. Moreover, since we're restricting this to a single role, we really can afford to collapse all the changes into a single average. Thus, we can merely show average delta affection, average delta trust, etc.
This will require a separate screen rather than a dialog box, because it requires popup menus. I think I can make it fit.