In terms of bandwidth required for the game, how good do you plan to make the netcode in Star Citizen? Is it going to be rather lean or will it be more taxing? For example, back in UT99 days, 90KB upload could actually serve over 32 players. Nowadays games like ARK, on the same bandwidth, you could maybe host only 8-10 at best. MMOs also, originally worked with 56k lines but then started requiring SDL or higher connections. Where do you see Star Citizen going?asked by Wolf_Frakken
TL;DRThe aim is netcode as good as anyone's; the main limits so far are server and client performance rather than bandwidth, so they are refactoring to send only changes and scale better.
Our plan is to make the netcode in Star Citizen as good as we possible can and as good as anyone else's out there. To be honest most of the challenge at the moment isn't bandwidth in terms of how much data were pushing up or down the pipe, although that obviously when you have a big solar system with lots of people doing things and lots of NPC's doing things can definitely get saturated.Although we have made some pretty good improvements with something that's called the Dead Reckoning system which essentially just means that you don't send data like say positional update data unless something has changed. If something is just moving at a constant speed in a certain direction, once you've established the direction and the speed, you need to not send anymore data unless something changes, so basically you change the deltas and states. So not necessarily the deltas and position because you can already calculate position based on a fixed velocity and direction, it's really the deltas and states. So if something changes in the delta and state then you communicate it.That's really the fundamentals of the Dead Reckoning system which is what we have on our network bandwidth side and we're sort of right now actually in the middle of a refactor on the system to have a much more sophisticated serializing and aspect system that integrates much simpler and better with the game code on a scalability basis because unfortunately CryEngine and this is pretty much true with every engine out there like Unreal and Unity is you don't buy off the shelf engines that are really thinking about scaling for millions of players and thousands of concurrent players. They're built for "We need a 16 player or 32 multiplayer match." That has very different demands to what we'll need in Star Citizen and the Persistent Universe.So we're refactoring things to scale thing better. Doing things like putting the network communication messaging into a thread doing a better job of it. It is kinda threaded already in CryEngine, but we want to do a better job at it. So that's all stuff we're doing, but the really big challenge is the updating of these objects, but not necessarily so much the network bandwidth, but the amount of CPU time it takes to simulate and update the objects and obviously with GPU time to render them.When you have for example, I think people play 2.1 or 2.0 and if everyone spawns into the game and they all go to one area, well the performance is much better there than if they all went to 6 different areas and 6 different sets of AI all spawn, because what's happening on the server is it's running all those AI and all those players and all these different locations. It actually has a very heavy update loop and then why the game can slow down is now the server is now dropping down to 10 frames per second instead of what we want it to be, 30 frames per second, it's sending less frequent messages to the client and now the client feels like it's sluggish because it's not getting enough update or things are rubberbanding.So there's a lot of making the updates more efficient, obviously making the rendering better, streamlining the netcode to really only send things that are deltas and making sure it's like well threaded in terms of communication and making sure there's good sync points within the update. Those are all the things we are doing because we need to scale it for the size we want. I think we'll probably try to utilize as much bandwidth as we want, but up until now it's been less about bandwidth assuming you have a got a proper broadband connection and much more about server performance and client performance.So we're focusing on things that will improve that and we'll be back to optimize the data packages we're sending over the network because maybe they need to be smaller so we can get more information across. That's some of the process, but the goal will be to have something that will pass. We're working pretty hard towards that and there's a lot of pretty talented folks focusing on that. So there you go.