Structures of Interactive Games


#1

A worthwhile read.

Note, in particular, the difference between “Time Cave”, “Gauntlet”, and “Branch & Bottleneck” structures.


#2

Thanks for sharing. This was a great read. Something that was really useful in helping my thinking.

I think, though, that the author misunderstood the concept of “delayed branching”. Or else I did. The branch-and-merge thing is also talked about in the delayed branching article linked, but delayed branching is much more about stats than how nodes are linked… I think. Right?


#3

Yes, the author failed to explain a crucial aspect of Delayed Branching, that Dan discusses here: https://www.choiceofgames.com/2011/07/by-the-numbers-how-to-write-a-long-interactive-novel-that-doesnt-suck/

What the first article is missing is the “dotted line” of the second article: how stat-changes at the yellow “result” nodes ultimately influence the final orange node, producing the three green and three red nodes at the end.

If someone wanted to create a modified image, that would be great.


#4

My game would fall between the Gauntlet and Branch and Bottleneck structures.


#5

Hey! Glad you enjoyed the article.

Yeah, I didn’t include state in the diagrams; I should probably explain why. First, I made the assumption (perhaps not a good one!) that everybody understands what the word ‘state-tracking’ implies.

Second, representing state-tracking on a diagram of this kind is pretty difficult, and I haven’t ever seen a satisfactory way of doing it in a static image. Even in a fairly simple diagram like the example Branch-and-Bottleneck, if you threw a dotted line in to connect every state-changing node to each node dependent on that state, you’d have an unreadable spiderweb. (Dan’s single dotted line is a decent way of expressing the general concept that things in earlier nodes affect things in later nodes, but that’s really just another way of explaining what state-tracking is! So if your audience already has a general idea of state-tracking, it doesn’t add much.)

Third, there are lots and lots of different ways to use state-tracking, not all of which I have a solid grasp on. (Choicescript has a pretty specific model for that, too, but I couldn’t give a survey of all the other approaches with any great authority.) I was trying to explain pretty generic structures, so I didn’t want to make things more complicated and specific by overlaying a particular model of state.


#6

@heterogenous Hey, thank you for making that post. It actually illustrates some things that I try to explain to authors on a regular basis, and I’m grateful to have it as a reference point.


#7

You can do branch-and-merge without delayed branching at all, right? It’s really just the conflation of those two ideas that I found confusing.

I should also say: The article was awesome and clarified my thinking about some stuff in a really useful way. So please don’t take my bringing up this one quibble as any kind of condemnation.


#8

You can indeed do a branch-and-bottleneck structure without state-tracking that influences later choices, but the more frequently your structure re-merges, the more valuable state-tracking/delayed-branching becomes. In a classic time cave with no merges at all, state-tracking is effectively useless: in something like Long Live the Queen which constantly re-merges to a central sequence of events, state-tracking becomes the entire game: if a game like that didn’t have heavy state-tracking, it would constantly make all of the player’s earlier choices irrelevant.

So the ideas are, if not precisely the same thing, strongly linked.

To clarify a little: Dan’s delayed-branching diagram is a subspecies of branch-and-bottleneck, not identical to it. But most uses of branch-and-bottleneck - all the ones I can think of off-hand - end up gravitating towards the delayed-branching model.


Creating Separate Story Streams
#9

OK. That’s strongly clarifying. And really helpful. Again. Thanks!


#10

This was useful. Apparently I have a sorting-hat-influenced branch and bottleneck going on. :smiley:

However, could someone please help me understand this bit:
“Somewhat rarely, the bottlenecks may be invisible – the plot branches and never reaches an explicit rejoining node, but the choices at the end of each branch are the same or similar, creating an exquisite-corpse effect.”

I understand how bottlenecks can be invisible (e.g. different paths reaching distinct resolutions before heading off to the next arc of the plot, right?) But I don’t see how the “exquisite corpse” metaphor applies, even after looking up the Victorian parlor game. Does it just mean a whole constructed of very different parts, chimera-like?


#11

That’s the meaning I took, too, but I’m not super confident in it.


#12

OK, put it like this.

The game is divided into sections - call them days of the week, as an example. As the last part of each Monday node, you always get the same set of choices about what to do on Tuesday. (There’s no specific then-you-go-to-bed node that they all join up with.)

When people draw a section of an exquisite corpse - I’m thinking of the children’s-game version here, where you draw a head, torso, legs of a human-shaped creature - they have no way of knowing what the previous player drew. Their range of choice is exactly the same, no matter what anybody else does. The author is in the same position - they have to write each node so that it works regardless of what might have already happened. (The one game I know that kind of approximates this is the Ruckdeschel & James What if… series, whose protagonist ends up being something of a social butterfly, so that plot developments which affect one set of friends don’t have any implications in the other branches).

It’s a bit like the chimera thing that you said - I mean, any choice-based story is a chimera of some kind, but in this particular case there’s no guarantee that any two playthroughs will have anything in common after the first node. That said, they can’t be very different - in fact, it kind of enforces a strong uniformity on the world, because if you change too many big things then it’s hard to make later nodes that make sense for every playthrough.