Thoughts on I7

Until now I've been presenting the facts about I7. In this section I give you my thoughts on the language and system.

Natural Language

In many respects, I7 is the anti-Perl. It's easy to write Perl code that you're unable to read two days later without a lot of thought. Contrariwise, you need know very little about I7 to read a game's source and understand large swaths of it, regardless of how familiar you are with the code to begin with. This can lull you into believing that your knowledge of I7 is much larger than it is, until you trip over syntax details when you try to write your own game. It's very much like playing IF in that respect: you have to learn the conventions of English that I7 uses. Because of this, the IF community may be far more receptive to I7's natural language approach than other communities would be of a similar language.

Programming languages don't typically employ natural language, or even a subset thereof. Natural languages are considered too verbose and imprecise to be truly usable. Graham addresses these concerns in his paper on I7, "Natural Language, Semantic Analysis and Interactive Fiction," with mixed success. To address the issue of verbosity, he gives a carefully-chosen example that is concise. While that shows that I7 can be concise, it doesn't show whether on the whole the language is verbose. I don't believe it's overly verbose, and I'm willing to put up with that for the improved readability. As for imprecision, Graham cites scientific papers and medical prescriptions as examples of precise documents written in natural language. Perhaps, but the best examples of making natural language precise are legal documents, where pages and pages are spent on removing ambiguities.

To my mind, the major benefit of the language is how easily it allows simple syntax to express complex situations and conditions. Once you have defined relations and actions, assigning verbs to them, the language to use them becomes simple. Consider the code example I had given earlier:

For this code to work, all I need to do is define the relation "can detect".

Speaking of which, relations are a wonderful part of the language. By taking common IF relationships between objects such as "is contained within" and abstracting them, I7 allows for new relationships that aren't necessarily physical. This has some benefit for physical relations about inanimate objects, but is most useful for relations that can change without direct player input, like a character's knowledge or feelings about the player and other characters.

At first I was suspicious that I7's natural language would slow down my ability to write I7, and would be better suited to the less-hard parts of writing IF, such as setting up rooms and descriptions. By now I'm sold on its ability to handle more complex situations. There is a power and elegance in this approach.

That's not to say that I7's natural language is always powerful and elegant. It occasionally gives way to more traditional programming. The most obvious example of this is in how arrays are handled. Arrays are created by putting together a table of values.

To loop through a table, you must use a looping procedure:

While readable, this is in no way natural language.

Basing I7 on English has one unavoidable side-effect: porting it to other languages will be difficult. While all of the text that the player sees can be re-written in another language with moderate effort, porting the entire I7 language itself to, say, French would involve so much work that I'm doubtful it will occur.

Rules and the Library

I7 has a skeleton for building up complex rules but a relatively simple world model underneath. A more complex or simulationist set of rules will either have to be coded by an author, included through third-party extensions, or taken from the large set of examples that are throughout the manual. This is the opposite approach of a language such as TADS 3, which has a very large and interrelated library that provides a tremendous amount of simulation right out of the box. Whether this is a good thing or not depends on your preference for having libraries provide a lot of what you need at the expense of having a lot of things you don't need.

Building up all of these rules is surprisingly easy. In my experiments with I7, I've only run into a few cases where I couldn't figure out how rule interactions would play out. I7's guesses are mostly right. The times I did have problems, though, I ran into I7's limited debugging capabilities. If you use the commands "RULES" or "RULES ALL" in a play-through, I7 will print out your new rules as they occur, but the result is not as useful as a full debugger would be.

The Front End

The GUI, despite some quibbles that I will touch on shortly, is wonderful. My first reaction to the Replay, Skein and Transcript functions was to stare at them, open-mouthed, while thinking, "Why hasn't anyone thought of doing this before?" Those three elements alone make repetitive testing of games much easier. When I was writing Losing Your Grip, I hand-created testing walkthroughs and used the Unix diff utility to compare the resulting transcripts, so that I could see if any code changes I made had broken the game unexpectedly. I7 automates all of that. The only change I'd like to see is the ability to hide skein branches, as the skein becomes unworkably large over time. Even with labels I find it hard to work with as time passes and the skein grows.

Having the source code as one long file of text frustrates me in ways that are difficult to explain. My guess is that, by breaking code into separate files, I'm able to compartmentalize my mental map of the code. With all code in a single file, I found myself losing my view of the game's structure despite the volume and chapter markings and the Index, much as if I was rising higher and higher above my source to keep it all in view, distance obscuring detail. This might be alleviated if the GUI allowed me to collapse headings to hide their associated code.

Conclusion

Inform 7 is a new and exciting approach to writing IF. It is a sharp departure from Inform 6 and from other languages such as TADS and Hugo. The most extreme changes are its use of a subset of English as its programming language and its abstracting the game world's logic as a set of rules. Both of these allow complex situations to be expressed simply and powerfully. The tools that are available under Windows and Mac are incredibly useful for creating IF, though the lack of a true debugger is a weakness. I believe that I7 will be well-suited for IF writers who are less familiar with traditional programming languages, but still of great use for those who are experienced programmers.

One of the most interesting things about I7 is how it provides authors with a meaningful choice of IF languages that goes beyond the aesthetics of the code. In recent years we've seen the proliferation of large simulationist libraries such as that of TADS 3. I7 takes the opposite approach, providing a minimalist library coupled with a rules-based framework. Given a form-driven language like ADRIFT, a traditional IF language with strong multimedia support like Hugo, an object-oriented language with a massive library like TADS 3, and I7, authors can choose a language that best fits their game and prefered working style.