A Little Box Full of Shiny Gears

For the past few months I’ve been pretty much ignoring interactive fiction, but that may be changing.

My dissatisfaction with IF has several roots. First, it’s very much a marginal field of creative endeavor: The number of people who care about it (or have even heard of it) is tiny, and not likely to grow. If I’m indulging in some sort of grandiose idea that I want my creative work to be appreciated by an audience of any appreciable size, IF is not going to be my first choice, nor even my second or third.

More important, perhaps: Although I’ve written half a dozen IF games, I don’t get much pleasure from playing the games written by others. I enjoyed playing “Zork” back in the ’80s — but there were several other things that floated my boat back in the ’80s that I no longer indulge in (and no, you’re not going to get any details).

I try dutifully. I played some of the Comp games last year, or at least started some of them. Sometimes I volunteer to beta-test other authors’ work because it gives me an excuse to sit down and put a game through its paces even if I’m not really enjoying it. But mostly I get bored pretty quickly. This is not necessarily a criticism of other authors’ work; it’s more a criticism of the medium itself. Interactive fiction is a medium that, by design, frustrates its audience. This is not a good thing.

There’s also a rankling and contagious dissatisfaction in the fact that I just plain don’t like Inform 7. Inform 7 is far and away the most popular authoring system for IF. I’ve written two complete games using it, one short and one long. I’ve even written a couple of extensions, which you can download from the I7 website. In spite of all that, I7 is a poor fit for me. I may write about that another time; at the moment it’s just a data point.

Last week, though, I read a comment (I wish I could remember where) to the effect that what’s fun about being a hobbyist programmer is that you get to solve a long series of intriguing little problems. Puzzles, if you like. And I thought, “Aha!” Perhaps because of a confluence of factors in my personal life, it struck me powerfully that having a hobby that allows me to create and solve my own puzzles is a good thing. I don’t have to enjoy playing IF to enjoy writing it. I don’t even have to care whether anybody plays the games I write.

Naturally, I try to make my games playable and enjoyable. But that’s just one room in the puzzle palace: How do you make a given game scenario, or a given in-game object, interesting and fun to interact with?

So I have this half-finished game that has been sitting on the hard drive for six or eight months. Actually, I have two versions of it, which are basically the same game scenario. I started it in Inform 7 and then ported it to Inform 6. Neither version is finished.

The reason I switched to Inform 6 was because (a) I dislike Inform 7 and (b) Inform games (either 6 or 7) can be played in the Quixe interpreter, which runs in your favorite web browser. Inform games can be played, that is, without downloading and installing a separate interpreter program. In theory, this fact will increase the popularity of IF. If I care about reaching an audience, I should stick with Inform 6.

I6 is a fairly simple, yet fairly effective authoring system. I’ve written a couple of games in it too. But as the scenario of my new game developed, I6 got to be not so much fun to use. The technical term is “spaghetti code.” I was writing a lot of long routines full of if-tests, switching a lot of variables that kept track of the state of the model world, and so forth. I sensed that the game was going to be very difficult to test, because it could get itself into so many logical states. So I set it aside.

But Inform is not the only authoring system on the block. This week, feeling a need for distraction (and not having cable TV), I started re-reading Learning TADS 3, a book-length tutorial by Eric Eve. I’ve written a couple of games in TADS 3 as well. One was a collaboration with Eric, in fact.

It may seem insane to take a half-finished game that has already been ported from one authoring system to another and start porting it to yet a third system, but that’s what I’ve been doing. And I’m having fun again. All of a sudden I’m solving little puzzles of my own creation, one after another.

Along the way I’m starting to make a few improvements in the game. Minor ones, so far. But T3 sort of invites you to design your game in sophisticated ways. I’ve got four characters running around on a small island, and with the tools in T3 I can let each character manage his or her own agenda of activities. That is, I’m writing all of their agendas — the character objects don’t actually get to improvise. I can structure the code better, that’s all.

It has to be said, though, that there’s a tremendous advantage in already being familiar with T3. It’s not a simple authoring system at all. On the contrary: It’s dauntingly complex. I’m a bit rusty, but I know where to look for information in Learning TADS 3. Once in a while I turn to Eric’s Tour Guide instead. Certain topics are discussed more fully in the System Manual. And knowing how to use the Library Reference Manual is essential. The writing process is, at this stage, almost half research.

TADS 3 is a brilliantly designed authoring system. (Mike Roberts is the author, and they ought to give him a Macarthur genius grant.) It’s like a little box full of hundreds of shiny brass gears, all turning at once. Until you start to understand where the linkages are, though, every time you stick a screwdriver into the box the gears will jerk to a halt, and it will drive you nuts.

At one point tonight I hit Ctrl-F5 to compile and run my game, and immediately hit a fatal bug. The development environment reported a Nil Object Reference, loaded the file where the problem popped up, and pointed an arrow at the offending line. Naturally, the offending line wasn’t in my code, it was in one of the T3 source files. So I stared at the source file, thought about what a Nil Object Reference might be, and then went back and stared at the code I had just written. The error jumped out at me: I had forgotten to put a plus sign in front of an object declaration.

The point of this story is not to bore you with obscure references to T3 coding. The point is, I had a little puzzle to solve, and I was able to solve it. This is very gratifying. And since TADS 3 is a system that requires a certain level of dedication and expertise (I like to call it “the IF authoring system for grown-ups”), I got to congratulate myself on being able to arm-wrestle an expert programming system and win.

Oh, by the way: All of these authoring systems are free, and there’s good support from an active user community. If you’re looking for a creative outlet, email me and I’ll tell you more.