Star Citizen Network Rework

Welcome to some more Star Citizen every week I’ll be looking through spectrum and the forums for Dev responses on particular topics this time looking at SC Network Reworks & The Organic Shader.

Server, Client &  Netcode optimization is core to the multiplayer nature of star citizen there was a continuation of a thread we were looking at recently (link below) with a new question from ELEC

Can you also talk a little bit about the upcoming actor networking rework, and how it’ll be in comparison to the current tech? Especially if it helps decreasing the movement and shot delays between players and the forward and backward jumping of ships flying parallel in the verse.

CIG Gordon replied – I can talk about it a bit, I’m the programmer currently working on the actor networking rework. It’s split into two parts – upstream and downstream.

First to clarify what an actor is – in the current game that is any humanoid actor (either controlled by an actual human player or by AI) running around in the verse. It does not effect ship or weapon networking, they’re different enough that they use different systems (though they do all have some common elements/strategies).

Upstream refers to the communication from the local client up to the server:

• Currently the actor movement is client authoritative – this means that when you press the ‘W’ button locally your client moves you forward and then sends the new position up to the server, which then replicates it to all other remote clients. This has a number of issues, not least it being a nightmare for anti-cheat as well as it having an effect on perceived lag (most notably, if someone else has a poor connection you see them teleporting about a bunch).
• We are moving actor movement (and indeed their entire state) to being fully server authoritative – when you press the ‘W’ button locally that is bundled up in an “action” and sent off to a component called the Actor Action Handler. This component replicates this action up to the server and it is processed on both – the local client and the server will move you forward (hopefully the same amount, there’s a whole lot of code to make sure it does) and the position from the server is then replicated to all clients, with remote clients accepting it (same as before) and the local client validating against it (too much divergence and they are moved to where the server thinks they are…or rather were, since by the time it’s got back down he’s likely moved on, we reset and then rerun the inputs since the frame we were reset to).
• There are a bunch of new complexities with all of this – we have to do our best to not miss any actions, we have to take into account the time it takes the actions to get up to the server, we have to appropriately deal with any divergence between client and server and we have to have methods of mitigating lag.
• The most obvious user facing improvements to this will be improved validation and slightly improved experience when facing players on a poor connection. For the validation, since the server is fully authoritative and can tell us exactly when something has diverged we can better cope with that – the previous method was very susceptible to poor server framerate or network latency, manifesting most obviously with the mobiGlas flicking open and closed rapidly, or ladders being a bit clingy (those changes have already made it back into the main branch actually, expect them in 3.5). For playing with/against players with a poor connection you will see them teleport around less, though on their own clients they will rubber-band more as the server corrects them.
• For the most part, think of this as a change that has some minor improvements but is mainly just a precursor to the next part.

Downstream refers to the communication from the server to all remote clients:

• Currently to smooth out actor movement on remote clients we artificially inject a 250ms delay into all their movement processing – being able to see a quarter of a second into the future allows the various movement and animation systems to give a better visual result, and having that buffer mitigates the problem of lag spikes.
• For us, this is not really a sustainable solution. Everything being 250ms out contributes to the game feeling laggy and is an overwhelming factor in the “movement and shot delays” you mention.
• The plan is to reduce this rewind amount significantly to something sensible (hopefully around ~2 frames instead of 15), with improved dead reckoning and state processing helping to cover over the visual impact of this.
• Another factor of this will be remote client patching that is already implemented but needs some tweaks (and bugfixing…) before going fully live. This means, for example, when I kill someone on my client I can temporarily take control of that remote actor to immediately play a hit/death reaction. Since you tend to be looking directly at someone when you kill them any latency on them playing the reaction is very noticeable, so removing the need for the hit to go up to the server and then come back down reduces the perceived lag significantly. Obviously, if the server disagrees with you (you didn’t actually hit/kill them) then it will be undone on your client, though this should only happen in cases of extreme lag or cheating.

We have been planning and working on this rework for quite some time, and have confidence that it should improve things significantly.

Better Server/Client Reg, less teleporty more smooth characters, with less lag and better animation responses has been well needed for a while now, certainly for the immersive polished experience that SC eventually wants.

They will continue to improve server and client optimization in regard the systems and features using less resources, what data gets sent & saved, to both get more players on a server and for that to be a good looking experience.

 

There was another thread by Marc_FC – What is exactly the organic shader?

What improvements will bring to the planets? Will be released on next patch? (3.5)

Divi from CIG Responded

1) mostly nicer looking rocks that better integrate with the terrain  

2) with the “Distribution and Ecosystem Improvements” on the horizon, the redone assets on the planet surface with the new shader are planned to be released in tandem with the improvements, as the shader will benefit from data that comes with the improvements to realize it’s full potential. so no, even though the shader will be close to or at to it’s final iteration with 3.5 internally and having a barebones version with a different featureset already being in use for mineables, it will not see a widespread use with 3.5.

Naming can be somewhat confusing as it is mostly to differentiate between “solid” organic objects formed naturally and “solid” machined objects made from metals and plastics that use the hard surface shader. it is unlikely that it will see much use for plants as it’s features do not really bring much benefit for them.