.. epigraph::
- | *S was a sailor, and spent all he got;*
- | *T was a tinker, and mended a pot.*
+ | |CENTER| *S was a sailor, and spent all he got;*
+ | |CENTER| *T was a tinker, and mended a pot.*
.. only:: html
.. image:: /images/picS.png
:align: left
-.. raw:: latex
-
- \dropcap{s}
-
-imple though they are, our two games have covered most of the basic
-functionality of Inform, providing enough solid ground underfoot
-for you to start creating simple stories. Even if some of what you've
-encountered doesn't make sense yet, you should be able to browse a
-game's source code and form a general understanding of what is going on.
+|S|\imple though they are, our two games have covered most of the basic
+functionality of Inform, providing enough solid ground underfoot for you to
+start creating simple stories. Even if some of what you've encountered
+doesn't make sense yet, you should be able to browse a game's source code
+and form a general understanding of what is going on.
We'll now design a third game, to show you a few additional features and
give you some more sample code to analyse. In "Heidi" we tried to make
minimally at first and then adding complexity as need arises. Again,
this means that you won't be able to compile for testing purposes after
the addition of every code snippet, so, if you're typing in the game as
-you read, you’ll need to check the advice in "Compile-as-you-go" on page
-255.
+you read, you’ll need to check the advice in :ref:`compile-as-you-go`.
A lot of what goes into this game we have already seen; you may deduce
from this that the game design business is fairly repetitious and that
.. pull-quote::
- "Impersonating mild mannered John Covarth, assistant help boy at
- an Impersonating insignificant drugstore, you suddenly STOP
- when your acute hearing deciphers a stray radio call from the
- POLICE. There’s some MADMAN attacking the population in Granary
- Park! You must change into your Captain FATE costume fast...!"
+ "Impersonating mild mannered John Covarth, assistant help boy at an
+ insignificant drugstore, you suddenly STOP when your acute hearing
+ deciphers a stray radio call from the POLICE. There’s some MADMAN
+ attacking the population in Granary Park! You must change into your
+ Captain FATE costume fast...!"
which won't be so easy to do. In this short example, players will win
when they manage to change into their super-hero costume and fly away to
The game starts with meek John Covarth walking down the street. We set
up the game as usual:
-.. code-block:: inform6
+.. code-block:: inform
!% -SD
!============================================================================
Almost everything is familar, apart from a few details:
-.. code-block:: inform6
+.. code-block:: inform
Constant MANUAL_PRONOUNS;
Constant MAX_SCORE 2;
see two more constants: ``OBJECT_SCORE`` and ``ROOM_SCORE``. There are
several scoring systems predefined in Inform. In "William Tell" we've
seen how you can manually add (or subtract) points by changing the value
-of the variable ``score``. Another approach is to award points to
+of the variable :var:`score`. Another approach is to award points to
players on the first occasion that they (a) enter a particular room, or
(b) pick up a particular object. To define that a room or object is
indeed “particular”, all you have to do is give it the attribute
-``scored``; the library take cares of the rest. The predefined scores
+:attr:`scored`; the library take cares of the rest. The predefined scores
are five points for finally reached rooms and four points for wondrous
acquisition of objects. With the constants ``OBJECT_SCORE`` and
``ROOM_SCORE`` we can change those defaults; for the sake of example,
of an equals sign ``=`` is optional with ``Constant``; these two lines
have identical effect:
-.. code-block:: inform6
+.. code-block:: inform
Constant ROOM_SCORE 1;
Inform provides for displaying strings of text. Until now, we have shown
you:
-.. code-block:: inform6
+.. code-block:: inform
print "And now for something completely different...^"; return true;
...
example games, this happens quite a lot, so there is a yet shorter way
of achieving the same result:
-.. code-block:: inform6
+.. code-block:: inform
"And now for something completely different...";
statement instead.
You'll notice that -- unusually for a room -- our ``street`` object has
-a ``name`` property:
+a :prop:`name` property:
-.. code-block:: inform6
+.. code-block:: inform
Room street "On the street"
with name 'city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
need to refer to in order to SAVE the day", rather than the misleading
"You can't see any such thing". We mostly prefer to deal with such
scenic words using classes like ``Prop`` and ``Furniture``, but
-sometimes a room's ``name`` property is a quick and convenient solution.
+sometimes a room's :prop:`name` property is a quick and convenient solution.
In this game, we provide a class named ``Appliance`` to take care of
furniture and unmovable objects. You’ll notice that the starting room we
have defined has no connections yet. The description mentions a phone
booth and a café, so we might want to code those. While the café will be
a normal room, it would seem logical that the phone booth is actually a
-big box on the sidewalk; therefore we define a ``container`` set in the
+big box on the sidewalk; therefore we define a :attr:`container` set in the
street, which players may enter:
-.. code-block:: inform6
+.. code-block:: inform
Appliance booth "phone booth" street
with name 'old' 'red' 'picturesque' 'phone' 'booth' 'cabin'
has enterable container open;
What's interesting are the attributes at the end of the definition.
-You'll recall from Heidi's ``nest`` object that a ``container`` is an
+You'll recall from Heidi's ``nest`` object that a :attr:`container` is an
object capable of having other objects placed in it. If we make
-something ``enterable``, players count as one of those objects, so that
+something :attr:`enterable`, players count as one of those objects, so that
they may squeeze inside. Finally, ``containers`` are, by default,
-supposed to be closed. You can make them ``openable`` if you wish
+supposed to be closed. You can make them :attr:`openable` if you wish
players to be able to OPEN and CLOSE them at will, but this doesn't seem
appropriate behaviour for a public cabin -- it would become tedious to
have to type OPEN BOOTH and CLOSE BOOTH when these actions provide
-nothing special -- so we add instead the attribute ``open`` (as we did
+nothing special -- so we add instead the attribute :attr:`open` (as we did
with the nest), telling the interpreter that the container is open from
the word go. Players aren't aware of our design, of course; they may
indeed try to OPEN and CLOSE the booth, so we trap those actions in a
-``before`` property which just tells them that these are not relevant
-options. The ``after`` property gives a customised message to override
+:prop:`before` property which just tells them that these are not relevant
+options. The :prop:`after` property gives a customised message to override
the library’s default for commands like ENTER BOOTH or GO INSIDE BOOTH.
Since in the street's description we have told players that the phone
connection to the as-yet-undefined café room and a default message for
the movement which is not allowed):
-.. code-block:: inform6
+.. code-block:: inform
Room street "On the street"
with name city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
"No time now for exploring! You'll move much faster in your
Captain FATE costume.";
-.. todo::
-
- Notice how the syntax coloring thinks that the exclaimation point
- above is a comment. This is another problem with the built-in inform6
- syntax colorer.
-
That takes care of entering the booth. But what about leaving it?
Players may type EXIT or OUT while they are inside an enterable
container and the interpreter will oblige but, again, they might type
NORTH. This is a problem, since we are actually in the street (albeit
inside the booth) and to the north we have the café. We may provide for
-this condition in the room's ``before`` property:
+this condition in the room's :prop:`before` property:
-.. code-block:: inform6
+.. code-block:: inform
before [;
Go:
also refer to the café, so we express our bafflement and force the
player to try something else:
-.. code-block:: inform6
+.. code-block:: inform
n_to cafe,
s_to [; <<Enter booth>>; ],
Now everything seems to be fine, except for a tiny detail. We've said
that, while in the booth, the player character’s location is still the
-``street`` room, regardless of being inside a ``container``; if players
+``street`` room, regardless of being inside a :attr:`container`; if players
chanced to type LOOK, they'd get:
.. code-block:: transcript
Hardly an adequate description while *inside* the booth. There are
several ways to fix the problem, depending on the result you wish to
-achieve. The library provides a property called ``inside_description``
+achieve. The library provides a property called :prop:`inside_description`
which you can utilise with enterable containers. It works pretty much
-like the normal ``description`` property, but it gets printed only when
+like the normal :prop:`description` property, but it gets printed only when
the player is inside the container. The library makes use of this
property in a very clever way, because for every LOOK action it checks
whether we can see outside the container: if the container has the
-``transparent`` attribute set, or if it happens to be ``open``, the
-library displays the normal ``description`` of the room first and then
-the ``inside_description`` of the container. If the library decides we
+:attr:`transparent` attribute set, or if it happens to be :attr:`open`, the
+library displays the normal :prop:`description` of the room first and then
+the :prop:`inside_description` of the container. If the library decides we
can’t see outside the container, only the inside_description is
displayed. Take for instance the following (simplified) example:
-.. code-block:: inform6
+.. code-block:: inform
Room stage "On stage"
with description
In our case, however, we don't wish the description of the street to be
displayed at all (even if a caller is supposedly able to see the street
while inside a booth). The problem is that we have made the booth an
-``open`` container, so the street's description would be displayed every
-time. There is another solution. We can make the ``description``
+:attr:`open` container, so the street's description would be displayed every
+time. There is another solution. We can make the :prop:`description`
property of the ``street`` room a bit more complex, and change its
value: instead of a string, we write an embedded routine. Here's the
(almost) finished room:
-.. code-block:: inform6
+.. code-block:: inform
Room street "On the street"
with name 'city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
The description while inside the booth mentions the sidewalk, which
might invite the player to EXAMINE it. No problem:
-.. code-block:: inform6
+.. code-block:: inform
Appliance "sidewalk" street
with name sidewalk' 'pavement' 'street',
looks from the *inside*); but while we are on the street we need
something else to describe it:
-.. code-block:: inform6
+.. code-block:: inform
Appliance outside_of_cafe "Benny's cafe" street
with name 'benny^s' 'cafe' 'entrance',
],
has enterable proper;
-.. todo::
+.. index:: accented characters
- Figure out how to set off this entire note section as an indented block
+.. note::
-NOTE : although the text of our guide calls Benny's establishment a
-"café" -- note the acute "e" -- the game itself simplifies this to
-"cafe". We do this for clarity, not because Inform doesn't support
-accented characters. The *Inform Designer's Manual* explains in detail
-how to display these characters in "§1.11 *How text is printed*" and
-provides the whole Z-machine character set in Table 2. In our case, we
-could have displayed this::
+ Although the text of our guide calls Benny's establishment a "café" --
+ note the acute "e" -- the game itself simplifies this to "cafe". We do
+ this for clarity, not because Inform doesn't support accented
+ characters. The |DM4| explains in detail how to display these characters
+ in :dm4:`§1.11 <s1.html#s1_11>` "*How text is printed*" and provides the
+ whole Z-machine character set in Table 2. In our case, we could have
+ displayed this::
- The town's favourite for a quick snack, Benny's café has a 50's ROCKETSHIP look.
+ The town's favourite for a quick snack, Benny's café has a 50's ROCKETSHIP look.
-by defining the ``description`` property as any of these:
+ by defining the :prop:`description` property as any of these:
-.. code-block:: inform6
+ .. code-block:: inform
- description
- "The town's favourite for a quick snack, Benny's caf@'e has a 50's
- ROCKETSHIP look.",
+ description
+ "The town's favourite for a quick snack, Benny's caf@'e has a 50's
+ ROCKETSHIP look.",
- description
- "The town's favourite for a quick snack, Benny's caf@@170 has a 50's
- ROCKETSHIP look.",
+ description
+ "The town's favourite for a quick snack, Benny's caf@@170 has a 50's
+ ROCKETSHIP look.",
- description
- "The town's favourite for a quick snack, Benny's caf@{E9} has a 50's
- ROCKETSHIP look.",
+ description
+ "The town's favourite for a quick snack, Benny's caf@{E9} has a 50's
+ ROCKETSHIP look.",
-However, all three forms are harder to read than the vanilla "cafe", so
-we've opted for the simple life.
-
-.. todo::
-
- Indented block ends here
+ However, all three forms are harder to read than the vanilla "cafe", so
+ we've opted for the simple life.
Unlike the sidewalk object, we offer more than a mere description. Since
the player may try ENTER CAFE as a reasonable way of access -- which
would have confused the interpreter immensely -- we take the opportunity
-of making this object also ``enterable``, and we cheat a little. The
-attribute ``enterable`` has permitted the verb ENTER to be applied to
-this object, but this is not a ``container``; we want the player to be
-sent into the *real* café room instead. The ``before`` property handles
+of making this object also :attr:`enterable`, and we cheat a little. The
+attribute :attr:`enterable` has permitted the verb ENTER to be applied to
+this object, but this is not a :attr:`container`; we want the player to be
+sent into the *real* café room instead. The :prop:`before` property handles
this, intercepting the action, displaying a message and teleporting the
player into the café. We ``return true`` to inform the interpreter that
we have taken care of the ``Enter`` action ourselves, so it can stop
right there.
As a final detail, note that we now have two ways of going into the
-café: the ``n_to`` property of the ``street`` room and the ``Enter``
+café: the :prop:`n_to` property of the ``street`` room and the ``Enter``
action of the ``outside_of_cafe`` object. A perfectionist might point
out that it would be neater to handle the actual movement of the player
in just one place of our code, because this helps clarity. To achieve
-this, we redirect the street's ``n_to`` property thus:
+this, we redirect the street's :prop:`n_to` property thus:
-.. code-block:: inform6
+.. code-block:: inform
n_to [; <<Enter outside_of_cafe>>; ],
-You may think that this is unnecessary madness, but a word to the wise:
-in a large game, you want action handling going on just in one place
-when possible, because it will help you to keep track of where things
-are a-happening if something goes *ploof* (as, believe us, it will; see
-"Debugging your game" on page 197). You don't need to be a
-perfectionist, just cautious.
-
-A booth in this kind of situation is an open invitation for the player
-to step inside and try to change into Captain Fate's costume. We won't
-let this happen -- the player isn't Clark Kent, after all; later we'll
-explain how we forbid this action -- and that will force the player to
-go inside the café, looking for a discreet place to disrobe; but first,
-let''s freeze John Covarth outside Benny''s and reflect about a
-fundamental truth.
+You may think that this is unnecessary madness, but a word to the wise: in
+a large game, you want action handling going on just in one place when
+possible, because it will help you to keep track of where things are
+a-happening if something goes *ploof* (as, believe us, it will; see
+:doc:`16`). You don't need to be a perfectionist, just cautious.
+
+A booth in this kind of situation is an open invitation for the player to
+step inside and try to change into Captain Fate's costume. We won't let
+this happen -- the player isn't Clark Kent, after all; later we'll explain
+how we forbid this action -- and that will force the player to go inside
+the café, looking for a discreet place to disrobe; but first, let's freeze
+John Covarth outside Benny's and reflect about a fundamental truth.
A hero is not an ordinary person
================================
sufficiently non-committal, and that's it. Of course, if your game
includes a magic portal that will reveal itself only if the player lets
rip with a snatch of Wagner, you may intercept the ``Sing`` action in a
-``before`` property and alter its default, pretty useless behaviour. If
+:prop:`before` property and alter its default, pretty useless behaviour. If
not, it's "Your singing is abominable" for you.
-All actions, useful or not, have a stock of messages associated with
-them (the messages are held in the ``english.h`` library file and listed
-in Appendix 4 of the *Inform Designer's Manual*). We have already seen
-one way of altering the player character's description -- "As good
-looking as ever" -- in "William Tell", but the other defaults may also
-be redefined to suit your tastes and circumstantial needs.
+All actions, useful or not, have a stock of messages associated with them
+(the messages are held in the ``english.h`` library file and listed in
+:dm4:`Appendix 4 <sa4.html>` of the |DM4|). We have already seen one way of
+altering the player character's description -- "As good looking as ever" --
+in "William Tell", but the other defaults may also be redefined to suit
+your tastes and circumstantial needs.
John Covarth, aka Captain Fate, could happily settle for most of these
default messages, but we deem it worthwhile to give him some customised
nicety that many players regard as important. For this mission, we make
use of the ``LibraryMessages`` object.
-.. code-block:: inform6
+.. code-block:: inform
Include "Parser";
If you provide it, the ``LibraryMessages`` object must be defined
*between* the inclusion of ``Parser`` and ``VerbLib`` (it won't work
otherwise and you’ll get a compiler error). The object contains a single
-property -- ``before`` -- which intercepts display of the default
+property -- :prop:`before` -- which intercepts display of the default
messages that you want to change. An attempt to SING, for example, will
now result in "Alas! That is not one of your many superpowers" being
displayed.
number of the message to be displayed, so you can change the default
with a test like this:
-.. code-block:: inform6
+.. code-block:: inform
if (lm_n == 39)
"That's not something you need to refer to in order to SAVE the day.";
-.. todo::
-
- That block of code above should be colored. Is there a defect in the
- syntax coloring code?
-
where 39 is the number for the standard message "That's not something
you need to refer to in the course of this game" -- displayed when the
player mentions a noun which is listed in a room's name property, as we
did for the ``street``.
-.. todo::
-
- Begin big chunk of indented text. Also, NOTE should be in bigcaps.
-
-NOTE : remember that when we are testing for different values of the
-same variable, we can also use the switch statement. For the Miscellany
-entry, the following code would work just as nicely:
-
-.. code-block:: inform6
-
- ...
- Miscellany:
- switch (lm_n) {
- 19:
- if (clothes has worn)
- "In your secret identity's outfit, you manage most
- efficaciously to look like a two-cent loser, a
- good-for-nothing wimp.";
- else
- "Now that you are wearing your costume, you project
- the image of power UNBOUND, of ballooned,
- multicoloured MUSCLE, of DASHING yet MODEST chic.";
- 38:
- "That's not a verb you need to SUCCESSFULLY save the day.";
- 39:
- "That's not something you need to refer to in order to SAVE the day.";
- }
-
-.. todo::
-
- End big indented chunk
+.. note::
+
+ Remember that when we are testing for different values of the
+ same variable, we can also use the switch statement. For the
+ Miscellany entry, the following code would work just as nicely:
+
+ .. code-block:: inform
+
+ ...
+ Miscellany:
+ switch (lm_n) {
+ 19:
+ if (clothes has worn)
+ "In your secret identity's outfit, you manage most
+ efficaciously to look like a two-cent loser, a
+ good-for-nothing wimp.";
+ else
+ "Now that you are wearing your costume, you project
+ the image of power UNBOUND, of ballooned,
+ multicoloured MUSCLE, of DASHING yet MODEST chic.";
+ 38:
+ "That's not a verb you need to SUCCESSFULLY save the day.";
+ 39:
+ "That's not something you need to refer to in order to SAVE the day.";
+ }
Not surprisingly, the default message for self-examination: "As good
looking as ever" is a ``Miscellany`` entry -- it's number 19 -- so we
discouraged; choices like this become more common (and easier) as your
experience grows.
-.. todo::
+.. Ugh. Ghastly, but it does the job.
- Begin big indented chunk. That "whatever new look" needs to be italicized.
+.. |WNL_LATEX| replace:: :latex:`\emph{\textbf{whatever new look}}`
-NOTE: going back to our example, an alternative approach would be to set
-the variable ``player.description`` in the ``Initialise`` routine (as we
-did with "William Tell") to the "ordinary clothes" string, and then
-later change it as the need arises. It is a variable, after all, and you
-can alter its value with another statement like ``player.description =
-*whatever new look*`` anywhere in your code. This alternative solution
-might be better if we intended changing the description of the player
-many times through the game. Since we plan to have only two states, the
-``LibraryMessages`` approach will do just fine.
+.. |WNL_HTML| replace:: :html:`<strong><em>whatever new look</em></strong>`
-.. todo::
+.. note::
- End big indented chunk
+ Going back to our example, an alternative approach would be to set the
+ variable ``player.description`` in the ``Initialise`` routine (as we did
+ with "William Tell") to the "ordinary clothes" string, and then later
+ change it as the need arises. It is a variable, after all, and you can
+ alter its value with another statement like ``player.description =``
+ |WNL_LATEX| |WNL_HTML| anywhere in your code. This alternative solution
+ might be better if we intended changing the description of the player
+ many times through the game. Since we plan to have only two states, the
+ ``LibraryMessages`` approach will do just fine.
A final warning: as we explained when extending the standard verb
grammars, you *could* edit the appropriate library file and change all
your library file will probably not be right for the next game. Use of
the ``LibraryMessages`` object is strongly advised.
-If you're typing in the game, you'll probably want to read the brief
-section on "Compile-as-you-go" on page 255 prior to performing a test
-compile. Once everything's correct, it’s time that our hero entered that
-enticing café.
+If you're typing in the game, you'll probably want to read the brief
+section on :ref:`compile-as-you-go` prior to performing a test compile.
+Once everything's correct, it’s time that our hero entered that enticing
+café.
projects / ibg.git / blobdiff