The Lonely Spaceman
Presently, there is a maximum of 50 players per player server, such that a single player of Star Citizen can only interact with or see a maximum of 49 other players in each game session.
More players are catered for, but only by diverting them to other silos where they can only see the players on their local silo.
That’s a big limitation for a MMO with such big ambitions as Star Citizen.
Then consider the fact these 50 players are usually spread across an entire system.
If you think about how seldom you come across other players out in the wild, just think how bad it will be when other systems join the expanding 'verse. One more system should effectively halve the chance of you seeing another players ship or suit when out playing. Imagine adding a third system!
For a game where player interaction is a strategic design goal, clearly this isn’t sustainable.
Then consider all the apparent bugs that are present in SC that relate to server performance and latency, that would otherwise work flawlessly. Further consider how much this frustrates the developers when trying to debug these issues that turn out to be down to current technical performance limitations. Finally, consider the poor player/backer who has to experience these unresolved issues on a daily basis!
CIG is working on some clever tech to change all of this.
Mesh it up!
Server meshing, in this instance, is a way of taking the online player population and serving virtually geo-located players (relative to each other in the 'verse) on the same server. As they move throughout the world, they are transitioned between servers that are tied to areas or locations, rather than fixed player populations. Thus, up to 50 players, all things being equal, are no longer spread out across the entire 'verse, but can be presented locally to the player, increasing the protentional for player interaction and all that that might entail!
To maintain immersion, these transitions will need to be as seamless as possible. The challenge is there will be a time and processing cost of transferring players and their assets between servers and unless carefully managed, this could otherwise introduce unacceptable stuttering and lag into the player experience.
However, the engineers can take advantage of natural lulls in gameplay. For example, and to begin with, they are likely to take place in deep space during a Quantum Jump; you know, the times you tend to just be switching to the external view and rotating the camera, admiring your ship and the QJ animation, whilst doing almost nothing else, sometimes for minutes! Who knows, when this process gets fast enough, this might mean one server ends up dealing with everyone on a single busy space station, taking advantage of the transition time within an elevator from the launch pads or hangars to make that happen … or between metro stations … you get the idea!
This is not entirely trivial, however, because it would still be desirable to maintain immersive features like the ability to see ships flying into a spaceport from behind the glass observation area, not just have new joiners pop out of the lift. Much for the designers and engineers to consider, then.
There are other significant advantages to this architecture. Not only do player counts and density matter, but so do object and NPC density. This provides a path to provide optimum server capacity to complex, high traffic areas.
Now clearly there will be other variables at play. There may eventually be a higher player population than 50 people per zone, it might not be efficient to have a server per fixed zone size and the system may need to cater for both larger and smaller zones depending on player, NPC and object density (for example) and players will be logging in from regions across the globe, so latency will also need to be considered. There may end up being a set of servers for each real world region that will dynamically take ownership of parts of the verse and communicate as appropriate with servers in other real world regions covering the same geography for attributes which will affect all players. These areas may grow and shrink depending on player activity, events, etc.
CIG is talking about supporting “thousands of players” at once in the 'verse. You can see how this might scale even further, though, and it might need to in order to fully achieve the potential of this online universe and its significant popularity: with over 3 million registered backers and other big games supporting hundreds of thousands of players at once (albeit not in the same game instance), the pressure is on!
That’s great, but when is all this happening?
2022 is supposed to be the year we see the full realisation of this tech, with the rollout ending in Q3, apparently, alongside the rollout of new territories in whole new star systems (starting with Pyro). We need to take this with a pinch of salt, however, as it was originally targetted for 2021. That said, parts of this system may end up in Live sooner than that.
It has to be said though, alongside improvements to the graphics rendering pipeline, covered here: CitizenCon 2951: Gen 12 & The Multicore of Vulkan - StarZen: The Unofficial Star Citizen Community, this is probably the most crucial upgrade to SC in a decade.
The CIG Roadmap for this item is here: RSI Progress Tracker (robertsspaceindustries.com)
Their recent video on the topic at the 2021 Citizencon, is here: CitizenCon 2951: Server Meshing & The State Of Persistence - YouTube
If this guide was useful or you have a comment, please Like it and/or reply below! Sign in via Discord or just by using your email address. Thanks for reading this far!
If you’ve yet to join Star Citizen, please consider supporting this site by using our referal code STAR-QSK9-YWYF