That is an excellent point. How can we have large crews with low pop caps?
On the design of the server mesh for this:
As we refine the technology and move away from Static Server Meshing towards Dynamic Server Meshing, designers can use this tech to have larger, more interesting areas (such as larger settlements or large ship interiors) with denser numbers of AI and player characters.
For server simulation, big ships are far more expensive than players characters at that, as they hold not only the players but other ships/vehicles within, so I doubt the number of players will ever be more imposing to capacity than the number of ships for crews to become any problem.
Forgive my ignorance here. What I was inferring was along the lines of conflict. If I have 80 in my Javelin and I want to attack some POI… would anyone be able to come fight us? If so… what if my group flew in 2 Javelins….
Or how would it work if we get a large fight and someone wants to launch smaller ships from the capital ships but the “shard” is full? Would the small ship end up in another instance?
Small zone caps was a huge factor in Crowfall’s demise. (Certainly not the only one) But games that have PvP in general will be challenged more on this. Especially if you can take over other peoples assets.
Does 1 Javelin full of 80 people count as 1 for the server limit? Or does it count as 80? Or 80 plus each ship? Not sure if the javelin holds smaller ships but I know some other ships do.
Aren’t their 3,000,000 backers or something? What happens when 2 large player groups piss in each other’s Wheaties and want to fight it out?
All time classic MY NEW FAVORITE POST! (Keep laying those bricks)
"I should point out that no other company has shipped out a beta on a disc before this." - Official Mortal Online Lead Community Moderator
Proudly wearing the Harbinger badge since Dec 23, 2017.
Coined the phrase "Role-Playing a Development Team" January 2018
"Oddly Slap is the main reason I stay in these forums." - Mystichaze April 9th 2018
Let me know when they do 2000-5000 per server. Until then ZzzZzzzzZz
not a mmorpg. Never was one.
Google the following. You'll see that they themselves have described it as an MMO on their own site and pinterest advertisement. Server meshing will be required to meet their goals of full persistence for all players though. And they will likely end up backing off on some goals.
Discover space, build a life. Start your journey here and play today. Star Citizen is the groundbreaking and record-setting Space Sim MMO by Chris Roberts and Cloud Imperium Games.
But listening to them pitch it it seemed that it was following a more "freelancer" type of game. Not MMO.
So I bet dollars to donuts that's marketing screwing up.
Well, for me that adds to the confusion. Why all the fancy server technology for 125 people per server?
I'm getting the sense I'm missing something here...
They started out with a Crytek engine, probably useable for Sq42, but basically a single player shooter engine. Most likely because it made nice looking trailers for the original crowd funding push. (Trailers that were mostly made by Crytek.) After they got some money and Roberts overweening ego latched onto SC as the holy grail, they didn't switch to or build another appropriate game engine, they just stuck with Crytek 3, and tried to jury rig it to work. They lucked in to Crytek closing down their German development, hired all these Crytek engine devs....and six or eight years later, they still can't get meshing going. Though they've talked about it 'being next year' for years now.
Pretty classic bad game management, combined with very successful cult branding.
If you are holding out for the perfect game, the only game you play will be the waiting one.
That is an excellent point. How can we have large crews with low pop caps?
On the design of the server mesh for this:
As we refine the technology and move away from Static Server Meshing towards Dynamic Server Meshing, designers can use this tech to have larger, more interesting areas (such as larger settlements or large ship interiors) with denser numbers of AI and player characters.
For server simulation, big ships are far more expensive than players characters at that, as they hold not only the players but other ships/vehicles within, so I doubt the number of players will ever be more imposing to capacity than the number of ships for crews to become any problem.
Forgive my ignorance here. What I was inferring was along the lines of conflict. If I have 80 in my Javelin and I want to attack some POI… would anyone be able to come fight us? If so… what if my group flew in 2 Javelins….
Or how would it work if we get a large fight and someone wants to launch smaller ships from the capital ships but the “shard” is full? Would the small ship end up in another instance?
Small zone caps was a huge factor in Crowfall’s demise. (Certainly not the only one) But games that have PvP in general will be challenged more on this. Especially if you can take over other peoples assets.
Does 1 Javelin full of 80 people count as 1 for the server limit? Or does it count as 80? Or 80 plus each ship? Not sure if the javelin holds smaller ships but I know some other ships do.
Aren’t their 3,000,000 backers or something? What happens when 2 large player groups piss in each other’s Wheaties and want to fight it out?
On this end I would at least say, unless they did something profoundly dumb with the design, the people launching ships from the Javelin are already part of the present server. Depending on how they factor for it, part of that 80 man crew would themselves be pilots for the fighters it's carrying.
I don't think that part will be the bottleneck as much as the fact this means the biggest a fleet battle scales to is a 1V1 against two Javelins and some fighters, and they'd have to understaff the Javelins just to bring in extra ships.
If you just overloaded one Javelin before going somewhere then yeah, you'd have both military and numeric dominance and no one could even field anything in comparative force against you.
They could do that with a military ship and be at a better advantage.
Wedging 100 people onto a yacht really doesn't mean much.
For context, the 890J is a luxury ship with a max crew of 8. The extra 90+ people on that ship ain't doing anything until they get to set foot somewhere.
Javelin is an (ex)military ship with a max crew of 80. If they're going to load 100+ people onto a ship to invade anything, there's a very clear winner in terms of choice.
If the goal is only control through dominating server capacity and strangling the connection for incoming players though, then yeah sure whatever. Who needs pesky gameplay when you can just dominate a server through "standing room only".
I guess it's good SC figured out how to choke out their servers 10x more efficiently than EVE.
With the base logic of the server mesh, there won't be the logic of a "cap" beyond the server mesh itself that is all its game-servers together simulating a single copy of the game-world.
So if a place on the game-world becomes a hotspot it probably can go beyond the intended capacity a server can cope with, at least on the static version of it because the end goal dynamic mesh is mean to spin more hardware as needed to share the workload.
What I understand based on what they said is them making areas of space overcrowded/jammed that players wouldn't be able to quantum jump to that location for example, or a queue on the ATC that won't deliver your ship to hangar immediately which was mentioned as well.
That on the initial static mesh, the dynamic one is meant to scale, and is where they stated interiors being simulated by an extra simulation node if need be.
Forgive my ignorance here. What I was inferring was along the lines of conflict. If I have 80 in my Javelin and I want to attack some POI… would anyone be able to come fight us? If so… what if my group flew in 2 Javelins….
Or how would it work if we get a large fight and someone wants to launch smaller ships from the capital ships but the “shard” is full? Would the small ship end up in another instance?
Small zone caps was a huge factor in Crowfall’s demise. (Certainly not the only one) But games that have PvP in general will be challenged more on this. Especially if you can take over other peoples assets.
Does 1 Javelin full of 80 people count as 1 for the server limit? Or does it count as 80? Or 80 plus each ship? Not sure if the javelin holds smaller ships but I know some other ships do.
Aren’t their 3,000,000 backers or something? What happens when 2 large player groups piss in each other’s Wheaties and want to fight it out?
The Shard is not the game-server, aka what they call simulation node on the context of the mesh, the shard is ALL of them simulating a copy of the entire game-world.
Like I just posted there won't be an artificial cap on a region of space when players have free movement, they can is do mechanics to prevent or discourage further travel until they have the dynamic mesh that is meant to resize simulation areas to share workload and cope with that density.
As well, things like claiming a ship on an overloaded area facing a queue until your ship is delivered on hangar for you.
On the case of that Javelin if you pack it and the interiors are simulated by a different node, then the other node simulating outside won't need to bother much with how many the ship is packing. The capital ships can carry a limited amount of fighters so they would never represent a load of anything close to 80 ships.
But everything has its limits, on games like this, especially Albion Online because I suffered and did this too, if you can move 500 people in one go, you surely can simply "win without a fight" by overwhelming a place of the map. There is not magic bullet solution to this, but I think they will push to increase server capacity as much as possible as that'll render such scenarios more uncommon.
That's a whole lot of hope on how things might work versus the current dilemmas faced. Even with server meshing you're now talking about distributed processing across servers to handle headcount, which slows everything down exponentially as you bring more servers into the mesh. This is a basic speed problem that plagues blockchain networks as well, as with any meshed network, and big part of why they don't really get evoked in any kind of real-time scenario traditionally.
Part of why EVE uses deferred authority layers to their server structures. They already face a regularly slow experience, but if they ran on meshed servers or even traditional ones they'd be facing complete stalls well before hitting 1000 players.
Your explanation certainly sounds like a magic bullet.
That's a whole lot of hope on how things might work versus the current dilemmas faced. Even with server meshing you're now talking about distributed processing across servers to handle headcount, which slows everything down exponentially as you bring more servers into the mesh. This is a basic speed problem that plagues blockchain networks as well, as with any meshed network, and big part of why they don't really get evoked in any kind of real-time scenario traditionally.
Part of why EVE uses deferred authority layers to their server structures. They already face a regularly slow experience, but if they ran on meshed servers or even traditional ones they'd be facing complete stalls well before hitting 1000 players.
Your explanation certainly sounds like a magic bullet.
This is really not something that is a "magic bullet" unproven tech, you have SpacialOS around that in a nutshell brings many servers working together to achieve mass-scale, has been shown to work.
What SC is doing is around similar lines. Dual Universe is also around the same SpacialOS lines, but uses CAF, there's also others around.
Cloudgine for example is what Microsoft used to simulate the destruction physics of Crackdown 3 on the cloud, was now bought by Epic Games.
That's a whole lot of hope on how things might work versus the current dilemmas faced. Even with server meshing you're now talking about distributed processing across servers to handle headcount, which slows everything down exponentially as you bring more servers into the mesh. This is a basic speed problem that plagues blockchain networks as well, as with any meshed network, and big part of why they don't really get evoked in any kind of real-time scenario traditionally.
Part of why EVE uses deferred authority layers to their server structures. They already face a regularly slow experience, but if they ran on meshed servers or even traditional ones they'd be facing complete stalls well before hitting 1000 players.
Your explanation certainly sounds like a magic bullet.
This is really not something that is a "magic bullet" unproven tech, you have SpacialOS around that in a nutshell brings many servers working together to achieve mass-scale, has been shown to work.
What SC is doing is around similar lines. Dual Universe is also around the same SpacialOS lines, but uses CAF, there's also others around.
Cloudgine for example is what Microsoft is using to simulate the destruction physics of Crackdown 3 on the cloud, was now bought by Epic Games.
SpacialOS is running an interim layer to merge multiple servers, it operates differently from what you'd call a mesh by batching task deferrals within it's libraries that sit on top of a server. Part of why you build your code to operate within their "worker" service, as those workers are used for the discrete batching. All that service has is a list of cancelled and a few unreleased games, with a pivot into Crypto and NFTs
CAF operating on supervision trees and suffers the same concurrency issues I'd mentioned prior, they are not solving for the fundamental issue presented there. Part of the issue with them only being able to benchmark 30k actors using virtual machines.
Cloudgine was the company that worked on Crackdown 3's engine, and used cloud computing to handle large scale math-heavy processes on a server, with at most ten players interacting with each other. That physics system only runs in the 5v5 multiplayer mode.
Still sounding like magic to me compared to these buzzword examples.
It is interesting the duality presented by these recent posts.
You point at live games that already use the kind of tech that they've only partially implemented, and it's off to argue how this is something more or super challenging.
You point at something that's actually unproven in practical application and you get a list of duds as if it's proof positive that it's actually very real and people are already doing it.
SpacialOS is running an interim layer to merge multiple servers, it operates differently from what you'd call a mesh by batching task deferrals within it's libraries that sit on top of a server. Part of why you build your code to operate within their "worker" service, as those workers are used for the discrete batching.
CAF operating on supervision trees and suffers the same concurrency issues I'd mentioned prior, they are not solving for the fundamental issue presented there. Part of the issue with them only being able to benchmark 30k actors using virtual machines.
Cloudgine was the company that worked on Crackdown 3's engine, and used cloud computing to handle large scale math-heavy processes on a server, with at most ten players interacting with each other. That physics system only runs in the 5v5 multiplayer mode.
Still sounding like magic to me compared to these buzzword examples.
An in-depth dive into it from the engineers who are creating it: That'll explain it better than I ever could, they go in-depth about it on that showcase.
They also did a follow up Q&A with a lot of questions that popped about potential problems and how they're addressing them, which includes answers about latency/delays/tick rates and the replication layer.
Well I can tell you in the first ten minutes I mostly was just thrown off by them making up new terms for old things.
Yeah, containers, understandable.
Binding bubble? You're stream loading content to the client with a bounding range. That's the basis of many games that stream load, and a standard part of object culling. Even sleeping processes if there's nothing in bound is normal there.
The replication server description is very similar to the server node network CCP uses for deferred authority. Even the point on server nodes holding unique authority over specific entities, it's sorting actions and spitting back to a middle layer of servers that then re-sync events and adjusts for the estimated actions from deferred authority. Now this does resolve server meshing on a small scale, but if they want to mesh the entire shards together without taking a big hit to their replication layer, that's going to take something they haven't explained.
This just rolls on with the entity graph talking about being a library of parented entities that's concurrently read and written to as a world snapshot.
Even seeding, known as pooling.
The global database is just standing above that as another larger library for static entities.
Ironically, the video mentions the theoretical benefits of server meshing, but not the actual how throughout. No wonder that first link warns about deduced and speculated technologies. It also distinctly avoids the prior issues I brought up around handling speed over a meshed network, something that was also avoided by the examples of cloud computing.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
Certainly hope they resolve the client authority issues that still exist according to the Q&A too.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
In a nutshell, it's viable, and they did answer on the Q&A directly about addressing delays on that process, it's not like it's not being minded because they have already redone a service of the mesh, what they call now Persistent Entity Streaming because it wasn't fast enough.
The biggest questions lie on the performance and scalability of mostly the replication as described there, as it's what servers and players connect to per shard. The game-server themselves, simulation nodes here, benefit from taking workload taken off them, all they need to ensure is that data flows with the minimum delay possible and if the services do the job they're supposed to do... you have your mesh.
The dynamic mesh is not talked to detail as that's not the one directly being worked on, with focus set on implementation of the static version first, most likely this will see prototyping work upon the static mesh to define details.
Well I can tell you in the first ten minutes I mostly was just thrown off by them making up new terms for old things.
Yeah, containers, understandable.
Binding bubble? You're stream loading content to the client with a bounding range. That's the basis of many games that stream load, and a standard part of object culling. Even sleeping processes if there's nothing in bound is normal there.
The replication server description is very similar to the server node network CCP uses for deferred authority. Even the point on server nodes holding unique authority over specific entities, it's sorting actions and spitting back to a middle layer of servers that then re-sync events and adjusts for the estimated actions from deferred authority. Now this does resolve server meshing on a small scale, but if they want to mesh the entire shards together without taking a big hit to their replication layer, that's going to take something they haven't explained.
This just rolls on with the entity graph talking about being a library of parented entities that's concurrently read and written to as a world snapshot.
Even seeding, known as pooling.
The global database is just standing above that as another larger library for static entities.
Ironically, the video mentions the theoretical benefits of server meshing, but not the actual how throughout. No wonder that first link warns about deduced and speculated technologies. It also distinctly avoids the prior issues I brought up around handling speed over a meshed network, something that was also avoided by the examples of cloud computing.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
Certainly hope they resolve the client authority issues that still exist according to the Q&A too.
As pointed out, they are still in the process of answering a lot of questions you bring up. As I said in a previous post, you seem to have it all figured out, you should present your conclusions to CIG and get paid.
The foundation of all of this back and forth was that what CIG has today is working better than they thought it would so they decided to see if they could increase the number of players per server and achieve better stability than they had in the last patch. Turns out they can.
By the way, we are a long way away from having capital ships in Alpha, one reason as someone pointed out, a fully crewed cap ship, would at this time be the ONLY cap on the server making it not much fun. 100-person servers are not the goal, it's a stepping stone. I won't pretend to understand the tech beyond that. If I did, I would be knocking on CIGs door trying to get paid.
If you want a new idea, go read an old book.
In order to be insulted, I must first value your opinion.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
In a nutshell, it's viable...
If your interpretation of viable is small-scale, yeah sure.
Well I can tell you in the first ten minutes I mostly was just thrown off by them making up new terms for old things.
Yeah, containers, understandable.
Binding bubble? You're stream loading content to the client with a bounding range. That's the basis of many games that stream load, and a standard part of object culling. Even sleeping processes if there's nothing in bound is normal there.
The replication server description is very similar to the server node network CCP uses for deferred authority. Even the point on server nodes holding unique authority over specific entities, it's sorting actions and spitting back to a middle layer of servers that then re-sync events and adjusts for the estimated actions from deferred authority. Now this does resolve server meshing on a small scale, but if they want to mesh the entire shards together without taking a big hit to their replication layer, that's going to take something they haven't explained.
This just rolls on with the entity graph talking about being a library of parented entities that's concurrently read and written to as a world snapshot.
Even seeding, known as pooling.
The global database is just standing above that as another larger library for static entities.
Ironically, the video mentions the theoretical benefits of server meshing, but not the actual how throughout. No wonder that first link warns about deduced and speculated technologies. It also distinctly avoids the prior issues I brought up around handling speed over a meshed network, something that was also avoided by the examples of cloud computing.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
Certainly hope they resolve the client authority issues that still exist according to the Q&A too.
As pointed out, they are still in the process of answering a lot of questions you bring up. As I said in a previous post, you seem to have it all figured out, you should present your conclusions to CIG and get paid.
The foundation of all of this back and forth was that what CIG has today is working better than they thought it would so they decided to see if they could increase the number of players per server and achieve better stability than they had in the last patch. Turns out they can.
By the way, we are a long way away from having capital ships in Alpha, one reason as someone pointed out, a fully crewed cap ship, would at this time be the ONLY cap on the server making it not much fun. 100-person servers are not the goal, it's a stepping stone. I won't pretend to understand the tech beyond that. If I did, I would be knocking on CIGs door trying to get paid.
It's funny the counterargument to scrutiny is for fans to scream "Then you do it." Twice from one and once from another now.
The foundation of the conversation was how well their tech will realistically scale. PS2 can run ~400 people in action combat with physics based projectiles and vehicles in one area. 120 people across an entire server isn't much beyond Battle Royale standards.
Yes, you can tout "but they're doing way more simulations" as to why that number is lower. The response to that is "exactly". There's a reason every real-world example Bacon tried to share demonstrated the practical limitation of cloud computing for mass real-time simulations. Mesh networking being an inherently slower to validate process isn't going go expedite that, so wedding the technology and expecting magic to happen leaves a lot of head-scratching to be done.
It's funny the counterargument to scrutiny is for fans to scream "Then you do it." Twice from one and once from another now.
But you're the one discrediting everyone working on this, which includes network engineers of decades of experience, not a team of random programmers assigned to work on network, because you know better, from an outsider look at that, that what they are doing is not viable.
Which is the type of attitude that makes me cringe, how can something that requires a team months of preparation and planning to start executing, be so easily figured out by you that's not viable within minutes, how do you have all the answers, including the ones they don't yet do? Just feels nitpicky on purpose to find something you can contest about it.
It's funny the counterargument to scrutiny is for fans to scream "Then you do it." Twice from one and once from another now.
But you're the one discrediting everyone working on this, which includes network engineers of decades of experience, not random programmers assigned to work on network, because you know better, from an outsider look at that, that what they are doing is not viable.
Which is the type of attitude that makes me cringe, how can something that requires a team months of preparation and planning to start executing, be so easily figured out by you that's not viable within minutes. Just feels way nitpicky on purpose to find something to contest about it.
Why don't you ask that question to the studios you used as an example earlier?
Ask Improbable how they're ten years in with four cancelled projects, three delayed, and none released while they as a company are now wandering off to mess with NFTs.
Ask Cloudgine why their technology has only managed to be demonstrated with one game on the scale of ten concurrent users in practice.
As Dual Universe where their development currently is.
Should we not ask questions of them in how those studios spent months, years, preparing and planning for what you claimed was at the least similar technology and goals?
Questioning and having doubts based on the factual history of the technology in practical application isn't "discrediting everyone working on this". Being critical of how a game is being developed is not arbitrary bias.
This isn't some small technology. It's hardly a nitpick to wonder about something that's a linchpin in how the title will scale and whether or not it can even support things like Javelins in play as an end goal.
Should people not ask if Planetside's networking layer can handle the task of running hundreds of people concurrently when they pitched the idea of a 400 player battlefield?
Which is the type of attitude that makes me cringe. how can something with known hurdles and quantifiable issues that have historically plagued a technology not bear scrutiny? This blind faith and abject hostility to any sort of doubt just brings right back the point made previously about how some fans make the whole deal around this game look like a cult.
Perhaps take a breather and regain some moderated perspective on the subject.
So some people here claim that its an mmo.
Some claim it never was an mmo.
The creators clearly market it as an mmo (always have).
Clear sign of a scam. And don't give me EVE or GW2 as an example, none of those games have ships with the crew size higher than server cap.
Mark my words: This will never release because they make more money on the anticipation than they would on the live game. Giving them any more money (because you cannot turn back time) is a crime against your own common sense.
No fate but what we make, so make me a ham sandwich please.
Why don't you ask that question to the studios you used as an example earlier?
Perhaps take a breather and regain some moderated perspective on the subject.
You act like those games were cancelled because of SpacialOS is not viable, this is a weak AF argument.
Games like Mavericks: Proving Grounds and Worlds Adrift faced the BS stunt of Unity with the SpacialOS license, funding dried up, development stopped, this wasn't to do with the tech not being viable, WA was live and working, Mavericks already had shown it in action.
Dual Universe it also has not to do with the that technology, it's facing general development challenges, where network runs fine the game's framerate performance is terrible for example.
Cloud technology, just like VR and others, had a rough start, complicated adoption and problems haunting it, but the state of cloud now is far from what it once was, a few years ago cloud gaming was laughed at, look at it now. It now hosts online games and MMOs as well where it once was too expensive and inefficient. With a more powerful and infrastructure comes the ease to build upon it,
At that, those pieces tech are also not dead, Epic Games snatched Cloudgine, even Crytek has integrated SpacialOS on CE and is building a large-scale BR project on it, rumored to be a Crysis title.
Why don't you ask that question to the studios you used as an example earlier?
Perhaps take a breather and regain some moderated perspective on the subject.
You act like those games were cancelled because of SpacialOS is not viable, this is a weak AF argument.
Games like Mavericks: Proving Grounds and Worlds Adrift faced the BS stunt of Unity with the SpacialOS license, funding dried up, development stopped, this wasn't to do with the tech not being viable, WA was live and working, Mavericks already had shown it in action.
Dual Universe it also has not to do with the that technology, it's facing general development challenges, where network runs fine the game's framerate performance is terrible for example.
Cloud technology, just like VR and others, had a rough start, complicated adoption and problems haunting it, but the state of cloud now is far from what it once was, a few years ago cloud gaming was laughed at, look at it now. It now hosts online games and MMOs as well where it once was too expensive and inefficient. With a more powerful and infrastructure comes the ease to build upon it,
At that, those pieces tech are also not dead, Epic Games snatched Cloudgine, even Crytek has integrated SpacialOS on CE and is building a large-scale BR project on it, rumored to be a Crysis title.
See, this isn't being honest at all.
Certainly you can point at some things and say "this was the problem", but a) there's never one problem and b) you made a point to address as little as possible via anecdote there.
WA was shown off, but it was not demonstrated to ever work at-scale. Small demos was the most it ever showcased, much like Mavericks. And this is the problem, you want to argue that something works at scale that historically has not, by using examples that don't actually prove it.
I looked at Dual Universe's forums before commenting as well. I can safely say that what you claimed isn't nearly the scope of Dual Universe's issues, and their network is not "fine" Perhaps it's only benefit to stability was the hemorrhaging of players.
SpatialOS has integration with multiple engines, that doesn't say much of anything. And Indeed there are a few projects still theoretically going using the technology. That fails to deliver any demonstration of the technology successfully in action at scale.
Same with Epic buying Cloudgine. They bought the company four years ago as they were expanding their online services. The tech was already developed largely on UE4, and as Epic noted in the acquisition they were planning to leverage the cloud computing service to "push the creative and technical limits of games, film, animation, and visualization." You know what Unity has done since then with cloud computing? Photogrammetry.
Cloud technology has many great applications. Thing is, those strengths do not encompass every form of network task. Cloud gaming even now struggles against network capability, getting more boost from new cellular networks than anything else. MMO have always utilized parallel architecture to cloud for authoritative game systems deferred away from the client, the thing is the architecture was not trying to create that many layers and cross-communication versus the singular hubs.
Not to mention cloud computing wasn't the issue. Cloud computing and mesh network architecture aren't the same things. The subject that was questioned was the use of mesh networks to try and scale architecture that has to run at a stable speed to maintain simulation elements and user experience. Said it yourself that they've already had to backtrack and redo parts of that, and I doubt they aren't going to have to do the same many more times.
Seriously, instead of grasping for straws at every imagined slight, take a breather.
Why don't you ask that question to the studios you used as an example earlier?
Perhaps take a breather and regain some moderated perspective on the subject.
You act like those games were cancelled because of SpacialOS is not viable, this is a weak AF argument.
Games like Mavericks: Proving Grounds and Worlds Adrift faced the BS stunt of Unity with the SpacialOS license, funding dried up, development stopped, this wasn't to do with the tech not being viable, WA was live and working, Mavericks already had shown it in action.
Dual Universe it also has not to do with the that technology, it's facing general development challenges, where network runs fine the game's framerate performance is terrible for example.
Cloud technology, just like VR and others, had a rough start, complicated adoption and problems haunting it, but the state of cloud now is far from what it once was, a few years ago cloud gaming was laughed at, look at it now. It now hosts online games and MMOs as well where it once was too expensive and inefficient. With a more powerful and infrastructure comes the ease to build upon it,
At that, those pieces tech are also not dead, Epic Games snatched Cloudgine, even Crytek has integrated SpacialOS on CE and is building a large-scale BR project on it, rumored to be a Crysis title.
See, this isn't being honest at all.
Certainly you can point at some things and say "this was the problem", but a) there's never one problem and b) you made a point to address as little as possible via anecdote there.
WA was shown off, but it was not demonstrated to ever work at-scale. Small demos was the most it ever showcased, much like Mavericks. And this is the problem, you want to argue that something works at scale that historically has not, by using examples that don't actually prove it.
I looked at Dual Universe's forums before commenting as well. I can safely say that what you claimed isn't nearly the scope of Dual Universe's issues, and their network is not "fine" Perhaps it's only benefit to stability was the hemorrhaging of players.
SpatialOS has integration with multiple engines, that doesn't say much of anything. And Indeed there are a few projects still theoretically going using the technology. That fails to deliver any demonstration of the technology successfully in action at scale.
Same with Epic buying Cloudgine. They bought the company four years ago as they were expanding their online services. The tech was already developed largely on UE4, and as Epic noted in the acquisition they were planning to leverage the cloud computing service to "push the creative and technical limits of games, film, animation, and visualization." You know what Unity has done since then with cloud computing? Photogrammetry.
Cloud technology has many great applications. Thing is, those strengths do not encompass every form of network task. Cloud gaming even now struggles against network capability, getting more boost from new cellular networks than anything else. MMO have always utilized parallel architecture to cloud for authoritative game systems deferred away from the client, the thing is the architecture was not trying to create that many layers and cross-communication versus the singular hubs.
Not to mention cloud computing wasn't the issue. Cloud computing and mesh network architecture aren't the same things. The subject that was questioned was the use of mesh networks to try and scale architecture that has to run at a stable speed to maintain simulation elements and user experience. Said it yourself that they've already had to backtrack and redo parts of that, and I doubt they aren't going to have to do the same many more times.
Seriously, instead of grasping for straws at every imagined slight, take a breather.
But Chris promised.
/Cheers, Lahnmir
'the only way he could nail it any better is if he used a cross.'
Kyleran on yours sincerely
'But there are many. You can play them entirely solo, and even offline. Also, you are wrong by default.'
Ikcin in response to yours sincerely debating whether or not single-player offline MMOs exist...
'This does not apply just to ED but SC or any other game. What they will get is Rebirth/X4, likely prettier but equally underwhelming and pointless.
It is incredibly difficult to design some meaningfull leg content that would fit a space ship game - simply because it is not a leg game.
It is just huge resource waste....'
Gdemami absolutely not being an armchair developer
It would be interesting to know how many crew are needed for the ships? I don't think this has been thought through, if you cap the servers at a low population, putting bums on crew seats is not going to be easy. Having played games like PS where you can have loads of players and it is still a problem, SC could be setting themselves up for a big issue here. What are the penalties of not being fully crewed, or have they realised that having no penalties will alleviate the problem?
Between all MMORPGs I've played, Darkfall Online provided the best large scale experience. I can't remember there being any issues, apart from the load lags when players are entering the "server shard" or whatever the terminology is in their case. This was over 10 years ago, surely there must have been steps made in the right direction to handle large scale battles? I remember events with over 200vs200 within "the same area".
It would be interesting to know how many crew are needed for the ships? I don't think this has been thought through, if you cap the servers at a low population, putting bums on crew seats is not going to be easy. Having played games like PS where you can have loads of players and it is still a problem, SC could be setting themselves up for a big issue here. What are the penalties of not being fully crewed, or have they realised that having no penalties will alleviate the problem?
I thought I read somewhere players might be able to hire NPCs to fill the seats if actual human players were not available.
Could have just been some fans theory crafting as well.
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon
Comments
Small zone caps was a huge factor in Crowfall’s demise. (Certainly not the only one)
But games that have PvP in general will be challenged more on this. Especially if you can take over other peoples assets.
All time classic MY NEW FAVORITE POST! (Keep laying those bricks)
"I should point out that no other company has shipped out a beta on a disc before this." - Official Mortal Online Lead Community Moderator
Proudly wearing the Harbinger badge since Dec 23, 2017.
Coined the phrase "Role-Playing a Development Team" January 2018
"Oddly Slap is the main reason I stay in these forums." - Mystichaze April 9th 2018
If you are holding out for the perfect game, the only game you play will be the waiting one.
Pretty classic bad game management, combined with very successful cult branding.
If you are holding out for the perfect game, the only game you play will be the waiting one.
I don't think that part will be the bottleneck as much as the fact this means the biggest a fleet battle scales to is a 1V1 against two Javelins and some fighters, and they'd have to understaff the Javelins just to bring in extra ships.
If you just overloaded one Javelin before going somewhere then yeah, you'd have both military and numeric dominance and no one could even field anything in comparative force against you.
With the base logic of the server mesh, there won't be the logic of a "cap" beyond the server mesh itself that is all its game-servers together simulating a single copy of the game-world.
So if a place on the game-world becomes a hotspot it probably can go beyond the intended capacity a server can cope with, at least on the static version of it because the end goal dynamic mesh is mean to spin more hardware as needed to share the workload.
What I understand based on what they said is them making areas of space overcrowded/jammed that players wouldn't be able to quantum jump to that location for example, or a queue on the ATC that won't deliver your ship to hangar immediately which was mentioned as well.
That on the initial static mesh, the dynamic one is meant to scale, and is where they stated interiors being simulated by an extra simulation node if need be.
The Shard is not the game-server, aka what they call simulation node on the context of the mesh, the shard is ALL of them simulating a copy of the entire game-world.
Like I just posted there won't be an artificial cap on a region of space when players have free movement, they can is do mechanics to prevent or discourage further travel until they have the dynamic mesh that is meant to resize simulation areas to share workload and cope with that density.
As well, things like claiming a ship on an overloaded area facing a queue until your ship is delivered on hangar for you.
On the case of that Javelin if you pack it and the interiors are simulated by a different node, then the other node simulating outside won't need to bother much with how many the ship is packing. The capital ships can carry a limited amount of fighters so they would never represent a load of anything close to 80 ships.
But everything has its limits, on games like this, especially Albion Online because I suffered and did this too, if you can move 500 people in one go, you surely can simply "win without a fight" by overwhelming a place of the map. There is not magic bullet solution to this, but I think they will push to increase server capacity as much as possible as that'll render such scenarios more uncommon.
Part of why EVE uses deferred authority layers to their server structures. They already face a regularly slow experience, but if they ran on meshed servers or even traditional ones they'd be facing complete stalls well before hitting 1000 players.
Your explanation certainly sounds like a magic bullet.
This is really not something that is a "magic bullet" unproven tech, you have SpacialOS around that in a nutshell brings many servers working together to achieve mass-scale, has been shown to work.
What SC is doing is around similar lines. Dual Universe is also around the same SpacialOS lines, but uses CAF, there's also others around.
Cloudgine for example is what Microsoft used to simulate the destruction physics of Crackdown 3 on the cloud, was now bought by Epic Games.
CAF operating on supervision trees and suffers the same concurrency issues I'd mentioned prior, they are not solving for the fundamental issue presented there. Part of the issue with them only being able to benchmark 30k actors using virtual machines.
Cloudgine was the company that worked on Crackdown 3's engine, and used cloud computing to handle large scale math-heavy processes on a server, with at most ten players interacting with each other. That physics system only runs in the 5v5 multiplayer mode.
Still sounding like magic to me compared to these buzzword examples.
It is interesting the duality presented by these recent posts.
You point at live games that already use the kind of tech that they've only partially implemented, and it's off to argue how this is something more or super challenging.
You point at something that's actually unproven in practical application and you get a list of duds as if it's proof positive that it's actually very real and people are already doing it.
It's quite the curiosity in behavior.
Here's one of the best charts that are shortest way to understand the structure of services that were and are still being created and how they generally interact: https://prezi.com/p/xk5ilzstjrhy/star-citizen-unofficial-road-to-dynamic-server-meshing/
An in-depth dive into it from the engineers who are creating it:
That'll explain it better than I ever could, they go in-depth about it on that showcase.
They also did a follow up Q&A with a lot of questions that popped about potential problems and how they're addressing them, which includes answers about latency/delays/tick rates and the replication layer.
Now if you aim to look at that and argue it's not viable and you know better... well, the only suggestion I can make is https://cloudimperiumgames.com/jobs/uk/lead-network-programmer-wilmslow
Yeah, containers, understandable.
Binding bubble? You're stream loading content to the client with a bounding range. That's the basis of many games that stream load, and a standard part of object culling. Even sleeping processes if there's nothing in bound is normal there.
The replication server description is very similar to the server node network CCP uses for deferred authority. Even the point on server nodes holding unique authority over specific entities, it's sorting actions and spitting back to a middle layer of servers that then re-sync events and adjusts for the estimated actions from deferred authority. Now this does resolve server meshing on a small scale, but if they want to mesh the entire shards together without taking a big hit to their replication layer, that's going to take something they haven't explained.
This just rolls on with the entity graph talking about being a library of parented entities that's concurrently read and written to as a world snapshot.
Even seeding, known as pooling.
The global database is just standing above that as another larger library for static entities.
Ironically, the video mentions the theoretical benefits of server meshing, but not the actual how throughout. No wonder that first link warns about deduced and speculated technologies. It also distinctly avoids the prior issues I brought up around handling speed over a meshed network, something that was also avoided by the examples of cloud computing.
It's interesting how much talk there showed all these different components and mentions they'll mesh them together, but the how of that remains unspoken. When it's the central component that's trying to be held up and discussed, that makes for an interesting observation for it to be a black hole in the details.
Problem ends up remaining that how they go about the replication server that's meshing the servers within a shard, as well as how they are expecting to mesh the shards themselves. That directly impacts the notion of how that speed and cost analysis ends up panning out.
Where there might not be a hard cap, the practical application has to be examined about what it means for "optimal" player load, and the reality that spinning up extra servers into a shard has direct give and takes on performance that limits it.
Certainly hope they resolve the client authority issues that still exist according to the Q&A too.
The biggest questions lie on the performance and scalability of mostly the replication as described there, as it's what servers and players connect to per shard. The game-server themselves, simulation nodes here, benefit from taking workload taken off them, all they need to ensure is that data flows with the minimum delay possible and if the services do the job they're supposed to do... you have your mesh.
The dynamic mesh is not talked to detail as that's not the one directly being worked on, with focus set on implementation of the static version first, most likely this will see prototyping work upon the static mesh to define details.
The foundation of all of this back and forth was that what CIG has today is working better than they thought it would so they decided to see if they could increase the number of players per server and achieve better stability than they had in the last patch. Turns out they can.
By the way, we are a long way away from having capital ships in Alpha, one reason as someone pointed out, a fully crewed cap ship, would at this time be the ONLY cap on the server making it not much fun. 100-person servers are not the goal, it's a stepping stone. I won't pretend to understand the tech beyond that. If I did, I would be knocking on CIGs door trying to get paid.
If you want a new idea, go read an old book.
In order to be insulted, I must first value your opinion.
The foundation of the conversation was how well their tech will realistically scale. PS2 can run ~400 people in action combat with physics based projectiles and vehicles in one
area. 120 people across an entire server isn't much beyond Battle Royale standards.
Yes, you can tout "but they're doing way more simulations" as to why that number is lower. The response to that is "exactly". There's a reason every real-world example Bacon tried to share demonstrated the practical limitation of cloud computing for mass real-time simulations. Mesh networking being an inherently slower to validate process isn't going go expedite that, so wedding the technology and expecting magic to happen leaves a lot of head-scratching to be done.
All time classic MY NEW FAVORITE POST! (Keep laying those bricks)
"I should point out that no other company has shipped out a beta on a disc before this." - Official Mortal Online Lead Community Moderator
Proudly wearing the Harbinger badge since Dec 23, 2017.
Coined the phrase "Role-Playing a Development Team" January 2018
"Oddly Slap is the main reason I stay in these forums." - Mystichaze April 9th 2018
Which is the type of attitude that makes me cringe, how can something that requires a team months of preparation and planning to start executing, be so easily figured out by you that's not viable within minutes, how do you have all the answers, including the ones they don't yet do? Just feels nitpicky on purpose to find something you can contest about it.
Ask Improbable how they're ten years in with four cancelled projects, three delayed, and none released while they as a company are now wandering off to mess with NFTs.
Ask Cloudgine why their technology has only managed to be demonstrated with one game on the scale of ten concurrent users in practice.
As Dual Universe where their development currently is.
Should we not ask questions of them in how those studios spent months, years, preparing and planning for what you claimed was at the least similar technology and goals?
Questioning and having doubts based on the factual history of the technology in practical application isn't "discrediting everyone working on this". Being critical of how a game is being developed is not arbitrary bias.
This isn't some small technology. It's hardly a nitpick to wonder about something that's a linchpin in how the title will scale and whether or not it can even support things like Javelins in play as an end goal.
Should people not ask if Planetside's networking layer can handle the task of running hundreds of people concurrently when they pitched the idea of a 400 player battlefield?
Which is the type of attitude that makes me cringe. how can something with known hurdles and quantifiable issues that have historically plagued a technology not bear scrutiny? This blind faith and abject hostility to any sort of doubt just brings right back the point made previously about how some fans make the whole deal around this game look like a cult.
Perhaps take a breather and regain some moderated perspective on the subject.
Some claim it never was an mmo.
The creators clearly market it as an mmo (always have).
Clear sign of a scam. And don't give me EVE or GW2 as an example, none of those games have ships with the crew size higher than server cap.
Mark my words: This will never release because they make more money on the anticipation than they would on the live game. Giving them any more money (because you cannot turn back time) is a crime against your own common sense.
No fate but what we make, so make me a ham sandwich please.
You act like those games were cancelled because of SpacialOS is not viable, this is a weak AF argument.
Games like Mavericks: Proving Grounds and Worlds Adrift faced the BS stunt of Unity with the SpacialOS license, funding dried up, development stopped, this wasn't to do with the tech not being viable, WA was live and working, Mavericks already had shown it in action.
Dual Universe it also has not to do with the that technology, it's facing general development challenges, where network runs fine the game's framerate performance is terrible for example.
Cloud technology, just like VR and others, had a rough start, complicated adoption and problems haunting it, but the state of cloud now is far from what it once was, a few years ago cloud gaming was laughed at, look at it now. It now hosts online games and MMOs as well where it once was too expensive and inefficient. With a more powerful and infrastructure comes the ease to build upon it,
At that, those pieces tech are also not dead, Epic Games snatched Cloudgine, even Crytek has integrated SpacialOS on CE and is building a large-scale BR project on it, rumored to be a Crysis title.
Certainly you can point at some things and say "this was the problem", but a) there's never one problem and b) you made a point to address as little as possible via anecdote there.
WA was shown off, but it was not demonstrated to ever work at-scale. Small demos was the most it ever showcased, much like Mavericks. And this is the problem, you want to argue that something works at scale that historically has not, by using examples that don't actually prove it.
I looked at Dual Universe's forums before commenting as well. I can safely say that what you claimed isn't nearly the scope of Dual Universe's issues, and their network is not "fine" Perhaps it's only benefit to stability was the hemorrhaging of players.
SpatialOS has integration with multiple engines, that doesn't say much of anything. And Indeed there are a few projects still theoretically going using the technology. That fails to deliver any demonstration of the technology successfully in action at scale.
Same with Epic buying Cloudgine. They bought the company four years ago as they were expanding their online services. The tech was already developed largely on UE4, and as Epic noted in the acquisition they were planning to leverage the cloud computing service to "push the creative and technical limits of games, film, animation, and visualization." You know what Unity has done since then with cloud computing? Photogrammetry.
Cloud technology has many great applications. Thing is, those strengths do not encompass every form of network task. Cloud gaming even now struggles against network capability, getting more boost from new cellular networks than anything else. MMO have always utilized parallel architecture to cloud for authoritative game systems deferred away from the client, the thing is the architecture was not trying to create that many layers and cross-communication versus the singular hubs.
Not to mention cloud computing wasn't the issue. Cloud computing and mesh network architecture aren't the same things. The subject that was questioned was the use of mesh networks to try and scale architecture that has to run at a stable speed to maintain simulation elements and user experience. Said it yourself that they've already had to backtrack and redo parts of that, and I doubt they aren't going to have to do the same many more times.
Seriously, instead of grasping for straws at every imagined slight, take a breather.
/Cheers,
Lahnmir
Kyleran on yours sincerely
'But there are many. You can play them entirely solo, and even offline. Also, you are wrong by default.'
Ikcin in response to yours sincerely debating whether or not single-player offline MMOs exist...
'This does not apply just to ED but SC or any other game. What they will get is Rebirth/X4, likely prettier but equally underwhelming and pointless.
It is incredibly difficult to design some meaningfull leg content that would fit a space ship game - simply because it is not a leg game.
It is just huge resource waste....'
Gdemami absolutely not being an armchair developer
Could have just been some fans theory crafting as well.
"True friends stab you in the front." | Oscar Wilde
"I need to finish" - Christian Wolff: The Accountant
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon