UPDATE:

This post is now out of date - for my current thinking about the future of Quest, see viewtopic.php?f=15&t=4826

Hi all

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.

Games will be converted to JavaScript to play, so there will be no WebPlayer for Quest 6 - instead there will be a JavaScript converter, based on "QuestJS" for Quest 5, which up until now has been an internal tool. This will generate HTML, CSS and JS files to play the game in the browser, with no online server component required.

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:
[list]
[*]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...

No desktop version: Yes, this is a logical step for the next Quest generation. And I think this shouldn't be a problem as far as there is an option to import and export a game file (with libraries!). In my opinion there is no other effectiv way to create a game than using a text editor.
And I hope, it will be possible to use the JS converter offline so it would be still possible to create a game completely offline.

I am a bit worried about your crystal ball. There are 138 open issues in the tracker and some are really important in my opinion (like timer problems or customisation of the gui). These issues will be done before starting with Q6?

It makes sense to make the JS converter also available as a downloadable app - its GUI is quite simple and it currently exists as a desktop app anyway.

Development of Quest 5 is still on-going anyway - I do want to fix those timer issues. But those kinds of problems shouldn't exist with Quest 6 anyway, as it's much simpler for timers to work as they're pure client-side JS.

Initial checkin of the fairly horrible QuestJS code, which will become the "compiler" for Quest 6, is now here: https://github.com/textadventures/quest

Right now it's a Windows desktop app which will take in a Quest 5 .quest file and spit out a folder full of HTML, CSS and JS. Sometimes it works - and I really do mean sometimes. Also, I was playing with the layout a bit so you'll find that right now the HTML is a horrible mess, with a textbox of the wrong size, links that sometimes don't work etc etc.

The generated JS should use some kind of namespace pattern eventually, instead of the big mess of global variables it currently generates. The good news is I know JavaScript a lot better now than I did when most of this was hastily hacked together

So there's a lot of fixing and tidying up to be done. Remember the purpose of the code will be to power Quest 6, not as a general purpose converter for Quest 5, so there are things in there that we can safely remove as we're not actually interested in supporting Quest 5 games with this.

My primary concern about losing the desktop version is how code will be entered. Right now, the UI can only edit the main game file scripts. LIbraries are considered read-only unless explicitly copied into the main game file.

My development structure is primarily library-based. Which means I have a small core game file, and then the bulk of my code (especially stuff I want to reuse) is in libraries. It helps keep me sane to be able to modularize and factor things out. So if we're going to get rid of the desktop version, I'd want a way to be able to manage and edit all the library files within the UI without having to import them from the desktop for each change. It would be way too tedious that way.

I haven't read the entire message above yet, but I wanted to inject that up front.

Good point. I think it would be good to have a library editor built-in - just a code view for each library file basically, with the ability to upload and download each .aslx file. Would that work for you?

Yep, that would be great!

While we're at it, there can be auxiliary files in general - image files, sound files, .js files, library files, css files, etc. I haven't used the web editor much. Is there a way to manage all of those? Or will that need to be added as well (perhaps as an all-around asset management ability)?

Yes, that's an area for improvement. Currently if you upload a file to the web editor, it will stay there in the game folder - there's no way of removing files, and no way to upload a file without (initially at least) using it somewhere.

Obviously, given the current state of Quest and what's been discussed so far, CSS will be able to be used to create new UI experiences for Quest games, but what I'd like to see is maybe some sort of "hooks" (not sure if this is the proper term, it's late lol) in place to help take the guesswork out of certain elements of UI design in Quest, like automatic handling of screen resolution scaling/fullscreen/anchoring elements etc. Similar to how programs like Construct 2 will automate a lot of these tasks for you in a project.

Also, I'd like a way to embed external assets directly into the project. I know this sort of already exists, but I mean more than just the file formats that are currently supported. For example, web fonts for local use (negating the need to have an active internet connection for the game to display properly), video files (or the ability to link to local video files outside of the project itself, i.e. avi video files in a /video folder on a cd/dvd).

With additions like these, Quest could essentially become the ultimate text adventure framework and really push the text adventure medium into the (relative) mainstream as games with visual styles similar to Cypher and the like could be created without the need of trying to adapt 3D game engines like Unity to work as a text adventure framework. Just my 2 cents, but as my background is as a graphic designer these are the things I tend to think about the most when coming up with a new game design.

It probably just needs the existing UI stuff to be documented, so you can more easily adapt it using JavaScript. I don't think we need more "hooks" from ASL into that stuff, as you may as well just customise it directly using jQuery.

I'm not sure there will be a great deal of value in being able to embed more stuff locally. The places where you can't get a good internet connection are ever dwindling. But with a game being packaged as pure HTML/CSS/JS it would be easy to copy some resources like fonts locally, so they're served from the same location. That would mean no need for an internet connection if you distributed the game as a bunch of these files. Video could probably be done the same way, as I assume with HTML5 it's just a matter of a tag pointing to a file which could be either local or remote.

Yeah, I know Internet connections are. Fairly common thing nowadays, but in my own experience it's not always 100% reliable so it's a dependency I'd rather not be forced to have. Plus with video, I wouldn want that local anyway because on a cell phone or something, those can eat through your bandwidth really quick, plus if you have a crappier connection the video will look like crap anyway.

Now granted, once the game is converted to JS you could go in and manually add all this stuff, but it would be less work (and less problems to debug) if Quest just allowed you to add them. Maybe I'm the only one who would care for this as a feature, but it's a workflow that I'm familiar with, having used programs like GameMaker, Construct2, Unity, etc. So adding it would maybe help people who've used those programs be more familiar with quest?

As for the jQuery stuff that's true too, but not accessible to people coming to Quest who don't know how to program. Having some UI customizations like that built into Quest would allow non-programmers a little more flexibility in creating unique UI experiences with their games. Since Quest is designed to make the process of creating text games more accessible, I would think it would be helpful to extend that to all aspects of the game creation process and not just the game logic. That's just my opinion though, obviously.

I've been away for a while and haven't been keeping up with a lot of this so I'm a bit late to the party, but sorry, I'm calling bu11sh!t.

A desktop version will always be more responsive, customisable, and easier to use than a web-based version. It doesn't matter how good internet connections get on average, a web version will need to contend with Wi-Fi signal dropouts, ISP problems, server loads, problems with browser software etc. A web version prevents anyone from using Quest out of the home in cafes, trains, planes, etc.

Only having a web version has a psychological association that this product is for half-baked amateur works. There are online photoshopping tools but you can guarantee anyone worth their salt prefers the stability of desktop photoshopping software. I've given some others a try and I honestly believe that Quest is the best IF software out there, but at the same time I can not deny that the best games are always made using something else. Why is this? If you can't attract the people making good games, why would people continue to use Quest?

The one thing a web only version would have going for it is control. The amount of centralised control over the games provided is markedly greater. Which is perfect if your focus is on providing your services for schools. Schools generally don't like installing software on their computers, they need to control and monitor what the kids are playing so keeping it web-based makes sense. And if this is the direction you're trying to push the product in then why would you want to waste your efforts on maintaining a desktop version?

I'm not trying to say that any of this is automatically a bad thing or some sort of "conspiracy." Just don't pretend that it's the next logical and inevitable step in the evolution of IF software, and that it makes no sense to have a desktop version in this day and age. Don't pretend that it's actually in the interest of game writers who actually have the skills, and want to put the time and care in to make a game worth playing. I can appreciate that every effort is being made to preserve as much of the customisable aspects of the desktop version as possible, but there will always be more limitations imposed by a web based version than a desktop.

Here's a question -- why would you have be online to use a browser-based Quest editor? What is the server doing that you couldn't do on the client?

It would be beneficial to find a way to allow a game to be played completely client side. That way people can play offline if they want to. Always online requirements are getting a lot of heat these days.

It wouldn't hurt to take a look into chromiumembedded/Brackets Shell or AppJS to make a faux desktop version of the editor/player. Some people tend to be more comfortable with them, and this way you won't have to rewrite pretty much anything (but you could optionally add additional functionality that these wrappers support, like file saving).

But this of course would require it to be entirely client side.

It would be a shame to have an online only setup. Web connectivity in many, many areas is just not present. Take Canada, for example, a supposedly 'developed' nation where I live. In a city, fine yes ... even though the reasonably priced carriers have spotty networks. In a rural area? Forget it unless you want to pay big dollars for what amounts to dial-up speeds over a 3G network with data capped in the 5 to 10 gig per month range. Every extra gig overage? Add $50 plus to your bill that month.

Plus usage on the go, even in major US cities, you hit dead spots in networks. So many people use their mobiles in off time like on a subway or bus ... online only is a terrible idea.

Client side app options are a must.

IIRC you need to have a desktop version for Steam Distribution too. It looks as if Quest 5.X can manage a Steam viable product but again ... online only ... forget it, you don't qualify.

EDIT: It is a very optimistic view that these sorts of connectivity issues will be solved in the next decade outside of very advanced nations (i.e. maaayyybe Scandinavian nations might get good rural service). Add to the fact that international markets already have the largest portion of netziens, China, for example. These nations represent a valuable business opportunity that due to connectivity restrictions imposed by local telcos / govt (i.e. the great firewall) make server side a non-option. Online only vastly cuts your international sales potential.

A secure registration / DLC delivery option is something that could preserve most aspects of an online business model. Something based on whitelisted e-mails perhaps?

Also, not sure if you mentioned you were going to do this. But in Quest 6, only support Javascript for code, rather then using the current Quest coding system. Using your Javascript converter, you could convert libraries and such for Quest 6.

I am a little late to this shindig, but I have to say, the very first thing on the agenda kind of pulled the rug out from under me. I will always prefer to be able to build and play offline. Yes, obviously I have to be able to connect to the internet to download the editor and the games that come with it, but then I almost always build and play offline. If I could find a tutorial offline, as in already coded into Quest, I would not even be online accept to chat.

As others pointed out, not everyone has access to the internet twenty-four hours of the day. Worse yet it cuts in and out when a plane flies over head or there is a thunderstorm, etc. And I just hate typing things online that simply do not need to be online. (Yes I understand I am using an online forum...) I really hope you reconsider, not just for myself, but for others like me.

Now if you just kept Quest 5 as the all intuitive desktop version and kept updating it to be just like Quest 6, even if I had to wait longer for it, than I do not see a problem. But once there is a gap and no one wants to play Quest 5 anymore, because all the neat and cool features are on Quest 6 and it is online only, you have killed it for me.

However, I also understand it is more work for you to do two different versions and you only have so many volunteers. I believe I had told you all once I was planning to bring a lot of new and fresh faces to this site. I hope with my game I will still be able to do that. I just need to get it out before you guys switch to online only...

I wouldn't worry about it. These ambitions were stated before Alex announced he was getting a full time job so I doubt if it holds true anymore. If I've understood correctly I think Quest development has pretty much ended. See here:
http://blog.textadventures.co.uk/2014/0 ... ew-201314/

What we need is for people to make more public codes~libraries for us non-good-coders and non-coders to use, as Alex got quest quite completed with v550, we just need to implement its potential, more for the public's use (for us noob coders and non-coders).

And keep in mind that anyone with an interest and a desire can contribute to the Quest code base. It is open source and ready and waiting to accept pull requests for new or changed code from anyone who wishes to do so! I would not say that Quest is dead or will have no further development as much as it may either be slower or could come from others besides Alex largely (except where the mood strikes him ).

Actually I can assure you, this in no way makes me happy, actually quite the opposite. Not so much that Alex will be busy with a new/full time job/career, because that is great for him. Nor even so much that he wont be working on Quest as often if at all, but simply that he feels he has done all he can with it and that it is not quite living up to his expectations, especially for the classroom aspect... That must be disheartening...

How were the schools informed of this project? I would think, as Alex had thought, that schools and other learning establishments would enjoy this as well. For both creativity and even in classroom projects. If nothing else, since the majority of people enjoy graphical games, at least in English class or I should say any “language” class, you are stuck with nothing but words and only words to use... I would think this would be a very fun alternative. What about libraries in general or out reach programs? What about associations for the blind?

What we need is the word to be spread around and fresh faces with those willing to stay... It seems like there are really only five or so commenting on the forums... is everyone else making games? And when was this game maker first put out to the public or to beta test? Any one know?

TextStories wrote:What we need is the word to be spread around and fresh faces with those willing to stay... It seems like there are really only five or so commenting on the forums... is everyone else making games?

There are a LOT of games being made. They go into the uncategorised bit and are then moderated. Most end up in the Sandpit as they are either demos, really short or are broken in some way. What's needed isn't MORE people making games: It's those who ARE making them putting a bit more effort into their content. Making even a half decent IF game takes a bit of dedication. Quest's strength is also its weakness. It's an incredibly easy tool to learn to use. But that also encourages people to rock up, spend a few hours tinkering with it to make a game then rush to publish. Decent games take weeks/months to come to fruition, imo.

Silver wrote:

"TextStories"

What we need is the word to be spread around and fresh faces with those willing to stay... It seems like there are really only five or so commenting on the forums... is everyone else making games?

There are a LOT of games being made. They go into the uncategorised bit and are then moderated. Most end up in the Sandpit as they are either demos, really short or are broken in some way. What's needed isn't MORE people making games: It's those who ARE making them putting a bit more effort into their content. Making even a half decent IF game takes a bit of dedication. Quest's strength is also its weakness. It's an incredibly easy tool to learn to use. But that also encourages people to rock up, spend a few hours tinkering with it to make a game then rush to publish. Decent games take weeks/months to come to fruition, imo.

I agree 100%, but I was not stating specifically for new people to make games, although it is inevitable that some will. I was referring more to those coming to play these games, enjoying them and spreading the word, thus adding to the community as a whole. Those that find the game engine endearing will of course try their hand at it as well. If it means anything to you, my game is two years in the making... although to be honest it is only really a few months since I was on a hiatus.