I'm going to attempt to put together a new plan for Stage III. Here goes:
The starting point is marketing. The marketing concept behind Stage II was fundamentally flawed in that we believed that the Erasmotron could be licensed to studios for large fees. I now believe this assumption to be incorrect, for several reasons. The most important is the conservatism of the studio executives. They are not willing to invest large amounts of money in untried ideas. They of course appreciate the importance of interactive storytelling, but they are unwilling to gamble money on the genre until is has proven its sales potential. Moreover, many feel that their current efforts constitute adequate storytelling. I recognized these things earlier, but had hoped that we could find just a few pioneers willing to invest money in the technology, and their success would drag in the remaining publishers, but now I believe that this is a risky strategy. Getting the first studio to take the plunge could prove difficult, and if we fail, then the entire project collapses.
In the interim, however, I have been astounded by the enthusiasm of the creative people for the interactive storytelling technology. My experiences at ECDC, at UCLA, at Rotterdam, and elswhere all demonstrate a deep yearning on their part for something that will let them do real interactive storytelling. These people are ready to go; they constitute our foot in the door.
Thus, we must re-orient our strategy towards the creative storytellers rather than the executives. The plan will be to enlist their support in a way that proves the popularity of interactive storytelling, then follow up with a studio version. This reverses the order of release contemplated in Stage II. It also carries many implications for the design of the Erasmotron. Instead of building a high-powered tool for studio use, we must now design it for the individual storybuilder/writer working at home. This changes everything. We can no longer assume training classes for storybuilders; therefore our standards of user interface design are now much higher. We must support a less technically adept audience; this requires us to provide greater protection against mistakes. We cannot assume lots of custom artwork and animation; therefore we must provide standard artwork that the storybuilder can paste into the runtime engine. And lastly, we cannot assume the ready availability of a 17" monitor, and therefore we must contemplate redesigning the screen layout for a 15" monitor.
This last option is particularly tricky. A 17" monitor costs about $900, while a 15" monitor costs about $450. Most consumers have 14" monitors. However, most writers have larger monitors, so that they can see a full page on their screen. I have asked Jenn and Laura to ask around about the most commonly used monitors among writers. There are two additional factors to consider with monitor size. If we decide on the 15" monitor, then we shall have to allocate about a month of my time to redesign all the screens. Second, the redesign will result in a more cumbersome user interface, with more nested mouseclicks necessary to accomplish a given task. My inclination is to stay with the requirement of the 17" monitor, but I consider the matter open.
Another issue is the matter of strong typing. The current system uses a "half-strong" typing system: data types are enforced much of the time, but there are three cases (substitutes, ThirdObjects, and FourthObjects) that ignore data types. It is therefore possible to mix up the data types in these slots. For example, a storybuilder could have Upstream_Verb store a Character into ThirdObject, and then mistakenly use the same ThirdObject in Downstream_Verb as a Thing. We could always blame this on the storybuilder's carelessness, but good design makes such oversights harder to make. The only solution I have at present is to replace ThirdObject and FourthObject with PersonObject, ThingObject, StageObject, VerbObject, EventObject, and NumberObject. This is a lot of additional baggage to tack onto the substory structure, and it's especially irksome because in the vast majority of cases these values will be empty. Even worse, it's quite possible that a storybuilder might want to have two things stashed away, requiring two ThingObjects &emdash; but this would not be possible with this approach. Thus, the storybuilder would have five unused objects and still be lacking a necessary one.
We also need to do some further work on the poison issue.
The biggest chunk of work will be providing the front end software. This will include two engines: the smart text translator and the graphics engine. Each of these will also require an editor. Lastly, we'll need to provide some standard artwork to go along with the graphics engine.
We'll also need to build a separable runtime engine that storybuilders can ship with their mythocosm files. This shouldn't be too hard.
Scheduling considerations are dominated by the time required for our test storybuilders to learn the system and build a mythocosm. Initially I'll be the gating factor, as Laura and Jenn await the redesigned Erasmotron. Once they've begun work, my task is to get the cosmetic stuff together (face display and smart text interpreter). We must ask ourselves if we want to take the face display technology up a generation, or leave it as is. The same question applies to the smart text interpreter. Nonetheless, I think that the gating during this period will be provided by the storybuilders. If a storybuilder can produce one completed verb per hour, and we require a minimum of 500 verbs in a mythocosm, then the task will take 500 hours. This comes after training is complete and does not include testing and tuning work. I believe that Laura will not be able to begin work on the Erasmotron until September 1st; after that, she can work half-time on this project. At 20 hours/week, she will need 25 weeks to complete her mythocosm &emdash; six months. This gives me eight months to put together the new Erasmotron. This points towards a March 1, 1997 date for completion of Stage III. In Stage IV we would begin shipping the Macintosh version as a commercial product and begin work on the PC port, which would take about six months.