Data Type Range of Values NonValue Label NonValue Value Color
Number -32768 - +32767 Undefined 32767 green
Person 0 - 31 Nobody 31 blue
Verb 0 - 4095 NoVerb 4095 orange
Event 0 - 4095 NoEvent 4095 brown
Thing 0 - 127 Nothing 127 purple
Stage 0 - 63 Noplace 63 ???
Time > 0 NoTime ??? ???
Macro ??? ??? ??? ???
Boolean T, F ??? ??? ???
Anything ??? ??? ??? black
This group of data types is intended to expand the concept of data typing in the Erasmotron in two ways. First, I have added several new data types: Thing (which I previously referred to as "Asset"), Stage, Time, and Macro. I'm not so sure about the value of Time as a datatype.
The other new idea is the concept of a NonValue. This is the return value from a function that denotes an unsuccessful computation. I have chosen the highest value of each range as the value that NonValue will take. This creates an opportunity and a danger. The opportunity is for the storybuilder to examine the returned value and, if it is equal to the nonvalue, then take appropriate action. For example, suppose that the Fred decides to take revenge on Joe by, among other possibilities, slapping around Joe's girlfriend. So the role calculation asks for SigOther[Joe]. The storybuilder could then say that
Weight[SlapAroundGirlFriend] <= BooleanToNumber(!(SigOther[Joe] = Nobody)) * somethingelse.
NewDirObject[SlapAroundGirlFriend] <= SigOther[Joe]
This would fix a great many problems. But what if the storybuilder does not avail herself of this opportunity? What if she just uses plain old:
Weight[SlapAroundGirlFriend] <= somethingelse.
NewDirObject[SlapAroundGirlFriend] <= SigOther[Joe]
This is an error condition, but how do we detect it? In both cases, the correct one and the incorrect one, the invalid value is placed in NewDirObject. The error detection must take place after the consequence equations are calculated but before the options are presented to the human player.
I think that this is a place for poison to come into play. What if the interpreter performs some error checking whenever it stores a value into NewDirObject or NewIndObject, and if either is Nobody, then it performs a Level One Poisoning of the results: it sets the weight of that consequence equal to -32768, which tells the engine that this option is poisoned and it may not be presented to the player or considered in any way.
Now let's add a function rather like assert in C; its format is:
Assert(boolean condition, consequence number)
This function evaluates the boolean condition and, if it is false, it poisons the consequence indicated by consequence number. There's one flaw with this plan: it requires the storybuilder to enter the consequence number directly; subsequent editing of the consequence list could render that value incorrect. Perhaps we could make this value a verb constant, but then it would be sensitive to verb editing. (Yeow! This problem applies to ALL verb constants!!! Oops! We will have to insert a major recalculator in the verb editing sequence that adjusts every single verb constant in the entire system whenever a verb is created or destroyed. Hoo, boy, this is gonna cost blood AND cycles!) But there are more problems: what if the storybuilder puts in a verb constant that's not a consequence of this role? I need to tie the assertion directly to the consequence. Do I build it into the token string? That seems wasteful. Perhaps the assert function is enabled in the menu only when a consequence has been selected, and then it automatically assumes that consequence. Now there's a user interface horror story waiting to happen. Do we need a new data type called Consequence? What if there's a new menu item placed in the Consequences menu that allows insertion of assertions (and wild card assignments, too!), but only when a consequence has been selected. Hmm, yes, I like that.