Extensions & Contractions

This week I’ve been working on updating my Inform 7 Handbook. It’s rather discouraging process.

Central to my discouragement is the chaotic state of the Inform extensions arsenal. In chapter 3 of my Handbook (which is a full-length book that has been, and presumably will be, available as a free PDF), I had guided the reader toward using a handy extension called Consolidated Multiple Actions by John Clemens. Published in 2008, this extension was designed to convert ugly 1980s-style output of this sort:

>drop dollars

silver dollar: Dropped.

silver dollar: Dropped.

silver dollar: Dropped.

silver dollar: Dropped.

silver dollar: Dropped.

…into something much more tidy:

>drop dollars

You put down the five silver dollars.

Needless to say, this extension doesn’t work with the current version of Inform. It’s a fairly complex extension — frankly, it’s beyond my ability to fix it. There is apparently no currently functional extension that does this. As a result, the new version of Inform 7 is actually less capable than previous versions when it comes to giving the author some basic control over the output text.

As a writer, I care about making the output look presentable. Call me eccentric if you like.

Inform 7 was designed from the ground up to encourage third parties to extend its fairly basic functionality by writing clever extensions. This is a valid approach to designing a programming language, I suppose. But it works better if you have a user base that’s, oh, let’s say a hundred times larger than the tiny, scattered community of interactive fiction authors. With such a minuscule pool of qualified programmers (of whom I am not one) to call upon for maintenance tasks, the result is sadly predictable: Stuff doesn’t get fixed.

As the author of Inform 7, Graham Nelson really ought to have understood this long ago. Inform is his creative project — perhaps, in some sense, his life’s work. I don’t know Graham, so I don’t know what other work he may engage in, but he has certainly put a massive effort into Inform, over the course of more than 20 years. And yet it’s not enough.

Knowing that numerous clever extensions would be broken by his new version, he ought to have taken definite steps to insure backward compatibility. Rather than eliminating numerous phrases from I7 syntax (and some features such as the Library Messages from the underlying I6 code base), he ought to have worked out a way to keep those phrases and features available, so that older extensions could continue to use them if need be.

Either that, or he ought to have revised all of the potentially useful extensions himself.

His failure to do either of those things sabotages his end users — the community of Inform authors. He has ignored authors’ legitimate needs.

Graham is a very bright guy. He’s certainly smarter and harder-working than I am. But it’s hard for me to feel enthusiastic about supporting aspiring Inform 7 authors by rewriting my Handbook, when the mastermind who created the entire authoring system shows so little evident interest in supporting them.

I’m strictly a bumble-fingered amateur programmer, not a computer scientist, but I can easily imagine a simple way that he could have preserved the functionality of those old extensions. Edit each extension to put the line “Allow deprecated syntax and features” at the top. An intern could update the whole library in less than an hour. Then tell the compiler that when it encounters a separate .i7x file with that line, it should, for that file only, switch to a different compilation mode — a mode that already exists as a code base, because it’s what the old compiler did.

If he had done it that way, wretches like me wouldn’t have to thrash around for hours trying to make things like Consolidated Multiple Actions work. I’m told Graham teaches at Oxford. Perhaps the words “ivory tower” would not be misplaced here.

Scatter

Having cut my teeth on Adventure back in the early days of desktop computing, I’m comfortable with and partial to parser-based interactive fiction. Apparently the new version of Twine has some very nice point-and-click hypertext features, but that whole way of interacting with the story seems too passive to me. The attraction of IF is, I think, that the fictional world of the story has a sense of mystery and discovery. You don’t know precisely what will work and what won’t, until you try it.

Personally, I’m partial to the TADS 3 authoring system, and in particular to Eric Eve’s adv3Lite library for T3. But Inform 7 remains the more popular authoring system for several reasons, some of them good, some of them not so good.

Back in 2009 I wrote The Inform 7 Handbook, an alternative to the official documentation. It’s now quite out of date. Possibly I ought to be thinking about rewriting it. So today I’ve been having a fresh look at I7.

If you’re new to the whole idea of IF authoring, what follows will make very little sense to you. Sorry about that.

I7 provides, by design, a bare-bones world model. The model includes some strikingly powerful features, such as scenes and regions, but there’s a lot that it doesn’t do. Graham Nelson’s intention in making this design choice was to encourage third parties to write extensions for the I7 language. This both streamlined his own already Sisyphean task and encouraged the growth of a community.

Numerous authors have created and uploaded I7 extensions; I’ve written two myself. By including an extension such as Bulky Items or Exit Lister in your source code, you can produce a text game that more nearly approaches your vision of how you want your interactive story to be presented. You don’t have to know how the extension works — just put the line “Include Exit Lister by Eric Eve” at the top of your story, and you’re jammin’.

Sounds great. There is, however, a fly in the ointment.

Inform 7 has gone through several versions during the past ten years. As a result, extensions written for earlier versions quite likely won’t work with more recent versions. This is especially true with respect to I7 version 6L02. Released in May of 2014, 6L02 was a major upgrade. (The current version, 6L38, is mostly a maintenance release.)

Not infrequently, the author of an extension doesn’t upgrade it to work with the new version of I7. Possibly the author has lost interest in interactive fiction, or is simply too busy. For whatever reason, functionality that an author might like to employ by using an extension may be difficult to gain access to.

The Inform 7 website has a long page devoted to extensions, complete with download links. Unfortunately, this page is entirely out of date. None of the extensions that work with 6L02 and 6L38 are to be found there, and most of what’s there won’t work with the latest version(s). Technically, it’s possible that an author who is still using 5Z17 or some other earlier version might want to have access to the old extensions, but basically the I7 site is now riddled with digital rot.

Some of the new extensions are in a github repository. Others are on IF star author Emily Short’s website. But the I7 website itself won’t tell you how to find any of them. (Nor does it mention that the contents it does provide are nearly useless.)

Edited to add: The best way to get a functional pile of extensions is to make sure you don’t have any (at least not where Inform can find them) before installing 6L38. Then use the Public Library page of the IDE to download the new ones with a single click. This works pretty well, though in my preliminary testing I find that the compatibility is not complete. [End of edit.]

It’s possible to download an outdated extension and edit it yourself so that it works with the new version of Inform — but instructions on how to do that are not to be found in the I7 documentation. In particular, older extensions sometimes use a type of widget called a procedural rule. Procedural rules were deprecated a couple of years ago, and they’re now no longer supported at all. So how would the author who wants to use a given extension edit it so as to get rid of the procedural rules?

Don’t ask me. I have no clue.

I was able to update my Notepad extension for 6L38 compatibility quite easily. All I had to do was delete the word “indexed” about ten times. Other extensions will require more labyrinthine revision. I’ve also updated Secret Doors by Andrew Owen, a very nice (and old) extension.

The interactive fiction community is all-volunteer. Nobody is getting paid for maintaining code; nor for maintaining a website. As frustrating as the situation is with respect to I7 extensions, there’s nobody to blame. Okay, we could mildly suggest that Graham Nelson really ought to update his own website, but hey — he has a day job. He has already done tons and tons of hard work that we can all take advantage of for free. Would it make sense to kvetch because he’s let the website slide, or would that just be bad manners?

Maybe instead of rewriting my Handbook, I ought to corral the scattered extensions, fix the most useful ones, test them thoroughly, and upload a zip file containing 30 or 35 assorted items. That might make a good project for this month.

Footnote: Keyword Interface by Aaron Reed is one of the nominally compatible bunch (available as part of the Public Library) that doesn’t exactly work. I now have it sort of halfway working, but a couple of features are not active. I’ve sent an email to Aaron. If I wasn’t down with a bad cold this week, I’m not sure I’d bother. Maybe I would.

Virtual Snapshots

Time for a tiny bit of boasting. In the course of working on my upcoming much-too-large text adventure game (“The Only Possible Prom Dress,” look for it before the end of the year, I hope), I decided the player character was going to need a digital camera. Implemented as a cell phone, obviously.

Using Eric Eve’s adv3Lite library for TADS 3, I managed to create a cell phone with which you can snap a photo of any object in the game, and then read a list of the photos you’ve taken. (Because reading is all you can do in a text game — there are no images.) This is kind of cool, and it’s less than obvious how to do it. Dynamically created objects and all that.

The game, if it’s ever finished, is going to be a sequel to “Not Just an Ordinary Ballerina,” my first game, which was released back in 1999. Same location, but greatly elaborated. Similar plot premise. Lots of new characters. A few of the puzzles are related to those in the first game, but most are completely new.

More Fun with Software

I happen to be involved in two software-heavy pursuits — electronic music and writing interactive fiction. The differences between the two fields may be of interest to nobody but me, but this is my blog, so here goes.

The software in both fields is sophisticated and feature-rich. But there’s at least a hundred times more activity in electronic music than in IF authoring. In IF, we have probably seven or eight developers, total, who are actively maintaining authoring systems. If you want to do creative work as an IF author, you’ll be using the tools uploaded by one of these kind and generous souls.

There are two main reasons for this. First, the audience for electronic music is at least ten thousand times larger than the audience for interactive fiction. Second, writing IF is much harder than laying out music in a digital audio workstation, so the number of people who even consider writing a text game is very small. The number who ever finish and release their games is even smaller.

The audience for IF is small for two reasons: First, if you want to play a computer game, you’ll probably get more excitement out of a game with video and music. Beyond that, though, playing a text game requires that you think. Few people think while listening to music … or at least, they don’t think about the music.

I’m grateful every day to the developers for producing such wonderful tools. On the IF side, Mike Roberts and Eric Eve are my heroes. On the digital audio side, there are too many heroes for me to list them all, but sound designers like Eric Persing and Howard Scarr would be high on the list, as would Ernst Nathorst-Böös, whose steady hand on the helm has turned Reason into such an amazing music program. Keep up the great work, guys!

Too Many Puzzles

Once in a while I get bored with life in general, and with composing electronic music in particular. At times like this, my mind drifts off in the direction of interactive fiction. I start to wonder, would I enjoy writing a new text adventure?

Yesterday I started taking a look at Eric Eve’s adv3Lite, an alternative library for the TADS 3 authoring system. “adv3Lite” is an unfortunate name, as the project has grown well beyond its initial concept. Yes, it’s somewhat easier to work with than the original adv3 library distributed with TADS — but it also has some spiffy features not found in adv3. My initial impression is that Eric has really accomplished something with adv3Lite (more especially as Graham Nelson appears to have lost interest in supporting Inform 7). Eric has written a number of games, and he knows what’s needed.

So I’m thinking, maybe I could take this 1/4-finished game that has been languishing on my hard drive for a couple of years, recode it where necessary for adv3Lite, and finish it.

The basic difficulty with this notion is that the game is simply too large. It’s huge. It’s unwieldy. It’s bloated. We’re talking more than 80 rooms, most of them containing lots of scenery and at least one or two significant objects, and more than 75 puzzles, some of them requiring that you do several tricky things in the proper order. Even if I finish writing it, nobody is ever going to play it all the way through. Hell, not even the beta-testers (assuming I could recruit a couple of them) would have the patience to play it all the way through.

It’s a fun idea for a game, in my opinion. It’s a sequel to the very first game I wrote, back in 1999, “Not Just an Ordinary Ballerina.” It has more characters than “Ballerina,” more rooms, more complex puzzles, more magic, more oblique literary references — oh, and it’s a love story. Sort of.

Finish it? What a depraved idea.

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