As I suspect you’ve noticed, the I7 documentation avoids detailed discussion of scope, referring interested writers to the I6 DM4 documentation, which at least implies that the definition hasn’t changed between I6 and I7. The DM4 has this to say:
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 experimentally by
compiling any game with the debugging suite of verbs included (see
§7) and typing "scope’’ in interesting places."In scope’’ roughly means "the compass directions, what you’re carrying and what you can see’'.
It exactly means this:
(1) the compass directions;
(2) the player’s immediate possessions;
(3) if there is light, then the contents of the player’s visibility ceiling (see §21 for
definition, but roughly speaking the outermost object containing the player which
remains visible, which is usually the player’s location);
(4) if there is darkness, then the contents of the library’s object thedark (by default
there are no such contents, but some designers have been known to move objects
into thedark: see `Ruins’);
(5) if the player is inside a container, then that container;
(6) if O is in scope and is see-through (see §21), then the contents of O;
(7) if O is in scope, then any object which it "adds to scope’’ (see below).with the proviso that the InScope entry point (see below) can add to or replace
these rules, if you write one.It’s significant that rule (3) doesn’t just say "whatever is in the current
location’'. For instance, if the player is in a closed cupboard in the Stores
Room, then rule (3) means that the contents of the cupboard are in scope, but
other items in the Stores Room are not.
Even in darkness the player’s possessions are in scope, so the player can
still turn on a lamp being carried. On the other hand, a player who puts the
lamp on the ground and turns it off then loses the ability to turn it back on
again, because it is out of scope. This can be changed; see below.Compass directions make sense as things as well as directions, and they respond
to names like "the south wall’’ and "the floor’’ as well as "south’’ and "down’'.
The concealed attribute only hides objects from room descriptions, and doesn’t
remove them from scope. If you want things to be unreferrable-to, put them somewhere
else!The small print:
- For "player’‘, read "actor’‘. Thus "dwarf, drop sword’’ will be accepted if the dwarf can see the sword even if the player can’t.
- Scope varies depending on the token being parsed: for the [multi-] tokens, compass directions are not in scope; for [multiexcept] the other object isn’t in scope; for [multiinside] only the contents of the other object are in scope.
Some further notes expanding on scope in the context of I7:
-
Rule (1) is hard-coded outside of the main scoping system, such that testing directions such as ‘North’ for being in scope (using the I6 routine TestScope) anomalously returns false unless they are manually added to scope, e.g. ‘Place North in scope’ in an ‘After deciding the scope’ rule.
-
Regions and Rooms, including the current location, are never ‘visible’ and are in scope only if manually added to scope in an ‘After deciding the scope’ rule. Placing a Region in scope does not bring rooms or anything else in that region into scope.
-
Doors and Backdrops in the location are both ‘visible’ and in scope when there is light (unless the player is in an opaque, closed container), but neither when in darkness. Conversely, for characters other than the player doors and backdrops are visible (in the light) and in scope only if their current location happens to coincide with that of the non-player character.
-
Objects placed in scope (directly- or indirectly such as the contents of a room placed in scope) with the phrase ‘place (object) in scope’ in an ‘After deciding the scope’ rule do not necessarily become ‘visible’ as a result- they will be ‘visible’ only if the actor is illuminated.
-
A combination of Rules (2) & (6) leads to a bug which remains uncorrected- the contents of a carried closed transparent container (e.g. a starfish in a closed jam-jar) is no longer ‘visible’ but remains in scope when in darkness.
-
Interestingly, a combination of rules (5) & (6) does not lead to a similar anomaly- a player in a transparent shower cubicle will be unable to find the soap if the bathroom light is switched off, even though they can open or close the cubicle.
-
Rule (6) refers only to the direct contents of (O)- so anything enclosed by an opaque, closed container that is in (O) will, as might be expected, be out of scope.
-
For characters other than the player, objects that are not possessions can remain in scope even in darkness. Thus, although ‘take the sword’ will fail, ‘dwarf, take the sword’ followed by ‘dwarf, give me the sword’ will succeed if player, dwarf and sword are together in a dark room- as long as the dwarf is placed in scope to be spoken to and the rule that usually blocks giving of things is disabled! ‘If the dwarf can see the sword’ is false, however. This also feels like a bug, particularly as it seems a contradiction to small print 1. in that it seemingly doesn’t matter whether the dwarf can see the sword.
-
When in darkness, Rule (4) suggests that the contents of the I6 object ‘thedark’ are in scope. Its I7 equivalent name is ‘(darkness object)’ (brackets included) but this object is not generally accessible when writing in I7. Should the author finesse this by making an I7 variable equivalent to the I6 object “thedark”, or through other hackery, it turns out that in I7 objects in the dark are considered ‘off-stage’ so remain out of scope unless deliberately ‘placed in scope’.
-
The closest functional I7 equivalent of the I6 property ‘add_to_scope’ referenced here is the incorporation relation (‘is a part of’) - although differently implemented.
-
The I6 ‘concealed’ attribute is equivalent to the better-named I7 ‘undescribed’ property, not the concealment relation. An item which is concealed via the I7 concealment relation is not ‘visible’ or in scope, but an undescribed item is both ‘visible’ and in scope. An exception is immediate possessions that the actor conceals, which (following rule (2)) are nevertheless in scope for the actor- but anything they themselves conceal and the contents thereof are not (i.e. rule (6) applies). This last point reflects a rule governed by rule (6), whereby objects enclosed by concealed (and therefore out-of-scope) objects are also both out of scope and invisible.
-
When a player or NPC is in/on an enterable container/supporter alongside certain objects concealed by that container/supporter, those objects remain concealed and they, and their contents, are therefore invisible and out of scope.
-
When a player or NPC is in/on a concealed enterable container/supporter (NB. since rooms can’t conceal things, this concealed container/supporter must be in/on another enterable container/supporter that conceals it) the following unintuitive behaviour is seen:
- A concealed closed container is always in scope to any player or NPC it contains (light makes no difference here).
- A concealed supporter or open container, is always out of scope to any player or NPC it contains/supports EXCEPT in darkness, (i.e. when there is neither internal nor external illumination to the container/supporter), in which case it is in scope to the player but out of scope to an NPC. This means that in darkness you, but not an NPC companion, can close yourself into a cupboard- but then (c.f. 1. above) either of you can then open it- the former being another manifestation of the fact that light/darkness is not considered when determining scope for NPCs.
-
Some of the same I6 routines are used in determining both scope and visibility, which is why it’s easy to get tangled in recursive stack overflows if both are mentioned in the same condition or rule.
-
As noted above, there is a large overlap between ‘visible’ and ‘in scope’ but there are exceptions where objects in scope are not visible:
- when the actor is in darkness, objects directly or indirectly brought into scope by 'Place (object) in scope’.
- when in darkness, the actor and objects enclosed by the actor (unless the enclosed objects are in a closed, opaque container, in which case they’re both out of scope and invisible).
- when in darkness and in/on an enterable container or supporter, that container or supporter (in all cases for the player, for an NPC only in the case of a closed container (an open container or supporter will be both out of scope and invisible to an NPC)).
- directions- which are peculiar in not being visible but always treated as being in scope even though they don’t ordinarily test as such.
- when grammar tokens prefaced by ‘any’ are being considered (e.g. ‘Understand “Go to/-- [any room]” as routegoing’ then all objects matching the description (visible or not) are brought into scope, overriding the usual scoping rules.
- in the case of characters other than the player who are in darkness, things which would be in scope for that character in the light.
-
Conversely, when certain grammar tokens (as noted above) are being considered, some ‘visible’ objects may be excluded from scope. For example [any door] will bring doors which are not ‘visible’ into scope but exclude any ‘visible’ thing which is not a door.
-
As in I6, you can test for the current scope when playing an (unreleased) I7 story by typing ‘scope’. (The list produced of ‘in scope’ objects does not include the compass directions.)
-
I7 does not call or compile an I6 InScope() routine. In I7, the Scopability extension by Brady Garvin allows you to definitively remove objects from scope, while
After deciding the scope of ...rules allow you to add objects to scope.