Hello Paxians,

We're amazed every day by the beautiful structures you've built since our first Alpha, the building system is one of the most highly engaged in Pax Dei so far. As such, we thought you might be interested in knowing a bit more about the tech behind the system - which is probably one of the most complex systems in the history of video games.

Currently, the hottest home valley zones have around 400,000 building pieces. With a total of 24 home valleys per world, there are many millions of pieces in each world. The typical build rate is 10,000 new pieces per week in a single home valley.


In a networked multiplayer game, the replication system is used to ensure that all the players have a consistent and up-to-date game state. In other words, It receives the input information of a player and distributes it to other players.

The building data size for a single home valley is currently around 30MB. That doesn’t sound like a lot, right? But let’s say we have 100 players - we are now talking about 3GB of data that needs to be managed by the server, the client (the player’s machine), and our replication system.

This amount is so massive that it needs very special handling in all stages of the game’s pipeline. If we use Unreal Engine replication for gameplay, we can’t use it for the buildings. The backbone of our building replication is the Repli backend server - aptly named ‘Repli’ - which sends build data from the world database to the clients and the servers.

When logging in, both the client and the server connect to Repli, which first sends the current full state of the zone. As we said, initial data is currently around 30MB in the largest zones. After the initial state replication, the client and the server listen to new build events from Repli. We use gRPC streaming as a communication channel to build events from Repli. We won’t go into detail about gRPC here but, simply put, it ensures all parties involved, the server, Repli, and the clients, communicate correctly and understand each other.


Here is simply what happens after a player swings their construction hammer:

1. The client sends a build request to the Unreal server;
   
2. The server does some permission checks to verify if the build request is allowed;
   
3. If the server allows it, it then sends the build request to the backend;
   
4. The backend does its own checks to allow or refuse the build request;
   
5. Once allowed, the building piece is added to the main world database;
   
6. The build event is sent from the database to our custom Repli backend server;
   
7. Repli will send the build event to both the server and the client;
   
8. The server and all the clients in the zone - here, the Home Valley - spawn the building piece;
   
9. The server does the integrity check that the structure still holds;
   
10. The client calculates integrity as well to display it in the UI.

Massive data replication is one of many challenges. After the client has all 400,000 pieces of the home valley, the 30MB package we discussed earlier, we need to make them visible. Your computer must draw them, and here comes the second big challenge.

It would be impossible to use a system that draws 400,000 pieces one after the other. We need something tailored to suit our needs. The two key elements we use are instanced static meshes (ISM) and area managers.

ISM are used to draw several, even thousands, of pieces in one draw call, instead of drawing them one by one.

Area managers, the parallelepipeds boxes in the video below, control all props and building pieces in their areas. They handle the creation and destruction of building pieces and props, integrity calculations, and other things, including the ISM.

The area managers look at all the standard building pieces in its area - not the crafters nor the containers - and sorts them spatially. Then, they insert them in custom instanced static meshes. And now the magic can happen.

That being said, we are not done yet. In addition to buildings, we have containers, crafters, and decoration pieces that need to be drawn, and most of them have their own gameplay functionality. All these props are standard Unreal actors, but contrary to the buildings you can see from pretty far away, they spawn only around the character inside the streaming distance.

In the video below, you can see how the area managers are working and how the props become visible or not. Each box you can see is an area manager. As explained above, each area manager controls its own area for ISM and integrity, but they also control the visibility of the prop actors - crafters, containers, and other decoration pieces. Depending on the position of a character and the streaming distance of its client, the manager will activate or deactivate the visibility of all its prop actors.

In the video, red shows the area managers that deactivate the props’ visibility and cyan the active ones. Purple shows the ones pending ongoing activation, and magenta the ones pending ongoing deactivation.

There is another type of prop that needs special treatment: lighting sources. When your character is close to them, the lights are running through the Unreal Lumen lighting - the dynamic global illumination system from Unreal Engine 5 - to improve immersion. However, the lights are switched to lightweight light cards at a certain distance to improve performance. Some valleys have more than 20,000 lights that you can observe simultaneously!

Of course, we also have some constraints on the server side. One single Unreal Engine server can handle only a maximum of 150-200 players, and if more players want to be in the same village, then we need to create some server instances. That’s another area where having some custom systems helps a lot. Our replication system allows the buildings to be visible across all the server instances and in real time! If one player builds in one server instance, then all the players in the other server instances see the building changing at the same time.


Spawning all this building stuff around the player without visible lag is complicated and is done over several seconds, even minutes, sliced into many frames. Also, as you might have guessed from our step-by-step process above, the integrity calculation is a very complex process. Our servers also stream world content, so integrity calculation needs careful setup so that all supporting landscapes are there before they even start. Creating only physics states for pieces needs to be done without delay, and after that, querying overlaps from physics and actual integrity calculations need to be done iteratively.

Now you know why when logging in, you often can see the landscape first, then the buildings, and finally the props.

Players have been building much faster than we initially anticipated. The whole system has seen many optimization passes so far, and we still have many tricks up our sleeves. The current system should work fine until around 500 000 pieces. After that, we will start seeing new issues that must be solved. Good news, though! We already have plans to scale the system to 1 000 000 pieces per zone. But, that is a story for another time.

In the meantime, you can keep building and follow these tips [discord.com]from players who have mastered our systems and environment to create gorgeous structures!

Pax vobiscum,
The Mainframe Team

We know combat hasn’t been the strongest aspect of Pax Dei so far, but we’ve been hard at work behind the scenes, almost starting from scratch, to establish the foundations for a solid and dynamic combat system going forward. While this next content update will introduce some exciting additions, it’s just the beginning - significant improvements are on the way.

Creating a game like Pax Dei requires an iterative approach, and this is particularly true for combat. More updates will follow as we continue to refine the combat system.

With that in mind, let’s dive into some upcoming changes in the next content update.


First off, moving around the world will feel smoother. One major change is that running, not walking, will be the default movement speed. Currently, when your character is idling a bit, their movement is changed to walking instead of running.

Of course, we will keep the run/walk toggle - and the ability to sprint. And for those who prefer the current system, there will be an option in settings to re-enable it.

Additionally, swimming will be less taxing, as we plan to reduce the stamina cost for moving through water.

Last but not least, falling damage will be refactored to ensure consistency so you can better predict how much a fall may hurt.


Melee combat is receiving a lot of love. 

When engaged in combat, your character will automatically face a target based on the direction you're looking in. Moving and rotating toward enemies during combat will allow for smoother movement in combat and target changes.

As part of improving responsiveness, we’ll also add a bunch of new early exit conditions for melee attacks. You’ll be able to interrupt your melee attacks by taking other actions like spellcasting, blocking, jumping, or performing special melee attacks. Most will only be available during the anticipation phase of the attack, but performing a special melee attack allows an animation to cancel from a regular melee hit directly to the special attack.

Many weapon animations will be retimed or remade to improve responsiveness and add forward momentum to attacks, making it much easier to hit moving targets with your attacks. You will also be able to aim attacks up or down to strike enemies at different elevations.

Hit detection will also be improved to better match actual weapon motion. For example, spears will deal damage in a line-shaped zone, while great axes will strike enemies in a circular radius, making the weapons feel more distinct.

Right now, it can be very difficult to hit fleeing animals and even frustrating. These changes should give a better feeling while hunting animals… and players. And speaking about PvP, we also consider testing a significant change where characters will be slowed down for a few seconds when hit by another player.

Additionally, blocking will come with more meaningful consequences. Holding the block button will prevent your stamina from regenerating (though food and potions will still work), and it will also force your character to walk, adding a bit more tactical depth to defensive play.

Equipping / unequipping items will be much easier thanks to an added input queue system that delays the equip action until it can take place. We will also increase the number of possible actions that can happen simultaneously with equips and unequips.


For spellcasters, spell targeting will be reworked to be much more accurate, and the target will remain displayed during the entire casting process. This change ensures that you’ll always know whether your spell is aimed at the right player or enemy in case our improved targeting fails you.

Similarly, as with melee, spellcasting will be given a responsiveness pass to ensure the player always remains in control. You will be allowed to cancel spellcasting at any time during the spellcasting phase by moving, jumping, melee attacking, blocking, or equipping something else - allowing you to pre-cast spells or adapt to changing situations mid-battle.

Spells will also have casting bars to make it easier to read what spells your opponents use in PvE or PvP. This will allow you to make better decisions over which spells to interrupt.

Plus, we will add early-game spells, unlockable from loot in small PvE camps, offering more options to small groups and solo players.


Many enemies will have their attack animations revisited, making it easier to anticipate their moves. These changes will add more telegraphing before attacks are performed, giving you a better chance to react.

Several user interface improvements will be made to give players more information during combat. Both enemy and player nameplates are going through changes to be more informative.

Enemy nameplates will indicate how powerful they are. The current implementation, as you can see in the video segment, shows their ‘level’ - which is somewhat ironic in a game where characters don’t have a level, but it is a first implementation on which we need to iterate. The goal is, of course, to help you assess whether you can handle the fight or… flee. The color of their health bars will also reflect if they are neutral or hostile.

These new nameplates will also be used by players and will be more readable in PvP, indicating at a glance whether an opponent is friendly or hostile.


We’re also making significant updates to the camera system. Camera collision events have been smoothed out, reducing the “jumpiness” you might experience when some objects block your view.
Additionally, if the camera gets too close to your character, your avatar will fade out to prevent your view from being blocked - and yes, this feature will also be present in the building mode.
Finally, we are adding camera smoothing to the melee system to handle sudden character movements during combat and make it more immersive.

On the audio front, we will add distinct audio cues for when your stamina is too low to perform an action and when you level up a skill. We’ll also add more grunt sounds for chained and combo attacks.
NPCs will also have more grunt variations, reflecting their health status and adding personality to the encounters with the Cultists of Zeb and the Inquisitors. We’ll also adjust the overall sound mix to improve clarity.
Looking Ahead

These changes are just the beginning - as you can see, we read your feedback, and we’ve made changes with your thoughts in mind, as well as our own experience and vision for the game. The next content update focuses on making combat feel more dynamic and responsive, but there’s much more to come.

As we continue to improve Pax Dei, we’ll work on role identity, balancing all spells, and making gear choices feel more impactful, especially when playing in groups. Expect more updates in the future as we polish these systems even further.

We’re looking forward to your feedback once the content update has been deployed to the live shards.

Pax vobiscum,
The Mainframe Team