Roger Firth's IF pages
InFancy -- using Inform objects
A number of properties control the way in which your game environment -- the rooms and their contents -- is presented to the player.
The description is pretty easy to understand and test: for a room it's what you see upon entry and after LOOK, and for an object it's what you see when you EXAMINE the object. It can contain a routine or a string, as in these two examples:
Object bottle "bottle" kitchen_table with description [ liq; liq = ChildWithProp(self,capacity); print "You see an ordinary wine bottle, of green glass, with a faded label and a "; if (cork in self) print "cork protruding from the "; print "slender neck"; if (liq ~= 0) print ". There is a quantity of liquid inside"; "."; ] has transparent; Object label "label" bottle with name 'faded' 'label' 'lable', description "Though somewhat faded and difficult to make out, the label seems to read ~Chat Eau~.";
The inside_description property comes into play only when the player is inside an enterable object.
initial can also contain a routine or a string. Applied to an object, it is invoked (following the description for the room where it appears) until that object has been handled by the player (strictly, until the object's moved attribute is set). The effect is to draw the player's attention to the object (though personally I find it does this in a rather obvious and clumsy way). Applied to a room, it is invoked early in the processing cycle, before the room's description is printed. Anyway, here it is introducing the table:
Object kitchen_table "table" kitchen with name 'battered' 'scuffed' 'stained' 'pine' 'table', initial "In the centre of the room stands a battered pine table.", description "The table is scuffed and stained with indeterminate substances." has static supporter;
In a similar vein, the four properties when_closed, when_open, when_off and when_on take the place of initial for objects which are respectively container|door, container|door open, switchable and switchable on.
Note that all of these properties are invoked only when creating a room description -- not when examining the object itself -- and apply only to objects which are immediate children of the room -- on the floor, as it were. Nothing happens for objects on supporters or in containers.
The last of the descriptive properties, describe can contain a string, but really requires a routine. If present, it runs before initial or when_XXX. If it returns false, any other description is then generated; if it returns true, that's all you get. It's a bit of a specialized property, not one for which a natural example is easy to contrive.
If you think about it, the label object doesn't contribute much to the game. Its solitary task is to respond to EXAMINE LABEL commands, and these only come about because the bottle's description happens to mention a label. That is, the bottle is a real object, so we try to give it a convincing description. Unfortunately, in doing so we're likely to imply the existence of sub-objects, in which the player may well take an interest. It's bad game design to respond "You can't see any such thing." when the player tries to EXAMINE something you've just told him about; therefore, most authors find themselves creating a multiplicity of secondary objects whose only role is to handle EXAMINE requests.
The scenic.h library package -- obtainable from the Archive or from my home page -- offers a partial solution. It enables you to embed 'scenic' items, which support only examination, within the parent object whose description brought them to the player's attention. For example, we could have coded the label like this:
Object bottle "bottle" kitchen_table with description [ liq; liq = ChildWithProp(self,capacity); print "You see an ordinary wine bottle, of green glass, with a faded label and a "; if (cork in self) print "cork protruding from the "; print "slender neck"; if (liq ~= 0) print ". There is a quantity of liquid inside"; "."; ] scenic 'faded' 'label' 'lable' 0 "Though somewhat faded and difficult to make out, the label seems to read ~Chat Eau~." has transparent;
This is a simple case; scenic.h is of more value when the alternative is to create a whole handful of secondary objects.
Right, we can't put it off any longer. Time to talk about the Class directive and the class segment.