For a new hypertext story I decided to try and actually plan the whole thing before starting out on writing. Partly because the story is going to be complex, with multiple protagonists and plots with twists, turns and reveals, and partly to try and ensure a solid level of interactivity throughout.
This is a big deal for me. I rarely plan stories. I let them grow and then pummel them into shape. But when you’re coding something as well as writing, that takes a lot more time and you throw a lot away. (And you father many, many bugs.)
That iteration is healthy if you’re finding your feet; with a new interface, say, or a narrative gimmick. But in this case, I know what I’m writing – an Undum-based hypertext along the lines of the (as yet unreleased) No Space to Breathe. So instead the experiment is in taking a more organised approach to story development.
Here’s how it went.
The original scheme was pretty structured. I was going to produce the following:
- A brief one-line pitch of the story: beginning, middle, and end(s).
- A chapter breakdown. Four chapters, prologue and epilogue, who narrates each one and what happens in it. This is where the basic plot gets worked out.
- A beat breakdown. What happens in each scene: what choices can the player make, what important details are revealed when. How do previous choices affect the way scenes play out.
- Code an outline, with major choices and paths laid out.
- Fill in the details.
That was the plan; something along the lines of the approach mentioned in this article by Emily Short. Here’s what actually seemed to work.
First, I brainstormed. I knew my genre, basic structure, and a little about what choices I wanted the player to be able to take. I also had a good idea of my main characters, and who would narrate which sections of the plot.
I also had a strong sense of what kind of interactivity I was going to use – some directed conversations, some things closer to puzzles. I didn’t need a map – because this is hypertext, not parser-IF.
The brainstorm threw up a lot of interesting directions, and better yet, some goals to try and meet. Writing a genre story means meeting a few expectations – if it’s romance, your lovers should meet, be foiled, fall apart through misunderstandings and then be brought together at the eleventh hour. If it’s a detective story, your prime suspect should be the second person to be murdered.
Having a clear list of the expectations I wanted to meet – and the ones I wanted to subvert – made for a great set of headlines under which to produce the actual plot.
That’s what came next. Scene by scene, starting with the first, then the last, then the two in the middle, I worked out what happened and why. That took two days, because each bit broke the bits on either side.
This is the part I am so glad that I did. Had I been writing/coding already, the damn thing wouldn’t have made the least bit of sense, or at least, I would have had a lot reworking to do. Instead, I can now look at it and know that, whatever else, all the cogs do fit together.
It also gives me a list of points of exposition to slot in and tick off. That’s not come in useful yet – I’ve not written that much text – but I can see that it’s going to.
While working out the scenes, I also worked out what the player’s choices were. Here was a scene dedicated to getting the protagonist to Place A. What if they don’t make it? What if they don’t want to go? Here’s how the story pans out in that way.
Next to that are all the game-type decisions. Do I allow failure states? Can a chapter simply end, and force you to replay until you get it right? Is that better or worse than having a game which simply freezes up until you solve a puzzle or find your way through a challenge? I’m still not sure I like my answers, but it’s good to over-viewing these issues rather than making them up on the fly.
So that’s the paper plan done. It’s three pages long, in three different colours, and probably incomprehensible to anyone but me. I threw away another ten pages of doodles, scribbles and notes. As a process, I like it a lot.
The next phase was coding up the game skeleton. Here, the plan disappeared almost completely. I did set up a file structure. And then I started writing Part One, instead of writing a skeleton of the entire game.
And I’m glad I did, because as soon as I started writing, new choices and new directions started to creep out of my narrative plan. A whole new section appeared to deal with a choice players who steered away from the direction I’d laid out for them; a direction I’d intended to force, but in writing, came up with a more graceful solution. A new section emerged, then peeled back into the main thread. The skeleton I’d worked out on paper began to put on flesh.
And here’s my take-away from the process:
Focusing on the major choices in a game design leads you to neglect smaller choices. But the smaller choices are the ones the author, and the player, interacts with the most.
I’ve written 2/5 sections in first draft, and both have demonstrated the same phenomenon: the major choices have become distributed across a series of smaller choices. The nice thing is, however, I can afford to do this because I know where those larger choices are going.
Which is to say, there’s nothing like actually writing something to work out what’s in it.