Ok, so here’s a hot take on choice vs. parser: I think I’ve been sticking with writing choice-based games primarily because I like Ink and its designed-as-middleware approach. And you’d think that the VM-based approach to parser games would actually be a good fit for an Ink-like integration into other languages/game engines - it seems conceptually quite similar to how Ink stories compile into bytecode compatible with Ink runtime implementations for a wide variety of languages and engines. But for some reason, all of the popular authoring tools for parser IF are still chained to a conception of what an IF VM should look like from 40 years ago.
You can write a minimal CLI wrapper around an Ink game in less than 30 lines of JS. It’s extremely trivial to integrate Ink into basically anything, and build whatever additional features you want on top of it. But despite Z-machine allegedly being “possibly the most portable virtual machine ever created,” I haven’t found an easy way to do the same thing with parser games in any of the engines or languages that I usually work with. And Glk doesn’t help, because whatever problems it’s solving are completely orthogonal to what I personally want out of an IF VM.
I’m considering just writing my own Z-machine interpreter in GDScript or something, with my own highly-opinionated modifications, but that seems like a lot of work to commit to when I’m still not sure if I enjoy writing parser IF - but on the other hand, I don’t want to commit to learning to write parser IF when it feels like I won’t actually be able to do the things I want to do with it without also implementing my own Z-machine! Terrible chicken and egg problem.
Glk is capable of a lot more than what most games actually do with it, and if you want fancier visual effects you can probably get them by bundling your game together with a hacked-up fork of quixe. And while the Z-machine can be pretty constraining, Glulx is not. Asking as the developer of Bedquilt, do you have any particulars in mind for the kind of thing you wish you could do with parser games but don’t think any of today’s engines can handle?
It may be trivial for people who know what these things are. I think JS is Javascript and I know that’s a coding language but that’s it. No idea what a CLI is. Or VM. I’d love to be able to spice up the parser game interface but I don’t have the coding chops to do these things and I’m probably not ever going to learn all that stuff. I use Inform because it was made for people like me, and learning it has been enough of a serious challenge.
I’m talking about things ranging from including parser-based mini-stories inside a “wrapper” game (think 80 Days but parser), or graphical minigames in a primarily-parser game, all the way up to a more hybrid “graphical adventure with parser input,” with a mix of free-roaming 2D or 3D navigation, parser input, textual output, and graphical output (the latter being limited/stylized enough to not conflict with the text output).
EDIT: Or in other words, basically the same range of stuff you can do with Ink.
The capacity to link JS, at least, with parser games is technically there, but more oriented to doing “more of the same with some JS tweaks” than anything discussed above.
To clarify, what I’m talking about would not need to involve changing how Inform works at all. It would just be an alternate way of using the output, for those who are so inclined. Similar to how you can write a story in pure Ink and export it to web without any other programming experience, but it’s also designed to be usable as a component of full-on 3D games like Heaven’s Vault.
This kind of thing should be achievable someday with Bedquilt because I’m keeping the parser and world model as separate as possible from anything to do with IO. Basically, it should allow you to call process_turn("GET LAMP") and get back a document tree that you could then pass to another function that will render it using Glk, but process_turn will not itself pull in a dependency on Glk or any other system interface, nor on Glulx or any other VM platform. I think @DavidC has similar plans for Sharpee.
It sounds like you’re planning to carry things even a step further than I am, then. I intend to separate the code that 1. mutates the world model and 2. produces a batch of output to be rendered from the code that 3. actually does the rendering, but I wasn’t planning to separate (1) from (2). That is, the same routine that mutates the world model to add the brass lantern to the player’s inventory will also be responsible for mutating the document tree to add a “You pick up the brass lantern” paragraph node. Having the model mutation automatically emit an event that’s processed by output-generating code that lives somewhere entirely different is not something I’ve considered.
It took me a while to find the spots in Quixe where you can ‘link in’ stuff, but once you find them it’s not too hard to integrate javascript and graphic games into the parser:
I haven’t done anything more with this concept because I can’t think of fun games that would involve both moving a character around screen and parser input. I have adapted this to make it easy to do CSS transitions and music in games (resulting in an interpreter called Bisquixe).
I’m aware that “modify an existing Glk implementation” (glkote in this case) is the painful, hacky solution to integrating an Inform game with something else. I’d just really rather that there were a non-painful, non-hacky solution like there is with Ink.
I can see what you’re saying, but Ink doesn’t process text input and Inform/ TADS/Dialog do. I can’t really think of any scenarios where you’d have to debate between which one to use. Unless you want to use Inform only for its text variation properties and then disguise it as a choice-based game (which I and a group of others did with Untitled Relationship Project).
Do any of your game concepts involve parsed text input?
(I am moving the goalposts a bit here, as I think your original point, that Inform is much harder to integrate with other systems, is completely correct, so if you don’t want to engage in this tangent I understand!)
To clarify, I do want to make games with parsed text input. Like the “80 Days but parser” concept mentioned earlier (i.e. a game that has parser IF segments interspersed between other styles of gameplay), or “graphical adventure driven by parser input” (that used to be a thing), or using Inform to implement an ask/tell dialogue system inside an RPG, or something like that. I just want to be able to do it using a friendly API like Ink has.
To be clear, I want an API that works something like:
story = new ZMachineStory("some_file.z5")
while True:
print(story.get_current_text()) # or do whatever I want with the text output
user_input = input("What now? >")
story.parse_input(user_input) # or get input in whatever way I choose
In other words, I just need a black box that I can send text input to, and get text output back from, and then be able to do whatever I want with it. Features for getting/setting Inform variables/world state from within the outer program would be a nice bonus, but not strictly required. I want to be able to write & test “just the parser part” of a game in a nice DSL like Inform7 (or Dialog or w/e) with a powerful world model, and then import it into a fully-featured game engine like Godot where I have more exotic options for input, output, and overall game-y-ness.
Yeah, that really would be nice. You’re right that Inform is pretty rough now. I wanted to do something similar and asked about it six years ago. People told me what it would take but I just didn’t understand. It was many years later before I learned how to do what you describe. And even that is really shaky (the text input isn’t released in nice, discrete chunks you can easily manipulate or throw tags around, it’s assembled via a very complex process and then pushed out all at once each turn). So I do wonder if it would be better like you’ve thought of before to use something else. Dialog is in the process of being forked into open source, and it’s code is a bit ‘cleaner’ and easier to mess with. I wonder if that would be a better avenue for the ‘inkification’ of the z-file format
I realize it’s rather more complicated than integrating Ink, but RemGlk is getting pretty close to this, at least. It uses stdin and stdout instead of the function calls Ink does, but any decent programming language should have a standard library for hooking up to those nowadays (like Python’s subprocess module).