Known objects vs. unknown objects

Something that keeps jumping out at me:

> touch blanket
The wool of the blanket is warm and comforting on the frigid night.

> n
You walk north.

Storage Room
The walls are lined with bare metal shelves, rusting away. Mounted to the wall is a control panel for the building's emergency lights. They are switched on. Rows of crumbling shelving support hundreds of cans
of food, the labels long since aged away. The break room lies back to the south and a utility ladder climbs through a broken skylight to the roof.

> touch blanket
(I only understood you as far as wanting to feel something.)


It feels like the stdlib might handle this differently; currently the blanket is out of scope so the word “blanket” becomes meaningless to the parser. I’d kind of prefer if the stdlib, having seen/described/interacted with the blanket previously and successfully, would instead say I don't see a blanket here.

1 Like

In Inform, it looks like:

An Interactive Fiction by Howard M. Lewis Ship
Release 1 / Serial number 200211 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD

You can see a blanket here.

>touch blanket
You feel nothing unexpected.



>touch blanket
You can't see any such thing.

… which may just be a difference in the error message, rather than significant differences in logic.

1 Like

That’s the request, I guess. Inform follows the classic “out of sight, out of mind” rule, and it looks like Dialog does too.

The alternative would be to keep known objects in scope (even when they’re elsewhere in the game), so that you can print errors like “I don’t see [the specific item] here.” This has been discussed before, obviously. The trick is that you really want such items to be handled at a lower priority in disambiguation. Otherwise you get towards the end of a large game and “GET ROCK” produces “Which do you mean, the small rock, the small cracked rock, the rock wall of the chasm, the rock music from that tavern in Chapter 1, …”

Inform’s disambiguation was never quite good enough to make this practical. I’d also worry about speed issues, although to some extent Inform has already lost that battle for very large games.

1 Like

I still get tripped up by how instant everything is, unlike playing Infocom games on my Atari 800 (30+ year old memories so who can say).

1 Like

Should be noted that Inform’s “You can’t see any such thing” response to >TOUCH BLANKET doesn’t take the blanket item into account in any way, the response would be the same to >TOUCH ASDFG or any other words after the verb, as long as it doesn’t match anything in current scope.

Inform does consider a difference between verbs that do and don’t require a noun, so >SLEEP UNDER BLANKET would give an “I only understood you as far as wanting to sleep” response (regardless of where the blanket is.) Based on the transcript in the first post, it looks like Dialog doesn’t make this distiction.

In some systems (Hugo, TADS) there’s a third option when the command includes words that don’t exit in the game’s vocabulary at all, so >TOUCH ASDFG would print “You don’t need to use the word “asdfg” in this game” or something similar. Whether the player has seen the object or not doesn’t make a difference. Some authors don’t like this feature because it might reveal hidden information too early.

1 Like

To clarify, the Dialog library does distinguish between a situation where the verb was understood (“I only understood you as far as wanting to feel something”, as quoted in the original post) and a situation where nothing was understood (“I’m sorry, I didn’t understand what you wanted to do”). But it behaves in the same way whether or not there is a grammar rule for the same verb without an object—it doesn’t make this distinction. Is this what you meant?

Incidentally, Dialog can also report on a partial understanding where the unrecognized bit is in the middle. So, “PUT ASDFG IN BOX” might result in “I only understood you as far as wanting to put something in the ivory box”. As far as I can see, this is not done by Inform 7, at least not by default.

In the upcoming 0j version of the language, there will be a built-in predicate for checking whether a word typed by the player was present in the game dictionary or not. This will make it possible to implement a message such as “You don’t need to use the word ‘asdfg’ in this game”.

Returning to the original request, I’m not sure I want to add this to the standard library, in part because it would affect the performance of the parser. However, it can be implemented as a modification. One would have to track what objects the player has encountered using a new flag, perhaps ($ is encountered). As a first approximation, one could do:

(on every tick)
        *($Obj is in scope)
        ~($Obj is hidden)
        (now) ($Obj is encountered)

Then, one would have to make the parser understand those objects. Rather than placing them in scope, I would suggest modifying (parse object name $ as $ $ $) to consider objects that are encountered rather than objects that are in scope. That is:

        %% this is the normal case
        (determine object $Obj)
                *($Obj is encountered)
                ~(direction $Obj)

Then, one should indicate that it is very unlikely that the player is referring to such objects:

(very unlikely $Action)
        *($Obj is one of $Action)
        ~($Obj is in scope)

Note that the above rule needs to have exceptions for actions that take “any” object, such as “FIND”. Furthermore, the built-in verbs that act on rooms are already disabling (very unlikely $) altogether. This needs to be handled a bit more carefully now, either by replacing the negated rule with something a bit more specific:

~(very unlikely [enter $Obj])
        (room $Obj)
        ($Obj is in scope)

or by considering the full picture, and putting the logic in one place—which in this case allows it to be simplified:

(very unlikely [enter $Obj])
        ~($Obj is in scope)

Now, all of this is just loose speculation on my part. It’s untested, and I’m sure there are a lot of troublesome details and corner cases. But it could be a starting point.

1 Like