Writing Interactive Fiction With Twine is available in print!

Writing Interactive Fiction with Twine on the shelfI ventured out to a local Barnes & Noble yesterday, and was pleasantly surprised that it was not only there, but also given some prominence on the shelf by the staff.

I think the book production folks at Que did a great job with the print edition. After spending so much time looking at drafts in Word, it was nice to see it, y’know, actually given form with typography and layout.

I had also forgotten — honest! — about the foreword I had written for the book. So I can say that not only did I help with the editing, but my writing does appear in it, even though it’s but one page of 432.

I think by law I am required to link to where you can purchase it, in case you do not know how to exchange money for books, so go to it.

(I didn’t notice Mazes for Programmers next to it until after I had gotten home, but what a book title!)

I’ve cofounded Unmapped Path

I have been making games with Joel Haddock for six years now. I have to remind myself how long it’s been, because it’s just a fact to me. I have a lot of difficulty imagining otherwise.

We had always talked about building games, but it wasn’t until I found Flixel, which abstracted away all of the housekeeping and ceremony you’d normally need to get a game up and running, that we actually built them and released them to the world. There’s a symmetry there with my work on Twine, I think.

We invented a studio name for ourselves, Twofold Secret, after much hand-wringing. We built a web site for ourselves and probably argued over the page design more than any actual work we did on the games. We released five games, all of which I’m very proud of– even the early ones, with their warts. Alight landed a sponsorship on Newgrounds homepage. When Flash’s popularity began to wane, we moved into downloadable games with Sought and Camp Keepalive. We put on a gallery show that made the cover of the Baltimore Sun‘s companion tabloid b.

And then there was a space in our work. We tinkered with game concepts but never fell in love with one enough to fully follow through on it. We never gave up on the idea of building games — just, we weren’t sure what to build next. We had both changed.

It took some time to figure things out, but I think we have our bearings once again.

We’ve decided to change our focus to be more squarely on interactive narrative, and our name to Unmapped Path. Joel and I both have always thought of ourselves as writers, but our Twofold games belong to genres like strategy game and platformer. You can see our interests poke out of the dark clouds of Alight and the terminals of Sanctuary 17, but someone giving them a quick glance would surely think retro before they thought literary.

It’s time to let our writing play a larger role. We want to build games that engage more fully with storytelling, and we’re going to leverage our experience with Twine to do it. We’ve developed an in-house engine called Disbound (which, of course, has an etymology) that makes building polished experiences for mobile and desktop with Twine extremely easy.

The other reason why we’ve changed names is that we’re actively pursuing client work, and Twofold was more a garage band for us than a professional enterprise. Our first client project, Undo Othello, debuted in March. We built this for the Shakespeare Theater Company in nearby Washington DC, and it was a real pleasure working on it. I’ve always liked working in the nonprofit space, and especially the education space. I’m hopeful Undo Othello is just the beginning of our work there.

We’re also working with Andrew Schneider to bring his game Nocked! True Tales of Robin Hood to iOS using Disbound. You can get a taste of the storyline by playing the version Andrew entered into the Back Garden of this year’s Spring Thing interactive fiction festival. I can promise, though — the Spring Thing version is just a preview of what’s to come.

And there is a third project Joel and I are working on ourselves that I can’t tell you about yet. There have to be some secrets for us to keep, right? If you’d like to know when we do announce it, follow us on Twitter or sign up for our monthly newsletter. And — of course, if you have a project you’d like our help with, please drop us a line.

A second book about Twine!

I’m pleased to see that Writing Interactive Fiction With Twine, a book by Melissa Ford that I tech edited, is now available in e-book format! It will appear in print later this month, at which point I will gush with excitement all over again.

I’m excited both that this is the first book I’ve ever tech edited, and that it’s the second book I know about that is specifically about Twine. (There’s Rise of the Videogame Zinesters too, of course — but while it talks a lot about Twine, I think the ambitions of the book extend past Twine, to a larger creative movement.) That first book is Videogames for Humans, which Merritt Kopas herself gave me a copy of– pretty nifty.

What I really like about Writing Interactive Fiction With Twine is that it treats coding and writing as equal partners in the creative process, and devotes its time accordingly. I think that’s just right for a book about Twine, and for that matter, interactive fiction in general. I think it’s easy to fall into the trap of gee-whiz technical tricks without considering what story purposes they might serve. Melissa dodges that quite deftly.

(By the way, the book also devotes many chapters to a gentle introduction to Harlowe, the default story format in Twine 2 — so if you’re used to SugarCube but are curious what Harlowe’s all about, the book is a great way to try it.)

Tech editing was more intimidating than I expected. I hate errors in technical books and resolved to make sure Melissa’s copy was spot-on accurate, but after all was said and done, I remained paranoid I missed something. We’ll see!

Superluminal Vagrant Twin

I really liked it! You should try it out.

What I especially liked, and I think distinguishes it from other, shorter Pacian games I’ve played (and would also recommend — especially Castle of the Red Prince), is the sense of depth to the world. Where Red Prince feels allusive, SVT is expository. For example, there are some characters who exist only to point the player to other locations to visit, from a mechanical point of view. And yet, the few sentences they’re given often give a sense not only of the politics and culture of the world, but also of the characters themselves. It’s pretty masterful to be able to do so much with so few words.

It reminds me a little bit of how the exposition in A Dark Room is parceled out in bite-size morsels, though it doesn’t make as much sense in SVT. Shouldn’t the protagonist know at least most of their homeworlds? The “Visited Worlds” list only contains the one you’re standing on when you begin the game. But, this was the kind of quarrel I only thought of after I had finished — I was willing to accept the artifice while I played.

The only other criticism I have is that I felt the end arrived a little too abruptly. I had found one tool of what looked to be several that I’d need to reach the end, and then by pursuing a different thread, ended up bypassing the process completely. And I was actually looking forward to hunting for tools!

I was OK with the limited parser vocabulary. It felt accommodating rather than restrictive, the same way it did in Midnight. Swordfight. The act of typing felt unnecessary, though, because there are so few verbs, and there are no hidden objects (so far that I found, anyway). I’ve played some of Draculaland (warning: autoplays music), and it seems like this kind of verb-buttons-next-to-nouns interface would suit SVT well. But I also understand that the tooling to create those interfaces isn’t quite as mature as Inform. It struck me as a practical choice, to privilege narrative and mechanics over interface in development time.

(By the way, I named my spaceship The Zoombeast, in case you’re shopping for a spaceship for me and are wondering what to christen it. Another grace note in the game is when the moment you get to name your ship occurs– not right at the start, as is typical for roguelikes, but in the mid-game, after you’ve had time to build a mental picture of it through gameplay.)


In August 1986, for publication on ACEN, I began writing and designing the interface and programs for the hyperfictional narrative database, Uncle Roger. And in the process, I created an authoring system — Narrabase — which I have continued to develop for my work for 27 years.

From Judy Malloy’s artist statement for Uncle Buddy, a hypertext she created for the Apple ][. Imagine working on a piece of software for 27 years! Something to aspire to.

Miss Manhattan, or the anonymity of ubiquity

I’ve been a fan of the 99% Invisible podcast for a long time, but their recent Miss Manhattan episode really knocked it out of the park. I knew in the abstract sense that statuary is often based on real models, of course, but I had never really considered what it would feel like to look up at a thing made of marble, or bronze, or any other material that will last many more years than a single human lifespan, and see your own face. And in Audrey Munson’s case, at least, to be ubiquitous yet forgotten.

Some links on the history of gamebooks

So I got to present a session at MAGFest this past weekend! I enjoyed it a lot. If you’re not familiar with it, it’s a fan convention centering around video games but with a strong focus on music. (Hence the name — Music And Gaming.) That means chiptune performances like Chipzel (who I sadly missed this year), for example, but also performances with gameplay such Bit Brigade and Journey Live. I was lucky enough to see most of the debut performance of Journey Live, and was just floored by how good it was. If there’s any way at all for you to go to one of their performances, you ought to.

Anyway, I’ve been attending MAGFest for a number of years, but this was my first one presenting. I did a session on the history and predecessors of gamebooks, a subject that’s obviously dear to my heart. And, it appeared, a subject that also brought up fond memories for a number of attendees. Thanks to everyone who dropped in!

As I promised in the session, below are the links from my presentation:

Twine 2.0.11pre1

This post originally appeared on my Patreon.

It took longer than it should have, but we’re firmly on the road to 2.0.11. You can grab a copy of prerelease 1 here. This is a minor update, fixing a number of bugs (especially a couple bad ones affecting Linux users) as well as adding Finnish and German translations. If you notice a bug, please report it!

I’ll write a little bit about why there’s been a longer gap between this release than there typically has been, because I think it’s a useful cautionary tale. Over 2015, I was proud to hit a release about every month and a half. The slowdown was basically a case of pulling one thread in the codebase and all kinds of thing untangling.

I had some free time around the holidays, so I decided to try using a CSS preprocessor for the code, and also to try to improve the code structure. That is to say, to try to pay down some technical debt. What ended up happening was that using a preprocessor triggered a general rethink of the Twine UI, to try to make it more consistent, and improving the code structure led me down the road to major refactoring, which also implies major retesting. Both these things took up the time I had charted out in my head, and went well beyond. It was clear to me that getting this branch of the source tree (which I had named, with increasing dismay, refactor-2k15) in shape that it could be merged back into the main line of development would take a long time, much longer than I (and many other contributors to the code) was comfortable with.

So I’m taking a different tack now, prompted by a talk by Ryan Florence called “Don’t Refactor, React” that Aimee Knight was kind enough to point me to. It’s well worth a watch if you’re trying to grapple with the dizzying carousel that is JavaScript development these days. (No, this does not mean I’m rewriting Twine in React — though who knows what the future may bring, I guess? Right now I am finding I prefer Vue over React, for what it is worth, though this opinion is not informed by a lot of experience yet.)

The point of the talk being, instead of refactoring from all the way at the top, start simply, and at the lowest level. Succeed early, and use momentum to your advantage.

What this means in practice is that once 2.0.11 is out the door, I’m going to try to move over the changes from that ill-fated refactor-2k15 branch over in small, incremental steps. My hunch is that this will work a lot better. Here’s hoping!

I’ve attached a screenshot of the revised UI, by the way. As you can see, it’s not radically different — hopefully just refreshing. There’s a whole other post to be written about how I got there.

Screen Shot 2015-12-13 at 8.16.29 PM

Twine is free software

In a lot of ways, that’s all you need to know.

This week, I’ve been informed by folks in the Twine community of a couple developments: that Twine has been placed on Steam Greenlight by someone who is running a crowdfunding campaign for same, and that someone had set up a page on itch.io to sell binaries of Twine for $5. (itch.io has since taken this page down.)

Right upfront, I’ll state that nobody has previously communicated with me about any of these things, so you can consider them unauthorized by me — which I italicize to stress that I’m speaking for myself only.

But, besides that– is it legal to put Twine into an app store regardless of my own personal wishes, let alone charge money for it? I’m not a lawyer, obviously. But I believe the answer is yes, if that distribution complies with the GNU Public License v3 (or GPLv3), which is the license I chose for Twine 2. (I used GPLv2 for Twine 1.x.) In particular, sections 4, 5, and 6 describe the requirements for distribution in what I think is pretty plain language.

One nuance of the GPLv3 that you may not be aware of is that it allows for a fee to be charged for distributing the software — but there are two major requirements. First, the distribution must include source code or otherwise make it available to end users. Secondly, it requires that customers be also allowed to distribute the software themselves, for free or for cost. So, there’s no point in charging for a GPL-licensed application, since anyone who ponies up whatever cash is allowed to then give it away to the entire world for free.

Before I move on, I’ll also point out that works you create with Twine are not governed by the GPL. The story formats that your work is bound to — Harlowe, Sugarcube, and Snowman — have more permissive licenses that largely only require you to credit them appropriately.

That said, there’s something here that I especially don’t want to discourage, which is people asking for donations to expand Twine’s capabilities. It would be hypocritical to do otherwise, considering I’ve set up a Patreon to do exactly that. Again, the GPL places limitations on this. If you create a derivative version of Twine, it must also be released under the GPL — and ideally, you would contribute those changes to the main source repository. You are not permitted to take Twine, change it, and then offer it under a different license (in particular, a proprietary one).

Obviously, you should use the same judgment that is appropriate when evaluating any crowdfunding campaign. I don’t know the person running the crowdfunding campaign nor have I spoken with them, as I mentioned above, so I can’t really speak to its viability. You’ll have to draw your own conclusions.

I’ll close with why I haven’t put Twine in app stores like Steam, itch, the Mac App Store, and so on thus far. Right now, I have my hands full supporting mobile browsers and all three major desktop OSes — producing separate versions for the various stores, let alone supporting them, is too much for me to consider right now. Though that may change in the future– who knows?

Speaking of, I’m looking for someone to assist with managing the Linux version of Twine. There were a number of Linux-specific bugs that made it into 2.0.10 because we didn’t test on that platform as much as we did Windows and OS X. If you’re interested, please drop me a line.

Edited on 20 December 2015 to clarify that changes to Twine must remain under the GPL, as specified by the terms of the GPLv3.