Sequence vs. Interactivity

by Talin

 Originally published in the Journal of Interactive Entertainment. Reprinted with permission.
 

All sequences are the enemy of interactivity.

 I'm not just talking about the obvious kinds of sequences, such as the general flow of a game. I'm talking about the hundreds of little sequences which permeate nearly every game product in existence.

 This article will attempt to explain the reasoning behind this statement, and explore some of it's consequences.

 But first we need a rigorous definition of the word "sequence". For purposes of this article, I use the word to mean a series of steps pre-ordained by the creator of the game.

 By this I do not mean determinism. Naturally, any cause-and-effect relationship will cause a series of events to occur. And we may think that the result is pre-ordained if we believe in a deterministic universe. But many real-world phenomena which we consider to be "interactive" are too complex for humans to predict exactly, and thus appear to be probabilistic rather than sequential. True, the sun rises and sets every day in strict sequence, but the sun isn't interactive.

 The best example I can give is the most interactive thing on earth: The human brain. There are no sequences in the brain. There are no subroutines that say "Think about food now". Neurons send signals to their neighbors unpredictably, messages percolate through the brain in chaotic fashion. And the brain is infinitely interactive. People have more depth and responsiveness than any other system I can think of.
 
 

Sequences in computer games

I'm sure we are all familiar with "branching games", where every so often the player is given a limited set of choices (or branches), and each can lead to a different set of experiences, or even a different overall conclusion to the game. Of course, the branch points are connected by sequences, albeit short ones compared to the overall length of the game. These sequences are the enemy of interactivity too, although not as much because they are shorter.

 In general, the shorter the sequence, the less interactivity it curtails.

 Another example of sequence is the long sought-after and often complained-about "Full Motion Video". (I think that more companies have sacrificed themselves on the altar of FMV than any other game technology, with the possible exception of the Mythical Epic Generator / Universal Game Engine). FMV is about the most un-interactive thing I've yet seen in a computer game.

 Basically, anything that spools off of a CD-ROM in real time is necessarily a sequence, because that's the way CD-ROM technology works. Naturally, I feel that CD-ROMs are the enemy of interactivity too, when they are used in this fashion. (I have no problem with using CD-ROM as a large floppy).

 Story sequences are another example. In current games, stories and dialogues are sequences. Branching stories and branching dialogues are less sequential, but still sequential enough to limit interactivity.

Stories don't have to be pre-ordained, however. An early example is James Meehan's TALE-SPIN, a LISP program which generated simple stories from a database of physical and character relationships. A more advanced possibility is Brenda Laurel's proposal of an "artificial playwright", an expert-system which encoded the rules of drama and storytelling. Each act that the player does causes the story to be completely re-written based on that act, yet still following the tension and relaxation, pacing and climax of a real story. Result: total interactivity.

 In fact, we can think of Laurel's system as one that constrains the player to follow dramatic rules, but allows the player to violate plot. A modern "adventure" game, on the other hand, requires the player to follow the plot, but allows them (even requires them) to totally ignore the laws of drama. After all, what novel have you ever read where the protagonist puttered endlessly around the tavern looking for clues, and finding nothing? Or where the protagonist found the treasure by exhaustively searching every door in a two mile radius?

 The player must be able to violate something, otherwise it's not a game, it's a movie. In fact, it might be possible to come up with a "taxonomy of interactivity", which categorizes interactive designs based on what constraints the player is allowed to break. We start with a base of reference which is a totally non- interactive experience, with zero degrees of freedom. An interactive product can then be classified by the extra degrees of freedom it provides, such as:
 
 

Another approach to the story issue is to abandon it entirely. My friend Leo Schwab has suggested that perhaps the proper metaphor for an interactive game is not "Movie" but in fact "Amusement Park". An amusement park is full of a variety of activities, some of which are short non-interactive sequence fragments (you can't stop the boat, you can't even turn off the damn music), while others have little if any sequential structure at all (shooting gallery).
 
 

Machine Instructions as Sequences

Perhaps the most pernicious sequence of all is the actual game program itself, the sequences of instructions coded by the programmer. These, too, are the enemy of interactivity.

 Now, you are probably thinking that I've gone completely bonkers. Am I actually suggesting that computer games can be created without sequences of instructions?

 No, but you can do something that may seem almost as strange: You can code the game such that the flow of execution in the game is only loosely coupled to the outward behavior of the game. In other words, no part of your code should be a mirror of what's happening from the user's perspective.

 A classic example of this is Conway's Game of Life. In Life, we have gliders, oscillators, glider guns, and all kinds of wonderful creatures made out of cells which flicker back and forth. But look at the code:
 
 

        For each cell

                If cell has less than 2 neighbors, or more than 3 neighbors

                        then set cell off,

                else if cell has exactly 3 neighbors, then set cell on,

                otherwise leave cell alone.

That's all there is! Do you see any "glider gun" subroutine in there? Do you see an IF statement that mentions oscillators?

 Conway's Life exhibits emergent behavior, in other words a complex set of behavior which is not at all obvious by looking at the basic rules of the system.

 Games can exhibit emergent behavior as well. As a designer, one of the most pleasurable moments for me is when the game does something that I could not possibly have predicted, and yet turns out to be the right thing to do! That's when the craft of game design starts to feel like magic.

 To make a game act sensibly and yet unpredictably requires that you throw out all notions of "scripts". The environment in which your characters (or other game tokens) interact will be a sea of facts, a multiplex database of humanly-relevant attributes and relationships. The events which take place in the game will be derived naturally from these relationships rather than being imposed from above by a designer, and each action will affect the database further, spawning new actions.

 Loosely-coupled behavior can also be achieved in other ways as well. There are a variety of chaotic systems that can be employed. One example is the good ol' probabilistic state machine. Imagine a simple "emotion simulator" for example. Each character can only have one emotion at a time. For each emotion, there is a probability (based on the specific emotion and the external stimuli) that it will change to another emotion. Anger can turn to hatred, or to depression, but it's unlikely to turn into joy (at least, not without passing through surprise first).

 In the above example, each emotion would be modeled as a state. Each state would have a number of possible transitions to other states (including a transition to itself, to indicate "no change"). The specific transition chosen would be based on a random probability, assigned by the designer. External stimuli could influence the system either by changing the probability values, or by disabling certain transitions altogether. In addition, each transition could invoke some kind of action, which would inform the player that something is going on.

 State machines such as this can be implemented as strictly code, but it is often better to represent them by a combination of code and data tables. In the latter case, the flow and structure of code has only the most tenuous resemblance to what the player is seeing.
 
 

Conclusion

Note that I haven't discussed the issues of how much or how little interactivity is desirable. Sequences inhibit interactivity; whether or not this is a good thing depends on your goals in designing the game.

 But if you want your game to your make to be truly interactive, you must eschew all sequences. Seek them out in your design and destroy them. Take no prisoners and show no mercy!

 Good Hunting!
 
 


Last updated: 
Talin@ACM.org

 Back to Talin's main page