.. highlight:: inform
+.. default-role:: samp
+
.. epigraph::
- | *G was a gamester, who had but ill-luck;*
- | *H was a hunter, and hunted a buck.*
+ | |CENTER| *G was a gamester, who had but ill-luck;*
+ | |CENTER| *H was a hunter, and hunted a buck.*
.. only:: html
.. image:: /images/picG.png
:align: left
-.. raw:: latex
-
- \dropcap{g}
-
-oing through the design of our first game in the previous chapter has
+|G|\oing through the design of our first game in the previous chapter has
introduced all sorts of Inform concepts, often without giving you much
detail about what's been happening. So let's review some of what we've
learnt so far, in a slightly more organised fashion. We'll talk about
location = before_cottage;
-to reset the value of the ``location`` variable to the
+.. Generated by autoindex
+.. index::
+ pair: location; library variable
+
+to reset the value of the :var:`location` variable to the
``before_cottage`` object, and we wrote::
if (nest in branch) deadflag = 2;
-to reset the value of the ``deadflag`` variable to 2.
+to reset the value of the :var:`deadflag` variable to 2.
Later, we'll talk about the :term:`local variable` (see :ref:`routines`)
and about using object properties as variables (see :ref:`objects`).
indeed the player herself is also an object (one that's automatically
defined by the library).
-.. todo::
+The general model of an :term:`object` definition looks like this:
- The set-off below needs to be tweaked or perhaps a custom lexer
- created to get italics in the right places.
-
-The general model of an :term:`object` definition looks like this::
-
- Object obj_id "external_name" parent_obj_id
- with property value ,
- property value ,
- ...
- property value ,
- has attribute attribute ... attribute
- ;
+ | `Object {obj_id} "{external_name}" {parent_obj_id}`
+ | `with`
+ | `{property} {value},`
+ | `{property} {value},`
+ | `...`
+ | `{property} {value},`
+ | `has {attribute} {attribute} ... {attribute}`
+ | `;`
The definition starts with the word ``Object`` and ends with a semicolon;
in between are three major blocks of information:
An object header comprises up to three items, all optional:
-* An internal ``obj_id`` by which other objects refer to this object. It's
+* An internal `{obj_id}` by which other objects refer to this object. It's
a single word (though it can contain digits and underscores) of up to
thirty-two characters, and it must be unique within the game. You can
- omit the ``obj_id`` if this object isn't referred to by any other
+ omit the `{obj_id}` if this object isn't referred to by any other
objects.
For example: ``bird``, ``tree``, ``top_of_tree``.
-* An ``external_name``, in double quotes, which is what the interpreter
+* An `{external_name}`, in double quotes, which is what the interpreter
uses when referring to the object. It can be one or more words, and need
not be unique (for instance, you might have several ``"Somewhere in the
desert"`` rooms). Although not mandatory, it's best to give *every*
- object an ``external_name``. For example: ``"baby bird"``, ``"tall
+ object an `{external_name}`. For example: ``"baby bird"``, ``"tall
sycamore tree"``, ``"At the top of the tree"``.
-* The internal ``obj_id`` of another object which is the initial location
+* The internal `{obj_id}` of another object which is the initial location
of this object (its "parent" -- see the next section) at the start of the
game. This is omitted from objects which have no initial parent; it's
*always* omitted from a room.
...
The ``tree`` starts like this; the only real difference is that, because
- the player character can't move a ``scenery`` object, it's always going
- to be in the ``clearing``::
+ the player character can't move a :attr:`scenery` object, it's always
+ going to be in the ``clearing``::
Object tree "tall sycamore tree" clearing
...
By happy coincidence, those examples also demonstrate most of the different
types of value which can be assigned to a property. The value associated
-with the ``description`` property in this particular example is a string of
-characters in double quotes; the value associated with this ``e_to``
-property is the internal identity of an object; the ``name`` property is a
-bit unusual -- its value is a list of dictionary words, each in single
-quotes; the ``each_turn`` property has a value which is an :term:`embedded
-routine` (see :ref:`embedded-routines`). The only other type of value
-which is commonly found is a simple number; for example::
+with the :prop:`description` property in this particular example is a
+string of characters in double quotes; the value associated with this
+:prop:`e_to` property is the internal identity of an object; the
+:prop:`name` property is a bit unusual -- its value is a list of dictionary
+words, each in single quotes; the :prop:`each_turn` property has a value
+which is an :term:`embedded routine` (see :ref:`embedded-routines`). The
+only other type of value which is commonly found is a simple number; for
+example::
capacity 10,
In all, the library defines around forty-eight standard properties -- like
-``name`` and ``each_turn`` -- which you can associate with your objects;
-there's a complete list in :ref:`object-props`. And in :doc:`08` we show
-you how to invent your own property variables.
+:prop:`name` and :prop:`each_turn` -- which you can associate with your
+objects; there's a complete list in :ref:`object-props`. And in :doc:`08`
+we show you how to invent your own property variables.
Object attributes
-----------------
Constant Headline
"^A simple Inform example^by Roger Firth and Sonja Kesserich.^";
-and as the value of an object ``description`` property::
+and as the value of an object :prop:`description` property::
description "Too young to fly, the nestling tweets helplessly.",
finds all the words, and they seem to represent a sensible course of
action, that's what happens next.
+.. Generated by autoindex
+.. index::
+ pair: name; library property
+
So far, we've seen dictionary words used as the values of an object
-``name`` property::
+:prop:`name` property::
name 'bird^s' 'nest' 'twigs' 'moss',
which is an example of an :term:`assignment` statement, so-called because
the equals sign ``=`` assigns a new value (the internal ID of our
-``before_cottage`` room) to a variable (the global variable ``location``
+``before_cottage`` room) to a variable (the global variable :var:`location`
which is part of the library). Later we saw::
if (nest in branch) deadflag = 2;
deadflag = 2;
-which changes the value of the library variable ``deadflag`` from its
+.. Generated by autoindex
+.. index::
+ pair: deadflag; library variable
+
+which changes the value of the library variable :var:`deadflag` from its
current value to 2. Incidentally, ``if`` statements are often written
on two lines, with the "controlled" statement indented. This makes it
easier to read, but doesn't change the way that it works::
projects / ibg.git / blobdiff