Dead Letter Office

Apparently nobody is very serious about wanting a solid, modern presentation for interactive fiction in web browsers. My recent blog posts on the subject, which I mentioned in the IF Forum, have met with a thunderous silence. As Adlai Stevenson once remarked, “I’m underwhelmed.”

I suspect that the main reason nobody is hot to tackle this issue and wrestle it to the ground is because nobody really gives much of a crap about interactive fiction in any form. I suspect that the observation I made the other day about Quest — that it’s caught in a negative feedback spiral because nobody who truly cares about producing high-quality work would mess with it — applies to the entire field, not just to Quest.

The 2011 IF Comp was won by a game called “Taco Fiction,” whose premise is that you’re a down-and-out, seriously broke guy. You can’t pay your rent or make your car payment, so you’ve decided that the solution to your problems is to mug a passing pedestrian and then rob an all-night taco joint at gunpoint. You haven’t actually loaded your revolver; you’re not quite that much of a desperado. In fact, trying to hold up a taco joint with an unloaded revolver is sort of doubly pathetic, isn’t it? But there we are. That was the most profoundly meaningful or best developed IF story of the year.

It’s pretty easy to see why any writer who wanted to produce serious fiction (and we’ll include humor in the “serious” category) would look at

Re: Quest

So far, the response has been underwhelming. I post a couple of thinking-out-loud pieces about how a 21st century interface and authoring system for interactive fiction might be developed. I drop links to those posts on the IF forum. And … nothing. On the forum itself, a couple of brief discussions ensue, but if there’s a groundswell of people saying, “Holy crap! You’re right!”, I blinked and missed it.

Alex Warren chimed in, noting that his Quest authoring system produces games that run in a Web browser and is extensively customizable. Alex is always keen to remind people about Quest, and very polite about it. So I had a quick look at Quest. I want to emphasize the word “quick,” because I may well have missed something important. But after an hour or so poking away at it, I’m moving on to look at other things.

The promise of Quest is, “You can write text adventures without programming!” And indeed, you can. To this end, the authoring system makes extensive use of mouse-clicking and little boxes where you enter snippets of this and that. This approach is bound to appeal to aspiring authors who are intimidated by programming — but if you have a bit of programming experience under your belt, having to grab the mouse over and over and over in order to create objects and define their behavior becomes fairly annoying.

This may be a matter of personal taste. If you like the mouse and hate typing, you may respond differently.

Within, or behind, the Quest authoring interface is a powerful scripting feature, with which you can customize your games.  But to get at the power, you have to

Look Through Telescope

Yesterday I summarized the problem: The existing delivery systems for interactive fiction (a.k.a. text adventure games) are mired in the 1980s. The early 1980s. Today I’d like to toss out a few ideas about what, ideally, ought to happen in order to bring the presentation of IF forward into the 21st century.

Broadly, there are two ways to move forward: either a massive extension of an existing authoring system, or an entirely new system. Both courses are fraught with difficulties; neither is a stroll in the park.

Let’s take a brief look at the characteristics such an authoring system would, ideally, have. The list below is not intended to be exhaustive — I may have left something out. It’s intended to serve as a starting point for discussion.

1. The games produced using the new system should be playable, and with an essentially identical appearance and functionality, in MacOS, Windows, Linux, and mobile platforms.
2. Convenience for the end user should be emphasized. The user should not have to download and install separate interpreter software or a self-contained app.
3. The authoring system itself should be available on all three desktop platforms, and without too great compromises in terms of utility. (No use of a command-line compiler should be required in one OS, for instance, if it’s not required in another.)
4. The author should have

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

It’s a Big, Wide, Wonderful World

Recently a couple of threads have popped up on the interactive fiction forum proposing that interested parties write games set in shared worlds. The worlds to be shared were set forth in some detail. As it happens, I found one of the proposed scenarios rather evocative, the other less so. But that hardly matters; I already have a few ideas of my own that I’d like to develop.

What struck me was how easy it is to spin out phantasmagorical ideas for a shared world — and how much more difficult it is to craft an engaging story.

When she wrote an introduction to the 1831 edition of Frankenstein, Mary Shelley described the little contest that gave rise to the novel. Lord Byron had proposed that he, Percy Shelley, Mary, and a certain Dr. Polidori, who were cooped up in a house in Switzerland owing to an incessant and altogether fortuitous siege of summer rain, each write a ghost story. “Poor Polidori,” she tells us, “had some terrible idea about a skull-headed lady who was punished for peeping through a key-hole — what to see I forget: something very shocking and wrong of course … The illustrious poets, annoyed by the platitude of prose, speedily relinquished their uncongenial task.”

And then she says, “I busied myself to think of a story.” (The italics are hers.) That sentence has been a touchstone for me for a very long time.

Storytelling is surely one of the oldest of art forms — and unlike painting and music, its essentials probably haven’t changed much, if at all, in the last hundred thousand years. The most exotic and elaborately imagined world will fall flat if it isn’t animated by a compelling story.

Abstract vs. Concrete

Yesterday I was reading up on the Javascript programming language. Then after supper I resubscribed to Netflix and watched the first four episodes of Buffy the Vampire Slayer, back to back. Both activities were fun, but the contrast was noticeable.

Why Javascript? Because I’ve been looking into the possibility of presenting interactive stories in a web browser. Ian Millington’s Undum system makes this possible — but Undum uses Javascript quite intensively, so I would need to know it a lot better than I do in order to create a story with Undum.

The goal is clear: I’d like to write stories and make them available for people to read. The stories themselves would be concrete experiences — just words on a page or screen, it’s true, but words stimulate the brain to imagine that real events are transpiring.

Same deal with Buffy: The reality (cameras, scripts, lighting, makeup, paychecks to the actors, carefully designed special effects) is an abstract apparatus, but the viewer has, in the end, a concrete experience. Mentally constructed, to be sure, but it’s an experience of “real” events, not an experience of the syntax of computer code, nor of camera angles and all the rest. If we notice camera angles and lighting while watching a movie or TV show,

Undum & Vorple, Part III

What will interactive storytelling look like in the 21st century? Oops, we’re already 12 years into the 21st century. And yet the main authoring systems for interactive fiction still produce stories that rely on a computer user interface that was common and well understood in 1980.

Maybe it’s time for a paradigm shift. Do you suppose?

In the last couple of days I’ve glanced at a variety of new software tools designed for interactive storytelling, and/or stories created using said tools. Verdict, first, evidence afterward: Undum with Vorple is the clear winner.

Twine has a nice editing environment (it’s a bit like Quest), but Twine stories seem to want to clear the main display area and toss up entirely new text every time you click a link. Continuity of narrative in such a system is essentially zilch. Bad psychology — in essence, it’s even worse than what you get with an old-school command line interface.

The two ChoiceScript stories that I looked at were stunningly bad. It appears ChoiceScript is set up to collect the player’s characteristics based on what radio button the player clicks on in various menus of choices. Player characteristics — a relic of Dungeons & Dragons. Radio buttons — ugly.

Ren’Py might be a reasonable system if I were a graphic artist. I’m not. BloomEngine may be capable of delivering an effective browser-based story experience, but the game written by its creator neither looks attractive nor reads well; plus, the engine apparently relies on HTML 5 tags with a minimum of Javascript code, which seems a somewhat artificial limitation to me. If you’re going to build a race car, you don’t start with a bicycle frame.

John Ingold wrote a clickable story called “A Colder Light” using Inform 7 with some extensions. That development system may have some promise, but “A Colder Light” reads exactly like a 1980-era command line game (because that’s what it is). The sugar sprinkled on top is

Undum & Vorple, Part II

No matter how attractive a technology may look, if it doesn’t do what you need it to do, it’s a doorstop.

After looking at Undum for a couple of days, I’ve concluded that it’s a doorstop. [Edit: Probably not true.] This saddens me, because it looks very enticing. As I detailed in my previous post, Undum is a way of delivering interactive stories in a web browser. It’s visually beautiful, requires no special knowledge of the reader, and can deliver stories to users on any platform that supports a modern browser — iPad, Linux, an old PC running Windows XP, whatever.

Using Undum, you create your story using Javascript and HTML 5. This is not precisely an author-friendly way of developing stories, but it’s manageable. These technologies are well understood and very powerful. If you want not only to create an interactive story but have it look good … folks, I hate to break it to you, but Inform, TADS, Quest, and the other authoring systems used for the past decade or so by authors of IF just ain’t gonna cut it. All of them display their stories in app interfaces that are, frankly, ugly. And not very user-configurable, either. So Undum would appear to be a super, super choice for the author who cares about giving the reader a gratifying experience.

But between the dream and the reality falls the shadow.

Web browsers are, very sensibly, designed in such a way that web pages can’t read files on your hard drive or write files to your hard drive. If such activities were allowed, the whole world of modern computing would collapse. Your personal computer would quickly become a hornet’s nest of malicious stuff. A web page can store a small piece of data (called a cookie) in a special folder, but only that page can read the cookie. Other restrictions quite likely apply.

As a result, Undum has no way to allow readers to store their progress through a story. Okay, technically it has one store point, which you can create using the Save button. The next time you load that Undum story, it will automatically fast-forward to the point where you saved the cookie. But you can’t save multiple store points within your story. [Edit: It turns out HTML 5 provides a facility called localStorage, which is plenty big enough to store lots of save points. Undum just hasn't implemented a full save/restore feature, that's all.]

This is a problem because Undum is designed specifically to produce interactive stories. In an interactive story, the reader

Undum & Vorple

Technologies — there are so many! How do you pick and choose what you’ll use?

Last week I finished writing an interactive fiction game called “The White Bull.” This game has been entered in the 2012 Spring Thing competition, which will be open for players/voters on April 6. I’m pleased with the way the game came together, and I hope players will be too. I used the TADS 3.1 development system, which is very sophisticated. Almost intimidatingly so.

It has to be said, though: What TADS produces is, at the end of the day, 1980s-style text adventures. Granted, it has all sorts of advanced features, but the way you encounter the story as a player is, you type commands at the command prompt, exactly the way you probably did when you were playing Zork or Adventure on your Commodore-64. The same is true of Inform 7, a far more popular development system than TADS.

This user interface is very good for certain things, but not so good for others. The author can implement complex actions that are not immediately obvious to the player — for instance, something like ‘put the gerbil in the microwave’. This could be an effective puzzle, assuming you don’t mind a little cruelty to small animals. The player has to conceive of the action and then try it.

A user interface that relies on clickable links can’t easily be used to implement this type of puzzle. If the menu of allowed actions for the gerbil includes ‘put in microwave’, then

This Is Your Game on Mugs

Sometimes an upgrade is a mirage. Sometimes cool new features remain tantalizingly out of reach. [Note: This piece has been edited on Jan. 26 to reflect new information.]

I’m getting ready to enlist testers for my almost-completed interactive fiction game, “The White Bull.” I’m hitting what I hope is only a speed bump. At the moment the picture is rather murky. And the speed bump (if that’s what it is) has nothing to do with my work. It’s packaged in the development system. It’s … a feature.

One of the main reasons I decided to go ahead and finish this project, which had been languishing on my hard drive for a couple of years, was the release of TADS 3.1. TADS is a very slick system for writing text adventure games, and the 3.1 release enhances its power in some cool ways. Games compiled using 3.1 will be playable in a web browser, for instance, without the need to download anything. This is a huge step forward, as it makes TADS more competitive with Inform.

But wait — there’s less.

If I understand the documentation correctly, there are two ways to deploy a game for web play. You can upload it to the IF Archive and create a page for it on IFDB. The IFDB server, which is operated by TADS developer Mike Roberts, will make your game publicly available for online play. Alternatively, you can set up your own server.

I so thoroughly do not want to learn how to set up my own server.

The tricky bit is, how am I to test the web features of a game before it’s released? The word “test”