In Part 1 of this blog, I looked back over the last year of working on Quest full-time. That covers the “what”, and for this second part, I want to take a look at “how well”. What have been the good and bad parts, and what are my aims for Quest in the future?

I’m interested to hear your own views on this too, so please add your thoughts to the comments!

The Good

My Britishness makes me shy away from blowing my own trumpet too much, but I think it’s worth saying that I’m really happy with the general design of Quest. Joel Spolsky may have said many years ago that the worst strategic mistake any software company can make is to rewrite the code from scratch, but I think in this case it was totally the correct decision. We now have quite a flexible architecture that handles creating and playing games across multiple platforms.

There are two “engines”:

• the Quest 5 ASLX engine (called WorldModel)
• the legacy component for running old Quest games (LegacyASL)

There are currently three different user interfaces:

• the desktop Quest software
• the “play online” software (WebPlayer), which has different modes for desktop and mobile browsers
• a simple console-mode player (QuestConsole), in source code only – the idea being that this can be used an example or foundation for building other UIs in the future, e.g. an implementation using Mono for Mac and Linux

The Quest 5 WorldModel component itself is used not just when playing games, but also when editing them. This means that the player and editor can make use of the same code – for example, for performing undo/redo, and for saving and loading games. The standard game logic doesn’t appear in the WorldModel component, but exists in a separate Core library. This Core library defines not just the behaviour in the player, but also the editor interface. The editor logic itself sits in a separate EditorController component, which has two user interfaces:

• the Editor component of the desktop Quest software
• the web-based Editor

Having the Core library define how the editor looks, and the EditorController exposing that to the user interface, has massively cut down on effort getting the web-based editor to work. There is definitely a tendency towards over-engineering in software development, but in this case creating my own editor forms framework, supporting both desktop and web, has reaped dividends:

The desktop editor design…

..can mirror the web editor design

New features can be added to the Core library, and to the editor, entirely within ASLX library files – no need to change any C# code, no worries about breaking existing games (when published, game files include all the library code they’re using), and both the desktop and web editors instantly handle the new feature.

This design made the migration of the desktop editor from WinForms to WPF between Beta 1 and Beta 2 much simpler. In addition, Gamebook mode is able to use this design to define its own entirely separate Editor interface. I think this design will continue to prove its merit as more third-party libraries are created, which will be able to both add additional functionality to Quest and be instantly supported by both versions of the Editor without requiring any of the system code to be modified.

I was also glad that I created the Core library from the beginning to be language-agnostic. There is no hard-coded English text – instead all language text comes from a template. We have templates for 5 languages now (6 as of Quest 5.2) – we just need to see some games being published which make use of them!

HTML was a good choice for the player interface. I designed Quest 5 from the start so that games could be played online, so it made perfect sense for HTML to be the output format. This opened up a lot of flexibility, making it easy to implement things such as hyperlink verbs – which I think work very well, and have translated very nicely into the smartphone UI. HTML also means that it was easy to implement things such as embedding YouTube videos.

So, overall I’m pleased with how the design has panned out. Pretty much any new feature that is requested can slip fairly neatly into the existing architecture – in fact many features now can be implemented entirely within the Core library, which means minimal risk and they “just work” everywhere – truly a software developer’s dream!

The Not So Good

There is always room for improvement. Although I’m fairly pleased with the Script Editor, sometimes I feel it can be a bit inflexible. I think it handles the majority of scripts well, but some things feel more difficult than they could/should be such as including “and”/”or” in an “if” expression – currently you have to switch to “expression” to do that, but then the helpful dropdown lists of objects etc. aren’t available.

It’s been interesting creating the web version of the Script Editor – somehow, to me it actually feels a bit easier to use than the desktop version, which is a surprise. It just feels cleaner to me – the user interface doesn’t get in the way so much, because things like the cut/copy/delete buttons only appear when you’ve actually selected something. And maybe the web UI idiom of using tickboxes to select things is actually better than the desktop version’s “rich listbox” approach?

The desktop Script Editor is OK, but…

…the web-based Script Editor feels nicer to me

The web editor’s psuedo-popup script adder also feels easier than the desktop adder, which often seems “slippery” to me as it expands beyond the bottom of the current scroll area. I also think I prefer how the web editor places the “Add new script” button where the resulting script will actually be added – in comparison, the desktop’s adder expander feels a bit more detached from the script you’re actually editing. So, maybe one way to improve the desktop Script Editor would be the make it more web-like. I also think it would be nice to have a code view toggle for the Script Editor, so you can quickly dive in to the code without having to reload the entire game – this would also be another step towards pushing the “use Quest to learn to code” side of things.

I do wish I’d been a bit more careful with some of the terminology used with Quest, but it’s probably too late to change much of it now. Sometimes things are ambiguous and in at least one case the terminology is just plain wrong. The word “type” has at least four meanings – a class, a data type, “Object” vs “Room”, and “Inanimate” vs “Animate”. It even appears twice on the same editor screen – on an object editor you have one place to specify “type” as “Object”, “Room” or “Object/Room”, and then a few lines down you can choose a “type” from “Inanimate object”, “Male character”, “Female character” etc. The usage of the word “article” is simply incorrect – it should be something like “subject pronoun”, as “article” means something entirely different. I would also prefer “Room” to be “Location”, as that would be more accurate. I probably won’t be able to change any of these until there is such a thing as Quest 6.

Spot the mistakes!

Staying on the object editor, there are probably too many tabs here already, and as more features are added, and third-party libraries are created, this could start to become a problem. Most of the tabs are not relevant for most objects though, so the fix will probably be to make certain tabs context-sensitive, only appearing at all for particular object types, which could be specified on the Setup tab maybe.

The number of tabs is starting to become a problem

Having the documentation in wiki format means it is reasonably convenient to write and maintain, but it’s a pain for anybody who wants an offline version. There are various options for converting a wiki to PDF but they are all complicated – mostly requiring the installation of plugins on the server which need root access. But every wiki page has a “Printable version”, so surely it can’t be hard to write a little app which can be run externally and just spiders these? There’s an idea for someone out there!

Accessibility is more of a pain than it really ought to be. JAWS is probably the most widely used screen reader for people who are visually impaired, and it works with Quest – but only up to a point, and it’s not been smooth sailing. Sometimes it reads text out automatically and sometimes it doesn’t, so I had to add code to ensure game output was always read out. I am not a JAWS customer myself so that makes my support options limited. There is also a problem with labels in the Editor not being read out, and this is still unsolved – StackOverflow is usually good for this kind of thing, but even though some people have offered help, my question still doesn’t have a satisfactory answer. The web version of the editor should be easier for a screen reader to handle, which mitigates this somewhat, but it’s still hugely frustrating that what should be a great platform for visually impaired gaming isn’t as good as I want it to be.

Things That Changed

Windows Forms was a bad choice for the initial Editor implementation, and as I wrote yesterday it took a few weeks to redo this, but it was well worth it.

In implementing the JavaScript converter to allow games to made into apps, a load of synchronous (i.e. thread-blocking) functions had to be deprecated. This was a pain, in particular because I had to substantially re-engineer the parser – I wrote more on this at the time. Could this have been foreseen earlier? Possibly – suspending a thread in the background while awaiting on user input wasn’t ideal for the “play online” server for example, although it had never been a problem.

My initial implementation of “static picture frame” attempted to demonstrate that the player UI could be completely customised with HTML and JS, without the underlying Quest code knowing anything about it. However this didn’t work very well as the resulting HTML/JS made assumptions about the rest of the Player HTML, so when this changed, the implementation broke. This was bad because this “detached” implementation was then wrapped up in games packaged with version 5.0. It required adding some Quest code to detect this and replace it with the new implementation. In hindsight, a static frame is such a standard thing that this should have just been “baked in” to the Player from the outset.

For version control, using SVN on CodePlex was possibly the wrong choice. I’d chosen CodePlex as apparently the best place to find .net developers – and although I had signups it seemed that a lot of them were people who sign up for a lot of projects, probably to make their profile look good to somebody. SVN on CodePlex runs over TFS, and this was incredibly buggy. It turned out that simple things that you would expect to be able to do in SVN, such as branching, simply weren’t possible. Astonishing! I toyed with moving over to Github, but git is frankly too unpleasant on Windows, and some users who had already been making contributions to the Core library weren’t comfortable with it. In the end I settled on sticking with CodePlex and migrating to Mercurial. This has turned out to be a good choice – it works well on Windows, and I didn’t have to migrate the non-VCS stuff like Quest’s Issue Tracker, which is the main way I organise what I’m working on. Recently, CodePlex has started getting a bit of love and attention once more – after languishing for a while, they’ve started adding more features again, so hopefully it’s a good place to stay for the future.

Other Thoughts

I’ve been pleased at the number of people willing to help out by creating Quest translations. Weirdly this hasn’t resulted in many non-English games yet though. Also, I was hopeful that more people would join in and contribute to the C#/VB.net code – there have been a few contributors, but generally it seems people are far happier to use open source software than contribute to developing it! This is probably an absolutely typical experience though. CodePlex has a system where you can advertise your project as requiring help – I was blown away by the number of volunteers who signed up, but none of them subsequently did anything. It is probably a backwards approach to recruiting developers – it’s probably the case that existing users who can code are much more likely to help out than people browsing CodePlex for projects that need assistance.

I’m really happy with how well Quest is working in classrooms. It has been something at the back of my mind for a long time, the thought that schools could make use of Quest, and finally it’s happening. It seems like the time is right for it, as over the last year it seems everybody has woken up to the fact that we need to teach kids how to code, and we especially need to encourage the girls. There is a lot more work to be done in this area especially.

Some Numbers

• I started tracking “play online” counts on 7th February 2011. Since then, the total number of games played online is 166,000. That was 422 days ago, so around 400 games played per day or about 144,000 per year.
• Total game download count since the same date is 60,000, so that’s about 140 game downloads per day or 52,000 per year.
• The desktop version of Quest is launched by about 120 users per day.
• About 40-50 new users sign up daily to play or create games at textadventures.co.uk. This is a huge increase from only 1-3 a day last year, as new features like saving games and creating games require a login.
• The web-based Editor only went into public beta three weeks ago, but over 300 games are currently in progress.
• There are 380 games published on the website – 76 games added in the last year

It will be interesting to revisit these numbers again in a few months or a year’s time, especially with the web Editor making it easy for anybody to create games anywhere.

Your Feedback

Please add your thoughts to the comments, or send me an email!

Just over one year ago, at the end of March 2011, I left my job to work on Quest full-time. One of the nice things about not working for an employer has been a complete absence of such time-wasting exercises as conducting an annual performance review. However, there is something to be said for periodically taking stock, and seeing how far and how quickly things have progressed. So, here’s a review of one year of working on Quest.

A Brief History of Quest

By way of introduction, let’s wind the clock back not one year, but almost fourteen. Quest has been part of my life for a long time. I started work on Quest 1.0 in 1998 – I was a bored 16 year-old looking for a coding project during the summer holidays, and I wanted to create something using Visual Basic 5. I thought a text adventure would be a simple way to start, but I didn’t want to hard-code the entire game – some sort of engine would be what I needed… I never actually wrote a text adventure in the end, because writing the engine was too much fun.

I kept tinkering with Quest in my spare time while I went through sixth form, university and my first job – which was doing technical support. I got bored of that – solving the same problems over and over again has never really been my thing – so in October 2006 I quit my job and decided to work full-time to create Quest 4.0, which at the time I was selling on a “shareware” or “try before you buy” basis.

I failed to really make much money doing that, and from May 2007 Quest became a spare-time project again as I got my first “proper” developer job.

Rip it up and start again

I definitely learned a lot in the first couple of years working on “someone else’s” software – it taught me a lot about how large software should be structured. It also taught me a lot about what not to do – the company I worked for was stuck with a huge legacy codebase which nobody fully understood, and was liable to break in all kinds of subtle ways.

I carried on working on Quest 4, but I was becoming increasingly frustrated with it. I had a lot of ideas for things that I wanted to do, but which were simply impossible given that its design had never really been thought through particularly well, and it had grown a lot over the years into what was approaching an unmaintainable mess. It was also written entirely in Visual Basic (version 5, and later 6), which meant it was getting painfully out of date – that language not having received an update since Quest was first created a decade previously.

Around April 2009 I started playing with some ideas for how Quest ought to be, writing the bare bones of an entirely new system in C#. This grew into Quest 5.0, announced in January 2010 – a completely new text adventure system, sharing pretty much just a name with Quest 4.

By July 2010 I’d got fed up with my job, and quickly found a job with another company. Too quickly, as it turned out, and I got pretty fed up there too, so in March 2011 I handed in my notice. By this time I had refactored the old Quest 4 VB6 code into a component that plugged into the new Quest 5 architecture, and I had announced that the new system was to be open source. The new Quest was shaping up nicely, and I submitted a couple of examples of its new “play online” interface to the IF Demo Fair at PAX East.

Alongside the demo of the regular “play online” interface was a split-screen demo, showing off the flexibility of the new system – I think this kind of customisability of the Quest 5 interface is an area which still hasn’t really been fully explored yet, which shows the potential of Quest which still remains untapped.

Split-screen text adventure prototype

The year in review

So we finally reach the start of the year. It was the start of April 2011 and I was working on Quest full-time, without much in the way of a business plan – I was just really sure that I wanted Quest 5 to exist, and, if nothing else, it would probably add a lot more to my CV than working for somebody else for the equivalent amount of time.

One of my first tasks was to redesign the website, moving the main Quest site from the old axeuk.com domain to bring it together with the games at textadventures.co.uk. This was light relief from the meatier task of working on the Quest 5 Editor, the bare skeleton of which was already in place, but most of the editor controls and functionality had not yet been implemented.

textadventures.co.uk website, old and new

In May, I carried on working mostly on the Editor, culminating in the release of the first beta near the end of the month. The Script Editor looked a bit different in this Beta compared to later versions:

The Script Editor from Quest 5.0 Beta 1

This Editor was written using Windows Forms, and although it mostly worked, it could be quite glitchy. Screen elements would often not draw correctly, and I was also not entirely happy with the design – in the screenshot above, you have a list of script commands, and the editor for the selected command appears below the list. This was similar to the design of the Script Editor in Quest 4, but it looked harder to use than it could be. Wouldn’t it be better if the “Hello world” in the list was directly editable in-place?

Windows Forms was clearly never going to be up to the job – WPF looked like the more flexible and modern solution. It was going to be a pain to throw away a lot of the code I’d been working on, but I’d been careful throughout to separate the UI from the underlying Editor logic, so it was “simply” a matter of entirely replacing the user interface.

So, in June, I sat down and taught myself WPF. In total it only took about two weeks to redevelop the WinForms code. It felt painful at the time to do two weeks of work and essentially stand still, but it was well worth it. All the weird layout glitches went away, and I was able to implement the design I wanted for the Script Editor:

The Script Editor in Quest 5.0 Beta 2 (and now)

I released beta 2, and by now was eyeing the final release of version 5.0. A lot of the “nice to have” features logged on the Issue Tracker were moved to later versions – it was much more important for Quest 5 to be “out there” than perfect. Over July 2011, I released beta 3 and beta 4, and worked on getting the documentation done, in particular the tutorial. I decided that it was time to stop adding things, and declared that beta 4 was feature complete – after a few months of working on Quest it was time to tie up everything and release a production quality version.

Over August, I released various release candidates, and finished up the documentation. I also squeezed in a week up at the Edinburgh festival, and while I was up there I met up with my nemesis/arch-rival/fellow text adventure engine creator Campbell Wild, the man behind the ADRIFT system.

Finally at the end of the month, Quest 5.0 was ready.

Trying to reach a bigger audience

So, I had created the software. The next focus then had to be getting people to hear about it and use it! I submitted a press release, which perhaps inevitably didn’t really get very far. I attracted more visitors with a short blog post about Quest on Gamasutra.

In hindsight, perhaps this isn’t surprising. “A new piece of Windows desktop software that gives you the ability to write a text adventure game” somehow doesn’t have a great “hook” to it – I think it’s much easier to announce a game than it is to announce a system for making a game, as with a game you’ve immediately got something to demonstrate – a game system is harder to get your head around. Furthermore, nobody gives a crap about Windows desktop software in this day and age – when was the last time any such software was newsworthy?

It was this realisation that fuelled the subsequent Quest projects. It was time to move beyond the desktop.

Pick up the phone

In September 2011, I started work on getting Quest games onto smartphones. While I was working on Quest 5.0, I’d thought I might achieve this using MonoTouch for iOS and MonoDroid for Android. However, these products are fairly expensive, and I wondered if having a Quest game running on top of the Quest platform running on top of the Mono platform running on top of the underlying mobile OS was a recipe for terrible performance.

Fortunately I had a bit of an epiphany while cycling one lunchtime and realised that an even better platform would be JavaScript, because this can be wrapped with PhoneGap to create “native” apps for all major mobile OSes. Quest’s ASLX programming language is conceptually pretty similar to JavaScript, so the “only” effort required would be to reimplement Quest’s C# platform code in JavaScript, and then write a converter to convert ASLX into JavaScript. The UI would be relatively straightforward because I could just use HTML, and Quest was already written with that as a target output format.

It only took a couple of weeks to get the basics up and running, implementing a converter plus the necessary code to get a game running. This would only work for Quest 5.0 games though – if I wanted to actually release a Quest game as a mobile app any time soon, I had a problem because all the existing games were for Quest 4.x and earlier. So I spent a while working on another converter, so that with Tim Hamilton’s help we could convert his Quest 4 game “The Things That Go Bump In The Night” first into a Quest 5 game, and then into an mobile app.

In October, I released the first bug-fix for Quest – v5.0.1. I was quite pleased that nothing too serious had come up in the six weeks since the original 5.0 release – all those betas and release candidates had been worthwhile. I’d also started working on Quest 5.1, adding the enhanced game browser (converting it to WPF along the way), and adding a Simple Mode based on feedback from Kristian Still, who was starting to use Quest in the classroom.

The major changes in Quest 5.1 though were brought about by the requirement to be able to convert to JavaScript – the inability of JavaScript to use threads turned out to be a significant limitation, as a lot of the 5.0 code was written assuming that there would never be a problem with stopping a thread from processing in order to ask the user a question, for example. This meant that the app conversion didn’t turn out to be quite as simple as I thought it would be, and it was the end of November before the first Quest iPhone app was submitted to the iOS App Store.

Interest was picking up in using Quest as an educational tool, fuelled mostly by Kristian Still’s enthusiasm. I presented Quest at the Changing the Game conference in Birmingham, all about teaching through creating and playing games, and was pleased at the response – it seemed my ideas about teaching with text adventures had at least some merit! One bit of feedback struck me though – it’s not always easy for schools to roll out software across Windows desktops. It can often be expensive, if a school is locked into an IT contract with an external supplier. This, and my general feeling that Windows desktop software is probably a bit of a dead end in this day and age, moved my vague plan for a web-based Quest Editor way up my “to do” list.

So, the web Editor has been pretty much what I’ve spent most of the last three months doing. I’ve done a couple of other things on the side – releasing Quest 5.1 and also enhancing the web-based player (adding the ability to save, and also making it work nicely on mobiles and tablets). I’m also nearly ready to release a beta of Quest 5.2 – notable new features being the Gamebook mode and two-object verbs.

I’m continuing to present Quest whenever I get the opportunity – in January I was at LWF, in February I helped out year 7 using Quest at Perins school and presented it to the London Educational Games meetup, and in March I did an online TeachShare. There should also be a workshop Games Britannia in July – hopefully more details on that soon.

What’s next?

After the release of Quest 5.2 (including the web Editor), what’s next? The Issue Tracker has many items logged for Quest 5.3, and there is still work to do on the smartphone apps – bringing them to Windows Phone 7, a better layout on iPad, and converting more games.

However, the clock is ticking, and my bank balance is emptying. It is likely that I will have to return to some more regular form of paid employment pretty soon, which will mean Quest becomes a spare-time activity again, and the pace of updates will slow down a lot.

If you think all of this is worthwhile, you can help make more of it happen sooner. Please consider making a donation towards the development work. Maybe you’d like to sponsor me to work on a feature? I would love to hear your thoughts – please get in touch and let me know.

Alternatively, if you’re a developer – with knowledge C#, VB.NET, ASP.NET or JavaScript etc. – why not join in the open source project? If you need help, drop me an email or go to the Developer Forum.

In the next blog post, I will continue my “appraisal” of Quest, looking at what works well, and also at what an HR department would euphemistically call its “areas for improvement”.

Quest lets you add verbs to objects, so you can provide the player with varied and interesting ways of interacting with things in your game. You might add a “read” verb to a book to allow the player to type “read book”, or add an “eat” verb to a burger. By adding these verbs to the “display verbs” list for an object, they appear on the hyperlink menu:

But what if you wanted to do something a little more complicated? Light the kindling with the match for example, or inspect the flock of hair under the microscope? In Quest 5.1 and earlier, you would have to set up a command – “light #object1# with #object2#” – and then add some script to see if object1 and object2 made sense. And then, you would be making your game harder to play, because the player is forced to type that command – there’s no way of clicking or touching to trigger a command requiring two objects.

Quest 5.2 makes this easier by introducing two-part verbs. These fit in with the existing verbs mechanism, making them very easy to set up. Best of all, they’re mouse and touchscreen friendly.

Setting up a two-part verb

The process for setting up a two-part verb is very similar to setting up a normal one-part verb. Just go to an object’s Verbs tab and add the verb you want. In the screenshot below, we’ve added a “light” verb to the “kindling” object:

(Note – these screenshots are from the web-based Editor, but the steps are the same on the desktop version)

The next step is to set the verb option to “Require another object” – a new setting in Quest 5.2.

This will then give us an editor where we can add objects which can be used to the light the kindling.

We can now set the script that runs when we light the kindling with the match:

Finally, let’s add “light” as a display verb for the kindling object, to make this verb usable with mouse or touchscreen.

Playing the game

When we play the game, we can type in “light kindling with match”, and we get the expected result – in this case, we see the message “The kindling vanishes quickly in a brief burst of flame”, and then the kindling disappears.

But we can also activate this command using the mouse or touch instead. We added “Light” as a display verb, so we can select that:

Selecting this brings up a menu of things we can use to light the kindling with:

This menu shows all visible objects, excluding the object we just tapped on – in this case, we only have one other object in the room, the match. We can tap Select to trigger the command:

Sensible defaults

By setting this up as a verb, we get a lot of functionality for free. Previously, in Quest 5.1 and earlier, if we’d set up a custom command for this, we would have had to manually deal with the case where the player tried to light the wrong object. Here though, Quest sensibly handles the full range of things a player might type in – “light flower pot”, “light kindling with egg”, “light myself with match”, etc.

Use and Give

The existing “use” and “give” commands have been updated in Quest 5.2 to display a menu like the “With which object?” menu shown above if the player tries to use them on their own. This means these commands can now also be used without typing.

Try it out now

This functionality is part of Quest 5.2, which will be in beta soon. In the meantime, I have already deployed this new feature to the web-based editor preview, so you can try it out online.

Please let me know your feedback in the comments!

If you use Google Chrome, you can now add the new web-based version of Quest into it as an app, via this link.

Once you’ve done that, Quest will appear on your Apps tab:

That’s all there is to it – it’s pretty much just a link for now. In the future, it could be enhanced to log you in automatically with your Google account, giving you quick and easy access to your games simply by logging in to Chrome.

The web-based version of the Quest editor is now available publicly for the first time. Many thanks to all those who tested it during the closed beta – your feedback has been really useful. Please keep it coming!

I’ve redesigned the Quest page, to reflect the fact that for the first time Quest is now available on more than one platform. Whereas before it was a Windows-only download, now you can access Quest from anywhere, in any browser.

I don’t expect the desktop software to be disappearing any time soon, but with the increasing popularity of always-connected devices such as tablets, it’s clear that any popular software will really need to be available as a web app.

Quest was the first system to allow people to play text adventure games online (as far as I can tell – Quest has had this since February 2007, and I can’t find any references to Parchment before 2008), and now it’s the first full text adventure editor to appear on the web (i.e. it’s much more than a big text box!). Currently, about 10 times as many people play games through the web than download them to play offline, and I’m hoping that the new web-based editor will similarly increase the reach of Quest. It’s not just about extending the editor to Mac, Linux, iPad, etc. – many people simply can’t (or won’t) install software even on Windows PCs.

But it’s also more than just making the software easier to access on any device – it opens up new possibilities too. For the first time, you can start editing a Quest game at home on your PC, continue it on your iPad in the bedroom, and pick it up again during your lunch hour at work. If you’ve got good mobile coverage, and even better eyesight, you can continue on the bus home!

It also means collaborative game editing will become possible, and this is something I plan to look into soon. I’m keen to hear any more suggestions, so please add your comments below or drop me an email.

You can find out more about the web version in the original announcement, but why not sign in and start using it now?

What’s not implemented

This is still a beta version, so a few features are not implemented yet. Most importantly, at the moment you can edit and play games while logged in, but there’s no way to publish them on the site yet. This is partially because I’ve simply not implemented that feature yet, but also because the web version is Quest 5.2, and the desktop version of this is not in beta yet (so that would mean any games you published would not be playable on the desktop). Both Quest 5.2 Beta for desktop, and the ability to publish games, are coming soon – probably within the next few weeks.

Also, some of the more advanced features of the Quest desktop editor are not yet implemented on the web version. These will probably be added later, after the first “non-beta” release (probably as part of Quest 5.3 later this year). These are:

• walkthrough editor
• attributes editor
• verb definition editor
• “Advanced” section (libraries, templates, dynamic templates, object types, JavaScript)

I look forward to hearing your feedback! You can email me or send feedback via Uservoice.