Back to search

Why is serialized variable range culling less problematic than network bind culling? To me they sound very similar.

TL;DRSerialized variable culling keeps entities loaded on clients, whereas bind culling unloads them and would cause loading stalls, so bind culling was dropped from 3.1 as a gamble, with game code assumptions also needing fix-up work.

Clive JohnsonLead Network Programmer, Foundry 42

Yeah, it is very similar. The only difference being that with serialized variable culling, the entities themselves are kept around on the clients. With bind culling, the binding part is effectively creating the entity on the client, connecting it to the network, that's the bind part, and letting the server know that this entity is available to talk to on the client. [Keeping] the entity around, we solve that problem. We don't have to get rid of the entity itself, which means that then the data for that entity is loaded in on the client. So what you could have is a situation where you've got a ship, you're at Port Olisar, you're watching a ship quantum travel away. So if we're bind culling, that ship would be unloaded. You'd potentially lose all the data files. And then if it quantum travels back, you'd have to load those data files in again and respawn that entity on your client. And that will cause a loading stall at the moment. So the reason that we haven't gone with bind culling for 3.1 is because we don't want players to experience additional loading stalls beyond what they already do. The reason it was on the 3.1 roadmap was because we thought, what the hey, we'll give it a try. We'll see how bad it actually is. But in the process of working towards 3.1, priorities have changed a bit, and it was always a gamble, as I say, whether bind culling was actually going to improve things or make things worse. So we decided that we'd shift focus and make sure that serialized variable culling was in and working, and then assist with the different optimizations that are being done.

Rob JohnsonLead Gameplay Programmer, Foundry 42 Wilmslow

Yeah, from the game code perspective as well, what you always tend to have in engineering is you can't help but have certain assumptions as to the way things work. And if all of a sudden we've got entities that were once there, albeit the other side of the universe, and now they're not, then by the nature of the fact that we have so many tens of thousands, sorry, hundreds of thousands, millions of lines of game code, there's going to be places where people have assumed once an entity exists, it's there, it's not being pulled in and out depending on whereabouts you are in the server. There's going to be fix-up time that we're going to have to work our way through.

Reverse the Verse›LIVE - Performance and Optimization·
Published on this date.9 Mar 2018