Post navigation

Twine Gardening

I haven’t published much in Twine on IFDB, but I actually use it a great deal: it’s become a prototyping tool of first resort for a wide range of professional projects, the format in which I deliver content to be converted into some other final presentation. A not-trivial amount of pro-level game story prototyping happens in Twine these days.

Which reminds me to mention that Chris Klimas has a Patreon for Twine maintenance and development, and it would be great to see that get some more support. Twine is usefully free to creators who might not be able to afford it, and long may it remain so — but I use it for industry purposes, so I pay for mine. (He’s also reachable via Unmapped Path, and has developed an engine to bring Twine pieces to mobile.)

One of the most characteristic things about writing in Twine is the business of curating the narrative map. Twine generates this map automatically, making a new passage for content every time you create a link that doesn’t refer to an existing passage, and placing that box somewhere near the originating passage. Which is fine, to a point, but very soon several things happen.

performance drags and Twine takes its own sweet time inserting the box

Twine’s idea of where to auto-place the box doesn’t correspond to my idea of how the contents should be visually arranged

I can never zoom out as far as I want to, because even the smallest-box depiction of the Twine map doesn’t show me the whole monstrosity I’m working on

A really large portion of my time working in Twine consists of clicking back to the map view and dragging boxes around to better convey the story structure I have in mind. Pruning. Gardening. Rebalancing. Trying to make clusters of content stick together and make critical moments visible at a glance. Structuring so that I can recognize certain standard mini-structures.

For instance, both of these passages belong to a narrative that is, at the large scale, a standard branch-and-bottleneck, but the lower-level structure is actually very different:

The first diagram describes an “are you really sure you want to commit to this disaster” sequence: if the player heads down the left-hand path, they have several opportunities to opt out and rejoin the main storyline; but past a certain point, they’ve lost the game and are committed to a losing epilogue. And then, if the player survives that and traverses to the lower right portion of the diagram, there’s a big delayed-branching result with many different outcomes customized to what the player’s done so far: a narrative payoff for earlier choices. There’s some clustering to those delayed-branch results, which the diagram also tries to convey.

The second diagram, by contrast, is basically a sorting hat with a couple of different long storylines the player can opt into for that entire portion of the story, but those stories are internally quite linear before they eventually reach their rejoin. These are passages where there’s a bit of exposition to communicate, but the player has chosen which aspect of the story they’re interested in pursuing at the moment, so they get different narrations likely to color their take on the choice that comes next.

I do wish I could color-code: there’s a neat feature in Twine where, if you search for something in the search box, all the relevant passages are highlighted in yellow… but that goes away again as soon as you search for something else, like this:

…but I’d rather like to be able to add a permanent filter to tint every passage with “TBD” in it, or every passage that changes a particular variable.

Clearly other people think about this too — even with the same metaphor — hence the Twine Garden tumblr curated by Porpentine.

To be clear, I don’t say this frequent rearrangement is a waste of time, except in the sense that once you’ve got a sizable work — say 20K words of content spread over hundreds of passages — it starts getting really slow dragging around any significant number of passages at a time. If I decide I need to insert an interlude between two long sections of my game, I generally have to select the second section, move it down half a page, and then go do something else for 30-90 seconds while I wait out the DOS attack I just committed on Twine. It would be nice if that weren’t the case. [Edited to add: this may be a function of the version I’m using; see comments below.]

But some amount of node-gardening feels to me like a natural part of the process, in which I’m checking myself on my structural decisions. (I used to do a different form of this for parser puzzle games too.) You notice immediately if you have way less content on one play path than on another, for instance; in fact, I think the fact that Twine dynamically engages the author in this curation is one of the under-appreciated but most important features of the tool.

Other people do think this is a waste of time. ink doesn’t do automapping of its content, and Jon Ingold once claimed that node mapping was fully pointless. This might seem like we totally disagree, but ink works with very small passages of text, feeding back into each other very frequently — and for several of their works, the large scale structure is actually provided by something else. In the case of 80 Days, that’s the actual literal map of the world.

I know I’m not the only person to wish for a tool that would allow for both macro- and micro-mapping, where it would be possible to view the large-scale segments of the story map from on high, then drill down into the specific structures within a segment. Varytale had branching narratives (mapped) embedded in a larger scale quality-based narrative system (unmapped, perhaps because it’s tricky to meaningfully represent QBN structure; this is something for another post at some point). StorySpace 3 has a concept of clustered content with internal structure as well, though as I’ve not used it, I’m less familiar with how this plays out in practice. ChoiceScript doesn’t do mapping at all, nor does ink; inklewriter has a map that can’t be manipulated and is really best suited for short/small works.

There’s a more perfect solution out there, one that would let you curate both macro- and the micro- branching narrative maps. I’m sure of it. For that matter, it might even be a future version of Twine.

I’ve tried to recreate gamebooks in Twine (for practice), and I have no Twine-thumb at all, almost ending up with a mess, so I’ve kind of hacked together an (probably ugly and limited, I’m not even close to a programmer) emulation of ink’s functionality for inline weaving together of passages within a single box, without changing any of the other types of functionality Sugarcube provides.

I’m also having writing-flow trouble with the constant switching between text-boxes and the fade-in/fade-out animations, so that’s another reason I’m trying this out. Yet, if I want to fit one “room”‘s content into one text box and another one’s in a different one, I can do it, so the visualization element is still there to be used. I suppose I did it so could reduce a cluster’s worth of content into a single text-box to save space. But it might’ve been a wholly pointless exercise; remains to be seen.

The screenshots you’ve posted look like they came from the Twine 2.0 release series. One big focus in 2.1 was dealing with performance issues with big stories — I used Birdland as a benchmark, which is about 75k words — so I’d suggest upgrading if you haven’t already.

The passage placement algorithm is still hinky. If you click New Passage, it puts it exactly at the center of where you are looking, but will then shift it around to avoid overlaps with other passages, which can be unpredictable if you are currently looking at a rat’s nest of passages. Newly linked passages attempt to appear underneath their parent, centered horizontally, but the same caveat applies. This is one area that I could honestly use some help with, because it does surprising things to me too and I’m not sure how to approach the problem.

Being able to color passages by tag is on the horizon. I’d expect that to happen sometime this year.

I have thoughts on how to do a zooming interface with Twine, where you could collapse and expand detail like you’re describing instead of just making boxes bigger and smaller, but they haven’t quite coalesced yet in my head. It’s definitely one of the big feature gaps in Twine right now.

Hey, thanks for the comments! And for the guidance about Twine versions. It’s true I haven’t updated to the latest because I’ve been finishing a large, long-running project, and didn’t want to potentially destabilize; but it might be worth it if the experience is a lot faster. At any rate, so as not to mislead people, I’ve added a note to the body text about this.

Being able to color passages by tag is on the horizon. I’d expect that to happen sometime this year.

Yay!

I have thoughts on how to do a zooming interface with Twine, where you could collapse and expand detail like you’re describing instead of just making boxes bigger and smaller, but they haven’t quite coalesced yet in my head. It’s definitely one of the big feature gaps in Twine right now.

I need to give this a bit more thought, but I think what I’m imagining here is the ability to select a group of connected nodes and give them a shared label, like “Scene in the Canteen” or something. Then those nodes would be replaced by a slightly larger-than-one-node, labeled scene box, but one could double-click into the scene box to see its contents. If any node inside the scene box led anywhere outside, those would be shown as connections from the scene box, until you drilled in.

I’m not sure if that’s the same thing that everyone else would want here, of course! But off the top of my head.

As for passage autoplacement, I’m not sure I do have a better suggestion about how that could be done. Varytale did a nice job of automating it, but the node view wasn’t your primary interaction space, and it was rendering the results of links you’d made elsewhere, so it was able to reason about the appearance of the entire graph at once rather than having to find the best possible place for a new node given an otherwise static existing layout.

I feel like there’s a good solution out there which *doesn’t* rely on the author hand-labelling things.

I’ve experimented a little bit with automatic grouping of nodes — a tool which finds vertical (serial) chains and horizontal (parallel) divisions and boxes them up for you as you work. Or unboxes them; the point was that it would recalculate as you added links so that it always represented the current structure of the graph.

But I didn’t completely succeed with this. It wouldn’t have done a great job with the graphs at the top of your article. And it was proprietary work, so I can’t share the code, I’m afraid.

I finally upgraded. (I was waiting until I had finished with a major project because I didn’t want to switch midstream just in case it proved to mess things up.) And yeah, wow, the performance is now *way* better.

When writing for Tin Man Games, I write the story in one program and map it in another (which allows for colours, comments, different shapes, notes, etc). The two editors and I all have access to the map, and colour-code it based on how close it is to being release-ready (which is crucial with three team members in two states). We also number all sections (which the writing tool does automatically and the map does manually), which is extremely useful for finding stuff.

I have seen demos of Articy:Draft, though never used it for a project myself or bought a license; I didn’t remember this feature being in there, though I see what you mean, given the website. Thanks for the pointer!