Axe Software Blog » Quest

Quest in other languages

Alex Warren — Mon, 01 Mar 2010 19:36:11 +0000

Quest 4.1 supports languages other than English by creating an LDF file.

I have now added a Quest Translations page to the website containing LDF files contributed by users. Currently we have translations of Quest into German and Spanish.

If you’ve created an LDF file for Quest, I’d love to hear about it! Please email me at alex@axeuk.com if you would like to submit an LDF file to the site.

Games in Spanish

I came across this page of Quest games in Spanish:
http://wiki.caad.es/Categoría:Aventuras_Quest

If you know of any other pages of foreign language games (or indeed any other websites to do with Quest), please let me know and I’ll add a link from this site.

The HTML interface in Quest 5.0

Alex Warren — Fri, 19 Feb 2010 09:00:28 +0000

Previous versions of Quest used a “rich text” control to display text. This is quite an old Windows control, which is fine for basic formatting but ultimately lacks flexibility. Quest 5.0 replaces this with an embedded web browser, which opens up a lot of new capabilities.

At a basic level, it makes it very easy to add something I have wanted to add to Quest for a long time – hyperlinks:

By default, objects and exits in a room description are hyperlinked, so the player can look at objects and move around the game by clicking the game text. I may add the option to display a short menu of verbs instead, so that the hyperlinks could potentially be used as a complete replacement for the object panes.

Of course, some game authors may not like this, just as some authors don’t like Quest’s default panes – but you will be able to turn these off. The links are put there as part of the room description code in Core.aslx, so you can override it, and there will be an option to turn it off.

Two-way interaction with JavaScript

The most exciting thing about using HTML for the interface is that you can completely customise it to look exactly as you want. You can specify your own HTML file for the interface by including an interface tag in your ASLX file. Within that HTML file you can call JavaScript just as in any standard webpage, and that JavaScript can interact with your ASLX file.

To call JavaScript from your game code, we can use a particular call to the request command. The request command’s first parameter is the request type, and a request type of “RunScript” lets you call any JavaScript function defined in your game interface.

You can see an example of this in the YouTube example included with the Quest 5.0 samples. In the example we use the following code:

request (RunScript, "AddYouTube; ZXZWepU7zC8")

This calls the AddYouTube function defined in YouTube.js, and passes in the parameter “ZXZWepU7zC8″ which is just the YouTube id of a particular video.

The AddYouTube function simply creates the relevant HTML to embed the video and adds it to document.body.innerHTML. The video then appears in the Quest window.

You can also go the other way, making a JavaScript function call a function in your ASLX file. This way, we might get rid of the hard-coded panes altogether and have a purely HTML and JavaScript solution which can be customised however you want. It also opens up the possibility of support for “point and click” games in the style of Monkey Island, because you could trigger game behaviour when the user clicks on something in the HTML interface such as part of an image.

To trigger a Quest function from JavaScript, you can call the ASLEvent function defined in WebFunctions.js. This is included in the standard HTML interface (PlayerDefault.htm, which is the default interface used by Core.aslx), and takes two parameters – the name of the function, and one parameter. You can call any Quest function that takes one string parameter.

Types in Quest 5.0

Alex Warren — Thu, 18 Feb 2010 09:00:52 +0000

“Types” let you share sets of properties between objects. They work in the same way as Quest 4.x, except slightly more efficiently in that instead of copying the properties to the object, the object just references the underlying the type if it doesn’t have its own override for a property.

You can view all the properties of an object using the Debugger, which is accessed via the Tools menu. Properties from an inherited type are shown in grey.

Types are defined using a element, and properties are defined in the same way as for an object. Objects and types can both inherit from other types using an tag.

  
    0
    It looks tasty, but you're not hungry right now.
  

  
    
    10

Default behaviour

If the ASLX defines a type called “default”, then it is applied to all objects – there is no need to specifically inherit from this type. Core.aslx uses this to define the default behaviour for objects:

The displayverbs and inventoryverbs properties are defaulted to give the standard buttons on the panes on the right-hand side of the Quest screen (“Look at”, “Take” and “Speak to” for the objects list, and “Look at”, “Use” and “Drop” for the inventory list)
All objects are droppable by default
The neutral gender and article (“it”) are set
Default container properties are set – by default the object is not a container, cannot be opened or closed, etc. This is just for convenience really – if we didn’t set these in the default type, then properties such as “isopen” would default to null instead of false, which would make the container logic messier. (An enhancement might be to add special logic so that in an expression “null=false” would be true, but I’m not sure how good an idea this would be – I’m open to feedback on this)

“Undo” support in Quest 5.0

Alex Warren — Wed, 17 Feb 2010 09:00:18 +0000

Over the years one of the most commonly requested features for Quest has been the ability for the player to be able to type “undo”. This would have been difficult to add to previous versions of Quest, as the game state was stored in a number of different ways, but in Quest 5.0 the entire game state is stored within object properties. The location of objects is a property, global variables are properties, and so on. This makes it much easier to enable support for “undo”, and from the start Quest 5.0 has been written with this feature in mind.

Every change to a property is internally logged, which makes it easy to go backwards and undo changes on a turn-by-turn basis.

Core.aslx defines the “undo” command, which simply calls the script command “undo”. This gives the player unlimited access to the “undo” command, but you could override this in your own games to set certain conditions for undoing. Perhaps you would disable undo in certain locations by setting a certain property in the player’s parent room, or maybe you would set a limit on the number of times the command can be called. Any of this is easily achievable by creating the appropriate script around the “undo” command.

Monitoring changes to properties

If you want some script to be triggered whenever the value of property
“X” changes, you can add a “changedX” script property.

For example, when the player moves, the value of their “parent” property changes. This means you can call some script when this happens by setting a “changedparent” script property for the player. This is what Core.aslx uses to trigger the printing of the room description:

  
    OnEnterRoom

This calls the “OnEnterRoom” function every time the player moves into a different room.

Another way this might be useful would be if you had a “health” property for the player – you could create a “changedhealth” script which would finish the game if the health value reached zero, and maybe also set a maximum value.

Expressions in Quest 5.0

Alex Warren — Tue, 16 Feb 2010 09:00:47 +0000

Quest 5.0 handles expressions throughout all script commands. Whereas in previous versions, things like string variables had to be denoted using special characters, in Quest 5.0 you can use expressions everywhere, just as you can in ordinary programming languages.

Of course, many games will only ever need very simple expressions, and the visual editor will mean that many game authors may never need to write one directly. But, with Quest 5.0, the full power of expressions is available everywhere if you need it.

This means no more special characters are required to denote variables and functions, and also the “if” command gets the full power of expressions – you can use nested expressions with “and” and “or”, and compare expressions directly.

Here are some example script commands containing expressions:

foreach (obj, GetObjectsInScope("Visible")) {
  msg ("You can see: " + obj.name)
}

if ((a and b) or (c and d) or (somenumber * 3 > somethingelse)) { .... }

foreach (obj, somelist + anotherlist + SomeFunctionReturningAList(blah)) {
  ....
}

MyCustomFunction(a, b, c+d)

player.parent = GetRandomRoom(GetNearbyRooms(player.parent))

someobject.take => {
  msg ("Blah blah")
  someobject.counter = someobject.counter + someotherobject.someproperty
}

Quest 5.0 also supports local variables. This means you can reuse the same simple variable name inside different functions, if you don’t need to access that value outside the function. You don’t need to declare variables in advance – you can just use them by setting them.

Global variables are now just properties of the “game” object, which means the entire state of the game is always defined entirely by object properties.

Quest 5.0 Technical Preview now available

Alex Warren — Sat, 13 Feb 2010 14:29:11 +0000

The first Quest 5.0 Technical Preview version is now available.

This is a very early release. Most importantly, it’s limited to hand-coding games (there’s no visual editor yet), and there’s no support for games for earlier versions of Quest. These features will be added over the coming months/years (it’s going to be quite a while even before the first proper beta versions).

You can download it from the new Quest 5.0 wiki at quest5.net

If you have any feedback or questions, please drop me an email or see the forums.

Enjoy!

Verbs, Commands and Templates in Quest 5.0

Alex Warren — Wed, 03 Feb 2010 09:00:49 +0000

Note: this information is now out of date. Please see the updated article on the Quest 5 wiki

Quest 5.0 currently follows relatively similar principles to previous versions when it comes to processing player input. I say “currently” as this may change over the course of the technical previews and beta versions, and I say “relatively” as although based on the “old” system, there is a lot more flexibility and power in the new way of doing things. In a nutshell, we retain the concepts of verbs and commands.

Here is a simple command:


  msg ("Hello")

This allows the user to type “test”, and in response prints “Hello”. So far, very similar to Quest 4.

Verbs let you add “doing” words, to let players interact with objects. For example:

You cannot eat that.


  
    msg ("Yum yum yum")
    crisps.parent = stomach
    player.health = player.health + 5

This would let the player type “eat crisps”, and provide a sensible response for when the player tries to eat other objects in the game.

Templates

Core.aslx defines the behaviour for standard verbs such as “look at”, “speak to” and so on, but the actual text for the verbs themselves comes from the language library (English.aslx). To have the behaviour in one place but the verb itself in another, we have templates, which look like this in English.aslx:

A French version might look like:

We use square brackets in Core.aslx to dynamically replace text with the template. So Core.aslx might have a line like this to define the verb, which will behave in exactly the same way as the verb in the above example:

[cannot_eat]

As well as using square brackets, for tags you can use command templates. These let you specify multiple ways of expressing the same command, which each resolve to the same template. For example, English.aslx might define an “inventory” command like this:

i
inv
inventory

That way, “i”, “inv” and “inventory” all resolve to the same template “inventory”, and Core.aslx can define the behaviour of the command like this:

...

Matching objects in commands

For more complicated commands, such as “put apple on table”, you can match objects within a command. Quest 5 lets you use regular expressions for this:

.*) (on|in) (?.*)
]]>

This may look slightly frightening at first glance, but it’s pretty simple underneath the scary syntax. The “” characters for the named groups in the regular expression, but we will have an invalid XML file if we don’t use a CDATA section.

For any named group with a name starting with “object”, Quest tries to match it to an object in the current visible scope (e.g. the objects in the current room, plus the objects in the inventory – I’ll be discussing scopes in more detail in a future post). You can also have named groups starting with “exit” to match available exits.

When the script for the command runs, local variables “object1″ and “object2″ are set to the objects specified in the command, so you can access their properties directly using “object1.parent” etc.

It may be the case that this mechanism is refined as we go through the development process, as regular expressions are probably overkill. It might be nice to simplify the named group syntax so that you can write “put #object1# (on|in) #object2#” in a similar way to Quest 4.x.

Dynamic Templates

Templates are used for all the standard output from Core.aslx. This includes the standard error messages, such as “I don’t understand your command”.

A dynamic template is a template that can call functions and read properties. This is useful for dynamic responses such as when the player tries to take an untakeable object. Usually, a response of “You can’t take it” is sufficient, but what if the object is a female character? Dynamic templates to the rescue – they are essentially functions that return a string value, for example:


  "You can't take " + object.article + "."

A female character should have their “article” property set to “her”, so this will print “You can’t take her.”

To print this from a script, call the DynamicTemplate function, which takes two parameters:

msg (DynamicTemplate("TakeUnsuccessful", object))

Note: this information is now out of date. Please see the updated article on the Quest 5 wiki

The Quest 5.0 .aslx game file

Alex Warren — Mon, 01 Feb 2010 09:00:11 +0000

Quest 5.0 uses a new XML-based file format, and files have an .aslx extension.

Here is a simple example:


  
  

  

  
    
    
      a
      Just a sofa.
      
         msg ("Example script property")
      
    

    
  

  
    
    
  

  
    
      Just an ordinary sink

This example defines what in previous versions of Quest would have been three rooms – a lounge, a hall and a kitchen. In Quest 5.0 these are just objects, and they themselves contain the objects “sofa” and “sink”. By nesting elements, you can define further objects inside objects.

Libraries

There are two libraries included in this example:

Core.aslx provides the default Quest functionality, including: showing room descriptions, implementing default verbs such as “take”, “drop” and “use”, opening and closing containers, and deciding which objects are currently available to the player.
English.aslx provides the English text for the built-in default responses, and the names of the verbs whose behaviour is defined in Core.aslx. This means Core.aslx is language-neutral – if you wanted to make a game in German or Spanish, just translate English.aslx and plug it in to your game.

Properties

Each object’s properties are defined in the XML. In previous versions of Quest, there were only two data types – “properties” were strings, and “actions” were scripts. To make things more confusing, the properties and actions for an object were separate from the tags specified in the ASL file, so you couldn’t always read all the information about an object from a script.

In Quest 5.0, everything has been unified into properties, and there are more data types available, with the XML “type” attribute used to specify the type. If no type is specified, the string type is assumed, as with the sink’s “look” property in the above example. An exception is if there is no data in the XML tag, in which case a boolean “true” is assumed instead – as in the “start” property for the lounge.

The available types are currently:

string
double
int
boolean
script
list (of strings)
list (of objects)
object
exit
null

The type of a property can determine the behaviour of an object. In the above example, the sofa’s “take” property is a script, so that will run when the player types “take sofa”. If the “take” property is a string, the object will be taken and the string will be printed. This behaviour is defined in Core.aslx.

Properties can change type while the game is running, by simply setting them to a new value.

Additional properties

When Quest loads the game, it will set the following additional properties on objects:

name – string, from the “name” attribute specified for the tag
parent – reference to the containing object, or null if the object has no parent

The player object

The player is itself an object in Quest 5.0. Here, the lounge has the property “start”. Core.aslx defines the player object, and when the game starts it will move the player into the start room by setting the player’s “parent” property to the first object that has a “start” property set to “true”.

An overview of Quest 5.0

Alex Warren — Sat, 30 Jan 2010 14:28:30 +0000

Quest 5.0 is under development, and is substantially improved from previous versions. Although it is still a long way from being released, I thought it would be a good idea to write a series of blog posts discussing how the new system works, and the new capabilities this will bring to the system.

Limitations of Quest 4.x

Quest has grown over the years, from the very limited and somewhat quirky Quest 1.0 back in 1998, to the much more powerful system that it is today. However, it is still based on those foundations laid over a decade ago, and this means that it would be hard to implement some frequently requested features without a fundamental rewrite. This is the reason for taking Quest “back to the drawing board” – Quest 5.0 is a brand new text adventure game system, but taking many cues from the current design of Quest.

Doing more with less

The main idea behind the new version of Quest is that most of its features should be implemented in Quest itself. This is a fundamental change from the way previous versions have worked – in Quest 4.x, there is code for handling the ASL (the Adventure Scripting Language, which is how games define their own logic), and there is also separate code for providing the default behaviour for games, such as what happens when a player takes an object, how to print room descriptions, etc.

By contrast, Quest 5.0 is designed to handle as little default game behaviour as possible. Instead, all this code is written in ASL itself, and defined in a core library. This means that as a game author, you can see exactly how the system works at quite a deep level – and more importantly, you can override this and specify your own behaviour instead.

Many concepts which were separate in previous versions have now been unified. For example, Quest 4.x has separate ideas about rooms and objects, and the player itself is something different again. In Quest 5.0, these are all just objects. An object can contain other objects, and they can contain objects themselves, and so on. So when the player enters a kitchen, the player object moves inside the kitchen object. The kitchen then contains the player, in exactly the same way that a fridge defined in the game might contain a bottle of milk.

Eating one’s own dog food

In writing the fundamental behaviour of Quest in ASL, I have had beef up the power of the language. By “eating my own dog food”, I have had to design ASL to handle many things that previous versions simply couldn’t cope with, with the result that it is now a much more powerful and capable language. Expressions are now fundamental to the way ASL works, for example, and there is built-in support for handling lists.

Technical Preview

I’m very excited by the potential of the new system, and I’m keen to release an early version as soon as possible so I can get your feedback. This will be a very rough “technical preview” version, with plenty of functionality missing – there will be no visual editor and no ability to load Quest 4.x games – though of course these will arrive later. I expect to release this preview version in the next month or two.

Stay tuned this blog for updates, and if you have any questions or ideas then please post to the new Quest 5.0 forum.

Quest 4.1.2 is now available

Alex Warren — Sun, 17 Jan 2010 18:01:36 +0000

Quest 4.1.2 is now available.

This release improves the performance of large games.

It also fixes the following bugs:

A run-time error could occur when typing “put on” if that command did not exist.
Locked exits weren’t working in packaged games.
Some container-related messages were not present in the LDF file.

If the JAWS screen-reader is running, QDK now shows the old-style menus and toolbars as these are easier for the screen-reader to work with. In addition there is a new “Go To” menu for JAWS users which makes it easier to select items from the Treeview.

Quest Pro users can download the update from http://www.axeuk.com/mydownloads

Non-Pro users can download the update from http://www.axeuk.com/quest/quest412.exe