Stuck in Lodi Again

First a little ancient history, then a rant, and then maybe a vision for the future.

It would have been the summer or fall of 1982, just about 30 years ago today. I had a Kaypro II, my very first computer. Single-sided 5-1/4″ floppy drives and 64kb of RAM. I bought it when the price came down to $1,295, if memory serves. Anyway, my friend Jon Sievert, who had been instrumental in convincing our boss to invest in Kaypros for the office, hung out in his free time and swapped cool software at Kaypro user meetings. This was a couple of years before copy-protected software, and programs were passed around like party favors. So one day Jon showed up at my house and said, “Here, let me make you a copy of this. You’re gonna love it.” And he was right. I did.

What he gave me was, of course, “Adventure.”

“Adventure,” and later, “Zork,” transformed the computer from a rather balky utilitarian device into a magic playground. You didn’t know what might happen.

Another 15 years would pass before I discovered Inform 6 and wrote my first text adventure game, “Not Just an Ordinary Ballerina,” but I knew from the very beginning that this was a creative field I would enjoy. Today I’ve written six or seven text games, using three different development systems, so I feel qualified to make a few observations.

The Kaypro ran the CP/M operating system, a precursor of MS-DOS. The user interface was a command prompt. It looked like this: > The screen had one color: green. There were no graphics, no mouse, no sound, and no notion of networking. When you wanted the computer to do something, you typed a command at the command prompt.

Fast-forward to 2012: Computers today have graphics and sound. Many of them have touch-screens, and they’re small enough to fit in a backpack, or even in your pocket. Worldwide networking is a fact of life.

Today there are several full-featured development systems with which to write and deploy text-based games. And yet, the games produced with these powerful tools still use the command prompt as their primary user interface. Does this seem just a trifle retro to you? Possibly even bordering on clueless? The audience for text games is too small even to qualify as minuscule — not one computer user in ten thousand even knows they exist. Does it seem possible that the very antiquated user interface has anything to do with that?

There are millions of computer users. Most of them know how to read. Heck, even the ones in Asia and Europe quite often know how to read English. Most computer users are on the Web every day, and most of what they encounter on the Web is text. Nicely decorated with fonts and pop-up menus and sidebar graphics, to be sure, but it’s text. So it’s not at all unreasonable to suppose that more people might be open to the idea of experiencing a text-based entertainment product, might even be willing to pay a couple of bucks for it, if only the user interface made sense in terms of how they use computers every day.

A text-based game ought to present the same kind of user interface that any other computer software does. If it had a nice point-and-click (or tap) interface, drop-down menus, pleasant graphics, maybe a few mouse-over sounds or a low-budget video clip, the audience might only be a hundred times larger. But it would be significantly larger; that’s beyond dispute.

As an aside, the command-prompt interface does have some advantages for game-play. These games make much use of puzzles, and presenting a nice drop-down menu of available commands pretty much jerks the rug out from under a lot of possible puzzles. Also, it’s easier to type “take all” than it is to click on half a dozen items and then select the “take” command for each of them individually. But I’m a lot less concerned with the details of interface utility than I am with the reader/player’s overall experience. (A brilliantly designed UI could make a traditional command line available, somewhere down at the bottom of the window, for those rare occasions when it’s truly needed.)

Even if we set aside the idea that a larger audience would be a good thing, we’re still left to contemplate the fact that the experience of an interactive story would be much more pleasant and gratifying if the UI were not so stone-age. The essence of the experience of “Adventure” was that it turned the computer into a magic world where things could happen — things you had never imagined, but that would stimulate your imagination. You never knew what might lie around the next corner. Plus, it was a safe experience! You could stumble into a pit of boiling lava and then restore the game to an earlier point, and now you knew to avoid the pit of boiling lava.

Today, we all have exactly that kind of experience on the Web. The computer is a magic world where things can happen — things we haven’t imagined. And if we don’t like what we see, we can click the Back button. In essence, the World Wide Web is interactive fiction. And interactive fiction itself needs to take that fact into account.

I’m certainly not the first person to notice that the IF UI needs a facelift. Various developers have been at work for several years on ways to improve the delivery system. Atul Varna and Dannii Willis (apologies if I’ve misspelled your names) have developed Parchment, a browser-based interpreter for smallish games written in Inform, and Andrew Plotkin has developed Quixe, which does the same for larger Inform games. More recently, Mike Roberts has deployed WebUI for his TADS 3 authoring system, again as a way of letting players encounter the games in a Web browser, without the need to download and install a separate interpreter program.

And yet Parchment, Quixe, and WebUI still utilize the command prompt for user input. Quixe won’t yet do sound or graphics. And if you want to do any custom UI design, you’d better roll up your sleeves. You’ll need a thorough grounding in Javascript — plus, the WebUI API isn’t exactly documented, so you’ll need to paw your way through the source code to figure out what’s what.

Ian Millington has released Undum, a Javascript authoring system that does away with the command prompt. Juhana Leinonen’s Vorple extensions to Undum add some extra possibilities for display and interaction. Yay! But Undum isn’t well suited to full-featured interactive storytelling, for several reasons. You almost literally couldn’t port “Adventure” as an Undum story. A couple of years ago, David Cornelson and Jesse McGrew were working on FyreVM, which I gather is a slightly different way of controlling graphic output from an Inform game, but that effort seems to have stalled.

Given the tiny size of the IF authoring community, it’s not surprising that development efforts have been sporadic. It’s easy to have Dreamweaver dreams, but we’re on a BASIC budget, if that.

What frustrates me is that I would like to be writing interactive stories that people might enjoy. I’m basically a content developer — always have been. As a programmer, I’m strictly a hobbyist. If you held a gun to my head, I could certainly learn Javascript. I may end up doing exactly that. But writing games in TADS or Inform is enough of a challenge for me. If I can meander on to the end of my days without learning a single thing about JSON, Ajax, or PHP, I won’t suffer a moment of regret.

Even if I did start writing IF entirely in Javascript (and I’m tempted to do so, in spite of the very significant hurdles I would have to leap), it would be my own personal development system. Nobody else could use it without extended hand-holding. This seems less than optimal. Ideally, a modern development system would be something that any author could use, given a modest investment of time and effort.

At the moment, I don’t think there’s anything like a consensus on what a modern IF UI would even look like. Each developer seems to be off in his own sandbox. It’s a true blind-men-and-the-elephant situation. The possibility that an authoring system might see the light of day is still further off.

I’m going to split off my half-baked ideas of what such a development system and game UI would look like into a separate blog entry. The point of the post you’re reading, which I hope is clear, is — yeah, we really do need that.