Section 17: The light and the dark

Contents Back Forward | ### 17. The light and the dark
| The library maintains light by itself, and copes with events like: a total eclipse of the sun; fusing all the lights in the house; your lamp going out; a dwarf stealing it and running away; dropping a lit match which you were seeing by; putting your lamp into an opaque box and shutting the lid; black smoke filling up the glass jar that the lamp is in; the dwarf with your lamp running back into your now-dark room. The point of this list is to demonstrate that light versus darkness is tricky to get right, and best left to the library. Your code needs only to do something like
    give lamp light;
    remove match;
    give glass_jar ~transparent;
    move dwarf to Dark_Room;
and can leave the library to sort out the consequences. As the above suggests, the `light` attribute means that an object is giving off light, or that a room is currently lit, e.g. because it is outdoors in day-time. If you simply never want to have darkness, a sneaky way of doing it is to put the line
    give player light;
in `Initialise`. The game works as if the player herself were glowing enough to provide light to see by. So there's never darkness near the player. The definition of "when there is light" is complicated, involving recursion both up and down. Remember that the parent of the player object may not be a room; it may be, say, a red car whose parent is a room. Definition.`` There is light exactly when the parent of the player 'offers light'. An object 'offers light' if: it itself has the `light` attribute set, or any of its immediate possessions 'have light', or it is see-through and its parent offers light; while an object 'has light' if: it currently has the `light` attribute set, or it is see-through and one of its immediate possessions has light, or any of the things it "adds to scope'' (see Chapter V) have light. The process of checking this stops as soon as light is discovered. The routines `OffersLight(object)` and `HasLightSource(object)` return true or false and might occasionally be useful.
| So light is cast up and down the tree of objects. In certain contrived circumstances this might be troublesome: perhaps an opaque box, whose outside is fluorescent but whose interior is dark, and which contains an actor who needs not to have other contents of the box in scope... The dilemma could be solved by putting an inner box in the outer one.
| EXERCISE 32: (link to the answer)
| How would you code a troll who is afraid of the dark, and needs to be bribed but will only accept a light source... so that the troll will be as happy with a goldfish bowl containing a fluorescent jellyfish as he would be with a lamp? Each turn, light is reconsidered. The presence or absence of light affects the `Look`, `Search`, `LookUnder` and `Examine` actions, and (since this is a common puzzle) also the `Go` action: you can provide a routine called
    DarkToDark()
and if you do then it will be called when the player goes from one dark room into another dark one (just before the room description for the new dark room, probably "Darkness'', is printed). If you want, you can take the opportunity to kill the player off or extract some other forfeit. If you provide no such routine, then the player can move about freely (subject to any rules which apply in the places concerned).
| When the player is in darkness, the current `location` becomes `thedark`, a special object which acts like a room and has the short name "Darkness''. You can change the `initial`, `description` or `short_name` properties for this. For example, your `Initialise` routine might set
        thedark.short_name = "Creepy, nasty darkness";
See Section 18 for how 'Ruins' makes darkness menacing.
| EXERCISE 33: (link to the answer)
| Implement a pet moth which escapes if it's ever taken into darkness.
| REFERENCES: For a `DarkToDark` routine which discourages wandering about caves in the dark, see 'Advent'.

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.