I’ve been looking at Gruescript by @robinjohnson and it has seemed like a promising option for making parser-like games more accessible on mobile devices. But it appears to be an independent IF system, which means that glulx/z-machine games still remain inaccessible.
I was wondering if either of these exist or are being developed:
a tool that could convert z-machine games to Gruescript, or
a playing environment that could read z-machine games in a way that shows clickable options like Gruescript (maybe as an extension to parchment)
I understand that the two systems are fundamentally different and that both z-machine and glulx likely have more features than Gruescript which would make conversion a complex process. But is it possible for an environment like Grue’s could exist for z-machine?
If these do not already exist, I was thinking if I could work on them but I don’t have much experience with the internals of z-code and would very much like a hand in finding out if what I’m thinking is actually possible.
That’s a great idea. I’m a big fan of the Gruescript environment. To pick up the thought:
One (absolutely naive) approach would be to write a game for z-code interpreters. I think you need two things:
An extension for Inform with which you can declare verbs for each object (glass of water: take, drink). These verb lists should be dynamically changeable (dependent on (for example) location or progress of the player).
A representation of the game in Gruescript-style (that means you need a new interpreter): Header, text window, objects in the room (including exits), inventory and game options. The classic text input line is suppressed.
For each object the current valid verbs (from the new extension) are displayed as buttons. If you click on the button “Drink” behind the object “Glass of water”, the interpreter executes “drink water” (like a player typing “drink glass of water”).
If this could be done by such an extension (declaration of verbs for each object in the z-code) and a new interpreter (i.e. executable in internet browsers), it should be easy to modify an existing game for this kind of “gruescript”-presentation (in the case there is no special conversation system, etc.). So players could play the game in “gruescript” or “classic” style depending on the interpreter they choose.
(Sorry, this is probably very naive: I have no experience in programming z-code interpreters.)
I’m a big fan of separating the game from the interface, and in my view that’s what Inform needs to do too. The separation also needs to provide “meta data” so the interface can display things like verbs available, objects carried, worn etc. as well as the map, current exits and so forth.
Once that were done, it would then be possible to make a gruescript-like interface. But, of course, the game itself would not be in gruescript, only the front-end.
A while back i looked into how this might be done using the new I7->C translation pathway. Once it’s gone i7->i6->Z, i think this is less possible.
Glulx and Z do both have a standard way of conveying other information to the interpreter, in the form of extra output streams; this is what FyreVM and Vorple use, and I think also the release version of Hadean Lands to make the map work. If you have a front-end ready, it shouldn’t be too hard to make an extension that conveys all this information automatically.
Hm, just a thought: In inform7 you could (miss)use the rule “Every turn, say…” to output everything the interface needs (text, outputs, exits, objects with corresponding verbs, and commands of the buttons, inventory, …). Best in a normalized form (e.g. in XML style).
The interface can use the provided meta-information to build the screen with all elements (header, text, objects with buttons, exits) then.
Of course, that’s an interleaving of code and interface. But the “Every turn, say…” rule, which produces all the needed meta-information, could be switched on and off as an option.
Hm, both seem like great ideas. I’m especially liking how ChannelIO in FyreVM works. This might be helpful in trying to port the older games for which we don’t have source code. But I’m not sure how much extra information glulx actually gives us.
Dumping output in inform seems like a nice hack. If I understand correctly, for pre-existing games, we’ll need to decompile, modify the source code and recompile, right?
Yep. That’s the problem. I just took a look at ztools and the output isn’t encouraging. But maybe we can keep it as fallback, if nothing else will work? It can be useful for new games, in any case.
I wasn’t particularly thinking of decompiling, but adding the per-turn output to the source code and recompiling. This output would be prefixed by a “magic code” to identify it. Same for pictures and sounds. Add “magic” output codes for these embedded in the regular text output.
then;
The hosting environment would filter out information prefixed by “magic” codes. So none of this would appear in the output text window. Information filtered using the magic code system would provide, at least, the following:
names of pictures to display
names of sounds to play
current location
current exits
current inventory
Possibly also a list of verbs to action, but this might be more difficult to generate. It could be done by additional context-sensitive authored markup and, of course, a magic code
That’s basically what a new output stream would accomplish: it’s a separate channel that the game can use to send information to the interpreter, distinct from the text to be drawn to the screen. The danger of magic codes is that they could show up in actual game text (no matter how unlikely a sequence you choose, someone could end up using it in an ASCII-art map!), while the separate output stream will never be used by accident.
From a coding perspective, you would just switch output to this other stream (takes one or two opcodes), print whatever information you want the interpreter to receive, and switch back.
@plytonrexus I would be interested in contributing to something like this.
For modifications to the user interface I have had some small success with Jon Ingold’s Flexible Windows, which allows you to divide the single main window into various Glulx sub-windows.
Here is a screenshot from The Time Machine v1.8, an update to an existing game of mine, where the left side is used for descriptive text and parser commands and the right side is used for inventory, people you can talk to, and conversation Ask/Tell topics (this is running in Parchment).
For clickable links, Andrew Plotkin’s suggested I look at his Bigger Than You Think source code for an example of clickable links in I7. I fooled around with the source code a bit but still haven’t been able to get it to compile under the current version of Inform (I admit that I haven’t been able to devote as much time as I would like to on this because of other priorities).
I have also read about other extensions out there for creating and handling clickable hyperlinks within an I7 game but have not been able to do anything more than a cursory search.
Here’s how i would do clickable links. Firstly, not change anything with i7 at all. I would just add markup to my text.
To take examples from your images;
Will you climb [upwards](go up) or [downwards](go down)?
and
Will you explore the [canyon](x canyon), take the [crowbar](get crowbar) or continue [climbing](d) down?
What we do is have a hosting system for i7 games that filters the text before display. We add markdown style syntax to the text. Also support italic, bold etc using markdown, because why not.
So also we support things like, see my [website](https://spam.com) and use the same syntax for text which is fed directly back to the game when it’s not a URL, as in the above examples.
So you’re proposing a replacement for the whole Glk formatting system? It’s doable, but note that you will need to change the Inform side of things to sanitize everything that’s printed. For example, authors will now need to be careful with how they use asterisks to make sure it’s not accidentally read as italic.
The other issue is that this makes the game file incompatible with all other interpreters, since the text is full of markup. The benefit of working with the Glk formatting system is that most existing interpreters already support it.
Glulx games can have hypertext interfaces (Jon Ingold’s A Colder Light) with plain Glk. And Vorple can do the UI elements described; while the latest version is glulx-only you could use an older version with Z-code.
But to end up with a contextually sensible list of nouns and verbs per turn, the game would have to have been written from scratch with support for it. Offering everything in scope each turn in combination with every verb that acts on a thing would be unwieldy to say the least, and there’s no built-in means to let you whittle that down to reasonable combinations: that would have to be added.
@Draconis When you talk about “output streams” are you talking about this (for Z-Machine) and this (for Glulx/Glk)? I would like to learn more about them.
Yep, exactly that. Whenever the Z-machine prints something, it sends that data to some combination of the “output streams” it supports. Making a transcript, for example, involves turning on an output stream that goes to a file. Or you can print to a buffer in memory to mimic sprintf.
If you want a new way for the game to send data to the interpreter, you can just define a new output stream. Every turn, the game will turn off the “screen” and “transcript” streams, turn on the “new interpreter communication” stream, and print whatever data it wants. Then switch back afterward.
Glulx (or rather Glk in this case) inherited the concept from the Z-machine, so it can do the same thing, just in a slightly different way.
Vorple uses this for all the JavaScript interfacing. It defines a “JavaScript output stream” where the game can print things it wants executed in the browser (along with a way for the results to come back).
