This morning I tested a few features of the Frotz text adventure delivery system for iPad. I was curious whether an author can make unreleased beta versions of new games available to Frotz users for testing. Answer: Yes. I was able to download a game file from my own website server and play it in Frotz.
While looking for a couple of game files I could test this with, I had a look at the list of the top-rated games in last year’s IF Competition. Several of them were written in a development system called Twine. I haven’t looked at Twine for several years, so I figured I should check it out. Verdict: It’s not for me, but I like what they’re doing.
Truth be told, all fiction is interactive, and in at least two different ways. First and more trivially, you can always flip back to an earlier page and re-read a passage. Second and more significantly, in the process of reading you actually produce an imaginary world based on your own experiences, emotions, and subconscious creative effort. Without this complex mental activity, fiction would be not just meaningless but incomprehensible.
In the computer age, however, more complex delivery systems for fiction can make the reading experience less linear and more interactive. That’s why we call it interactive fiction.
In order to write a story that’s interactive in this sense — a story that relies on computer-based delivery to the reader — it’s not enough to write sentences and paragraphs. The author must actively assemble the story out of separate components, and develop an idea of how the reader/user/player will interact with those components.
All authoring is nonlinear, unless perhaps you’re Jack Kerouac engaged in pure stream-of-consciousness, and even Kerouac may have juggled a few ideas in his head as he went along before committing them to the page. For the author of interactive fiction, however, the nonlinear nature of the medium is welded into the creative process. Not only do we have to imagine how the reader will encounter the various bits of the story, we have to make sure that the reader has some options from which to choose along the way. If there are no options, the story is just standard fiction. It could be delivered, on a computer, as a PDF document, to be read from beginning to end with no branches or choice points for the reader, other than, as noted above, “Would I like to turn back to an earlier page and re-read that passage?”
This observation brings us to the core point I wanted to make today. Twine’s approach to interactivity is essentially quite different from the more traditional parser-based interactivity. Each system has its merits and its drawbacks.
Parser-based IF, the kind produced by programming languages such as Inform and TADS, uses a world model as its foundation. Other systems, such as Twine, have a choice-based, branching tree foundation, and are oriented more toward presentation. That’s not to say presentation is irrelevant in a parser-based story, or that a choice-based story can’t model a fictional world. Still, the differences are significant.
In parser-based IF, the user has to type commands in a sort of spiffed-up command line interface. This kind of interface was universal on computers in the 1970s, when IF was born, but today it feels rather balky and old-school. This is especially the case if you’re trying to play/read the story on a tablet or a phone. Typing in an on-screen keyboard is an ugly business, no matter how agile your thumbs. IF delivery systems may give authors of parser-based stories a few shortcuts to ease the burden of typing, but the shortcuts can take you only so far.
The advantage of parser-based authoring, and in my opinion it’s huge, is that developing a complex, immersive world that the reader/player can actively manipulate is a straightforward business. While encountering the story, you can pick up objects, carry them around, and drop them. To be sure, you can only do this in the ways the author imagined, but the number of possible states that the story can get into is likely to be astronomically larger than in a choice-based story.
In a choice-based story, the user doesn’t have to (and in fact can’t) type. Instead, you tap or click on links, and the story displays new words and sentences in response. You may be able to wander around at will in the haunted mansion, going back and forth from the wine cellar to the attic and perhaps having a conversation with the ghost of the butler, but you’re always making choices within a finite branching tree. Complex behaviors that would be half-hidden puzzles in a parser-based story — something like FILL THE BUCKET WITH WATER, perhaps — are either obvious in a choice-based game (because the link is visible) or nonexistent.
That’s the downside. The advantages of a choice-based system are, first, that it’s easier for your readers to deal with; and second, that the authoring system will probably have more robust support for graphics.
The original enticement of systems like Twine was, I believe, “Hey, you don’t have to know computer programming! Just write your story! It’s easy!” (Not that it’s ever easy to write a story….) But in its present incarnation Twine has quite a lot of programming hooks. You don’t have to use them if you don’t want to, but if you’re aiming at any sort of sophistication, you’ll want to.
That was the original enticement of Inform 7 too, by the way, and I7 is for writing parser games. If anything, I7 authoring looks less like computer programming than Twine authoring does. Unfortunately, neither Inform nor TADS is in active development these days. The future seems to belong to Twine and its brethren.
I still feel strongly that a parser-based story is a better choice for the author. But I’d be lying if I didn’t acknowledge that readers, and especially younger readers, may much prefer a choice-based story.
Jim Aikin's Oblong Blob 