This is a review, mixed up with a description of some of my own experiences, of a language for writing interactive fiction games, called Inform 7. Perhaps I will start by saying something about interactive fiction.

My first experience of interactive fiction was playing a game called The Hobbit on the Commodore 64. At the time, it presented me with a wonderful illusion of complete freedom within a computer game, unlike anything I'd played before. The games I'd played up until that point had mostly understood five instructions, being the four directions available on the joystick, and the fire button. You could move around, and you could shoot things. The Hobbit was different, because you could write in anything you could think of; the main frustration with this was that it was slow and then a lot of the time what you could think of wasn't something you could actually do. Trying to look through a high window, I tried to write something like "jump up and look through the window", only to be told "I don't understand what you mean" or words to that effect. Still, I enjoyed The Hobbit for a long time, although I never did finish it -- I think it wasn't really designed to be winnable by small boys, unlike Archon and Gridrunner and various other entertaining distractions I enjoyed at the time.

I won't go into my full personal history of playing IF (Interactive Fiction; also called "Adventure Games" or "Text games"), except to say that that problem which I first experienced with The Hobbit turned out to be something which was there through all the various IF games I played for a long time. One would be moving along through some kind of story, at various points being interrupted by puzzles, only to arrive at a puzzle which I could think of a solution for, but for which the program wouldn't understand my explanation of my solution. I became less interested in IF games as other types of games began to give me a stronger sense of being immersed in a world which the player could interact with freely and meaningfully. Ultima 6 and The Mines of Moria were probably the games that signposted the end of the road for my love of IF.

It was a long time after that, that I came across a little IF game called Photopia. This wonderful little game was different than any other IF game I'd played for several reasons. One, it was free -- I'll get back to that part in a minute. Two, it was short -- you could play through the whole thing in one brief sitting. Three, most importantly, there were no puzzles. The interest in the game came not from being able to "beat" the game and finish it, but from the characters and the story -- quite a beautiful, touching story, and very well written.

It was free principally because of the work of Graham Nelson, an Oxford mathematician. Nelson wrote a language for creating IF games, called Inform, which he gave away for anyone who wanted to to use. (There had been a long line of such languages, the best of which was TADS, but all of them had cost money in one way or another, which meant that the pool of potential authors was limited. In response to Inform being freely available, TADS and several other systems were soon free, too). The free availability of Inform, along with the growing access to the internet, meant that a small but lively community of IF authors soon developed. One of the best of these authors was Adam Cadre, who wrote Photopia, the game that lead to me discovering all of this.

Well, ever since I first played computer games I had entertained fanciful notions of creating them myself. BASIC had allowed me to write very short multiple-choice "games" (Go left or right? Left. You fall into a spiked pit and die horribly!) but that was as far as I'd ever been able to get. The prospect of being able to write any kind of game -- even if IF games were no longer really my favourite genre -- was thrilling. Besides, the example of Photopia had inspired me with the thought that the frustrations and limitations of games like The Hobbit could be transcended, if the author knew what they were doing.

Sadly, I soon discovered, the author did not know what he was doing. By which I mean, once I started trying to write games in Inform, I found that anything much more complicated than laying out a fixed map of static, empty rooms was beyond my programming skill. Perhaps if I'd had more time, patience, maturity... but I didn't. Making interesting games was much, much easier than it would be without Inform to help me, but it was still more difficult than I could manage. Other languages (such as ADRIFT) would have made it possible for me to make games, but the limitations of the language left me feeling very uninspired; none of the ADRIFT games I played had anything like the complexity or sophistication of the best Inform or TADS games.

Fastforward to the present moment. (Here's where the review starts, by the way.) Nelson has again done a wonderful thing. Inform has been updated to a new version, Inform 7. (There have been suggestions that this iteration of Inform is so different from the previous version that it ought to be called something else, like "Ocelot" or "Teacup", both of which I think are fine names, but still, "I7" has quite a nice ring to it, too). When I started looking at some of the source code for I7 games, I was shocked. It was as though Nelson had written this language with the exact purpose in mind of trying to solve the problem I'd run into with I6 the last time. I won't show you an example of I6 code, but suffice it to say that for a nonprogrammer like me it looked a lot like any other source code does; weird brackets and semicolons all over the place, in arrangements that I could see were probably logical but, alas, with the specifics of that logic entirely escaping me. Take a look, then, at the following scrap of I7 source code:

"Midsummer Day"

The Gazebo is a room.

Guess what? That will compile and run. That's a complete game. Of course, it's not a very interesting game. However, given that it takes all of three seconds to type out, you wouldn't really expect it to be. What's really interesting about it, though, is that someone who knows and understands nothing about programming can read it and know exactly what it will do. Compile and play it, and you get a transcript that looks something like this:

Midsummer Day

An Interactive Fiction

Release 1 / Serial number 061110 / Inform 7 build 3T38 (I6/v6.31 lib 6/10N) SD

Gazebo

> look

Gazebo

> inventory

You are carrying nothing.

> go north

You can't go that way.

Well, that's very nice for setting up rooms, but what about a game that actually does something -- this is where the millions of nested brackets and incomprehensible DO R$ FOR I = 1 TO 20 stuff starts, right?

"The Undertomb"

A dead end is a kind of room with printed name "Dead End" and description "This is a dead end. You'll have to go back the way you came, consoled only by [river sound]." A dead end is usually dark.

The Undertomb is a dark room. East is a dead end. South is a dead end with printed name "Collapsed Dead End". Northwest is a dead end called the Tortuous Alcove. In the Undertomb is the lantern. It is lit.

A dead end has a property called river sound. The river sound of a dead end is usually "a faint whispering of running water". The Tortuous Alcove has river sound "a gurgle of running water".

From which we can derive a game with the following transcript:

The Undertomb

An Interactive Fiction

Release 1 / Serial number 061110 / Inform 7 build 3T38 (I6/v6.31 lib 6/10N) SD

Undertomb

You can see a lantern (providing light) here.

> e

Darkness

It is pitch dark, and you can't see a thing.

> w

Undertomb

You can see a lantern (providing light) here.

> get lantern

Taken.

> e

Dead End

This is a dead end. You'll have to go back the way you came, consoled only by a faint whispering of running water.

If you can understand how that first scrap of writing relates to that transcript, congratulations, you are well on your way to being able to read I7 source code -- and to write it.

There's been a fair bit of argument in the IF community about I7. And in fairness I should say, games which are more complex than the two examples I've given above do, gradually, start to get more confusing to write and to read. But for me, the big thing is just that I look at that "code", which looks so much like normal English, and I think, "I can do that! I can do that right now!" And this is all that's needed in order to get started.

In fact, I did get started. I've written a short but playable game (admittedly using quite a bit of borrowed code) (but again, borrowing the code was easy because I understood what it was and what it did) which, someday after I get out of thesis hell and actually have the freedom to work on it, I intend to make into a game which is not only playable but interesting and enjoyable. And if you've ever dreamed about creating a computer game, but felt that computer programming was an impassable wall between you and that dream, I can't recommend highly enough that you download I7 and give it a go. Thanks to Nelson, that wall has become very low indeed.