Server Cluster

Instead of being a single server application; Professional now works as a multi-server scalable cluster to improve zone performance and distribute players across physical hardware. The server is split into the following applications:

Master Server – Manages all other servers by monitoring the cluster status and performance as well as distributing zones and players across other servers. Provides an interface for developers to manage the cluster remotely (see Administration section).

Zone Server – Updates zones, players and scripts including general interaction, combat, NPCs, etc.

Account Server – Loads and saves player data using a custom account script, handles players at the login and character creation/selection phase.

Proxy Server – Accepts and directs physical client connections to the cluster and redirects packets to their connected internal servers (see below).

This new structure introduces a ‘proxy’ element which is designed to both protect the internal servers from public access and to remove the need for a client to continuously reconnect and authenticate with a server whenever he changes zone. In order to help visualize this, here is an image of how a medium-large ‘realm’ cluster would be setup:

Servers can be added as either game content grows or concurrent players increase. Multiple account servers are allowed, though less are required due to players only spending a small amount of time connected to them.

When a player is connecting to the cluster, the Master Server will direct him to the least burdened Proxy Server. Similarly, new zone instances will be spawned the least populated and least encumbered server. When an actor enters a portal (or is warped via a script) his data is packaged and sent to the new server with the change happening on the internal network; thus making a seamless change between internal servers that is completely unnoticeable to the player.

The ‘Statistics Connection’ is used by all the servers to send important information related to their performance to the master server for the purposes of balancing and reporting to administrators. Because of this, each server application has no specific interface, only a console window. Additionally, the server will run using Mono on Linux operating systems (with only shell access required).


Several server applications running with Windows Server and Ubuntu.

Network Based Spatial Partitions

In order to improve network performance, virtual partitions have been created in zones. Each of these ‘sectors’ is 768 units in diameter so that the view range never exceeds two whole sector lengths. The server keeps track of every player and actor by the sector it is in rather than the zone it is in; this means that any data sent to other players (such as movement, combat, spawns) are only sent to those close enough to see it. This change will see that bandwidth consumption is dropped massively over large zones which have ‘pockets’ of population rather than a low distribution. The savings here will also become more apparent when MegaTerrains II is implemented, which will allow larger zones that might feature more than one heavily populated location (more information will be posted in a further announcement related to this).


This image shows a large zone (in the green areas), but the only actors the client is aware of are within the view area. As he moves, new actors will be created and old ones destroyed; keeping overall bandwidth down to just essential data.

Remote Administration

With a distributed server cluster, a central administration system is required in order to monitor all important aspects of the game at one time. The Master Server features a built in HTTP based Web Server which provides an AJAX based administration site to developers/administrators. It features the ability to view all active servers and their performance statistics; all active zones and zone instances arranged by their current ‘Host Server’ and player counts; a 24 hour log of average bandwidth consumption (TX/RX and Total); a 24 hour log of player counts and a log of script exceptions.

The bandwidth and player graphs can be viewed per individual proxy server or globally.

Script Exceptions should never occur, or at least be very rare for a live game; however, they can and probably will happen. When any server in the cluster hits an exception in a user-script, the details are all sent to the master server and kept in a central log for developers to assess and repair. Screenshots of this in action are visible below:


This announcement marks the first milestone of 2.50; the longest and most difficult. We now have our new working server and scripting language ready to make the fixes which had to be deferred until this version and we can start adding other features which people have requested. Further announcements/worklogs will be posted soon with information on new features and a more in-depth look at scripting customizations.