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.

Cross-posted to Gamasutra. This blog post is based on part of my AdventureX talk from December – hopefully a video of that will be available soon.

Every couple of weeks, it seems, another games journalist writes an article about how they’ve rediscovered the long lost art of the text adventure game. After a few minutes looking through Wikipedia, they write an article which will inevitably talk about green screens, clattering keyboards, and grues. Then they will talk about a somehow thriving yet hidden “scene” of people who are still creating and sharing these games like some kind of long-forgotten tribe that had been cut off from the rest of the civilised world.

As the creator of a text adventure engine, Quest, these pop up in my Google alerts with tedious regularity. They are so boring and predictable. And more importantly, they are utterly short-sighted.

Many people think of text adventures as an old-fashioned game form, something that was maybe acceptable in the 80s but which we have now outgrown and left behind. But I think the opposite is true. Right now, we are early in the history of text adventure games. Their time to shine is just beginning.

The image above is from the film Le Voyage Dans La Lune (A Trip To The Moon), a French science-fiction film from 1902. For me, it’s the image that immediately springs to mind when I imagine the very early days of cinema. You can watch it on YouTube if you have a spare 10 minutes. If you do, I want you to notice one thing…

It doesn’t look very much like a modern film, does it?

That’s because it’s over 110 years old, of course.

Nearly 40 years later, Orson Welles released his first film, Citizen Kane. You can watch various scenes on YouTube too. This film pioneered many aspects of modern film-making.

It took 40 years to get from Le Voyage Dans La Lune to Citizen Kane.

Forty. Years.

40 years from the early days of film-making to get to something that even starts to look like a modern film. And this wasn’t forty years of hobbyists dabbling with making little movies in their spare time, to be enjoyed only by other hobbyist film fans. This was 40 years during which films were a mainstream entertainment format.

And of course film continues to develop today. Citizen Kane looks somewhat different to Inception, for example (yet I wonder if it’s closer to that than Le Voyage Dans La Lune?)

The first text adventure was written in about 1975, which makes text adventures only 38 years old. Text adventures have never really been a mainstream entertainment format. IFDB attempts to list every work of interactive fiction, and it currently lists 4,444 games. As a comparison, IMDB currently lists 48,525 films created during the period between Le Voyage Dans La Lune and Citizen Kane.

So, there are hardly any text adventure games, really. In that light, it seems completely ridiculous to think of text adventures as some kind of ancient game form. We have barely even begun.

We cannot possibly argue that text adventures have matured. We cannot reasonably declare that we know how a text-based interactive story should work. We will need a lot more games to be written, and a lot more experimental works to be created, before we will be able to see which direction this particular art form is taking.

Therefore when thinking about the future of text adventure games, I like to pretty much ignore the 1980s entirely. Those games have interesting historical value, but will look pretty quaint when we put them next to the text adventure games that will be created over the next few decades.

There is a quote from an interview with Orson Welles which I find particularly inspirational:

Interviewer: What I’d like to know is, seeing that you’d never in all your life, ever made a film before Kane, and had never so far as I’m aware been in a studio before Kane … where did you get the confidence from to make a film with such –

Welles: Ignorance. Sheer ignorance, there’s no confidence to equal it. It’s only when you know something about a profession, I think, that you’re timid, or careful.

What I take from this is that it doesn’t matter if you don’t know much about the existing text adventure games – just the vision and desire to create an interactive story will be enough. Don’t be afraid to try something new.

And right now is a great time to start reimagining what a text adventure is. Why?

Because this never happened:

And this never happened:

(My Photoshop Masterclass was, coincidentally, another thing that never happened – but you get the idea).

Desktop computers, terminals and laptops were never really the right devices for playing book-like games. Tablets and smartphones are the natural home for interactive fiction – and it’s only in the last few years that these devices are in everybody’s pockets. People are used to taking their phone out of their pockets to play with something for a few minutes, and text adventures can perfectly fill that need. Apps can bring text adventures where they belong – in front of people who want to read, wherever they are.

Unlike early film, the tools are available to everyone. My own engine, Quest, is free and open source. You don’t need any programming experience to get started with it, and it can run entirely in a web browser so you don’t even need to download anything. The system is open and hackable, with a core library written in Quest itself which defines the default behaviour – so you can change fundamental things about how the system works, even without going into the source code.

Quest is built upon web technologies, so games can run anywhere, or be packaged with Phonegap and be turned into offline apps. Hyperlinks mean that “guess the verb” is a thing of the past – if you want to, that is, because authors can disable hyperlinks if they choose.

HTML5 opens up a lot of possibilities for experimenting. For example, using Canvas we can dynamically draw maps:

Of course, HTML is designed for laying out text – so there is plenty of room for experimentation here. For example, why not split the screen in two:

The images above are very basic protoypes, but of course you can tap into the full power of CSS and JavaScript to give games your own look, and build your own UI. Perhaps you would want to remove the command bar entirely, or add your own information panes? Maybe change the UI for each scene in the game. Have players type inside a speech bubble, or inside a newspaper column. Make text move, blur, melt away. There are so many possibilities – so many things that have not yet been tried. Some will work, some will not, some will simply inspire other authors to do better.

And even within the writing, there is much experimentation to be done. Text adventures are typically written in the form “You can see… You can go…”. Why not in first person, or third person? Why does it have to be the present tense – why not past tense? Maybe the future tense could even work. We just don’t know – yet.

What about other technologies and APIs we could get a game to tap into? How could we use geolocation within a game? The ability for players to take photos and record sounds? How can we have players interacting over the internet?

There is so much unexplored potential for text-based games. With new devices and technologies, we are really only just getting started. I think we need a new generation of authors to come along, unhindered by 1980s expectations of what a text adventure should look like, and in the spirit of sheer ignorance, create games that will excite and inspire us all.

I hope that Quest is a platform that will enable that – but I’m sure there are many ways it needs to be improved to let that happen. I’m always open to ideas so please get in touch if there’s anything I can do to help your vision become reality. You can email me at alex@textadventures.co.uk or find me on Twitter @alexwarren.

Quest 5.3 is now available. You can download the Windows version, or you can use it in any web browser.

A quick recap of what’s new:

• automatic map generation
• web fonts
• cover art
• text effects
• background images
• changeable player “point of view” object
• light and dark rooms and objects
• automatic display verbs
• new UI for Windows player (identical to the web-based version)
• Windows player UI is now powered by Chromium

For full details on all of these, see the beta announcement which goes into more depth.

Many thanks once again to Phillip Zolla, Pertex, James Gregory, Aleksandar Hummel and Jay Nabonne for code and contributions towards this release.

Don’t forget, Quest is completely free and open-source software. If you want to get involved, please take a look at the CodePlex site where you can find all the source code and the issue tracker.

I’m working full-time on Quest again for at least the next few months, so hopefully you can look forward to some exciting new features and more announcements. If you’d like to show your support, you can help me work on Quest by making a donation.

Thanks for all your support so far – even if you can’t contribute code or donate money, you can help by simply using Quest, releasing games and giving your feedback. Please keep it coming – and help to make Quest 5.4 even more awesome!