User interfaces in text-based games
===================================


18 December 2016

Maybe I write too much about text-based games, but in my defense the written word is awesome. It's the closest you get to a digital medium without actual computers (what with letters and words being discrete symbols by definition), and one of the most flexible as well. Communication doesn't get more pure than a stream of symbols flowing back and forth; you can write them down on paper, ticker tape, or walls, going left or right, up or down, and even lay them out in three dimensions, as the Ancient Egyptians amply demonstrated. You do have to pick one path when reading, but hey, that's what we call hypertext nowadays.

Early computer games, from _Hamurabi_ (Doug Dyment, 1968) to _Adventure_ (Will Crowther, 1976) were limited to a linear stream of text, simply because they had to run on teletypes. For the same reason, input was also limited to typing words on a keyboard. But that limitation also meant you exchanged words with the computer from equal footing -- what people in the real world call a chat.

And so, a command line remained the defining way to interact with text adventures, helpers like a clickable compass rose notwithstanding. Oh, there were always a few games that tried to emulate the pick-a-choice interface popularized by gamebooks in the 1980s. But those were hardly on anyone's radar until 2009, when Twine swooped in. At which point it became impossible to ignore all the people shouting that the emperor is naked.

You see, over the decades interactive fiction authoring systems have evolved into highly sophisticated simulations of everything from furniture and clothing to non-player characters (NPCs) with their own knowledge and agendas. What hasn't changed is the parser -- the part that makes sense of your words when you type, "take the sword from the wall and hit the orc with it" -- not from the mid-1980s. That's over three decades, an eternity in computer time. Oh, the parser has become smarter about figuring out what you mean by "open cover", but that only helps people who already get it. Otherwise it's still just as hard to learn what verbs are likely to be understood, and how to form the limited range of imperative sentences a text adventure accepts. Which in turn greatly increases the burden on authors to make their creations accessible, and still limits the potential audience.

Twine on the other hand, along with all other tools for making choice-based games, throws out the baby with the bathwater. In order to keep things simple, it gives up on not just the parser, but also the underlying world model (the aforementioned simulation). Which just means that you still need the usual trappings of programming, such as if-else and variables, to make anything remotely game-like, and the results still come across as simplistic in comparison.

In parallel, _Rogue_ (1980) and its descendants tried another way, namely doing it all with one-key commands, the list of which can be shown on screen at any time. But that turned out to require most of an ordinary keyboard, including the shift key, which was no easier for players. And some games, like _[NetHack](https://www.nethack.org/)_ (1987), still need more combinations. One might ask why they don't resort to a menu system instead, similar to those used in Japanese role-playing games, as indeed _[POWDER](http://zincland.com/powder/)_ (Jeff Lait, 2003) does in order to be playable on videogame consoles, with only a D-pad and two action buttons for input. In text adventures, however, it didn't work out: _Wonderland_ (David Bishop, 1990) supplements the parser with lists of words you can click with a mouse, not unlike when early graphical adventures first tried to do away with the typing requirement. And just like with the latter, _Wonderland_'s approach failed to catch on, apart from isolated attempts. I can only speculate as to why, but clearly people didn't feel like it fixed the parser's biggest problem. Namely, you know, exactly how to put all those words together such that a dumb computer can actually make sense of them for a change.

Oh well, mobile devices with their limited screen space would have killed the approach anyway, just as on-screen keyboards are killing the good old parser.

Good riddance, some might say. Following links is so much easier anyway. At least until it turns out that most choice-based games actually offer very little choice. Why? The reason quickly became apparent for many beginning authors who jumped feet-first into Twine: the promise of making games without programming is overblown. For all but the simplest interactive stories, you need to model at least actors with mental states, a physical environment, or more likely both. Which is... exactly what Inform 7 hands you on a plate. But Inform 7 games feature the dreaded command line...

It would seem we're stuck between two evils. Except this is where so-called hybrid interfaces come in. First announced in 2014, [Texture][] finally launched this summer, and quickly became popular thanks to its unique take on the issue, one equally well-suited to desktop and mobile: you drag verbs from a small list at the bottom of the screen over nouns in the text to trigger an action. This may sound like it's still limited, but potential options multiply quickly with each new verb or noun. The only downside is that you only get binary flags (true/false) for state tracking, even less than Twine provides.

[Texture]: https://texturewriter.com/

A bigger breakthrough came from Robin Johnson, whose game _[Detectiveland](https://versificator.itch.io/detectiveland)_ won the 2016 Interactive Fiction Competition with acclaim. His innovation, so obvious in retrospect that nobody saw it for decades, was to attach just a couple of important actions to every object listed on screen: "look" and "take" for example, or "talk" for an NPC -- which in turn reveals a list of topics. Add a set of exit buttons for each room, that you can press to navigate the map, and you get the old dream of having full-blown text adventures, with a complex world model, as easily playable as a choice-based game.

Of course, this leaves each object with few possible interactions, but half a dozen buttons on screen at any one time, if not more, is pretty good. Especially as now you have a whole virtual world to play in.

Turns out, it's not how many verbs you have, but what you can do with them. And there's a third authoring system getting notice this year, one which carries this idea to its logical conclusion. Taking the middle ground, [Elm Narrative Engine][elm] simulates just the basics of a game world: actors, props and locations. It doesn't even bother with a map -- you can simply revisit any place already discovered with a single click (not unlike the way some modern parser games have a GO TO command). As for the rest, you can only click on stuff repeatedly, but different things will happen at each point in the story, and you can interleave and distribute pieces of the narrative in ways even Inform doesn't readily enable.

[elm]: http://elmnarrativeengine.com/

It took a surprisingly long process of refinement to reach this point, and I didn't even mention keyword-based input, or games with a restricted parser (a topic for another chapter). Or the fact that authoring systems such as ChoiceScript, Ren'Py or even Twine also allow for freeform text input at key points in the game -- and I never saw that used in a game made with either. But the fact that so many alternatives to the parser/choice duality rose to prominence in a single year tells me something big is happening.

Things are exciting again. We needed it, too.