Text Adventures

Haha, as in “adventures with text”.

Anyway, I’m still working away on this Twine I’ve been making in fits and starts since late September called Burnt Matches. At this point I have pretty much the whole thing structurally done, and it’s been a wild ride trying to do something that (I feel) is interesting with text and layout on webpages. One way or another I’ve kind of drifted toward a model of text and text animation as representative of space rather than “description” per se. Not that that’s original or anything, but that’s what’s happening as I try to grapple with the “story” involved (about penetrating into a hidden/forgotten facility for storing nuclear waste). Strange given that the project started mostly with an interest in modelling alien-feeling user interfaces for that facility. The interfaces are still there, but they’ve been really backgrounded by this spatial stuff.

But the weird thing of all about this project has been just how damn complicated it’s been trying to work with text in the way I want to. Feels like I’m pushing on Twine in ways it doesn’t particularly care to be pushed on. Vast swathes of the game are written as overelaborate macros of JavaScript that generates pages of text/space rather than writing it in terms of Twine’s interface. So an entire sequence of events on a page in the Twine might be coded in the Twine interface as “«generatewasteland»” or something, which pulls in a bunch of JavaScript to do the heavy lifting. Feels unnatural and like I’m right at the edge of this actually being a sensible project to build in Twine in the first place.

This is especially true as I run into performance problems with the “Twiney” ways I initially wanted to use for aesthetic effects. Notably there are a bunch of places where I want to have text flashing, say, and I’ve been implementing that with macros from Twine (like the excellent «timedcycle»). Except that it turns out that’s got really awful performance if you do a lot of it on a single page, which I need/want to do. Today, fortunately, I discovered that there are often ways to pull off exactly the same visual effect through CSS instead, which turns out to perform really well. So I’m now migrating various effects to CSS in reduce the load the passages have in the browser, to try to prevent them from taking a second or two to actually load. There’s more work to do on that front, but it’s getting there. Thank good I teach a web art course at my university so I actually at least have a faint idea of how to do these sorts of things.

Anyway, the huge irony of this to me is that my games almost never need to “worry” about performance in the engines I’ve used, because they’re just so simple and trivial for the engines to handle (hardly any sprites, not much physics, not many moving parts, etc.). And yet now, working with Twine, ostensibly an incredibly lightweight and “simple” way to make a game, I’m running into honest-to-goodness performance issues that I’m having to optimise away like a real programmer.

The project as a whole feels like it’s been a series of weird tastes of forms of game design and development that I generally don’t go in for traditionally, from working with text for representation, to optimisation issues, to trying to actually build a narrative environment, etc. Really been a strange project. Fortunately, the more I’ve worked on it, the more I find that kind of rewarding rather than the “depressing” I’ve been rating it earlier on when it was just dragging on and felt like an ugly child I didn’t want to be responsible for. It’s still probably super ugly, but hopefully ugly in that way that it turns out to be strangely beautiful and walks down catwalks with great flair.

That’s enough out of me. Bye.

10 November 2016
← next words previous words →