5 ========================
7 ========================
11 .. image:: /images/picD.png
18 uring our travels, we've encountered certain terms which have particular
19 significance in the context of the Inform text adventure development
20 system; here are brief definitions of many of those specialised words and
26 The generated effect of the player's input, usually by the
27 :term:`parser` but also occasionally by the designer's code. It
28 refers to a single task to be processed by Inform, such as DROP
29 KETTLE, and it's stored in four numbers: one each for the action
30 itself and the ``actor`` object who is to perform it (the player or
31 an :term:`NPC`), one for the ``noun`` -- or direct object, if
32 present -- and a fourth for the ``second`` noun -- if it exists, for
33 example the "POT" in THROW KETTLE AT POT. See also :term:`fake
37 The testing which is carried out by the game's :term:`designer`, in
38 a futile attempt to ensure that it does everything that it should
39 and nothing that it shouldn't. See also :term:`beta-testing`.
42 A parameter supplied in a call to a :term:`routine`, which is the
43 actual value for one of the routine's defined local variables. For
44 example, the argument is 8 in the call ``MyRoutine(8)``. The
45 definition of the routine includes the variable that will hold the
46 argument, in this case ``x``: ``[ MyRoutine x; ... ];``
49 See :term:`text file`.
52 A statement which sets or changes the value of a :term:`variable`.
53 There are three in Inform: ``=`` (set equal to), ``++`` (add one to
54 the current value), ``--`` (subtract one from the current value).
57 Named flags that can be defined for an object after the keyword
58 ``has`` . An attribute is either present (on) or not present
59 (off). The designer may test from any other part of the program
60 *if* an object *has* a certain attribute, *give* an attribute to an
61 object or take it away as need arises. For instance, the attribute
62 ``container`` states that the object is capable of having other
63 objects placed inside it.
70 Information about a game which is displayed at the start of play.
73 The testing which is carried out by a small band of trusted
74 volunteers, prior to general public release, during which the gross
75 inadequacy of the designer's :term:`alpha-testing` effort becomes
80 A computer file containing binary data -- 0s and 1s -- which is
81 created by a program and which only a program can understand.
84 Used to highlight a term explained in this glossary.
87 See :term:`object tree`.
90 A special :term:`object` template from which other objects can
91 inherit :term:`properties` and/or :term:`attributes`. The template
92 must begin with the word ``Class`` and must have an internal
93 identifier. Objects that wish to inherit from a class usually
94 begin with the internal ID of the class in place of the word
95 ``Object`` , but may instead define a segment ``class`` followed by
96 the class's internal ID. The designer may test whether an object
97 belongs to -- is a member of -- a class.
100 See :term:`statement block`.
103 Text which starts with an exclamation mark ``!`` and which is
104 ignored by the compiler when it reads the :term:`source file`;
105 added to improve the file's layout or for explanatory notes.
108 The time when the :term:`compiler` is at work making the
109 :term:`story file`. See also :term:`run-time`.
112 A program that reads the source code written by the designer and
113 turns it into a :term:`story file`, which can then be played by a
114 Z-machine :term:`interpreter`.
117 A particular value which is defined at :term:`compile-time`, always
118 stays the same and cannot be changed while the game is being
119 played. Common examples include numbers, strings and the internal
120 IDs of objects, any of which can be either written out explicitly
121 or set as the value of a named ``Constant``.
124 A option which causes to compiler to include extra code into the
125 story file, thus making it easier for the designer to understand
126 what's happening while a game is being tested prior to release.
127 See also :term:`Strict mode`.
130 A person who uses Inform to create a text adventure game: in other
131 words, gentle reader, you.
134 The collection of all input words "understood" by the game.
137 A word written in single quotes '...' within the :term:`source
138 file`, usually (but not exclusively) as one of the values assigned
139 to an object's ``name`` property. All such words are stored in the
140 :term:`dictionary`, which is consulted by the :term:`parser` when
141 attempting to make sense of a player's command. Only the first
142 nine characters are significant (thus ``'cardiogram'`` and
143 ``'cardiograph'`` are treated as the same word). Use
144 ``'coins//p'`` to mark "``coins``" as plural, referring to all coin
145 objects which are present. Use ``'t//'`` to enter the
146 single-character word "t" into the dictionary (``'t'`` is a
147 constant representing a character value).
150 A line of Inform code which asks the :term:`compiler` to do
151 something there and then, at :term:`compile-time`; typical examples
152 are to Include the contents of another file, or to set aside some
153 space within the story file where a variable value may be stored.
154 Not to be confused with a :term:`statement`, which asks the
155 compiler to compose an instruction which the interpreter will obey
156 at :term:`run-time`; typical examples are to display some text, or
157 to change the value held within a variable's storage space.
160 A general-purpose program for creating and modifying :term:`text
164 A routine that is defined in the body of an object, as the value of
165 one of its :term:`properties`. Unlike a :term:`standalone
166 routine`, an embedded routine doesn't have a name of its own, and
167 returns ``false`` if execution reaches the terminating marker
171 One of a predefined list of optional routines which, if you provide
172 it, will be called by the library either to produce some
173 supplementary output or to return a value causing the library to
174 change its default behaviour.
177 An action generated indirectly by the library rather than directly
178 by what the player types. For example, PUT X IN Y triggers a real
179 action of Insert (which can be intercepted by X) and a fake action
180 of Receive (which can be intercepted by Y).
183 A logical state which is the opposite of :term:`true`, represented
187 A variable which can take only two possible values.
193 A variable not specific to any routine or object, which can be used
194 by any routine in the game.
197 The process by which an :term:`object` belonging to a :term:`class`
198 acquires the properties and attributes of said class. Inheritance
199 happens automatically; the designer has just to create class
200 definitions, followed by objects having those classes.
203 A program that reads the :term:`story file` of a game and enables
204 people to play it. Interpreters must be platform-specific (that
205 is, they will be different programs for each operating system),
206 thus allowing the story file to be universal and
207 platform-independent.
210 Used for emphasis, and as a placeholder to represent a value which
214 A group of text files, part of the Inform system, that includes the
215 :term:`parser`, definitions for the :term:`model world`, language
216 files, grammar definitions and a customised stock of default
217 answers and behaviour for the player's actions. The library will
218 make frequent calls to the game file to see if the designer wants
219 to override those defaults.
222 The actual files containing the source code of the library. There
223 are basically three (although these three Include other files as
224 well): ``parser.h`` , ``verblib.h`` and ``grammar.h``, and they
225 should be Included in every Inform game.
228 One of a set of routines included as part of the library which the
229 designer can call to perform some commonly useful task.
232 A variable which is part of only one :term:`routine`; its value
233 remains unavailable to other routines in the game. The value of a
234 local variable is *not* preserved between calls to the routine.
237 The imaginary environment which the player character inhabits.
240 The ASCII control character(s) used to mark the end of a line of
244 A non-player character; any character other than the protagonist.
245 Could range from an opponent or love interest to a pet gerbil or a
249 A group of :term:`routine`\s and variables bundled up together in a
250 coherent unit. Objects represent the items that make up the
251 :term:`model world` (a torch; a car; a beam of light; etc.), a fact
252 which organises the designer's code in sensible chunks, easy to
253 manage. Each object has two parts: the header, which comprises the
254 internal ID, the external name and its defined parent (all fields
255 are optional), and the body, which comprises the property variables
256 and attribute flags particular to that object, if any.
259 A hierarchy that defines objects' relationships in terms of
260 containment. Each :term:`object` is either contained within
261 another object -- its parent -- or is *not* contained; objects such
262 as rooms which are not within another object have the constant
263 ``nothing`` (0) as a parent. An object contained within another is
264 a child. For example, a shoe inside a box: the box is the shoe's
265 parent and the shoe is a child of the box. Consider now this box
266 being inside the wardrobe. The box is a child of the wardrobe, but
267 the shoe is still a child of the box, not the wardrobe. In a
268 normal game, the object tree will undergo many transformations as
269 the result of the player's activities.
272 See :term:`object tree`.
275 Part of the :term:`library` which is responsible for analysing the
276 player's input and trying to make sense of it, dividing it into
277 separate words (verb, nouns) and trying to match them against the
278 words stored in the game's :term:`dictionary` and the actions
279 defined in the game's grammar. If the player's input makes sense,
280 the parser will trigger the resulting :term:`action`; if not, it
281 will complain that it didn't understand.
284 1. a personal computer;
285 2. the player character (see :term:`player`).
288 1. the final user of the game, normally a person full of radical
289 opinions about your capabilities as a designer;
290 2. a variable referring to the :term:`object` -- sometimes known as
291 an "avatar" -- which currently represents that user within the
295 A customised rule to apply while in a ``print`` or ``print_ret``
296 statement, to control the manner in which an item of data is to be
297 displayed. For example: ``print (The) noun, " is mine."`` is
298 telling the game to use a capitalised definite article for the
299 noun. The library defines a stock of print rules, and designers
300 may create some of their own.
303 Variables attached to a single :term:`object`, of which they are a
304 part. They are defined in the body of the object after the keyword
305 ``with`` and have a name and a value. The latter (which defaults
306 to 0) can be a number, a string "...", a dictionary word '...' or
307 an embedded routine ``[;...]``; it can also be a list of those
308 separated by spaces. The value of an object's property can be
309 tested and changed from any part of the game. The fact that an
310 object provides a property may be tested.
313 The ``rec.arts.int-fiction`` Usenet newsgroup for IF designers.
317 The ``rec.games.int-fiction`` Usenet newsgroup for IF players.
320 An :term:`object` which defines a geographical unit into which the
321 map of the :term:`model world` is divided. Rooms have no parent
322 object (or, more precisely, their parent object is ``nothing``) and
323 they represent the places where the player character is at any
324 given moment -- the player character can't be in more than one room
325 at a time. Note that the name "room" does not imply necessarily
326 "indoors". A clearing, a sandy beach, the top of a tree, even
327 floating in outer space -- these are all possible room objects.
330 In general terms, a routine is a computer program that makes some
331 specific calculation, following an ordered set of instructions;
332 this is the only unit of coherent and executable code understood by
333 Inform. More practically, a routine is a collection of
334 :term:`statement`\s which are written between markers ``[...]``.
335 When a routine is "called", possibly with arguments -- specific
336 values for its defined variables, if they exist -- the interpreter
337 executes the statements in sequence. If the interpreter encounters
338 a ``return`` statement, or reaches the ``]`` at the end of the
339 routine, it immediately stops executing statements in the routine
340 and resumes execution at the statement which called that routine.
341 Every routine returns a value, which is either supplied by the
342 return statement or implied by the ] at the end of the routine.
343 See :term:`embedded routine` and :term:`standalone routine`.
346 The period of time when the :term:`interpreter` is running a
347 :term:`story file` (that is, someone is playing the game). See
348 also :term:`compile-time`.
351 A text file containing your game defined using the Inform language.
354 A routine which is not part of an object. Unlike an
355 :term:`embedded routine`, it must provide a name of its own, and it
356 returns ``true`` when execution reaches the terminating marker
360 A single instruction to be executed at :term:`run-time`. See also
364 A group of :term:`statement`\s bundled up together between braces
365 ``{...}``, which are then treated as a single unit -- as if they
366 were only one statement. They commonly appear in loops and
370 A binary file which is the output of the :term:`compiler` and can
371 be played through the use of an :term:`interpreter` (also known as
372 Z-code file or game file). The format of story files is standard
373 and platform-independent.
376 An option which causes the :term:`compiler` to include extra code
377 into the story file, thus making it easier to detect certain design
378 mistakes while a game is being played.
381 A piece of text between double quotes "...", to be displayed for
382 the player's benefit at :term:`run-time`.
385 1. an optional keyword or symbol to operate special features of the
387 2. a statement which decides among different paths of execution
388 according to the value of an expression.
391 A computer file containing words and phrases which a human can
395 A logical state which is the opposite of :term:`false`, represented
396 by any value other than zero (typically 1).
399 A named value which can change during :term:`run-time`. It must be
400 declared before use, either as a ``Global`` variable (available to
401 any routine within the game), or as a local variable (part of one
402 specific routine and usable by that routine alone). Variables have
403 a name and a value; it's the value which is capable of change, not
404 the name. Object :term:`properties` behave as variables.
407 See :term:`story file`.
410 A virtual machine (an imaginary computer simulated by the
411 :term:`interpreter`) on which story files run. Z stands for
412 "Zork", the first ever Infocom title.