QuestKit

Alex
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.

Pertex
YES! It would be great to get rid of all the problems you describe. I hope it will also be possible for the game creator to change the complete player interface like adding new panes or rearranging the existing areas?

"no more ASL" means scripting? Will there still be the known aslx files with all the objects which will be translated to JS?

Alex
Yes, the game creator will have complete flexibility to tweak the player interface. In fact it will be much easier than it is now, as the interface will just be a template you can easily edit.

The current Core.aslx files will be converted into a set of Core JavaScript files.

jaynabonne
Woo hoo! Quest is alive again. What you say sounds great to me. It incorporates things I've wanted (like JS scripting able to affect the object model, etc).

I'd also be more than willing to help out, in a more active and effective way than I have been with the current open source code.

jaynabonne
This could also imply custom editors as well, which I'd love... :)

Pertex
Alex wrote:The current Core.aslx files will be converted into a set of Core JavaScript files.


OK, but I mean the file the user creates. The user will still add rooms and objects to his text file and this file will be converted into JS then. So it will be possible to convert classic Quest files into QuestKit files (except the tags which are not supported by QuestKit, of course)

jaynabonne
It sounds to me like there will no longer be aslx files. I'm sure there will be a converter for old games, but I think internally, it's meant to all be JS. (I could be wrong.)

Alex
The input file is a text file containing the rooms and objects - the user creates this by hand or using the QuestKit editor.

These won't be ASLX files, but it's a similar concept. Rooms and objects will have attributes, and they'll also be able to have JavaScript functions (so an object might have an "eat" JavaScript function, just as today an object in a Quest game might have an "eat" script).

The QuestKit compiler takes this input text file and outputs the HTML/JS for running the game.

I'll post a sample of what an input text file might look like soon, as well as some thoughts for how the world model will work.

george
This is awesome. I've been having the exact same thoughts (that Quest should be converted to JS-based software) but wasn't comfortable proposing that in the face of Quest as is -- it's often tempting to burn the barn down and rebuild it but that's often a lot more work than it seems at first. However it's great to see this proposal coming from you Alex. I'm ready to contribute in any way I can!

The Pixie
Sounds good to me too. At last we can use == and +=.

jaynabonne
One thing I would love to see in a new version of Quest is a real WYSIWYG editor (at least for common things like font, size, color, bold, italic, etc) so people don't have to manage HTML tags and all that. And an easy way to manage CSS and CSS classes. (I imagine it could look like how named styles work in programs like Word, except the named style would turn into a CSS class. And there could be built in styles for all the default UI components so people could change the game UI with some easy GUI controls.)

That might seem a bit daunting, but I did some desktop publishing programming in a previous life, and I think it's doable, assuming a reasonable editor UI could be devised.

Alex
I think I'd prefer using Markdown than having a WYSIWYG editor.

I have no evidence for this, but I'm going to make a claim: A good game probably uses a fair amount of conditional text. So you can't really do WYSIWYG in a text adventure editor.

Still, we could include a word processor-style editor anyway I suppose. Quest's WebEditor used TinyMCE for a short while, although it clashed a bit weirdly with some of the ASP.NET MVC bindings as I recall - but that wouldn't be an issue for the new QuestKit editor.

george
One experiment with WYSIWYG might be to style the conditional text token. It might get confusing, but it could work too.

jaynabonne
For those who are following this thread, there is a new related thread as well:

viewtopic.php?f=15&t=4835

(in case you don't get around, like me :) ).

PaladinRevenant
Well, huh. I was just thinking the other day about what a shame it is that I can't create Quest games on my tablet offline. I was even thinking about proposing a project to convert the Quest editor to Java (Which in my head I was calling QuestJ) so that I could create an Android application with the functionality of the desktop editor. Then I came across this thread. Seems kind of silly to continue to move in that direction if Alex is moving in another.
So, how can I help? Do I understand correctly that the editor will wun completely in the browser? I don't have a lot of experience doing impressive things purely with JavaScript, but I am a developer by trade and I always like a challenge.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums