Using Quixe without the display layer?

I was wondering if it was possible to use Quixe without Glkote or anything affecting the DOM, so that it can be used in e.g. Node.js.

With a bit of luck, it would work like RemGlk: you give a JSON object to Quixe and get another one in return.

I looked at Quixe’s source to see if it was possible to modify it, but I had a hard time understanding it. Its working seemed convoluted to me, with gi_load.js, gi_dispa.js, glkapi.js…

In fact, what would be really great would be to decouple every component of Quixe and use JS import statements so that it can be used as a part of a larger JS projects. (Say you take only the interpreter part and not the display part).

It’s not urgent, I was just thinking of potential use cases, nothing concrete. One idea would be to use Quixe with NativeScript or React Native to make a mobile app. (I could also compile interpreters with RemGlk for Android and iOS, but I have no idea how to do that.) But again, these are only thoughts, nothing concrete.

Sure you can, though I’m not sure if anyone has it set up like that now. If you want it to work like RemGlk you obviously still need to provide it with a Glk library.

You might be interested in my glkote-term library which I use for testing.

tests/zvm.js shows how to join all the components of a JS Glk-based interpreter together. You should be able to replace new ZVM.ZVM() with Quixe and I think it should Just Work. It wouldn’t be hard to then make a RemGlk mode which takes the output of glkapi.js and writes to stdout and then waits on stdin and returns what it gets to glkapi.js

1 Like

If you remove glkote.js but leave in glkapi.js, you should have a setup that works exactly like RemGlk.

I say “should” because it hasn’t been thoroughly tested in that configuration. But I think I tested it a little, at some point.

Yes, the organization of the code is kind of ugly. The startup sequence starts at load_run() in gi_load.js and zig-zags through the other modules. But they are in fact meant to be modular; they can be used as Node modules in a Node environment. Each one refers to the others through well-defined APIs.

1 Like

Thanks for the answers!

With your help, I found that the function to submit an input is Glk.accept_ui_event (in glkapi.js) and the function that creates the update events is Glk.update (that we should modify to make it return the event in some way instead of passing it to GlkOte). Then it’s a matter of removing all calls to GlkOte.

In any case, I managed to retrieve the events by logging them in the console, so at least it seems to work.

To clarify what I meant by decoupling (which might in fact not be the right term): Having two different repos for Quixe the library and Quixe the playable webpage.

Instead of creating global namespaces, the library would export classes like Quixe, Glkote and so on. To start a story, you would write something like

story = new Quixe(Base64StoryFile, { outputEngine: new Glkote("#gameport") })

Then you could have multiple story each with their own state that you could control programmatically; something like

update = story.send(inputObject)

The Quixe library could even be published on NPM like that.

Then you would have the Quixe webpage, a separate project, which uses gi_load.js and the Quixe library for authors to have a plug-and-play solution to publish their work.

Like that, it would be easier to use Quixe in a larger JavaScript project using webpack and such, for example. But anyway, that’s another topic.

Thanks again, I’ll start tinkering when I’ll have time!

1 Like