So do we just ... wait?

Despite all the work I've built into my world template that I've been working on as a platform for my Quest games, which includes physics for fire among other things, I'm not really feeling like investing more time into it if a completely incompatible system is coming along. Working on it would feel like a waste of time, and I'm not going to hold off on a vague promise that, some day, somehow, maybe, the new iteration of Quest might be compatible with what I'm doing, so... I'm not doing anything.

I feel like all this work to build this thing and work out the bugs is for naught, so it makes me sick to think it's going to go waste.
How soon will it be before this new and improved Javascript-only maybe-someday-compatible-with-old stuff version comes out?

Correct me if I'm wrong, but...
When you publish your game, Quest loads it up with your current Quest support functions.
That would make it compatible across versions...
But... while typing that, you may have a point...
If Quest 6.0 is completely new, would older versions even run?


I would advise completing your game in the current version of Quest. The alternative would be completely rewriting/porting your current work-in-progress in Javascript.

Pixie said we might (one day in the future) be able to convert Quest 5 games to the future format:

"There may be a way to convert files from Quest 5, at least to some degree, one day."

Even if this comes true, you'd still need a finished Quest game to convert.

So, you either finish the game in the current version of Quest (which, again, is what I advise), or you can manually translate everything you've already coded with Quest into Javascript (which sounds unpleasant).

A few posts (months) later, Pixie said:

"It will not be possible to play current games on it, it will not be backwards compatible."

This seems to be the case because there will be no new Quest Player. The future version of Quest will output a stand-alone website, which means the games can be ran in any standard browser.

Games run in the browser. Everyone has a web browser, which means everyone already has all the software they need to run your game. You can just upload the files to your web site, or zip them and upload them to, and it will just work. Also, because the game runs in the browser, not on a server, there is no lag and no timeout, and players can save their game progress on their own PCs to "localStorage".

Here's where I got that info:

Also see the thread on this forum:

As long as this site exists, a Quest player will always be available to allow us to play every game ever created with the software -- from the beginning of Quest all the way up to the current version of Quest. (Pixie is big on this. Trust me.)

Hi Xordevoreaux, I am try to build a system for handle fire. I am not finished it, it's a work in progress. For now I wrote something that handles heat, dryness, humidity, type of wood (different burning time), and finally carbonize to other matter (coal or ash, dipends on volume of the burned object). Every matter has a "critic heat" level that if overpassed can start a combustion process. The dryness percentage determines how much time we need to make the object start the combustion (when HEAT reaches the "critic" level).
Fire is an object that "incorporates" other objects (becomes the father in the childnodes). Every object burning inherits the type "fire" with all his scripts . Furthermore the combustion process involves all the objects that have the "burning" script inside the same room (this is dangerous!)
The burning object loses volume every turn.
This is a very "simplified" idea of the real combustion process. Could be a starting point to make some type of crafting library.
If you are interested I can share ideas an code here in this forum, naturally. My big problem is the "organization" of the developing work (script and functions). I am a programmer but I have no experience in videogame code developing.

@pascal feel free to download my world template here

Fire is my most-developed part of my template (aside from a world clock time and regions/ambience).

What you want to look at are the class libraries for fire, and you can see how they work by:

  1. Start the world template.
  2. Wait about a minute for the sun to come up (was in the middle of testing world time)

Then try the following:

get match
You pick it up.

light match
The match ignites!

light candle with match
The candle ignites!

douse candle
You douse the candle.

light candle with match
The candle ignites!

Then, just stare at the screen for a second, then the following happens:

The match burns out.
There's nothing left of the match.

And then wait even longer, the following happens:

There's nothing left of the candle.

Hi all, and thank you (Xordevoreaux) for the reply!
I just rewrite my post to the "Libraries and Code Samples" section, because here it's a bit off-topic. I tried to remove the old posts but it's no possible so I replaced the posts with some lines. Please, people forgive me for this.
The lib is "FIRE."


We've never had an update that completely broke old games and left them broken. Last update, all or most of the games online were unplayable except for the web editor, but that was fixed in a month. The games are left unplayable due to oversights, not planning.

If you want my prediction, I predict Quest 6 will fail, and after a month they'll switch back to the last update. That's just based on previous updates.

To echo what others have said to some degree, we do strive to ensure old versions of Quest are still playable, and there are definitely games written in Quest 4 that can still be played, despite it being an entirely different system with a different game format. In theory Quest 1 games can still be played (I think it uses the same basic format as Quest 4).

Quest 6 runs in the browser; it is just a web page. This means the website does not need to be changed - it already handles Quest 6 games.

Quest 5 will continue to be maintained. It is unlikely to have any big updates but bugs corrections will still happened.

@The Pixie Well, now I just feel dumb. Sorry.

Sounds like functionality for playing locally with no internet connection ceases with 5.x, right? goes down for any length of time, only people with the 5.x standalone editor and local versions of a game can play.

You will still be able to download a game with 6, and then play off line, you will just be doing that with the browser. However, if the server goes down when you are in the middle of playing game, you will not notice, you will just keep playing.

Will you be providing an abstraction layer that is quest-specific for programming or is everything going to be in 6.0 raw javascript?

It will be (and in fact already is) all in JavaScript. The hope is that that is not so different from ASL (the scripting language for Quyest 5) when wrapped up in an editor. How far scripting can be done graphically I am not sure; probably not at all in the first instance.

My template is heavy with functions, etc, pieced together from examples on the forums here. Functions all in javascript don't even begin to look like ASL.

Overall it's disheartening to think all my functions will need rewriting from ASL to Javascript to squeeze them into 6.0, because it's not exactly like there's a ton of javascript-based function examples on the forums here, but I'll reserve any further judgement until I actually fire up 6.0.

Thank you for your replies.

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