Continuing my Inform7 adventure. Looking into the way Inform handles scope.
The Inform7 documentation states in §18.29. Deciding the scope of something that the default behaviour is complicated and refers me to the Inform Designer’s Manual, 4th edition, page 227. The relevant part is in §32 Scope and what you can see:
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:
the compass directions;
the player’s immediate possessions;
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);
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’);
if the player is inside a container, then that container;
if O is in scope and is see-through (see §21), then the contents of O;
if O is in scope, then any object which it “adds to scope” (see below).
So to make sure I understand how it works I created a small test:
The Test Lab is a room. It is dark.
The player carries a backpack.
The backpack is a closed openable container.
The glass jar is a closed openable transparent container in the backpack.
The apple is in the glass jar. It is edible.
Then I tried the following:
Darkness
It is pitch dark, and you can't see a thing.
>i
You are carrying:
a backpack (closed)
>open backpack
You open the backpack, revealing a glass jar.
>i
You are carrying:
a backpack (open)
a glass jar (closed)
an apple
>eat apple
The glass jar isn't open.
>open jar
You open the glass jar.
>eat apple
(first taking the apple)
You eat the apple. Not bad.
>
Now it may be just me, but the revealing a glass jar bit and the fact we can somehow ‘see’ it contains an apple does not really make sense to me.
Does anyone have any experience in creating a more “realistic” approach to scope?
The ‘contents of a transparent closed carried container in darkness are in scope’ quirk is a longstanding unrevised bug/feature of the language- which I recently mentioned again to @GrahamNelson alongside the other quirks mentioned here. It’s a matter of reasonable debate the extent to which invisible possessions, particularly direct possessions, should nevertheless be routinely identifiable to their owner. Sight is not the only sense. I’m not sure whether anything will be changed. Graham naturally has his own views on the rights and wrongs of these things and it’s ultimately his call.
If these edge cases really bug you, you can manually remove things from scope by using Scopability extension by Brady Garvin or add them to scope using After Deciding the Scope rules.
Realism, which is what you seem to be most focused on right now. (But do also consider sight vs. other senses, as already mentioned.)
Complexity (both at runtime and for authors). Scope is already not too easy to wrap your head around. In a large game, determining scope can already take a significant amount of processing time. Adding more rules like “when opening a container in the dark, only place those things into scope that have been previously seen” may be more trouble than it’s worth for most games.
Game Winnability. Imagine if the lights went out but you couldn’t turn on your flashlight because it’s in your backpack but the contents of the backpack aren’t in scope in the dark. (The weight of this argument will vary depending on your stance towards UNDO.)
I don’t think that the current behavior should be considered a bug (in the sense that it could be called “objectively wrong”). It’s a tradeoff, as I said, and I doubt that you’ll be able to find a behavior that will make everybody happy. It’s just a shame that these rules remain relatively hard to change in I7.
Indeed. One can make an oblique argument, for example, that an actor is most likely to be aware of the contents of a closed transparent container in the dark (as opposed to an opaque one), in that it’s most likely that they’ve seen the contents before the lights went out. That won’t ALWAYS be the case, of course, and sometimes the actor will be well aware of the contents of closed opaque containers too (as in your flashlight stowed in the backpack example), so the current behaviour can be defended as the best compromise without the added complication of instituting a system for tracking what has been seen by every actor.
I think it’s more difficult to defend the fact that darkness doesn’t affect scope for NPCs at all, who can therefore accomplish tasks in darkness which are impossible for the player…
It might be reasonable to make a “revealing the contents of (a container)” an activity, which would at least give a convenient hook for anyone who did want to tackle customizing the behavior.
Ideally, something like Epistimelogy would be in place, or, better, Remembering, to track whether or not the player already knew what was inside. Surely it would be worth special mention if last time you looked, it had walnuts in it and now it had chess pieces.
If that is ever likely to happen. In most stories, it just won’t. If it’s going to happen in your story, you can code for it. I guess this a judgment call (in common with many others in the Standard Rules) as to how many edge cases to cover in the base World Model and how many to leave to be implemented for the particular requirements of individual stories or as extensions. Hence no standard implementation of fire, or money for example.
Inevitably, to an extent what is implemented represents the interests, and preferences and use cases of the developers. For example, how many stories need the implementation of equations, or units, or functional programming, I wonder?
Which, for me is OK as long as the World Model implementation doesn’t in implementing its own rules make it unnecessarily difficult to code the edge cases or extensions.
I’m not thinking of walnuts → chess pieces as something the world model should handle by default, but something someone customizing via an imagined revealing the contents of activity might want to account for. To support a case a like that, and for a zillion other use cases, I do think it’d be appropriate for tracking player knowledge to be something baked-in.
I agree, this would be a cool standard feature. After all, there’s been the handled/not handled visited/not visited attributes since the early days of I6, so it feels the time may be ripe for progress in this area.
It would dovetail neatly with the big conversation expansion WIP.