],
has scenery;
-The tree's :prop:`before` property is intercepting a ``FireAt`` action, which
-we'll define in a few moments. This action is the result of a command like
-SHOOT AT TREE WITH BOW -- we could simulate it with the statement
-``<<FireAt tree bow>>`` -- and it needs extra care to ensure that the
-:var:`second` object is a feasible weapon. To deal with silly commands like
-SHOOT AT TREE WITH HELGA, we must test that :var:`second` is the bow, one of
-the arrows, or ``nothing`` (from just SHOOT AT TREE). Since this is quite
-a complex test, and one that we'll be making in several places, it's
+The tree's :prop:`before` property is intercepting a :act:`FireAt` action,
+which we'll define in a few moments. This action is the result of a
+command like SHOOT AT TREE WITH BOW -- we could simulate it with the
+statement ``<<FireAt tree bow>>`` -- and it needs extra care to ensure that
+the :var:`second` object is a feasible weapon. To deal with silly commands
+like SHOOT AT TREE WITH HELGA, we must test that :var:`second` is the bow,
+one of the arrows, or ``nothing`` (from just SHOOT AT TREE). Since this is
+quite a complex test, and one that we'll be making in several places, it's
sensible to write a routine to do the job. Which we'll do shortly -- but
first, a general introduction to working with routines.
A diversion: working with routines
==================================
+.. Generated by autoindex
+.. index::
+ pair: each_turn; library property
+
A standalone routine, like the familiar routines embedded as the value of a
property such as :prop:`before` or :prop:`each_turn`, is simply a set of statements
to be executed. The major differences are in content, in timing, and in
control when it's called. A standalone routine, however, is completely
under your control; it runs only when you explicitly call it.
+.. Generated by autoindex
+.. index::
+ pair: false; library constant
+ pair: true; library constant
+
* If an embedded routine executes all of its statements and reaches the
final ``];`` without encountering some form of ``return`` statement, it
returns the value :const:`false`. In the same circumstances, a standalone
else return false;
];
+.. Generated by autoindex
+.. index::
+ pair: location; library variable
+ pair: self; library variable
+
However, the two routines are very similar; the only difference is the name
of the variable -- :var:`self` or :var:`location` -- which is being checked. A
better approach might be to rework our ``BeenHereBefore`` routine so that
if (BeenToBefore(location) == true) ...
+.. Generated by autoindex
+.. index::
+ pair: visited; library attribute
+
In the first line, we supply :var:`self` as the routine's argument. The
routine doesn't care where the argument came from; it just sees a value
which it knows as ``this_room``, and which it then uses to test for the
return false;
],
+ .. Generated by autoindex
+ .. index::
+ pair: true; library constant
+
On the other hand, just because a routine returns a value doesn't mean
you always *have* to use it; you can simply ignore the value if you want
to. The ``TooFarAway`` routine that we showed you earlier in this
Return to the marketplace
=========================
-After all that introduction, finally back to the ``FireAt`` action. We
+.. Generated by autoindex
+.. index::
+ pair: FireAt; library action
+
+After all that introduction, finally back to the :act:`FireAt` action. We
want to check on the characteristics of an object, possibly then displaying
a message. We don't know exactly *which* object is to be checked, so we
need to write our routine in a generalised way, capable of checking any
*Or* is it ``nothing``? Or, using the ``ofclass`` test, is it any object
which is a member of the ``Arrow`` class?
+.. Generated by autoindex
+.. index::
+ pair: before; library property
+ pair: false; library constant
+ pair: second; library variable
+
What this means is that the value returned by the call ``BowOrArrow(bow)``
is :const:`true`, while the value returned by the call ``BowOrArrow(tree)`` is
:const:`false`. Or, more generally, the value returned by the call
reacts to that value and ignores the following statements. Then
* in both cases, the ``return true`` statement terminates the object's
- interception of the ``FireAt`` action.
+ interception of the :act:`FireAt` action.
+
+.. Generated by autoindex
+.. index::
+ pair: deadflag; library variable
That whole ``BowOrArrow()`` bit was rather complex, but the rest of the
-``FireAt`` action is straightforward. Once the tree has determined that
-it's being shot at by something sensible, it can just set :var:`deadflag` to 3
--- the "You have screwed up" ending, display a message, and be done.
+:act:`FireAt` action is straightforward. Once the tree has determined that
+it's being shot at by something sensible, it can just set :var:`deadflag`
+to 3 -- the "You have screwed up" ending, display a message, and be done.
Gessler the governor
====================
],
has male;
-Like most NPCs, Gessler has a :prop:`life` property which deals with actions
-applicable only to animate objects. This one responds merely to ``Talk``
-(as in TALK TO THE GOVERNOR).
+Like most NPCs, Gessler has a :prop:`life` property which deals with
+actions applicable only to animate objects. This one responds merely to
+:act:`Talk` (as in TALK TO THE GOVERNOR).
Walter and the apple
====================
the apple was in his pocket or otherwise out of sight; the interpreter
would reply "You can't see any such thing".
+.. Generated by autoindex
+.. index::
+ pair: found_in; library property
+
Walter has a :prop:`found_in` property which automatically moves him to the
player's location on each turn. We can get away with this because in such
a short and simple game, he does indeed follow you everywhere. In a more
events in the marketplace are such that specialised responses are more
appropriate there than our standard ones.
-Walter's :prop:`life` property responds to ``Give`` (as in GIVE APPLE TO
-WALTER) and Talk (as in TALK TO YOUR SON); during ``Give``, we increment
-the library variable :var:`score`, thus rewarding the player's generous good
-nature. His :prop:`before` property is perhaps a little confusing. It's
-saying:
+.. Generated by autoindex
+.. index::
+ pair: Give; library action
+ pair: before; library property
+ pair: score; library variable
-#. The ``Examine``, ``Listen``, ``Salute`` and ``Talk`` actions are always
- available (a ``Talk`` action then gets passed to Walter's :prop:`life`
- property).
+Walter's :prop:`life` property responds to :act:`Give` (as in GIVE APPLE TO
+WALTER) and Talk (as in TALK TO YOUR SON); during :act:`Give`, we increment
+the library variable :var:`score`, thus rewarding the player's generous
+good nature. His :prop:`before` property is perhaps a little confusing.
+It's saying:
+
+.. Generated by autoindex
+.. index::
+ pair: Examine; library action
+ pair: Listen; library action
+ pair: Salute; library action
-#. The ``FireAt`` action is permitted in the ``marketplace``, albeit with
- unfortunate results. Elsewhere, it triggers the standard ``FireAt``
- response of "Unthinkable!"
+#. The :act:`Examine`, :act:`Listen`, :act:`Salute` and :act:`Talk` actions
+ are always available (a :act:`Talk` action then gets passed to Walter's
+ :prop:`life` property).
+
+.. Generated by autoindex
+.. index::
+ pair: FireAt; library action
+
+#. The :act:`FireAt` action is permitted in the ``marketplace``, albeit
+ with unfortunate results. Elsewhere, it triggers the standard
+ :act:`FireAt` response of "Unthinkable!"
#. All other actions are prevented in the ``marketplace``, and allowed to
run their standard course (thanks to the ``return false``) elsewhere.
-The apple's moment of glory has arrived! Its :prop:`before` property responds
-to the ``FireAt`` action by setting :var:`deadflag` to 2. When that happens,
-the game is over; the player has won. ::
+.. Generated by autoindex
+.. index::
+ pair: deadflag; library variable
+
+The apple's moment of glory has arrived! Its :prop:`before` property
+responds to the :act:`FireAt` action by setting :var:`deadflag` to 2. When
+that happens, the game is over; the player has won. ::
Object apple "apple"
with name 'apple',
Verbs, verbs, verbs
===================
+.. Generated by autoindex
+.. index::
+ pair: Talk; library action
+
The Inform library delivers a standard set of nearly a hundred actions
which players can perform; around twenty of those are "meta-actions" (like
SAVE and QUIT) aimed at the interpreter itself, and the remainder operate
already catered for, either by the interpreter doing something useful, or
by explaining why it's unable to. Nevertheless, most games find the need
to define additional actions, and "William Tell" is no exception. We'll be
-adding four actions of our own: ``Untie``, ``Salute``, ``FireAt`` and
-``Talk``.
+adding four actions of our own: :act:`Untie`, :act:`Salute`, :act:`FireAt`
+and :act:`Talk`.
.. rubric:: Untie
#. The ``->`` indicates an action to be triggered.
+.. Generated by autoindex
+.. index::
+ pair: Untie; library action
+
#. If players type something that matches the pattern -- one of those five
verbs followed by an object in scope -- the interpreter triggers an
- ``Untie`` action, which by default is handled by a routine having the
+ :act:`Untie` action, which by default is handled by a routine having the
same name as the action, with ``Sub`` appended. In this example, that's
the ``UntieSub`` routine.
The illustration shows four attempted usages of the new action. In the
first, the player omits to mention an object; the interpreter knows (from
-that :var:`noun` in the grammar which implies that the action needs a direct
-object) that something is missing, so it issues a helpful prompt. In the
-second, the player mentions an object that isn't in scope (in fact, there's
-no dog anywhere in the game, but the interpreter isn't about to give *that*
-away to the player). In the third, the object is in scope, but its
-:prop:`before` property intercepts the ``Untie`` action (and indeed, since this
-object is of the class ``Prop``, all actions apart from ``Examine``) to
-display a customised rejection message. Finally, the fourth usage refers
-to an object which *doesn't* intercept the action, so the interpreter calls
-the default action handler -- ``UntieSub`` -- which displays a
-general-purpose refusal to perform the action.
+that :var:`noun` in the grammar which implies that the action needs a
+direct object) that something is missing, so it issues a helpful prompt.
+In the second, the player mentions an object that isn't in scope (in fact,
+there's no dog anywhere in the game, but the interpreter isn't about to
+give *that* away to the player). In the third, the object is in scope, but
+its :prop:`before` property intercepts the :act:`Untie` action (and indeed,
+since this object is of the class ``Prop``, all actions apart from
+:act:`Examine`) to display a customised rejection message. Finally, the
+fourth usage refers to an object which *doesn't* intercept the action, so
+the interpreter calls the default action handler -- ``UntieSub`` -- which
+displays a general-purpose refusal to perform the action.
The principles presented here are those that you should generally employ:
write a generic action handler which either refuses to do anything (see,
which might make a legitimate target for the action, and instead provide a
more specific response, either performing or rejecting the action.
-In the case of ``Untie``, there are no objects which can be untied in this
-game, so we always generate a refusal of some sort.
+In the case of :act:`Untie`, there are no objects which can be untied in
+this game, so we always generate a refusal of some sort.
.. rubric:: Salute
-The next action is ``Salute``, provided in case Wilhelm chooses to defer to
-the hat on the pole. Here's the default action handler::
+.. Generated by autoindex
+.. index::
+ pair: Salute; library action
+
+The next action is :act:`Salute`, provided in case Wilhelm chooses to defer
+to the hat on the pole. Here's the default action handler::
[ SaluteSub;
if (noun has animate) print_ret (The) noun, " acknowledges you.";
print_ret (The) noun, " takes no notice.";
];
-You'll notice that this is slightly more intelligent than our ``Untie``
+You'll notice that this is slightly more intelligent than our :act:`Untie`
handler, since it produces different responses depending on whether the
-object being saluted -- stored in the :var:`noun` variable -- is :attr:`animate`
-or not. But it's basically doing the same job. And here's the grammar::
+object being saluted -- stored in the :var:`noun` variable -- is
+:attr:`animate` or not. But it's basically doing the same job. And here's
+the grammar::
Verb 'bow' 'nod' 'kowtow' 'genuflect'
* 'at'/'to'/'towards' noun -> Salute;
the same room as the player.
#. If players type something that matches one of those patterns, the
- interpreter triggers a ``Salute`` action, which by default is dealt with
- by the ``SaluteSub`` routine.
+ interpreter triggers a :act:`Salute` action, which by default is dealt
+ with by the ``SaluteSub`` routine.
So, we're allowing BOW AT HAT and KOWTOW TOWARDS HAT, but not simply NOD
HAT. We're allowing SALUTE HAT but not GREET TO HAT. It's not perfect,
accepts FIRE AT APPLE, FIRE AT TREE, and so on. Note that there's only one
semicolon in all of the grammar, right at the very end.
+.. Generated by autoindex
+.. index::
+ pair: noun; library variable
+ pair: second; library variable
+
The first two statements in ``FireAtSub`` deal with the first line of
grammar: FIRE (or SHOOT, or AIM) by itself. If the player types just that,
both :var:`noun` and :var:`second` will contain ``nothing``, so we reject the
at the end of the line, and then ``FireAtSub`` will work the same in all
cases.
-Before leaving the ``FireAt`` action, we'll add one more piece of grammar::
+.. Generated by autoindex
+.. index::
+ pair: FireAt; library action
+
+Before leaving the :act:`FireAt` action, we'll add one more piece of
+grammar::
Extend 'attack' replace
* noun -> FireAt;
This uses the ``Extend`` directive which we've just met, this time with a
``replace`` keyword. The effect is to substitute the new grammar defined
here for that contained in ``Grammar.h``, so that ATTACK, KILL, MURDER and
-all the other violent synonyms now trigger our ``FireAt`` action instead of
-the Library's standard ``Attack`` action. We're doing this so that, in the
-Marketplace, KILL GESSLER and MURDER WALTER have the same unfortunate
-results as FIRE AT GESSLER and SHOOT WALTER.
+all the other violent synonyms now trigger our :act:`FireAt` action instead
+of the Library's standard :act:`Attack` action. We're doing this so that,
+in the Marketplace, KILL GESSLER and MURDER WALTER have the same
+unfortunate results as FIRE AT GESSLER and SHOOT WALTER.
.. rubric:: Talk
-The final action that we define -- ``Talk`` -- provides a simple system of
-canned conversation, a low-key replacement for the standard ``Answer``,
-``Ask`` and ``Tell`` actions. The default ``TalkSub`` handler is closely
-based on ``TellSub`` (defined in library file ``verblibm.h``, should you be
-curious), and does three things:
+.. Generated by autoindex
+.. index::
+ pair: Answer; library action
+ pair: Ask; library action
+ pair: Talk; library action
+ pair: Tell; library action
+
+The final action that we define -- :act:`Talk` -- provides a simple system
+of canned conversation, a low-key replacement for the standard
+:act:`Answer`, :act:`Ask` and :act:`Tell` actions. The default ``TalkSub``
+handler is closely based on ``TellSub`` (defined in library file
+``verblibm.h``, should you be curious), and does three things:
#. Deals with TALK TO ME or TALK TO MYSELF.
+.. Generated by autoindex
+.. index::
+ pair: life; library property
+ pair: true; library constant
+
#. Checks (a) whether the creature being talked to has a :prop:`life`
- property, (b) whether that property is prepared to process a ``Talk``
- action, and (c) if the ``Talk`` processing returns :const:`true`. If all
- three checks succeed then ``TalkSub`` need do nothing more; if one or
- more of them fails then ``TalkSub`` simply...
+ property, (b) whether that property is prepared to process a :act:`Talk`
+ action, and (c) if the :act:`Talk` processing returns :const:`true`. If
+ all three checks succeed then ``TalkSub`` need do nothing more; if one
+ or more of them fails then ``TalkSub`` simply...
#. Displays a general "nothing to say" refusal to talk. ::
That second condition ``(RunLife(noun,##Talk) ~= false)`` is a bit of
a stumbling block, since it uses ``RunLife`` -- an undocumented
- internal library routine -- to offer the ``Talk`` action to the NPC's
- :prop:`life` property. We've decided to use it in exactly the same way
- as the ``Tell`` action does, without worrying too much about how it
- works (though it looks as though ``RunLife`` returns some :const:`true`
- value if the :prop:`life` property has intercepted the action, :const:`false`
- if it hasn't). The ``~=`` operator means "not equal to".
+ internal library routine -- to offer the :act:`Talk` action to the
+ NPC's :prop:`life` property. We've decided to use it in exactly the
+ same way as the :act:`Tell` action does, without worrying too much
+ about how it works (though it looks as though ``RunLife`` returns
+ some :const:`true` value if the :prop:`life` property has intercepted
+ the action, :const:`false` if it hasn't). The ``~=`` operator means
+ "not equal to".
The grammar is straightforward::
internal library routine called ``LanguageVerb`` -- not complex, but a
little too heavy for our second game.)
-Here's the simplest ``Talk`` handler that we've seen -- it's from Gessler
-the governor. Any attempt to TALK TO GESSLER will provoke "You cannot
-bring yourself to speak to him". ::
+Here's the simplest :act:`Talk` handler that we've seen -- it's from
+Gessler the governor. Any attempt to TALK TO GESSLER will provoke "You
+cannot bring yourself to speak to him". ::
life [;
Talk: print_ret "You cannot bring yourself to speak to him.";
],
-Walter's ``Talk`` handler is only slightly more involved::
+Walter's :act:`Talk` handler is only slightly more involved::
life [;
Talk:
projects / ibg.git / blobdiff