Quest uses an XML-based file format, and files have an .aslx extension.
Here is a simple example:
<asl version="500"> <include ref="English.aslx"/> <include ref="Core.aslx"/> <game name="Test ASLX Game"/> <object name="lounge"> <object name="player"> <inherit name="defaultplayer" /> </object> <object name="sofa"> <prefix>a</prefix> <look>Just a sofa.</look> <take type="script"> msg ("Example script attribute") </take> </object> <exit name="east" to="hall"/> </object> <object name="hall"> <exit name="east" to="kitchen"/> <exit name="west" to="lounge"/> </object> <object name="kitchen"> <object name="sink"> <look>Just an ordinary sink</look> </object> <exit name="west" to="hall"/> </object> </asl>
This example defines three “rooms” – a lounge, a hall and a kitchen. These “rooms” are defined as objects, and they themselves contain the objects “sofa” and “sink”. The lounge also contains the “player” object.
By nesting <object> elements, you can define further objects inside objects.
There are two libraries included in this example:
Each object’s attributes are defined in the XML. Attributes define all the behaviour of an object. The XML “type” attribute used is to specify the type of the attribute. If no type is specified, the string type is assumed, as with the sink’s “look” attribute 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.
The available types are listed on the Attribute Types page.
The type of an attribute can determine the behaviour of an object. In the above example, the sofa’s “take” attribute is a script, so that will run when the player types “take sofa”. If the “take” attribute is a string, the object will be taken and the string will be printed. This behaviour is defined in Core.aslx.
Attributes can change type while the game is running, by simply setting them to a new value.
When Quest loads the game, it will set the following additional attributes on objects: