Branching stories

On my last post, Kim commented,
"I really want to learn to do the kind of programming you apparently do. I'm interesting in exploiting the choices that you mention so that I can show students (a) that writers have choices and (b)ways to play with choices. My hope would be they'd transfer the comfort they gain with playing with choices to their own writing development."

So I thought I'd elaborate a little more on how to do this--first on how I did it with my game, and secondly on a sort of, well, quick-and-dirty way to do it.

The game I wrote back in 2003 was in C++, a fairly common programming language. You could pick it up yourself, it's certainly possible, but I took a semester of CS to really get my head around it; and now, though I know the concepts well enough, I doubt I could really write a similar program now without a lot of relearning of the nitty-gritties.

Basically the branching story game has a large library of "nodes," each of which is a specific instance, happening, location, etc. in the story. The game took the information about each node from a text file, so depending on what text file you used, you could have the game load up a number of different games/stories if you wished. Each node had a block of text that presented the player with what had happened, and a number of associated choices the player needed to pick between. This was the game's opening:

"You awake on your side, half covered in snow. You're very cold. There's a lot of blood staining the snow around you; you realize it's from your arm, which upon examination looks like it's been shot--if only you could remember why! You stagger to your feet and look around. You're in a trench that leads away in both directions across the face of a hill."

Then some choices, such as:

"It looks like there might be something down the hill...besides, it'll be easier to go down hill in my condition."
or
"This trench looks like it may go somewhere...I'll follow it and see where I end up."

Each node had a number, and each choice had an associated number indicating which node it led to. The twist that gives this program an advantage over the quick-dirty method I'll outline in a second is that each choice had another number associated with it, which controlled whether or not the player could see that choice. The game could keep track of things the player "picked up" along the way (specifically, there was an array of saved variables, and each node when reached by the player could turn one of those variables on, to represent the gain of some item, skill, or informational tidbit, or turn one of them off, to represent using or losing one of the same), and that could range from taking a key from the gatehouse to whether or not they chose to talk to the postman; therefore, if the player came to a locked door but had not picked up the key, the option to unlock the door would not appear. Or if the player had not followed the story in such a way as to learn that the neighbor's daughter liked chess, they could not then challenge the neighbor's daughter to a match...quite flexible in that regard.

Now, the quick and dirty replication of this program could use html to accomplish almost the same thing, and in some ways it could be better, as it would be able to look nice and even use illustrations. I would start with a simple html page reading something such as:

James the baker was strolling down Main Street when, through a window, he spied his mother-in-law shopping for a puppy. James frowned, recalling that he had been missing some of his silverware since her last visit. On impulse he entered the store and tapped her on the shoulder.

Then I'd follow that with some links:

(link to page 2a) "Good afternoon," James said. "Are you going to get another retriever to play with Rover?"
(link to page 2b) "I've been missing a few of my grandmother's forks lately," James explained. "Have you seen them?"
(link to page 2c) "I know you stole my silver," James grumped. "I hope one of my spoons chokes you."

Pages 2a, 2b, and 2c would follow the same lines as the above, continuing the story in the direction dictated by each link. In this particular instance the relationship between James and his mother-in-law would clearly take very different forms depending on the level of tact the reader/player decided to take in this conversation, since character-driven stories can turn on the pivot of a single line spoken between two characters in passing.

Now in my mind, the html branching story is advantageous in that it can be produced much more easily than a similar .exe-type program. However, such a construction would not really be able to reach the same story point from different paths, because it, unlike the program I wrote, would have no way of remembering what had transpired. If the player picks up a key bit of information by one path, the path on which they use it would have to be unreachable from the path where the player does not learn that information. Depending on the story which is written, however, this might not be much of a limitation; my game depended in part on the reader/player passing through the same location several times, where their actions might unlock new choices at key points; a more purely story-oriented construction might not, particularly if it were only a fragment of story branches intended to illustrate something for an education purpose.

You can see a quick branching story in html that I started as an illustration here. As short and somewhat silly as it is, it still took quite a while to write; a lesson learned in the judicious restriction of branches...