Today the topic of optimizing your Inform 7 game code so that it will run faster came up on the newsgroup (, for those of you who just wandered in from the music industry). Ron Newcomb, who knows a whole lot more about Inform than I do, had several useful suggestions. The one that stunned me was this:

Don’t use Before, Instead, or After rules if you can help it. Use Check, Carry Out, and Report.

I don’t use After rules too often, but Before and Instead rules are the meat and potatoes of action processing as it’s presented in “Writing with Inform,” the built-in documentation in the IDE. Yet Ron suggested that Instead rules are sub-optimal from a performance standpoint. If you can write a Check rule instead of an Instead rule, he suggested, you’re well advised to do so.

Only here’s where the massive edit of yesterday’s blog entry hits the pixels. Turns out he was wrong. His take on it, based on inspecting the output when you run with the ‘rules all’ command in the IDE, was that when your game is running, Inform will consult every single Before and Instead rule in response to every single command the player gives. If you’ve written 200 Before and Instead rules, that would amount to 200 extra, superfluous function calls, or whatever the Inform equivalent is.

That’s true up to a point. Vaporware chimed in, however. (That’s a nom-de-pixel. I forget his real name. Jesse something.) He suggested that as Instead rules begin to pile up in your game code, the compiler will optimize the code, packing a bunch of them into a rulebook so they can be consulted more quickly. And by doing a little testing, I was able to verify that. So, uhh, never mind.

On modern computers, of course, things happen so quickly that the slow-down caused by a bit of unnecessary rule-checking would be invisible. But: We’re now starting to see a new generation of Javascript-based interpreters that run in Web browsers. And while Javascript is fast enough to run a text game, it’s grindingly slow compared to a free-standing interpreter like Zoom.

Ron’s other suggestions undoubtedly have some value, but the performance improvements are unlikely to be dramatic. (If you want to see a real performance improvement, you might try switching to Inform 6. On the other hand, that suggestion is based on hearsay. I haven’t bench-tested it.)

Inform 7 is not a simple piece of software, and the pool of people who know it inside out is small. Ron wrote Inform for Programmers, which is a good reference source, though it’s now two versions behind the times and mentions at least one syntax option that is now deprecated. In any event, he doesn’t know every detail of what the compiler is doing. Since the compiler is not open-source, so this is not totally surprising.

The confusion was cleared up pretty quickly. All the same, I sometimes feel that Inform has slipped off into the deep end of the pool. Other recent events have tossed bits of tinder on the ever-smoldering fire of my cynicism.

Last night I was looking at the new chapter in “Writing with Inform,” which is called “Advanced Phrases.” I couldn’t make heads nor tails of it. It read like the Old Testament in Coptic. I’m sure it all makes perfect sense … to Graham Nelson and possibly to several other people. But given that Inform is an authoring system that aims to bring new authors into the field of IF by providing simple, friendly programming tools, and given also that I’ve written two complete Inform games and also a 280-page Handbook on basic programming in Inform, the fact that I can’t fathom a chapter in the manual would seem to indicate … well, we can interpret it in several ways. Possibly that chapter makes perfect sense, but I’m slipping off in the direction of early-onset senile dementia, or am just too darn impatient to read it carefully. Possibly Graham Nelson (whose manual for Inform 6 was a gem of lucidity) has forgotten how to write good documentation. Possibly he’s just too darn busy to do so. Possibly the new features discussed in that chapter are an outgrowth of his fascination with “natural language” programming syntax, and are not something that most authors will ever need or want to use. Or possibly Inform itself, as a programming language, is just too complicated for its own good.

It’s great that Inform now has a public bug tracking page. Among other things, this alerts authors to potholes in the sidewalk that might otherwise cause them hours or days of gnawing frustration. But when I scan the list of reported bugs, some of the things I see are discouragingly basic. Inform is a complex system, and arguably each new release ought to be more thoroughly tested, in order to avoid the kinds of problems that are cropping up. Or alternatively, a new build ought to be released every few weeks, in which the reported bugs are stepped on and squashed. That would be nice, wouldn’t it?

What with one thing and another, I’m still feeling a bit non-plussed. But maybe that’s just me. I want to like Inform, honestly I do. There’s a lot to like. But I can’t help wishing there were fewer complicating factors.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s