Chris Klimas

(an, not the) Ursula LeGuin documentary airs on PBS this Friday. I can’t wait to watch. Count me as one of those kids who fell in love with the Earthsea books but came back to her other works as I grew older. She’s one of my heroes.

This was originally posted to my Patreon.

The Chapbook web site has been updated with URLs for beta 2. Note– plural URLs. There are now two flavors of Chapbook: the regular one, and a stripped-down micro build that removes all test-related code, that’s about 20% smaller.

I’ve also opened Chapbook’s issue tracker, with some trepidation, to the world at large. Time to find out what everyone thinks, I guess!

This should be the final version before final 1.0.0.

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.)

This was originally posted to my Patreon.

Get it here.

This should resolve all the issues I’m aware of with beta 1– related to Windows saving files, and all platforms having trouble with playing or testing stories right after you’ve created them. Please remember that this is still a beta, so make sure to keep copies of your work before using this!

The other announcement for today is that I have transferred ownership of Snowman, the Twine story format I created, to Dan Cox. I put out a call for interested people back in November—I want to focus on developing Chapbook—and Dan was gracious enough to volunteer. Dan is a steadfast contributor to the Twine community and also serves on the IFTF’s Twine commitee that I chair.

I’m excited to see what Dan will do as maintainer, and hope you are too.

This post originally appeared on my Patreon.

Hooray! I’m very excited to have something for people to try out, but mind the warnings about data loss. Expect some bumps in the road– I noticed a new bug just this morning as I was doing the release.

Below are the release notes I posted to GitHub, where you can also download the beta.

New Features

• Now uses Electron as its desktop app shell instead of NW.js. The goal of this change is to increase stability of the desktop apps. It also should allow for a more responsive interface, as certain tasks (like saving changes) will happen in the background as opposed to locking up the main UI. Because this change involved considerable reworking of the saving and loading process, it is possible that this beta may contain bugs that would affect saved stories. Before using this beta, please take a backup of your stories, and save backups often.
• Harlowe 3.0 is now included as a story format choice.
• Bahasa Malaysian, Chinese, and Russian localizations have been added.

Bug Fixes

• Dragging passages should be more reliable, as the algorithm for avoiding overlaps has been improved.
• If you have a test or playable version of a story open in another browser tab or window and choose to test or play it again, the tab or window will refresh (it previously only showed the tab or window again).

 

This post originally appeared on my Patreon.

This is a quick fix to resolve a bug that can cause data loss– data loss so bad that I’ve yanked the 0.0.1 release. One feature I added to Chapbook is, if a story runs into an error, it offers to the player two choices:

• Go back to the previous passage, hopefully so that a different route will allow the player to continue
• Do a “hard restart,” which clears all saved progress and restarts the story

The problem with the hard restart in 0.0.1 is that it cleared the entire local storage for the entire site that the page was running on, which could do all kinds of nasty things, including stories saved to the web version of Twine. Eek!

The new URL to use is: https://klembot.github.io/chapbook/use/0.0.2/format.js

This post originally appeared on my Patreon.

I’ve been quiet for some time now, because I’ve been working on something new that I’m excited to share. In fact, I have a lot of news, so I’ll summarize everything first, then go point by point.

• I have a new story format, Chapbook, that is in prerelease state.
• I’m going to involve Patreon backers in the Chapbook development process, and have added reward tiers and a goal.
• I am getting more transparent about my Twine development process.
• I am seeking someone (ideally, some people) to take over ownership of the Snowman story format.

Told you it was a lot! Let’s start at the top.

I have a new story format, Chapbook, that is in prerelease state.

This is probably the most exciting bit of news to most of you reading this. I am pleased to announce Chapbook, which is a story format whose origins began in two separate, quite different projects: writing up a guide to Snowman, the story format I created for Twine 2, and collaborating on a Twine game.

My Snowman guide idea was in theory noble: to teach people the rudiments of front-end development–HTML, JavaScript, and CSS–on the way to building stories in Snowman. I still think it would be an interesting book to write, but I quickly realized as I began to outline it: this is way too much to learn just to write a story with some links.

At the same time, I had been working with my creative partner Joel on a game we were creating with Snowman– hopefully more about that soon. After much back-and-forth, the workflow we decided on was that he would pseudocode out the functionality he needed in each passage and I’d actually write the JavaScript to make it happen. As I was typing away, I thought: why can’t we make the pseudocode actual code?

I’ll let the rest of the Chapbook guideexplain where I went to from there. I consider Chapbook to be in a state that you can at least build small stories with it. I have, for example, built out a Cloak of Darkness example with Chapbook that you can play around. But there is a lot left to be done, and many design decisions to make, which brings us to…

I’m going to involve Patreon backers in the Chapbook development process, and have added reward tiers and a goal.

I want to try an experiment with Chapbook. Right now, I am not accepting bug reports, feature requests, or pull requests on Chapbook from the general public. When it reaches version 1.0, I will. Before then, I want to allow Patreon backers to collaborate with me on the shape it takes.

What this means in practice is that I will begin postly weekly patron-only updates on Chapbook and Twine development, and I’ll use these posts as a way to gather feedback and suggestions as I work on Chapbook. If you pledge $5 or more per release, you’ll receive access to these posts, and have the ability to share your feedback there. I can’t promise that I’ll incorporate every idea, of course, but I will promise that I will read everything and do my best to respond in the comment thread.

If you pledge $10 or more per release, I’ll also add your name to the Patron page of the Chapbook guide, and if you pledge $20 or more, I’ll also give you access to a monthly one-hour livestream. The livestream will be an experiment! I’d like to use the stream as a chance to talk about what I’m working on, talk about IF, and answer questions from patrons. I’ll even do my best to give advice on building stories with Twine! I really mean that it will be an experiment, because I’ve never tried anything like this before.

Just as a reminder, my Patreon is based on releases, but I only charge patrons at most once a month. If I don’t do any work on Twine or Chapbook, I don’t charge patrons. And although I am building Patreon into my Chapbook development process, you can use Chapbook right now without having to be a Patreon backer, and you always will be able to.

On a final Patreon note, I’ve added a goal: the amount of money pledged I’d need in order to work on Twine fulltime. The number I’ve come up with is also a bit experimental, to be honest. It represents how much I think it would take for my Patreon to become a primary source of income, though not my only one. I’ve been doing a lot of back-of-the-envelope math about my living expenses, and so in a lot of ways the goal is also a back-of-the-envelope number.

But… even so, reaching that goal would be a life-changing moment for me. I hope that doesn’t sound too overdramatic, but I mean it. I love working on Twine and everything surrounding it, and I constantly wish that I had more time to do so. Reaching this goal would allow me to reorder my working time to better reflect what I want to do. And–if you want to be a bit selfish about it, it’d mean more regular Twine updates.

Which brings us to…

I am getting more transparent about my Twine development process.

If you pop over to the Twine source code repositoryand click on the Projects tab, you’ll see that I’ve laid out the roadmap for the next release of Twine, which will be 2.3.0. Right now everything is sitting in the To Do column; as I work on things, I’ll move them forward to In Progress, and finally Done. This way, everyone can get a sense of what’s on deck for the next version, and how close we are to a release.

This is just the beginning. I think as I get more experience with GitHub projects, I’m likely to add multiple projects, so that the roadmap goes further out than just the next release.

Finally, a slightly sad note.

I am seeking someone (ideally, some people) to take over ownership of the Snowman story format.

I know I can’t maintain two story formats, so I am looking for people to take up the mantle of ownership of the Snowman format. If you’re interested in this, please drop me a line. Snowman as-is will remain an option for use in Twine, but I don’t have the time to devote to it right now.

Let’s start by turning some subtext into text: I am trying out gradually moving away from Twitter in favor of this blog. Lots of reasons why. Twitter’s got issues, to say the least, but I also like writing longer posts. I like the quiet of working on something for a while, of typing into a rectangle that fills my screen instead of a one guiding me towards writing three sentences, maybe, at most.

I’m also going to try bundling up links into single posts, since a lot of smart people to do that, too.

• Emily Short blogs about her experience taking a masterclass in set design with Punchdrunk, the Sleep No More people. Her notes and reflections are thorough enough that although I’m sure they’re no replacement for the class, I found myself thinking quite a few thoughts in response.
• Eve is an abandoned programming platform, but I found so much I agreed with in its goals and orientation. I am tired of editor color themes that turn comments dim and code bright and citrusy, as if comments are meant to be jotted in haste and henceforth ignored.
• I’ve been to the FedEx office mentioned in this history of Nazism in Baltimore (may you one day rise from your grave, City Paper).