Contents
Back
Forward

31. Limitations on the run-time format


How wide the limits stand
Between a splendid and an happy land.

...Oliver Goldsmith (1728--1774), The Deserted Village

The Infocom run-time format is well-designed, and has three major advantages: it is compact, widely portable and can be quickly executed. Nevertheless, like any rigidly defined format it imposes limitations. These are not by any means pressing. Inform itself has a flexible enough memory-management system not to impose artificial limits on numbers of objects and the like.

Games can be compiled to several "versions'' of the run-time format. Unless told otherwise Inform compiled to what used to be called Advanced games (version 5). It can still compile Standard games (version 3) but doing so imposes genuine restrictions, and there is little point any more. Stepping up to the new version 8, on the other hand, allows much larger games to be compiled. Other versions exist but are not useful to present-day game designers, so the real decision is V5 versus V8.

Memory. This is the only serious restriction. The maximum size of a game (in K) is given by:

V3     V4     V5     V6     V7     V8
128    256    256    512    320    512
Because games are encoded in a very compressed form, and because the centralised library of Inform is efficient in terms of not duplicating code, even 128K allows for a game at least half as large again as a typical old-style Infocom game. The default format (V5) will hold a game as large and complex as the final edition of 'Curses', substantially bigger than any Infocom game, with room to spare. V6, the late Infocom graphical format, should be avoided for text games, as it is much more difficult to interpret. The V8 format allows quite gargantuan games (one could implement, say, a merging of the 'Zork' and 'Enchanter' trilogies in it) and is recommended as the standard size for games too big to fit in V5.

Grammar. The number of verbs is limited only by memory. Each can have up to 20 grammar lines (one can recompile Inform with MAX_LINES_PER_VERB defined to a higher setting to increase this) and a line contains at most 6 tokens. (Using general parsing routines will prevent either restriction from biting.)

Vocabulary. There is no theoretical limit. Typical games have vocabularies of between 1000 and 2000 words, but doubling that would pose no problem.

Dictionary resolution. Dictionary words are truncated to their first 9 letters (except that non-alphabetic characters, such as hyphens, count as 2 "letters'' for this purpose). They must begin with an alphabetic character and upper and lower case letters are considered equal. (In V3, the truncation is to 6 letters.)

Attributes, properties, names. 48 attributes and 63 common properties are available, and each property can hold 64 bytes of data. Hence, for example, an object can have up to 32 names. These restrictions are harmless in practice: except in V3, where the numbers in question are 32, 31, 8 and 4, which begins to bite. Note that the number of different individual properties is unlimited.

Special effects. V3 games cannot have special effects such as bold face and underlining. (See the next two sections.)

Objects. Limited only by memory: except in V3, where the limit is 255.

Memory management. The Z-machine does not allow dynamic allocation or freeing of memory: one must statically define an array to a suitable maximum size and live within it. This restriction greatly increases the portability of the format, and the designer's confidence that the game's behaviour is genuinely independent of the machine it's running on: memory allocation at run-time is a fraught process on many machines.

Global variables. There can only be 240 of these, and the Inform compiler uses 5 as scratch space, while the library uses slightly over 100; but since a typical game uses only a dozen of its own, code being almost always object-oriented, the restriction is never felt. An unlimited number of Array statements is permitted and array entries do not, of course, count towards the 240.

"Undo''. No "undo'' verb is available in V3.

Function calls. A function can be called with at most 7 arguments. (Or, in V3 and V4, at most 3.)

Recursion and stack usage. The limit on this is rather technical (see the Z-Machine Standards Document). Roughly speaking, recursion is permitted to a depth of 90 routines in almost all circumstances (and often much deeper). Direct usage of the stack via assembly language must be modest.

/\ If memory does become short, there is a standard mechanism for saving about 8-10% of the memory. Inform does not usually trouble to, since there's very seldom the need, and it makes the compiler run about 10% slower. What you need to do is define abbreviations and then run the compiler in its "economy'' mode (using the switch -e). For instance, the directive
Abbreviate " the ";
(placed before any text appears) will cause the string " the '' to be internally stored as a single 'letter', saving memory every time it occurs (about 2500 times in 'Curses', for instance). You can have up to 64 abbreviations. When choosing abbreviations, avoid proper nouns and instead pick on short combinations of a space and common two- or three-letter blocks. Good choices include " the ", "The", ", ", "and", "you", " a ", "ing", " to". You can even get Inform to work out by itself what a good stock of abbreviations would be: but be warned, this makes the compiler run about 29000% slower.


Contents / Back / Forward
Chapter I / Chapter II / Chapter III / Chapter IV / Chapter V / Chapter VI / Appendix
Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.