The Gameshelf

Aaron has not written a reference manual, nor a tutorial, nor has he duplicated the standard I7 manual. What he's written is example code -- except it's example code that covers the entire game-creation process, step by step, from the first room up to a finished game. By the time you reach the end, you will have had a tour of I7's core features. But it's all driven by "What do I add next to this game?"

This gives the reader an unusual progression of topics: first objects, then relations, descriptions, actions... Traditional programming constructs like if-statements and variables don't show up until halfway in. This may infuriate readers with a traditional programming background. But then, maybe not. The point of this approach is to explain constructs as they're needed, and you can frame out an awful lot of an Inform game without using a global variable. (Okay, "if" is more crucial. But the sorts of conditionals that are most common in I7 -- conditional text and rule conditions -- do show up earlier. They're just not presented in the context of old-school statement-by-statement imperative programming.)

To be sure, the standard I7 manual (which comes built-in with the I7 IDE) tries to use the same model. It, too, offers topics in the order that an I7 programmer might need them. However, without the underlying structure of the game-in-progress, that sequence can seem opaque. Aaron's sample game... well, pun not intended, but it provides the narrative for his manual.

More important: the game, Sand-dancer, is a good game. It is not the sort of example that exists to have one of everything in the manual. It is the sort of game that exists to make IF better. Aaron puts it together on your workbench. You can see the parts going in, and I don't mean rules and action constructs now; I mean character, background, voice, theme, and narrative drive. He explains what he's doing, and what each game element is for. He talks about story structure and shape of interactivity. He discusses what you have to do to get the player involved and what you have to do to put the player in control.

You'll come out the far side of this book with a clear view of what goes through an IF author's head. I won't go so far as to say this is a platform-neutral IF writer's guide. It's about Inform 7, and it spends most of its time teaching you to program in Inform, not to design IF games in general. But if you're an absolute newcomer to the field -- if you have no idea of what this medium is good for, or why anybody bothers -- you could get worse introductions than Aaron's book.

(Or you could play Sand-dancer right now, in your web browser. The source code is also available -- complete, or as of each chapter of the manual's construction process.)

My reviewer's license (nice wallet-sized card, laminated, hologram seal -- ask me sometime) says that I should pick some nits before I go. Well, the "tip" icon -- for highlighted "tip!" paragraphs, you know -- is a weird-looking black light bulb. That's not a nit. The nit is about the "caution" icon, which seems to be a dead alien vampire baby head. I guess those do make me cautious, so it makes some sense. Maybe?

Really, my only complaint is that it's not always clear when Aaron is teaching you his own personal I7 usage style.

For example -- sorry, I'm going to lapse into I7 technicalities for a moment -- Aaron claims that "instead" rules are always for specific situations, and "check" rules are for changing default behavior. Well, you can do it that way. Indeed, the built-in I7 manual makes the same claim -- but neither book digs into the reasons why that might be true. The fact is simply that an "instead" rule bypasses the "check" rules; so if there's a conflict, "instead" takes precedence. You will often want specific checks to take precedence over general ones, but not always. There's a lot of ways you could use this tool, and the book doesn't go into many of them. Is this a fault? Of course not; the book could be twice as long and not detail half of I7's subtleties. But I'd have appreciated a hand waved in the general direction.

Or too: The book leans heavily on the slightly-cutesy mnemonic BENT, for "bracket every notable thing". This is Aaron's proffered solution to the problem of under-implemented objects in games. Basically, you write each room description in such a way that the compiler nags you to implement all the objects (if only minimally). As a solution to a specific problem, it's fine. Is it the most urgent problem for students of IF, and is it the most comfortable solution? Is it what they need to be nagged about? I'm not convinced. But of course, I'm a crotchety old IF guy and my habits are set. Don't put me in front of students.

Really, any programming guide will teach you the author's programming style. Especially in a bactrian programming language (which I7 very much is).

(Eh? Bactrian, as in there's always (at least) two ways to hump your pack across the desert. As opposed to a serpentine programming language, in which there's just one way to slither through, no side limbs. Got it? Good.)

But now the reviewer's license is satisfied; it's cooling down from its red heat with faint pops and pings; I can go back to praising the book.

So yeah. Creating Interactive Fiction with Inform 7, by Aaron Reed. Cool-looking book. Also worth reading.

Aaron Reed provided a free review copy of his book for The Gameshelf. It didn't actually arrive until after I posted this review, though. I bought my copy off B&N like a regular schlub.