Fictionally interactive

Markers and highlighters: a gamedev metaphor

(Excerpt from the book Let a Billion Videogames Bloom.)

It's common nowadays to see people complaining online that there are too many games out there (or books, or music, you name it). It's not nearly as common to hear them complain about too many game development tools, but that's mostly because fewer people are game developers; if you hang around in the right circles, you're bound to come across that one sooner or later. Interactive fiction, in particular, seems to suffer from this; a big part of nurturing new authors is helping them pick an authoring system. Already in the 8-bit era multiple companies sold competing products, in addition to the proprietary tools of major studios. Nowadays, the Cloak of Darkness website alone compares no less than 20 of them, and that's just for parser-based works! As for me, I created as many (toy) authoring systems as I did text adventures — one of which actually saw real-world usage, to my eternal surprise and gratitude.

And there's absolutely nothing wrong with any of that.

With so many authoring systems out there, some of them come so close in features and overall feel as to seem redundant. That's inevitable. I will also argue this is a red herring. Funny, isn't it? You never hear anyone complaining that markers and highlighters are redundant. Or crayons and colored pencils. Tempera and gouache. You get the idea. Arguably, software is different because it tends to proliferate in a way physical media do not, due to programmer hubris and the nature of computers, and I can't fault people for feeling overwhelmed. But even subtle differences may matter more than you think.

In the rest of the article I'd like to compare three authoring systems for browser-based interactive fiction, with remarkably similar design, that nevertheless make for a far from trivial choice.

Launched in 2010, Undum was the first choice-based authoring system I remember making a big splash, not least due to its heavy focus on excellent typography out of the box. Having built-in support for features like save, restore and undo couldn't have hurt, either, and "qualities" makes it suitable out of the box for RPG-like experiences reminiscent of old gamebooks.

Nowadays Undum is easy to use thanks to the Raconteur front-end, but at the time the would-be author had to messily code their game in Javascript. The system also felt big, even considering its capabilities. So on a whim I set out to create Ramus, an experimental system with the same overall flavor, except easier to use and deploy. In Ramus you write plain HTML (with a minor quirk) unless you need state tracking, and the entire game is contained in a single small file, at least until you start adding multimedia.

Not long after that, Alex Warren of Quest fame came up with Squiffy, yet another tool for making interactive fiction in the same style. Unlike the other two systems, Squiffy compiles games from a lightweight markup language, which includes shortcuts for things like counting how many times a passage has been read, that must be tracked manually in Ramus (not sure about Undum). Compiled games look very plain by default, but that's easy to correct with basic knowledge of CSS. Which is, of course, both good and bad news.

Now, at the core, all three systems produce mechanically identical works: interactive stories that unfold visibly as you make your choices, turning into a smooth linear narrative that reads like it was written that way, mainly by hiding the links not clicked (but leaving the previous text passages). That's a lot more similarity than between works made with Inform versus TADS, for example. One could easily argue we only need one of these systems. Undum was first, and still the most famous by far. It's gorgeous out of the box, and make no mistake, that matters. It has a lot of useful features on top of the core mechanic. So why would anyone bother making not one, but two other systems that do the exact same thing, more poorly?

I can't speak for Squiffy, but with Ramus minimalism was the whole point of my little experiment. Just as hammers and screwdrivers are still useful in an era of ubiquitous power tools, sometimes you just want to edit one file, writing good old HTML — no need to learn anything new — and be done with it. Clearly, a good handful of authors agreed with me. But writing HTML directly quickly gets tiresome. Nowadays I much prefer Markdown, and this is where Alex Warren was coming from, I suspect. Also, compiling your game from a plain text source file has advantages over editing a template directly. So Squiffy is definitely an option too. Doubly so as it re-adds as built-in facilities some stuff that Ramus requires you to code from scratch. Squiffy also makes it easier than either of the other two systems to add custom Javascript code if you really need it.

That's all from an author's perspective, and as such it already influences what the audience sees. But even if you're strictly a reader, the differences are more than just aesthetic. For example, Squiffy lacks that fancy scroll-and-fade-in effect of the other two systems... but that makes it the only one well-suited for dedicated e-readers! It's also the most plain-looking by default... but it means you can bundle your game as an EPUB 3 file and let the e-reading software deal with typography. Funny how it all fits together, isn't it?

So yeah. Just as writing with a pencil versus ballpoint versus fountain pen yields distinct results, even though your vocabulary and paper are still the same, three authoring systems for the exact same flavor of interactive fiction can make for works that don't read the same and don't play the same, in ways no less real or meaningful than "parser disambiguation works differently". And it's worth putting some thought into it when creating a new authoring system, because authors will consider it, and that makes you, the programmer, partly responsible for the results.

(P.S. Raconteur can be found on GitHub.)