Back in June, I started a post on interactive fiction this way: “For the past few months I’ve been pretty much ignoring interactive fiction, but that may be changing.” In January, I started a post this way: “After ignoring interactive fiction for a couple of months, I’m drifting back in that direction.” Those have been my two most recent posts on IF.
It’s a good thing I took a look through recent history, or I would have started this post the same way. Periodically I get interested in IF, but it’s been a couple of years since I actually wrote a game. (“A Flustered Duck” won the 2009 Spring Thing competition.)
I have other absorbing interests, so I’m easily distracted. But I think the problem runs deeper than that. There are three principal development systems for IF — Inform 7, TADS 3, and Inform 6. None of them is entirely satisfactory. There are also half a dozen other systems swarming around the fringe, and they’re even less satisfactory.
At the moment, most of the authors have pitched their tents in the Inform 7 camp. Inform 6 probably has a few more aficionados than TADS 3, but the numbers are vanishingly small. (There was one T3 game in this year’s IFComp, and it was a tiny one.)
Inform 7 has a handsome cross-platform development environment. Unfortunately, I dislike its “natural language” syntax, which is full of bizarre and cumbersome workarounds.
TADS 3 is easily the most powerful of the three, and it’s not too difficult to use, but you can play Inform games (either 6 or 7) in a web browser. T3 has no equivalent deployment system. This makes it a poor choice. In addition, the T3 development environment, a program called Workbench, is Windows-only. It sort of runs on MacOS if you use Crossover, but it’s only about 99% compatible, and that last 1% does make a difference. Sometimes I like using my Mac — what can I say?
Inform 6 is a splendid compromise … except when it’s not. Technically, you can do quite a lot in I6 to create a user-friendly experience for your players. You can design a game with multiple windows, graphics and sound, clickable links, and so on. But the methods for doing this are poorly documented.
For the last couple of days I’ve been trying to put together what should be a simple user interface concept: Certain words in the room description are clickable links, and when you click them, it’s the same as typing a certain command. If the room description says, for instance, “A path leads _east_,” then clicking on the word “east” should have the same result as typing “go east” at the prompt.
I can’t figure out how to make it work. There are at least two websites (both of them ten years old) that purport to give instructions, and even after consulting those sites, I still can’t make it work.
I’m pretty sure I’d have an easier time setting up such a system in Inform 7. I know it would be easy in TADS 3. Maybe I’m just being stubborn. But on the whole, I like Inform 6. It was the first IF programming language I learned (back in 1998). It’s very straightforward, yet it can be extended in numerous useful ways.
Now if only someone would tell me how to make the damn links work properly….
Footnote: 24 hours later, I have the clickable link commands working. But now, every time I resize the game window by dragging an edge with the mouse, the test game that I’m running re-issues the last command given to it. I can’t see anything in my code that would cause this weird behavior. This kind of thing is an energy drain. You want to just get on with the creative work, but until the framework is in place, it’s hard to be certain that your creative effort will be rewarded with an actual finished, polished game. Feh.
Jim Aikin's Oblong Blob 
Clickable links is a good idea. I’m totally new to writing IF so I have no idea how it would be implemented in Inform though.
Inform 7’s natural language thing is nice for beginners like me, but I sometimes wish I could switch between ‘normal’ programming (in the style of C++ or Python) and the natural language parser.
I agree — the Inform 7 language syntax gives newcomers a very friendly way to get started. (I’ve written a book-length tutorial that might help too. It’s at http://www.musicwords.net/if/i7hb.htm.) And the IDE is wonderful.
Getting started with TADS 3 requires more mental effort, because for one thing there’s just a lot to learn. I’m sure some aspiring IF authors are intimidated by its C++ style syntax. And if you use a Mac, you’ll find that the T3 Workbench is only about 99% functional under Crossover. (It doesn’t remember your preferences between work sessions, for one thing.)
Nonetheless, it’s clear that T3 is more powerful and more stable. And you might be surprised at how close its code is, at times, to natural language. Here’s an example:
roomBeforeAction {
if (gActionIs(Yell))
failCheck (‘Better not. You’d wake the princess. ‘);
}
Aside from the “g” in gActionIs, a prefix that is used across a number of global macros, every word in that should be readable even if you’ve never seen TADS code before. A roomBeforeAction runs within the room before any player action is attempted, so the room can intervene if desired. failCheck is an often-used macro that prints out a message and then stops the action. Pretty simple.
Ah. I’ve done C++ so that’s all right. TADS syntax does look quite friendly from that short snippet, though I imagine it’d take a while to get used to the idea of a roomBeforeAction.
That’s a really helpful book, thanks!
Come on Jim. Yes you can write an arbitrary TADS 3 code snippet that appears easy to read, but such a feat is likely impossible for any large chunk of TADS 3 code. As you say, there is a LOT to learn with TADS 3, and without that depth of learning, the code is not very easy to read. As nearly as I can tell, the same thing can be said of Inform 6. In this single regard, Inform 7 comes out ahead.
As they say, “That’s why God made horse races.” Everybody gets to have their own opinion about which horse is fastest.
There are other factors to consider besides readability. I7’s automatic indexing is very nice, but you have to put all of your source code in a single long file, which is not so nice when you’re trying to edit two or three chunks that are widely separated. In T3, each chunk can be in its own file, so you can hop back and forth quickly using the tabs in Workbench.
In I7, you can strew your rules out wherever you like, putting closely related rules in widely different places, and the compiler will attempt (not always successfully) to put them in a rulebook in a sensible order. Because T3 is object-oriented, you pretty much have to put all of the code that relates to a given object in that object — that is, in a single block. Not only does this promote readability, it eliminates confusion about what order the compiler chose when it assembled your rules into a rulebook.
Another factor to consider is that T3 code is all in one language. The syntax is uniform from top to bottom. To do complex things in I7, you have to use I6, which has a completely different syntax. This, I would argue, reduces the readability of I7 code in a significant way.
Oh, and one more thing: T3 is more thoroughly documented than I7.
This is not to say that I7 isn’t the right choice for some authors. Clearly it IS the right choice for some authors. I would suggest, however, that its initial allure is, to some extent, cosmetic rather than substantial.