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 http://quest5.net 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 http://www.axeuk.com/quest/


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:

> TAKE SOFA
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?

Screenshot

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,
        System.Text.RegularExpressions.RegexOptions.IgnoreCase);

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.

Conclusion

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: http://quest.codeplex.com

Contributing

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: http://quest.codeplex.com

Documentation is on the wiki: http://quest5.net


Guathon - new .NET stuff and Windows Phone 7

15 August 2010

On Friday I went to Guathon, a free Microsoft conference all about the latest .NET stuff and Windows Phone 7, held at the Odeon cinema on Shaftesbury Avenue. I was lucky to get a place, as when registration opened last week, the website immediately buckled under the strain. It reminded me of trying to get tickets for Glastonbury - and you’d think Microsoft would be able to get this kind of thing right. But after a lot of refreshing, opening new tabs, and filling in the same registration form multiple times, I eventually got my confirmation email.

Arriving at the Odeon bleary-eyed yesterday morning, I knew I was in the right place when saw a long queue of poorly dressed men - I blended in seamlessly.

Presentations without boredom

[image by Jeff Sandquist]

Scott Guthrie is the man in charge of the .NET teams at Microsoft, and spent three quarters of the day doing presentations. It must have been pretty gruelling, but he didn’t show it - and he really knows his stuff, eschewing slides almost completely for a very hands-on style, mostly writing code in Visual Studio and answering questions as we went along. He’s a hugely effective presenter, and I just wish more people would learn that making a presentation isn’t all about knocking together slides in PowerPoint and then reading out each bullet point in a monotone.

The first session covered Visual Studio 2010 - a mix of new features, such as the improved IntelliSense, plus old features that surprisingly many people haven’t heard of, such as conditonal breakpoints. He also talked for a while about the new IntelliTrace debugging and automatic diagramming features which are sadly only available in the seriously expensive versions - a shame as it looks like these could be a real productivity boost for a lot of programmers. I’m still waiting to get my hands on VS2010 myself, as for some reason it’s taking Microsoft weeks and weeks to process my new Action Pack subscription.

By the end of the first session we were already overrunning massively, and everybody was in desperate need for some fresh air, a trip to the toilet and some coffee. If the Odeon had been prepared, they would have known that 250 developers logically entails a requirement for 250 lattes, but clearly this had been missed somehow as a huge queue quickly developed at the tiny coffee bar, with only one member of staff and the world’s slowest coffee machine.

ASP.NET MVC, 1, 2 and 3

Sessions two and four were all about ASP.NET MVC. This is a framework that sits on top of ASP.NET and provides a quite amazingly neat and elegant way of building web-based applications. I didn’t know anything about it before, but there was a good quick introduction before diving into the new stuff in versions 2 and 3, so I now feel like I’m up to speed and am quite keen to have a play with it - if only Microsoft would hurry up with letting me access the software I’ve ordered…

Instead of a load of slides, the presentation was entirely in Visual Studio, taking us from starting a new ASP.NET MVC project. “What kind of website shall we make?” asked Scott. “An event registration site” was the highly appropriate response, and Scott took us through creating the web application from scratch. He covered a huge amount of functionality in the way that makes the most sense to programmers - by actually writing code. Not only was it a great way of covering lots of material, the fact that he could cover so much during the sessions is testament to how well-designed the MVC framework is - it’s really very quick to start putting things together.

Windows Phone 7

To give Scott a bit of a break from presenting, between the two ASP.NET MVC sessions Mike Ormond stepped in to talk about developing applications for Microsoft’s forthcoming Windows Phone 7 platform. It was a mixture of slides and a more hands-on demonstration, as he demonstrated writing a simple game which he then showed working on both an emulator and an actual prototype phone.

The presentation was good but I was left feeling underwhelmed by the product itself. Despite the name, Microsoft has effectively thrown away its old phone platform to start again, so it’s very much a “1.0” product at the moment. Unfortunately they seem to have taken all the worst bits of the iPhone and then added in some extra limitations of their own. Like Apple, they will be controlling the “Marketplace” (equivalent of the App Store) so they won’t accept certain types of applications. Like Apple, you can’t do proper multi-tasking - the phone will quit applications when you switch to another one, and as a developer you have to manually write code for saving the application’s state. Even the process of using the camera within an application causes it to restart, which seems very cumbersome. And for the moment they’ve even locked down things such as access to the camera flash LED, meaning no flashlight applications are allowed. This just seems dumb.

One of the positive things to come from Apple’s control freakery is that at least mobile network operators can’t stuff the phone with crappy applications themselves, but there are no such limitations on Windows Phone 7. Network operators have more power than ordinary developers, as they will be able to create proper native applications instead of the Silverlight and XNA apps that other developers will be limited to.

They have also taken some decisions with the interface that they probably think of as “innovative”, but I would describe as “strange”. For example, instead of the iPhone’s single “home” button, there is a “back” button which will navigate back through your app, until you reach the first page when it will quit. But there’s also a “Start” button which takes you back to the app launcher. I can’t see the advantage of the additional hardware button here - the iPhone approach of having all app navigation in the touchscreen works perfectly well, so I wonder if Microsoft are forced to go this way to avoid stepping on one of Apple’s many patents.

I have doubts about the “panorama” interface, as shown in the picture above. It looks like this just makes a lot of the menus hard to find - it will be interesting to see how well this works on the devices when they appear later this year.

In summary, I find it hard to see Windows Phone 7 taking off. It would have been a great product five years ago, but Microsoft is clearly desperately chasing Apple and Android and is way behind. I like the idea of .NET on a mobile device - it would certainly make it easier for me to port my own existing applications to a mobile phone - but there’s nothing (yet) that makes it stand out in any area ahead of the competition, so any mobile app developer is going to have an extremely limited potential user base. It’s too little, too late.


All Posts