A few days ago I started working on a text game using Inform 7. Trying to get comfy with the language and all the lumber arrayed around it. Today I’m asking myself, would I perhaps rather write the game in Inform 6?
Inform 6 is a much simpler language, and of course we all love using the latest sophisticated tools. I’m as guilty of that tendency as anybody. The thing is, though, there isn’t a darn thing in the story I’m envisioning that couldn’t be structured perfectly well in Inform 6. So does that additional layer of complexity actually gain me anything?
Arguably not. By using Inform 7 I gain, it’s true, the possibility of using a nice Integrated Development Environment. But developing in Inform 6 is not actually difficult from an ergonomic standpoint: You keep the manual open in Adobe Reader and the code open in a text editor. In an OS directory window you have the batch file. Each time you want to compile the game you double-click the batch file. This is not a heavy burden.
With respect to the code itself … first of all, in principle Inform 6 can do absolutely anything that Inform 7 can do, because Inform 6 is the intermediate layer between the I7 compiler and the compiled game code. The I7 compiler doesn’t generate game code directly; it generates an I6 source code file. So by definition there is no functionality in I7 that can’t be generated within I6.
Okay, if using I7 doesn’t buy you any new functionality, what does it buy you? Certain concepts are, to be sure, easier to implement in I7. Relations, for instance. But the truth is, I’ve never used a relation while writing a game, other than the containment relation, which is a built-in. I don’t quite know why I might want to roll my own relations. There’s Eric Eve’s Conversation Framework extension — okay, that’s a plus for Inform 7, because I’d have to generate all that code myself in I6.
The downside of Inform 7 is that the language is fuzzy, convoluted, and opaque. Let’s suppose you want to enable the player to give the command, ‘bob, give me the wrench’. I7 can certainly do that, but setting it up requires several steps, scrounging around for information, and so on. In I6, you just write some code in Bob’s life routine, and you’re good to go.
Inform 7 has an active, enthusiastic community. That’s another plus. There are still a few eccentrics (even by IF standards they’re eccentrics) programming in I6, but it’s not the hotbed of creativity that it was ten years ago. Nobody is writing I6 extensions to do multi-window Glulx displays, for instance. You want to code that in I6, you’re on your own.
But I don’t care about that. I just want to tell a story.
Here’s a key difference: I6 is based on objects and functions. I7 is written using a loose aggregation of rules. If you’re trying to find out what’s going on in I6 (because it’s not producing the output you expect), you can read the library source code. And you can do that in I7 as well — open up the Standard Rules and read them. The difference is, the Standard Rules are not structured. They’re just a mad list of stuff. The structuring is done by the compiler, which assembles the rules into rulebooks based on its own fairly well defined but not always easy-to-comprehend guidelines. So after finding a rule (let’s say the block giving rule) in the Standard Rules, you also have to understand what rulebook it’s going to end up in when the game is compiled. Until you know that, you can’t modify it in your own source code. But the Standard Rules, as a document, won’t tell you what rulebook a rule will end up in — you have to know how the system works, which often means looking up information somewhere else. This is entirely different from the situation in Inform 6, because the structure of the I6 library is entirely visible on the surface.
So what’s the best option for me, right now, with this game I’ve barely started? I don’t know.
Jim Aikin's Oblong Blob 