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.)