War, Pestilence, Famine, Death, and Twine

I originally wrote this post for StoryCade.

There’s something unusual about the announcement of this year’s XYZZY Awards finalists. For the first time since since Inform 7 was released in 2006, most of the XYZZY Awards finalists were not created with it. In fact, this is the first time in the entire seventeen-year history of the XYZZY Awards that the plurality of nominees were not created with some version of Inform.

Continue reading War, Pestilence, Famine, Death, and Twine

The economy of Twine

Mark Bernstein was recently interviewed by Exprima Media, and a good portion of what he talked about concerned Twine. If you’re not familiar with Mark, he’s the chief scientist at Eastgate Systems, which publishes hypertext works– and more relevant to the discussion at hand, Storyspace, a hypertext authoring tool that was created in the 80s. Among his remarks was this:

Twine has no model for building a literary economy.

Continue reading The economy of Twine

Why I’m doing this

This was originally written for gimcrackd.com. A postscript — the piece in question was A Kiss by Dan Waber.

To counterbalance the gloominess I’ve been posting about recently:

Last month, I got an email asking for help with Twine. It was running really slowly, the writer said, and it was nearly intolerable, working with the story map. After trading emails back and forth, I asked if I could look at the story file he was trying to work with, and he obliged. (I always feel a little strange asking for these things — at least I feel quite protective of my own work — but people have always been willing to share so far.)

I opened it to find a total spaghetti of nodes and links. All in all: 300-some passages, about a thousand links running between them. This was, to put it lightly, more than I had ever expected my poor little program to deal with. The lines running to the central node were so tightly clumped together, in fact, they formed a kind of moire pattern. This was the worst-case scenario made flesh. It took maybe two seconds to redraw the map — not that long in the grand scheme of things, but when you just trying to scroll around, get a sense of things, you know, actually do work — it was agonizing.

What caught my interest, though, was the content. I did not go poking around in it deeply — again I felt odd doing so — but I did want to see what some of the really critical nodes, the ones that caused the frame rate to plummet as soon as they came onscreen, were doing. So I caught the drift of it.

It was a love poem.

I came up with some quick optimizations to help him out — I had missed some very obvious things. For example, if a passage linked to the same place twice, Twine would actually go to the trouble of drawing the same line twice. This helped a little, but the final solution was to allow users to turn off some of the prettier features of the story map to get better performance.

I have a better solution in the works for the next version of Twine that should solve the problem entirely. (Briefly: it will save offscreen the parts of the story map that never change, so that each redraw of the map only manually draws what has changed — e.g. the passage you are dragging around, or the marquee selection you are making. Again, fairly elementary stuff.) I still hold onto that story file, mainly to test out optimizations, but also to remember what I’m doing helps people do real things, to make poetry even. There aren’t that many developers out there making things that people make poetry with. I feel lucky.

(Quoth jwz: “Your ‘use case’ should be, there’s a 22 year old college student living in the dorms. How will this software get him laid?” Easy question.)