We have run into a profound and fundamental problem, one that I feel is so important that I want to take the time to explain it fully, so that I might get the best possible critique from all concerned. The question before us might be framed as follows: what degree of mathematical abstraction will we require of the storybuilder? To explain this question, I will embark on a lengthy description of levels of mathematical abstraction.
Level One: Numbers At this level, we think only in terms of actual numbers: 27, 51, 3, and so forth. This is obviously a very low level of abstraction. Another way to describe this level of abstraction is to note that it can be calculated with the simplest of electronic calculators, in which you just see a number of the screen and add, subtract, multiply, or divide it with other numbers.
Level Two: Variables At this level we substitute a variable for a number, like x, y, or z, or, in the case of interactive storytelling, Pride, Greed, or Libido. We understand that "x" stands for a number such as 27, 51, or 3. It could contain *any* number, and at the level of abstraction we are using, we are unconcerned with the precise numeric value of the variable; our concern is with the truths that apply for any value of that variable. Thus, we might talk about Pride, and our discussion would (we expect) be valid whether Pride was actually 7 or 70.
This level of abstraction can be calculated with an electronic calculator with a single memory register. Thus, in the middle of a calculation, you can push the "Store to memory" button, and it will store that number away for you, and then later you can push the "Recall from Memory" button and it will recall that number. While this is happening, you have forgotten the actual value of the number -- after all, if you remembered it yourself, you wouldn't need the calculator to remember it for you. You just tell yourself, "OK, I've stored the net present value of the corporation in memory, and now I'll do some other calculations, and when I need to get the NPV back, I'll just recall it. Do you see how you're now thinking in terms of a variable (NPV) rather than a number ($27 million)? That memory register is the hardware manifestation of the concept of a variable.
Level Three: Indexed Variables Now we add one more level of abstraction: we think in terms of a set of related variables, such as the pride value of each of the characters in the story. We represent this algebraically as Pride[CharacterIndex]. This represents an increased level of abstraction because now we are thinking about not just one variable, but a group of variables, arranged in a sequence.
Our calculator, in order to handle this higher level of abstraction, must now include a bunch of memory registers arranged in a sequence. It might have, say, 10 memory registers, and now instead of pushing a button labelled "Store to memory", you would push two buttons in sequence: first, a button that says "Store to memory register #", and then one of the digits 0 through 9. So now you're no longer thinking in terms of *THE* memory register, but rather *A* memory register, a register indicated by a number. You can see we're getting more abstract.
Now, let's just stop right here for a moment and note that this level of abstraction is the level of abstraction demanded (at this time) by the Erasmotron. However, we are now contemplating moving to a higher level of abstraction -- a weighty decision.
Level Four: Symbolic Expressions This level arises from the looping construct. Let's think in terms of the simplest looping structure we have created. Here's an example of its use in the Erasmotron:
CharacterSum(Pride[LoopIndex] * Greed[LoopIndex])
First off, this is a nonsensical expression; I don't know why anybody would want to multiply Pride by Greed. Bear with me; let's just assume that somebody has a good reason for this particular combination, as I'm sure that somewhere out there we can find expressions that do make sense. Anyway, the big idea now is that we're putting together an even more abstract expression. This function will actually calculate the following sum:
(Pride[1] * Greed[1]) + (Pride[2] * Greed[2]) + (Pride[3] * Greed[3]) + (Pride[4] * Greed[4]) + (Pride[5] * Greed[5]) + (Pride[6] * Greed[6])
and so on through all the characters. So now we're talking about expressions using our previous level (indexed variables), but we're adding the notion that we can build up structured combinations of these expressions. By "structured combinations" I mean arithmetic groupings of different variables, with the provision that they are grouped by index. The above expression doesn't mix Pride[6] with Greed[2]. Things are grouped "respectively". That adds a higher level of abstraction.
Let's fall back on our calculator example. How would we have to improve our calculator from previous examples to provide this new level of capability? It's a big step: we have to go to a programmable calculator to get to this level of abstraction. Our calculator would require us to push a button labelled "record program"; then we'd push all the buttons that comprise the actions of the loop; then we'd push a button labelled "stop recording". Then we'd set up all the registers with the values they need, and push a button labelled "run program". As you can see, this is a big, big step up in abstraction and complexity. Even more important is to note the market success of programmable calculators: they don't sell except to the techie-geeks. This constitutes a valuable data point: just about everybody owns a calculator, but most people draw the line at Level Three.
So now I can put the question before you: should we move to Level Four in abstraction, or should we stay at Level Three?
Arguements for moving to level four The storybuilder needs this level of power. Without level four, the storybuilder cannot build general-purpose looping structures. Instead, the storybuilder will be confined to whatever custom looping functions we choose to provide. The storybuilder's ability to explore the intellectual space provided by the Erasmotron model will be severely constrained.
There are billions and billions of possible expressions that the storybuilder might want to use; how can we be confident that any custom functions we provide will meet all possible needs?
Arguements against moving to level four This is too complicated. A programmer might be able to utilize this capability, but not a storybuilder. Observe that Chris has a programmable hex calculator, and he can't program it because it's too much hassle learning the damn programming language.
The vast majority of those "billions and billions of possible expressions" are nonsense expressions such as Pride * Greed. Why do we want to provide the capability for creating so much useless nonsense?
I believe that we can build a set of simplified functions that cover the most commonly needed abstractions.
This level of abstraction destroys one of the most useful aspects of the Erasmotron, its ability to prevent all sorts of errors on the part of the storybuilder. If we go to this level of abstraction, we will no longer be able to provide that level of protection. All sorts of programming problems will emerge.