28. Scope and what you can see

He cannot see beyond his own nose. Even the fingers he outstretches from it to the world are (as I shall suggest) often invisible to him.

...Max Beerbohm (1872--1956), of George Bernard Shaw

Wherefore are these things hid?

...William Shakespeare (1564--1616), Twelfth Night

Time to say what "in scope" means. This definition is one of the most important rules of play, because it decides what the player is allowed to refer to. You can investigate this in practice by compiling any game with the debugging suite of verbs included and typing "scope'' in different places: but here are the rules in full. The following are in scope:

the player's immediate possessions;
the 12 compass directions;
if there is light (see Section 17), the objects in the same 'enclosure' as the player;
if not, any objects in the thedark object; if the player is inside a dark container, then that container.

In addition, if an object is in scope then its immediate possessions are in scope, if it is 'see-through', which means that:

the object has supporter, or
the object has transparent, or
the object is an open container.

Two library routines are provided to enable you to see what's in scope and what isn't. The first, TestScope(obj, actor), simply returns true or false according to whether or not obj is in scope. The second is LoopOverScope(routine, actor) and calls the given routine for each object in scope. In each case the actor given is optional; if it's omitted, scope is worked out for the player as usual.

Formally, scope determines what you can talk about, which usually means what you can see. But what can you touch? Suppose a locked chest is inside a sealed glass cabinet. The Inform parser will allow the command "unlock chest with key'' and generate the appropriate action, Unlock chest key, because the chest is in scope, so the command at least makes sense.

But it's impossible to carry out, because the player can't reach through the solid glass. So the library's routine for handling the Unlock action needs to enforce this. The library does this using a stricter rule called "touchability''. The rule is that you can touch anything in scope unless there's a closed container between you and it. This applies either if you're in the container, or if it is.

Some purely visual actions don't require touchability -- Examine or LookUnder, for instance. But most actions are tactile, and so will many actions created by designers. If you want to make your own action routines enforce touchability, you can call the library routine ObjectIsUntouchable(obj). This either returns false if there's no problem in touching obj, or returns true and prints a suitable message (such as "The solid glass cabinet is in the way.''). Thus, the first line of many of the library's action routines is:

    if (ObjectIsUntouchable(noun)) return;

The rest of this section is about how to change the scope rules. As usual with Inform, you can change them globally, but it's more efficient and safer to work locally. To take a typical example: how do we allow the player to ask questions like the traditional "what is a grue'' ? The "grue'' part ought to be parsed as if it were a noun, so that we could distinguish between, say, a "garden grue'' and a "wild grue''. So it isn't good enough to look only at a single word. Here is one solution:

Object questions "qs";
[ QuerySub; print_ret (string) noun.description;
];
[ Topic i;
  switch(scope_stage)
  {   1: rfalse;
      2: objectloop (i in questions) PlaceInScope(i); rtrue;
      3: "At the moment, even the simplest questions confuse you.";
  }
];

Object q1 "long count" questions
  with name "long" "count",
       description "The Long Count is the great Mayan cycle of time,
           which began in 3114 BC and will finish with the world's end
           in 2012 AD.";

Verb "what"
                * "is"  scope=Topic              -> Query
                * "was" scope=Topic              -> Query;

When the parser reaches

scope=Topic

, it calls the Topic routine with the variable scope_stage set to 1. The routine should return 1 (true) if it is prepared to allow multiple objects to be accepted here, and 0 (false) otherwise: as we don't want "what is everything'' to list all the questions and answers in the game, we return false.

A little later on in its machinations, the parser again calls Topic with scope_stage now set to 2. Topic is now obliged to tell the parser which objects are to be in scope. It can call two parser routines to do this.

ScopeWithin(object)

PlaceInScope(object)

0 -- (false) to carry on with the usual scope rules, so that everything that would usually be in scope still is, or

1 -- (true) to tell the parser not to put any more objects into scope.

So at scope_stage 2 it is quite permissible to do nothing but return false, whereupon the usual rules apply. Topic returns true because it wants only question topics to be in scope, not question topics together with the usual miscellany near the player.

This is enough to deal with "what is the long count''. If on the other hand the player typed "what is the lgon cnout'', the error message which the parser would usually produce ("You can't see any such thing'') would be unsatisfactory. So if parsing failed at this token, then Topic is called at scope_stage 3 to print out a suitable error message. It must provide one.

Changing the global definition of scope should be done cautiously (there may be unanticipated side effects); bear in mind that scope decisions need to be taken often -- every time an object token is parsed, so perhaps five to ten times in every game turn -- and hence moderately quickly. The global definition can be tampered with by providing the entry point

InScope(actor)

Here are some examples. Firstly, as promised, how to change the rule that "things you've just dropped disappear in the dark":

[ InScope person i;
  if (person==player && location==thedark)
      objectloop (i near player)
          if (i has moved)
              PlaceInScope(i);
  rfalse;
];