What is extensibility? What is considered extensible?
Extensibility is the notion that certain elements of the storytelling engine can be extended, modified, added to, or subtracted from the defined set.
Any S-code, that is, term, function, or operator that goes into any of the equations in the role editor, is fair game for extensibility. For example, a storybuilder could take a hatchet to the addition operator (the plus sign). After all, perhaps s/he doesn't want to add things together. This is a ridiculous example, but it demonstrates just how broadly defined our system is. If our mathomaniacal storybuilder wanted to replace + with, say, a matrix diagonalization function, hey, that's not our business.
More seriously, there are a great many S-codes that might reasonably be subject to editing. First among these are the S-codes that define the personality model. There are sixty of these in the current system. Many are obviously necessary, such as Trust, Affection, Pride, and Greed. Others are obviously specific to Le Morte D'Arthur, such as Cattle, InCampaign, Casualties, and Brave. There are also a number of personality traits that are reasonable, but not be appropriate to some stories; Libido and Sexiness are examples.
A second group of S-codes that could be subject to editorial control are the global variables associated with the story. As with the personality traits, some of these global traits are obviously necessary in just about any story: GameClock, GameDay, ThisVerb, and so on. And there are also plenty of global variables that are exclusive to Le Morte D'Arthur: SaxonStrength, RevoltFlag, and OutsideCamelot, for example.
A third broad group of S-codes are the special functions provided to support the process with high-speed or complex calculations. Again, some of these functions will be useful in any situation: AdjustTrust, CheckHistory, SquareRoot, or CreateLie. Others are for Le Morte D'Arthur only: AmbushHelpValue, PersonalCombat, and so forth.
As you can see, extensibility is tricky because some things are so obvious and natural that we want to provide them no matter what, but there are other things that are just as obviously inappropriate for general purpose work ("Little Red Riding Hood galloped forward on her horse, waving her sword. The three little pigs fled in terror.") So how do we separate the necessary elements from the story-specific ones?
This problem arose from our consideration of the problem of disentanglement. It's obvious that at some point we need to strip out all the King Arthur stuff. I had been thinking of this as a subtractive problem &emdash; how will I remove it? But in fact the problem is larger, for I must also consider what I will put in its place. Extensibility is the strategic issue raised by the tactical problem of disentanglement.
This is the new idea under consideration. We would define the personality model, the global variables, and the set of support functions, and hardcode all these into the system. We'd have to hit on the right set, or something close to it. The storybuilder would have to live with our defined system.
The obvious question raised by this is, are we wise enough to see what the ideal set of S-codes would be? How do we know what the storybuilders will do with it? The obvious answer, of course, is that we will never know what all those creative people will want to do with our system, and so we should provide them with the broadest possible set of tools.
But there's a counterarguement. If we want to give them total creative freedom, why not just give them a sheaf of blank paper and a pencil? That gives them total freedom to do anything they want.
The point here is that we need to strike a balance between freedom and power. A car gives me lots of power to go places fast, but I have to stay on the roads. If I want total freedom, I have to walk. We're building a car here, and the fact that it will have to stay on the roads is a weakness, but one that can be counterbalanced by the power we provide.
We're giving our storybuilder more than just a piece of software that edits and computes. We're giving an intellectual structure, a model for how we think that interactive storytelling should work. Like any theory or model, our model focusses attention, provides clarifying insights, and limits freedom of thought.
A good analogy is provided by word processing software. Every word processor has its own typographical model that forces us to think in terms of fonts, paragraphs, indentation, styles, and so on. The model limits our freedom &emdash; why can't my letters wander up and down on the page in different colors? Why don't I have Swahili notation? But it also makes things much faster.
Yet word processors also offer their own extensibility. I can set up my own style sheets and define my favorite styles. I can set my preferred fonts, indentations, tab settings, page numbering, or whatever. In MicroSoft Word I can rearrange the menus at will. Thus, some elements of the word processor are fixed and others are flexible. We should be able to strike a good balance, too.
Moreover, a narrow system tends to run faster and have fewer bugs. Inasmuch as the Erasmotron already works, and runs fast enough, this isn't much of an issue.
What would a narrow system look like?
We'd start by defining our ideal set of variables (personality model, global variables, and support functions). We'd hardcode this into the system so that it can't be changed. Then we'd add a few empty slots for customization. For example, personality model might have 30 regular traits and 3 empty slots for customization. They'd simply be called "ExtraTrait1", "ExtraTrait2", and "ExtraTrait3". So in a western, ExtraTrait1 might be how much the character loves his horse, while in a science fiction story, ExtraTrait3 might be how much ESP the character possesses. We should be able to come up with a way to permit the storybuilder to add his own labels to these extra traits to make the results more readable. Similarly, we could add some extra global variables and permit renaming of these.
We can't use the slot trick with functions. Sorry, there's just no way to bring special functions into the mix without bringing a programmer along and getting the source code mixed in. This limitation may be the most telling problem with narrow extensibility. If we go with a narrow system, then we must compensate by adding more capabilities to the Erasmo-language. Specifically, our current language does not support branching or looping; if we go to narrow extensibility, we may have no choice but to provide these capabilities.
This is what we have in place right now. The user can freely change the personality model and the function set by editing the Master Globals file.
This requires us to release the story engine source code to the licensee. That's risky. Sure, we have a patent, but still, letting them snoop around in the source code creates all sorts of ugly risks. Do we really want to lose control of our own source code? What happens when people take our source code and start souping it up? What if they study our source code to find a loophole in the patent that they can exploit?
It also requires us to explain to the licensee how to edit the Master Globals file, and creates plenty of opportunities for them to screw up. This is like turning monkeys loose on the source code &emdash; they're bound to come up with all sorts of bugs. Sure, we'll be able to defend ourselves with the observation that "it was never intended to be used that way" but nobody ever accepts that defense. Our licensee will think we're turkeys. The licensees programmers will contemptuously declare that our code is amateur stuff and demand that we rewrite it according in their own style. How will we manage these disputes?
The best arguement in favor of broad extensibility is the fact that we already have it in place. Normally a narrow system is easier to program, and a broad system is more difficult, so most software systems are originally built as narrow systems and their extensibility increases as the designers refine the system. To move from broad to narrow would be a regression in terms of software evolution.
So why can't we have both? We simply build the best system we can, put it into the Master Globals file, and then tell the licensee, this should work for you, but if it's not good enough, here's how to change it. This seems to me to be little different from the broad extensibility scheme with a default option built in. I don't know.
OK, here's an idea: what if we stick with narrow extensibility, but we provide lots of slots and make them nameable. You get lots more capability this way, but it's still under our control. We don't have to give up control of the source code, either.
But there's still the problem of the user-definable functions. I think I see a way to solve it. What if we set up a group of function slots whose default condition is to do nothing, but into which a programmer could stick some code. In other words, we have, say, 16 function slots labelled ExtraFunction1, ExtraFunction2, etc. These come equipped with code that does nothing, returning. But we also include some sort of pointer scheme that allows another programmer to plug values into a table that will jump out to his own code. If we confine it to, say, 16 functions, it shouldn't be hard to do and it won't be anywhere near as messy as the current Master Globals system.
This could work.