Quest

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

XML
I plan to use XML for all communication, because many types of data Quest will need to communicate are structured and I want to use one format for all data. XML parsers already exist in many languages, so that will save time.

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

`*_io.pm` user input/output

`text_io.pm` an example interface client

As an example to show how communication with the meta client should happen I wrote text_io.pl. 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:

*_io::get_command() --> XML string

This function triggers the specific client to send user input to the meta client, a text client would do something like this:

sub get_command {
    print "command? ";
    my $input = readline(STDIN);
    return '' if $input =~ /hello/;
    return '' if $input =~ /quit/;
    return "" # default
}

*_io::display($string) --> void
This function sends a string from the meta client to the specific client, so that the specific client can decide for itsself how that string should be displayed. A graphical client will treat the string completely different than a text client.
A simplistic example in Perl of text_io::display is
```
sub display { print shift }
```
*_io::init(\$world_ref,\$current_room_ref) --> void
This function takes two references from the meta client, one reference to the `world', the other to the `room' where the player currently is, and stores them locally, so that the specific client can access the world directly without having to send an XML request to the meta client.
Communication from the specific client to the meta client works through the return value of get_command(), which is an XML string.

`wxperl_io.pm` 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:

Room requesting and caching
Quest reasoning,
like checking which information should become available to the player and if certain quests the player is participating in have been completed.
Local event generation,
like random encounters and room triggers.

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>
<ROOM name="tree top">
    <DESCRIPTION>The top of the big tree</DESCRIPTION>
    <DOOR name="down" target="tree" file="start.xml"/>
</ROOM>
<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> 
<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"/>
</ROOM>

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"/>

Networking

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:

Individual quests
Sharing quest information with friends
Traveling between Quest servers
Party gameplay

Contact

Mail any comments, questions or suggestions to <wrvh@xs4all.nl>
For further information try the Quest homepage at http://quest.sourceforge.net