Diversia QtOgreEditor with a barreldude!

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.

The weather is changed by a lua script on the server, all clients smoothly transition into the new weather (from normal weather, to rain and back to normal weather in the video). The client uses Caelum for the sky and precipitation effects.

Sky and weather effects are synchronized between the client and server using the new client-server plugin architecture in trunk. It’s very easy to create a new plugin like this, basically all you have to do is use the client-server plugin code template and add bindings for the variables and function calls that you want to synchronize, no wrapper functions are required. Permissions are also available for every variable and function call so that for example only the server administrator can change the weather, not just any user. We’ll provide more in depth information about the new architecture in a future blog post!

“In this edition we spoke with the developer of Diversia, an open source virtual world. In an extensive illustrated article, project manager Melvin Rook explains why Diversia has an advantage over existing virtual worlds such as Second Life, which is slowly turning into a ghost world.”

We are still working on the Linux client port, but we ran into strange compile issues. Help is welcome, so we can release soon.

The stable branch can be found at the following URL: http://xmultiverse.svn.sourceforge.net/viewvc/xmultiverse/branches/stable/

Please join our IRC channel (#diversia @ irc.freenode.net) if you would like to help.

In our opinion Phyzle is done (apart from a few small bugs and missing features). The sandbox feature is really popular among a lot of people and the game is downloaded by tens of thousands of people. We received loads of positive reactions on Phyzle:

“I’m a computer teacher and some of my students enjoy problem solving games. I thought maybe this would be a good one to add to our collection. They love Armidillo Run and Crayon Physics.”

“Phyzle – another physics game puzzle builder like Phun. This time in 3D.”

“Some kind of Incredible Machine simulator, sounds cool.”

“Wow this looks awesome! I’m a big fan of sandbox style games like this and the fact that it’s open source makes it even better.”

We moved to Diversia in august 2008, because we expected we can do a lot of things better in Diversia. The sandbox feature would be persistent in Diversia for example. And with the multiplayer feature of Diversia the sandbox feature would be awesome. Not to mention the decentralized feature of the server.

With the Diversia project we raised the bar further and because of many new features the project became really a challenge for us. With the new features, many, many new aspects came into view and soon Diversia became a really big project to manage. We decided to split up the project into two sub-projects and we did the same to the project team. We teamed up with the developers of BlockBox, so we would have six developers in total. Now we had three developers working on the server and three developers working on the client.

In the first three months we had loads of fights discussions on how to implement the server grid, the client- and server structure, UML models, documentation and many more things. After about three months the design was ready and we started implementing. After another three months our proof of concept was ready and we astonished loads of people with our results.

A few months later an article was published in the Dutch tech magazine TECHNO! and in august 2009 Gohla and me demonstrated Diversia at HAR2009. Now with the new architecture coming up, Diversia has a really great future ahead. And lot’s of more is expected.

When you are interested in continuing Phyzle, please contact us, although we will encourage you to join the Diversia team.

- Bamieater

Phyzle 0.1 preview

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.

New architecture, client UML class diagram

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.

New architecture, dependencies diagram

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!

• Teams
• Balancing of teams
• Capture flags
• Dropping flags
• Bombs

The server starts and runs fine, but uses a lot of CPU resources. The bug was introduced after we upgraded a few of the libraries (RakNet or BulletPhysics are the suspects). The CPU usage affects the overall performance of the server, so this bug has a high priority.

During the porting I wrote the documentation in ‘cookbook’ style. In that way it would be easy for everyone to setup a Diversia server on FreeBSD. The documentation can be found on our wiki: http://wiki.diversia.org/wiki/FreeBSD_Server.

If you have any suggestions about the issue described in this post, or would like to help, please drop by in our IRC channel.

They presented Diversia (codename: MultiVerse) for a crowd of about 600 people. The presentation and demonstration was recorded and can be viewed below.

(Excuse the quality while we figure out how to embed video in HD quality)