The Future of Quest?

I have been having a play around with JavaScript, building a new version of Quest. Note that this will not work with existing games, and as yet there is no editor. There definitely will be an editor eventually. There may be a way to convert files from Quest 5, at least to some degree, one day.

What there is at the minute is a framework to create games in JavaScript.

You can see an example game here. There is not much in the way of plot, but stuff to interact with to see how the world model feels. Let me know if there is anything important I see to have missed out.

Why JavaScript?

Better for players

  • No lag between turns
  • Game does not time-out

Better for authors

  • Authors can upload games to their own web site
  • Authors are learning/using JavaScript, the computer language of the internet, rather than ASL, which is exclusive to Quest 5.
  • Authors can change absolutely anything in the game system; everything is accessible

Better for me

  • No need to support legacy games in the app (Quest 5 and the web player both have to support every version of Quest 5, and Quest 4 (and I think all the way back to Quest 1).
  • Updates are far easier to publish without legacy support

What else?

As I was building this from scratch, I could build in some features from seem lacking or are tricky to implement in Quest 5. The parser has a better idea of context, looking at what objects are where when matching commands, so should be better able to guess what the player means when it is ambiguous.

As much as possible is neutral with regards to the character (i.e., works for both the player character and NPCs), making it easy to add commands allowing the player to command an NPC.

Objects can be in several rooms at once. Countable objects that have specific numbers at different locations are built-in.

See more...

More details here, including a tutorial on how to create a game in this framework.

I this is new, from the ground up, can I add an idea...
When the script has a get input command, the script stops and waits for the player to answer it?
This way, there is no need to nest get inputs inside of get input...
msg("Hello player, what is your name?")
get input
// script stops waiting for the answer...

or even:
get input player.alias

Then you could do this:
// player set-up
msg ("Name?")
get input player.alias
msg("sex: (M/F)")
get input player.gender
msg ("{player.alias}, what is your class? (Fighter, Thief, Cleric, Magic User)")
get input player.class

direct, no nesting, and no need to keep track of how many nests you did...

That is built-in to JavaScript already, with the prompt function.

      msg("'What's you name?' she asks.");
      var name = prompt("Your name?");
      msg("'Hi " + name + ",' she says. 'You're very sweet.'");

That is what I was suggesting...
And not that far from Basic's input command...

Couple of thoughts on possible next steps with Quest

  • I've been playing with the code base, writing and testing stuff for the last couple of months.
    I thought of perhaps implemeting some improvements into how the script language works, but have reached the conclusion that 5.8.0 code base is too interconnected and too complex to refactor and improve - making it much more efficient to do a rewrite from scratch.
  • I've been thinking about a good way how something like Quest can be implemented from scratch. I am wondering - have you looked at the possibility of using the Electron project as UI and self-hosted ASP.Net Core endpoints as actual functionality? (they can be self-hosted using in-process Kestrel server)
    Another potential bonus in such approach - since Electron based apps are essentially websites, it should be relatively easy to implement a web-based player.

The Electron project is essentially a Node.js application that hosts border-less browser window with Chromuim as UI engine - it is essentially similar to what Quest 5.8 uses currently so existing UI code can potentially be re-used, and "backend" using .Net Core could be leveraged to re-use some parts of existing code.

I don't have too much free time, so my progress in this is very slow, but I did some testing - it is certainly possible. (Node.js interop with .Net to start the self-hosted ASP.Net Core server can be made possible by the Edge library)

You built all this from scratch in a month and a half? Respect! I am curious how it will develop.


I was looking around for a good framework for the editor, and came across Electron. KV recommended it too. It does look to be the best solution. At the moment I am looking at a desktop system, but that should be cross-platform, if built on Electron. I have very little experience do this sort of stuff on a server, so that will take rather longer...

hi so I’m not sure if my reply to this is posted or not so I’m trying again I am totally blind and play these games I have tried to use the web player but I have found that it is very clunky because when you type in commands the screen reader does not read back what the command is so you have to swipe around on an iPhone to see what the command was which is what I would like to use to play these games now using quest on the computer works fine but that’s only with the application itself so what would be nice is to see away in the web player where you could type in a command and then have the screen reader automatically read back the response instead of making you go find it in the history of responses for example when you type examine cat the player should automatically re-ply The cat is round and fluffy instead of making you having to swipe left to see the response of the cat is round and fluffy I hope I explain this well enough but if not let me know and I can try to explain it better

So... maybe a text-to-speech option???


I have added a SPOKEN command to the test game, which may help (only tested on Chrome). That said, if you are using a screen reader anyway, it may make it worse, as you may get everything twice.


There is a text-to-speech option in desktop Quest 5 (or at least there is if you have some extra software). H2359 is wanting to use it on the web player, which then has the browser sat in the middle, so it is the text-to-speech in the browser. The problem with the web player I guess is that Quest inserts the response into page, rather than appending it to the end, as it needs to go in before the command bar.

Log in to post a reply.