Quest 5.4 has now been released, and you can download it now or use it in your browser.

The major new features in this version are the text processor, gamebook scripts and script editor code view. For a full list, see last month’s beta announcement.

Since the beta there have been a few minor enhancements, most notably to the gamebook scripts. There is a new “Text + Script” page type which lets you run a script before displaying the normal gamebook text and options, so you’re not forced to display text and options manually. There are new functions for moving the player between pages, and for adding and removing links.

Also:

• In gamebook mode, when playing a sound there is a new option for the sound to continue playing after the player moves to a different page
• You can now turn off the automatically generated display verbs list on a per-object basis (contributed by Pertex)
• New {rndalt} text processor code displays a randomly chosen name from an object’s alt list (contributed by Ivor Levicki)
• With the new-style menus, restored the option to force the player to make a choice from the menu before continuing. (Note this is a breaking change – previously compiled games for Quest 5.4 Beta will continue to work, but to compile against the new library you will need to set the value for the new parameter)
• New function to output text without a line break at the end

As always, if you have any questions or problems, please let me know – you can email me alex@textadventures.co.uk and you can find me on Twitter @alexwarren.

Update 18th March – now with prize money!

It’s officially the first unofficial Quest competition!

Over on the forums, various people have got together to organise QuestComp 2013 – a competition to use Quest to create a text adventure game around the theme of “Plague”.

Evan Williams a.k.a TriangleGames is organising the competition, and there are no prizes except for the glory of winning thanks to Phillip Zolla for sponsoring a first prize of £100.

If you intend to enter, please email Evan by March 31st – full details on the rules, competition timetable and how to enter are at the QuestComp 2013 page.

Thanks also to Scott Greig for the interesting logo, which I hope I’ve got the right way up.

Quest 5.4 is now in beta. You can download the Windows version from the Quest download page. The 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!

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:

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:

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:

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.

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.

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.

Future

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.

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:

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:

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 player.health<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 player.health<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.