The system is made up of numerous files in a number of folders.

The top level has the index.html file which is what the player actually sees. You can rename this to whatever you like (if you upload to textadventures.co.uk, the site seems to find it whatever).

• game: The files that define a particular game, i.e., settings.js and data.js. Most authors would only edit the files in this folder. You can change the folder name, but need to then change it inside index.html too on line 21. This means you can have several games under development at once (see here).
• assets: Contains subfolders for icons and default CSS files, and potentially images, audio and videos
• lang: Language files (authors can select the language in settings.js)
• lib: Other JavaScript files. Those that start with an underscore are required, others are optional.

The player types a command or clicks something in the interface, which passes a command string to the parser. The commands feed into the parser, and one is selected and passed to the game world. Changes in the game world are reported back to the user via the interface.

This is where I started. It originally used AngularJS, but I ran into problems and was using it for so little, and I decided it was easier to remove it. It also used jQuery, but I realised that too was unnecessary nowadays, so was dropped (relatively late in development!).

The panes can be removed, the inventories modified, the compass turned off and the command line turned off in the settings file (see below). You can scroll back though your previous commands. Shift-arrow will move you in the compass direction.

This is the actual web page. It loads in the other files, and besides that is pretty basic. The language file that is loaded is set in another file (settings.js).

The CSS styles. These can be edited by uses to change the look-and-feel.

The JavaScript relating to input and output.

Having had a quick read around, I can find no better way to parse player input than searching through an array of commands and testing regexs. JavaScript supports regexs exactly as Quest does (as far as I can tell), so these can be copied straight across. Translating patterns is not straight forward. For example, "get #object#;take #object#" needs to become /^(get|take) (?.*)$/. Tricky if you have multiple objects.

Unlike Quest 5, the parser is context sensitive, and will try to guess what you mean based on the objects present. The parser will get all the commands with a matching Regex, then try and match objects, and score each from that, and will go with the highest scoring. You can add a score to a command to make it higher (or lower) priority. More details here.

An array of commands. Many of the commands hand off the real work to the item, which is a more object-orientated way (and similar to how verbs work in Quest 5). The createItem function therefore gives an item with lots of default "It does not work that way" messages. Adding a template overrides that, to allow the item to perform.

JavaScript to support functions (such as class definitions).

The world model is a set of objects that define some default behaviour in world.js, contained in a dictionary, w. Objects can be given templates (dictionaries or functions that return dictionaries) to give standard behaviour, such as takeable or wearable.

Objects are referenced by their name attributes, which are strings. References to objects are by the name as a string. The player's current location, for example, is the object's "loc" attribute, as a string.

Various functions that relate to the world model.

A template is a dictionary (or function that returns a dictionary). Creators can give a template to an object to add default behaviour, such as wearable.

The three basis templates; object, item and room.

The NPC template (also TOPIC). Note that this file can be omitted if there are no NPCs in a game (but you would want to also remove it from the list of library files).

Various functions that can be used by any component. Will probably be broken into other files as it gets bigger.

The text processor.

Functions to support saving and loading.

The user can make changes here to modify how the game looks ad plays. See here.

All the default settings.

This contains all the language-specific text (in theory). Creators would point Quest to it in "settings.js", but should not need to change it otherwise.

The creator's world is here. Each room or item is created via createObject or createItem (which calls createObject).

The creator's code, other than items and rooms, goes in here.

Configuration for the game, where the author can override any value in lib\settings.js.

CSS styles.

You can include as many files as you like; you may find it helpful to break up the code across several files, or to have NPCs defined n their own file (though that may not be compatible with the editor). Modify the settings.files value in the "settings.js" file to tell Quest which files you want included. Note that they will get added in that order, after everything else.