This post is now out of date - for my current thinking about the future of Quest, see viewtopic.php?f=15&t=4826
I've got my crystal ball out and have been looking to the future. How does Quest need to change and evolve to become the kind of text adventure platform we'll need for the future?
So I've been having some thoughts about what Quest 6 will look like. These are all at a fairly early stage, and it will be at least a year or two before this is finished. Please let me know what you think - and I hope that if you think it sounds good, you'll consider joining in with the project(s) to help it come to fruition!
The first major change I'm considering is going to be controversial - no desktop version. Quest 6 will be entirely web-only. It simply makes no sense to work on Windows desktop software in this day and age - and since I don't have time, and nobody else has yet volunteered, to work on a Mac or Linux version of Quest 5, it seems to be a lot more logical to simply have one web front-end for everything.
It will save time because any changes will only need to be implemented for one platform, and everybody will benefit from the same features everywhere.
This also makes handling "legacy" games much easier - the existing Quest 5 WebPlayer will continue to be used to handle games for Quest 1 to 5.
Now, I understand that the desktop version is still very useful and important for some people. Particularly people who have poor network connections, which includes a large number of schools. But internet connections everywhere will improve over time - so by the time Quest 6 is released, this will be less of an issue for many. Also, Quest 5 isn't going anywhere, and will continue to be supported - and I think it's a pretty good text adventure platform already, even if I do say so myself!
On to the changes themselves. With the desktop version gone, the editor will be based on the Quest 5 WebEditor. This means that all the currently "missing" features from the desktop version will need to be implemented.
The performance of the editor will need to be improved. This can be done by changing how the front-end communicates with the server, and by changing how the server stores data. In the Quest 5 WebEditor, the server generates the HTML for all element editor tabs for an object, and sends it to the client. When you click between objects in the tree, or tick a checkbox, that triggers a save of the current element (all form fields across all tabs) and a load of the new element (all HTML for all tabs). These can be quite big chunks of data to be working with. In Quest 6, the client will do more of the work, storing data locally and only sending changes to the editor via an API. The server will then save data to table storage instead of writing to a single .aslx file. This means it will be able to save and load an element's data very quickly, as it won't have to parse an entire game's XML file.
Import and export of an .aslx file is still desirable though, as I don't want to hold people's games hostage - transferability of your data is very important to me. Being able to edit an XML file of game data will also be required for the editor to give a "code view" of the entire game.
Saving and loading from table storage opens up the possibility of collaborative editing, or even simply editing the same game in multiple browser tabs.
The core library will be based on the Quest 5 core library, and most of the same functions will be available, although some changes may be desirable or necessary. It should therefore be relatively easy to migrate a game from Quest 5 to Quest 6.
Benefits of this:
[*]no separata conversion necessary for turning a game into an app, as the game already runs natively in JS. If we create a responsive HTML UI, the game can be wrapped trivially in Phonegap or any other wrapper.[/*:m]
[*]host a game easily on your own website[/*:m]
[*]easier control over HTML, CSS etc for the finished game[/*:m]
[*]possibility of having two script types in Quest - code scripts using Quest scripting, or write pure JS functions which can access game attributes. The former will be turned into the latter via the converter. This means no more FLEE weirdness, and you can write more advanced scripts.[/*:m][/list:u]
One challenge will be saving the game state. Currently QuestJS saves the game state to the browser's local storage, but I think it's important that your game progress is accessible when you move to another device. The solution for this will be to create some kind of sync API, to save the contents of local storage to the cloud, and re-load it when you play from somewhere else. This sync API will of course have to work entirely from JS code on the client. Game saves will be a delta from the original game state, which will make it possible to saved games to be loaded by newer versions of the game if the author updates it (and allows old saves to be loaded).
So, that's the vision. A lot of the groundwork for this is already in place, so unlike the big rewrite of Quest 4 into Quest 5, this should actually be a simpler set of projects, which should put Quest on the best technological footing for the next few years.
There are four main strands of work, then:
1: WebEditor performance - refactoring how the client communicates with the server, and how the server stores data
2: Missing WebEditor features. It would make sense to only implement these after the refactoring.
3: QuestJS. I will be opening up the source for this soon. It currently works as a Windows desktop app, and the code is pretty nasty - both the QuestJS code itself and the code it generates. It's going to need quite a lot of cleaning up.
4: Game state sync API
Let me know your thoughts...