I find this a bit hard to articulate in a way that gives it the attention I think it needs; I’m sure the idea isn’t original, it just strikes me as one that needs more attention. Not sure where to begin and end, but here goes…
Working with multiple IF backends, interpreters, I find myself again and again wishing there was some Glk-like common ground on object-oriented aspects of IF. The wish list could grow long, and I don’t want that temptation to keep it from happening. Something progressive that deals with only a couple needs is fine and enactments to it in the future.
Within a story, a room
This is by far the most important advance I see. I think each room in a story should be assigned a 32 bit integer identification number by the compiler (Inform 6, Inform 7, Hugo, etc). And a standard set of Glk-like API calls defined upon entry to a room or exit from a room.
Everything from invoking CSS and image changes (Vorple comes to mind) and even maps and navigation can be built upon some basics like this. It really is a powerful tool to know for certain that a room has been entered and that it isn’t just matched based on string of the room name. This could even be the basis of a save/restore descriptions, hyperlinks you send to people as hints, and automated testing system for IF stories. I know not all stories allow teleportation between rooms, I’m not saying they should, but from a presentation of IF to a user - I think the room is such an essential concept (the name of it, have you visited it before - like a hyperlink color in HTML) - that it is beneficial to all to make the rooms and their entry/exit identifiable ‘events’ all the way to the presentation layer.
I know mapping systems exist and such, but really I find I see at the Inform 7 level a “room” is a clear defined concept, but at run-time presentation it’s lost by the time it goes from Glulx–>Glk to the user interface. And the problem seems to hold for other interpreters as well, not just the Z-inspired ones. Thank you.
A TAVERN extension could be proposed to implement such thing like this perhaps. (TAVERN uses 16-bit numbers, but what you mention could be worked with 16-bit numbers too, anyways.) I don’t know what kind of presentations and so on, although some general kind of object oriented presentation commands could be provided as an extension to TAVERN, and then perhaps also to make up a Glk extension for this too, by reserving a range of numbers. I don’t know how to reserve ranges for Glk or for Glulx (which are separate, although perhaps Glulx need not know about it if the Glk layer does instead), but for TAVERN you can easily to add a ticket and/or to add such proposals to wiki too. It is one of the thing I am hope to make TAVERN to do, to support such futuristic extensions too.
I don’t have a direct solution, but I’ve considered this sort of thing. It came up when building UI features for the app versions of Dreamhold, Hadean Lands, and so on.
First, “object oriented” is a misleading label. That has programming-language connotations which aren’t really what you’re talking about. The question is about extracting high-level (I7) data from the game for UI purposes. I’d say this is “game state inspection”.
You are thinking about rooms, but the feature should not be room-specific. I built a map UI feature for Dreamhold, but a to-do list for Shade and a starship-display for Heliopause. The latter two had nothing to do with game location. The Hadean Lands app used the location and the set of known formulas/recipes/etc. So we need to talk about the game providing arbitrary data for inspection – whatever is appropriate to the game.
I found it best to perform the inspection once per game input, not every time the player enters or leaves a room. In theory a player might go through several rooms in a turn. (Particularly in HL!) You don’t want the map to flicker through a bunch of states, you just want to display where the player ends up.
So the most useful solution would be an game-specified output routine which is invoked just before input time. (In the I6 PrintPrompt routine, although really you need another couple of places for keystroke input etc.) This output routine would collect the appropriate information and shove it out some output channel. This could be via Vorple, via FyreVM’s channel system, or through a Glk extension call.
Now for my apps, I actually did something slightly different. I extended the VM interpreter to inspect the raw VM memory to extract the information I needed. This isn’t any better – in fact, it’s more of a pain in the ass than authors should really have to deal with. But I was able to set it up fairly quickly and without recompiling the game code. (Important for Dreamhold and Shade.)
Ditto on Zarf’s comment about this being turn-based and whatever arbitrary state inspections the UI might need. That is exactly how fyrevm-web works and from my own experience in my limited use of my platform, the right cadence for information updates. And then if you start storing this inspection data for every turn, you can do some data mining for even more detailed information (someone want to graph progress in some picturesque way, display a map with altered states, alter the entire UI based on state (Photopia coloring)).
It might be want to be used though even if the game isn’t written in Inform7. But you are right it may not be “object oriented” in terms of the programming languages.
The stuff mentioned by zarf and DavidC can be ideas to know what kind of information it might be used, and so the design can be written by such way.
Just making the interpreter hard-coded to inspect raw VM memory in specific way seems no good, although it may have work in that way in your case of those specific game. Better is to do different ways if possible! A general kind of way to do it seem best though, but I don’t know what way exactly.
They can be figured out and made as extensions for Glk, FyreVM, Vorple, TAVERN, etc. (And then in the case of Glk, a Inform7 extension to support it can be made too. Extensions for other compilers for other systems can then also be made up.)
I agree with zarf to not be room specific, although zarf also says “best to perform the inspection once per game input, not every time the player enters or leaves a room”; however, this would be an interpreter feature rather than a feature of the VM specification. The game needs not to know when the interpreter updates the display; it can emit the command every time the player enters/leaves the room and the interpreter does not have to update the display every time.
But the opposite is also true… if a room is quickly passed through in a turn, you could very well want events to trigger. My concern is a indexed (integer) based data flow that’s multiple-interpreter to a higher level. It would be up to the higher level (presentation, ISO Layer 7). Buffering and logic at the ISO 7 layer could account for not flickering, etc.
I agree that it’s more than just room entry/room exit, obvious things include inventory changes (add/remove/change to an inventory item). But I felt room is a solid enough cross-interpreter concept that I saw it as a useful situational awareness all the way to ISO Layer 7.