Monthly Archives: July 2011

Quest 5.0 Beta 4 released – approaching the final release

Quest 5.0 Beta 4 is out now, and we’re on the home straight – this beta is feature complete. I’m not planning to add any new features to version 5.0 – very minor ones may be still be added, but all the outstanding feature requests have been moved to a planned future version 5.1 release (they may be rescheduled again of course).

I will still accept contributions of new/updated translations and minor additions to the Core library – I know a few people may currently be working on these. The project is still hosted on CodePlex but recently switched from SVN to Mercurial hosting, which will make it much easier for people to work on their own forks and for me to manage contributions.

New in Beta 4: Some improvements to the parser, re-implementing features that existed in Quest 4.x but hadn’t yet found their way into 5.0:

  • you can now refer to objects in the previous command by article or gender, e.g. “it”. So you can type “look at box”, “take it”, “open it” etc. Multiple objects are handled via the usual disambiguation menu – so you can type “put book on shelf”, then “look at it” will let you choose between “book” and “shelf”.
  • if you make a mistake while typing an object name, you can now use “oops” to correct it. For example, “look at bok”, “oops book”. This can even handle multiple objects and a whole sequence of mistakes, so if you’re an especially poor typist you can end up with sequences like this:
> put bok on shulf
I can't see that. (bok)

> oops bik
I can't see that. (bik)

> oops book
I can't see that. (shulf)

> oops sholf
I can't see that. (sholf)

> oops shelf
You put the book on the shelf.

If you don’t like “oops” you can of course still press the up arrow to correct the previous command (or just type more carefully in the first place!). Even though it may not be an especially useful feature, I was pleased that I was able to implement it entirely with changes to the Core library – I think this shows how flexible Quest is, as you could implement your own entirely customised parser in a game if you wanted, and it would work without requiring any software updates.

There have also been some improvements to help with creating non-English games:

  • directions can now have default prefixes – there are three different sets, one for compass directions (N/S/E/W/NE/etc.), one for up/down and one for in/out. These are all blank for English games, but may be useful for other languages.
  • language templates can now add object types, for example for masculine and feminine inanimate objects.
  • when adding a verb, the language template can now define a default expression which can include object attributes. In previous betas this was a hard-coded string. Now, for English the default verb expression is:
"You can't #verb# " + object.article + "."

So if you add a verb “smash”, you get sensible default responses “You can’t smash it”, “You can’t smash them” etc.

Other new features in Beta 4:

  • Record a walkthrough while playing the game – on the walkthrough editor, click the “Record” button. Play your game and all steps will be recorded, which is great for testing. If you click “Record” on an existing walkthrough, it will play through and you can then append more steps.
  • Add external links to a game, so you can link back to your own website or email address.
  • There is a new “in” direction (which has meant a slight redesign of the compass rose).
  • You can now run scripts after taking, dropping, opening, closing, locking, unlocking, switching on, switching off an object, so you don’t need to override any built-in behaviour if you just want to play a sound, show a picture, release a herd of wildebeest or whatever in response to the player doing one of these “standard” things to an object.
  • Finally fixed a long-standing design flaw with verbs in Quest, in that it was easy to override and therefore break default functionality. I’ve lost count of the number of times people have asked for help because the “take” command had suddenly stopped working, and it was because they had added “take” as a custom verb instead of using the Inventory tab. The editor now prevents you from adding a verb to an object that would clash with an existing command, and gives you guidance on where you should go to put that script or message instead.

You can download the new version here:

Get those bug reports in! The next release will be a Release Candidate, probably in a couple of weeks. All being well, we should go “gold”/RTM around late August.

In the meantime I need to complete the documentation, one of my least favourite tasks!

Teaching with text adventures

The “retro” aspect of text adventure games is kind of fun, but I think it can also be limiting. I think there is a lot of potential for text adventure games to have a broader appeal, with wider uses, way beyond harking back to old-skool computer games. There is a place for text adventures on the modern web, but not simply “hey, remember those old games from the 1980’s? Some people are still making them!”

I am guilty of this kind of pigeon-holing myself of course. The current introduction on the Quest website says “Quest brings 1980’s-style text adventure games up to date” – well, fine, yes, maybe it does, but when I rewrite that introduction for Quest 5.0, I don’t want to frame it in those terms.

This is because I want to introduce this type of game to a new generation of authors and players, and these people may not even “remember” text adventure games in the first place. In fact, the most important people who I want to introduce to text adventures certainly won’t remember them – anybody at school today will have been born after 1993, a long time after text adventures ceased to have a mainstream appeal.

Using Quest in Education

There are educational uses for Quest, both in getting students to play text adventure games, and in getting them to write their own. There are probably ways of using Quest in any subject that touches on problem solving, reading, or creative writing:

  • Quest could be used as an introduction to programming – all the standard programming concepts are in there: variables, functions, expressions, objects, loops.
  • For teaching creative writing, Quest makes the author think of multiple points of view – the “reader” will be interacting with the game world.
  • Teaching foreign languages – getting students to play a game in a language that is not their mother tongue challenges them in both reading and writing, and it ensures comprehension, as they can’t progress in the game unless they can read and write sentences correctly.

To children, text adventures are not old-fashioned – they’ll likely have never played anything like them before, so it will be new to them. This could be a challenge, in that they’ll be unaware of the conventions around the kinds of things they can type – but I think that Quest’s hyperlink support can help them to get the idea quickly.

Current users

I am very keen to hear from any teachers who are either currently using Quest in the classroom, or who may be thinking about doing so.

In the last month or so I have heard from:

As well as secondary schools, I have also heard from a university professor considering creating a final year project using Quest. There should be applications at the younger end of the spectrum as well – simpler text adventure games for primary school pupils.

In fact I don’t see any reason why primary school pupils wouldn’t be able to create games as well. I may need to work on a “simple mode” for the Quest editor, but if I can introduce young children to programming, that will be a great thing. I myself started programming on an Acorn Electron using BBC BASIC at the age of 8, and it would be fantastic if Quest could be used to get today’s 8 year-olds into programming too.

Deployment and Assessment

Quest features the ability to distribute games over web, so players don’t need to install any software. You can either upload games to, or if you have a Windows server, you can install the Quest WebPlayer component. This means that it’s simple to deploy a game – whether you want students to play over a school network, or on their home computers, iPads etc., there’s no software to install on the end-user machine – all you need to do is give them a web link.

In the near future I want to look at enabling ways of integrating Quest with systems such as Moodle. The idea being that you could get students to play a game, and assess any aspect of the game session in the external e-Learning system – that could be simply whether or not they completed the game, or it could be any attribute such as the score, the number of rooms visited, or a full transcript of the game session. Unlike other “play online” systems (such as Parchment for Inform), Quest runs the game on the server, not the client – so it should be easier to implement such monitoring features by creating an API that can transmit details of the game session somewhere else.


I’m very keen for any feedback on this, as this is a new area for me. If you’re thinking about using Quest in the classroom, I’d love to hear from you – what are your ideas, and what can I do to help?

You can get in touch by leaving a comment here, emailing me at, or you can find me on Twitter at @alexwarren.

Quest 5.0 Beta 3 and Tutorial available

Quest 5.0 Beta 3 is now available for download.

The first draft of the Quest 5.0 Tutorial is also now available.

We are getting closer to the final 5.0 release now. The Issue Tracker currently only has a few relatively minor features assigned to a future Beta 4 release, so what we have now is close to the final version 5.0. Of course, version 5.0 is just the beginning – a rebirth for Quest, really – and I have lots of ideas for the versions that will come afterwards. But I think it is important now to get the new system stable and “out there”, so I don’t expect that there will be too many dramatic changes before the “gold” or “RTM” version 5.0.

New features in Beta 3:

  • Status Attributes – these are the equivalent of Status Variables in Quest 4, and let you display attributes (such as player health, money) in the pane on the right of the screen.
  • Multi-object commands – “take all” and “drop all” are now implemented by the Core library.
  • Ask/Tell – you can now give characters a list of subjects that the player can ask or tell them about.
  • Lockable containers – you can now assign a “key” object to a container which the player must have before they can unlock or open the container
  • Compass exit editor – more easily create exits between rooms, including automatically creating exits in the other direction. Hyperlinks in the exit editor allow you to navigate between rooms.
  • Play YouTube and Vimeo videos – now built-in to the Core library.
  • Switchable objects – easily implement objects which can be switched on and off.
  • Object Types can now extend string lists – this is used so that multiple types can contribute to the display verbs list. For example, if an object is both a container and switchable, the display verbs list shown when the player clicks its hyperlink will include “open”, “close” as well as “switch on”, “switch off”.
  • Player object is now shown in the editor – easier to set the start location, set up attributes, and set up the player’s initial inventory.
  • Editor now watches file for external changes – so you can more easily make edits using an external text editor while the file is still open in Quest.

This release also fixes all bugs which have been logged so far – 45 items since Beta 2, according to the Issue Tracker. Many thanks to everybody who has been logging bugs so far. Please keep them coming!

Download Quest 5.0 Beta 3

Eliminating "Guess the Verb"

Two classic problems of text adventure games:

  1. “Guess the Verb”. When you want to do something in the game, it should understand you, and if you’re trying to solve a puzzle, you shouldn’t also have to figure out the particular sentence formation that the game author was expecting you to use.
  2. Players who are new to text adventures often don’t know what kinds of things they can type in.
An old solution

To address these problems, Quest has always featured lists and a compass to the right of the game window. These show the objects in the player’s inventory, and objects and exits in the current room. The idea is that, to a large extent, the player can interact with the game using the mouse.

However, these have always been a little inflexible. Firstly, there was a hard-coded list of verbs (“Look at”, “Take”, “Speak to”) displayed on the buttons. Secondly, not everybody likes the look of the panes, but if you turn them off, you’ve removed a lot of the help that the player might get.

A new solution

Quest 5 introduces another approach – you can dispense with the lists entirely, and use hyperlinks.

When you click one of the links, you get a menu showing the display verbs for that object. Each object can have its own display verbs, tailored to the type of object.

Quest provides default display verbs for various object types. For example, characters such as Professor Dave:

Objects such as the desk:

Containers such as the box of pens:

Switchable objects, such as the fan:

You can also add custom verbs to the list. For example, here we’ve added “push” to the button:

Apart from the final example, all of the display verbs were set up automatically using the functionality built in to Quest’s Core library. When you mark an object as “Male character” for example, you get the relevant display verbs (“Look at”, “Speak to”) which are different to the display verbs you get for “Inanimate object” (“Look at”, “Take”). When you mark an object as being able to be switched on or off, you get “Switch on” and “Switch off” added to the display verbs list.

Any type can add to the list of display verbs. Quest supports multiple inheritance, and the resulting display verbs list can be extended by multiple types. This means that if an object is both a male character, a container and can be switched on/off, you will get the full list of display verbs that you would expect. Any future libraries can also easily add to the list.

From the Object tab, you can customise the display verbs list entirely – adding or removing the default verbs.


You can turn hyperlinks off by selecting “game” from the tree, then on the Options tab deselect the “Enable hyperlinks” options. But first consider why you would want to do this – if it’s because seeing a list of verbs spoils your puzzle, it probably means it’s not a very good puzzle.

Note that the display verbs is not the full list of verbs for an object, so you can easily support additional verbs for detail, without cluttering up the display list.

As with all Quest user interface features, the pop-up list works both on the desktop and via the web. So whichever way people play your game, they will get the same experience. I believe this feature will be especially important for web-based games, because if text adventures are to attract a new (and like it or not, more casual) audience, they have to be easy for people to start playing, and of course hyperlinks provide a very intuitive way to to get web users started.

(The hyperlink feature is available in the current Beta 2 release of Quest 5.0. “Display verbs depending on object type” is a new feature in Beta 3, which will be available soon – or you can download the latest source code from CodePlex)