Longevity

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!

p.s.
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.

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. twine.2.0.9pre1.zip 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.