Quest lets you add verbs to objects, so you can provide the player with varied and interesting ways of interacting with things in your game. You might add a “read” verb to a book to allow the player to type “read book”, or add an “eat” verb to a burger. By adding these verbs to the “display verbs” list for an object, they appear on the hyperlink menu:
But what if you wanted to do something a little more complicated? Light the kindling with the match for example, or inspect the flock of hair under the microscope? In Quest 5.1 and earlier, you would have to set up a command -
light #object1# with #object2# - and then add some script to see if object1 and object2 made sense. And then, you would be making your game harder to play, because the player is forced to type that command - there’s no way of clicking or touching to trigger a command requiring two objects.
Quest 5.2 makes this easier by introducing two-part verbs. These fit in with the existing verbs mechanism, making them very easy to set up. Best of all, they’re mouse and touchscreen friendly.
Setting up a two-part verb
The process for setting up a two-part verb is very similar to setting up a normal one-part verb. Just go to an object’s Verbs tab and add the verb you want. In the screenshot below, we’ve added a “light” verb to the “kindling” object:
(Note - these screenshots are from the web-based Editor, but the steps are the same on the desktop version)
The next step is to set the verb option to “Require another object” - a new setting in Quest 5.2.
This will then give us an editor where we can add objects which can be used to the light the kindling.
We can now set the script that runs when we light the kindling with the match:
Finally, let’s add “light” as a display verb for the kindling object, to make this verb usable with mouse or touchscreen.
Playing the game
When we play the game, we can type in “light kindling with match”, and we get the expected result - in this case, we see the message “The kindling vanishes quickly in a brief burst of flame”, and then the kindling disappears.
But we can also activate this command using the mouse or touch instead. We added “Light” as a display verb, so we can select that:
Selecting this brings up a menu of things we can use to light the kindling with:
This menu shows all visible objects, excluding the object we just tapped on - in this case, we only have one other object in the room, the match. We can tap Select to trigger the command:
By setting this up as a verb, we get a lot of functionality for free. Previously, in Quest 5.1 and earlier, if we’d set up a custom command for this, we would have had to manually deal with the case where the player tried to light the wrong object. Here though, Quest sensibly handles the full range of things a player might type in - “light flower pot”, “light kindling with egg”, “light myself with match”, etc.
Use and Give
The existing “use” and “give” commands have been updated in Quest 5.2 to display a menu like the “With which object?” menu shown above if the player tries to use them on their own. This means these commands can now also be used without typing.
Try it out now
This functionality is part of Quest 5.2, which will be in beta soon. In the meantime, I have already deployed this new feature to the web-based editor preview, so you can try it out online.
Please let me know your feedback in the comments!
If you use Google Chrome, you can now add the new web-based version of Quest into it as an app, via this link.
Once you’ve done that, Quest will appear on your Apps tab:
That’s all there is to it - it’s pretty much just a link for now. In the future, it could be enhanced to log you in automatically with your Google account, giving you quick and easy access to your games simply by logging in to Chrome.
The web-based version of the Quest editor is now available publicly for the first time. Many thanks to all those who tested it during the closed beta - your feedback has been really useful. Please keep it coming!
I’ve redesigned the Quest page, to reflect the fact that for the first time Quest is now available on more than one platform. Whereas before it was a Windows-only download, now you can access Quest from anywhere, in any browser.
I don’t expect the desktop software to be disappearing any time soon, but with the increasing popularity of always-connected devices such as tablets, it’s clear that any popular software will really need to be available as a web app.
Quest was the first system to allow people to play text adventure games online (as far as I can tell - Quest has had this since February 2007, and I can’t find any references to Parchment before 2008), and now it’s the first full text adventure editor to appear on the web (i.e. it’s much more than a big text box!). Currently, about 10 times as many people play games through the web than download them to play offline, and I’m hoping that the new web-based editor will similarly increase the reach of Quest. It’s not just about extending the editor to Mac, Linux, iPad, etc. - many people simply can’t (or won’t) install software even on Windows PCs.
But it’s also more than just making the software easier to access on any device - it opens up new possibilities too. For the first time, you can start editing a Quest game at home on your PC, continue it on your iPad in the bedroom, and pick it up again during your lunch hour at work. If you’ve got good mobile coverage, and even better eyesight, you can continue on the bus home!
It also means collaborative game editing will become possible, and this is something I plan to look into soon. I’m keen to hear any more suggestions, so please add your comments below or drop me an email.
What’s not implemented
This is still a beta version, so a few features are not implemented yet. Most importantly, at the moment you can edit and play games while logged in, but there’s no way to publish them on the site yet. This is partially because I’ve simply not implemented that feature yet, but also because the web version is Quest 5.2, and the desktop version of this is not in beta yet (so that would mean any games you published would not be playable on the desktop). Both Quest 5.2 Beta for desktop, and the ability to publish games, are coming soon - probably within the next few weeks.
Also, some of the more advanced features of the Quest desktop editor are not yet implemented on the web version. These will probably be added later, after the first “non-beta” release (probably as part of Quest 5.3 later this year). These are:
When I was at Perins School last week, I was asked about puzzles with a time limit. For example, the player opens a cupboard, inside which is a hungry alien. How do you give the player 10 seconds to kill the alien, before the alien kills them instead?
This is pretty straightforward to handle, because in Quest you can run scripts after a certain number of seconds. Here’s a quick how-to:
First, add the cupboard and alien objects. The alien should be inside the cupboard. For the cupboard, go to the Container tab. Choose “Container” from the type list, and untick the “Is open” box so that the cupboard is closed when the game begins.
Now we want to run a script when the player opens the object. We’ll tell the player they’ve surprised the sleeping (and hungry) alien, then give them 10 seconds to get rid of the alien before it kills them. To do this, scroll down to “After opening the object”, and add a “Print a message” script. Next, add another script - from the Timers section, choose “Run a script after a number of seconds”.
You can now specify how many seconds to wait before something else happens. In this case, 10 seconds. After 10 seconds, we want to see if the “alien” object is still visible. If so, print a message and kill the player. If not, we don’t need to do anything.
So, all we need to do is add an “If” inside the “After 10 seconds” script, as shown below:
Finally, we just need to implement a way to solve the puzzle. Let’s add a flame thrower object. When the player uses the flame thrower on the alien, the alien bursts into flames.
Add an object called “flame thrower”, then on the “Use/Give” tab scroll down to “Use this on (other object)”. Select “Handle objects individually”, add “alien”, and then edit the script. Add a “print a message” command to say something to the player, then add a “Remove object” command to remove the alien from play.
The resulting script looks like this:
Now after the player opens the cupboard, if they use the flame thrower on the alien, the alien will no longer be visible in the room. This means that after the 10 seconds have elapsed, nothing will happen. However, if the player has not used the flame thrower, the alien will still be visible, in which case the alien enjoys a tasty meal.
I had the pleasure of spending Wednesday at Perins School in Alresford, Hampshire, where the entire Year 7 (11-12 year olds) went off-timetable for the day to start creating their own text adventures with Quest.
Timetable for the day
This was part of their “Transform” programme spread over five Wednesdays. In the first week, the school had a visit from a local author to talk about writing and creating characters. In week two, they started looking at text adventures, playing The Things That Go Bump In The Night. In week three, they started planning their own games on paper (limiting themselves to four rooms to give a realistic chance of being able to implement the entire game).
Student plans for their own game
I joined them for week four, where the pupils got to create a Quest game for the first time.
To get everybody up to speed, instead of diving in to create their own pre-planned games, the students were given the same game to implement. This was split up into various “Builds” consisting of step-by-step helpsheets, with only about 30 minutes for each Build:
Students learn about creating exits
After the break, various workshops run by myself and Kristian Still. We covered destroying objects, switching objects on and off, locking and verbs, and any other questions the students had such as keeping a score.
I must admit, I thought the timetable was pretty ambitious - these students hadn’t seen the Quest Editor at all before the day, yet by the end of it, most of them were getting on really well. They had covered everything they needed to implement their own games next week.
Kristian grabbed a few of the students for some quick “phonecast” interviews, and asked them how they found the day:
Testing the game
It was really great to see the students getting on well with the software, and I look forward to seeing their finished games.