Why Nobody Cares

Millions of people love to read. Millions of people love playing computer games. So why don’t millions of people love playing games that require a little reading?

Lately there has been a flurry of discussion about why the audience for interactive fiction is so tiny, and what might be done to change that. I can think of several reasons why, but I would agree with the emerging consensus that the command line interface (CLI, for short) is a Big Problem.

The new round of discussion seems to have begun with a post titled “So, Do We Need This Parser Thing Anyway?” on Emily Short’s blog. It branched off to this thread on the intfiction.org forum. Horace Torys soon put up a blog post called “Simple IF Interfaces” in which he presents what appears to be a series of mockups of an elegant non-CLI design.

The command line interface, which emulates an old-fashioned device called a teletype, is frankly a holdover from the 1970s. Games that used a CLI made perfect sense when all computer users were familiar with that type of interface, and when it was the best you could expect because computers didn’t do graphics. Today, most computer users never see or use a command line, so they’re not comfortable with it.

Also, the commands you can use in a story are not visible. You can’t grab them from a menu — you have to learn them. Many newcomers to IF gameplay give it a try, get confused, and quickly give up. Possibly they’ve been misled by someone who told them they could just type English sentences at the command line. (Howard Sherman, who makes a vigorous pretense of selling IF commercially, is fond of making this preposterous claim.)

The command line syntax in interactive fiction is much better thought of as Caveman English. GET ROCK. HIT TROLL WITH ROCK. SEARCH BODY. TAKE SCROLL. But “Caveman English,” however apt, is not a phrase that’s likely to catch on with a marketing department, or with the general public. “Yeah, I’ve been playing this terrific game … and the way you do it is, you type commands in Caveman English!” No, you won’t get any word-of-mouth promotion with that phrase.

The CLI is not the only stumbling block in the way of IF success. Many of the existing stories are just not very good — and finding the good ones is not easy, because there isn’t really a gatekeeper at the portal. Any novice can release a third-rate game, and a lot of them have. There are reviews at the Interactive Fiction Database … but even if you happen to know how to find the IFDB, reviews by unpaid and possibly ill-informed players are not a rock-solid guarantee that you’ll like the game.

Then there’s the necessity of downloading a separate interpreter program in order to play the game. Doing this is extra trouble, and it’s confusing to newcomers.

Lately some work has been done on creating browser-based interpreters for games written in Inform. This eliminates the need for a separate interpreter program, but what I’ve seen so far doesn’t impress me. The interpreter (written in Javascript) loads slowly, and then the game loads slowly, and then the game responds sluggishly to user commands … which are, of course, typed in a command line.

I’m a writer, not a graphic artist. I don’t want to be forced to come up with clever graphics to put a story across. I like the idea of text-based games a lot. But I’d love to be able to design a game around a better user interface. We could have some long, multi-faceted discussions about what “better” means in this context. I don’t pretend to have all the answers, or indeed any answers at all. David Cornelson is a strong proponent of testing possible user interfaces by having players (ideally, those who are brand new to IF) try them out. Really, there’s no other way to be sure a design is working.

But in order to run tests with volunteer players, you have to have something to test. And that, at this stage, is also a major stumbling block. We have, today, three well supported authoring systems (Inform 6, Inform 7, and TADS 3), none of which is capable of generating a text game with a streamlined user interface. With these systems, what you can write is CLI games.

They do have some limited ability to enhance the teletype metaphor with late-20th-century UI elements. You can add clickable links to a TADS game, or open up secondary windows (in either TADS or Inform) to display special items (maps and so forth). But adding those features is not easy, you’ll be seriously hampered by the limitations of the system, and after you’ve gone to all that extra trouble, the people who play your game may not be able to see or use the links or the secondary windows, because they may be using an interpreter program that won’t display them.

Trying to coax Inform or TADS into doing what’s needed is like trying to build a billiard table on a bicycle frame, basically.

If I were a real programmer, I’d download QT (which I’ve heard does a sweet job of generating cross-platform apps), roll up my sleeves, and create an entirely new authoring/gameplay system from scratch. But alas, I’m not a real programmer. It would take me at least two years of daily effort just to come up with a crude prototype, and a couple more years after that to whip it into shape. That’s probably a bigger project than I want to tackle.

If I were rich, I’d hire a programmer, or several of them, to do the coding. But I’m not rich. Hey, does anybody out there have, like, a quarter of a million dollars they don’t know what to do with? If so, send me an email — I’ve got a swell idea for you.

This entry was posted in Interactive Fiction, technology and tagged , , . Bookmark the permalink.

6 Responses to Why Nobody Cares

  1. georgek says:

    Have you looked into the non-CLI systems such as Twee/Twine, Undum, or ChoiceScript? They’re usually billed as CYOA-style systems, but you can do a fair bit with the underlying code to make them more IF-like.

    • midiguru says:

      Interesting! I had never heard of any of those systems. Twine appears (from my preliminary look) to be pretty strictly a CYOA system. ChoiceScript looks like an invitation to spaghetti code, with the ready availability of Jump commands, and it seems to have its own syntax.

      Undum looks more promising. I like the visual quality of the output, I like the fact that the output changes dynamically, and I like the fact that the story will keep track of certain things as you move through it. How exactly you’ll be able to use the data it’s keeping track of to alter the progress of the story remains to be seen … the short tutorial doesn’t explain that.

  2. georgek says:

    The technique to alter the story choices based on data is, from what I can tell (not having written anything in Undum or Twee/Twine), more straightforward in Twee/Twine. For example, in Twee:


    In Undum, it seems like you need to write a function that then selects text from the game’s HTML file (distinct from the game’s JavaScript source file). For example:

    "two": new undum.SimpleSituation(
    "Option Two\
    You chose option two, which is my favourite option as well.\
    I find the photographs accompanying option one to be too disturbing.\
    Finger nails just shouldn't bend that way...\
    From here it is just a short step to the\
    final bits of content in this tutorial."

    // Again, we'll retrieve the text we want from the HTML file.
    "saving": new undum.Situation({
    enter: function(character, system, from) {

    That gets the ‘s_saving’ div from the HTML file, rather than just going directly to the Undum ‘saving’ situation defined in the .js file.

  3. georgek says:

    Oops, it looks like WordPress ate the link code there — the ‘short step’ link should show the anchor to ‘saving’ instead. Anyway, it’s all in the tutorial .js source code for Undum.

  4. midiguru says:

    I’m thinking maybe I should try implementing the beginning of a story in both systems, and also in Inform 7, so as to be able to understand their differences. One thing I suspect is that both Undum and Twee may be at their best with branching stories, while Inform is at is a better choice for a story that involves problems — that is, puzzles. All of the choices in a CYOA-based system will pretty much need to be visible to the reader/player, as there is no parser.

    However, some choices may remain invisible until the reader makes other choices. For instance, if the word “painting” in a room description is a link, it might only be equivalent to ‘x painting’, or you might find the wall safe behind the painting by clicking on that link. You don’t know until you try it. So I suppose there would still be a sense of discovery, even if the story hasn’t branched.

    What attracts me about Undum is that the authoring environment is Javascript — a well-supported language that runs natively within the browser. Twee has its own syntax. But we’ll see….

  5. Horace Torys says:

    It might not take that long to make a story — you’re not trying to program a language like Inform or TADS, just a new story. I did an experiment in Javascript which is very simple, but with a bit of creativity could be extrapolated into a full story. And instead of spending time writing for readers doing things you don’t want them to do (as with a CLI), you can put that time into making the story read well when they do things you want them to do (their choices are limited). My story doesn’t have an inventory, but that also would be fairly simple.

    You can check it out my site under Fiction. It’s called “Red.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s