Chapter 2: Rooms & Scenery

As explained in Chapter 1 (see “What Happens in a Game,” here), the model world in which your story takes place will be divided neatly into rooms. For the purposes of IF, a “room” might be not a kitchen or living room but a football field or a phone booth.¹ The same word is used in each case. Some people feel that the word “room” is misleading, but we have to call the places where things happen by some name or other, and the word “room” has been used for this purpose for a long time.

Although the characters (including the player) can travel from room to room, for most purposes other than travel we can think of each room as a sealed box. When the player is in a given room, she will be able to see, touch, and use the things that are in that room. But everything in every other room will be invisible and out of reach. In fact, if the player tries to refer to something that’s not in the current room, the parser (the software in the game engine that interprets what the player types) will usually pretend that the object the player referred to doesn’t exist.

This is usually what’s needed in a game, but sometimes having a room operate like a sealed container won’t give you the results you’re hoping for. If the “room” is a tree limb high in a tree, for example, when the player drops something we would expect it not to land on the limb. Rather, it should fall to the forest floor far below.

You’ll find that there are two or three ways to work around the limitations imposed by the sealed-room metaphor. If the player is at the north end of an open field, for instance, you may want him to be able to see (but not touch) the things that are at the south end of the field. Later in this chapter, in the section “The Great Outdoors,” we’ll suggest some ways to do this. There are also some exceptions that come into play when you’re designing a conversation system to let the player talk to other characters: You can easily allow ASK BOB ABOUT THE JEWELS to work as expected even if the jewels themselves are not in the room. (The techniques for doing this are explained in Chapters 4 and 5 — see here and here.) In most situations, though, an object has to be in the room with the player in order for the player to do anything with it or even see it.

This concept is one of the most basic in interactive fiction. It’s called scope. An object is “in scope” if the player character can see and/or touch it; otherwise it’s “not in scope.” The parser is responsible for enforcing the rules of scope. If the parser pretends not to know about a given object when the player refers to it, it’s because the object is not in scope. This will most likely happen because the object is in a different room. But it can also happen because the object is in a closed container in the room. If the room is dark, the object might be in the room but not available for the player to interact with. If the player character is tied to a chair, things in the room may be visible (that is, in scope for purposes of the EXAMINE command) but not touchable. Enforcing the proper limitations on player interaction is partly handled by Inform, but as your story becomes more complex you may find that you need to handle some of the more awkward situations yourself.

By convention, everything in a room is assumed to be equally within reach of the player character, with a couple of exceptions. As we’ll see in Chapter 3, objects can be placed in locations that are out of reach, so that the player can look at them but not touch them. In addition, the player character may be seated on a chair or lying in a hammock in the room, in which case she will have to STAND UP before interacting with objects. In general, though, rooms have three standard characteristics: Everything in the room is equally available for examining, touching, or other manipulation; the player character is not facing any particular direction; and things that are dropped end up on the floor. All of these conventions can be changed, but experienced IF players will take them for granted, and there’s usually no need to concern yourself with them — especially not when writing your first game.

1 A phone booth could also be created as an enterable container within the main room — see the section on “Enterable Containers & Supporters” in Chapter 3 of the Handbook. ↩