The heart of any interactive storytelling system is the engine that drives the story in response to the user’s inputs. I shall here address only the fundamentals of engine operation; I shall refrain from going too deeply into the particulars of the Storytron engine. Instead, I’ll try to present only what I consider to be the absolute essentials.
I begin with this diagram of a story as a sequence of events:
If a story is a sequence of events, then the task of an engine is to assemble that sequence out of the individual events. Inasmuch as the engine builds the story event by event, this leads inevitably to the conclusion that the engine is essentially a reactive system: when an event takes place, the engine must figure out what event should follow as a consequence of that event. This seems to me to be intuitively obvious to the most casual observer, but some people can’t seem to get this down their craw. Just keep the above diagram in mind when you think of how an engine must operate.
I have already described the system of verbs, roles, and options that the engine needs to figure out the reactions to an event. Here’s how such an engine actually functions:
1. An event takes place
2. The engine determines who witnesses the event (at its simplest, all actors on the stage where the event took place.)
3. For each witness, the engine determines whether that witness has a role to play, using the reaction script.
4. For each reacting witness, the engine figures the immediate consequences: changes in relationships, ownership, etc.
5. For each reacting witness, the engine calculates the best option to choose.
6. The selected option, along with its chosen objects, is added to the plan list, along with its specified time of execution.
7. The engine returns to its regular clock-ticking main loop.
8. At each tick of the clock, the engine consults the plan list to see if any plans are scheduled to execute.
9. If a plan is scheduled to execute, it is moved to the event list (aka the History Book) and we go to Step #1.
There are a million ways to make this more complicated, but I hope you recognize that it’s already pretty complicated.
A Multitude of Engines
People have been building interactive storytelling systems for nigh unto twenty years now. None has been widely recognized as successful; many have been abandoned by their developers. Here’s a list of twenty different systems. As you can see, they span a wide range of approaches. I interpret this to mean that we still don’t know what the hell we’re doing.
The Storytron Engine
The Storytron engine includes all of the basic elements listed above. It also includes these embellishments, none of which are truly necessary and should have been left out:
A. Abort capabilities. These are meant to permit the engine to abort a plan before execution. For example, suppose that Othello determines to murder Desdemonia because he believes that she has been unfaithful to him. He creates the plan to murder her, but has other pressing business to attend to. Prior to murdering her, he learns that he has been duped and in fact Desdemonia is innocent. But that plan is still sitting in the Plan List, waiting to be executed. In the words of Adolf Hitler upon learning that Britain had declared war in response to his invasion of Poland, “What do we do now?” The solution in the Storytron engine is an abort script executed prior to execution of a verb. When the plan attempts to execute, it first runs the abort script (if there is any) and gets either a true or false answer. “True” means “abort this plan!” and the plan is cancelled. In all my work with the Storytron engine, I think that I used the abort script maybe three times.
B. Hidden witnesses. I thought that it was important to allow people to eavesdrop on each other. So I included a feature whereby the spying person could somehow hide while still being privy to a conversation. Again, I never used this much. Another unnecessary complexity.
C. Hijacking the storyline. This one turns out to have some value. Suppose that we have a typical back-and-forth interaction between two actors. Sometimes, it’s important to permit a third actor to intervene, interrupting the back-and-forth interaction. I call this ‘hijacking the storyline’ and included a feature that made it possible for the author to insure that such an action would prevent any further reactions of other actors. For example, suppose that Joe and Fred are arguing. Joe says to Fred, “You’re stupid poppyhead!” At this point, Mary intervenes and says, “Both of you just shut up!” Fred does NOT get to react to Joe’s insult; all reaction calculations are terminated on Mary’s reaction and instead the actors must react to Mary’s event.
D. Alarm events. This was an entire class of events that were triggered on various events. They correspond to hardware interrupts on microcomputers. There are four such alarms: clock alarms, meeting alarms, prop alarms, and stage alarms. Alarms can be set in a script at any time during the story.
A clock alarm is something that happens at a predefined time. The author creates the clock alarm and sets the time for it to go off. When it goes off, it triggers a clock alarm event, and presumably the author has set up some reaction to that event. This permits the author to have something happen automatically at a predetermined time, outside of the normal action-reaction system of the engine.
A meeting alarm is triggered when two specified actors meet for the first time. The purpose of this is usually just to permit the author to show an introductory event. For example: As you enter the room, a tall dark stranger approaches you. “Hi, I’m Darth” he says. He’s dressed entirely in black, and he sounds like he has a cold. His cape is quite dashing. The author can create a meeting alarm for any pairing of actors.
A stage alarm does the same thing for a stage. The author specifies a combination of an actor and a stage. The first time that particular actor enters that particular stage, the stage alarm is triggered. Again, the author can create many stage alarms, one for each pairing of actor with stage.
A prop alarm does the same thing for any time that a specified actor enters a stage containing a specified prop.
E. Automatic movement. The movement of actors is the cause of many problems. Game designers, still stuck in their little rut of defining everything in terms of spatial movement, always want to be able to control the movement of the actors. “Why can’t I order my actors to move to specified stages?” they whine. I gave in to their demands, a serious mistake. Actors go where they go for specific dramatic reasons, and those reasons should be built into your algorithms, not imposed from above. You don’t really want to let the audience see the strings on your puppets, do you?
The only good reason for an actor to move to another stage is to execute a plan involving an actor residing on that stage. And no, the moving actor needn’t know where the other actors are. This is a STORY, remember? Actors just go where they’re needed, OK?
However, in practice, I found that it was often useful to have actors spontaneously decide that they wanted to interact with another actor. If an actor has been sitting around twiddling their thumbs for too long, then the engine decides that the actor is bored and randomly picks somebody for the actor to go visit. This turned out to be necessary to keep the level of action up. I suspect that better storyworld design would have avoided this necessity.
F. Group activities. Example: “Hey, how many people want to join me in lynching Fred?” This was pressed upon me by overenthusiastic storyworld builders. It was a really bad idea. Don’t do it. End of discussion.
