I gave this talk on June 15, 2019, at the (hopefully first) Narrascope conference in Boston, Massachusetts. Some talks were recorded on video, but mine wasn’t, and I thought at least some of this information was worth sharing with the world at large. These written notes are, of course, far from my exact words, but they are roughly my recollection of what I said, at the very least.
This talk is mostly about the present state of Twine and what I think about when I think about its future, both short- and long-term. I’ll talk a little about its origins just to set the stage and provide some context, but the history of Twine is really a talk unto itself.
In other words– this is a Twine State of the Union. We have a tradition in the United States where every year our president gives a speech on the state of the country, and of course they always say that the state of the union has never been stronger. So either the United States has never had a bad year, or maybe some of our presidents lie to us.
So I have to say: the state of Twine has never been stronger.
This is a state of the Twine union, not the state of the Twine union. This is my own point of view on Twine, which is of course incomplete.
I’ll also do my best to keep to 45 minutes so that we have time to have a discussion about Twine. Believe it or not, I rarely get to talk to people who use Twine in person, and so this is a nice opportunity to do just that.
By way of introduction, Twine is a decade old this year, which is a kind of milestone, especially for software, which often has a short life.
That said, it exists in a broader context. Storyspace, the software that was used to create many hypertext works in the 90s, is now 32 years old. Judy Malloy, another early hypertext artist, has been working on her own system, Narrabase, since the 1980s. And Douglas Englebart’s “mother of all demos”, which was not where hypertext was invented but where it was introduced to a broader world, took place half a century ago now.
So, let’s talk briefly about Twine’s past.
I entered the IF world writing a few parser games, but I found that what I wanted to write didn’t mesh well with the conventions of that medium. This is nothing against parser as a medium, of course; it just wasn’t what I needed for then.
I found a funny little piece of software, TiddlyWiki, which was a web page you could download and then edit directly in your web browser. It fascinated me as a piece of software because I didn’t think a web page sitting on your computer could do that. We’d now call this a security hole. But it’s funny, how so many interesting things come out of security holes, out of things that weren’t intended to be possible.
Anway, I began writing hypertext stories with TiddlyWiki, though I don’t think I exactly thought of them as hypertext.
At the same time, the process of writing in TiddlyWiki was cumbersome for me at times. It was a little like designing a labyrinth while you were inside it–easy to get lost. So I came up with a simple markup language that I could use to create TiddlyWiki files using a text editor, and I called it Twee.
It didn’t take off really at all.
So—fast forwarding quite a bit–I created a GUI to create stories of course called Twine three years later.
Twine, too, didn’t take off– not at first.
It wasn’t until a community that I wasn’t even aware of at the time, the indie game community, adopted it, that it really took off. That too is a story in itself.
And fast forwarding quite a bit again, five years after the first release of Twine, we migrated it to a fully web-based version called Twine 2. I decided this needed to happen because at that point, tablets had just been introduced and I thought that they might become the main way we compute, and I didn’t want to deal with app stores or other things. I saw moving Twine to the web as a way to work around those limitations.
Which brings us to now…
I first want to talk about who uses Twine.
Twine 2.3.1 is not the most recent release --that happened Monday, five days before this presentation (which was June 10)-- but the second most recent release’s desktop app version has been downloaded around 25,000 times. That’s not 25,000 people; it just means that the software has been downloaded that many times. And this number doesn’t include people who use Twine on the web.
Breaking the desktop app downloads down by operating system, it roughly follows global statistics but with a larger Linux and Mac contingent.
On the web side, the official web site for Twine had about 50,000 people visit it in May.
And the link to work with Twine online has been clicked 40,000 times. That isn’t 40,000 people–that is 40,000 clicks—and it doesn’t include anyone who has bookmarked the web editor directly. We intentionally do not collect any analytics about what happens when people actually use the web version of Twine; it's completely private.
All these numbers can’t be directly compared, but what it does tell me is that the desktop app version is just as important as the web-based version, and they both seem to have dedicated audiences.
Another way to measure the size of the overall community is to look at the official Discord server, and the unofficial subreddit. Of course, these also are subsets of a much larger population.
Here we exit the part of the presentation based on actual evidence, and move into observations I’ve had online. Roughly speaking, there appear to be three major groups of people who use Twine.
A year ago I might have written game designers instead of creative professionals, but it seems that people use Twine to create more than just digital games. For these folks, Twine is a prototyping tool, to test out interactions or a narrative structure. It sometimes is a starting point, where what they create is added to to create a full experience. For example, the prologue to Firewatch began as a Twine game that the team created for internal use, to help flesh out the main character, and they liked it so much that it appears in the final game. It’s not Twine underneath in the actual game, I don’t think, however.
As I said, it’s more than just digital games being created with Twine– Charlie Brooker wrote the treatment for Bandersnatch using Twine, and Ryan North charted out a Choose Your Own Adventure flavored take on Romeo and Juliet with Twine that was published as a physical book.
The second group I see are educators, sometimes in game design programs, sometimes not. In game design programs, Twine is often used as a prototyping tool, or a way to introduce game design to students, in the same way that introductory courses have students designing board games. Outside of game design programs, Twine is sometimes used by teachers themselves, who design interactive activities for students to complete or experience, but more often it’s the students who are creating things with Twine, sometimes as a way to engage with computer science topics, sometimes as a way for them to demonstrate their knowledge of a topic—instead of writing a book report, they might create an interactive activity. When students are told they get to create a game, they often get very excited.
This is one of my favorite pictures related to Twine. It’s a classroom in India where the children are being taught to build a story with Twine. I like it not only because it reminds me of how far Twine’s reach has been, but also because Twine may be one of the first experiences that a child has with computing. It's a big responsibility.
The third group I see of Twine users are indie creators, who for me are the hardest to keep tabs on—they often live and communicate in very different spaces than me online and in real life. They’re cool and I’m not particularly. At the same time, often the most interesting and groundbreaking things are created by folks in this group.
It really runs the gamut. On the left is a screenshot of the itch.io digital marketplace where I did a search for Twine games, and on the right is an exhibit listing for the Whitney Biennial two years ago, where some of Porpentine’s work was exhibited. It says something to me that Twine is appearing in spaces like art galleries, that it's being recognized in spheres outside of digital games.
Moving from the people using Twine to the people developing it– what are we working on right now?
Firstly, Twine has been adopted by the IFTF. What this means is not that the technical direction that Twine goes in is determined by IFTF. Instead, it means that IFTF provides technology and funding to Twine and its surrounding community. One example is, the main official site for Twine is now hosted by IFTF. Another concrete thing that has occurred due to IFTF’s involvement is that we now have monthly archive backups of Philome.la, an immensely popular free site for hosting Twine stories that has tens of thousands of them hosted there. IFTF’s archives will ensure that these stories will be preserved for a long time.
IFTF has formed a Twine committee to manage and guide these efforts–I’ll talk about Leon and Thomas a bit later in this presentation. But by way of introduction of these members—
Dan Cox has created hours of tutorial videos of how to use Twine. When people ask me what the best way to learn Twine is, I point them to Dan’s videos.
M.C. DeMarco has been a mainstay of the community since nearly the beginning. She’s created several story formats for Twine, too.
David ‘Greyelf’ Tarrant is also a venerable part of the Twine community. If you’ve ever asked a question on Twine’s Q&A web site, he probably answered it. The site assigns points to people who provide answers marked as correct by the user posting the question–David’s score on this site is several times larger than my own.
Finally, Colin Marc is the current maintainer of Philomela.
Two recent things that the committee has worked on: first, the Twine Cookbook, which is a shameless ripoff of Inform’s recipe book. It covers topics that aren’t easily handled in reference documentation. For example, a question that gets asked a lot is how to build an RPG battle system inside of Twine. This isn’t a great fit for reference documentation, since it involves a couple different topics, but it is a good fit for the cookbook. The cookbook is now published at regular intervals.
Secondly, the committe is working on a formal spec for Twee, the text-based markup for Twine. I didn’t write one back when I first created Twee, and so there have been several compilers that all handle the basics correctly, but we haven’t so far been able to agree on a common way to extend what I originally came up with, which of course could be improved. The spec is an effort to get everyone on the same page. Right now it is open for public comment, and likely later this summer we’ll finalize it.
Outside of the committee, two major recent efforts have been made related to story formats. First, I’ve been spending a lot of time on Chapbook, a new story format. People always ask– we already have three built-in formats, why do we need another one? A lot of Chapbook came out of my own experience teaching Twine. I found that in order to show people how to do certain things, especially related to multimedia, I had to bring in heavier-weight concepts than felt necessary. It also stemmed from my own experience writing Twine– I write longhand a lot, on paper. And so I adopted some of the shorthands I found intuitive on paper, too.
Here’s a sample of Chapbook code, to give you an idea of what it looks like. Chapbook is currently on a beta 1 release; the goal is to release 1.0 in July.
Leon has also recently released version 3.0 of Harlowe, the default story format of Twine 2. I have this link to the release notes because there is no one major feature that has been added, in my opinion—it’s been a lot of small ones that add up in terms of the authoring experience.
So who is doing all this work?
I really wanted to include this section because one of the things I really hate is people assuming that Twine is developed by a single mysterious entity. ‘They’ changed my favorite feature, ‘they’ broke Twine. In reality, of course we are individual people. We disagree with each other, and we’re imperfect. But we’re people, not a ‘they.'
People often ask what the size of the “core” Twine team is, and it’s hard to define what that means. There are a lot of people who contribute to Twine through a single pull request, for example. For the purposes of today, I’ll talk about myself, and the two other people who work on the default story formats of Twine, the things that take over once you play your story in a browser. Neither of them unfortunately could be here today, but I asked them what they would like to share about themselves with the world.
Leon created Harlowe, which is the default story format for Twine. If you’ve casually created a quick story with Twine on the web site, you probably have used his work.
Leon lives in Australia, builds web and twine games, and is very interested in programming language design—which is very evident in Harlowe–and preservation of digital games. As part of that preservation effort, he’s ported several games to the Mac that were originally created in GameMaker, which is Windows-only– for example, the original Spelunky.
Thomas Michael Edwards created and maintains SugarCube, a very popular story format that has been around for quite a long time too. He’s also the creator of Tweego, a command-line compiler for Twee.
He’s a Lousiana-based network sysadmin and programmer who has done a fair bit of web development too.
Finally, myself.
I live in Baltimore and work fulltime as a web developer. I’m on the board of the Interactive Fiction Foundation and am also a cofounder of a small indie game studio called Unmapped Path that creates Twine-based games. We’re going to be releasing our first game this year (we showed it in Narrascope’s demo room). And just this past spring, I began teaching at MICA’s game design program.
So besides trying to humanize the team behind Twine a little bit, the other point I want to make is that Twine is not a fulltime job for any of us. We wear a lot of different hats, and Twine is just one of them.
Which makes for a good jumping-off point for talking about the economics of open source. People always get a bit nervous when you bring up money, so I want to stress that this isn’t intended as a guilt trip. I’m not going to pass around a collection plate.
When I set up my Patreon, one of the hardest thing was trying to come up with a dollar amount that, if I was able to bring in that much, I would go fulltime on Twine. I came up with this $2,500 figure that I’ll talk about in a moment, but you can see, I haven’t really come even close to meeting that number. It might sound a bit high…
… but the thing about that $2,500 number is, if you assume I do a Twine-related release every month, that equates to an annual salary that’s a hair above minimum wage in the state in which I live, once you take out Patreon fees and self-employment tax.
But the other thing about that number is, I’m at $774 a release…
… but that is actually really good by Patreon standards. This chart is from last year, so bear that in mind, but the amount of money I’m currently raising is currently right at the start of that long tail, the last red block that equates to below minimum wage.
The point of talking about all this is not to make you feel guilty for not giving money to me, if you haven’t. Really!
The point is, is it possible to make developing Twine sustainable…
… not just for me, but for everyone working on it? Because Twine is not just me. There are so many other people who make it happen.
Which brings us to the stage in this talk where I ask questions that I don’t know the answer to.
But before I jump into those, I want to point out that the Twine development roadmap is on GitHub. If you go into the Projects tab, you can see what issues are going into the next release, and what progress has been made on them. If you look right now, there’s not that much to see, though– we just did a release and I need to lay out what’s coming next.
That said, there are some things not on that roadmap.
First, Twine needs to become a signed app. Right now if you run the desktop app, especially on Windows, your computer will warn you that it’ll crash your computer, steal your data, and eat your children. The way around that is to code-sign the app. I don’t exactly know how this works yet on Windows, but on Macs it means paying Apple $100 a year to become a recognized developer.
Fortunately, this is an easy problem to solve. IFTF will be able to help with this.
This doesn’t mean necessarily that Twine will appear in any app stores. I don’t know how much effort is involved with that yet.
Secondly, Twine will hopefully soon gain a package manager. The problem that this solves is, if you want to extend Harlowe or SugarCube or anything else really, right now the most common way to do that is by copying and pasting code from someone else. This is problematic on a lot of different levels– a package manager allows things to work a lot more seamlessly, and in a more trustworthy way.
Finally, something I have wanted to add to Twine for a long time but haven’t been able to get to yet is adding collaborative features to Twine. Right now, collaborating with Twine is annoying. You have to trade files back and forth, and heaven help you if you end up making changes to an old file and have to figure out how to merge those changes back in. It ought to work more like Google Docs. You should be able to edit a story at the same time as multiple other people.
Adding this not only takes development time, but it also may end up requiring support in terms of a back end server to manage this collaboration.
I’ll close with some more questions I don’t know the answer to that I alluded to before.
First, a small thing. Our Q&A site is full of spam and it has been for quite a long time. We’ve tried different technical approaches to solving the problem but none have been successful. What do we do with this site? It serves a real need in our user population, but it sucks up headspace from people who could otherwise be doing more interesting and valuable work.
Secondly, what do we want to do about the source code of Twine? It’s been suggested that its copyright should be owned by an organization, not a collection of people. But in order to make that happen, we have to track down all the people who have already contributed to Twine and get their permission. Everyone involved has to agree or it won’t work. We’d also need to create a CLA–a contributor’s license agreement.
The thing I wonder about is, if we go to all this effort, will it be worth it when all is said and done?
(This wasn’t a slide I showed in the talk, because it was a thought that crystallized the morning of the talk. I said this at the talk, but didn’t have a slide to match it.)
And finally, how do we make decisions that reflect the entire Twine community? A lot of development discussion happens on GitHub, but so many of our users don’t use GitHub and maybe don’t even know what GitHub is. How do we make decisions that don’t ignore their needs?
(Here’s where my talk ended, and we indeed had some discussion with the audience. I won’t try to capture that here, but I will add that if you too have thoughts about these questions, feel free to reach out at the info listed above.)