Creating Interactive Fiction with Inform 7, by Aaron Reed. Cool-looking book, eh? It's been out for a few weeks, and I haven't seen a review beyond short "this book is awesome!" posts. I finished reading it last week. I ought to write a review.
This book is awesome, and... hm. What is it? Hm. Okay, what isn't it?
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.
Comments imported from Gameshelf
Irfon-Kim Ahmad (Sep 21, 2010 at 1:59 PM):
I'm not very far through the book thus far, but I like the approach a great deal as well. I really think it's a fantastic book as far as I've read.
If I had any complaints, it's that it tries to straddle a line between developing an example game and having you do exercises that involve you in the process in a way that I find imperfect. When I read through the processes and techniques, what I really want to be doing is trying them on a game of my own, following along with my own project. Of course, nothing's preventing me from doing so, but there's always the thought that if I don't follow along by developing Sand Dancer, then I might not wind up developing the hooks that later parts of the project wind up hanging on. On the other hand, if I follow along with Sand Dancer, it works well from a general learning perspective, but I feel kind of at a loss when I'm prompted to add in details of my own, because I'm not invested in the game at all, especially when I'm instructed to be careful to think about how my additions work to achieve the right tone for the game -- I have no idea what tone the game is supposed to have or what details will run counter to that.
That's a pretty minor nitpick, though.
leandro ribeiro (Sep 27, 2010 at 5:00 PM):
I don't know nearly as much I7 as it is necessary to write a proper review of this title, but I'll add this to yours: Reed's book reads like a book, not like a manual; doing such while remaining focused and technically accurate, is quite something...
ZUrlocker (Oct 6, 2010 at 8:54 PM):
Good, detailed review. I wrote up a shorter item about Aaron's book here. http://www.z-machine-matter.com/2010/10/aaron-reed-inform7.html
guild wars 2 gold (Nov 23, 2010 at 9:22 AM):
On the other hand, if I follow along with Sand Dancer, it works well from a general learning perspective, but I feel kind of at a loss when I'm prompted to add in details of my own, because I'm not invested in the game at all, especially when I'm instructed to be careful to think about how my additions work to achieve the right tone for the game