Six years ago I wrote an unauthorized book-length manual called The Inform 7 Handbook. There were (and still are) some things I liked about Inform 7, an authoring system for text adventures, but I didn’t feel its built-in suite of documentation was very well organized. So I wrote an alternative.
Inform 7 (called I7 by the tiny coterie of people who have even heard of it) has been updated several times in the intervening years. By now the Handbook is seriously out of date. A few months ago I started working on a revised edition, but before long I got annoyed with a couple of the more glaring limitations of I7. So I set it aside.
Last week two things happened. I learned that a guy had actually taken the old Handbook (which was only ever a PDF) down to his local print shop and had a spiral-bound copy printed up. This made me proud but also sad, because it’s not a very useful document. Mere days thereafter, Emily Short, who is an I7 developer and guru, stepped up to the plate and fixed the main problem that had gotten me annoyed.
So I took a deep breath and started working on the Handbook again. But then …
I had written and released, five or six years back, a couple of extensions for I7, including one called Spellcasting. The idea of extensions is that they add functionality to I7. Anybody can download an extension and use it, and it adds new features that some authors will find useful. Spellcasting was designed to allow the author to set up a system of magic spells — magic words that the player of the game could use to perform cool actions. This is not a very advanced concept, but I added a couple of features, such as the idea that the player would have to learn a spell before being able to use it.
Spellcasting was also seriously in need of an update. So I tackled that as a side project. And promptly hit another snag.
It occurred to me that it would be nice if the player could command another character in the story to cast a spell. For instance: BOB, CAST FROBOZZ AT THE DRAGON. In itself, this is not difficult to set up. But there’s a wrinkle. We can imagine several ways to cast the frobozz spell — several different commands the player might type (ignoring, for the moment, the idea of commanding Bob to do it). The player might simply type FROBOZZ or CAST FROBOZZ without specifying what to cast the spell at. Or the player might type FROBOZZ THE DRAGON as a shorthand version of CAST FROBOZZ AT THE DRAGON.
Again, this works fine. It’s not hard to set up. But the command BOB, FROBOZZ THE DRAGON fails. There is simply no quick way to get Inform 7 to implement that command syntax using the revised code I’ve been working on for my extension. Nor will BOB, FROBOZZ work as a command to Bob to use the spell without casting it anywhere in particular.
This happens because I7 is looking for a verb after the noun of address and the comma. BOB, PICK UP THE ANVIL works nicely, because PICK UP is understood as a verb. But I had implemented FROBOZZ (and other possible spells) as nouns, not verbs. When the game parser sees BOB, <NOUN>, this input from the player triggers a conversational action called “answering it that.” The noun isn’t even seen as a noun, just as a string of text, which presumably would be part of a conversation the player character is having with good old Bob.
Okay, there’s a workaround. But it’s ugly. To set up the game so that BOB, FROBOZZ will work, the author has to make the word frobozz both a noun (an object in the model world of the game) and also a verb. Separately. To create one new magic word, the author has to write a bunch of redundant code. And each new magic word will require its own bunch of code. My revised extension can’t short-cut this process in the way that the original version did, by handling all of the magic words within one block of code.
This is as good an illustration as any of why I get so frustrated with Inform 7. Getting started as an I7 author is easy, but doing sophisticated things with it can turn out to be a pain in the butt.
For the benefit of the technically minded, I might explain that I7’s “kinds” (which is what other programming languages refer to as classes) can be derived from only four basic kinds — room, thing, direction, and region. You can’t define a kind of action. I’d like to be able to write “spellcasting is a kind of action,” so as to set up some stuff that will be used only by the spellcasting actions created in conjunction with the extension. But the compiler won’t let me do this. Nor will it let me write, “An action has some text called default-output.” Thus the basic functionality of a spellcasting action can’t be embedded in the action itself; it has to be written up in a separate list of rules.
“An action can be learned or unlearned”? Nope — the compiler won’t allow that either. In order to track whether each type of spell has been learned by the player character, the author has to create an in-game object to hold the data. At which point, it’s up to the author to keep the frobozzing action coherent with respect to the frobozz object.
It’s certainly possible for an author to manage all this — but why should I bother to write an extension, when I can’t offer the author any viable shortcuts? Inform 7 is like a kitten with diarrhea. It’s not just cute, it’s adorable. But do you really want it sitting on your lap?