Game Discussions Star Citizen Discussion Thread v12
- Thread starter Yaffle
- Start date
-
- Tags
- star citizen
Kotaku | Gaming Reviews, News, Tips and More.
Gaming Reviews, News, Tips and More.www.kotaku.com.au
Viajero
Volunteer Moderator
Are you now the Russian Andy Serkis?
Yes, you can call me Randy though.
In other news...
Yes, the faithful are still playing the "they had to build a company first" card.
I look forward to seeing this card being played next year... and the year after... and the year after...
Viajero
Volunteer Moderator
So, in a nutshell, Turbulent is attempting to trade total amount of entities that need to be tracked (partitioned and smaller regions of a star system) for a (hopefully) larger number of players per instance/shard, for their network budget/bandwidth.Source: https://youtu.be/TSzUWl4r2rU
My Amateur Summary:
Old Server Meshing idea scrapped:
Because its crazy...
Replaced by the 'Replication Layer':.
A system which will magically connect a ton of clients, a ton of servers, and the persistence database etc. And which is not crazy at all. Oh no.
A single server will have authority for any given entity:.
Allocated on a first-come-first-served basis, and transmitting that simulation to other servers via the RL. Authority can migrate between servers depending on changing circumstances.
There will be multiple shards:
They've scrapped the single shard idea.
Bonus stuff:
- They'll start with 'static server meshing' (servers allocated to fixed locations, rather than mobile bubbles) because the authority transfer aspect is a nightmare.
- Many aspects of the game will need to be redesigned (missions, background services like 'Quantum' etc) to work with this new system, now that they've finally settled on a final approach. Kind of.
- Entity Graph is "an evolution of the original iCache".
- The broad beats all tally very nicely with claims by TheAgent's sources.
---
Introduction: [20s]
- OCS is a thing.
- Dynamic entities are nested. "Additionally to the static hierarchy of object containers there are also all the dynamic entities which bring the universe to life. NPCs, an interactive vending machine, and of course players and spaceships. Most of these entities are made of a hierarchy as well. For example a player has this body and undersuit and armor attached to it, and they are all child entities of the player. The streaming system treats these mini hierarchies as streaming groups to make sure that an object like a spaceship is always streamed in as one unit."
'Streaming and Replication': [2m50s]
- Streaming bubbles: "When a player connects we create a so-called streaming bubble around that player and object containers as well as streaming groups that are visible from the player's point of view are considered inside this bubble. Any object container that is inside the bubble will stream its content and any streaming group within the bubble will also be streamed in on the server and then replicated to the client."
- "Entities are considered inside the streaming bubble if their projected screen size on a virtual 1080p plane is larger than 5 pixels based on distance of the player. So while a large object like a moon will be considered inside the bubble from far away a small object like ship will only be considered inside when it's much closer to the player."
- "When the player starts moving across the universe entities that leave the streaming bubble will become unbound and the replication layer will remove these entities from the client. Entities that enter the streaming bubble will get bound to the client which caused the network layer to replicate these entities to the client, effectively streaming them in. We call this technique entity bind calling because streaming on the client is driven by the network layer binding and unbinding entities."
'Problems to Solve': [4m38s]
- "This model works quite well on the client however it doesn't scale well on the server... The more clients we try to match to given game server the likelihood of a player being at every single location increases and that basically nullifies the benefit of server-side streaming."
- "So how do we solve this? The answer should be simple. Allow multiple instances of the game server to work together so they can split up the work. Well it's not quite that simple."
'Architecture': [5m19s]
- Current dedicated game servers
'Replication Layer': [6m4s]
- "The goal of server meshing is to allow multiple DGS instances to work together and divide simulation cost between each server and the mesh. In the best case we can scale this to infinity by adding more nodes to the mesh."
- "If you want to mesh these servers together we need to find an efficient way to synchronize data between each server. With our current architecture, depending on the vision of the simulation, and the overlap this would require, a lot of synchronization points between each node. It's an exponential problem as in the worst case each node would need to talk to each other node in the mesh, severely limiting our ability to scale it."
[Otherwise known as the 'Chris is a Moron' slide]
- "To solve this issue we are separating simulation and replication."
- "The replication layer has two major functions. It holds the state of every entity in memory, and replicates the state to clients but also to server nodes."
- "I said server nodes because in this setup the traditional dedicated game server becomes a game server node. This server node connects to the replication layer, very similar to a client, and only a subset of entities are replicated to that server node."
- "Replication to server nodes is controlled by the network bind culling algorithm that we saw earlier, and it's driven by streaming bubbles, and it works very similar to how it works on clients."
- "The server node has certain[?] streaming bubbles assigned to it which will cause the replication layer to replicate entities from these streaming bubbles to the server node."
- "Contrary to a player's client the server node has the additional responsibility to execute server-side authoritative code for those entities. Controlling AI, doing damage calculations, etc etc. The result of the simulation is then written back from the server node to the replication layer, and from there it is replicated to all connected clients and other server nodes."
- "Since streaming bubbles can overlap entities may be replicated to multiple server nodes, exactly the same way how they are currently replicated to multiple clients if players are at the same location. To avoid two server nodes trying to simulate the same entity only one server node can have authority over any given entity, and only that server is allowed to write entity state back to the replication layer. This is usually the first server node who replicated the entity and other server nodes will only run client code on those entities"
- "Authority can transfer between server nodes. For example if an entity leaves the streaming bubble of the current authoritative server it is then transferred to the next server node that has this entity currently streamed in.Further authority can be transferred between server nodes on demand in order to load balance the mesh."
'Shards & Persistent Streaming': [9m8s]
- "Since we now mesh multiple server instances together to simulate a shared state of the universe we no longer call this instance but instead we call it shard."
- "A shard is still a unique version of the universe,and we still have multiple shards running in parallel. However, the server mesh will lift our current hard limit of 50 players and it will enable us to steadily increase the number of players we can support within one shard."
- "There are some fundamental differences between a shard and an instance. And for this, we need to take a closer look at the replication layer and talk a little bit about persistent streaming." [Chin emote here...]
- NB there seems to be a replication layer for each shard, going by this graphic:
- "The entire state of the universe is stored in a graph database. We call this entity graph and it's an evolution of the original iCache."
'Persistence': [11m13s]
- Benoit on the graph format for storing data in the entity graph etc. Blah blah.
- "Our objective is to be able to save the state of the replication layer, which includes all entities in a given universe shard,in order to provide a truly persistent world, where actions you take as a player can influence environments in the game world, permanently."
- "Each of these entity nodes holds properties with regard to what the entity represents in the game. That class of object it is, the item type, its legal owner, orientation, and of course, the very precise physical location within the game world."
- Much blah about how the graph system super much better than columns. Easy to serialise & transfers, data won't be lost etc
- "The system retrieves a constant ordered streams of mutation from the replicant scribes that are part of the replication layer and are enqueued in durable queues, to ensure that no message is lost even if the service is unavailable or paused."
'Seeding': [19m10s]
- So the Replication Layer [RL] starts with every entity loaded into it in their default / 'initial' state. (Universe / solar system / planets / station etc. From unstreamable conceptual entities, to static stations, to dynamic items like doors, ship components, bottles etc)
- "As you play the game and go about with your ship,your playing character entity moves from location to location, getting attached to new zones as you travel. Your player aggregate is itself part of the entity graph, and your location and state are persisted by the replication layer scribes to the entity graph of your given territory."
- "When you interact with dynamic objects and their properties change, the state of that entity will not persist until this instance of the database is undeployed." [So dynamic objects only saved in place periodically etc?]
- "There are in fact multiple copies of the universe that are seeded at a given time. We call those shards. Each shard is a unique copy of the game world,complete with all of its entities and unique states. Think of it as an alternate universe." [Oh well, so much for Clive's single shard universe]
- "Dynamic entities that have been modified in each dimension will have different states. The bottle on the bar was moved or the door was destroyed, might not be in the same state between shards."
- A way to gain scalability as playerbase grows. "Even if each shard database is itself clustered and can grow substantially past a single machine there is a point where multiple clusters are needed." [IE one version can't hold all the entities, seems to be the admission , and/or handle all the info networked between multiple machines, once it grows beyond a certain capacity?]
- "In order to select the correct universe shard for you to play on using multiple data points like your friends location your active party your last game session and or which shards still have items on it that you own this is to ensure as much as possible that you end up on the same shard you expect to be as a player in order to provide a seamless game experience."-"It would be terrible if you lost items you used when you were in a given shard versus another or if your character was bound to a shard forever. To alleviate this the system includes the concept of stowed and unstowed entities."
'Benefits and Challenges' [25m39s]
- Synchronisation issue dumped: Don't have the issue of synchronisation between servers [in the old plan etc]."Each server node has one single connection to the replication layer which is used to push and get updates for entities of interest."
- Servers like current clients: "The second advantage is that the same streaming and replication logic that we already use for clients can be applied to servers and that server nodes will only stream in a small area which will greatly increase performance"
- 'Static to start...': "The first version of this technology will contain a static server mesh instead of the fully dynamic mesh that we saw earlier the static mesh assigns server nodes to predefined sections of the solar system this will reduce the amount of authority transfer that game code has to address in this first release." [GULPS]
- Loads of current stuff will need redesign: "So you can imagine that this will affect things like missions that currently are spawned locally on the game server. These now need to be spawned globally within the chart and also persist their state. So all services that are attached to missions where, whether it's the Quantum system in the back end, or the Quasar tools, need to know know about the concept of a shard. This also goes deep into like things that are mechanical, like you know getting global chat to work on a server. That concept now needs to be extended to the shard where this will probably push us to implement this as a location-based chat for example. And so many teams in the company now need to change their feature to take into account the meshing technology that's behind it."
---
SUMMARY OF SORTS:
So the Replication Layer...
- Is connected to every player client in that shard.
- Is connected to every single server in that shard.
- Is connected to the entity graph data store etc. (Of the precise location, orientation etc of all of the things...)
Conclusion: The replication layer is the new promised land.
And those partitions are not even dynamic to start with.
If I am not mistaken this is precisely what we already suspected and discussed not too many pages ago:
Hello loading screens.
Last edited:
Randy Circus
I'm optimistic that Turbulent can get this thing moving is all. They've been given the PU remit for a reason, so it's not just me that's being optimistic
Yeah, I'd just say the 'dynamic by Q2' bit is, at minimum, absolutely not going to happen
For one thing, the static version dropping this year is a bit of a stretch in the first place. (It's possible, especially if Agent's gossip of working prototypes back in May is true etc. But I would have expected much more flag-waving from CIG at Citcon if they were even vaguely likely to hit 3.16).
For another, the vid suggested they'd be concentrating on expanding player counts next. (IE clients per shard, players per server, etc). Static would be the place to do that initially. And it'll likely take a while.
And for another - they sound petrified of the difficulties involved in even tackling 'dynamic' server meshing. (And if the Agent's gossip continues to pan out on this, they don't even really intend to do it at all.)
But y'know, in terms of the classic Freelancer scenario turning a corner, and some kind of game actually coming out, I still think this is all good
(Just, F in the chat for the wasted years, the horrible teething troubles that are to come, and for anyone who bought a giant capital ship
)Thing is, lets say the freelancer scenario happens, professional management take over, and networking changes in to something doable.But y'know, in terms of the classic Freelancer scenario turning a corner, and some kind of game actually coming out, I still think this is all good
(Just, F in the chat for the wasted years, the horrible teething troubles that are to come, and for anyone who bought a giant capital ship
Okay.
But what will they release? Without dreams.txt they stop bringing in whale cash, and quickly run out of money to do any more star systems with hand-crafted locations.
I don't really see the path to releasing SC.
They release a game that is pretty decent and people buy in... then the lootboxes start
Notsureifserious.jpg
DiscoLando on why citizencon was a bit more sparse on content this year. - Star Citizen Spectrum
Just saw this segment on the astropub's 24 hr stream, where Jared came on and talked a bit about why things at citizencon this year seemed a bit more sparse than they usually , which is that...
robertsspaceindustries.com
So... bear with me here a moment, but why wasn't this an issue all the previous years where they had weekly shows but still managed to show off loads of stuff during citizencon?
It couldn't possibly be because most of what is shown off doesn't actually exist can it?
Ach, it could play out lots of ways.
They could successfully hide the Freelancering for years to come, working towards pragmatic ends, while claiming to still be aiming for Chris’s stars. (As they seem to be doing now with server meshing
)So long as they can retain that illusion, plenty of whales will stay, and plenty of new ones will come ¯\(ツ)/¯
Who knows though. They could get obviously bought out in a way that breaks confidence, get lashed by legal challenges, get rocked by whistleblowers. Lots of paths out there.
There seems to be much SC.txt still to be written ultimately
Interesting points. They do in fact hire backend engineers "Familiar with service-oriented architectures and microservices". Mind you, just about everyone working with cloud hosted server solutions will be throwing microservices with message queues/intergration bus at the problem.
I have long been of the opinion that the bartender AI reeks of web service->message queue. The way it just sits there waiting for a response and the whole point was to "put things in a queue" which apparantly had never been done before. The implementation manifests itself like everyones first attempt at a decoupled solution with some noddy web AI so that they can avoid having to put any more game logic in server ticks.
I'd be surprised to see an advert for a backend engineer that doesn't mention microsevices these days.
Yeah, no. It's a bunch of mambo jumbo disguised as revolutionary tech when in fact it's just the same old instancing and loading screens with a DB backend and some caching slathered on for good measure.
Snake oil merchants selling cure-alls. More methane coming out of CIG than Mole's cows produce in a year.
I wish CIG was on the stock market so I could short their stock.
Snake oil merchants selling cure-alls. More methane coming out of CIG than Mole's cows produce in a year.
I wish CIG was on the stock market so I could short their stock.
like anyone would in any forum lol. you insult someone you need to be ed