Backers have taken to referring to all performance-based issues as netcode issues. How crazy does that drive you?
TL;DRClive Johnson is livid at the netcode label; he explains that multiplayer performance load comes from entity counts growing rapidly with clients, spanning networking, game code, physics and graphics, with the server bottleneck having been networking code.
Absolutely livid.
That's why he's got no hair.
Yes. I had long hair when I joined the company. Not anymore.
What can we say to help dispel that? Obviously, we all know that there are performance issues. We see the same frame rate that our backers see when they play. What can we say now to educate folks that what you're seeing is not just a blanket netcode issue?
Okay, so saying that there's performance issues in multiplayer is fine. To then pin it on a particular part of code and say, well, because it doesn't happen in single player, all the code that you can see running in single player must be fine, is a bit of a leap, because basically you have different quantities of entities that we're dealing with between single player and multiplayer. So you'll have, I'm not entirely sure how many entities we've got per player, but say 20-odd entities per player for each client that joins, and then they'll spawn a ship that could be somewhere between 100 to, I think some of them get up to like 5,000 entities, and then they'll go and fill those with cargo, which is more entities, and they'll fly off and they'll interact with pirates and task givers, which are more entities that get spawned, and there'll be debris pieces flying off. So the number of entities grows very rapidly with the number of clients, and that's what causes the performance load. So if people want to call that netcode, then that's fine, but it's not the networking specifically, it's the networking and the game code and the physics.
Graphics and everything, yeah. It's really just every module and every engineering department really has to take a responsibility for their own performance that they achieve in game. When we've been profiling this stuff, you tend to find that almost no engineering department can ignore performance. We get the UI guys, the AI guys as well, the audio guys. It really is shared across the board. And it might be that, say, UI do really great optimization, and then all of a sudden the next biggest hitter on the list is the audio guys, and then it might be the graphics guys. From time to time, unfortunately, things can unexpectedly crop up, and all of a sudden we have to jump on those, fix that, and then get back to bringing the average frame time down, improving things.
I think as well, there's been a bit of miscommunication in that for a while we've admitted that the bottleneck on the server was the networking code. And I think that's been misunderstood a little bit, that it was the bottleneck everywhere. So maybe that's partly responsible.
Yeah, it's one of the reasons why we had wanted to have you on Happy Hour at the beginning of this year. But as I delved deeper into everything that was going on, we realized that this is far more than just netcode and networking. We wanted to do a much more robust feature, and that's what folks have hopefully seen on ATV yesterday. Performance and optimization is a task that affects almost every discipline in Star Citizen. So it will be all teams working in conjunction to bring Star Citizen to the 60-frame heaven that we're all aspiring to.
Yeah, and the other thing to add as well, of course, it's not just us engineers. If a designer wants to drop 2 billion entities in a level, then performance isn't going to be great. If an artist wants to model an apple out of a trillion polys and then place it on a table in an outpost, then again, it's shared company responsibility, really.
Somebody once told me that the original Freelancer model, the one that had all those crazy rivets, because the rivets were created incredibly poorly, to be honest, had a larger memory footprint than the Idris. And that's definitely not network related. It's one of the reasons we go back and we revisit these ships, not just because we want to change them for gameplay purposes, but sometimes we just need to seriously optimize the way they were built. We've gotten much better at building these ships as time has gone by.