I keep stumbling over how to handle more than a few path branches and fugidabout loopbacks between branches. I’m used to pantsingthe whole thing so… looking for general advice beyond ‘use this specific thing.’
I’ve worked with two different publishing companies on CYOA games, so I got a lot of feedback from editors. Generally, it went like this:
“Me: So, I want to do [fancy thing with loops and variables]…”
“Them: Hmmm, it seems complicated, and it doesn’t add anything to the player experience. What if you took it out?”
“Them: Now, the game is much better!”
If you look at the very best Twine games, like Birdland, My Father’s Long Long Legs, Howling Dogs, Bogeyman, etc. they tend to have very few ‘big branches’. Almost all the branching is done locally, with a few variables stored for later purposes.
Other games, like Lux, Urs, and the Axolotl Project build a Twine map where nodes correspond to physical locations, and most of the game’s ‘memory’ is just variables that determine if you can progress from one room to another. There is, again, no big overall branching.
The only game I’ve seen where extreme branching actually works is Animalia. It was very hard for the author to do, but you can read about their planning process in this post: https://intfiction.org/t/animalia-second-edition-absurdly-late-post-mortem/14025/1
Usually, the interface in Twine (and AXMA which I use) shows the structure clearly enough to keep track of it. For me, it helps to think of a choice game as a series of connected little exploratory minigames which affect each other.
What craiglocke described is the best strategy. Instead of thinking of the story as an ever-dividing tree of singular branches on a timeline, think of “locations” or at least “story nodes” or beats in your story designed like a connected web similar to a map, and then within each node there are smaller choice trees that set variables to change the plot and other choices available. The player might jump around freely between nodes, or be forced to experience them in order, making smaller choices along the way.
For example, imagine a situation with a house, and the player needs to access the basement.
[rant]First, “The house” is a main node location, essentially a hub to access every room with choices [living room] [bedroom] [basement] [back yard]- each subsequent room is its own hub with links that lead back to each other, and possibly with some minimal interaction. However, the basement is padlocked shut with a chain, and that choice checks a variable which won’t let me pass into the basement hub unless I am holding bolt cutters. (currently - $hasboltcutters = false)
“Back Yard” is a main node telling me there’s a shed in the back, offering a choice to [go in] or [go around] or [return to the house].
“Inside shed” checks $ispoweron - if it’s false, the description says it’s too dark to see. If true, it shows the description which includes a paragraph checking $hasboltcutters - if false, there’s a paragraph describing the bolt cutters with a link to [pick up] which sets $hasboltcutters to true. When $hasboltcutters is true, that paragraph disappears from the shed description as the cutters are assumed to be in the player’s “inventory”. Here’s the magic - after the choice to take the bolt cutters, I re-show the Shed description and the choice to take the boltcutters checks the variable and it no longer tells me they’re in the shed. They’re gone now, and I’m holding them. Narrative magic.
So before I can get the bolt cutters from the shed, I need to click “go around” from the back yard which leads me to a breaker box which turns on the shed lights. There’s a choice there that checks $ispoweron and has a choice in each case [turn on switch]/[turn off switch] which toggles $ispoweron between false and true. Also a link [return to shed].
Then, if I return to “the house”…I can now try the [basement] choice which will let me pass since the $hasboltcutters variable is true. It shows me text how I stoically make quick work of the chain and proceed into the dark basement where the monsters wait.[/rant]
The “story nodes” don’t have to be locations. They can be segments of conversation, or thoughts in the PC’s head, or different times of the day or elements in the forward-moving plot, however you wish to design them.
I tend to like choice-based games with big branches. I feel a bit short-changed if there’s just one main story with a few side branches that fold back in to the main trunk. If Animalia proves that it can be done, then is your main argument for not doing it that it’s difficult to do?
I suppose my question then should be 'I have a partial manuscript that has a few chapters in thendivolves into ‘beat’ paragraphs for filling in. Given you’ve been published? Is there any value in writing like a traditional book and adding paths (that might/might not merge with diffrent variables for each path that affect later on) or is the proverbial market looking for more ‘wandering location to location in a key and loot crawl’?
Nothing about the structure mathbrush describes necessitates writing a key and loot crawl. You should have a look at some of the examples he listed, if you haven’t played them already.
@Will I agree that you should try some of the best games out there and see what you like, then build off of that.
@J. J. I think branching is great, and I do think that time is the limiting factor. Some of us don’t have 30 years to spend on a game like Escape from the Crazy Place!
(If anyone wants to see what 30 years of development can create in terms of branching, you should try J.J’s game: