Section 14: Things to enter, travel in and push around

Contents Back Forward | ### 14. Things to enter, travel in and push around
| ...the need to navigate a newly added river prompted the invention of vehicles (specifically, a boat). ...P. David Lebling, Marc Blank and Timothy Anderson Some objects in a game are `enterable`, which means that a player can get inside or onto them. Usually, "inside" means that the player is only half-in, as with a car or a psychiatrist's couch. (If it's more like a prison cell, then it should be a separate place.) In practice one often wants to make an `enterable` thing also a `container`, or, as in the altar from 'Ruins', a `supporter`:
    Object -> stone_table "slab altar"
      with name "stone" "table" "slab" "altar" "great",
           initial "A great stone slab of a table, or altar, dominates the Shrine.",
      has  enterable supporter;
A chair to sit on, or a bed to lie down on, should also be a `supporter`. If the player gets into a `container` and then closes it, the effect is like being in a different location. (Unless the container has the `transparent` attribute and is therefore see-through.) The interior may be dark, but if there's light to see by, the player will want to see some kind of room description. In any case, many enterable objects ought to look different from inside or on top. Inside a vehicle, a player might be able to see a steering wheel and a dashboard, for instance. On top of a cupboard, it might be possible to see through a skylight window. For this purpose, any `enterable` object can provide an `inside_description`, which can be a string or a routine to print one, as usual. If the exterior location is still visible, then the "inside description'' is added to the normal room description, and otherwise it becomes that description. As an extreme example, suppose that the player gets into a huge cupboard, closes the door behind her and then gets into a plastic cabinet inside that. The resulting room description might read like so: The huge cupboard (in the plastic cabinet) It's a snug little cupboard in here, almost a room in itself. In the huge cupboard you can see a pile of clothes. The plastic walls of the cabinet distort the view. The second line is the `inside_description` for the huge cupboard, and the fourth is that for the plastic cabinet.
| EXERCISE 14: (link to the answer)
| (Also from 'Ruins'.) Implement a cage which can be opened, closed and entered. All the classic games have vehicles (like boats, or fork lift trucks, or hot air balloons) which the player can journey in, so Inform makes this easy. Here is a simple case:
    Object car "little red car" cave
      with name "little" "red" "car",
           description "Large enough to sit inside.  Among the controls is a
               prominent on/off switch.  The numberplate is KAR 1.",
           when_on  "The red car sits here, its engine still running.",
           when_off "A little red car is parked here.",
           before
           [; Go: if (car has on) "Brmm!  Brmm!";
                  print "(The ignition is off at the moment.)^";
           ],
      has  switchable enterable static container open;
Actually, this demonstrates a special rule. If a player is inside an `enterable` object and tries to move, say "north", the `before` routine for the object is called with the action `Go`, and `n_obj` as the noun. It may then return: 0`` to disallow the movement, printing a refusal; 1`` to allow the movement, moving vehicle and player; 2`` to disallow but print and do nothing; or 3`` to allow but print and do nothing. If you want to move the vehicle in your own code, return 3, not 2: otherwise the old location may be restored by subsequent workings. Because you might want to drive the car "out'' of a garage, the "out'' verb does not make the player get out of the car. Usually the player has to type something like "get out'' to make this happen, though of course the rules can be changed.
| EXERCISE 15: (link to the answer)
| Alter the car so that it won't go east.
| Objects like the car or, say, an antiquated wireless on casters, are obviously too heavy to pick up but the player should at least be able to push them from place to place. When the player tries to do this, the `PushDir` action is generated. Now, if the `before` routine returns false, the game will just say that the player can't; and if it returns true, the game will do nothing at all, guessing that the `before` routine has already printed something more interesting. So how does one actually tell Inform that the push should be allowed? The answer is that one has to do two things: call the `AllowPushDir` routine (a library routine), and then return true. For example ('Ruins' again):
    Object -> huge_ball "huge pumice-stone ball"
      with name "huge" "pumice" "pumice-stone" "stone" "ball",
           description "A good eight feet across, though fairly lightweight.",
           initial
               "A huge pumice-stone ball rests here, eight feet wide.",
           before
           [;  PushDir:
                   if (location==Junction && second==w_obj)
                       "The corridor entrance is but seven feet across.";
                   AllowPushDir(); rtrue;
               Pull, Push, Turn: "It wouldn't be so very hard to get rolling.";
               Take, Remove: "There's a lot of stone in an eight-foot sphere.";
           ],
           after
           [;  PushDir:
                  if (second==s_obj) "The ball is hard to stop once underway.";
                  if (second==n_obj) "You strain to push the ball uphill.";
           ],
      has  static;
| EXERCISE 16: (link to the answer)
| The library does not normally allow pushing objects up or down. How can the pumice ball allow this?
| REFERENCES: For an `enterable` `supporter` puzzle, see the magic carpet in 'Balances' (and several items in 'Alice Through The Looking-Glass').

Contents / Back / Forward
Chapter I / Chapter II / Chapter III / Chapter IV / Chapter V / Chapter VI / Appendix

Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.