by Willem van Hage & Eddy Wolthuis

Quest is a free, modular system for creating computer based role-playing games. This is the documentation and background of the Quest project.

Writing free software takes a lot of effort and to get anything done cooperation is necessary. The thing I've found to pose the greatest problem when adding to free software is discovering how to communicate with the already existing software. To overcome this problem the goal of Quest is to be as modular and simple as possible and not to invent new systems where standards already exist so that outsiders will not have to struggle with arbitrary internal standards.

FIXME: add short story about how Quest is inspired by POSIX processes.

Used subsystems

The big picture

The Quest client is really a collection of clients each dedicated to a separate task, examples of such tasks are network communication, data administration, user input/output in a certain game situation, etc. The server is set up in a similar way and can start its own clients to get specific tasks done, for example create a client to control a pack of goblins attacking the player.

specific client <-> meta client <-> client comm. <->
server comm. <-> meta server <-> specific server

Details of the implementation

* user input/output an example interface client

As an example to show how communication with the meta client should happen I wrote It's a user interface that takes input from the standard input of a terminal and sends back output to the standard output of that same terminal, similar to Zork.

The idea is that every such client should have the same set of functions that the meta server can call, so that the meta server won't have to know what kind of specific client it's talking to. The set of functions will have to be determined as we go, adding to the specification when needed. Currently these functions are in use: a graphical interface client

The first problem I ran into was that most graphical user interfaces have their own main event loop. That means you can't just let the init function set up a window and then start displaying things into it from the main loop in the meta client, because if you start the GUI's main loop from the init function it won't return until the window is closed.

My immediate reaction in the past was to change the entire program to use the GUI's main loop as its main loop, thus making all other tasks of the program subservient to the GUI, but that is exactly what I don't want. So this makes communication between the meta client and the io client a bit more complicated.

The meta client

The meta client translates information from the specific client for the server and vice versa and does the client part of the administration of the world. Things the meta client will do are:

Here is a piece of example Perl code, to give an idea of the main loop of the meta client:

unless ($quit) {
    $_ = text_io::get_command; chomp;
    my $command = XMLin($_);
    if ($command->{"CLIENT"}) {
        my $cmd = $command->{"CLIENT"}->{"command"};
        text_io::display("Hello World!") if ($cmd eq "hello");
        $quit = 1 if ($cmd eq "quit")

Quest XML

Quest currently uses XML for two disctinct purposes. One is server--client communication, the other is storage of world information. Like the interface specification for the specific clients the XML standard will have to grow along as the game progresses.

Example: Here's an example data file.

<ROOM name="start">
    <DESCRIPTION>The first room of the game</DESCRIPTION>
    <DOOR name="blue door" target="blue room" file="blue_room.xml"/>
    <DOOR name="big tree" target="tree trunk" file="start.xml"/>
<ROOM name="tree top">
    <DESCRIPTION>The top of the big tree</DESCRIPTION>
    <DOOR name="down" target="tree" file="start.xml"/>
<ROOM name="tree">
    <DESCRIPTION>Near the top of the big tree</DESCRIPTION>
    <DOOR name="up" target="tree top" file="start.xml"/>
    <DOOR name="down" target="tree trunk" file="start.xml"/>
<ROOM name="tree trunk"> 
    <DESCRIPTION>At the base of a big tree</DESCRIPTION>
    <DOOR name="up" target="tree" file="start.xml"/>
    <DOOR name="down" target="start" file="start.xml"/>

Example: Here's some example communication records.

<CLIENT command="move" target="tree top"/>
<CLIENT command="trigger" target="look in mirror"/>

<REQUEST><FILE name="blue_room.xml" path="./data"/></REQUEST>

<ERROR info="blue_room.xml doesn't exist"/>


Not much effort has gone into networking or user administration yet. It'll happen when necessary. My first goal is to make a working single-player game that's easy to customize. Network play will come later. Expect things like:


Mail any comments, questions or suggestions to <>
For further information try the Quest homepage at