Note: this information is now out of date. Please see the updated article on the Quest 5 wiki

Quest 5.0 currently follows relatively similar principles to previous versions when it comes to processing player input. I say “currently” as this may change over the course of the technical previews and beta versions, and I say “relatively” as although based on the “old” system, there is a lot more flexibility and power in the new way of doing things. In a nutshell, we retain the concepts of verbs and commands.

Here is a simple command:

<command command="test">
  msg ("Hello")
</command>

This allows the user to type “test”, and in response prints “Hello”. So far, very similar to Quest 4.

Verbs let you add “doing” words, to let players interact with objects. For example:

<verb command="eat">You cannot eat that.</verb>

This would let the player type “eat crisps”, and provide a sensible response for when the player tries to eat other objects in the game.

Templates

Core.aslx defines the behaviour for standard verbs such as “look at”, “speak to” and so on, but the actual text for the verbs themselves comes from the language library (English.aslx). To have the behaviour in one place but the verb itself in another, we have templates, which look like this in English.aslx:

<template name="eat">eat</template>
<template name="cannot_eat">You cannot eat that.</template>

A French version might look like:

<template name="eat">mangez</template>
<template name="cannot_eat">Vous ne pouvez pas manger ça.</template>

We use square brackets in Core.aslx to dynamically replace text with the template. So Core.aslx might have a line like this to define the verb, which will behave in exactly the same way as the verb in the above example:

<verb command="[eat]">[cannot_eat]</verb>

As well as using square brackets, for <command> tags you can use command templates. These let you specify multiple ways of expressing the same command, which each resolve to the same template. For example, English.aslx might define an “inventory” command like this:

<commandtemplate name="inventory">i</commandtemplate>
<commandtemplate name="inventory">inv</commandtemplate>
<commandtemplate name="inventory">inventory</commandtemplate>

That way, “i”, “inv” and “inventory” all resolve to the same template “inventory”, and Core.aslx can define the behaviour of the command like this:

<command template="inventory"> ...

Matching objects in commands

For more complicated commands, such as “put apple on table”, you can match objects within a command. Quest 5 lets you use regular expressions for this:

<commandtemplate name="put"><![CDATA[
  put (?<object1>.*) (on|in) (?<object2>.*)
]]></commandtemplate>

This may look slightly frightening at first glance, but it’s pretty simple underneath the scary syntax. The “<![CDATA[” section is there because we need to use “<” and “>” characters for the named groups in the regular expression, but we will have an invalid XML file if we don’t use a CDATA section.

For any named group with a name starting with “object”, Quest tries to match it to an object in the current visible scope (e.g. the objects in the current room, plus the objects in the inventory – I’ll be discussing scopes in more detail in a future post). You can also have named groups starting with “exit” to match available exits.

When the script for the command runs, local variables “object1” and “object2” are set to the objects specified in the command, so you can access their properties directly using “object1.parent” etc.

It may be the case that this mechanism is refined as we go through the development process, as regular expressions are probably overkill. It might be nice to simplify the named group syntax so that you can write “put #object1# (on|in) #object2#” in a similar way to Quest 4.x.

Dynamic Templates

Templates are used for all the standard output from Core.aslx. This includes the standard error messages, such as “I don’t understand your command”.

A dynamic template is a template that can call functions and read properties. This is useful for dynamic responses such as when the player tries to take an untakeable object. Usually, a response of “You can’t take it” is sufficient, but what if the object is a female character? Dynamic templates to the rescue – they are essentially functions that return a string value, for example:

<dynamictemplate name="TakeUnsuccessful">
  "You can't take " + object.article + "."
</dynamictemplate>

A female character should have their “article” property set to “her”, so this will print “You can’t take her.”

To print this from a script, call the DynamicTemplate function, which takes two parameters:

msg (DynamicTemplate("TakeUnsuccessful", object))

Note: this information is now out of date. Please see the updated article on the Quest 5 wiki

Quest 5.0 uses a new XML-based file format, and files have an .aslx extension.

Here is a simple example:

<asl version="500">
  <include ref="English.aslx"/>
  <include ref="Core.aslx"/>

  <game name="Test ASLX Game"/>

  

    <exit name="east" to="hall"/>
  </object>

  

  

    <exit name="west" to="hall"/>
  </object>

</asl>

This example defines what in previous versions of Quest would have been three rooms – a lounge, a hall and a kitchen. In Quest 5.0 these are just objects, and they themselves contain the objects “sofa” and “sink”. By nesting <object> elements, you can define further objects inside objects.

Libraries

There are two libraries included in this example:

• Core.aslx provides the default Quest functionality, including: showing room descriptions, implementing default verbs such as “take”, “drop” and “use”, opening and closing containers, and deciding which objects are currently available to the player.
• English.aslx provides the English text for the built-in default responses, and the names of the verbs whose behaviour is defined in Core.aslx. This means Core.aslx is language-neutral – if you wanted to make a game in German or Spanish, just translate English.aslx and plug it in to your game.

Properties

Each object’s properties are defined in the XML. In previous versions of Quest, there were only two data types – “properties” were strings, and “actions” were scripts. To make things more confusing, the properties and actions for an object were separate from the tags specified in the ASL file, so you couldn’t always read all the information about an object from a script.

In Quest 5.0, everything has been unified into properties, and there are more data types available, with the XML “type” attribute used to specify the type. If no type is specified, the string type is assumed, as with the sink’s “look” property in the above example. An exception is if there is no data in the XML tag, in which case a boolean “true” is assumed instead – as in the “start” property for the lounge.

The available types are currently:

• string
• double
• int
• boolean
• script
• list (of strings)
• list (of objects)
• object
• exit
• null

The type of a property can determine the behaviour of an object. In the above example, the sofa’s “take” property is a script, so that will run when the player types “take sofa”. If the “take” property is a string, the object will be taken and the string will be printed. This behaviour is defined in Core.aslx.

Properties can change type while the game is running, by simply setting them to a new value.

Additional properties

When Quest loads the game, it will set the following additional properties on objects:

• name – string, from the “name” attribute specified for the <object> tag
• parent – reference to the containing object, or null if the object has no parent

The player object

The player is itself an object in Quest 5.0. Here, the lounge has the property “start”. Core.aslx defines the player object, and when the game starts it will move the player into the start room by setting the player’s “parent” property to the first object that has a “start” property set to “true”.

Quest 5.0 is under development, and is substantially improved from previous versions. Although it is still a long way from being released, I thought it would be a good idea to write a series of blog posts discussing how the new system works, and the new capabilities this will bring to the system.

Limitations of Quest 4.x

Quest has grown over the years, from the very limited and somewhat quirky Quest 1.0 back in 1998, to the much more powerful system that it is today. However, it is still based on those foundations laid over a decade ago, and this means that it would be hard to implement some frequently requested features without a fundamental rewrite. This is the reason for taking Quest “back to the drawing board” – Quest 5.0 is a brand new text adventure game system, but taking many cues from the current design of Quest.

Doing more with less

The main idea behind the new version of Quest is that most of its features should be implemented in Quest itself. This is a fundamental change from the way previous versions have worked – in Quest 4.x, there is code for handling the ASL (the Adventure Scripting Language, which is how games define their own logic), and there is also separate code for providing the default behaviour for games, such as what happens when a player takes an object, how to print room descriptions, etc.

By contrast, Quest 5.0 is designed to handle as little default game behaviour as possible. Instead, all this code is written in ASL itself, and defined in a core library. This means that as a game author, you can see exactly how the system works at quite a deep level – and more importantly, you can override this and specify your own behaviour instead.

Many concepts which were separate in previous versions have now been unified. For example, Quest 4.x has separate ideas about rooms and objects, and the player itself is something different again. In Quest 5.0, these are all just objects. An object can contain other objects, and they can contain objects themselves, and so on. So when the player enters a kitchen, the player object moves inside the kitchen object. The kitchen then contains the player, in exactly the same way that a fridge defined in the game might contain a bottle of milk.

Eating one’s own dog food

In writing the fundamental behaviour of Quest in ASL, I have had beef up the power of the language. By “eating my own dog food”, I have had to design ASL to handle many things that previous versions simply couldn’t cope with, with the result that it is now a much more powerful and capable language. Expressions are now fundamental to the way ASL works, for example, and there is built-in support for handling lists.

Technical Preview

I’m very excited by the potential of the new system, and I’m keen to release an early version as soon as possible so I can get your feedback. This will be a very rough “technical preview” version, with plenty of functionality missing – there will be no visual editor and no ability to load Quest 4.x games – though of course these will arrive later. I expect to release this preview version in the next month or two.

Stay tuned this blog for updates, and if you have any questions or ideas then please post to the new Quest 5.0 forum.

I thought I’d post here about the work that I’m currently doing on the next version of Quest – version 4.1.

So far the bulk of the work has been overhauling the internals of QDK (in programmer’s speak, “refactoring”). This is to enable me to more easily add new features in future versions, and also to enable me to more easily move the code from VB6 to the newer VB.net.

In fact QDK 4.1 is already using the Microsoft .net framework for some new interface elements – the toolbars have been overhauled with a more modern look, and there is a new rich editor for text, as you can see in the screen shot below. No more weird formatting codes – you now type in a room description just as you would in a word processor:

You can also see that the tree view now contains some of the editors that were previously pop-up windows accessed via the menus – the timers, object types, status variable editors etc.

Also there are new web-browser-style “Back” and “Forward” buttons, which should be useful if you’re editing a large game.

The rich editor also appears for the “Print a message” command in the Script Editor, which has been cleaned up a little:

Quest Pro 4.1 will also feature Quest Packager, which is an enhancement to the Quest Compiler. You will now be able to compile your game into a single setup EXE file, so you can give your game to other people, distribute it over the internet, and submit it to software download sites, without having to get your users to download Quest separately.

I’ll also be overhauling room exits for version 4.1, allowing you to easily create locked exits, and replacing the two tabs in the QDK room editor “Compass” and “Go to” with a single editor that will allow you to manage all exits for a room. I’ll post more details on this later, and I’ll create a thread in the Feature Requests forum to get your feedback on how this should work.

Hopefully a beta version will be ready in a couple of months time – I’ll post updates to this blog with details as we go along.