As you may know, the World of Pax Dei consists of a few regions (Gallia, Anatolia, Gothia…) split into several provinces (Ancien, Merrie, Kerys…). A province is a very large geographical area with several valleys interspersed by big mountain ranges. In specific provinces called heartland provinces, we have multiple valleys we call home valleys, and those are where you can build your home. And, of course, you also have dark dungeons and caves that mainly exist below the surface of these provinces.

But how do these geographical features map down to actual physical servers, and how do they affect how you play the game?

Worlds/Shards

The first choice you will face when creating a new character in Pax Dei will be the selection of a specific instance of a World, also commonly referred to as a Shard. Even though the world of Pax Dei is geographically vast, it can only accommodate a certain number of players in total. This is why we run multiple copies of the world, each being identical but completely independent of the others in terms of actual inhabitants. Each such copy we call a shard.

We estimate we’ll start with a maximum population in a single shard of around 7,000 players. A single shard is run wholly within one physical cloud hosting center. We will run shards in different availability regions worldwide, e.g., North America and Europe.

The factors that will mainly influence your choice of shard will thus be the following:

Latency to your main game computer
Seat availability, as some shards might be full
Shards where you have many friends already playing

Zone Servers

From a computational point of view, a shard consists of a large collection of various servers and cloud services, each of them fulfilling a specific function. The most numerous ones are what we call zone servers. This is because the simulation of a whole world is much too computationally heavy to be handled by a single hardware instance and is thus divided into smaller computational units that we call zones. A single zone server is a Dedicated Unreal Server that handles the simulation of a specific part of the world, e.g., one home valley.

At any given time, you, as a player, are automatically connected to a zone server. Whenever you move across a zone boundary, your connection automatically moves to the adjacent zone server. This is what we call a zone transition. In most cases, these transitions should be seamless, except for a few important exceptions:

Transitions between different provinces or into dungeons will typically incur some loading time as the client loads an entirely new map
There is currently no visibility of other players or NPCs across zone boundaries

Zone Instances

As mentioned above, a zone server is a dedicated Unreal Server handling the simulation of a small subsection of the world. Eventually, a zone server can also become overwhelmed with too many players. Currently, this limit is around 150 players, but it is expected to change with better hardware and optimizations. To avoid having to close off zones when the maximum number of players is hit, e.g., during peak hours, we introduce the concept of zone instances instead. The mechanism is such that when we surpass the maximum number of players in a zone, we distribute the whole set of players within a given zone boundary between two or more separate instances of the zone. Each zone instance is actually running a separate zone server for the same zone, but players within a given zone instance can not interact with players in another instance.

This separation only applies to direct player interactions, but the persistence of the buildings, amongst other things, works across instances, meaning the buildings are visible to all. Once the zone population levels go down, instances merge together. For regular operation, after a shard has reached maturity, instancing should only happen in exceptional cases, but it might be common at the beginning.

Persistence Backend

Apart from zone servers, the rest of the backend handles coordination between zone servers, transactional game logic, communication, and persistence. There are situations where the clients connect directly to this backend through secure APIs, e.g., for authentication. Still, in most cases, the zone servers are the ones communicating with the backend to specific services such as inventory service, resource management, etc.

All of this infrastructure is then deployed, coordinated, and scaled through a Kubernetes architecture running on top of a cloud infrastructure.

Frequently Asked Questions

Pax Dei Launcher