We hear a lot about client frame rate and server frame rate. What dictates a server frame rate, and how can that affect [the client]?

So there is not a clear lock point. I mean, that's not my area of ownership; that's the area I'm the very first close neighbor to. I don't believe that we have a very, very specific lockstep where this is what locks the client.

Right. The client frame rate is usually the rate at which you're refreshing the graphics and so on. So on the server side, on the DGS, as we call it, that's the simulation rate, and they're not locked together.

Yeah, absolutely. I know a lot of players are concerned with the FPS. First of all, I want to thank every single person who plays PTU and all the amazing people who play Evocati, and the great people that I woke up during the night, like, hey, I have a new combination I want to test, and people calling each other and coming online. This is amazing. I couldn't have imagined this was even possible. In my interview a year and a few months ago, I was asking, how do you guys test? It's like, we use people. Like, what do you mean? It's like, our players are awesome. You just say you want to test that, and you'll find people coming from nowhere. So what you guys do at PTU is define pain points that should be addressed. Optimization is a deep rabbit hole where you always need to be worried about premature optimization. But also we have a product out in the market that you guys are playing, and we want to make it playable and fun. What I'm trying to do, with my team and with the guys working in Frankfurt and the guys working in the UK and over here and in LA, is to point them as much as we can to that main pain point, like, oh, if you spend some time on this, we might get some advantage. But what we have right now is nowhere near what we would deliver. We have so many tricks in our bag that we know it's not the right time to bring in. But we really need to care about, yeah, you guys were suffering that much and we enhanced it 10%, 5%, 7%; it's still livable. And we're still keeping an eye on what's going on. And also, sometimes we are not willing to enhance anything right now, but we want to see: did our new code logic or complexity tax us a lot? Did it become very expensive or not? So thank you so much, guys, for all the amazing work you do testing PTU.

Yeah, there's RAD Telemetry profiles being generated all the time, and that gets disseminated to each of the teams appropriately. People will have on their radar what is most expensive on the game servers as well as the client, and just tackle it at the right time. But there's just so many features going into the game. Like I said, premature optimization: once you start optimizing code, it looks a little different than normal.

Right. And there's a wide range of things that we can optimize. From the client side, you're going to have things from rendering, you're going to have client-side simulation, and also you're going to have network latency. Then on the back end, there's all the physics and all the other things that happen there. Then there's also things where the game servers may rely on responses from the services. So there's a wide number. We don't want to pre-optimize now, but we optimize certain things over time, the low-hanging fruit and such like that. There's so many different departments that are going to focus on their little areas, but we have to focus on them at the right time. If we pre-optimize now, we could end up painting ourselves into a corner later.