§8   Places and scenery

In this longer chapter the model world of an Inform game will be explored and examples will gradually complete the ‘Ruins’ begun in Chapter II. So far, ‘Ruins’ contains just a location of rainforest together with some rules about photography. The immediate need is for a more substantial map, beginning with a sunken chamber. Like the Forest, this too has light, however dim. If it didn't, the player would never see it: in Inform's world darkness prevails unless the designer provides some kind of lamp or, as in this case, ambient light.

Object Square_Chamber "Square Chamber"
  with name 'lintelled' 'lintel' 'lintels' 'east' 'south' 'doorways',
       description
           "A sunken, gloomy stone chamber, ten yards across. A shaft
           of sunlight cuts in from the steps above, giving the
           chamber a diffuse light, but in the shadows low lintelled
           doorways to east and south lead into the deeper darkness
           of the Temple.",
  has  light;

This room has a name property even though rooms are not usually referred to by players. The nouns given are words which Inform knows “you don't need to refer to”, and it's a convention of the genre that the designer should signpost the game in this way. For the game to talk about something and later deny all knowledge – “I can't see any such thing” – is not merely rude but harmful to the player's illusion of holding a conversation about a real world. Better to parry with:

>examine lintel
That's not something you need to refer to in the course of this game.

· · · · ·

Not all of the Square Chamber's décor is so irrelevant:

Object -> "carved inscriptions"
  with name 'carved' 'inscriptions' 'carvings' 'marks' 'markings'
           'symbols' 'moving' 'scuttling' 'crowd' 'of',
       initial
           "Carved inscriptions crowd the walls, floor and ceiling.",
       description
           "Each time you look at the carvings closely, they seem
           to be still. But you have the uneasy feeling when you
           look away that they're scuttling, moving about. Two
           glyphs are prominent: Arrow and Circle.",
  has  static pluralname;

The static attribute means that the inscriptions can't be taken or moved. As we went out of our way to describe a shaft of sunlight, we'll include that as well:

Object -> sunlight "shaft of sunlight"
  with name 'shaft' 'of' 'sunlight' 'sun' 'light' 'beam' 'sunbeam'
           'ray' 'rays' 'sun^s' 'sunlit' 'air' 'motes' 'dust',
       description
           "Motes of dust glimmer in the shaft of sunlit air, so
           that it seems almost solid.",
  has  scenery;

The ^ symbol in "sun^s" means an apostrophe, so the word is “sun's”. This object has been given the constant name sunlight because other parts of the ‘Ruins’ source code will need to refer to it later on. Being scenery means that the object is not only static but also not described by the game unless actually examined by the player. A perfectionist might add a before rule:

before [;
    Examine, Search: ;
    default: "It's only an insubstantial shaft of sunlight.";
],

so that the player can look at or through the sunlight, but any other request involving them will be turned down. Note that a default rule, if given, means “any action except those already mentioned”.

▲ Objects having scenery are assumed to be mentioned in the description text of the room, just as the “shaft of sunlight” is mentioned in that of the Square Chamber. Giving an object concealed marks it as something which is present to a player who knows about it, but hidden from the casual eye. It will not be cited in lists of objects present in the room, and “take all” will not take it, but “take secret dossier”, or whatever, will work. (Designers seldom need concealed, but the library uses it all the time, because the player-object is concealed.)

· · · · ·

Some scenery must spread across several rooms. The ‘Ruins’, for instance, are misty, and although we could design them with a different “mist” object in every misty location, this would become tiresome. In ‘Advent’, for instance, a stream runs through seven locations, while mist which (we are told) is “frequently a sign of a deep pit leading down to water” can be found in ten different caves. Here is a better solution:

Object low_mist "low mist"
  with name 'low' 'swirling' 'mist',
       description "The mist has an aroma reminiscent of tortilla.",
       found_in  Square_Chamber  Forest,
       before [;
           Examine, Search: ;
           Smell: <<Examine self>>;
           default: "The mist is too insubstantial.";
       ],
  has  scenery;

The found_in property gives a list of places in which the mist is found: so far, just the Square Chamber and the Forest.

▲ This allows for up to 32 misty locations. If scenery has to be visible even more widely than that, or if it has to change with circumstances (for instance, if the mist drifts) then it is simpler to give a routine instead of a list. This can look at the current location and say whether or not the object should be present, as in the following example from a game taking place at night:

Object Procyon "Procyon",
  with name 'procyon' 'alpha' 'canis' 'minoris' 'star',
       description "A double-star eleven light years distant.",
       found_in [;
           return (location ofclass OutsideRoom);
       ],
  has  scenery;

found_in is only consulted when the player's location changes, and works by moving objects around to give the illusion that they are in several places at once: thus, if the player walks from a dark field to a hilltop, Procyon will be moved ahead to the hilltop just in advance of the player's move. This illusion is good enough for most practical purposes, but sometimes needs a little extra work to maintain, for instance if the sky must suddenly cloud over, concealing the stars. Since it often happens that an object must be removed from all the places in which it would otherwise appear, an attribute called absent is provided which overrides found_in and declares that the object is found nowhere. Whatever change is made to found_in, or in giving or removing absent, the Inform library needs also to be notified that changes have taken place. For instance, if you need to occult Procyon behind the moon for a while, then:

give Procyon absent; MoveFloatingObjects();

The library routine MoveFloatingObjects keeps the books straight after a change of state of found_in or absent.

· · · · ·

Whereas Procyon is entirely visual, some scenery items may afflict the other four senses. In ‘Ruins’, the Forest contains the rule:

before [;
    Listen: "Howler monkeys, bats, parrots, macaw.";
],

Besides which, we have already said that the mist smells of tortilla, which means that if the player types “smell” in a place where the mist is, there should clearly be some reaction. For this, a react_before rule attached to the mist is ideal:

react_before [;
    Smell: if (noun == nothing) <<Smell self>>;
],

This is called a “react” rule because the mist is reacting to the fact that a Smell action is taking place nearby. noun is compared with nothing to see if the player has indeed just typed “smell” and not, say, “smell crocus”. Thus, when the action Smell takes place near the mist, it is converted into Smell low_mist, whereas the action Smell crocus would be left alone.

The five senses all have actions in Inform: Look, Listen, Smell, Taste and Touch. Of these, Look never has a noun attached (because Examine, LookUnder and Search are provided for close-up views), Smell and Listen may or may not have while Taste and Touch always have.

• EXERCISE 6
(Cf. ‘Spellbreaker’.) Make an orange cloud descend on the player, which can't be seen through or walked out of.

· · · · ·

Rooms also react to actions that might occur in them and have their own before and after rules. Here's one for the Square Chamber:

before [;
    Insert:
        if (noun == eggsac && second == sunlight) {
            remove eggsac; move stone_key to self;
            "You drop the eggsac into the glare of the shaft of
            sunlight. It bubbles obscenely, distends and then
            bursts into a hundred tiny insects which run in all
            directions into the darkness. Only spatters of slime
            and a curious yellow-stone key remain on the chamber
            floor.";
        }
],

(The variables noun and second hold the first and second nouns supplied with an action.) As it happens this rule could as easily have been part of the definition of the eggsac or the sunlight, but before and after rules for rooms are invaluable to code up geographical oddities.

• EXERCISE 7
Create a room for ‘Ruins’ called the Wormcast, which has the oddity that anything dropped there ends up back in the Square Chamber.

▲ Sometimes the room may be a different one after the action has taken place. The Go action, for instance, is offered to the before routine of the room which is being left, and the after routine of the room being arrived in. For example:

after [;
    Go: if (noun == w_obj)
        print "You feel an overwhelming sense of relief.^";
],

will print the message when its room is entered from the “west" direction. Note that this routine returns false, in the absence of any code telling it to do otherwise, which means that the usual game rules resume after the printing of the message.

• REFERENCES
‘A Scenic View’ by Richard Barnett demonstrates a system for providing examinable scenery much more concisely (without defining so many objects).   •found_in can allow a single object to represent many different but similar objects across a game, and a good example is found in Martin Braun's "elevator.inf" example game, where every floor of a building has an up-arrow and a down-arrow button to summon an elevator.