The long-awaited open-source version of Inform 7 has now been released. (Yay, I guess.) For those who don’t know what this means, Inform is a specialized programming language designed for writing text adventure games, a medium that is often dignified by referring to it as interactive fiction.
I’ve written and released a couple of games in Inform 7 (I7 for short), but it’s not my preferred development system for this type of writing. I much prefer TADS 3, which I use with Eric Eve’s brilliant adv3lite library. I7 code tends to be rather verbose, and for technical reasons compiling your work-in-progress (in order to test the stuff you’ve just spent the last half-hour writing) takes longer in I7 than in T3. It’s faster than it used to be, but compiling is still a bit of a bottleneck.
On the other hand, I7 is by far the more popular developmental system. If you write a game and then enter it in one of the yearly competitions, you’ll probably get more players and better voting results with an I7 game, because players will feel more comfortable when they see the familiar .gblorb file extension.
There are other factors to consider. The tools for making your I7 game playable in a web browser are more robust. Also, the I7 IDE (that’s the host program in which you do your writing) has some nice features. It builds a topic-by-topic index of your source code, for instance.
On the downside, the documentation for I7 is rather awful. It tries hard to be friendly for the novice, and as a result it generally fails to explain anything in detail. Eric Eve’s documentation for TADS 3 is brilliant. In addition, the underlying code for the library (the stuff you need to use in order to write a game, such as the definition of how a Room object works) is extremely opaque in I7. In T3, on the other hand, the library source code is both clear (because it’s written in the same code language as the game you’re writing) and provided with very detailed comments. With a little study, you can tell exactly what the library is doing.
Or consider something like creating non-player characters (NPCs) whose behavior can change during the course of a game. T3 includes some lovely features for doing that. I7 has nothing comparable.
I’ve written a whole handbook on how to write games in I7 (patterned, I might add, on Eric’s book-length tutorials on T3). With the new release I should probably update my handbook. Some people have found it a useful document. And the most practical way to research updates for the handbook would be to actually write a game in the new version of I7.
Now we get to the conundrum. I have an unfinished game. It’s written in T3/adv3lite. It has been sitting on my hard drive for at least ten years now, in one form or another. And an imp sitting on my shoulder is whispering, “You really ought to finish ‘The Only Possible Prom Dress.'” Now and then the imp jabs my earlobe with his tiny pitchfork. So maybe I ought to take what I’ve written and port it over to Inform 7. Do you think?
But wait — don’t answer quite yet.
Porting a bunch of code from one programming language to another would be a big job in any case, but it’s swollen to unimaginable proportions by the fact that this game is huge. About 70 puzzles, more than 100 rooms, and several hundred objects if you include the scenery.
It’s by way of being a sequel to the first game I ever wrote, “Not Just an Ordinary Ballerina,” back in 1999. It uses the same setting, but with many new rooms. It uses the same plot device, but reworked. A few of the puzzles are similar, but most of them are entirely new. There are now seven or eight complex and chatty characters (NPCs), none of whom was in the original version. There is an octopus, a Lamborghini, and my favorite (?) wizard, Zarbolphung, he of the filthy mustache and the hideously gnarled toes, who first appeared in my I7 game “A Flustered Duck.” There is a hostile ocelot, a wooden Indian, a depressed art gallery owner, a thoroughly annoying beautician, and a singing fish.
Fitting all of these elements together in a tidy way is a big job. Each time you add a new action (such as, perhaps, “set fire to the newspaper”) you have to consider how else players may attempt to use the “set fire to” action in any other context in the game. You have to provide sensible non-default responses for dozens of possible “set fire to” actions. Now multiply that by ten or twenty new actions. And then start working on the built-in Hint system. With 70 puzzles, that’s at least 500 hints.
The story still has some rough edges. It’s not entirely clear to me, for instance, what happens if you succeed in enticing a certain character to join you in a certain location before you’ve befriended and/or recruited a couple of other characters. Conceptual barriers have to be erected so as to keep the player from going too far off track, but those barriers have to be designed in such a way that they’ll appear natural, not forced or contrived.
And then … then, after all that, the game is finished. Except, it’s not. Not even remotely. It’s ready for testing. No matter how careful you try to be while writing it, all software contains bugs. Not infrequently, the bugs are fatal. The game may crash, or the story may get itself into an unwinnable condition. Absurd, nonsensical responses to player input are going to pop up like toadstools.
So beta-testers will need to be recruited. And this is where the skid marks run straight through the guard rail and off the cliff. Did I mention that the game is huge? Finding a couple of beta-testers who will work their way through the whole damn thing is about as likely as waking up tomorrow morning to find that the Second Amendment has been repealed overnight. A consummation devoutly to be wished, as saith the poet, but don’t be holdin’ your breath.
Releasing a game that has not been thoroughly tested is not a nice or friendly thing to do. Still, it’s an awfully fun story, and I like having a good meaty creative project to work on. Maybe if I offer to pay the testers….
Update: After five days of hard work, I’ve gotten a good start on porting the existing code over to I7. Along the way, however, I’ve rediscovered in painful detail exactly why I dislike Inform 7. Again and again I bang my head against the fact that you really can’t tell whether you’re using the correct syntax in your code. In a real coding language, you can write…
if X > Y { }
…and the meaning is clear. (The curly braces surround the stuff that will happen if the logical test is true.) But how do you do that in Informese? Is that “if X is greater than Y”? Is it “if X is more than Y”? Or can I write “if X > Y”? This is a simple example. It can get more complicated.
Even aside from the syntax tangles, porting a game is not an automatic process! It mostly means creating a new object in I7 using the correct syntax, block-copying texts (such as the description of a room) over to I7 and then manually reformatting the text, and possibly redesigning a couple of the more complex puzzles. The game was less than half finished in T3, and just getting it all ported over would take several weeks.
I’m not sure I’m going to bother. I think I’m going to stick with the TADS version. Maybe finish it, finally. Because TADS is just a better programming language, frankly. Not only is it natively better, but Eric’s adv3lite library includes some spiffy features of I7 that were not included in the original TADS adv3 library — things like scenes, regions, and variable text output markings.
I wonder how Eric is doing. I haven’t exchanged emails with him for a couple of years now. We collaborated on writing a game, some years ago. It’s called “Mrs. Pepper’s Nasty Secret.” You can find it online.
Jim Aikin's Oblong Blob 