I've had a couple people tell me that after playing some games online, after a little while of game play, they cannot enter any new commands. This has happened to me as well especially if I play for any extended period of time (more than 15-20 minutes). I know this has been an issue in the past and just wondered if others have the problem or know if there is a solution on the horizon.

When that happens to me, I just assume it's my computer running out of memory. I figured it might be an issue with the site as well, probably. Good to see it's not just me.

I think there are just too many people using the server when that happens.

The amount of time I've been playing doesn't seem to matter. A command just hangs 1 out of 10 times. Sometimes, it eventually goes through and play resumes. Sometimes not. It usually happens within the first few turns if it's going to happen to me.

It's hopeless, I had to get my beta-testers for my most recent game to test using offline version of Quest. I have just submitted my entry to the Spring Thing, this will be the last game I write using Quest unless this problem is resolved. It has been continually raised for at least the last 12 months and no solution. I have even offered to chuck some money at the problem as I like the Quest engine so much.

I'm not 100% on the inner-workings, but...

When you use the desktop version of Quest, you can hear your PC ramping up when entering commands that trigger complex scripts. (This also happens when the desktop editor loads a good-sized game.)

Now, as far as I can tell, the online server is acting as each online player's PC. Each time a command is entered, that is sent to the server. The command then runs through Quest, the scripts run, and the server sends the output back to your browser, which prints the text (adding images, audio, and/or video, if applicable) and then runs any Javascript functions (including changes to display settings and a timeout if there are any scripts running which pause the game for input).

So for each person playing a game, for each command they enter, that server is going through the same strain as your PC when using the desktop player, but it's handling a large number (hundreds? thousands?) of commands simultaneously.

Did I get that right? Please, correct me, if not.

Furthermore...

If you go back and read Alex's posts and blogs concerning this, he knew it was a problem as far as people without Windows machines are concerned.

He began three projects, each of which compiled games to websites. This would make it so this site's server's only job would be hosting files. Also, we could upload our zipped website to our own website (or basically any website on which we could host files). Every one of these projects were abandoned before completion.

QuestKit is the best of the bunch. It is available from NPM (or you can get the source code from Git, or you can go to the QuestKit documentation and play with it in ScratchPad). It will allow you to create a very basic game, which is compiled to a website (or you have other compiling options), but it is a command line program. You have to code. It's not any language Quest uses. And a compiled game LACKS MANY FEATURES.

QuestJS would be the bee's knees, if it worked. This converted your published .quest file to a website. ...or it was meant to do that. A few of us pitched in and got it working a little bit, but the recent changes to the TAKE scripts rendered QuestJS useless. ( I will note that we did create a mod of this which will produce a working website, but your game can't include a map, any timeouts, and numerous other things. I don't recommend QuestJS to anyone any longer, though. It has a very high failure rate, even when you follow the known "rules".)

Quest 6 (the worst of the bunch) was intended to work just like the current version of Quest, only it would use the stuff from QuestJS to publish games directly to websites. The player was intended to handle these websites AND convert old Quest games to websites in order to load them in the player. If you read about this, it will seem that Alex was excited and making steady progress. I believe this was true for a while, but it seems that he hit a dead end quite early on. I've built Quest 6, and it still published a normal .quest file. The player and the editor were separate. The editor works just like Quest 5.6, and the player will only successfully run the provided example game, and that's after you install some stuff with NPM and start up a local server.

Once upon a time (I hope I've got this right!), Alex created Quest as a summer project. He used the programming language(s) he was learning at the time to build it. As time progressed, he learned new languages and things, and he integrated them into Quest, building upon what was already there each time. (Most of the things he included depend on programs and/or features which are only included in Windows, by the way.) EDIT: See this post for the actual facts.

So, Quest is a multi-programming-language, multi-human-language, single platform engine, with a GUI which loads in a web browser. The desktop player has the Chromium web browser embedded into it, and the web editor communicates with your browser via the server. Nearly every script that runs in the desktop version is passed from the browser, to Quest, to Windows, back to Quest, and back to the browser. (If using the online version, that would be browser -> server -> Quest -> Windows -> Quest -> server -> browser.)

Did I get this bit right? Please, correct me, if not.

If I have a point it is this:

Alex knew that Quest needs to compile to websites for a better experience during online play. At this time, we have quite a few people contributing to Quest, and at least two of those people are trying to come up with a good way to accomplish this, but Quest is so feature-rich... It is a daunting task.

Thanks K.V.

It’s really useful to see the whole timeline of this to someone who has only been around Quest for just over a year.

I appreciate that the service is free, and lots of very smart (and generous) people have and are working on it.

Once upon a time (I hope I've got this right!), Alex created Quest as a summer project.

There is a timeline of Quest here.

Wow.

I think it is an amazing accomplishment to create something as versatile as this with such an unstructured approach.

I am full of respect.

I know quest is not supposed to make money.
But I guess the server is running in some kind of cloud service?

If that is the case, then perhaps some sort of crowd funding could be set up to allow the users to donate a few coins to help buying a larger server.
I know I would be happy to contribute.

Best regards
Benny

The server is running on Azure, which is a Microsoft service, but that is as much as I know. It is Manowar who handles the servers.

I think it is an amazing accomplishment to create something as versatile as this with such an unstructured approach.

Quest is actually very well structured.

I feel I may have gone a little overboard while bashing the web version of Quest in my earlier post, but the web version is just ...what's that word? Oh yeah: wonky. And that seems because of all of the scripts Quest is running behind the scenes. These are the scripts which provide all of the awesome functionality, by the way, and things usually run smoothly unless our game has lots of attributes and turn scripts and change scripts. That's when the browser usually bogs down. (This is why you should never play my games online. Play them in the desktop version. I've got TONS of things going on in the background! I'm a crazy person!)

NOTE: THE REST OF THIS POST IS MOSTLY CONJECTURE (EXCEPT FOR THE PART ABOUT MACS. THEY WERE AND STILL ARE EXPENSIVE.)

I don't think Linux was popular at all when Quest was first created, and Macs were (and still are) quite expensive, so the majority were Windows users. So Quest was designed for Windows.

Later on (still conjecture), quite a few people in houses with no Windows wanted to use Quest, so the web version came to be.

You can go to GitHub and peruse the source code if you'd like to see how complex Quest actually is. Being familiar with the following programming languages (and some others, with which I'm completely unfamiliar) will be helpful:

C Sharp
VB.NET
HTML
CSS
Javascript
XML

Excellent timeline, Pixie! (I just now saw that post.)

I did not mean to be rude with my comment about the unstructured approach!!
It has just a comment on what you wrote about new things being added as Alex was learning them.
I have not looked at the code for quest itself, so I would not have any way of knowing whether the actual product is structured or not :-)

And I DO mean it sincerely when I say I am full of respect.

Just to clarify :-)

But what does everybody think of my idea of crowdfunding?

I did not mean to be rude with my comment about the unstructured approach

I didn't take it that way at all. That just made me realize that I had listed all sorts of negative aspects, but none of the positive ones.

:-)

I think the crowdfunding is a great idea. The most valuable thing about Quest for me, is that someone who wants to write a story has an engine that doesn’t immediately intimidate them with complicated code and is pretty intuitive to get started, and you pick up more code as you want to do more complicated things. The server issue is just that, a server issue, it may be exacerbated by the way Quest works, but surely not insurmountable with resources? Or is it? Being able to play online is a huge plus, casual players don’t want to download anything.

Being able to play online is a huge plus, casual players don’t want to download anything.

And for no other reason, this is enough. It would be an interesting questions to have answered... what would it cost/what are the resources required?