The prevalence of Twine in the most recent IF Comp, together with some discussions with Porpentine (author of howling dogs), made me give it another try. For those who aren’t familiar with its output, it’s designed for building CYOA or hypertext; it creates a website output that the author can then choose to customize with standard HTML/CSS tools, or leave as-is.
Twine has been around for quite a while. Some time back, I tried it out and couldn’t get it to run properly on a Mac. This time, I had no difficulty installing and running it, so whatever updates have occurred have resolved at least my problems.
Once again, I was struck by how relatively slight differences in the core model of the tool made big differences in how I was inclined to use it. Of the tools I’ve discussed on this blog, it probably has the most in common with inklewriter: both are honed for CYOA, both are free to use and quick to set up, both handle some simple variable tracking information but don’t go in for ChoiceScript’s fairmath or more sophisticated systems of inventory and displayed stats, or the storylets found in Varytale or StoryNexus works. Here are the key points of difference I found between writing with Twine and writing with inklewriter:
Visualization. First of all, Twine presents a graphical layout as its primary way of conceiving of authorship. Here’s a screenshot from a sample work I developed to explore its abilities:
This isn’t a million miles off from the “map” view available in inklewriter; if anything, inklewriter’s map has a little more visual slickness and indicates useful information with color and the little “end” tags that show where a story concludes:
But inklewriter’s map is a modal pop-up that you have to put away before you get back to work, while Twine’s is your main view into the work, all the time. Also, with Twine it’s possible to move the snippets around and reconfigure them into a pattern that is most friendly to your own personal conception of the story layout (with or without grid-snap, depending on how tidy you feel like being). So I found that encouraged thinking about the work structurally rather than focusing on a single linear path at a time.
Variable handling. Conversely, several things inklewriter does with an entirely graphical interface (measuring whether you’ve passed certain flags in the story, e.g.), Twine handles with more code-like markup. It’s extremely simple markup, though. Twine’s variables appear a bit more robust, too (though inklewriter has been adding features, so it’s possible I’ve missed some recent evolution). Nonetheless, if I wanted to create something that made extensive use of player stats, I think Twine might have the slight edge over inklewriter, which last I checked relied a lot on very simple flags. (Of course, if I wanted extensive player stats, I might also be considering ChoiceScript or Undum, both of which explicitly display stats to the player.)
Twine has one other feature inklewriter doesn’t at all, as far as I know, and that is its ability to “remember” a variable — storing it as a cookie. This provides a basic mechanism for tracking information across multiple playthroughs by the same player.
Segment length. Twine also presents the author with a somewhat larger text box for inserting text, and a wider text column (by default) in the final output — and I found that I tended to write more per individual passage with Twine, whereas inklewriter got me thinking in terms of really rather short bits of prose connected by many changes and turning points.
Format of presenting choices. inklewriter really wants you to add options to the end of a text snippet: it’s set up for CYOA but not so much for hypertext, where the links are embedded in the body of the text and might represent a desire to dig deeper into a bit of exposition, rather than to proceed forward with a story action. Varytale and Undum also allow this kind of in-line option; ChoiceScript, inklewriter, and StoryNexus do not, and in the case of StoryNexus it’s not completely clear what that would even mean.
In my observation, the hypertext presentation tends to encourage works written with more subjectivity and interiority, whereas CYOA presentations tend to be more about courses of action and what happens next. These are really broad-brush generalizations, and there are obviously lots of exceptions. All the same, my sense is that Twine has given rise to a lot of works that are personal expressions on the part of the author, that might not feel heavily game-like, and that prioritize communicating to the player rather than inviting the player to communicate in return.
Build cycle. Twine is a program that has to be downloaded, and each time you want to see the output you need to build the story and view it in a browser. This is not exactly an onerous cycle, and if you’re used to TADS or Inform it’s quite speedy; but it’s not quite as fantastically transparent as inklewriter, where you can write in a browser and immediately view the results there as well.
Ownership and monetization. Twine is a free program, not owned or maintained as a commercial enterprise; you can use it for commercial works if you wish, but you’ll have to invent your own monetization method. By contrast, inkle studios will for a fee let you export your inklewriter story into a Kindle format that you can then sell in the Kindle store — but they also require you to sign in to their site to use inkle tools, and retain ownership over the authoring program.
Because Twine is open source, it’s extensible, and a few people have developed additional features for it; for instance, here is a piece that features a map, automatically scrolled when the player moves from one location to another in the story.
Some Twine games can be found on IFDB; there is also a Google group for discussing the tools and announcing games.