Whitewash

After taking a break from it for a few months, I’m taking a fresh look at The White Bull, my most recent interactive fiction. The sad truth is, it’s not as good as I hoped it would be.

I’d like to roll up my sleeves and revise it, but I’m not at all sure how to make the necessary changes. The story would probably be easier to rewrite as a novel, but I don’t much care for that idea. For one thing, I don’t feel like writing a novel this year. For another, I’m not sure “The White Bull” would make a good novel either.

The limitations of the text adventure game as a medium make handling the story elements rather difficult. Complex characters are difficult — one reviewer complained that the the conversation system was “basic and not extensive,” which just meant that he failed to discover any of the dozens of conversations I implemented. Characterization issues aside, moving the story forward is even harder. If the reader/player has real choices that can affect the outcome, then many players will never find the path to the happy ending. Plus, if there are four significant paths, that’s four times as much work (or possibly 16 times as much). But if the player has no meaningful choices, then the story isn’t interactive — it’s a linear narrative.

My initial idea for the story was that the Labyrinth — you know, the one Daedalus built to imprison the Minotaur — was not only real but still present in some magical dimension. Theseus, in this reading, didn’t kill the Minotaur; he lied about it.

This idea seemed at first blush to lend itself well to interactive fiction, because the most hallowed trope of text games is the maze. The difficulty that immediately leaps up, however, is that players hate mazes. So the Labyrinth can’t be a real maze. I wrote several regions that look like mazes, but aren’t. I’m not sure that did much good. Maybe I should have just made it a giant maze and forced players to by golly work their way through it. Maybe.

A second difficulty is that in the first part of the story, the protagonist (that would be you, or “you”) has no clear motivation to do anything. As a practical matter, you need to

Black, with Cream and Sugar

Non-stationary art got a big boost in 1930, When Alexander Calder invented the mobile. Now that the computer is ubiquitous, the possibilities for non-stationary art — interactive or simply involving unpredictable and non-repeating motion — are staggering. Okay, computer screens can’t do real 3D, and a mobile is real 3D. But even so, the sky’s the limit.

I’ve noted before that if interactive fiction has any hope of being taken seriously as an art form, it’s going to have to present a modern, attractive user interface. To be both attractive and deliverable to users, it will need to run in a standard Web browser. And that means that IF authors who don’t wish to be ghettoized or marginalized are going to have to come to grips, in some way, with Javascript.

The same could be said about almost any digital art form, not just IF. Sure, you can upload your photos to Flickr or your music tracks to Soundcloud, but at that point your audience will encounter that user interface, which may well detract from the experience you would like to convey. You’ll have no control over the presentation. And presentation matters.

The same can be said of conventional interactive fiction played in a browser-based interpreter. Yes, it can be played over the internet, but as an author you still have damned little control over the presentation. If you want that control, you will have to roll your own interface in Javascript (or spend a lot of money hiring somebody who can do it for you).

What I’m discovering today about Javascript is still rather preliminary — these are my impressions, and should not be taken as gospel. I may be wrong. But I’m learning some stuff. I can list seven different reasons why Javascript is problematical, if not

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