Detritus: lessons learned from making my first Twine game

Node map for Detritus. Broken-looking passages use the print macro to link based on the contents of a variable.
Node map for Detritus. Broken-looking passages use the print macro to link based on the contents of a variable.

One of the side projects I’ve been hacking away at in my spare time recently is Detritus, an interactive fiction game thing about, well, packing. It’s a packing sim. In all it’s taken me about two months of intermittent work, including a couple of days where I put in six hours or so on it.

It’s made using Twine, a pleasingly versatile game creation tool that lends itself really well to branching narratives. It’s widely used by all sorts of awesome game makers, and it’s capable of a great deal more than it at first appears. There’s a Google group associated with making it better; there are some talented people devoting themselves to making macros for it, chunks of code that extend its native capacities to let people who can’t code do complicated things simply. I’m indebted to Porpentine’s resources list and a bunch of Webbed Space’s macros – without those things Detritus would have been impossible.

It’s much cleverer than it would be if I’d tried to do it all from scratch myself. I learned while building it that by far the best way to implement my ideas was to build on the work other people have done before me. It is not the first time I’ve bodged something together standing on the shoulders of giants, but it’s the first time I’ve literally copied slugs of code without knowing anything about what they do, as though they were magic spells where my only input is to know the activation words. It is humbling to create with tools other people have given freely to the world.

I learned that sometimes, not knowing what you’re getting yourself into leads to bigger, more exciting work than you’d originally intended. I decided, when I started it, that Detritus would have five short acts, each one using a different technique, because that would be a good way to teach myself some of Twine’s idiosyncracies and I’d come out of it knowing which ones worked for me and with some ideas about how to employ them. I thought it’d be a quick project. If I’d realised, when I chose the first objects the player encounters, that my choices would lead to having to write fifty separate individual passages and a reasonably complex looping system to make act 5 work, I might have chosen to do it differently. But I don’t regret that choice at all – it’s a much deeper, more intricate piece than I’d otherwise have written.

I learned that it’s sometimes better to work out what you’re doing before you do it, too. At one point about half way through act 3 I spent an upsetting amount of time stripping out and redoing the inventory system so it used array variables rather than single-item strings, because I had a list of twenty or so individual variables that might have several values and I was trying to write if statements and failing horribly because of the complexity. Not incidentally, I also learned quite a lot about Javascript array variables. And I learned that no matter how many bugs you think you’ve squashed, in a project this complex, there will always be at least one more. (Detritus has done more for my coding ability in two months than Codecademy managed in six.)

I learned about branching. Every time a narrative branches in a game like this, the path not taken by the player can, if you like, be seen as wasted work. If you want your players to see everything, you have to avoid branching too much, or branch only with descriptive elements. But the flip side is that then player choices don’t necessarily have much weight. I wanted Detritus to have weight in every decision, and it felt right to close off branches, to leave much more unread by the player than read, every time. It’s a game about loss, and that loss ought to be expressed mechanically, not just verbally; that’s why I wanted to use Twine to tell an interactive story, after all, rather than just writing something linear to express it. The game’s 27,000 words long, but the average playthrough will see less than a quarter of what’s written. There are easter eggs down some pathways, too, that mean much more because they aren’t signposted, and because they’re easy to leave behind.

Biggest and best thing about making Detritus, though, has been the wonderful feeling of making a solo creative project work, seeing it through from opening lines to existence in the wider world as an actual thing that people can genuinely play. It’s been too long since I did that, and without Twine and the community around it I probably still wouldn’t have managed. The democratisation of creative tools has meant an explosion in the numbers of people who can create and publish, in games and in fiction just as in other forms of publication. People with stories to tell or games to make can do so. Even if that story is a packing sim about loss and carrying your life in a suitcase. It is a wonderful thing.

Published by

Mary Hamilton

I'm a journalist-type tech-ish geek person, working in that interesting ambiguous place where reporting the news meets all sorts of peripheral skills. In my spare time I herd zombies, design games and write stuff.

2 thoughts on “Detritus: lessons learned from making my first Twine game”

  1. I just want to say that I know nothing whatsoever about gaming, coding or being technically very clever. But you have a way with words that makes everything sound very lovely and meaningful even when I understand so very little (in fact it possibly helps).

What do you think?