We must not forget a couple of tiny details in the café room:
-.. code-block:: inform6
+.. code-block:: inform
Object food "Benny's snacks" cafe
with name 'food' 'pastry' 'pastries' 'sandwich' 'sandwiches' 'snack'
And a not-so-trivial object:
-.. code-block:: inform6
+.. code-block:: inform
Object coffee "cup of coffee" benny
with name 'cup' 'of' 'coffee' 'steaming' 'cappuccino'
Benny, it's not a noun that the player can ASK Benny FOR. By making it a
child of the barman (who has the ``transparent`` attribute set), the
coffee is still an object that players can refer to. We ensure that they
-don't get more cups thanks to Benny's ``coffee_asked_for property``,
+don't get more cups thanks to Benny's ``coffee_asked_for`` property,
which will remain ``true`` after the first time.
We also ensure that Benny doesn't ask for money from players who have
There's not a lot about the toilet room and its contents, though there
will be some tricky side effects:
-.. code-block:: inform6
+.. code-block:: inform
Room toilet "Unisex toilet"
with description
mentioned in the room's description to aid players in their dressing
duties.
-.. code-block:: inform6
+.. code-block:: inform
Appliance light_switch "light switch" toilet
with name 'light' 'switch',
``on``. switchable enables the object to be turned on and off, and is
typical of lanterns, computers, television sets, radios, and so on. The
library automatically extends the description of these objects by
-indicating if they are currently on or off::
+indicating if they are currently on or off:
+
+.. code-block:: transcript
> X LIGHT SWITCH
A notorious ACHIEVEMENT of technological SCIENCE, elegant yet EASY to use.
Two new actions are ready to use, ``SwitchOn`` and ``SwitchOff``. Left
to themselves, they toggle the object's state between ON and OFF and
-display a message like::
+display a message like:
+
+.. code-block:: transcript
You switch the brass lantern on.
course, set or clear it manually like any other attribute, with the
``give`` statement:
-.. code-block:: inform6
+.. code-block:: inform
give self on;
and check if a ``switchable`` object is on or off with the test:
-.. code-block:: inform6
+.. code-block:: inform
if (light_switch has on) ...
A ``switchable`` object is OFF by default. However, you’ll notice that
the has line of the object definition includes ``~on`` :
-.. code-block:: inform6
+.. code-block:: inform
has switchable ~on;
Surely that’s saying "not-on"? Surely that's what would have happened
anyway if the line hadn't mentioned the attribute at all?
-.. code-block:: inform6
+.. code-block:: inform
has switchable;
itself (though this is usually convenient).
After setting the ``light`` attribute, we display a customised message,
-to avoid the default::
+to avoid the default:
+
+.. code-block:: transcript
You switch the light switch on.
.. note::
- remember what we said about class inheritance? No matter what you
+ Remember what we said about class inheritance? No matter what you
define in the class, the object’s definition has priority. The class
``Appliance`` defines a response for the ``Push`` action, but we
override it here with a new behaviour.
object to account for this. A couple of lines in the after property will
suffice:
-.. code-block:: inform6
+.. code-block:: inform
after [ ks;
Unlock:
.. note::
- now, could they? Well, if players could TAKE the light switch (which
+ Now, could they? Well, if players could TAKE the light switch (which
we have forbidden) and then did INVENTORY, the trick would be given
away, because all objects with the ``light`` attribute set are listed
as ``(providing light)`` .
routines``" of our game -- after the ``Initialise`` routine, for
instance -- include the following lines:
-.. code-block:: inform6
+.. code-block:: inform
[ InScope person;
if (person == player && location == thedark && real_location == toilet) {
return false;
];
-``InScope(actor_obj_id)`` is an entry point routine that can tamper with
-the scope rules for the given ``actor_obj_id`` (either the player
-character or a NPC). We define it with one variable (which we name as we
-please; it's also a good idea to name variables in an intuitive way to
-remind us of what they represent), ``person`` , and then we make a
-complex test to see if the player is actually in the toilet and in the
+:samp:`InScope({actor_obj_id})` is an entry point routine that can tamper
+with the scope rules for the given :samp:`{actor_obj_id}` (either the
+player character or a NPC). We define it with one variable (which we name
+as we please; it's also a good idea to name variables in an intuitive way
+to remind us of what they represent), ``person`` , and then we make a
+complex test to see if the player is actually in the toilet and in the
dark.
We have told you that the library variable ``location`` holds the
So the test:
-.. code-block:: inform6
+.. code-block:: inform
if (person == player && location == thedark && real_location == toilet) ...
finds himself in the dark *and* he actually happens to be in the
toilet...
-Then we make a call to one of the library routines,
-``PlaceInScope(obj_id)``, which has a very descriptive name: it places
-in scope the given object. In our case, we want both the door and the
-light switch to be within reach of the player, hence both additional
-lines. Finally, we must ``return false``, because we want the normal
-scope rules for the defined actor -- the player -- to apply to the rest
-of the objects of the game (if we returned ``true``, players would find
-that they are able to interact with very little indeed). Now we get a
-friendlier and more logical response:
+Then we make a call to one of the library routines,
+:samp:`PlaceInScope({obj_id})`, which has a very descriptive name: it
+places in scope the given object. In our case, we want both the door and
+the light switch to be within reach of the player, hence both additional
+lines. Finally, we must ``return false``, because we want the normal scope
+rules for the defined actor -- the player -- to apply to the rest of the
+objects of the game (if we returned ``true``, players would find that they
+are able to interact with very little indeed). Now we get a friendlier and
+more logical response:
.. code-block:: transcript
thinks to turn on the light switch, thereby placing the key in scope
once more.
-Why don't we add a ``PlaceInScope(toilet_key)`` to the above routine?
-Well, for starters, the key can be moved around (as opposed to the door
-or the light switch, which are fixed items in the toilet room). Suppose
-the player opens the door of the toilet, but drops the key in the café,
-then enters the toilet and closes the door. The condition is met and the
-key is placed in scope, when it's in another room. Second, this is a
-simple game with just a few objects, so you can define a rule for each
-of them; but in any large game, you might like to be able to refer to
-objects in bunches, and make general rules that apply to all (or some)
-of them.
+Why don't we add a :samp:`PlaceInScope({toilet_key})` to the above routine?
+Well, for starters, the key can be moved around (as opposed to the door or
+the light switch, which are fixed items in the toilet room). Suppose the
+player opens the door of the toilet, but drops the key in the café, then
+enters the toilet and closes the door. The condition is met and the key is
+placed in scope, when it's in another room. Second, this is a simple game
+with just a few objects, so you can define a rule for each of them; but in
+any large game, you might like to be able to refer to objects in bunches,
+and make general rules that apply to all (or some) of them.
We need to add code to the ``InScope`` routine, telling the game to
place in scope all objects that we drop in the dark, so that we might
have ``moved``. Here is the reworked ``InScope`` routine. There are a
couple of new concepts to look at:
-.. code-block:: inform6
+.. code-block:: inform
[ InScope person item;
if (person == player && location == thedark && real_location == toilet) {
dark rooms (well, the only dark room in the game *is* the toilet, but we
are trying to provide a general rule).
-.. todo::
-
- Lots of italicized typewriter stuff here...
-
-.. code-block:: inform6
-
- objectloop (variable) statement;
-
-is a loop statement, one of the four defined in Inform. A loop statement
-is a construct that allows you to run several times through a statement
-(or a statement block). ``objectloop`` performs the ``statement`` once
-for every object defined in the (``variable``) . If we were to code:
+ :samp:`objectloop (variable) {statement};`
-.. code-block:: inform6
+is a loop statement, one of the four defined in Inform. A loop statement is
+a construct that allows you to run several times through a statement (or a
+statement block). ``objectloop`` performs the :samp:`{statement}` once for
+every object defined in the (:samp:`{variable}`) . If we were to code:
- objectloop (item) statement;
+ :samp:`objectloop (item) {statement};`
-then the ``statement`` would be executed once for each object in the
-game. However, we want to perform the statement only for those objects
-whose parent object is the same as the player's parent object: that is,
-for objects in the same room as the player, so we instead code:
+then the :samp:`{statement}` would be executed once for each object in the
+game. However, we want to perform the statement only for those objects
+whose parent object is the same as the player's parent object: that is, for
+objects in the same room as the player, so we instead code:
-.. code-block:: inform6
+ :samp:`objectloop (item in parent(player)) {statement};`
- objectloop (item in parent(player)) statement;
+What is the actual :samp:`{statement}` that we'll repeatedly execute?
-What is the actual ``statement`` that we'll repeatedly execute?
-
-.. code-block:: inform6
+.. code-block:: inform
if (item has moved)
PlaceInScope(item);
This leaves us the clothing items themselves, which will require a few
tailored actions. Let's see first the ordinary garments of John Covarth:
-.. code-block:: inform6
+.. code-block:: inform
Object clothes "your clothes"
with name 'ordinary' 'street' 'clothes' 'clothing',
into ordinary clothes. So now we are dealing with a Captain Fate in full
costume:
-.. code-block:: inform6
+.. code-block:: inform
Object costume "your costume"
with name 'captain' 'captain^s' 'fate' 'fate^s' 'costume' 'suit',
lines to the ``Initialise`` routine to make sure that the player does
not start the game naked:
-
-
-
-.. rubric:: Footnotes
-
-.. [#dark]
-
- We're alluding here to the Classical concept of mimesis. In an
- oft-quoted essay from 1996, Roger Giner-Sorolla wrote: "I see
- successful fiction as an imitation or 'mimesis' of reality, be it
- this world's or an alternate world's. Well-written fiction leads the
- reader to temporarily enter and believe in the reality of that world.
- A crime against mimesis is any aspect of an IF game that breaks the
- coherence of its fictional world as a representation of reality."
-
-.. code-block:: inform6
+.. code-block:: inform
[ Initialise;
#Ifdef DEBUG; pname_verify(); #Endif; ! suggested by pname.h
check for errors when using his library, and he tells us how to use it.
So we include the suggested lines into our ``Initialise`` routine:
-.. code-block:: inform6
+.. code-block:: inform
#Ifdef DEBUG; pname_verify(); #Endif;
"William Tell", to write our customised messages and assign them to
``deadflag`` values greater than 2.
-.. code-block:: inform6
+.. code-block:: inform
[ DeathMessage;
if (deadflag == 3) print "Your secret identity has been revealed";
of things. We have already seen that we need a verb CHANGE. We'll make
it really simple:
-.. code-block:: inform6
+.. code-block:: inform
[ ChangeSub;
if (noun has pluralname) print "They're";
``Give`` action in the orders property handles every input not already
specified:
-.. code-block:: inform6
+.. code-block:: inform
orders [;
Give:
food: ! code for the food...
menu: ! code for the menu...
default:
- "~I don't
+ "~I don't think that's on the menu, sir.~";
}
],
Not so. The library grammar that deals with ASK BENNY FOR... is this
(specifically, the last line):
-.. code-block:: inform6
+.. code-block:: inform
Verb 'ask'
* creature 'about' topic -> Ask
undefined input from the player. We need to extend the existing ASK
grammar:
-.. code-block:: inform6
+.. code-block:: inform
Extend 'ask'
* creature 'for' topic -> AskFor;
talk a little more about compilation and debugging, and send you off
into the big wide world of IF authorship.
+
+.. rubric:: Footnotes
+
+.. [#dark]
+
+ We're alluding here to the Classical concept of mimesis. In an
+ oft-quoted essay from 1996, Roger Giner-Sorolla wrote: "I see
+ successful fiction as an imitation or 'mimesis' of reality, be it
+ this world's or an alternate world's. Well-written fiction leads the
+ reader to temporarily enter and believe in the reality of that world.
+ A crime against mimesis is any aspect of an IF game that breaks the
+ coherence of its fictional world as a representation of reality."
+
projects / ibg.git / blobdiff