Brass Lantern
the adventure game web site

Search

Introducing Inform 7

by Stephen Granade

The Language

The Library

IF systems are often judged on their library—the included code that defines types of objects (known as classes in most languages and as kinds in I7). The I7 library is pared down. It has fewer than twenty kinds such as doors, containers, persons, and devices. Furthermore, each kind can only be a specialization of one other kind. You can't have multiple inheritance as in other languages. Each kind can have lesser kinds and so ad infinitum in a single chain. New kinds are defined by telling I7 what they're a specialization of, and optionally what extra characteristics define this kind.

A bed is a kind of supporter. A bed is always enterable.

There is a system for including extensions, and the manual includes copious examples that can be incorporated into a game.

Grouping Things Together

I7 has mechanisms for grouping things together to make them easier to refer to. Spatially, the game is divided into rooms, which can be lumped together into regions. This can be used to have objects that only appear in certain regions, like having a ceiling that only appears in indoor regions and a sky that only appears in outdoor ones, to give a trivial example. It can also be used to confine effects to certain rooms, as in a policeman who only enters rooms that are part of his beat.

Temporally, the game is divided into turns, which can be grouped together as scenes, as if in a play. As in a play, you can define changes to the game world which occur when a scene ends and a new one begins: you can move objects on and off stage, as it were; you can move NPCs around; and more. For instance, my game Losing Your Grip is divided into five acts, with multiple versions of some acts. In I7 these acts could be defined as scenes, with conditions determining when a scene begins and, when necessary, which of the possible scenes occurs. Attached to each scene would be the directions defining what objects needed to be moved around, where the player should be moved, and more.

The Front End

Along with the language overhaul, I7 introduces a specialized front-end development environment available for Macintosh and Windows computers. The front end is not like many other IDEs. It has a number of tools that are specifically designed for IF development.

I7 takes the concept of a book as its metaphor. Rather than dividing your source code up into individual files, you write in a single stream of text that is optionally divided by volume, section, and chapter headings. The I7 front-end manages projects so that you don't have to worry about where files are kept within the project itself.

The Index helps manage this code. It collates information about your game and makes it available in an organized fashion. It has a table of contents that allows you to jump directly to specific volumes, chapters and sections in your code. It creates a map of the game world for you. It lists all rules and provides links to where they are defined in your game or are explained in the manual. It gives all possible actions in the game. It lists the kinds defined by your game and by the library, as well as the specific objects of each kind. In short, it lists most everything about your game in a condensed and categorized fashion.

The front end will let you compile and replay a game using the exact same commands as you used during a previous play-through. Furthermore, it keeps track of every command you've used in playing the game, and presents the commands in the Skein. The Skein is a tree view of the commands, branching every time you entered a different command than you did on a previous play-through. You can name branches of the tree for easy reference, and by double-clicking on a node you will play through the game using all the commands in the branches leading to that node.

Furthermore, I7 keeps a transcript of these playthroughs. You can "bless" a transcript as being the correct one, and any deviations from it are then shown in red. This allows you to quickly identify any unexpected changes in your game due to code tweaks.

Once you're ready to release a game, the front end can do a lot of the preparatory work for you. As part of your game code, you can define cover art and other files to distribute with the game and, upon compiling for release, information will be placed in the release file that mentions those other files. You can have the front end generate an HTML webpage for downloading your game, suitable for uploading to your website. You can use the Skein to generate a walkthrough file automatically, complete with annotations. The Index's world map can, with some tweaking, be released as a bitmap or EPS file. You can even have all of your game's source text included automatically with the files to be released.

I7 and Inform 6

You can write an I7 game without knowing how to write Inform 6 code at all. That's not to say that I7 isn't related to Inform 6. The I7 compiler converts its source code to Inform 6 source code, then lets the Inform 6 compiler turn the game into its final form. I7 is thus built on top of I6 in the same way that Rome rests on the bones of its past.

If I7 is built on top of I6, can you get access to I6 within I7 code? Yes. You drop down into I6 by surrounding your I6 code with "(-" and "-)".

To end the game in death: (- deadflag=1; -).

You can use small snippets of I6 code, as above, or include entire routines. This can be useful for programming tasks that are much more easily handled in a procedural language such as I6.

The drawback to doing so is a loss of readability: much as when you embed assembly directives in C, you now need to understand two very different languages. You can encapsulate I6 code and give it a natural-language form; in fact, parts of the I7 standard library do just that.

Next | 1 | 2 | 3 | 4

About Us | Contact Us | Technical Info | History
Copyright © 1997-2010, Stephen Granade.