An object definition block defines how an object appears and how it behaves. The object definition block usually appears within a room definition block - usually the room that the object first appears in. However, it can also appear in the game definition block, or it can "float" outside any other block. Such objects won't appear anywhere until they're moved. You may find this useful if you have a particular object that only ever appears in the player's inventory, for example (although in that case you may as well put it directly in the inventory room, which is the player's inventory, and make it hidden).
An object definition block starts with the line:
define object <object name>
and ends with the line:
end define
Note that you should not begin an object's name with "the" - i.e., don't call an object "the sign"; instead call it "sign" and give it a prefix of "the" (see below). The following lines may appear within an object definition block:
Specifies what happens when the player tries to add something to this object (e.g. they try to put something in it, or on it):
Sets up the action specified. Many of these tags may exist within one object definition block.
For example, you could give an object an "eat" action such as:
action <eat> do <object-eat-procedure(banana)>
As with properties, the action specified here will override any action with the same name included by using a type tag.
- see also action and doaction script commands, type tag, type definition blocks, Changing an Object's Behaviour
Specifies the name of this object that is presented to the player. All objects must have unique names, so if you want to have two objects called "book", give them different "real" names (say, "book1" and "book2") and then give them both an alias of "book". In case both books appear in the same place and Quest is unable to distinguish between the two, a menu appears asking the player to select which object they mean. The description for the object on this menu is provided by the optional detail tag. You can specify additional names that the player might use to refer to this object using the alt tag.
- see also alt
Here you can specify other names that a player can use to refer to this object. Separate multiple names with semicolons. Objects can share "alt" names just as they can share aliases, and in the case of ambiguity, the standard disambiguation menu appears.
- see also alias
article <article>
Specifies the article for this object, usually either "it" or "them". The default is "it". This is used in player error messages such as "You can't drop it."
Specifies what happens when the player tries to close this object:
Specifies that this object is a container, and can therefore contain other objects.
A short description of the object used in case of ambiguity where two objects share the same alias. This is the description that appears on the disambiguation menu, so keep it short and distinct from other detail tags. You only need to use this tag if there is another object in the game sharing this object's alias, and then only if there is a possiblity that both objects will end up in the player's inventory or in the same room.
displaytype <display type name>
Specifies what "type" to display this object as in Quest's "Places and Objects" list.
drop ...
There are two forms of the drop tag:
drop { everywhere | nowhere } [ <message> ]
Prints the specified message, if any, when the player tries to drop the object. If "everywhere" is specified, the object is automatically dropped. If "nowhere" is specified, the object cannot be dropped.
drop script
Executes the specified script when the player tries to drop the object.
If no drop tag is specified, the object can by default be dropped anywhere, and the message specified by the defaultdrop error in the game definition block is printed, or a default message.
examine { <description> | script }
Like look, except this specifes what happens when the object is examined. If not specified, the look tag text or script is used.
- see look
Specifies a script to execute when this object is gained by the player. This only works for the standard "giving" of an object to the player, and not when the object is manually moved into the "inventory" room.
- see also lose tag, give script command
There are four forms of the give tag. When the player types something of the form GIVE A TO B, your game can handle it in the following ways:
give <object A> script
(in the object B definition) Specifies the script executed when the specified object A is given to this object. For example, give <potato> say <Cheers mate!> will say "Cheers mate!" when the player gives the potato to the object.
give to <object B> script
(in the object A definition) Specifies the script executed when this object is given to the specified object B.
give anything script
(in the object A definition) Specifies the script executed when any object is given to this object.
give to anything script
(in the object B definition) Specifies the script executed when this object is give to any object.
For give anything ... and give to anything ..., the game can find out what the other object is by reading the #quest.give.object.name# string variable. This will return the real (unaliased) name of the object.
The priority for give tags is the order in which they appear above. If no suitable give tag can be found for GIVE A TO B, the defaultgive error in the "define game" block will be printed, or a default message will be printed if none is specified.
- see also use
gender <gender>
Specifies what gender this object is referred to as - use "he", "she" or "it". This tag should be specified in lower case unless any of the letters are always in upper-case. If omitted, "it" is used.
Specifies that the object is, by default, not displayed "in" the room when the game starts and is inaccessible to the player - to all intents and purposes, it does not exist. To make it appear and "exist", the script command show must be executed. This tag is useful for objects which appear in rooms later on in the game, as the plot develops.
- see also invisible, show script command, hide script command
Specifies that the object exists in the room and can be interacted with, etc., but does not appear in either the room description or the objects list.
- see also hidden, reveal / conceal script commands
list [ off | <message[:]> | script ]
Tells Quest how to list objects that this object contains. If no "list" tag is specified, by default Quest will display "It contains" followed by a list of objects.
list empty [ <message> | script ]
Tells Quest what to display at the end of this object's description if it is an empty container. By default, Quest won't print anything.
list closed [ <message> | script ]
Tells Quest what to display at the end of this object's description if it is a closed container. By default, Quest won't print anything.
look { <description> | script }
Specifies what happens when the object is looked at. It can either be a line of script (for example do <look_at_bloke_procedure>) or it could simply be a line of text for a description. E.g.:
look <He's an ugly-looking thug.> look do <turn_to_stone>
- see also examine
Specifies a script to execute when this object is lost by the player. This only works for the standard "losing" or dropping of an object, and not when the object is manually moved from or hidden from the "inventory" room.
- see also give tag, lose script command
Specifies what happens when the player tries to open this object:
If this object is a container, specifies that it is open when the game starts. If this tag is not present, a container is assumed to be closed.
Specifies that this object is contained by another object.
Specifies whether the object is referred to as "a (name)", "the (name)" or just "(name)", etc. For example, an object "shop assistant" would perhaps have a prefix of "a". An object "Cyclops" would probably have a prefix of "the", whereas "Mr. Smith" wouldn’t have a prefix. Prefixes should be specified in lower case. e.g. prefix <the>, except in cases where they are always displayed with capitals.
- see also suffix
properties <property or property list>
Sets what properties this object has. You can specify multiple properties separated by semicolons. The format for properties is:
[ not ] property name [ = { value | string }]
For example:
properties <wearable; hunger=12; type=animal>
The inclusion of not will cancel that property if inherited by using a type tag. For example, if type <food> included a property "edible", using properties <not edible> would mean that this object would not have the "edible" property, but would still inherit the rest of the "food" type properties.
Object properties can be read from script:
- see also type, type definition blocks, property script command, Changing an Object's Behaviour
Specifies what happens when the player tries to remove something to this object (e.g. they try to take something out of it):
speak { <speak text> | script }
Specifies what the object does when spoken to. It can either be some script or it could simply be a line of text to print. E.g.:
speak <"Hello there. Lovely weather, isn't it?" replies the postman.> speak doaction <dog; bite player>
Specifies text to display after the object name in the room description. For example, if you wanted the description of the room to show that there was "a scary monster with large teeth" in the room, you would use a prefix of "a scary", an object name of "monster" and a suffix of "with large teeth".
- see also prefix
Specifies that this object is a surface, and other objects can therefore be put on it. A surface is very much like a container, except it cannot be opened or closed, and objects are put on it rather than in it.
take [ script | <take message> ]
Specifies that the object can be taken.
If no script is specified, the object is moved from the current room to the player's inventory. If a take message is specified, that is printed, otherwise a default message is printed. For example:
take take <You pick up the nice-looking gem and place it in your pocket.>
If a script is specified, it is executed and the object is not automatically moved to the player's inventory. For example:
take {
msg <You reach for the grenade and it explodes in your hand.>
playerlose
}
take msg <This object is far too heavy to pick up.>
Not the use of msg in our final example here - this means that this is a script, rather than a take message, and so the object is not automatically moved to the inventory. On the other hand, in our "nice-looking gem" example above, what comes after the take tag is not a script - it's just a parameter to the take command. This means the object is automatically moved to the inventory, and the message is printed.
If this object is a container, specifies that it is transparent. A transparent container behaves in the same way as a non-transparent container, except that its contents are visible even when it is closed.
Includes the properties and actions in the specified type definition block.
- see also properties, action, type script command
There are five forms of the use tag. The first form is used for when a player types something of the form USE OBJECT:
use script
Specifies what script to execute when a player types USE followed by the object name, without specifying another object to use it on. Note that any use <object> (script) in a room definition block will take priority if the object is used in that room.
When the player types something of the form USE A ON B, your game can handle it in the following ways:
use <object A> script
(in the object B definition) Specifies the script executed when the specified object A is used on this object. For example, use <hammer> say <Owch!> will say "Owch!" when the player uses the hammer on the object.
use on <object B> script
(in the object A definition) Specifies the script executed when this object is used on the specified object B.
use anything script
(in the object A definition) Specifies the script executed when any object is used on this object.
use on anything script
(in the object B definition) Specifies the script executed when this object is used on any object.
For use anything ... and use on anything ..., the game can find out what the other object is by reading the #quest.use.object.name# string variable. This will return the real (unaliased) name of the object.
The priority for use tags is the order in which they appear above. If no suitable use tag can be found for USE A ON B, the message defined by any error <defaultuse; message> in the " define game" block will be printed, or a default message will be printed if none is specified.
- see also give