Star Citizen, Squadron 42 & Theatres of War News, Guides, Videos & Gameplay by BoredGamer

The Road To Star Citizen Alpha 4.0

We had a Juicy SERVER MESHING AND PERSISTENT STREAMING Q&A from CI where they talked all about this core technology and the current plans and timeframes for it and went into some detail about what it will enable… this is a summary of that billegerantly large post.

When will we see Persistent Streaming and Server Meshing in the PU?

Our current aim is to release Persistent Streaming and the first version of the Replication layer, ideally, between Q1 and Q2 next year. We’ll then follow up with the first version of a static server mesh, barring any unforeseen technical complications, between Q3 and Q4, of next year.

What is the current state of the server meshing tech and what are the biggest issues holding it back?

The short answer is the state is actually very advanced. Tho there are lots of steps.

The road to Server Meshing started back in 2017/2018

And to date there has been completion for Object Container Streaming (working out what entities to stream in and out efficiently), Entity Authority and Transfer (allowing server to take a pass authority between each other seamlessly).

The Replication Layer and Peristent Streaming is ALMOST  complete and in it’s final stage. This has them copying states on multiple server nodes as well as accessing a database that stores every state andn using / passing data between them.

This will then lead them to Static and then  Dynamic Server Meshing with at least the static part being planned for completion later in 2022. This has areas of space & Planets being their own servers that seamless pass data between each other… dynamic server meshing has servers spin up in down based on population of an area and any room or ship can potentially be a server.

With Dynamic Server Meshing it’s possible that large ships like a Javelin could have a dedicated server handling them. However that might not always be the case (as CI are avoiding inflexible rules). It will be down to efficiency and is it necessary aiming for a sweet spot so that “no single server is overloaded or underutilized” at any time is the idea.

CI did say –  If none of the existing servers have enough spare capacity to handle an increase in load, we can simply rent more servers from our cloud platform provider.

How many players will be able to see each other in one space? What’s the maximum you are planning?

We’re aiming to increase our player count and our expectation is that we will support scenarios where 100 players can see each other at reasonable framerates. However, as we start scaling our shards to support higher player counts, the likelihood that every single player within a shard can go to the same physical location and see each other without performance issues will decrease. 

This is where we will need to start implementing game mechanics that prevent these scenarios from happening too frequently.

The absolute limit is hard to predict until some of the new technology comes online and we can start to measure performance.

CI said – Don’t expect player counts to increase much with the first version of sharding.

Is the true end goal one single shard for all players?

This is our ambition, however giving a definite answer is not possible at this point.

They will start with many shards per region and then slowly reduce them with a goal of 1 shard per region.

Once they have that optimized they will try to merge all regions together as a global mega shard. However this may be prohibitive based on latency and technology.

The Economy will be global and reflected in each shard at realtime.

You will be able to play with friends in other regions, or at least they do not plan to limit you from doing so.

What is copied between shards?

They share databases but not necessarily states at runtime. 

Some features, such as player outposts or minable resources, implement special code that will replicate a global state to all shards, so an outpost may exist in multiple shards in parallel and slowly (relative to the speed of real-time play) replicate its state between shards. This isn’t an instant replication (a door opening/closing will not be replicated), however, a persistent state like a door being locked or unlocked may be replicated between shards.

Each shard has a unique version of a minable rock BUT the overall amount will be replicated between shards, so when players start to mine a certain area, the global resource map for this area will be modified and the number of minable rocks in that location will be affected on all shards.

If I make a base on a moon, will my base be reflected on the other shards that I am not on?

Claiming land for your base will claim this land on all shards, and we plan to replicate your base to all shards.

However, only one shard will have an ‘active’ version of the base, with other shards spawning a ‘limited access/read only’ version of that same base. For example, a base will give full access and the ability to expand in the shard the owner currently plays on, while on all other shards, this base may spawn with locked doors in an immutable state. The full design is not 100% established yet and may change though.

Can an asset as small as a bullet travel across server shards?

No, tho something like a missile can travel between multiple server nodes.

Bullets are actually spawned client-side. So, a unique version of the bullet is spawned on each client and server node.

What will prevent large groups of “blues” and large groups of “reds” ending up in echo-chamber shards?

Players will not be permanently assigned to shards as the matchmaking system assigns a new shard for the selected region on each login.

In the future the matchmaking system will help match players to shards based on multiple parameters, friends, reputation and various other stats, that will help them have a semi-diverse collection of players.

Will your character and ship always be in-game when you have logged out?

When you log out you and your ship will persist in the shard you were in until there are no players nearby and then automatically stream out and travel with you to your new shard when you log in.

If it gets destroyed while you were logged/logging out then you’ll wake up in a med bed.

Items that are on the floor on planets will stay there BUT might not be on YOUR shard when you return.

How much is new content dependent on Server Meshing now?

While Server Meshing will allow us to start to scale up the number of players who can play together in Star Citizen, it will also enable us to start adding new content experiences. Right now, we’re focused on using this to add new star systems.

Designers can use this tech to have larger, more interesting areas (such as larger settlements or large ship interiors) with denser numbers of AI and player characters. Server Meshing could open the doors to gameplay experiences that our designers have not even thought of yet!

The biggest gain will be server performance. Right now, our server performance is pretty limited due to the sheer number of entities that we have to simulate on one server. This results in a very low framerate and server degradation, causing the client to experience network lag/rubber banding and other network desync issues. Once we have even the static mesh in place, we expect server framerate to be considerably higher, causing less of these symptoms.

This will have little impact on client fPS tho however network lag will be significantly reduced.

Ping and Tick rates will be improved as the number of locations a server is looking after will be reduced. All the services are being built with these efficiencies in mind.

What will players experience if a Replication Layer is shut down/’dies’?

The client will remain connected to the shard but part or all of their simulation will temporarily freeze. The Replication layer will spin up a new replicant node to replace the one that crashed and will recover the lost entity state from persistence via EntityGraph. The client gateways and DGS nodes that were connected to the old replicant will re-establish connection with the new one. Once everything is reconnected, the game will unfreeze for the affected clients. At this point the client may experience some snapping/teleporting of entities. We’re hoping the whole process will take less than a minute.

The Hybrid or other server may crash, in which case you may be booted to menu but should be able to jump back in where you left off.

Boom that’s it for your summary of that Server Meshing Q&A… I am happy to see CI really starting to nail down answers to some questions and I felt this was a lot less vague than previous Questions they have answered which is good.