| Chapter 2: The Source Text |

| 2.13. Limits and the Settings panel

No computer has unlimited capacity, and a large, complex project may eventually bump its head against the ceiling.

Inform is a system for translating textual descriptions of interactive fiction into "story files". No single format of story file is standard to the IF community. The formats developed over the history of IF differ in three key respects:

> - the range of computers or devices capable of playing them;
> - how large they are, that is, how much play they can express;
> - what extra-textual effects they can bring off.

Inform can write to four different formats. None of these are proprietory, and none were created by the authors of Inform: each of the formats is a community property, defined by published standards documents. Each individual Inform project has its own choice of story file format, which can be changed using that project's Settings panel.

The format normally used is known as version 5 of the Z-machine, or "z5", which is highly standardised and can be played on a very wide range of computers, including a few handheld devices. For a small or medium-sized work of IF with no need of pictures, its widespread playability almost certainly makes it the best choice. Larger works will need version 8, or "z8". For very large works of textual IF, or to introduce pictures, the best option is to switch to the Glulx format. (In principle, the Z-machine version 6, or "z6", is also capable of displaying pictures, but Inform's support for z6 is limited and Glulx is a much better option.)

Internally, the Inform application uses a tool called Inform 6 (which was once the entire Inform system) to manufacture the story file. There are therefore two ways that large projects can run out of space:

> (a) By exceeding some maximum in Inform 6, or
> (b) By exceeding some fundamental limitation of the current story file format.

In both cases, the Inform application will display a Problems page explaining that the Inform 6 tool has failed to work as intended, and refer us to the "console output" - the text produced by Inform 6 - which is normally ignored, but can be found on the Progress tab of the Errors panel.

In case (a), Inform 6 will say that a memory setting has been exceeded: it will say what this setting is called (for instance "MAX_ZCODE_SIZE") and what its current value is (for instance 50000). We can then avoid the problem by adding the following use option into the source text:

> Use MAX_ZCODE_SIZE of 60000.

And similarly for every other Inform 6 memory setting. (If the source tries to specify the same setting more than once - which is quite possible if extensions are included, with rival ideas - then the highest value is used.)

In case (b), we must either switch to a larger story file format, or economise. The simplest thing to do is to switch up from z5 to z8, and then from z8 to Glulx, until no limits are reported any more. (Glulx has a huge capacity, so we need never worry about size limits again.)

However, if we really do need to stick to a specific format - say, if we want a story file playable on a tiny handheld computer unable to manage Glulx - we still have a few options. Unless the story is very large (in which case there is little we can do), the "z8" format is most likely to be exhausted for lack of what is called "readable memory", with a message like so:

> This program has overflowed the maximum readable-memory size of the Z-machine format. See the memory map below: the start of the area marked "above readable memory" must be brought down to $10000 or less.

followed by a tabulation of how the Z-machine's storage has been used, a large but not very useful diagram. The first time one runs into the problem on a large project, it can be postponed, by adding the following to the source:

> Use memory economy.

(Economy cuts down the verbosity of some of the testing commands, but otherwise subtracts no performance.) Writing this into the source is the equivalent of a diver switching to an emergency oxygen tank: it gives us a generous safety margin, but also tells us that now is the time to wrap things up.

If we hit the problem again, genuine cuts must be made. As a general rule, the most memory-expensive ingredients of an Inform design are various-to-various relations between large kinds such as "thing" or, if there are many rooms, "room". Other than that, if a kind has been festooned with new properties and we have created dozens of items of that kind, then we can get a fairly large saving simply by doing without one of those properties; and so on.

The ultimate memory-saving device, of course, is the one used by book publishers when there are too many pages to bind: to cut the design into two stories, Part I and Part II.

Previous | Contents | Next