New "Play Online" beta at

12 February 2011

I have rewritten the “Play Online” feature of

It is now running WebPlayer, which is the open source online player component of Quest 5.0.

Things to be aware of or excited about…

  • It is much faster than the old "play online" feature
  • It no longer uses Flash - instead it's using AJAX. This means that it works on iPhone and iPad etc. But note that the current layout is not very iPhone-friendly. Also it didn't work on the Android browser I tried for some reason.
  • It is free and open source, so if you wanted to host your own WebPlayer in your own design, you can.
  • It supports games for all Quest versions - both "classic" Quest (4.x and earlier) and "new" Quest (5.0).
  • It works properly - if it works in Quest, it should work in WebPlayer too. The old "play online" feature doesn't show embedded CAS resources for example - WebPlayer does.

To use the new WebPlayer, you must first log in to You will then see a “Try the new beta online player” under the usual “Play online” link. (There’s no technical reason for requiring a login, it’s just that I don’t want every casual player on the site hitting the new WebPlayer until I know it works properly).

Note that the very latest games added to won’t be available on WebPlayer yet, as I haven’t set up the service that grabs new game files on the new server.

Please, please, please give me your feedback and report any errors you see.

Quest 5.0 now runs all Quest games

15 January 2011

I’ve just updated the Quest 5.0 technical preview. This new version can play all games written for previous versions of Quest, right back to version 1.0.

Please download it and let me know if you see any error messages, or if anything behaves differently.

The code for running “legacy” ASL games is based on the code for Quest 4.1.4 - it has been converted from VB6 to VB.NET 2010, which is quite a jump, so it is highly likely that some things will need fixing. The code has been refactored to strip out all the old VB6 GUI code, to make a new LegacyASL component which implements Quest 5.0’s IASL interface. Doing this has meant adding support for pictures and sounds to the Quest 5.0 Player, so these features will be coming soon to Quest 5.0 ASLX games too.

One thing I’ve found is that the new .NET code is significantly faster than the old VB6 code. Commands seem to be processed quicker, and if you’ve ever tried to load a large game into Quest only for it to hang for several minutes, you’ll be pleased to hear that Quest 5.0 loads games pretty much instantly. One packaged CAS game which took about 10 minutes to load in Quest 4.1.4 on my machine takes a couple of seconds in Quest 5.0!

So please download the new Technical Preview version at and let me know if you encounter any problems.

Quest 5.0 playing a Quest 4.x game

Editor Preview

This new release has a preview of the Editor. It is currently very limited - so much so that I considered disabling it entirely for this release, but some people said they were interested in seeing how things were shaping up.

So, bear in mind that you can’t really do much with the Editor yet. What you can do is open an existing ASLX file (no support for creating a new game yet), and see the treeview of all elements in the game. If you click the “game” element, you can play with a limited preview of the Script Editor.

Some features that do work:

  • There is full support for undo and redo
  • The Script Editor lets you add and delete commands. I've refined the design from Quest 4.x - there are no pop-out windows at all, although you can click the "Pop out" button if it all gets a bit crowded. The "If" editor is a work in progress, so you will probably crash the application quite quickly if you start playing with it.
  • You can change the Filter at the bottom of the treeview to see elements that are loaded from libraries such as Core.aslx.

Quest 4 is now free

3 January 2011

With Quest 5.0 currently under development as free and open-source software, it doesn’t make much sense to continue trying to sell copies of Quest Pro 4.x. So I’m happy to announce that the new release, version 4.1.4 is now available and is completely free.

There is no longer a separate Quest Pro product. Instead, all of the benefits of that edition have been folded into the free version. So, Quest 4.1.4 is now free and includes:

  • an unrestricted version of the editor, QDK - you can now make games as big as you like
  • the Quest Compiler, which lets you encrypt your ASL file so players can't edit your game
  • the Quest Packager, which lets you turn your game into a stand-alone Setup EXE file for Windows machines

There have also been a handful of bug fixes, both from this version and from version 4.1.3, which was only quietly announced on the forums:

  • CAS resources: Fixed bug where subsequent calls to get an embedded picture or sound would fail. Also the performance of extracting resources has been improved.
  • In games written for Quest 3.1 and earlier, object "look" scripts would not run.
  • In QDK, when changing the game default font size, editing existing text would result in it being saved at the old font size. Also when editing text containing bold, italic and underline tags, formatting information could be lost.
  • Deleting a verb from an object didn't work.

You can download Quest 4.1.4 from

How to fix a bug in Quest 5.0

19 November 2010

Recently a bug was added to the Issue Tracker which sounded like a great one for somebody new to the project to dive into. The issue was that commands with upper-case characters didn’t work - you could type “take box” but not “TAKE BOX”. Unfortunately, nobody took the opportunity to fix it, so I’ve fixed it myself. But I thought it would be a good idea to take you through the process from the beginning, so you can see exactly what’s going on here. Hopefully by documenting this it will make it easier to join in with the project if you’re interested, as I realise all that code can be a bit daunting at first.

This blog post will give you an overview of how Quest 5.0 processes user commands, without prior knowledge of how the system works - I’ll try and guide you through the system assuming you’ve never seen the code before.

For this tutorial I’ll assume you have Visual Studio 2010 installed, and that you’ve checked out the Quest 5.0 source code on CodePlex. You should also read the Introduction for Developers - although the Technical Overview may make more sense after reading this tutorial, so don’t be put off just yet!

Note that I have not yet checked in my fix for the bug, so you can still see the bug in action and follow the steps below to fix it on your own machine. Update: The fix for this was checked in on 4th December 2010, so if you want to follow these instructions yourself, update to an earlier revision in SVN.

Reproducing the problem in the debugger

Fire up Visual Studio and open the solution file. Make sure that the “Quest” project is set as the StartUp project, then Run.

We could easily reproduce this issue in any game, and the SVN repository contains example ASLX game files under WorldModelWorldModelExamples-Public. To debug this I chose test.aslx.

Using this game, I did a bit of experimentation with a few different ways of writing the same command, and got this output:

I don't understand your command.

> Take sofa
I don't understand your command.

> take SOFA
You can't take it.

> take sofa
You can't take it.

This is interesting - it looks like Quest correctly handles different capitalisation for object names (it handled both “SOFA” and “sofa” in the final two commands, without telling us that it couldn’t see an object of that name), but it seems to be having trouble with “TAKE” vs “take”. So the problem is with capital letters in the first part of the command, rather than the object name.

What happens when we type a command

So, which part of the code handles commands? Let me take you on a tour…

First, we’re typing commands into a textbox at the bottom of the Quest window, but where does that textbox live in the code?


The Quest project has a form called Main.vb that contains everything - not just the game playing interface, but the game editor, and the game launcher that you see when you first start Quest. But it’s quite a thin wrapper - each of these components is implemented as a user control. The game playing interface is ctlPlayer, which is an instance of Player.vb in the Player project.

Go to Player.vb and you’ll see this contains:

  • a WebBrowser control, used for the game output
  • a Label control at the top, used to display the current location
  • two ElementList controls, defined in the same project. These are used for the "Inventory" and "Places and Objects" lists on the right of the screen.
  • a Compass control, also defined in the same project.
  • aha! A TextBox and Button, which is where we're typing in our commands.

So we now know where the chain of execution begins.

Passing the command from the GUI into the game

If you look at the code behind the button (cmdGo_Click), you’ll see it simply calls the EnterText sub, which in turn calls RunCommand, which calls m_game.SendCommand(). The same thing gets called when you hit the Enter key inside the textbox (although it happens via a timer so that the KeyDown event code finishes before we send the command).

m_game is an instance of an object which implements the IASL interface. The idea of the interface is that, in future, we may well want to hook up different “engines” to the same Player interface. This would let the same Quest front-end handle games for potentially different systems entirely, or more likely just different versions of the Quest engine. So we never directly link the Player front-end to the WorldModel project, which in this case is the engine driving test.aslx - we only ever talk to it through the IASL interface.

The IASL interface is defined in the IASL project, and it defines a few methods and events but the really important ones are:

  • SendCommand(string) which is how we pass a command into the game
  • PrintText event which is how the game tells the GUI what text should be printed

So let’s see what happens next. The WorldModel project has WorldModel.cs, which is our implementation of the IASL interface for Quest 5.0 games. If we go here and navigate to SendCommand, we can see that we print the command back, so the user knows what they just typed, and then we call RunProcedure and pass in various arguments.

RunProcedure("HandleCommand", new Parameters("command", command), false);

What’s happening here is that instead of using C# code to handle the command, we’re actually going into the ASLX file. WorldModel expects the ASLX file to provide a “HandleCommand” function, which will do all the work of processing what the user typed in. This is part of the design philosophy behind Quest 5.0 - a game author or Quest library author could define their own command parsing logic, or enhance the default logic, without having to make any changes to the Quest code itself.

So what we have here seems to be a bug in the Core library, in the HandleCommand function which is written in ASL, rather than a bug in the C# code.

Handling the command in the Core library

The default “HandleCommand” function appears in all ASLX games via Core.aslx, which is included in test.aslx (and probably will be in every Quest game) via the include tag:

<include ref="Core.aslx"/>

You can find Core.aslx under the Core folder in the WorldModel project. You’ll see that it includes various other files, as a way of splitting up the file into more manageable parts. You can use Visual Studio’s very handy “Find in Files” feature (Ctrl+Shift+F) to find where HandleCommand is defined - it’s in CoreParser.aslx.

The ASL should be fairly easy to read as it’s not too dissimilar to C#. All its script commands and functions are documented on the Quest wiki.

Let me talk you through how the function works. The parameter “command” is populated with what the player typed in, such as “take sofa”, and the first thing that happens is this:

candidates = NewObjectList()
foreach (cmd, ScopeCommands()) {
  if (IsRegexMatch(cmd.pattern, command)) {
    list add (candidates, cmd)

All commands in Quest are objects, and they can either apply to the whole game or a specific room. In the snippet above, we find out what commands are available by calling ScopeCommands() - this will give us back a list of command objects (the function itself is defined in CoreParser.aslx, so take a look if you’re interested).

Each command object has a property called “pattern”, which defines a regular expression that the input must match to trigger the command. We loop through all available commands, see if the pattern matches our input, and then we have a list of candidates.

The rest of the function determines which candidate is the strongest match for the input. Then it populates variables and runs the command’s script.

The command objects themselves are all defined in CoreCommands.aslx, and the “take” command is right at the top. The command object specifies the pattern regex that must be matched to trigger the command:

<command name="take" pattern="[take]">

In this case the pattern is in square brackets. Anything in square brackets gets taken from the template. In this case the templates are defined in English.aslx, and if we search for “take” in this file we find three verb templates that match:

<verbtemplate name="take">take</verbtemplate>
<verbtemplate name="take">get</verbtemplate>
<verbtemplate name="take">pick up</verbtemplate>

Verb templates are a special kind of syntactic sugar to save us the hassle of repeatedly typing very similar (and very ugly) regular expressions. If you run the game and click the Tools menu, then Debugger, you’ll see what the effect is. Click the Commands tab and look at the “take” object.

Debugger screenshot

You’ll see that via the magic of these three verb templates, the “pattern” property of our “take” object becomes:

^take (?<object>.*)$|^get (?<object>.*)$|^pick up (?<object>.*)$

Now we see why both “take SOFA” and “take sofa” work - they both match this regular expression, with the named “object” group being “SOFA” or “sofa” respectively. But a command like “TAKE SOFA” will not be matched, as the regular expression expects the word “take” to be in lower case. This means that when we type “TAKE” in capitals, the “take” command won’t even be added to the “candidates” list in the ASL snippet above, hence the command fails.

How best to fix this?

The problem is with this line in the CoreParser.aslx snippet above:

if (IsRegexMatch(cmd.pattern, command)) {

We want to perform a case-insensitive comparison, so we have a couple of options:

  • lower-case the "command" string before passing in to the IsRegexMatch function
  • update the IsRegexMatch function to perform a case-insensitive comparison

The first option is quickest, and would be a simple matter of updating the line like this:

if (IsRegexMatch(cmd.pattern, LCase(command))) {

However, I can see two problems with this:

  • it requires all command patterns to be defined in lower-case
  • it might not work in all languages

This question on StackOverflow leads me to think that updating the IsRegexMatch function would be the best approach.

The IsRegexMatch function is defined in QuestFunctions.cs - so in fact we need to do a C# code change after all, and leave Core.aslx as it is!

[Update: This fix was checked in as part of other work which has moved the code that was in QuestFunctions.cs to a new file ExpressionOwner.cs]

Designing the fix

Here is the offending line in IsRegexMatch:

System.Text.RegularExpressions.Regex regex =
    new System.Text.RegularExpressions.Regex(regexPattern);

which we need to update to

System.Text.RegularExpressions.Regex regex =
    new System.Text.RegularExpressions.Regex(regexPattern,

Bear in mind this will affect all usages of the IsRegexMatch function - but a quick search through the code reveals that it’s only used in one place, and that is the HandleCommand function we’ve been looking at. So I think this is a safe code change to make for now, and it’s a reasonably safe assumption that anybody who wants to call this function in Quest is probably using it for command processing and therefore probably wants to do a case-insensitive search as well. But in the future it may be worth making an overload of this function so that we can specify a boolean to make it explicit whether we want a case-sensitive comparison or not. I won’t add this now as I don’t think there is much point in adding superfluous functions that may not be needed - it will be simple enough to add this later if anyone requires it.


So there we have it - a simple one-line change for a simple problem. It took quite a lot of explanation to get here, but hopefully now you have a feel for how things hang together. There is a lot more detail we could go into - just how does that ASL script get run, you may be wondering - and maybe I’ll cover these another time. But now you have an overview of how it works, the best thing may be to step through the code yourself and see exactly what’s happening at each level.

As I said above I have not yet checked in my fix for this, so for now you can still see the bug in action and step through the code yourself using the tutorial above. Update: You can still step through this code if you update to a revision prior to 4th December 2010, or you could still step through the current version - just bear in mind that the fixed code now appears in ExpressionOwner.cs.

I’m happy to answer any questions you may have, so please feel free to add comments to this blog or ask for help in the forum. If there is an entire area of the system that you feel needs some more explanation, please let me know and I’ll write another blog post to give you an overview.

Quest 5.0 is now open source

18 October 2010

I believe Quest 5.0 has the potential to be a great system. I’ve put a lot of thought into the design and I think it’s shaping up to be a far more powerful, robust and flexible system than its predecessor.

But while it’s nice to have software that is good on a technical level, it doesn’t mean very much if it doesn’t have very many users.

The previous approach

Quest 4.x is sold on a “try before you buy” model, at least for people who want to create games. If you only want to play games, there is no need to pay - just download Quest and away you go. If you want to create your own games though, that costs money. Earlier versions had a 30-day trial of QDK, the game editor, although in v4.0 that restriction was removed in favour of a cut-down “lite” version that lets you create smallish games. So in the current system, if you want to create a bigger game, you have to pay.

While this approach is not entirely unsuccessful, I think it puts many people off. Even if they may never create a big game with Quest, the mere possibility that they might have to pay at some point probably puts some people off from even making a small game. So they go and take a look at other systems, even if they may have found that they would prefer Quest’s approach if they’d just given it a chance. Who knows, maybe the other systems don’t work out for them, and they abandon the idea of making a text adventure entirely?

Making it free

This wouldn’t bother me too much if the user base for Quest was huge anyway. But writing your own text adventure games is a niche hobby, and there are a number of excellent free alternatives to Quest, most notably Inform.

So, I’ve decided to unleash Quest from the shackles of directly trying to make money from its users. I would be so much happier to have created a free system with a large number of users, than to be in charge of a system with a small following that brings in only a small fraction of my overall income.

Becoming more open

Quest 5.0 was already designed with the idea of making its innards more open. Whereas previous versions hard-coded a lot of the standard game logic, in Quest 5.0 much more of the system is written using ASLX, the same format that the games themselves are written in.

Making Quest 5.0 fully open-source seems a logical progression, tying in nicely with both the free-of-charge aspect, and in making the system more open and customisable.

So, I’m pleased to announce that Quest 5.0 is now free open source software.

It is released under the Microsoft Public License (Ms-PL), which is similar to the MIT License. This means you are free to use the source code, even in commercial closed-source projects.

You can find the Quest 5.0 project at CodePlex:


I’m not expecting an overnight miracle, but in the longer term I hope that by being open source, people will join in with this project - the aim of which is to create a powerful, robust and flexible platform for the future of text adventure games/interactive fiction, which people can write games for easily, without having to know how to program.

So I’m looking for people to join in with me - we need C# and VB.NET developers, and also people to contribute to the Core.aslx library, which is written in Quest itself. We also need people to translate Quest into other languages.

If you think you can help, please join up on the CodePlex page. I’ve also added a page of Developer Guidelines to the wiki.

The beginning

I’m really excited about the new direction for Quest. I’ve not run an open source project before, so please don’t be afraid of joining in if this is new to you too. I believe that together we can achieve more, and turn Quest 5.0 into a totally awesome system. All questions and feedback are much appreciated!

Get the code from CodePlex:

Documentation is on the wiki:

All Posts