QServer2 - The Worldforge Demo Server

by Stefanus Du Toit

In a time long forgotten, amongst the realms of the Forge of Worlds, there was born a new child. It was named QuADAS, and gave much joy to the magicians of the World, since it was their first-born child of that kind. Soon however the magicians realised that the form in which Quadas was did not suffice for their needs, so a new child was created, in a different form, by the name QServer. QServer developed quick, soon it grew so fast that again its name was rethought to be QServer2. Of this child I will now report to you.

To cut it short, QServer2 is one of the first "working" server prototypes at WorldForge. It was never intended to be a playable server, and thus relies on a very simple model. The world consists of a map of entities, which have a few variable properties. This includes their position, name, description, direction, visibility & hearing radii, mass, width, height, type and state. The "state" property is a special one, it defines whether an entity is currently standing, walking, running, being born, dying or static. "Static" entities never change and cannot be moved or controlled by a player, which can be very well used for objects such as walls and other background items (which for now can be assumed to not be destroyed or turned into frog-like creatures by some magical spell). The visibility and hearing radii define the maximum distance that other entities can be seen or speech can be heard. This creates a rather nice "fog of war" effect when players travel through the world.

At the point of their creation, entities require a base type from which they will be derived. These types are predefined as part of the server map and loaded by QServer2 when it starts up. Players can log into the server through their client, which connects on the TCP port 6767 and transmits data from and to the server. The protocol, documented at [1], is a very simple line-based client/server language, particular to this server design. After having connected to the server, the client may request a list of server types from which it may create an entity, or a list of already existing entities in which it may log itself in to. From here on, the client will create or log into an entity and perform its limited set of actions: turning around, walking, running or creating a "speech" entity. Speech entities are special types of entities in that they describe something being spoken by a character. Being entities allows clients to write out the speech directly in the world representation, i.e. there where the player was standing at the point of saying his say.

One of the main features of QServer2 is its collision detection. When two entities collide, they are shifted away from each other to resolve that collision. If a dynamic entity is to collide with a static one, the static one will not move (since static entities are unchangeable) and push the dynamic entity back. Internally, entities are handled by the server as cylindrical objects, for the sake of simplicity.

Communication with the client is done using a so-called agent, which allows the protocol to be changed without requiring a major rewrite of QServer2 - the agent simply has to be replaced. This mechanism is also used at the client side, and in the future servers might even support several agents that can be changed depending on the requests of the client (e.g. binary versus text agents, etc.).

For the comfort of those running the server, QServer2 has several "console plugins" that can be easily switched around. These provide different types of output of all server messages, debugging notices, etc. Included with QServer2 are 3 consoles: a background console that just plainly logs, a text-based console that also takes input, and - the preferred version - a neat ncurses-based console that has features such as scrolling up and down the logs and constant updates of the server state.

The server has become very stable over the past few months, and can now handle fairly large amounts of entities at an acceptable speed. The only client currently to support it is Karsten's UClient, an isometric client using SDL. Karsten has put in a lot of work to keep up with all the QServer2 changes, and this became visible when the first WorldForge Demo was released on the 13th of August. Together, the client and server make a very nice pair.

The main goals when creating QServer2 were to show the public that we have not just been sitting around chatting on IRC but actually have some code that we're working at. In addition to this, it makes an ideal testing ground for further server developments. Quite a few issues have come up while QServer2 was being developed, and these will surely be of good use to the further server developments.

In the future, QServer2 will be reforged into our next prototype server: BackStage. We aim to remove many of the simplifications that were made during the QServer2 development, for instance introducing movement in 3 dimensions, thus adding items such as stairs. Also, more sophisticated line-of-sight mechanisms will be applied. But more on this matter in the BackStage article later in this issue of CB. The first playable WorldForge server, STAGE, will be likely to use BackStage as a testing ground for its features (hence the name) and possibly even inherit a few things from it. We will see with time.

If this article has raised your interest in QServer2, please feel free to take a look at it (you may download it via CVS). If you are interested in helping with our next Q-incarnation, BackStage, please contact us via the server@worldforge.org mailing list. New developers are always welcome.