This, but unironically
Game Discussions Star Citizen Discussion Thread v12
- Thread starter Yaffle
- Start date
-
- Tags
- star citizen
You could scream this at the faithful until you are blue in the face, but they won't believe you. They are hopeless dreamers who actually fell for the outrageous crap Roberts told them about their life as a Star Citizen and all it would take is money, their money. It was lies then and it's still going on.
You're erotic actor?
lol....
Solid realities are the only cure. This looting laugh where you lose your purchased flair items until a character reset is a really fascinating insight into life after "launch". Unless CIG back pedal this might turn into quite a serious issue; my guess is there is a decent subset of supporters who like strutting their stuff and another bunch who are happy to relieve them of it.
Viajero
Volunteer Moderator
Except that what you quoted wasn't really ironic but sarcastic. Feel free to redefine things and terms that have existed for years “a la“ CIG though!
Last edited:
Viajero
Volunteer Moderator
Do we need to answer the call?
Was there a Miss Strangler?
Good that they have learnt their lesson and the Sandworm and everything shown previously that was not delivered was just a prank, bro. Let's hope they continue to learn their lesson and laugh about all the things shown in this years show that won't actually be delivered, but can also be a joke in future shows. No server meshing here, no SQ42 here, no TOW here, no volumetric clouds here... lol
I know someone that specifically paid into the project on seeing the Sandworm demonstration as their first experience of Star Citizen. I'm sure they will feel comforted knowing it was just a joke intended only to get them to pay out some money lol.
I know someone that specifically paid into the project on seeing the Sandworm demonstration as their first experience of Star Citizen. I'm sure they will feel comforted knowing it was just a joke intended only to get them to pay out some money lol.
It took them 10 years to find out?Just having a dig through the Server Messing stuff.
Currently calling this the 'Chris is a Moron' slide...
Zyloh surely makes a difference - by eroding any semblance of honesty.
Poor CIG, give them more money and time, they just aren't "established enough" to make the game they promised back in 2012 when they said they were.
"Keep up the good work on Spectrum"
Guy must be on the spectrum to suggest that place is anything other than a playground for crazies if you get banned until 2030 for stepping out of line.
Guy must be on the spectrum to suggest that place is anything other than a playground for crazies if you get banned until 2030 for stepping out of line.
Just having a dig through the Server Messing stuff.
Currently calling this the 'Chris is a Moron' slide...
Wow, now comparing that to Frontier's presentation at AWS re:invent in which Dav detailed the infrastructure down to individual mysql queries and autoscaling commands, really gives me a picture of how impressively open CIG development is unlike "other games".
(GAM403) From 0 to 60 Million Player Hours in 400B Star Systems
(GAM403) From 0 to 60 Million Player Hours in 400B Star Systems - Download as a PDF or view online for free
www.slideshare.net
Last edited:
Holy moly, never seen that. Thanks!Wow, now comparing that to Frontier's presentation at AWS re:invent in which Dav detailed the infrastructure down to individual mysql queries and autoscaling commands, really gives me a picture of how impressively open CIG development is unlike "other games".
(GAM403) From 0 to 60 Million Player Hours in 400B Star Systems
(GAM403) From 0 to 60 Million Player Hours in 400B Star Systems - Download as a PDF or view online for free
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.
TheAgent said:
---
Introduction: [20s]
'Streaming and Replication': [2m50s]
'Problems to Solve': [4m38s]
'Architecture': [5m19s]
'Replication Layer': [6m4s]
[Otherwise known as the 'Chris is a Moron' slide
]
'Shards & Persistent Streaming': [9m8s]
'Persistence': [11m13s]
'Seeding': [19m10s]
'Benefits and Challenges' [25m39s]
---
SUMMARY OF SORTS:
So the Replication Layer...
Conclusion: The replication layer is the new promised land.
- 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.
Last edited:
Depends, this looks like a message bus, a pretty typical element to introduce when many distributed processes need to publish / receive from many other processes, in real time (or close to it). It is a common pattern for state replication among multiple systems.
It's very colourful.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 hardlimit 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.