Is there a reliable way to determine Object visibility to player

Technical Development Interpreters
1

Howdy :slight_smile:

I have written my own ZMachine interpreter and am adding extra “mouse operable” features to reduce the amount of typing required. One of these features is to popup a list of objects currently available for the player to interact with.

I build my list by navigating the object tree for the current location and player, however I don’t want to show objects the player cannot yet “see” or interact with, (eg objects locked inside other objects) in order to reduce “spoilers”.

Each game seems to use a different Attribute No or property for this purpose even if they are of the same zcode version (eg 3). At the moment I have resorted to issuing “behind the scenes” a “look” and “inventory” command and redirecting the output to an internal variable that I then use for scanning comparison against my object list in order to try and determine visibility.

Whilst this works for the most part, I have to save the entire game state and restore it after each automatic command in order to ensure automated triggers (some causing death) and time/move counts are not effected as a result of these extra commands just to popup my list of objects. This of course has its own set of extra issues with synonyms for objects in the text which don’t always directly match the object names. (mostly worked around this)

I have even had my code try to analyse startup routines (as each game does its own look on startup) to try and identify attribute numbers to test.

So, here we come to my question :). Is there an easier, reliable, multi game friendly way for the interpreter to identify if an object is visible to the player so I can filter it from my list.

Any advice greatly appreciated :slight_smile:

1 Like
2

Sadly, no. Every game really does use its own set of attributes, properties, and variables. Every game customizes them differently, too. (The object tree may not be used the same way in some games.)

1 Like
3

I think you’re talking about scope. There are two aspects to scope:

  • objects that are visible
  • objects that are touchable

If you take a look at some of the scope routines in the standard library, you should be able to work out how the library does it and replicate this yourself by walking the object tree and testing the appropriate properties and attributes. For example, TestScope(obj, actor) tests whether the object ‘obj’ is in scope with respect to the actor ‘actor’.

4

The problem is that property and attribute values differ from game to game. You can’t reliably figure it out unless you’re the game author.

(If you’re the author – using Inform – you can generate a gameinfo.dbg file during compilation. That contains all the necessary info. But the player doesn’t see that file.)

1 Like