Star Citizen: Pillar Talk - Alpha 3.8

From my standpoint, the biggest one will be AI and the way that the ships feel in combat as well as the FPS in combat. With our server frame rates the way that they currently run, it's basically 7 to 10 frames. When we get it running at 30 frames a second on the server, you'll see a major benefit.

So it's a lot less precise than what the client is, and so they get out of sync, and then you get weird behavior, lag. And so if you get the server frame rate, which our target is 30 frames per second up, then the experience on the client side is better. And a lot of that weird AI behavior that people see, or doors not opening when they should open, isn't actually necessarily a bug. It's just that the server's not telling the client in time to do stuff.

From my point of view, the biggest improvement on the SOC stuff is really going to be the fact that it's going to break us free from these limitations in terms of how many locations and how much content we can put into the solar system. So it's tangentially related to what Papy is saying in regards to, he's talking about the frame rate side of it. The part that I'm saying is, well, now we can get all these new locations without impacting the frame rate at all, because the server that you're on is still only loading what's absolutely necessary for the players that are on your server. And so what this is going to allow us to do is put more outposts, more space stations, more derelict ships... We've had to basically weigh everything from the point of view of, well, what is this going to do to server performance? Because we know every single server, regardless of whether there's a single player there, is going to have to load this. And so we've already been in the mode for the last quarter or two to where we're starting to get very sensitive about bringing in new content, whether we can afford it.

We've been that way since ArcCorp went in. 3.7, we wanted to put at least 100 caves in, and I think we got 15.

I think right now, if you take a look on the servers, I think it's anything like half a million entities. It could be millions of physical entities, and so even with really powerful servers, which we have, that can take more time than we want. So the whole idea of server OCS is that you try to only have the bits you need to be simulating with, and therefore the frame rate should be higher. So our target server frame rate is 30 frames a second. And like you said, currently, with everything overloaded with content, it can get down to five or six frames a second. And that's when you don't have such a great experience, even if you have a high frame rate locally.

And for me, it's on the two different pillar sides that I have. So on the technical content side, the big difference is actually, because we deal with the tools and the developer tools on that side, I think the biggest difference for us will be some internal differences, the turnaround time for us to run. So we're using so much RAM right now on the servers, so to be able to spin up the entire universe on a local dev box, on just a normal workstation, was getting to the point that either one, it took a long time to get that thing loaded, because without server object containers for me, it didn't work like the client did, which was just loading what it needed. It was going to bring everything in. So that took some time. But then additionally, we're at a point that you would just run out of memory. You wouldn't be able to do it. So we even put developer tools in place to be able to exclude stuff from the universe. But that would mean that if you ever had to do testing on any of those ones you've excluded, you've got to shut down, restart up. So basically the developer workflow is going to be a lot better because the turnaround is going to be a lot quicker.

The next stages is using the tech in the editor, also in Squadron 42 for the same reasons, where the level of detail that we're putting into all the locations and the star systems that we have in Squadron requires, you couldn't fit it all in memory and you wouldn't want to fit it all in memory, and the server OCS, which is basically a kind of an authoritative version of the worldview that you can sort of move a viewpoint around and stream in just the bits you need and stream out, it would make a big difference for that.

Yeah, when your iteration loop just takes that amount of time, you'll move things once, you'll move things twice, and then you'll be, oh, it's okay, I kind of spent 10 minutes making that little tweak. But that's what Star Citizen is, we're about that kind of quality, we want that kind of iteration loop. Things like elevators glitching out with you falling through them halfway and the server basically being at a different frame rate. Or ships inside of ships, or when collisions happen. It comes down to a feel thing. Things are responsive. Things are actually feeding back to you when you expect them to. When you hit a guy, he's actually hit. When the ragdoll happens, you see it at the same time. So to me, it's kind of those two things. There's a bit of feel in that, the responsiveness, and the developer workflow. And in the end, being able to load a lot faster.

In theory, it definitely should. I think we're at the point now to where we haven't yet done sufficient testing that we would basically want to definitively say one way or the other. That's certainly what we're thinking we're going to want to be, we're certainly going to be doing tests and seeing how far we can push it. It is possible that as you completely remove one bottleneck, you expose some other things that also need to be dealt with, and whether those would be egregious enough in terms of a problem, or whether you'd be able to quickly patch them up and deal with them and push it out with 3.8 with a player count, or whether some of that stuff would have to move to 3.9, that part we don't yet know. But that's definitely where we're headed.

Yeah, and to explain why that profiling is so important and the real reasoning behind it is that there's going to be a sweet spot for us where it makes a lot of sense to actually have that exact player count, because it has a little bit to do with how players play, where they're going to be positioned within the server. But conceptually you could end up in a state that we've got, let's say, 200 players that are in every single location, every single object container, and it's actually all loaded in the end. But it really depends on how the players are playing. But we will find a sweet spot in here, because there is an edge where we go too far, that it's actually not helping us as much. But I think even in that case, we're still going to be better.

But that's a perfect example of where SOCS is really a building block towards the future in terms of, yes, if you actually had a perfect distribution of players, then you could wind up eliminating much, if not necessarily all, of the benefit of SOCS. The server mesh would eventually fix this by simply going, oh, well, you're over in this area, we're going to mate you to a server that only covers items in that area. And therefore the long-term path will deal with that very elegantly.