Monthly Archives: February 2013

Quest 5.4 Beta is out now

Quest 5.4 is now in beta. You can download the Windows version from the Quest download pageThe web version will be ready within the next few days. Update 5th March: Quest 5.4 is also now live on the web version too!

Here’s a quick overview of what’s new:

  • the new text processor makes it much easier to create dynamic text and links
  • gamebooks can now use scripts
  • the script editor now has a code view
  • menus are now shown within the game text
  • object and exit hyperlinks activate and deactivate according to what’s in the current visible scope
  • list and dictionary attribute types can now hold any type of attribute value, so you can now create lists of lists, dictionaries of dictionaries, and all kinds of combinations
  • there’s a simpler syntax for calling JavaScript within your ASL – instead of using the RunScript request, you can now use a more natural-looking syntax with “JS.” followed by your function call. For example, JS.alert(“Hello world”)
  • new Portuguese (Brazilian) translation, contributed by Ramon Dellaqia
  • new Romanian translation, contributed by Catalin Catz
  • option to speak all text via SAPI
  • when adding a duplicate object name, instead of giving you an error message, a unique object name is generated and the name you entered is used as its alias – so it’s now easier to add multiple objects that appear to have the same name.

If you’re using libraries created for Quest 5.3 and earlier, please note that some XML attribute names have changed – please see the Upgrade Notes on the wiki for details. (Game files loaded in the editor will be automatically upgraded to use the new 5.4 attribute names when they are saved, so this shouldn’t cause a problem if you’re only using the standard libraries.)

Please try out the new version and let me know if anything breaks!

Slicker hyperlinks in Quest 5.4

Hyperlinks were introduced in Quest 5.0, and I think they’re a great way of navigating a text adventure game – without using any additional UI elements, you can always see what objects you can interact with, and you only see a relevant list of actions for each object.

In Quest 5.4, I have made hyperlinks a bit smarter. Previously, once a hyperlink for an object was displayed, it would remain on screen. So, if Quest told you that you could see “a book“, that book link would remain selectable even if you moved somewhere else, set fire to it, etc.

Furthermore, once a hyperlink was displayed, it would always show the same list of verbs. In the book example, the verbs might be the standard set of “Look at” and “Take”. But if you picked up the book, the hyperlink would still show you that same set of verbs – even though a more relevant verb set may now be “Read” and “Drop”.

Quest 5.4 features what I call live hyperlinks. Now, as you move through the game, all hyperlinks activate or deactivating according to what the player can see. Also, clicking a hyperlink now always gives you the current verbs list for the object, even if you select an “old” link.

Let’s see it in action. Here’s a room with a newspaper that the player can pick up, as well as some other objects:

Object links 1

Now if the player takes the newspaper and moves east, the other hyperlinks are deactivated. The player can still click the “old” newspaper link though, and interact with it using the current set of inventory verbs:

Object links 2

Notice also that the exit hyperlinks “east” and “west” are also activated or deactivated according to whether they’re available.

I have also improved how menus are displayed. Quest has a “disambiguation” menu which appears whenever the player isn’t specific enough about which object they’re referring to – for example, if the player abbreviates an object name, and there are multiple objects that start with the same letters.

Previously, this disambiguation menu was a modal pop-up. Now, I think modal pop-ups are ugly and they don’t work very well on smartphones. They also stop the player from scrolling back through the game text – they are forced to choose from the menu before they can continue.

So, in Quest 5.4 I have changed menus so they are shown in-line with the rest of the game text. Like this:

New menu

The player can now click the link or type “1” or “2” to make a selection. The menu uses a simple jQuery animation to slide away, and the game continues.

New menu 2

Alternatively, the player could just do something else – if they type another command or interact with a different object, the menu slides away and the game continues.

Bringing more power to gamebook mode in Quest 5.4

Quest started out as a text adventure system. Many people call text adventures “interactive fiction”, but to me this is a fairly broad term, encompassing kinds of games that are not text adventures in the traditional sense. The “Choose Your Own Adventure” books are also a type of interactive fiction, but they are not text adventures – to me, anyway.

Systems like Twine and Inkle are starting to become more popular, bringing interactive fiction to a wider audience. These games follow the “Choose Your Own Adventure” model of branching narratives, so they are “interactive fiction” but not “text adventures” by my definition, as there is no simulation of the objects in the game world in the background. However, some people do refer to these games as text adventures, so it seems pretty hard to pin down the terminology.

It was the rising popularity of Twine, Inkle etc., which inspired me about a year ago to add gamebook mode to Quest 5.2. My vision is for Quest to be a platform for all kinds of interactive fiction – whether that’s the rich world model of a text adventure, or the simpler multiple choice of the CYOA style gamebook. And, indeed, why shouldn’t one game be able to combine the two approaches?

The initial implementation of gamebook mode was really simple – multiple choice games were all it could handle. You could create pages, with links between the pages. That was it – nothing dynamically generated, no scripts, no game state of any kind except the page the player is currently on. This is fine if you want to create pure CYOA, but it’s a bit limiting if you want to do anything more complicated, like emulate dice rolls within a game, or make small changes to a page’s text depending on the path the player has taken to get there.

But it was fine for an initial attempt, to see if people would even use gamebook mode in the first place. Happily, they are – which makes sense, as it’s a much simpler way to flesh out a quick interactive story than creating the world for a text adventure.

So, in Quest 5.4, I have made a number of improvements to the capabilities of gamebook mode. These have actually been pretty straightforward to implement, as gamebook mode always sat on top of the same platform as the text adventure mode – it was still using Quest’s scripting engine underneath. The changes I have made simply expose some more of that power.

Gamebook Scripts

There is a new page type, “Script”. When the player visits a script page, the script runs. The script can do anything – it may dynamically print out some text with some hyperlinks, or it might just send the player immediately to another text page, chosen according to some condition.

It can also run a “get input” command to get the player to type something, then maybe store that in an attribute, or send the player to a page based on what they typed in.

The Script Editor is the same as in text adventure mode, although the commands that can be added are slightly different. Many text adventure script commands relate to objects, and these are not relevant in gamebook mode and so are not displayed. This means that the Script Editor is a bit simpler in gamebook mode, though it still has access to “if”, calling functions, running JavaScript and so on.

Text Processor

The new Text Processor I described in an earlier blog post is also available in gamebook mode. A similar set of codes is available, so you can conditionally print text even without using a script page.

For example, you can take advantage of the fact that pages have attributes like “visited”, to write some text only if the user has visited a particular page. If you have a page called “cake” which the player may visit if they choose to eat a cake, you could write this on a later page:

Your mother stares at you. {if cake.visited:”You have chocolate all over your face,” she says.}

You can also include links to other pages directly within the page text (instead of having them underneath), and it’s also finally easy to add images wherever you want them in the text using the {img} code.


This release brings gamebook mode closer to text adventure mode, by opening up a lot of functionality to both. Now in gamebook mode, things can happen “behind the scenes” with richer state tracking, instead of the game being forced to have a pure branching structure.

For a future release I would like to further bring the two together, with the ability to add gamebook pages to a text adventure game. This will be useful for conversation trees for example, or maybe you just want to have a game that features both kinds of interaction in different sections. You could do this already to some extent – in the text adventure mode you can add custom commands, custom hyperlinks, and turn the command bar on and off as required, but it’s my job to make it easy for you to create the kinds of interactive fiction you want to write. So please do let me know what you’re up to with Quest and how I can help you!

I’ve only got a few more things to do before the beta version of Quest 5.4 is ready, so this should be available for you to play with in the next few days. Or as always, the nightly build is available for the brave and impatient.

Quest 5.4 Text Processor – easier adaptive text and links

It is very easy to generate and manipulate text with software, which is why text adventures were some of the very first computer games ever to be created. Furthermore, the manipulation of words can make it easier for a text-based game to feel as if it is genuinely responding to the player’s actions – it is far simpler for software to tweak a paragraph of text than it is to tweak a graphical environment.

As the player interacts with a game, they can of course make choices which affect the outcome of the story – choosing which branch of a narrative to follow – but it is also possible to construct a game where the player is not so much directing the action as simply telling the game a bit more about themselves. An interactive game doesn’t necessarily mean that the player decides on the outcome – the effects could be more subtle than that. A character may say slightly different things to the player depending on what happened earlier in the game, for example, but this may not have any effect on anything else that happens.

So, it’s important for a text game engine to make it easy to generate adaptive text. Quest does a lot of this already without an author having to do anything – it will automatically generate a list of objects that are in the current room, for example. But anything more advanced than that generally has required the use of scripts. If you want to show a particular sentence only if the player has performed some action, you have to run an “if” script to print that sentence. The sentence will stand on its own, with a line break before and after, so this is more of a mechanism for complete paragraphs than it is for minor details within text.

It’s also harder than it should be to display object hyperlinks. These hyperlinks are a key way that players interact with games, and get displayed automatically as part of the room description, but it’s hard to easily “linkify” an object that you make a passing reference to in a paragraph. That’s because you have to be running a script again, and use the ObjectLink function in an expression.

Quest 5.4 addresses these issues with a new feature, the text processor. This is a core library function, so it’s implemented entirely in Quest’s own ASL programming language, and it steps in at the last moment, just before text is written to the screen. This means you can include text processor codes anywhere in your game – you can use the codes inside a “print message” script command, but you can also use them inside a plain-text object description. This makes it much easier to have dynamically generated text without having to create a script.

For example, here’s how we might write a description of a hungry mouse:

Text Processor - editing

We’re just using a text description here, not a script. The editor provides some helpful buttons so we don’t have to remember the available codes, and we can also easily add object links by clicking the “Object link” button – we can choose an object from the list that appears.

When we run the game, here’s what we see. The “Aaargh, a mouse!” text only appears the first time:

Text Processor - output

We can easily include conditional text using the {if} code, which allows us to check the value of game or object attributes. For example, if we’re looking at an apple and the player’s health is low, we might write:

That looks like a tasty apple. {if<10:It would be a very good idea to eat it.}

Using the {command} code, we could actually improve this and give the player an “eat apple” link. You can nest codes inside each other, so the link will only appear if the player’s health is low:

That looks like a tasty apple. {if<10:It would be a very good idea to {command:eat apple:eat it}.}

There is also the {random} code which allows you to choose text at random, and {img} lets you include images in-line with text.

The Quest 5.4 Beta release is very close now, but if you just can’t wait you can try out the nightly build.

Quest 5.4 Script Editor – showing you teh codez

Scripts are everywhere in Quest. Want to play a sound when the user looks at an object? Choose “Run script” and then you can. Want to let the player pick up an object only if they are already carrying another? Choose “Run script” and you can.

Quest’s script editor is easy to use even if you’ve done no programming before, because you can simply choose from a categorised list of commands. In Quest 5.4, this has been enhanced so that commonly used script commands are quickly available using buttons at the top.

Script Adder

As before, after choosing a command, it appears in the script editor, where depending on the command you chose, you can fill in text, choose the image, etc.

Editing a script

More complex script commands have more things to choose from, and may themselves have places where you can add more script commands inside – as with the “if” command:

Editing a more complex script

This design works well for short scripts, but can become cumbersome if you’re trying to code anything more complicated.

The Quest 5 editor has always offered a “Code View” of an entire project, but once your game gets large, it can be a pain to switch back and forth – once you’re in Code View, you no longer have the tree view of your game’s objects, and the editor has to reload your entire game if you make changes and want to switch back to the normal editor. Also, Code View is only currently available in the Windows desktop version – it is not yet available in the web version.

Code view for a whole project

These limitations are addressed by a new feature coming to Quest 5.4, in both Windows and web versions – Script Editor Code View.

This lets you easily toggle between the friendly English language user interface, and the underlying code. The new button is highlighted below, and appears if you have Simple Mode switched off.

Code View button

This is the effect of turning on Code View for the whole script:

Script Editor Code View - whole script

You can also turn on Code View just for any nested script section:

Script Editor Code View - nested script section

You can make changes in the Code View without having to reload the entire game.

Making changes in Code View

If you switch back to the English language UI, your changes are immediately reflected in the friendlier version.

Making changes in Code View

What if you make a mistake? The advantage of the friendly English UI is you can’t make syntax errors. No such protection in Code View though, so what if you miss off a bracket?

Making a mistake

Switching out of Code View shows us we made an error, but the rest of the script loads properly. We can easily correct the mistake.

Showing the mistake

All of this works in a very similar way in the web version. The Script Editor now has Code View buttons, allowing you to view the code for a whole script, or any nested section.

Web Editor Script Code View

The Code View button pops up an editor allowing us to view or change the underlying script code.

Web Editor Code View

I hope these changes will be very useful for people on the forums – you’ll now be able to easily copy and paste little script sections, which will be great for people seeking help with a game. When a script has been pasted in, you can toggle back to the normal English view and carry on working as normal. The script you’ve just pasted in will be displayed in English so will hopefully make more sense! You’ll also get a feel for how scripts work in the first place, which I think fits very nicely with Quest’s aim to provide a gentle introduction to programming.

A beta version of Quest 5.4 should be available soon, but if you’re feeling brave you can download the nightly build of the Windows desktop version at CodePlex.

Spanish adaptation of Scott Adams text adventure for iPhone, iPad, Android

The latest Quest-powered app “Aventura Pirata” is now available from the App Store and Google Play, for smartphones and tablets.

Aventura Pirata is a version of Scott Adams’s 1978 game Pirate Adventure, translated into Spanish and adapted for the Quest platform by Mauricio Díaz García.


The game supports the usual hyperlinks and tabs to reduce typing. Selecting an object produces a list of verbs, and exits are visible on the Exits tab (Salidas).


I think this game would be a useful and fun aid for anybody teaching or learning Spanish – it would be great to hear from anybody using it in this way.


In other news, Escape From Byron Bay is now available for Android as well as iOS.

If you’re interested in writing your own text adventure app, please take a look at the Apps page on the site. Any Quest game can be converted into an app, and it’s great to start making a range of different titles available. More are coming soon, but more are needed, so please get in touch!

Apple have recently introduced a new domain, which makes it very easy to find all the Quest text adventure apps for iOS: The equivalent page for Android is here.