Unraveling Twine—Using Twine to Tell Stories in a Different Way: Part 1, Getting Started

This is the first entry in what I hope is a multi-part series exploring my experience making games with Twine. I’m not sure how long it will be, but hopefully at least two parts or this article has a pretty crappy title. I’m documenting things mostly because I find the process interesting and, well, also because I’m a writer (so it kinda comes a bit naturally). However, if I can at all demystify the game making process, and perhaps show folks it’s more accessible than they think, then that would be awesome too.

And You May Ask Yourself, “Well, How Did I Get Here?”

I’ve been in the video game industry for nearly a decade. I started out providing support for games, before quickly moving on to writing about them. Currently, most of my time in gaming has been spent as a technical writer.

Despite being in the industry for a while, I still wouldn’t say that I “make games.” Sure, I help people make games. I’ve worked with some incredibly talented people who I feel are much more deserving of saying they had a hand in making the game. So despite having my name appear in the credits of a few games, I still feel like I’m standing on the shoulders of giants. Helping others make games, in whatever small way I can, still feels like I’m getting away with some great trick.

All that said, I still find the process of creating games fascinating. In fact, the longer I’m in the industry the more I feel like I’m just getting started to understand how the sausage gets made. From designing systems, engineering tools, rigorously squashing bugs, and writing code. To unblocking folks, weaving a story out of nothing, and championing to make a game more accessible. To say it can be a complicated process would be an understatement—so much so I often wonder how any games get made.

This fascination I think in part is what drove me to the industry. I’m often shocked that I was able to leverage my general tech support knowledge to get hired in an industry that I would still struggle to give advice on how to enter effectively. In my free time I’ve read books on game design, from the thought-provoking Reality is Broken to the illuminating The Art of Game Design. I’ve even tried my had at some pen-and-paper prototypes. However, as life has gotten busier it’s been more difficult for me to prioritize tinkering with games. Now, with a little more time on my hands, and a little more skill and confidence as a writer, it felt like a good time to take another crack at it.

Where to Even Start?

I recently had an idea for a video game and asked some former colleagues on what engine would be best to start with. I’ve worked a bit with the Unreal Engine, but it seemed like overkill for the mostly text-based idea that I had.

A few suggestions were tossed around, and among them Unity seemed like a frontrunner. So I downloaded it, played with it for about five minutes, and promptly declared it too hard before returning to the drawing board. (I was once again reminded how difficult making games can be, and that it’s not something I can likely conquer in an afternoon.) Humbled, I returned to the list of suggestions to see what else my hivemind of peers had for me. One other suggestion stood out among the rest, Twine.

As their website proudly states at the top, “Twine is an open-source tool for telling interactive, nonlinear stories.” It’s free (perfect), focuses on writing (I can write), and it’s easy to use (now you’re speaking my language). While I had some initial misgivings about if using Twine to craft a story was really considered making games, I quickly silenced those voices so I could embrace some creative energies I hadn’t felt in years. (Plus, Zork‘s a game that’s entirely text based. So shut up doubting voices in my head.)

Time to Make My Own Sausage! (That Sounded Better in My Head)

So there it was. I was going to create a ~~story~~ game using Twine. I went to their site, kicked off the download, and reflected on what my game might be about. In addition to being a mild-mannered technical writer, I sometimes wear my underwear on the outside and masquerade as a creative writer. Usually this amounts to nothing more than cryptic, confusing, or concerning sentence fragments saved to my phone’s Notes app. Sometimes, I’m able to tease a little more from an idea.

Years ago I read the poem Stopping by Woods on a Snowy Evening by Robert Frost. Like all poems, interpretations of it’s meaning can vary. However, like with all poems it’s ultimately up to the reader to decide what it means to them and how they connect with it. I love the snow. I especially love the stillness and peace that are found standing outside while it snows at nighttime. But the stillness of those nightly, winter snowfalls are not always without other feelings. I mean, how long do you think you could stand out in the snow, in winter, at night, with your eyes closed, without feeling (or at least imaging feeling) something watching you? Winter is a season of stillness but also of lurking dangers. Of watchful wolves and patient branches ready to fall on unsuspecting passersby (often called “Widowmakers”). It was these feelings, the duality of danger and peace, that I wanted to focus on with my game.

With Twine freshly installed, and the seed of an idea taking root in my grey matter, I was ready to get started. Twine, at its simplest, can be summarized as such:

Start a new project.
Create individual blocks of text called Passages.
Connect those passages using Links.
Repeat steps 2-3 until satisfied.

The more I learn about Twine the more I realize it can do more than that—there are some really impressive projects out there made using Twine—but at its simplest that’s it.

So I got to work. I’d write a little bit, figure out the branching paths I’d want to offer the player, write those passages, and then link everything together. As the story progressed I wanted to focus a bit more on fall (the current season outside my window) than winter. I also wanted to focus a little more on change and how we react to it.

As I encountered problems (ex. linking to an external URL) I’d take the time to research that problem. What I couldn’t find in Twine’s documentation I could usually find with a quick Google search.

I hammered on this idea on and off for the better part of a day. I’d write a little, get bored or distracted, and then some back to it and work a bit more. I’d go back and clean things up, rewrite some passages, delete others, and export the entire thing for a quick spellcheck (the version of Twine I was using didn’t have an integrated spell-checker).

Around noon I was pretty impressed with my progress. I’d written some stuff I found neat. Gave the player a few “bad” endings, and learned a ton about Twine. I had a rough idea of what I wanted the “good” ending to look like—but even then it felt like the narrative of the game was bit more complicated than just the binary of good/bad. I decided to wrap things up and jot down the “final” ending. While it felt abrupt, and I immediately knew I’d want to come back and expand that section later, I could say for now that this first version was done. I sat back, expanded Twine to a wider view, and had something like this:

SPOLIERS IF YOU HAVEN’T PLAYED MY GAME YET! Click the arrow below to Expand.

It wasn’t perfect, but I’d created something. And damn did that feel good.

“Once a Technical Writer…Maybe Not Always a Technical Writer But for Now Yes Still Very Much a Technical Writer.”

Before, during and after making my game I crafted some supporting documentation. I created a folder in my Google Drive to collect these items as I went.

I knew at the very least I’d want a sort of planning document. Something to collect my thoughts and attempt to keep my vision consistent, if not always crystal clear. I ended up with this, and made a template version to use for future projects.

While using Twine, I soon found that it did not have an integrated spelling/grammar checker. Looking online it seemed like the simplest solution was to export the project as text and import it to a word process. I did that, using Google Docs, and kept that version in my Google Drive as a sort of text backup. On that note, I figured it was also good to have a proper backup. I exported my project properly and tossed that in my Google Drive as well.

Lastly, I wanted to keep track of what I’d done, how much time I was spending on this project, and what were some things I wanted to do next. I created a spreadsheet with tabs for tracking work and pending to-do items—it’s no Jira, but hey, it works.

I guess lastly-lastly I then wrote this article. If you’d made it this far I genuinely want to thank you for your time and interest. While it was honestly fun to make this game, and not entirely horrible writing this article, it means a lot that others would take the time to hear me out. I’m already thinking about how to improve my game and what projects I might want to tackle next. I hope to provide an update on those efforts soon. For now, I think I’ll take a little break with a walk through the woods.

Download Game

Check out A Path, Dark and Deep on itch.io.

Contact

Want to chat? I’d love to! Reach out via my contact form or hit me up directly on LinkedIn.

Matt Watson's Content Portfolio