Monthly Archives: April 2012

Quest 5.2 Beta is now available

Quest 5.2 Beta is now available. You can download the Windows version, or you can use it in your web browser.

The main focus for this release was adding that second option – Quest 5.1 was Windows-only, and the main new feature of Quest 5.2 is that it is now available everywhere.

But I, and a couple of contributors, did find some time to add some other new features to Quest too:

Gamebook mode. This lets you create “Choose Your Own Adventure”-style games in Quest, in addition to text adventure games. There is more information in the announcement blog post. I’ve added a couple of small features since that post – you can now easily add YouTube videos into a gamebook, and you can also incorporate links to external websites.

Two-object verbs. It’s now much easier to set up commands like “hit nail with hammer” or “light candle with match”, using two-object verbs.

Inventory and container limits (contributed by Pertex). The concept of a “limited container” has been extended, so you can now limit by volume of objects as well as number. For example, a bag might be able to hold 20 apples but only one bowling ball, and it’s now easy to set that up. When an object is a limited container, you can specify the maximum volume that a container can hold. For objects that you might put inside a limited container, on the Inventory tab you can specify their volume.

These limits have also been extended to the player’s inventory. Select the player object, and you can specify the maximum number of items that are allowed in the inventory, as well as the maximum volume.

Multiple switch case expressions (contributed by James Gregory). When using the “switch” script command, you can now specify multiple cases separated by commas.

Customisable room descriptions. On the game editor, Options tab, you can now specify the order of elements in the generated room description. So you can now move the exits list after the description, for example.

Health and score. It’s now easier to have health and/or score on-screen, as you can now simply turn these on from the game options without having to set up the status attributes yourself.

There are new script commands for increasing and decreasing health and score. Also, when health is enabled, the object options tab has a new “Health” section which lets you specify that an object can be eaten. If the object can be eaten, it can add or subtract health points from the player.

First time scripts. It’s now easier to run a script just once, the first time something happens – such as the first time the player speaks to a character, uses an object, etc. Previously you would have to create flags for this, but you can now simply add a “First time” script command which handles it all for you.

Easier introduction scripts. There was a change to how “wait for a keypress” (and other functions such as asking the player a question) worked in Quest 5.1, which made it difficult to insert a pause before moving the player to a room. This made it difficult to create introductory text in a game, as the player would be moved to the start room before they had pressed a key. This has now been addressed in Quest 5.2, as the core library uses a new “on ready” script command to move the player into the start room only after any waits etc. have been completed.

Hide/show objects. Previously, if you wanted an object to appear mid-game, you would have to move it from another room – maybe a dummy room used for the sole purpose of containing objects that aren’t “there” at the start of the game. In Quest 5.2, you can now hide and show objects – in a similar way to how this worked in Quest 4.x and earlier. There are new script commands for making an object visible or invisible, and there is a new checkbox on the object setup tab so you can make an object hidden at the start of the game.

Other new things:

  • When playing a game, game output is saved, so that when you re-load it later, you can see all the text that was there before
  • When you double-click an .aslx file in Explorer, Quest opens in Editor mode (.quest files still launch the game)
  • The ListExclude function can now exclude multiple items (contributed by James Gregory)
  • When playing a game online, as long as your browser window stays open, your game session should no longer time out
  • When play-testing a game from the Editor, you can now exit back from the Player into the Editor by hitting the Escape key (feature generously sponsored by Thomas Hines)
  • Better handling of JavaScript errors in desktop Player – now prints error messages in-line with the game output instead of pop-up windows
  • New Esperanto translation and updated Spanish translation, both contributed by Francisco Orta
  • New word-wrap option in the Code View
  • Reduced memory usage
  • More helpful error messages when the wrong number of parameters are passed to a function
  • Warn before exiting Quest if files are still downloading in the game browser, and added “Delete downloaded file” to context menu
  • and of course various bug fixes!

Please try out the beta and let me know what you think. Download Quest 5.2 Beta for Windows or try it in your web browser.

Many thanks to those who have contributed to this release – Pertex, James Gregory and Francisco Orta. If you’re interested in contributing, please take a look at the Developer page and Developer forum.

3 Improvements to Publishing Games

I’ve just finished three improvements to how games are published on

Publishing from the web version of Quest

You can now publish games from the web version of Quest. From your game list, you can use the “Publish” link that appears next to your game. From the Editor itself, select “game” and hit the “Publish” button that appears in the top right of the screen.

After publishing your game, you can carry on editing it. Changes will not appear publicly until you re-publish.

Publishing from the desktop version of Quest

The process for uploading a game has been improved. The first step is to upload your file – after that, the game name, description and category you’ve specified in the Editor will be automatically extracted, so there’s no need to enter this information again on the upload form.

Unlisted games

You can now publish a game without making it fully public – handy if you simply wanted to try out your game online, or maybe to share a game with just a few friends. Simply select “Unlisted”, and your game won’t appear when browsing the site – only people who know the link will be able to see it (so it works in a similar way to unlisted videos on YouTube).

When logged in, you can see your unlisted games by clicking onto your profile. You can edit your game details to toggle it between public and unlisted at any time, so this may be useful if you want to have a few people beta test your game before releasing it more widely

Combining this with the new “publish” feature in the web editor means that, whether you’re using Mac, Linux, Windows, iPad or Chromebook, you can go through the entire game-making process in your browser:

  • create a game from scratch and edit it
  • publish it as “unlisted” to get a few of your friends to beta test it
  • carry on working on the game, publishing updates when you’re ready
  • when you’re finished, switch it to public and share with the world.

So you can now throw away your desktop PC (presuming you weren’t using it for anything other than making text adventures).

A year of full-time Questing, Part 2 – the Appraisal

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:

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

The desktop editor design…

..can mirror the web-based 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#/ 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 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!

A year of full-time Questing – Part 1

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

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 domain to bring it together with the games at 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. 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”.