Stage II VNE

Goal

The overall goal of the VNE is to provide a complete development environment that can be used by a team consisting of a storybuilder, a programmer, and a cosmetics team to create complete interactive storytelling products. The VNE will not handle the cosmetic aspects of these interactive storytelling products; its concern is with the internal dynamics of the story. A basic cosmetic interface will be provided with the VNE but we expect users to modify it or substitute their own.

 

What we have so far

The prototype version of the VNE allows editing of the verb traits, definitions, roles, consequences, and consequence calculations. It also allows verb network navigation through either verb classication or the verb causal network. It also has the rudiments of the point-and-click expression editor in place. However, most of these features are fragile and incomplete.

 

Improvements to make in the current feature set

Verb definition: allow auto-repeat of keystrokes.

Scroll bars in standard scroll boxes: allow auto-repeat of steps

Editing of Facial expression: show the facial expression selected

 

Verb Creation and Deletion

This has not been implemented yet; it must be completed in Stage II.

 

Point-and-Click Editor

This still needs branching and local variables. We need deletion and insertion options. Some modifications must be made to enforce certain restrictions on the user, such as insuring that he can't delete a weighting equation for an existing consequence and preventing him from applying logical operators to arithmetic terms and vice versa.

 

Documentation

People can't use it if there's no documentation. This will be a huge job, because the documentation must include a presentation of the theory behind the system. I propose to hire a person (whom I will call "Ham" for now) who will serve the dual function of first naive user, software tester, apprentice storybuilder, and technical writer. Ham's initial assignment will be to convert all of the existing weighting equations, currently expressed in Pascal, into our format. After having used it for a few months, Ham will create the documentation for the system as a whole. I intend that this documentation be online and hypertexty in style, perhaps using Adobe Acrobat. This is cheaper to distribute, more flexible, and more useful than paper documentation.

 

Automatic range checking for certain classes of inputs

It would be handy to check some inputs to verify that they are reasonable. For example, all indeces to character arrays must have values between 0 and CharacterCount; it should be possible to check some of these to verify that they fall within these bounds. This would require additional data structures specifying the allowable range of values for any given variable. There are also plenty of cases when it will not be possible to determine from the code itself whether the value is valid. This means that we may also need runtime bounds checking.

 

Script Editing

This would permit a writer to edit the scripts associated with each verb. It would automatically enter the nine (?) POVs and prompt the user for entries in each one. It would provide the script variables as macro-buttons that can be entered with a single click or command-key. I would like for it to provide some sort of auto-check feature that provides one or both of these capabilities: 1. a tree calculator that figures out how many variations of a basic script are possible; and 2. a sample generator that can show the writer exactly what the output text might look like, using a set of standard default values for the script variables.

 

Face Display engine conversion

The current face display engine must be converted from Pascal to C++.

 

Storytelling engine conversion

The current storytelling engine exists in Pascal; it must be converted to C++.

 

System testing, tuning, and auto-balancing

This is a very large feature. This would put the storytelling system through its paces, exercising the verb network with the defined characters, building up a HistoryBook, and compiling performance statistics for the system as a whole. This would then be fed back directly to the verb adjuster values to provide a simple kind of heuristic adjustment of consequence weights. It could also be examined by the storybuilder to ascertain the overall state of the system's tuning. I have many uncertainties about the exact nature of this process, but I suspect that it will require many months of effort.

 

Options and Issues

1. Should we go cheaper and slower? (No Ham, little Dave, no pay for Chris)

2. or faster and more expensive? (More Dave, additional programmer)

 

Schedule & Milestones

I assume that we begin work on November 1 and complete Stage II on July 31, 1996, giving us nine months to do the work.

 

January 1: The user will be able to create and label new verbs, enter their descriptions, navigate the verb network, create and label new roles for each verb, specify the consequences associated with each role, enter the logical definitions of the roles, enter the weighting equations and functional results of each consequence.

 

February 1: the face display in the face dialog editor will be operational.

 

March 1: the script engine and editor will be operational.

 

April 1: April Fool's; who would take seriously any milestone on this day?

 

May 1: the story engine will be operational. The system will be able to generate stories without interaction.

 

June 1: The statistical analyzer will be able to compile statistics on the performance of the system.

 

July 1: The autoadjustment code will be able to adjust weighting coefficients.

 

August 1: final delivery. Complete, bug-free environment and documentation.

 

Stage III

The goal of all this is to produce a development environment that can be used in Stage III (should Markle decide to fund Stage III) to create an interactive storytelling product. It certainly behooves us to think about what exactly we hope to happen in Stage III.

 

Stage III will have to divide into two separate efforts: final development environment work and creation of the product. These should be treated as financially separate operations, even though we may well shift people from one side to the other.

 

The main development environment work will be to port the various engines from the Macintosh to the Windows 95 environment. Without those engines, we can't have any Win95 product. We may also wish to port the development environment itself onto the Win95 platform, to make it more accessible to others. We will also want to retain some resource for polishing and adjusting the development environment as we learn from our experiences in product creation.

 

Product creation is the second main thrust of Stage III. The topic of our Stage III product could be anything with lots of dramatic conflict and soap-opera feel. Le Morte D'Arthur is necessary as a testing vehicle during Stage II, but we don't have to implement it in Stage III; the only advantage of sticking with Le Morte D'Arthur is that it will save us perhaps $100,000 to $200,000 and shave perhaps six months off our development time. On the other hand, a children's product might be easier to pull off on this our first attempt. Or we could jump straight into a corporate politics game, or a soap opera game.

 

The team for Stage III will likely consist of myself, Dave, Ham, a Win95 programmer, and as many cosmetics specialists as we can afford.