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.