The “retro” aspect of text adventure games is kind of fun, but I think it can also be limiting. I think there is a lot of potential for text adventure games to have a broader appeal, with wider uses, way beyond harking back to old-skool computer games. There is a place for text adventures on the modern web, but not simply “hey, remember those old games from the 1980’s? Some people are still making them!”
I am guilty of this kind of pigeon-holing myself of course. The current introduction on the Quest website says “Quest brings 1980’s-style text adventure games up to date” - well, fine, yes, maybe it does, but when I rewrite that introduction for Quest 5.0, I don’t want to frame it in those terms.
This is because I want to introduce this type of game to a new generation of authors and players, and these people may not even “remember” text adventure games in the first place. In fact, the most important people who I want to introduce to text adventures certainly won’t remember them - anybody at school today will have been born after 1993, a long time after text adventures ceased to have a mainstream appeal.
There are educational uses for Quest, both in getting students to play text adventure games, and in getting them to write their own. There are probably ways of using Quest in any subject that touches on problem solving, reading, or creative writing:
To children, text adventures are not old-fashioned - they’ll likely have never played anything like them before, so it will be new to them. This could be a challenge, in that they’ll be unaware of the conventions around the kinds of things they can type - but I think that Quest’s hyperlink support can help them to get the idea quickly.
I am very keen to hear from any teachers who are either currently using Quest in the classroom, or who may be thinking about doing so.
In the last month or so I have heard from:
As well as secondary schools, I have also heard from a university professor considering creating a final year project using Quest. There should be applications at the younger end of the spectrum as well - simpler text adventure games for primary school pupils.
In fact I don’t see any reason why primary school pupils wouldn’t be able to create games as well. I may need to work on a “simple mode” for the Quest editor, but if I can introduce young children to programming, that will be a great thing. I myself started programming on an Acorn Electron using BBC BASIC at the age of 8, and it would be fantastic if Quest could be used to get today’s 8 year-olds into programming too.
Quest features the ability to distribute games over web, so players don’t need to install any software. You can either upload games to textadventures.co.uk, or if you have a Windows server, you can install the Quest WebPlayer component. This means that it’s simple to deploy a game - whether you want students to play over a school network, or on their home computers, iPads etc., there’s no software to install on the end-user machine - all you need to do is give them a web link.
In the near future I want to look at enabling ways of integrating Quest with systems such as Moodle. The idea being that you could get students to play a game, and assess any aspect of the game session in the external e-Learning system - that could be simply whether or not they completed the game, or it could be any attribute such as the score, the number of rooms visited, or a full transcript of the game session. Unlike other “play online” systems (such as Parchment for Inform), Quest runs the game on the server, not the client - so it should be easier to implement such monitoring features by creating an API that can transmit details of the game session somewhere else.
I’m very keen for any feedback on this, as this is a new area for me. If you’re thinking about using Quest in the classroom, I’d love to hear from you - what are your ideas, and what can I do to help?
Quest 5.0 Beta 3 is now available for download.
The first draft of the Quest 5.0 Tutorial is also now available.
We are getting closer to the final 5.0 release now. The Issue Tracker currently only has a few relatively minor features assigned to a future Beta 4 release, so what we have now is close to the final version 5.0. Of course, version 5.0 is just the beginning - a rebirth for Quest, really - and I have lots of ideas for the versions that will come afterwards. But I think it is important now to get the new system stable and “out there”, so I don’t expect that there will be too many dramatic changes before the “gold” or “RTM” version 5.0.
New features in Beta 3:
This release also fixes all bugs which have been logged so far - 45 items since Beta 2, according to the Issue Tracker. Many thanks to everybody who has been logging bugs so far. Please keep them coming!
Two classic problems of text adventure games:
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)
It’s been another busy month of Quest development, and I’ve just released Beta 2.
The main change in this release is a substantial redevelopment of the Editor UI - it is now written in WPF, which has made laying out dynamically sized controls much easier. In particular, this is what has enabled me to implement the new-look Script Editor, as described in last week’s blog post.
Aside from that, all bugs that were logged against Beta 1 have now been fixed, and I have also implemented a few other features:
You can now keep a picture at the top of the screen, while the text scrolls beneath. This has been a common request for years, and I’m glad to have finally implemented it. Using HTML means that you can use any picture size you like, and the frame will resize accordingly. It means that it works the same wherever your game is being played - whether in the Quest desktop software, or online via the WebPlayer. It also means that in upcoming versions I’ll be able to extend this functionality to enable things like using a YouTube clip in the static frame instead.
Timers are now implemented, and you can use them in a couple of different ways. First, you can use them in the same way as in earlier Quest versions, where you can run a script at specified intervals. But there’s a new simpler way of creating a “one off” timer, which will run one time only, after a certain time period has elapsed. This creates a timer object behind the scenes, so even if the player saves the game and reloads it later, the timer will still be triggered at the correct time.
Turn Scripts are analogous to timers, but instead of running a script at specified time intervals, you can run a script every time the player enters a command. You can create multiple turn scripts in the game or in different rooms, and enable/disable them at will, so it’s a bit more flexible than the “afterturn” scripts from previous Quest versions. Also, just as you can now run a script after X seconds have elapsed, you can now run a script after X turns.
Random Numbers and Expression Templates
I’ve added functions to generate an integer in a range (say, from 1 to 10) and to generate a random floating point number (between 0.0 and 1.0). With the new Expression Templates (covered in the previous blog), I was able to easily add some nice templates to the editor:
In Beta 1 you could save your game as an ASLX file, but there was no safe way to distribute your game. Beta 2 comes to the rescue with a new “.QUEST” file format, which is similar to the CAS format in previous versions. It will take your game, including all libraries and external sound, picture files etc., and output one .QUEST file. This will be the file format you’ll have to use to upload your game to textadventures.co.uk. This will ensure that games written for one version of Quest will still work in future versions, as the entire Core library will be included within the .QUEST file, so there won’t be any incompatibility problems as features are added and changed in the Core library.
You can now put what the player types next into a string variable, ask the player a “yes or no” question, and there’s a full-screen option if you want to go completely old-school and get your Windows taskbar out of the way.
You can download Beta 2 now from the Quest 5.0 Downloads page.
If you have any questions or problems, please ask in the Quest 5 Forum or check the Quest 5 documentation wiki. Please report any bugs on the forum or the Issue Tracker, or email me at [email protected].
I’ve often described Quest as allowing you to create text adventure games “without programming”, but of course that’s not strictly true. While you could create a game without using any scripts at all, you’d only be able to tap into very basic, default behaviour, so it would be quite a boring game.
What Quest has always aimed to do is to make creating scripts easy, by taking a different approach to programming. You still enter commands, use variables, functions and so on, just as in “real” programming, but the Script Editor guides you through the process and tries to make it as intuitive as possible. There’s no need to remember syntax, type in strange punctuation or even remember the names of commands, because the Script Editor shows you all the available commands, and guides you through entering their parameters.
It essentially presents a graphical layer in front of the underlying code. The underlying code is still there, and in Quest 5 it looks pretty much like any other programming language, but the Script Editor shields you from all of that, and displays as much as it can in plain English. The aim of this approach is that you should be able to get started quickly, even if you’ve never programmed before, but also know that you have as much power as you could ever need if you delve a little further.
With the new Script Editor appearing soon in Quest 5.0 Beta 2, I think I have achieved my aim of improving on the design of the Script Editor in Quest 4, making it both quicker and easier to use for beginners, but exposing the full power of Quest 5’s new scripting language for those that need it. At the same time, the Script Editor is flexible enough that new libraries can hook into it to allow the game author to easily use all of the library’s features.
In Beta 2, I have rewritten the Script Editor UI from Beta 1, so it now looks quite a bit different. Here’s an example of the Script Editor showing the kind of script that often appears at the beginning of a game - it prompts the player to enter their name, and then welcomes them to the game:
Behind the scenes, this the script that has been created:
msg ("Welcome! Please enter your name to begin.") playername = GetInput() msg ("Welcome, " + playername)
Let’s look at each of these commands in turn, and how the Script Editor helps you to create this kind of script.
First, there’s a command which simply prints a message to the screen. Starting with a blank Script Editor, the only option we have is to expand the “Add new script” section, which gives us a searchable, categorised tree of all the commands we can use:
We can click “Add” or double-click to add this command. Now the Script Editor looks like this:
We can simply start typing the message. No need to worry about closing quote characters, or indeed including quote characters within the message - the Script Editor handles all of that, ensuring the underlying script is created correctly (with any quote characters in the message escaped if necessary).
Next, we want to add a command which will store the next thing the player types in at the command prompt. We click “Add new script” again, and add the “Set a variable or property” command, which can be found in the “Variables” category (or by typing “set” in the search box).
We can type in a name for our variable, “playername” for example. Next we need to enter the value for the variable. We can enter any expression, such as “2”, “foo”, “3+8”, “SomeFunction()” etc. So we could call the function ourselves, but the Script Editor has another trick up its sleeve - expression templates.
Expression templates appear for a number of script commands, and provide access to common functions. They are context-specific, so you see different expression templates for the “set” command than for the “if” command. If you click the “expression” drop-down, you’ll see the available templates. Currently, for “set” you will see this:
(This list may well be expanded before Beta 2 is released, and the templates are defined in the core library, meaning that the list can be easily extended)
Selecting “player input” completes the command, and now we can add the final “print” command to welcome the player. But this time we don’t want to print a static message - we need an expression, so we can include the value of the “playername” variable we created earlier.
A similar dropdown on the “Print” command allows us to switch to an expression:
We can now add the expression
"Welcome, " + playername, and the Script Editor will give us a bit of help with that, too. The blue triangle to the right of the expression contains a menu which allows us to add things to our expression:
Selecting “Variable” from the menu gives us a drop-down list of all variables in the current scope - in this case, just the “playername” variable we created earlier. Of course, we can simply type the expression too.
To experienced programmers, this may seem like quite a lot of pointing and clicking to create a simple script. You may think that nobody would want to program this way - but the evidence from previous versions of Quest shows that’s not the case. When I first added a visual editor to Quest, way back in 1999, it was far from clear that people would want to program in this way, but people do - the visual editor is by far the most popular way to create games for Quest 4, and while I’ve always supported the ability to “hand code” games using a text editor, pretty much nobody uses Quest in this way. In Quest 5, the Script Editor is even easier to use, and more powerful, so I hope it will allow both experienced programmers and novices alike a way to get started making games quickly. Quest 5 also features a Code View, so the “hardcore” version is just a click away anyway - you can switch back and forth easily.
The new Script Editor will be available in Beta 2, which I’m hoping to release within the next couple of weeks. If you can put up with buggy code and have Visual Studio, you can try it out now by downloading and building the latest trunk code from CodePlex.