Yeah, that's not happening. Even the biggest SC fanboys like Morphologis think static server meshing is arriving summer 2022 at the earliest.
Game Discussions Star Citizen Discussion Thread v12
- Thread starter Yaffle
- Start date
-
- Tags
- star citizen
Yeah sounds like the coffee cup has to pick its forest...
This is my take away too. It sounds like they've settled on something that isn't designed to meet the absurder 'Server Meshing' targets of 1000+ player concurrency etc. It's just designed to work at a basic level. And have a chance of scaling up to slightly chunky numbers. (So they'll get some server performance & player cap improvements by handling smaller regions per server, and try and ramp up the number of clients they can get in per shard etc. But they're not expecting to get good performance in heavy scenarios via combined servers or anything. IE no real expectations of giant 200+ player battles where it's all running reliably).
Will be interesting to see if the tail end of the Agent gossip pans out too there
I think it will. To add to the previous posts:
- What they showed, assuming I am right, is a reasonable persistence and replication layer. It solves the issue of the reliability of the persistence itself, but nothing more.
- Again, bye bye, coffee cup!
- Sharding, as presented, does not solve the issue of "dense" situations, because if all players on a shard decide to gather in one place for an epic battle, they are going to end up in the same bubble and, as a consequence, on a single server. For this reason, there will have to be a per-shard player limit and it will be set by what a single server can reasonably, well, serve. They could try to somehow dynamically move players between shards. BUT! Remember that shards share no state ; a player would approach a "dense" situation, say a potential capital ship battle, only to suddenly see themselves teleported to the same location in a parallel universe with different players and no battle happening. It would also be complex to implement.
- This extends to multiple star systems. Do shards contain a single star system or the entire 'verse? If it is the former, then we can have more players in a system but every jump would mean assignment to another shard. Imagine that you are jumping to Pyro and your org mate, who was sitting in the gunner's seat, disappears because he was assigned to another shard. What happened to him? Is he dead from being thrown into space of a parallel universe? Or are players assigned to a single ship always kept together, shard limits be damned? If it is the later, those shards will become more and more devoid of player interaction as more systems get introduced to the game.
- Points 3 and 4 would support what @WotGTheAgent said about capital ships - they need to figure out how to avoid dense situations. Two or more capital ships cannot meet, no matter what. It is a clusterhug.
- No other kinds of nonsense are resolved. Simulated materials, wonky physics grids, 30ks resulting from dripping server memory leaks, overabundance of polygons and unnecessarily large textures etc. These instances of mismanagement remain.
- Assuming it really exists on a computer, somewhere, we have no idea how well it scales. What they were showing so far, could run on a single machine. Can it scale to distribute the load? How is it done? This, in itself, is a complex issue, as now we are entering the realm distributed agent-based simulations.
- How will they integrate it with the rest of the presented backend? The first thing to mention is that the simulation will have to communicate with the rest of the system through the same replication layer (message bus / distributed log). If this part is new, does it mean Quanta so far has been built without support for such a thing? Do they now have to also rewrite persistence and communication for Quanta?
- Generally we know nothing about the architecture of this thing. It has been omitted from conversations about SC's backend infrastructure, even if it is a complex and integral part of it. At least according to dreams.txt. What does its persistence consist of? Does it have separate storage for state or does it simply "boot itself" by reading the stream from replication layer, understanding latest changes, doing its simulation magic and sending updates back to the stream, so that they can be "replayed" and influence the state of the shard?
- Does it work across shards, like the background simulation in ED? Or is there a separate instance of Quanta per shard?
They specifically talk about it being possible to switch between shards. No details on why, when or how though.
Yeah I’m unclear how they could be doing any fancy authority tricks & server share for locations in a static scenario. Which would suggest the server cap would be the cap for any given location. (With anyone trying to enter a maxed out location bumped to a new shard then? Which would be… bumpy, if so, I would have thought)
It seems to be a verse per shard…
"From the universe root to the star system root…"
Seemingly so…
"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."
20 years tops
Last edited:
90 days tops!
Tony Zurovek spent an inordinate amount of time designing a similar overly complex and untested 'Quanta' type economic system for Ultima at one point...which was totally abandoned after it refused to work at all when players used it...I think it will. To add to the previous posts:
Now, the biggest source of hilarity - Tony Z's Quanta:
- What they showed, assuming I am right, is a reasonable persistence and replication layer. It solves the issue of the reliability of the persistence itself, but nothing more.
- Again, bye bye, coffee cup!
- Sharding, as presented, does not solve the issue of "dense" situations, because if all players on a shard decide to gather in one place for an epic battle, they are going to end up in the same bubble and, as a consequence, on a single server. For this reason, there will have to be a per-shard player limit and it will be set by what a single server can reasonably, well, serve. They could try to somehow dynamically move players between shards. BUT! Remember that shards share no state
- This extends to multiple star systems. Do shards contain a single star system or the entire 'verse? If it is the former, then we can have more players in a system but every jump would mean assignment to another shard. Imagine that you are jumping to Pyro and your org mate, who was sitting in the gunner's seat, disappears because he was assigned to another shard. What happened to him? Is he dead from being thrown into space of a parallel universe? Or are players assigned to a single ship always kept together, shard limits be damned? If it is the later, those shards will become more and more devoid of player interaction as more systems get introduced to the game.
- Points 3 and 4 would support what @WotGTheAgent said about capital ships - they need to figure out how to avoid dense situations. Two or more capital ships cannot meet, no matter what. It is a clusterhug.
- No other kinds of nonsense are resolved. Simulated materials, wonky physics grids, 30ks resulting from dripping server memory leaks, overabundance of polygons and unnecessarily large textures etc. These instances of mismanagement remain.
We literally have no information about this aspect. It is one thing to implement something on local machine. Another is to turn it into a scalable system and integrate it with the rest of the backend.
- Assuming it really exists on a computer, somewhere, we have no idea how well it scales. What they were showing so far, could run on a single machine. Can it scale to distribute the load? How is it done? This, in itself, is a complex issue, as now we are entering the realm distributed agent-based simulations.
- How will they integrate it with the rest of the presented backend? The first thing to mention is that the simulation will have to communicate with the rest of the system through the same replication layer (message bus / distributed log). If this part is new, does it mean Quanta so far has been built without support for such a thing? Do they now have to also rewrite persistence and communication for Quanta?
- Generally we know nothing about the architecture of this thing. It has been omitted from conversations about SC's backend infrastructure, even if it is a complex and integral part of it. At least according to dreams.txt. What does its persistence consist of? Does it have separate storage for state or does it simply "boot itself" by reading the stream from replication layer, understanding latest changes, doing its simulation magic and sending updates back to the stream, so that they can be "replayed" and influence the state of the shard?
- Does it work across shards, like the background simulation in ED? Or is there a separate instance of Quanta per shard?
It seems that CR isn't the only one desperately trying to resurrect ancient failed pet project concepts
Last edited:
Why do they keep using the word "earned" when talking about giving real world money for stuff?
Viajero
Volunteer Moderator
The more I learn about this hilarious network 180 by Turbulent the more I appreciate the work done quietly and unpretentiously by FDEV on instancing, persistence and BGS tbh.I think it will. To add to the previous posts:
Now, the biggest source of hilarity - Tony Z's Quanta:
- What they showed, assuming I am right, is a reasonable persistence and replication layer. It solves the issue of the reliability of the persistence itself, but nothing more.
- Again, bye bye, coffee cup!
- Sharding, as presented, does not solve the issue of "dense" situations, because if all players on a shard decide to gather in one place for an epic battle, they are going to end up in the same bubble and, as a consequence, on a single server. For this reason, there will have to be a per-shard player limit and it will be set by what a single server can reasonably, well, serve. They could try to somehow dynamically move players between shards. BUT! Remember that shards share no state
- This extends to multiple star systems. Do shards contain a single star system or the entire 'verse? If it is the former, then we can have more players in a system but every jump would mean assignment to another shard. Imagine that you are jumping to Pyro and your org mate, who was sitting in the gunner's seat, disappears because he was assigned to another shard. What happened to him? Is he dead from being thrown into space of a parallel universe? Or are players assigned to a single ship always kept together, shard limits be damned? If it is the later, those shards will become more and more devoid of player interaction as more systems get introduced to the game.
- Points 3 and 4 would support what @WotGTheAgent said about capital ships - they need to figure out how to avoid dense situations. Two or more capital ships cannot meet, no matter what. It is a clusterhug.
- No other kinds of nonsense are resolved. Simulated materials, wonky physics grids, 30ks resulting from dripping server memory leaks, overabundance of polygons and unnecessarily large textures etc. These instances of mismanagement remain.
We literally have no information about this aspect. It is one thing to implement something on local machine. Another is to turn it into a scalable system and integrate it with the rest of the backend.
- Assuming it really exists on a computer, somewhere, we have no idea how well it scales. What they were showing so far, could run on a single machine. Can it scale to distribute the load? How is it done? This, in itself, is a complex issue, as now we are entering the realm distributed agent-based simulations.
- How will they integrate it with the rest of the presented backend? The first thing to mention is that the simulation will have to communicate with the rest of the system through the same replication layer (message bus / distributed log). If this part is new, does it mean Quanta so far has been built without support for such a thing? Do they now have to also rewrite persistence and communication for Quanta?
- Generally we know nothing about the architecture of this thing. It has been omitted from conversations about SC's backend infrastructure, even if it is a complex and integral part of it. At least according to dreams.txt. What does its persistence consist of? Does it have separate storage for state or does it simply "boot itself" by reading the stream from replication layer, understanding latest changes, doing its simulation magic and sending updates back to the stream, so that they can be "replayed" and influence the state of the shard?
- Does it work across shards, like the background simulation in ED? Or is there a separate instance of Quanta per shard?
Last edited:
That's....terrifying.
Very interesting, I didn't know it was such a disaster. Tony seems to be enjoying creating simulations for the sake of simulations. No gameplay-focused testing required. Or even any integration with a game for that matterTony Zurovek spent an inordinate amount of time designing a similar overly complex and untested 'Quanta' type economic system for Ultima at one point...which was totally abandoned after it refused to work at all when players used it...
It seems that CR isn't the only one desperately trying to resurrect ancient failed pet project concepts
Last edited:
Viajero
Volunteer Moderator
I hear you. I mean, P2P is not without its issues butThat's....terrifying.
P2P issues notwithstanding the way Elite manages the galaxy server, persistence and the generation of dynamic instancing/shards that move with the player(s) (iirc FDEV called them “islands”) etc was designed around a certain reasonable network budget and it just works.
Last edited:
They are running out of excuses.
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?
They went slaving at the job for the money they spent on the entertainment. Now they expect good value from it and not be scammed.
They are not buying anything, they are pledging to fund the development of the game
Another way in which CIG manage the message on the forums is by ensuring there are loads of sticked positive threads.
It's time to cancel Theatres of War. - Star Citizen Spectrum
While I'm in the minority who enjoyed most of Citizencon, I have to say that ToW being a no-show is a pledging deal breaker for me. We never asked for it, we never agreed to pledge for it and it's...
robertsspaceindustries.com
CIG altered the deal. Pray they don't alter it any further.
And...
LOL.... so this guy thinks people working on it are not taking resources from the company? Its internal man hours and costs for CIG employees and external costs for Firesprite employees. There is absoloutely a drain.
Oo, fighting talk eh. Can't hold your virtual drink?
Can't hold my real drink either....
LOL, some backers are even trying to retcon this