Again, because of the latency issues in dealing with a game like Star Citizen, especially considering the internet use, lockstep is not being used

Another way of optimising is to decrease the distance on which an entity is visualised and thereby reducing the amount of tracking.

Often multiple approaches are used in unison to increase and optimize performance through good resource management.

Tech art and tech content tend to focus on the GPU budget of 2500 draw calls, and try to use LODs, detail meshes, and skinning to reduce the number of draw calls.

Damage tech is being reworked to have less debris, and therefore less extra geometry. This reduces the number of draw calls required.

Another trick to limit draw calls is vis areas and portal culling - this essentially is only having the game render what you can see. They are currently fighting some significant bugs with this as seen on the Caterpillar where you can frequently see through the walls.

Another improvement is moving from using voxels to using signed distance fields for local physics grids. This is much more precisely and the actual shape can be described in much higher resolution. This will allow for much more ship-hugging shield tech.

Signed distance fields are also the first step in allowing ship wrecks to be fully accessible and therefore salvageable and explorable.

Network code on the server has been a big performance bottleneck. The main thread will get delayed because the network thread is too busy trying to send updates to all of the players in the game, causing everything to slow down or stall.

3.0 included a lot of optimisations for network code including conversion to serialized variables and remote methods.

The overload of network instructions on a single thread has now been parallelized onto multiple threads.

Network code has never really been a performance issue on the client side - the issue has always been on the server side.

Bind culling is intended to address this mismatch.

Essentially bind culling will mean the client will not load entities for which the player is not in range and therefore will not spend any CPU processing time on them and will not get updates from the server about them.

The issue, and why bind culling has taken so long to implement, is what to do when a player does go in range of an entity which the server has not been updating. How do you create the entities without causing the game to slow down massively?

Object container streaming is the answer to the bind culling issue - needed entities will be predicted and loaded on a background thread so the main thread is not halted while trying to do so itself.

Full implementation of bind culling won’t be coming to the player until object container streaming is in the game but bind culling is needed beforehand for the developers so that they can work to eliminate all the problems it can cause - such as how do you point a player to a destination for a mission when that destination does not currently exist in the game (due to being culled out).

A lot of the performance gains that were anticipated with bind culling have been able to be achieved with serialized variable culling which essentially just tells the server to stop sending updates to the client about entities which are not within a certain distance of the player.

When designing a game like Star Citizen, it becomes more difficult over time to optimize and improve performance as it’s being built due to the complexity and ambitions the game is trying to achieve.

One of the issues developers have had for awhile was not only trying to simulate a proper load on the server, but also get enough QA and other devs to participate in internal playtests.

With 3.1 they’ll be introducing two new tools in order to improve the data that’s being captured and be able to seek out where the performance hits are coming from.

They’ve designed headless clients which are able to simulate the random player actions in a server, and multiply that by the server player count. This allows developers to quickly populate a server internally and get a more accurate idea of what the server load will be like on live.

Secondly they’ve designed a tool that is able to capture data more accurately than before and give them detailed information on the specifics a player is doing instead of getting a log of data that has to be combed through to get to what they actually want.

When it comes to new features coming online, there usually is a performance drop, but with the new tools they should be able to quickly get performance back to the level players found acceptable and improve upon it.

With Star Citizen if they built the game as a regular studio where they didn’t have to have a playable build throughout development, and only polish it a few months beforehand then production would be way different, but because they took the approach they did, there’s a level of complexity involved in order to make the builds playable, while continuing development.

As Mark Abent puts it, there’s no one solution to fix all the problems, there’s billions of possibilities that incrementally improve performance and stability over time.

The consummate English gentleman, Shiver Bathory can be found posting news to The Relay, when not making puns that is.When not typing furiously at his keyboard he enjoys hanging in chat with The Relay community and every once in awhile can be found playing some game or another. Every Wednesday on The Base he hosts Dead Air - An alternative and extreme metal music show