Informed or Reformed?

Pardon me; I’m going to kvetch. This is sort of about computer programming, but it’s also about writing stories, so I’ll try to provide a few relevant bits of technical information along the way.

What with being stuck at home (like most of us, unless we work in a hospital or a grocery store) and being more bored than usual, I thought maybe I’d write a new text adventure game. The game I’ve worked on, off and on (mostly off) for the past few years is still as bloated and unmanageable as it ever was, so I thought maybe I’d do a new one instead. Something shorter and more straightforward.

Providentially, the yearly competition for interactive fiction, the IFComp, has a deadline at the end of September. Plenty of time to write a game and have it tested. Yowzah! Let’s go for it!

The landscape of text gaming has shifted over the past decade. Slid downhill, that may be a better way to describe it. Back at the turn of the century, parser-based games were the norm. These are games in which the user/player/reader types commands, such as perhaps HIT TROLL WITH SWORD, and the game responds in some fashion, such as “The troll easily ducks your clumsy swing and smashes your skull with his mace. *** You have died. ***”

Increasingly, though, would-be authors don’t have the patience to learn even the rudiments of computer programming. Instead, they use systems like Twine, Inklewriter, and ChoiceScript, in which the story unspools when the reader clicks a button to see what comes next. These systems are grouped under the heading CYOA (Choose Your Own Adventure), surely a finalist for the Optimistic Acronyms Award.

As a form of interactivity, CYOA is boring and trivial. On the other hand, the user interface of parser-based games is derived from the command line interface that was de rigeur on computers in 1980. Younger users are likely to be completely unfamiliar with it, and unsure what they ought to do to get the story moving. Everybody understands point-and-click, or perhaps I should say “tap.” So there’s that.

I’ve written parser-based games in Inform 6, Inform 7, and TADS 3. Of these, by far the most popular (for very small values of “popular” — interactive fiction is not taking the world by storm) is Inform 7. I prefer TADS 3, but I thought I really ought to give Inform 7 another chance, if only because the process of playing an I7 game is likely to be more seamless and familiar-looking to the people who play the competition games. And, well, it’s a very capable authoring system. It’s not crude or limited in scope.

Now for the kvetching part. After two days of starting to draft a new game in I7, I’m ready to pull the plug and switch back to T3. I’ve only started the development process, so switching now would be far easier than stalling, getting increasingly frustrated, and switching later.

The annoyances built into Inform 7 are several. In no particular order:

In I7 all of your source code is in one big file. In T3 you can split it up, for instance with your characters in one file, your map (the rooms in which the story takes place) in another file, your new actions in a third file, and your built-in hint system in a fourth file.

This fact has two consequences. First, every time you go to compile your source code, I7 has to compile the whole blessed thing from scratch. With even a smallish stub of a game that you’ve only started working on, compiling takes I7 close to 30 seconds. If you compile 12 times within a one-hour writing session, and that’s a very normal thing to do, you’ve just wasted six minutes. Compiling in T3 is faster because the compiler produces intermediate-level files and then links them together. When compiling anew, it only needs to recompile the files that have changed. Much faster.

Second, as your story grows, it gets harder to find the things you’re working on in the I7 IDE. (That’s the Integrated Development Environment.) Sure, you can put in headings and subheads, and you should, but you’ll still find yourself scrolling up and down in the file looking for the kitchen, because the character who is in the kitchen is in a different part of the file. In the T3 IDE, this is a one-click operation.

I7 generates an Index of all of the objects and headings in your source code, so in theory you can find things by clicking on items in the index. Trouble is, this feature doesn’t work worth beans. It’s based on line numbers (though line numbers are never displayed in the IDE). So if you’ve written something new near the top of the single massive source-code file, all of the linkages to the index will be horribly wrong until after you’ve recompiled, which takes another 30 seconds. Workflow? Not so nice.

The documentation for T3 is just plain better than the documentation for I7. Eric Eve wrote most of the T3 docs (as well as the alternative T3 library that I prefer), and he’s more articulate, more orderly, and more patient than Graham Nelson and Emily Short, who did the I7 docs. (Nelson is the person who created Inform.) There’s a definite gee-whiz quality about the I7 docs, a tendency to assume that the reader really doesn’t care about all the details and just wants to get going quickly. That may even be true, but when you’re looking for details it’s deadly.

The coding language of T3 is better structured and easier to read than I7 code. T3 is closely based on the syntax of C++, so things that belong together are found together in tidy blocks of code. I7 is a rules-based language, in which the compiler assembles rulebooks out of little snippets of rules that both the individual author and various developers of add-ons can strew out all over the place in whatever order or section they fancy. This becomes especially problematic when you’re trying to figure out what one of those add-ons (called Extensions in Inform-speak) is doing with its newly defined rules. You can read the source code for the Extension, but make sense of it? Maybe, maybe not.

I have more than a hundred I7 Extensions installed, written by 29 different authors. Some of them require others in order to run, so even if you can figure out the code in the one that’s puzzling you, it’s likely to relate to other stuff that you have to hunt for. The adv3Lite library for T3, in contrast, has literally everything. No extensions are needed. Also, Eric Eve grabbed good ideas from I7, such as scenes and regions, and built them into his adv3Lite library. So you really don’t lose much by sticking with T3. Except possibly users’ access to the completed game. I’m still investigating that.

Way too much I7 code is one-off syntax, designed to do just one thing — in a tidy way, to be sure, but you have to know the correct syntax for that one thing. Today I was having a problem getting a certain thing to happen in my story. The code looked fine, but it didn’t do what I wanted. So I posted a message on the forum, and someone soon suggested a way to write the code that solved the problem. What this suggestion didn’t do was inform me how the new code phrase related to what I had just tried, or didn’t. It was a one-off solution to a specific problem, so it taught me nothing that I could use elsewhere in the future.

Yes, I7 has some nice features. And T3 isn’t perfect. But the little aggravations build up.