Tag Archives: hyperlinks

Using Quest to create text adventures for iPhone, iPad, Android

You can already use Quest to create text adventure games for desktop PCs and web browsers. But the big area of growth for games (and indeed software of all types) in recent years has been smartphones, and I’m pleased to report that I am making good progress in bringing Quest games to the iPhone. The way it works is a tool which I am developing to convert Quest games into pure Javascript. By taking the output of this tool and combining it with PhoneGap, it is possible to create native applications for iPhone, iPad, Android, Blackberry and more, which we can then submit to the App Stores. So far, I’ve created an iPhone UI which uses a combination of HTML and the NativeControls PhoneGap plugin for added iPhone-native slickness (there is still some way to go before pure HTML UIs are really good enough). I’m pretty happy with the results – by using Quest’s existing hyperlink support to cut down on the amount of typing required, I think I have come up with a design which makes text adventures work nicely on a mobile phone. First, here’s a screenshot showing the start of an example game. Objects and exits have hyperlinks, and there is a clearly marked textbox for typing in commands. There are tabs at the bottom of the screen for Inventory, Objects, Exits and “More”. IMG_1007 Tapping a hyperlink brings up a standard style iPhone menu. In this screenshot, we’ve just tapped the “glovebox” object link, and we see the display verbs: IMG_1008 If we tap “open”, the “open glovebox” command is inserted, complete with another hyperlink to make it easier to perform further actions on the same object. IMG_1009 Tapping the gun in the output above again gives a pop-up menu. It’s a different set of options this time- in a Quest game, each object can have its own set of “display verbs”, and I think it is especially important for the mobile phone version of a game that each object has relevant display verbs. IMG_1010 If we tap “take”, we’re now carrying the gun. If we switch to the Inventory tab, we can now see it listed. IMG_1011 If we tap the gun in the inventory, we again get a list of verbs. This time it’s Quest’s “inventory verbs” that are used, so we get a different list of relevant actions now that we’re carrying the gun. IMG_1015 The Objects tab is laid out in a similar fashion to the Inventory tab, and shows the objects in the current location. IMG_1012 The compass tab shows the familiar Quest compass, with available exits highlighted. You can tap an exit to move in that direction. You could also simply tap the exit’s hyperlink on the Game tab. IMG_1013 Images are resized to fit the screen. In this example, looking at the car triggers a script to show a picture and print a message. IMG_1014

[Car picture by skrotmumrik, CC licence]

So far, this only works on iPhone, but an obvious next step is to make the UI work nicely for iPad too – which is the perfect excuse for me to go out and buy one! Because I’m using PhoneGap, it will be straightforward to create similar apps for Android too – although the UI would need to be developed for that platform. PhoneGap also supports Blackberry, WebOS, Symbian and soon Windows Phone, so it would be possible to bring Quest games to those platforms too – although it makes more sense to focus on iOS and Android as the main ones. Let’s make it happen If we’re going to find new audiences for text adventure games, we need to make them easy to find, install, and play. Right now, App Stores are a great way of making that happen. I believe they also provide a realistic opportunity to make money from text adventure games – for the first time in years. Think of how many people are happy to buy games for their smartphone, who may never purchase software for their desktop PC. With a few tweaks to the conventional parser-based interface, I hope I’ve shown that text adventures can work well on a mobile phone. I think they’re a great fit for mobile gaming – you can play a text adventure game at your own pace, for a few minutes at a time, whenever it suits you.

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)