Currently I'm messing with Quest 5 stuff, and I'm messing with Quest 6 stuff...
Some things are different, but very similar. This makes my mental database a little muddled. So, correct me if I post any misinformation.
Now, let's talk about the Quest 5 Player.
On the desktop player, the game runs on the embedded Chromium browser using the PlayerController. Said embedded Chromium browser communicates with Windows via ASLEvents. And . . .
Sigh. I don't even know where to start . . .
There should be a way to make Quest 5 games run in an Electron app without having to convert the games first.
It looks like IASL, IScript, and IFunction may be the keys. Maybe we could . . . Who am I kidding? That stuff is Greek to me!
How about an Electron app that works like the Quest web player. I mean, an Electron app is basically running a web page on a local server anyway; so, can Electron handle ASP.NET stuff?
I found this, but I don't know if it's a dead-end: https://github.com/ElectronNET/Electron.NET
I'm pretty sure Quest 5 is using ASP.NET 4.5, but that's just a guess based upon a few lines I've noticed in the source code.
That Electron.NET thing I linked to says .NET Core and it mentions .NET 5. Well, Mono mentions those as well, and I couldn't get the Quest webplayer to run under Mono on Linux. Someone else said they did, though.
I don't know. I just wish we could make a Quest 5 game run in an Electron app. That would be cool.
If it's a way of making my major project exportable in a more easily-played format that might save me from a big rewrite come release of 6, you have my full (and useless) cheerleading support! ♥
you have my full (and useless) cheerleading support!
Now figure out a way to upload the required data to my brain. Everyone, send me your energy! No, wait! Never mind. I'm not trying to make Spirit Bombs. (Or am I? Hehehe.)
Seriously though, what all sort of scripts do you add to your game? I mean, how complex is your code?
Never mind. Scratch that question for now. I don't know specifics concerning which functions and scripts will carry over and which ones will not. That is mainly because the Quest 6 editor is far from finished right now. Depending on what all you've got in your code, Quest 6 might just open it right up, with few to no things to fix manually afterwards. (No promises, though.)
Digressions aside, we still need some sort of Electron app to run all the existing, published Quest 5 games.
I wonder how Lectrote works? Like, what data needs to be transmitted back and forth (from game to interpreter) and in what format?
Lectrote will play Glulxe, Z-Code, HUGO, TADS2 and TADS3, and Ink games.
It uses the Quixe interpreter to handle Glulxe, and it uses Parchment to run Z-Code. This is what is packaged with Inform 7 for when an author wants to "Release along with a website and interpreter."
Lectrote is using NodeJS to interact with Quixe and Parchment, which are both JS interpreters designed to make games created using Inform playable as websites.
I don't know anything about HUGO.
The Lectrote page says Ink games are already written in JSON, so there's no mystery as to how that works with the browser.
I'm not sure about TADS either. Isn't TADS similar to Quest, as far as the back-end is concerned? (It seems like I read that somewhere once. I might be making that up.) Does anyone know how similar TADS is to Quest?
I have quite a few large scripts, but I'm also an inexperienced coding gremlin so a lot of them amount to inefficient nested If statements. Funnily, this might actually save me down the line with Q6. Though, I worry that things like the Map and Grid Inventory codes Angel sorted me out with will probably break in 6 due to being mangled into working in 5, ahah.
Though, I worry that things like the Map and Grid Inventory codes Angel sorted me out with will probably break in 6 due to being mangled into working in 5, ahah.
Yeah; I suspect that most of that stuff will not be able to be converted.