Anatomy of a Story Game 2
This is part 2 of “Anatomy of a Story Game”.
This week, we’ll complete the basic story design and discuss some implementation issues in various media.
A story state-diagram
A state diagram is something used in software engineering to design a state machine. We’re going to use one to design an interactive story. That’s a lot of 25-cent verbiage, but the concept is simple. We’re simply going to draw out the possible plots of our story.
In part 1, I wrote out a flash-fiction story. As a very short story, it has only a few opportunities for interactivity, but it does have a few. I started by writing the story in sections, similarly to the way you might write summaries of the sections of a novel on index cards so that you can arrange them visually and see the story flow, so that you can plan your novel.
In this case, we’re doing something similar, based on the same idea, but with a slightly different use of the idea. I’ve written out each of the player-events in the story (or summaries of them) and arranged them into a state diagram.
This state diagram represents an abstract view of the story. It does not necessarily correspond one-to-one with entities in the virtual world or narrative. Events, for example, include only things that the player does that actually move the story forward. Other things the player may do in a game, such as traveling back and forth through the game’s virtual world, do not necessarily generate story events and may not appear on this diagram. This state diagram is only an organizational tool to help us visualize the story.
States
In the diagram, each rounded rectangle is a state. A state is as if you were watching the story on a video tape and you hit the pause button. That frozen point in the plot is the state described inside each rounded rectangle. This is the point at which the player must decide what to do next, in order to progress the plot.
In our story, since it’s being written as a hypertext “choose your own adventure” type of story, the states themselves have no physical form. They simply represent the point to which you’ve read, where you’ve put the bookmark before deciding what to do next.
In interactive fiction and graphical adventure games, the player navigates through a virtual world, interacting with that world, manipulating objects in that world. In this kind of game, a story state may represent the state of various objects or characters in the world. For example, in a Myst-style puzzle-solving game, you might have a locked door. Before you discover the lock combination, the door is closed. That’s one state: “closed door.” After you unlock the door and open it, you’ve moved the story to a new state: “open door.”
Events
Each arrow in the diagram is a player event, something the player can do to push the plot along. Using the video-tape metaphor, this is the time during which we’re actually playing the tape, inbetween pauses, inbetween states. Events move the story from one state to the next.
In a hypertext interactive story, events correspond to passages that the user can read. These are the sections of narrative that I previously wrote. And you can see that the arrows are labelled with the headings of the narrative passages from part 1.
In interactive fiction and graphical adventure games, events usually correspond to cut-scenes. In the locked-door example above, when we unlock the door, we might watch a cut-scene showing the door open, after which time whenever we visit the room with the door, it will remain open.
Choices
During the plot, our character Martin (and thus the player) may face choices. Depending on which path he chooses, the plot will take a different path.
For example, after he asks Jane about the missing book, and Jane feels as though he’s accusing her, he can choose to state his accusation straight-out, or he can choose to backpedal. This story is so simple, each choice represents only a small diversion. But you could make the difference much more involved.
Concurrent states
Immediately after the introduction, denoted by the arrow coming from the “start” of the diagram, the story splits into two story threads. In one thread, Martin questions the guests from his dinner party in order to clue in on who might have misplaced or stolen his book. In the other thread, he searches his apartment, in case someone just misplaced the book, maybe put it on the wrong shelf or something.
These two threads happen independently, as shown in the diagram. At any time, both plot threads will be in force, and one state from each will be active. These are called concurrent states.
Again, this is a very simply story, with only two major sections, each of which has only two concurrent states. Typically, an adventure game will have at least three sections, each with at least three concurrent states, plus a “boss” sequence at the end (which this story also has).
Choices based on state
In the second part of the story, after Martin tries to trap Jane, the story goes one of two ways, depending on whether Martin had previously found the book. Whether Martin had found the book is part of the other story thread. So one concurrent state can effect choices made from other states.
Fatal error: Call to undefined function tweetmeme() in /home/timk/bethestory.com/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 3 |