What is bind culling?

So this is the act of unbinding the entities on the client when they go out of range. So if you're too far away from stuff, it basically streams it out, is the idea. There's quite a lot of implications of that for gameplay code, which I'm obviously slightly concerned with, being a gameplay programmer. So it's the type of thing of, if I'm on one side of the universe and I've got to go and kill someone on the other side of the universe, in the game just now you'd normally see a little objective marker, but that's not there because he doesn't exist on my client, because he has been unbound. Or simply if you have a comms call with someone who's too far away, he'll be unbound. Or similar things. And from a more technical standpoint, all our entity pointers themselves will, as soon as something goes out of range, become invalid. You can't talk to that entity anymore because it doesn't exist for you. You can't get his status, you can't get the amount of health he's got, because it no longer exists on your client. And you've got to be able to handle him leaving and then coming back again later on, so if you've got to fix stuff up, and if you've then got to rework your gameplay system to make it work with someone that's just come back. So what are the answers to those things? So for the likes of the markers, they were solved by having an independently streamable object. That's basically saying we've got this little marker, which is a really small lightweight thing. It's really far away from you, but the server's going to tell you that it has to exist on your client because you need to know some stuff about it. It's removed from the normal hierarchy. If you've got a marker, for instance, on a person that's inside a ship, normally you would need to have all these zones all the way down to get him. In this case it's just that marker, and it just gives you the zone position of the biggest zone that's still streamed in, so the planet, or the root zone if he's just in space somewhere.

I'm picturing like when you're playing golf and you pick up your ball and you put a quarter down in its place, so that you know where that thing's supposed to be. The ball isn't actually there anymore, but you know where it's going to be. And when it comes time for you to actually need to interact with it, it's going to know where.

Kind of. And it's also got the advantage that we can do things like, because it's so far away, the position doesn't need to update constantly, because you can't tell if it's 10 centimeters out. So it can update every 30 frames or every 60 frames or whatever, which also obviously increases performance ever so slightly.

That's going to be a big one for server FPS.

Yeah, and we don't need to get the messages from the server as often, so it's not affected. And then once you get in range, once it gets fully bound, everything else has been unbound, so the network performance and stuff. And then obviously there's stuff I'm not as involved in, so the radar scanning stuff has got to be able to work when the stuff it's scanning doesn't exist on your client. So a lot of the game code was changed from everything happens on the client to the client has to ask the server for some results, or it has to push requests to the server for things that happen.