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