Twine 2.0.9pre3

This post originally appeared on my Patreon.

This is getting serious.

On the one hand, it’s frustrating being so close to a release but still discovering last-minute problems. On the other, it’s really good to catch these bugs before they reach the world at large. On the third, I’m itching to dig into more substantive changes.

So let’s hope this is the last prerelease. Downloads, as before, are on Bitbucket.

Hey, it’s Twine 2.0.9pre2

This post originally appeared on my Patreon.

This isn’t much different from pre1 — that’s kind of the point! I’m hoping that this may be the actual release. This fixes a pretty bad bug with Windows 10, and also resolves a persistently annoying bug where dragging multiple passages would cause one or more to pop into odd positions. (This was interesting but aggravating to diagnose — what was going on was, instead of the passages being pushed off into space, they were instead snapping back to their original position.)

You can try out this version on the Bitbucket downloads page. Again, since this isn’t an official release, I’m not linking it from the main web site yet.

Twine 2.0.9pre1 is available

This post originally appeared on my Patreon.

It took longer than I would have liked, but Twine 2.0.9pre1 is now available for download. As the “pre” implies, this is not a full release and isn’t linked from the Twine home page– this instead a chance for people who are interested in testing to help catch any last-minute bugs before a real release goes out.

This is a change in the release process, for two reasons mainly:

  • Twine 2.0.7 made it out the door with a bad bug that caused real issues in the app versions. It was quickly recognized and I was able to rush 2.0.8 to get that addressed, but it was a little embarassing that something so basic made it into a release, and it was way more hassle than it should have been.
  • There have been major code changes, as well as changes in how I set up tests, that make me want to be extra careful before loosing this on the world.

In order to give this version a try, you’ll need to take a trip to the Bitbucket project page and choose the appropriate file. is just the web version zipped for local use; you probably want one of the larger versions that are marked with a platform name. (If you are on Windows, try this page for instructions on whether you want the 32-bit or 64-bit version.)

Here are the changes you’ll notice while working with Twine:

  • We have a whole bunch more localizations! This version adds Danish, French, Dutch, Brazilian Portuguese, and Russian.
  • Corrects a bug where you might have seen gray space around your story map after zooming in or out.
  • If you have a quick search highlighting passages, it will now update properly after changing a passage.
  • Indentation now works more consistently in the passage editor. (It used to always use spaces, even if you had hit the tab key previously.)
  • It’s now easier for users on the same computer on OS X to use the same Twine application. (Some people ran into permissions problems.)
  • Corrects a problem where the desktop apps would complain incorrectly about the size of your story.
  • A display glitch where you’d sometimes see two scroll bars in the passage editor has been fixed.
  • Global variables no longer leak into test versions of stories. This you probably only noticed if you are a web developer kind of person — what would happen is that certain libraries, like Underscore, would be available in test versions of stories but not the published ones.

Under the hood, the changes are bigger.

  • We now use Browserify to break up the code into more manageable modules.
  • The Selenium IDE tests have been migrated to JavaScript, and make use of the Mocha test framework, so they’re easier to run.
  • Switched from jslint to eslint.
  • Switched from YUIDoc to JSDoc 3.
  • Returned to Grunt for the build process after a flirtation with Gulp.

Those are pretty big changes, and I’ll probably devote some words to why I made some of those decisions in the future. In the meantime, if you have general feedback on this version, please take a trip over to the Twine forums! If you notice a bug, please go ahead and report it at Bitbucket.

Passing the test

This post originally appeared on my Patreon.

After what seemed like an eternity, I’ve converted the Twine 2 test suite to a pure JS-driven one… and more interestingly, the refactor into Browserify modules passes those tests. That gives me confidence that we can merge this branch into the main development branch, or trunk. We’ve made significant progress toward 2.0.9.

(My girlfriend asked: “Does this mean Twine is better now?” My war-weary reply: “It means it hasn’t gotten any worse.”)

Some quick lessons I’ve learned along the way:

  • Testing is still crucial.
  • Tests are still painstaking to write.
  • Moving from Selenium IDE-based tests to pure JS did not speed up the tests, but that’s mainly because each test now sets up an entirely new browser session.
  • You want your tests to run in separate browser sessions, because otherwise they can trample all over each other.
  • There’s a Selenium adaptor for PhantomJS, a platform specifically designed for automation, that should speed up the tests. But if I try it right now, some tests fail, probably because I’m not inserting enough “wait until this element exists” checks — it’s going too fast.
  • You can learn something by reading API documentation alone, but you’re not going to enjoy it.

Near-term goals for Twine 2

This post originally appeared on my Patreon.

I feel like we’re at the point where Twine 2, in its initial form, is pretty solid. The releases since then have all been what you’d call patch versions in the Semantic Versioning universe — hence we’re are 2.0.8, not 2.8. So once 2.0.9 is out the door, the question is: where to next?

We certainly have a ton of feature enhancements to consider. Right now I see a couple major things that need addressing:

  • We have no nice way for people to include multimedia in Twine stories. You can do it by pasting in Base64-encoded data into your passages, but this is a horrible user experience. I think about WordPress as an aspiration goal for the UI for this, but I’m curious if there are other models people would suggest looking at.
  • We need better ways for story formats to augment Twine so that it can better understand links. For example. It would be nice if a passage whose macros reference another one had a line between them in the story map. I have a spec for how to do this in draft form, which also includes other kinds of hooks for story formats. This doesn’t have a huge benefit to users right away, but it will make life a lot better for story format authors.
  • We need a better way to manage story map complexity. I’ve toyed with a lot of different ways to slice up a Twine story — for example, splitting it out into tabs that you can swap between (though I’m not overly fond of that approach, because it’s not spatial in the same way that the rest of Twine is). I feel like prototypes will be needed in order to decide what the best course of action will be.
  • I want to add support for locales that use right-to-left text.
  • We haven’t looked into how accessible Twine is at all yet, which is a woeful omission.

The interesting part to me will be making a decision as to what to prioritize. I’m not sure there is a wrong answer here — more a question of what will benefit the largest part of the user population.


What’s coming in Twine 2.0.9?

This post originally appeared on my Patreon.

Twine 2.0.9 is going to be a maintenance-oriented release. We have three new languages that have already landed on the main development sourcebase: French, Dutch, and Brazilian Portuguese. There’s also a pull request for Russian that I’m excited about getting landed. I think there’s a sizeable interactive fiction community that speaks Russian, so it’ll be cool to give them something that works in their native language.

The other big change I want to land is totally under the covers. After talking with some fellow developers at the CharmCityJS meetup and getting advice on the workflow I’ve set up for myself, I’ve been working on refactoring the code structure a bit so that we use Browserify to split the code up into more manageable modules. If I do this right, regular users won’t see any difference, but it will be way easier to work on the code. This not only makes my life easier, but will also make it easier for other developers to contribute to the other project. As of August, the work on this end is pretty much done, but I am waiting on the next part to land those changes…

… which is that I’m overhauling the automated tests for Twine. Up until now, I’d been using Selenium IDE to exercise Twine before release. It’s a Firefox plugin that automates browser actions and verifies they have the result you’d expect. Working with Selenium IDE has always been OK at best. I could never get a few tests to work predictably, so every time I did a release, I had to manually step through a few to make sure things would work correctly. This kind of friction always annoyed me, but I put up with it because it was the best way I knew how to do it.

So, also at the suggestion of fellow CharmCityJS’ers, I’ve been working on moving the Selenium tests out of the IDE and into the build process I’ve been using, Gulp. This has the advantage of being more convenient to run — a single command instead of having to navigate a GUI — but also promises more reliability. We shall see. The JavaScript bindings for Selenium are pretty full-featured, but it’s taking me some time to translate the IDE tests into JS because the best documentation I’ve been able to find is the API docs. It is a bit like trying to learn a language by skimming through a dictionary. Suggestions welcome!

My theory is that I’ll use the revised browser tests to validate the code re-organization. A major refactor is always a little perilous. Perhaps your code was ugly, but it had been working right for several releases. The automated tests are a way to better guarantee that.

That said, I’m still planning to do a prerelease test version to the world at large to catch anything that slips through the cracks. This release has been a bit slower to get out the door than others this year, mainly because I’m doing a lot of learning along the way. That said, I’m shooting for mid-September.

Twine 2, now a real(?) app

The release notes for Twine 2.0.4 are relatively brief. Partly this is because I haven’t had as much time in the past few months to work on Twine as I had earlier in the year, but it’s also because a lot of that work focused on a single bullet point there: “Added experimental native app builds.”

There really ought to be a full-fledged README to go with these builds, but in lieu of that, here are some notes on what’s going on.

Continue reading Twine 2, now a real(?) app

Helping at CoderDojoDC

Last weekend, I was invited to help with a session at CoderDojoDC that focused on Twine. CoderDojoDC is more-or-less the modern equivalent of the computer club I went to after school days in elementary school — only instead of pirating Apple II games and messing around with AppleWorks and Logo, kids these days are learning Python and messing around with robotics. Progress indeed.

Continue reading Helping at CoderDojoDC


At very long last, Twine 2.0 has entered beta. You can download it from Bitbucket, or play with it right now.

The word beta has been abused to the point that it is essentially meaningless, like HD or cloud, but I’m a bit of a traditionalist about it. To me, it means no more features until the real release, only fixes. It means we’re close to a final release. So it’s an exciting milestone for me.

Continue reading Beta