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.

Detritus: a Twine game

A couple of months ago, mid-move, I started a new project – a Twine game/interactive fiction thing called Detritus. I think it’s finished enough to share with the world.

It was meant to be quite a small experiment to see if I could teach myself the medium as well as using it to express something that’s almost impossible to express through non-interactive media. It got a bit more ambitious than that, I think mostly because I had no idea what I was doing or how tricky some of it was technically. At some point soon, when I’m a little bit less close to it and it’s had some air, I’ll blog about making it.

Any bug reports or feedback, please let me know. You can play it by clicking here: it should have sound running in some parts.