Flawed Methods for Interactive Storytelling

Let us consider the problem of designing interactive entertainment from a structural point of view. I begin with a simple diagram that presents the structure of a story:

In this diagram, each circle represents an event or action, while the arrows merely show the connections between the events. A story is thus a simple sequence of events: "Once upon a time there was a noble youth named Culhych. His stepmother told him that he must win the heart of a beautiful girl named Olwen, but to do this he had to gain the help of a great king. So Culhych set out for Arthur’s court..."

Note that the sequence of events is linear; that’s why we refer to this structure as a "storyline".

Now, how can we evolve this structure into something that is interactive? Some people don’t bother to ask this question; they just take a story and cram it into a computer, add a few meaningless technological tricks, and pronounce it "interactive". I shall dismiss such travesties without further exercise.

As discussed in my earlier essay, "Fundamentals of Interactivity" (Vol 7, #1), interactivity requires a number of steps or components, but for the purposes of this essay we need only focus on a single critical component of interaction: the element of choice on the part of the audience. The user gets to make decisions, to effect choices. I believe that, without such choice, there is no interaction. If the audience doesn’t get to make a choice, we don’t have interaction, we have a plain old story. A choice would be expressed in our little diagrammatic scheme through something that looks like this:

This is called a "branchpoint", a term taken from programming. The user comes to a point in the story where he gets to make a decision. He has several options. That is, the story can proceed in any of several directions. The user decides which option to take. The important fact is that there is more than one choice the user has a meaningful choice that will influence the future direction of the interactive story.

Now, what happens when we put this structure into our storyline? Well, the obvious thing to do is to simply cram it into the storyline structure like so:

Of course, this creates a new problem: what falls below the empty nodes? Well, the obvious thing to do is to continue the process of giving the user options by tacking additional branchpoints onto the structure. This yields something that I call a "storytree":

This is certainly an imposing structure, isn’t it? Now I’d like to ask, how many plies should the structure have? That is, how many layers should there be in the pyramidal structure? I have drawn just four layers, but what would a real product have?

A quick way to answer this is to look again at the storytree with one portion highlighted:

The highlighted portion, you will note, is exactly the same as the storyline at the beginning of this essay. In other words, a storytree is a storyline creator; a single path through a storytree yields a classic storyline. We can therefore apply what we know about stories to estimate the appropriate depth of a storytree. A movie, for example, will have many more than ten events or actions in it, and certainly less than ten thousand. In other words, I think that a movie has something like a hundred or a thousand events or actions in it. Novels tend to be longer, perhaps.

Let’s be conservative, then, and assume that our interactive story needs only a hundred events or actions in it. In other words, there will be one hundred plies in our interactive story. Let us further assume that each branchpoint will have only two choices available to it this is the absolute minimum required. This implies that the storytree will have a total of 2**100 nodes in it. How many is that? About 10**30. If you had a billion employees creating nodes, each one making one node every second, working 24 hours per day, 365 days per year, then it would take 30 trillion years to make the nodes necessary to build that one storytree.

Oops. We seem to have a problem here.

A variety of solutions have been developed over the years. One of the earliest solutions, first presented 25 years ago, had a structure like this:

I call this trick "foldback". The storyline folds back on itself. For example, consider the first four nodes, labelled A, B, C, and D. Suppose that node A represents Eloise saying to Bart, "I’m just not attracted to wimps like you, Bart". Suppose further that node B represents Bart wringing his hands and pleading with Eloise, while node C has him sneering at her, "Ha! I can find better sex in a broom closet!" Now, node D might represent Eloise declaring, "Oh, Bart, don’t say that I’ll take you back!" which response is appropriate to either of Bart’s actions. The problem with this method is that it robs the interactivity of any meaning. Whatever Bart does, Eloise is going to take him back. Indeed, if you step back from this diagram a few feet, it really doesn’t look any different from a regular storyline. This is a nothing more than a storyline masquerading as a storytree. This is fraudulent interactivity.

This is not to say that foldback is without value. Here’s a model storytree with a small amount of foldback:

Note that this storytree has the same number of choices as the earlier storytree, but three fewer nodes. It gives the audience just as much choice, but requires less work from the designer. Unfortunately, foldback still doesn’t solve our problem with geometric growth. Even with an acceptable amount of foldback, our billion workers might still need a billion years to get the job done.

Kill ’Em If They Stray
Here’s another approach:

I call this the "kill ’em if they stray" approach to storytree design. The designer allows the audience many options, but almost all of the options lead to the death of the player or the termination of the story. This scheme merely spruces up a linear storyline with many options to fail along the way. It’s still essentially linear. Many adventure games and puzzle-stories fit this model.

Obstructionist Stories
Another variation on this is the "obstructionist" scheme wherein the player is presented with a linear sequence of story nodes separated by obstacles:

The audience runs into a brick wall at each stage in the story, and must solve the puzzle before it can proceed to the next stage of the story. This is interactive after a fashion; the audience is permitted to interact with the puzzle. But of course there’s no interaction with the story itself. This is Skinner Box interactivity, reducing the audience to the status of a rat in a maze, required to push the correct levers to get the reward -- and punished for failure.

Despite its serious flaws, the technique has been used in a number of commercially successful products, the most recent of which is The Seventh Guest.

Hand-Wired Storytree
Next comes the "hand-wired storytree", too messy to diagram. The designer sits down and draws a big diagram showing how every node fits into every other node. He builds the entire structure by hand, plotting connections and figuring pathways. This sounds better; after all, it’s hand-tooled and surely must be finely tuned. The problem with such designs is that they are sorely limited by the amount of time that the designer can put into them. Even the very largest such designs sport no more than a few hundred nodes. Moreover, these are often crippled in other ways. They support only the most primitive of boolean connection schemes. In other words, the pathways in the system are opened or closed by the simplest of yes-or-no decision schemes involving such lamebrained factors was whether the audience uses the correct item, whether it recites the magic incantation, or some other such simple-minded pap. More sophisticated arithmetic or probabilistic systems (the current fad-term for this is "fuzzy logic") are too difficult to implement in such a gargantuan task.

Combinations on the above
Then there are the combinatorial schemes, which combine various elements of the above architectures. A bewildering array of such methods have been tried. One such scheme attempts to solve the problem of the gigantic storytree by linking together a group of smaller, more manageable storytrees. The links between the small storytrees are simple, direct connections.

This is common usage in graphic adventures. Each small storytree is used to establish a particular subgoal. The first storytree might determine whether you wheedle the orange key from the one-eyed pirate. With the orange key you can enter the secret room where the purple dragon awaits; now you enter a new storytree whose outcome, if successful, is another tidbit that advances you to the next storytree.

This system fails because each subtree produces a simple success-or-failure result. This means that we can replace each of the small storytrees with a single node that asks the question, "did the audience succeed at the assigned task?" It operates in exactly the same way that the obstructionist story operates.

The Desirability of Bushiness
At this point in the discussion it is incumbent upon me to explain an important point about storytrees. A good storytree is rich and bushy; a storytree that is narrow or scraggly is not very interactive. Why? There are two ways to answer this question.

One way is to think in terms of audience choice. The audience wants to make choices. Choice is the means by which we express our free will. Choice is the manifestation of our personality. Hence, a good design affords the audience with many choices many branches emerging from each branchpoint. Moreover, because foldback robs those choices of meaning, there won’t be too much foldback, and so we get a rich, bushy storytree IF we are truly catering to the needs of our audience.

Another way to look at this problem is to think of the interaction as an act of individuation. When our audience enters our storytree, each person desires to find his or her own personal resolution to the challenge presented in the interaction. This is a fundamental truth of human existence. In anything we attempt, we seek not to mimic the results of the masters, but to create our own unique solution. What cook fails to make some small individuating adjustments in the recipe in the cookbook? My wife is learning photography. If she wanted good photographs, she could buy coffeetable books with lots of magnificent photos in them, photos better by far than anything she will ever take (and it would cost less, too!) But she wants to take her photographs, with her camera, figuring the light her way, framing the shot her way. It is an act of self-expression, of declaring her individuality to the world.

So here we have all this clear evidence that people prefer to express their individuality, and yet what do we do to the audience of our interactive entertainment? We cram them into a slot, demanding that they follow OUR storyline. We narrow their options, declaring some options to be correct and others to be incorrect. We give them only a few choices, because we are too lazy to recognize just how varied they are.

If we wish to offer our audience a truly satisfying interactive experience, it is imperative that we allow each member of the audience to express his/her individuality during the experience. There should be billions of pathways through the storytree, so that each member of the audience can find his own path through, coming to his own conclusion and it’s no fair declaring that only a handful of such pathways are "correct". The average user should be able to move through his own pathway and still find a pathway with a satisfying conclusion. I’m not saying that the user should always "win" or find a satisfying conclusion, but rather that winning should not be based on the designer’s narrow expectations of proper behavior. Thus, we want to create a storytree that is thick and bushy, with billions of pathways leading through it. This is the only way to guarantee that each member of the audience will be able to find an individuating pathway through the storytree.

Returning now to the main line of reasoning, there remains one more commonly used structure. It uses a subgame tucked between the story nodes. The designer creates a small game that, by itself is interesting and entertaining but not quite compelling. Then this subgame is integrated into a simple storytree. This is really just a souped-up version of the obstructionist approach, but it’s more generous to the player in that the player actually gets to do something more than merely solving the designer’s puzzle.

An ideal example of this structure is provided by Wing Commander. This game had a skimpy little story with a hot 3D space shoot-em-up game. Either one of the two elements, by itself, would probably have failed, but when used together the result was a smash hit game. The idea was not original to Wing Commander, though; as far back as 1983, a game called Archon used nested subgames.

So what is left? It would seem that I have shot down every scheme that’s ever been used. This is to be expected. After all, we must admit that the present state of interactive entertainment design is abysmal, and that should reflect itself in our inability to find a way to build a storytree with adequate bushiness without taking a trillion years to design.

There is a solution to the problem, but it’s not easy; I’ve spent the last two and a half years developing it. It requires a fundamentally different approach to the problem. But it does work; I have a working program right now. It generates interactive stories, and it does not succumb to any of the problems described above. And I’d love to tell you about it but first I have to get funding to commercialize the technology. Until then, I’ll leave you in suspense.