Glad you like it! It would be nice if it could do that. But it would require some cooperation from the game.
One of my problems with the inform system is lack of metadata. The game engine appears unable to express to its environment even the most basic information. Such as:
The inventory
The current exits
The map in general
The objects in scope
I’m rather hoping that this sort of data could be made available through the compilation to C route. Eg by “well-known” properties that could be accessed externally. The run-time must know this somewhere. It’s a question of making it available.
I’d be interested if anyone can shed any light on this.
The run-time doesn’t really know any of this information. The library has conventional ways to express it, but the game can customize any of it freely.
You could define standard ways for the game to express this information to the outside world. (This was pretty much the idea behind the TextFyre system.) But then you’re putting extra burden on the author to follow the standards, no matter how they customize the parser or world model. This is a hard thing to ask. Authors do all sorts of wild stuff, and judge the results by whether the game plays right! If you tell them “Oh, you can’t add objects to scope that way, they won’t tab-complete correctly” then 90% of them will just ignore you.
Thanks for the explanation. That’s how i understand it currently.
However, the run-time must be able to make certain well-known assumptions in order to calculate scope. I don’t know how inform does this, but one way, is that the system has to have a well-known notion of “in” between objects. And typically scope is calculated as the recursive set of objects “in” the thing the player is “in” (obviously this doesn’t take into account closed containers, transparent ones etc, but it’s the basic starting point).
As i was saying, Inform might not use “in” at all. But however it does it, it must have some relation or property or set of properties that are “well-known” to the runtime as “roots” of the scope calculation.
I take your point that the game can adjust scope. It seems the game can add or subtract items from scope. But it must be doing that in a way the system can discover, unless the game can redefine the scope calculation altogether. But i can’t see how that would be expressed in I7 (perhaps some i6 extension maybe).
That being said, I’m thinking there are some well known properties that can be hooked, given the game is not redefining huge parts of the runtime itself (which most don’t).
Am i completely wrong here, or might there be a way. Thanks for information.
The point you might not be getting is that the run-time system, if you mean the executable game file, doesn’t know there is such a thing as scope at all. That’s just code. The parser is just code. It’s slightly different code in every game, although most of the differences are due to what version of Inform it was compiled with.
You can’t just look at an object and say “attribute 3 tells you whether it’s a container and attribute 4 tells you whether it’s open”.
I take your point that the game can adjust scope
The game can also adjust exits, and inventory, and everything else you mentioned.
From my limited understanding of them, making in-scope things available to the terp would be plausible with Vorple or FyreVM, which allow backchannel communications. But support for it would have to have been coded into the game’s source in advance.
Famously, the interpreter makes so few assumptions that the game can be… Tetris.
Check out Andrew Plotkin’s “freefall.z5”. I’ve quite enjoyed playing it.
So the interpreter runtime really knows absolutely nothing about commands. Everything which makes the game into Interactive Fiction is implemented in Inform code. It’s possible to have a framework of Inform code which provides hooks to the interpreter (as Zed mentioned), but it would have to be implemented on the game side.
This isn’t relevant to Inform 10, but an interesting historical note is that early versions of the Z-machine did expose more game-specific details to the interpreter. For example, the interpreter was responsible for handling the status line; for this purpose, the first global variable was always expected to hold the object number for the location, and the second and third globals were expected to hold the score and turn count as integers.
Details like these did make it easier to keep the game files small (the Scott Adams data format takes this to extremes) but limited flexibility. Version 3 of the format added options to customize the display slightly (such as displaying the second and third globals as a time instead) and version 4 onward gave up and passed all the responsibility over to the game, allowing for things like Trinity’s “location name only” status bar.
It seems to me that i could just write a bunch of functions in inform7/Internal/Inter/WorldModelKit/Sections/WorldModel.i6t that provide the necessary meta info and/or actually apply operations (or better, put them into a new section file).