=============
Our starting point is much the same as last time. Here's a basic
-``Tell.inf``::
+``Tell.inf``:
+
+.. include:: /config/typethis.rst
+
+::
!% -SD
!===========================================================================
Why not do that with the player? Because the object which represents
the player is defined by the library (rather than as part of our
- game), and actually has an internal ID of ``selfobj``; :var:`player`
- is a variable whose value is that identifier. Rather than worry all
- about this, it's easier to use the ``move`` statements.
+ game), and actually has an internal ID of :obj:`selfobj`;
+ :var:`player` is a variable whose value is that identifier. Rather
+ than worry all about this, it's easier to use the ``move`` statements.
There's one other task associated with the quiver; it's an article of
clothing which Wilhelm is "wearing", a state denoted by the attribute
quiver ~worn`` -- read that as "give the quiver not-worn"; Inform often
uses ``~`` to mean "not".)
+.. Generated by autoindex
+.. index::
+ pair: description; library property
+
* If the player types EXAMINE ME, the interpreter displays the
:prop:`description` property of the :var:`player` object. The default
value is "As good-looking as ever", a bit of a cliché in the world of
attributes are optional and can be omitted if there's nothing to be
specified. Now that the :attr:`light` attribute is being provided
automatically and there aren't any other attributes to set, the word
-``has`` can be left out. Here's the class again::
+``has`` can be left out. Here's the class again:
+
+.. include:: /config/typethis.rst
+
+::
Class Room
has light;
besides. Here's a ``Prop`` class (that's "Prop" in the sense of a
theatrical property rather than a supportive device), useful for scenic
items whose only role is to sit waiting in the background on the off-chance
-that the player might think to EXAMINE them::
+that the player might think to EXAMINE them:
+
+.. include:: /config/typethis.rst
+
+::
Class Prop
with before [;
return true;
],
-The role of that original :prop:`before` was to intercept ``Listen``
+.. Generated by autoindex
+.. index::
+ pair: Examine; library action
+ pair: Listen; library action
+
+The role of that original :prop:`before` was to intercept :act:`Listen`
actions, while leaving all others well alone. The role of the
:prop:`before` in the ``Prop`` class is broader: to intercept (a)
-``Examine`` actions, and (b) all the rest. If the action is ``Examine``,
-then the ``return false`` statement means that the action carries on. If
-the action is ``default`` -- none of those explicitly listed, which in this
-instance means *every* action apart from ``Examine`` -- then the
-``print_ret`` statement is executed, after which the interpreter does
-nothing further. So, a ``Prop`` object can be EXAMINEd, but any other
-action addressed to it results in a "no need to worry" message.
+:act:`Examine` actions, and (b) all the rest. If the action is
+:act:`Examine`, then the ``return false`` statement means that the action
+carries on. If the action is ``default`` -- none of those explicitly
+listed, which in this instance means *every* action apart from
+:act:`Examine` -- then the ``print_ret`` statement is executed, after which
+the interpreter does nothing further. So, a ``Prop`` object can be
+EXAMINEd, but any other action addressed to it results in a "no need to
+worry" message.
That message is also more involved than anything we've so far displayed.
The statement which produces it is::
display the following object's internal ID, is called a :term:`print
rule`.
+.. Generated by autoindex
+.. index::
+ pair: self; library variable
+
* There's a library variable :var:`self` which always contains the internal
ID of the current object, and is really convenient when using a
``Class``. By using this variable in our ``print_ret`` statement, we
A class for furniture
---------------------
+.. Generated by autoindex
+.. index::
+ single: NPC
+ pair: static; library attribute
+
The last class for now -- we'll talk about the ``Arrow`` and ``NPC``
classes in the next chapter -- is for furniture-like objects. If you label
an object with the :attr:`static` attribute, an attempt to TAKE it results
in "That's fixed in place" -- acceptable in the case of Heidi's branch
object (which is indeed supposed to be part of the tree), less so for items
which are simply large and heavy. This ``Furniture`` class might sometimes
-be more appropriate::
+be more appropriate:
+
+.. include:: /config/typethis.rst
+
+::
Class Furniture
with before [;
PushDir: print_ret (The) self, " is too heavy for that.";
],
+.. Generated by autoindex
+.. index::
+ pair: PushDir; library action
+
but since we're giving exactly the same response each time, it's better to
-put all of those actions into one list, separated by commas. ``PushDir``,
-if you were wondering, is the action triggered by a command like PUSH THE
-TABLE NORTH.
+put all of those actions into one list, separated by commas.
+:act:`PushDir`, if you were wondering, is the action triggered by a command
+like PUSH THE TABLE NORTH.
Incidentally, another bonus of defining classes like these is that you can
probably reuse them in your next game.
projects / ibg.git / blobdiff