AGT Programming (1) INVISIBLE objects and SYNONYMS

INVISIBLE Objects:
-----------------
The latest versions of AGT have the useful new optional attribute,
INVISIBLE, for nouns. All you have to do is add this line into
your datafile and objects can be examined and manipulated but
won't appear as individual items on the screen. This makes it easy
to hide objects in the location description, rather than handing
them on a plate to the player with obvious text such as:
     A valuable tapestry is hanging on the east wall.

However, in practice, I found the darn things were sometimes
printed on the screen anyway. It took a while but I eventually
figured out that it can depend on what order you list the
characteristics. No instructions are supplied telling you where to
put INVISIBLE in the list. You also shouldn't give a short
description for the noun.

This is an example of the format I used for INVISIBLE objects.

NOUN 300
tapestry
valuable
INVISIBLE
UNMOVABLE
LOCATION 53
END_NOUN

NOUN_DESCR 300
Though old, the tapestry is clearly valuable. As you gaze at it,
fascinated by the intricacy of its design and the number of tiny
stitches, you feel a faint breeze from behind it.
END_NOUN_DESCR

...thus giving the player the hint that there might be a hidden
passage behind it. Commands to manipulate the tapestry and reveal
the secret exit can then be programmed into the CMD file as
normal.


SYNONYMS
--------
Theoretically, a great idea. Add the extra line:

NOUN_SYNONYMS fabric

to the above description and program in a suitable metacommand
such as PULL TAPESTRY and a message like:

MESSAGE 100
You pull back one corner of the $noun$. To your amazement, you
find a tiny room behind the tapestry, where a narrow flight of
stairs leads down into darkness.
END_MESSAGE

and if the player types either PULL TAPESTRY or PULL FABRIC, the
noun used (tapestry or fabric) will be echoed back in the first
line. However there are a few drawbacks.

Firstly, you may occasionally get strange word-wrapping as a
result according to the lengths of the words used. This also
happens in ANY commands, such as PULL ANY or DROP ANY where
echoing is catered for in the resulting message. The way round
this is to spilt the message into two sections, eg:

MESSAGE 100
You pull back one corner of the $noun$.
To your amazement, you find a tiny room behind the tapestry, where
a narrow flight of stairs leads down into darkness.
END_MESSAGE

Not so neat, but it works!

Secondly, if you allow synonyms for one object in one place, (for
instance, a cupboard which you also want to allow players to refer
to as a door) but not in others (all other doors aren't given the
synonym cupboard, which would be a bit weird) you may get the
following response:

>Open door
What cupboard? I don't see a cupboard here!

Not only will this frustrate the player who is hoping to find your
game believable, but it can cause more drastic problems to you,
the programmer.  A conflict along these lines held up my own game
for three programming sessions when a command would work in all
locations I tried EXCEPT for the one where I wanted it to work. It
was only by finally admitting defeat and removing the offending
synonym that I could get an important puzzle to work.

The moral - use synonyms with care!
                                                       Sue