Schmunzels development Blog

Hi everyone *waves all around*

As we now have our new and shiny Forums in order to communicate more with you guys out there I thought that I give it a go and start with the communication process.

In this "blog" of mine I intend to post in an irregular way about my development endeavors so that you guys out there can have some basic idea of what I am doing here with our beloved precu.

Today I want to tell you about our general server layout.

As you possibly know (and if not you will learn it now) one of the major features of our server is its scalability which allows any possible layout starting from a small private party server to a fully fledged data-center install.

Scalability mainly boils down to the organization of data between different nodes of processing.
In a server layout were you allow a zone (say planet) being divided into different subzones which then might be run on a different cpu or an entirely different box, you have to organize your data-flow and the data ownership between them. In a real server implementation this would mean that you would have one central data-broker who would serve the nodes data-requests with potentially a lot of organizational overlap and a huge amount of inter-server communication to coordinate objects and their interactions between your nodes.

In our planet-based MMO this approach would be especially effective when you have large amounts of players evenly distributed over an entire planet which - in a perfect world- wouldn’t interact with each other like by seeing each other.

And this is exactly where the problems start. When our players are near each other but on different zones we need to inform the neighboring zones of what is happening on their adjacent zones. Players will interact with each other and the world around them regardless of zone boundaries - this subzone communication will require huge amounts of processing power and bandwidth.

Bearing this in mind we decided early on in development that given the amount of CPU power available nowadays the only real bottleneck a server would be likely to face is bandwidth.

While the bandwidth necessary in inter-server communication will be huge it will not be the main problem as servers usually should be interconnected by fast lan connections. However for the connection to the player this is quite markedly different - ignoring the extreme case of a lan-party with 1000 players.

As an example I will tell you that our private test center in Canada - which is on a 1MB upload line - can support around 40 to 50 players running around and interacting (combat socializing etc). The cpu is at this point hardly affected by one single zone (though in our case we host all 11 servers on a dualcore machine).
On my private machine (a 6000 Athlon dualcore) I have up to 300 bots running around in a single city in debug mode when debugging/testing the network layer, reaching around 40% load with the occasional spike upwards when new players log in.

Thus we made for ourselves the decision to go a markedly different way in terms of server design.
Our layout has a central connection server which handles the communication between the different zones and the players and one zoneserver per planet (and / or instance). The advantage here is mainly that the interservercommunication between planets is very limited - mainly to chat and travelling players.

This means that the community - or private person out there - will be able to decide whether they want to run a big scaled server with one zone sitting on one machine connected to the other zones over high speed network or whether they want to go for a smaller party server were all zones can be run on a single machine with the option of running only selected planets if this should be desired.

The upside to this is that our network layer has a much smaller overhead both in processing power and interserver bandwidth while it is only truly limited in the size of the outward connection.
The downside to this is that given a huge outward line it will in theory be possible to reach the limits of the CPU. This will quite certainly happen on older low memory machines.

However, the shared distribution approach will have its tangible limits reached in nearly the exact same situation as ours - when we are dealing with huge amounts of players on one spot, whereas its benefits of course are that the theoretical amount of players will be much higher, when the players are evenly distributed over the entire planet.

I hope that you had fun having this first look into our server design and I’ll promise to be back soon

sch