For the past week I’ve been working on an editor for Diversia using the client as a library and Qt for the user interface. It’s getting along pretty nicely, object and component (property) manipulation is working but still very simple at the moment. Here’s a screen shot of the editor in its current state:

The major problem I’m running into now is that data changed from within the editor is not yet serialized to server, and data changed from other sources (like clients or other editors) are not reflected in the editor yet. Once I get this working I’ll try to release some installers and documentation for running the server, client and editor.

This is a software development blogpost, it contains technical stuff!

Because this is the first development blogpost, I’ll begin by explaining our current architecture briefly. If you want to know more about the project visit our wiki or have a look at the HAR2009 presentation videos.

Current architecture

There is a server and a client project, servers can connect to each other to form distributed grids, clients connect to one or multiple servers and see the world that is defined by the servers in the grid.
Servers contain objects like barrels, crates and avatars. An object contains multiple components, and components are things like 3d meshes, sounds, object scripts and particles. Objects and components are synced between all clients using our object system and RakNet’s replica system. A simple plug-in structure is used for communication between global client-server processes like authentication, weather, grid layout and terrain data.

We’ve been working with the existing Diversia architecture since the beginning of the project, in that time we’ve found lots of limitations and things to improve in the architecture. A few examples of problems in the current architecture are:

• Low modularity, no easy way to create an AI client for example
• Duplicate code in object and communication systems
• Communication between the client and server is not consistent between different components and server plugins
• No easy way to implement a permission system without a lot of code duplication
• The client-server plug-in system is not as modular as the object system

New architecture

For the past few weeks I’ve been working on a new design to reduce code duplication, increase modularity and increase consistency in the object and communication systems. In the new architecture the project is divided into multiple libraries:

• UtilLib, contains utility code like events (slots), a property system, XML parsing, simple data types (vector, matrix, etc.) and more
• Object, contains the object system that will be used in clients and the server (and could be reused in other projects as well)
• DiversiaLib, contains code that is shared between the client and server
• ClientLib, contains all code that is not implementation (ogre3d) specific so that the code can be reused for an AI client for example
• Client, the ogre3d client
• Server

Properties

One of the biggest improvements in the new architecture is the property system. Properties wrap around simple data types, store the data and control the access to it. Properties can also contain sets of other properties, allowing for infinite nesting of properties. Properties can be automatically serialized/de-serialized to/from XML, binary and RakNet bistreams, this means that writing a custom XML parsing function for every component is not necessary any more!

Permissions

Another big improvement in the new architecture is the possibility to do permission checking. The idea is to do most communication using properties and a message system, because this makes it very easy to check if clients have the right permissions to do the action(s) defined in a message. For example, a client wants to edit the scale (Vector3 property) of an object:

1. The client edits the scale, a message is generated that encapsulates this mutation.
2. The message is first checked against the local permissions table, to see if the message can already be blocked from being sent.
3. If the message was not blocked on the client, it is sent to the server.
4. The server receives the message and checks the permission again, because clients cannot be trusted.
5. If the client has permissions to perform this mutation, the message is forwarded to the correct object and the mutation is executed.

This will work in the client-server plug-in system as well if properties and messages are used.

Diagrams

I’ve created an UML class diagram that shows some of the relations between the different libraries from the ogre3d client’s point of view. It’s a bit messy but it shows where the current components and client-server plug-ins fit in in the new architecture. Click on the image below to see the full image.

Here’s a simple diagram that shows the relations between the libraries inside Diversia, and a few important external libraries. I don’t think this is the official way to draw dependencies between libraries/packages in UML, but it’s simple and shows the relations.

That’s it for now, we’ll be busy fine-tuning the new architecture and implementing it when we feel we’ve got everything right. I’ll keep you updated on the progress!