I've been re-thinking my thoughts about the future of Quest. I've grown rather tired of working on Quest in its current form, and there are various problems with it which are holding it back.
One major problem is speed. The web-based player is slow, because all of the game logic happens on the server (and getting a bigger, faster server is expensive). The web-based editor is slow for the same reason. Despite this, Quest is getting more and more popular - traffic to the website has almost tripled in 2014. This is going to cause problems - things will only get slower as more people use Quest, and I don't really want to be spending more and more money every month to keep things going.
Another major problem is consistency of experience. Despite the desktop Quest player using an embedded web browser for its UI, there are still differences between playing games online vs offline. There are still major missing features from the web editor. If you want to turn a game into an app, you can use the QuestJS converter, but that is incredibly error-prone.
Introducing big changes is also difficult. With Quest's player UI being HTML-based, it's nicely hackable, but the same base HTML has to work with every Quest game, which makes it difficult to modify without the risk of breaking some existing games. And it really needs modifying - the mobile web player UI is poor, as Quest doesn't use a responsive layout, but it will be hard to change the desktop player UI to be responsive without creating a big mess.
If you want to run Quest offline, your options are limited, as Quest only runs on Windows. While the converter works sometimes, if it doesn't then the only way to distribute your game so that non-Windows users can play it is via this website.
Rewrite time!
Quest 4 suffered from some major issues, which I solved by starting a project to rewrite it in 2009. This turned into Quest 5.
Now, almost six years later, I think it's time to kick off another rewrite project. This time, I want to keep things much simpler and lighter. I propose:
- no more ASL. Just use JavaScript as the primary scripting language in games.
- games run entirely in client-side JavaScript. The server is only there to serve the files, and send/receive JSON for loading/saving game state.
- the editor is also built to use client-side JavaScript, instead of the server render anything.
- games and the editor both use local storage to store state, so it persists between browser refreshes. Use an API to sync this state with the server.
- just one responsive HTML UI for playing games, and just one responsive HTML UI for editing them.
- a packaged game is simply HTML and JavaScript - it can be uploaded and run anywhere. Future versions don't need to worry about backwards-compatibility, because once a game is compiled it contains everything it needs to run.
- for the offline experience, wrap using node-webkit or similar.
- game functionality itself will be very similar to Quest 5, as we'll convert its Core libraries to JavaScript
This simplifies things a lot, as it removes a lot of stuff - no more ASL, no runner or interpreter, just one player interface (down from 3 - desktop, web, mobile), just one editor interface (down from 2 - desktop, web).
It will run online, much faster than now. And it will run offline, on Windows, Mac and Linux.
There will be no gamebook mode - use Squiffy for that. (But I like the idea of being able to add Squiffy-style pages/passages which the player can be moved to. This will be useful for dialog trees etc.)
What about editing scripts? We'll use Blockly, so there will still be a visual script editor. Underneath it will just be JavaScript.
We'll keep Quest 5 around for editing games made with it, as there will be no automatic upgrade path. Perhaps it will be renamed "Quest Classic", as what I'm describing here is a new system, written from the ground up.
I'm provisionally calling this new system "QuestKit". A large amount of its functionality will be based on Quest (well, the Core libraries anyway), but it's a new thing. The new name will make it much easier to search ("Quest" is way too generic).
We'll start the version numbering at 6, but the initial version will probably be just be a simple command-line tool, very similar to how Squiffy currently is. There will be no editor initially, and the tool will simply take a text-based script file and output HTML and JavaScript.
In fact the whole approach to QuestKit will be very similar to the one taken with Squiffy - I'll write up a roadmap similar to
http://docs.textadventures.co.uk/squiffy/roadmap.html, and the system will work in much the same way.
Anyway, this will all take a LOT of time - this is just the vision for the next few years really. I'll post more thoughts here as I have them.