Monthly Archives: November 2006


Quest 4.0 Beta 2 has just been released, and this adds support for containers and surfaces. These are objects that you can put other objects in, or on top of. You can use these to implement things like bags, boxes, tables and shelves in your game.

To set up an object as a container, select the object in QDK and click the Container tab. Here you can:

  • choose whether the object is a container or a surface
  • choose what happens when the player interacts with it (by opening or closing it, or adding or removing objects to/from it)
  • tell Quest how it should list the contents of the object

By default, containers are closed, and so objects inside them won’t be revealed when the player looks at the object. Surfaces on the other hand are always open, so you can always see what’s on them. To make a container open when the game starts, just tick the “Initially opened” box.

If your container is transparent, however, the player will be able to see which objects are inside it, even when it’s closed.


To set which objects are inside a container, set their “parent” property from the Setup tab. For example, if you’ve created an object called “table” which is a surface, you can make a newspaper object be on the table by setting the newspaper’s parent to “table”.

Looking at a container reveals what’s inside it

If you set up a bag object as an open container, and set up a purse inside the bag, when the player enters the room they will only see the bag. Once they have looked at the bag, they will see the purse there. Subsequently when they enter the room, Quest will tell them that they can see both the bag and the purse.

Listing the contents

By default, when a player looks at a container or surface, its contents are listed. In the bag and purse example above, when the player looks at the bag they will see the bag’s description followed by “It contains a purse”. You can change this behaviour from the Container tab by editing list verbs. These allow you to specify if and how contents are listed. You can also specify what happens when the object is empty or closed – by default, Quest will print the description and nothing else, but you can make it add “It is closed” if you wish.

Opening and closing

By default, a closed container can’t be opened or closed by the player. To enable this, click the open and close verbs and specify the option you want. You can either have the object open and close automatically, or you can run some script when the player tries to open or close the object – use this if it is locked, for example.

Putting things and removing things

By default, a player can’t put anything on or in a container, or remove anything from it. To allow this, use the add and remove verbs. If the player can only put some kinds of object in or on this container, use a script to check what object they’re adding (it will be in the variable).

Default responses

Click Tools and then Standard Messages to modify Quest’s default responses when dealing with objects.


I’m very keen to hear any feedback you may have about the implementation of containers. Do they work as you expect? Do you find it easy to use them to do what you want to do? Please email me at with any suggestions, comments or bug reports.

AutoSave in QDK 4.0

QDK 4.0 includes a new feature called AutoSave, which will automatically create a backup copies of your game.

To configure AutoSave, click Tools, Options and then click the AutoSave tab.

By default, a backup copy will be saved every 10 minutes, and QDK will keep the last three backups. This means you can easily go back to a previous version of your game if you realise you have made a mistake.

With QDK currently being in Beta, you may find that you experience the occasional crash. Of course, you should let me know about these, but if you turn on AutoSave you can easily recover your work. In fact while using the Beta, you might want to change the setting so it saves every?minute, and keep the last, say, 10 copies of your ASL file.

If you’ve not signed up for the beta yet, there’s still time to do so – just send an email to If you’ve already applied but don’t seem to have had a reply, please check your spam filter or send me another email.

More advanced ways with verbs

I wrote the other day about verbs, and how they provide you with a much easier way of creating commands in Quest 4.0. I thought I would tell you a little bit more about how they work.

How an object’s verbs are stored

Basically verbs provide an easier way of doing what can be done in Quest 3.x with code like this:

command <eat #@object> {
    if action <#object#; eat> then doaction <#object#; eat>
    else {
        if property <#object#; eat> then msg <#(object):eat#>
        else msg <You can't eat that>

You will notice if you add an “eat” verb to an object in QDK 4.0 and then specify a script, that script will be stored as the object’s “eat” action. This means you can call it or check for its existence elsewhere within your game script in the same way as you call or check for an action. Similarly, if you specify the “Print a message” option for your object’s verb in QDK, the message gets stored as a property of that object.

The default script

In the verb definition (i.e. under “Verbs” on the tree in QDK, or as a “verb” tag in ASL), the script specified is the default script, i.e. it runs if the object the player refers to does not have that verb defined. QDK defaults to a message saying “You can’t eat that” (or whatever the verb is), but you can of course customise this to whatever you want.

If you want to always run a particular script, whether or not the object has that verb defined, you should use good old-fashioned commands instead of verbs.


One final tip: you can specify synonyms of your verb by listing them within the verb definition, separating them with semicolons. For example “eat; consume; munch”. Quest will only look in the object for the first property or action specified, so in this example, whether the player types “eat apple”, “consume apple” or “munch apple”, Quest will only look for the “eat” action or property. If you want to use a differently named action or property instead of the first one in a list, add it at the end after a colon. For example “eat; consume; munch :eatproc” will make Quest look for an “eatproc” action or property instead.

Verbs – an easier way to add commands in Quest 4.0

A couple of days ago I released the first beta of Quest 4.0. One of the new features of this version is verbs, which gives you an easier way of setting up certain commands.

Previously, in Quest 3.53, if you wanted to add an “eat” command to a game, you would have to add the command (and get your head round the concept of variables and using the #@…# syntax) and then add some logic to check for an “eat” property or whatever.

The new verbs feature in Quest 4.0 does all of this for you, and is especially useful if you edit games in QDK. Behind the scenes, verbs automatically add the kind of functionality you would have coded yourself using the old approach – in the “eat” example, once you’ve set up an “eat” verb, when the player types “eat apple” Quest will check the apple object for an “eat” property or action and display or run the script as appropriate.

QDK lets you add a verb directly from the object editor, so you don’t even need to set the verb up separately. Just click “Add” underneath the Verbs list, type “eat”, and then enter the relevant description or script. It really is that simple, and Quest handles the rest – the player will see a sensible response if they try to eat any other objects, and of course it will take care of alternative object names, typing “look at apple” followed by “eat it”, etc.

Hopefully this will make it a lot easier for you to add deeper levels of interactivity to your games. Please let me know if you have any feedback – and if you’re not already on the beta testers list, just drop me an email and I’ll send you instructions for downloading it so you can try out verbs (and the other new features) for yourself.