In another game? Could it be?!
Looks interesting either way.
View: https://www.youtube.com/watch?v=pdav0as54mU
Looks interesting either way.
Server Meshing....
- Thread starter Aramsolari
- Start date
CIG must have saw that video from the other studio and be like….”Hold up, we’re the OG Server Meshers!”
I haven't had the time to watch what the other game does as "server meshing", but I did watch CIGs vid. The takeaway is, and I quote
ALL CIG Devs in the vid: "We didn't expect this to work, at all"
And the thing is server meshing isn't some new form of magic, it's been done in other games for quite some time now. I guess the real issue was that they had to move everything over into this new system, and the scale of what they need to track and move is vastly different compared to something like what WoW or EVE has to deal with.
The only part of this that I haven't seen done yet (although I'm sure it's out there I just didn't hear about it cos it's such and obscure backend thing) is the dynamic tessellation of the play area into multiple servers depending on load. Come to think of it, I believe WoW does this... Anyways, lets hope CIG can keep it together and deliver a working solution is the next 3-4 years. When I say working, I mean truly working, not the like the server recovery thing that is utterly broken still.
What I really don't like about CIG vids like this is that they keep talking about things like the replication layer and server recovery as if it was working just fine in the live build.
It isn't, I haven't had a single server crash where it worked without any totally game-breaking issues like all consoles becoming unusable, ships becoming non-reactive to player input, no new missions being generated (and ofc the old ones being wiped) and so on... It's as broken as every single thing CIG has ever put out, yet they flaunt it around like it's better than perfect. It's disingenuous and I kinda feel a little bit offended that they spit in our faces with blatant lies like these. And it wasn't the first time....
ALL CIG Devs in the vid: "We didn't expect this to work, at all"
And the thing is server meshing isn't some new form of magic, it's been done in other games for quite some time now. I guess the real issue was that they had to move everything over into this new system, and the scale of what they need to track and move is vastly different compared to something like what WoW or EVE has to deal with.
The only part of this that I haven't seen done yet (although I'm sure it's out there I just didn't hear about it cos it's such and obscure backend thing) is the dynamic tessellation of the play area into multiple servers depending on load. Come to think of it, I believe WoW does this... Anyways, lets hope CIG can keep it together and deliver a working solution is the next 3-4 years. When I say working, I mean truly working, not the like the server recovery thing that is utterly broken still.
What I really don't like about CIG vids like this is that they keep talking about things like the replication layer and server recovery as if it was working just fine in the live build.
It isn't, I haven't had a single server crash where it worked without any totally game-breaking issues like all consoles becoming unusable, ships becoming non-reactive to player input, no new missions being generated (and ofc the old ones being wiped) and so on... It's as broken as every single thing CIG has ever put out, yet they flaunt it around like it's better than perfect. It's disingenuous and I kinda feel a little bit offended that they spit in our faces with blatant lies like these. And it wasn't the first time....
@Lorddarthvik You having a bad day mon? As someone who plays most every day in the roughest patches that are publically released, I have to take your post as rhetorical rather than factual.
Server meshing as a concept isn't new at all. The way that CIG intends and NEEDS for it to work IS new, and means inventing new code to get to the goal.
Unless they've dramatically re-written their backend in recent years, EvE does not use server meshing as CIG is implementing it. Typically one system or a handful of systems will occupy 1 server, and going through a jump gate (or cyno jump) moves your data onto the new server. While they spent a gigantic amount of effort to optimize the netcode and server performance, the working solution for big fights was 'time dilation' where player involvement would slow down to allow the server to hopefully hold up. If your corp or alliance KNEW there was a big fight coming up, it was possible (and a good idea!) to submit a formal request so that resources could be provisioned for it. Server meshing, in the manner that CIG is doing it, would have completely negated this problem.
The demo at CitizenCon was fantastic from several perspectives; the most impressive for me was how well synchonized the separate pieces of hardware were. The Replication layer provides the entity (say a bullet) to both servers; one doing the calculations and the other receiving data. As the bullet crosses the 'physical' border authority to decide the entitie's fate swaps, and the original server becomes the receiver of updates. The hard part is having this happen in a time frame short enough to be undetectable to the human player. And then doing it at scale for all the things. A KEY takeaway here: each DGS displays much more information than just what it 'owns'.
Dynamic Server meshing is the end goal, which adds the ability for the backend to seamlessly spin up and move players onto a new server (presumbably fresh hardware, but that is another conversation) without the players realizing it has happened. So an EvE style Fleet battle with 2000 player clients on each side might involve, say 10 dedicated game servers all communicating via the Replication layer (at least 1 server itself) which also manages the flow to and from the backend services such as long term persistence and the economy simulation servers.
Server meshing as a concept isn't new at all. The way that CIG intends and NEEDS for it to work IS new, and means inventing new code to get to the goal.
Unless they've dramatically re-written their backend in recent years, EvE does not use server meshing as CIG is implementing it. Typically one system or a handful of systems will occupy 1 server, and going through a jump gate (or cyno jump) moves your data onto the new server. While they spent a gigantic amount of effort to optimize the netcode and server performance, the working solution for big fights was 'time dilation' where player involvement would slow down to allow the server to hopefully hold up. If your corp or alliance KNEW there was a big fight coming up, it was possible (and a good idea!) to submit a formal request so that resources could be provisioned for it. Server meshing, in the manner that CIG is doing it, would have completely negated this problem.
The demo at CitizenCon was fantastic from several perspectives; the most impressive for me was how well synchonized the separate pieces of hardware were. The Replication layer provides the entity (say a bullet) to both servers; one doing the calculations and the other receiving data. As the bullet crosses the 'physical' border authority to decide the entitie's fate swaps, and the original server becomes the receiver of updates. The hard part is having this happen in a time frame short enough to be undetectable to the human player. And then doing it at scale for all the things. A KEY takeaway here: each DGS displays much more information than just what it 'owns'.
Dynamic Server meshing is the end goal, which adds the ability for the backend to seamlessly spin up and move players onto a new server (presumbably fresh hardware, but that is another conversation) without the players realizing it has happened. So an EvE style Fleet battle with 2000 player clients on each side might involve, say 10 dedicated game servers all communicating via the Replication layer (at least 1 server itself) which also manages the flow to and from the backend services such as long term persistence and the economy simulation servers.
Last edited:
If it's done right, it'll be fewer servers, not more. If you recall for the longest time we were stuck at 50 players per server. That's because everything the game needed to play was on that server. When a player loaded in, all the stuff that player owned became an entity on that server, and whales would cause lag spikes when they logged in lol.
The direction they are going is that a DGS will only run the code needed to perform functions in the game. Background functions like persistence storage management, economic transactions, mission tracking, ATC, inventory and bunches of other processes moving OUT of the DGS code has been a contributor toward the successful 400 per server/800 per shard test that happened earlier this year. So by leaning the DGS code out and making fundamental workload changes like Object Container Streaming, one server has become efficient enough to replace 8. The code that was removed is being run more efficiently on other servers which feed the results to whichever DGS requests it. Some things like the Quantum simulation (StarSim?) and master entity graphs will only ever be on their own cluster, passing data back and forth to the many replication layer servers.
This is kind of a clumsy explanation, and I do not have an accurate sense of how it it will eventually scale; they might not either at this point. But it could potentially be FAR fewer servers for the same number of players just by implementation of architectural efficiencies.
Will it work? Yes, it'll work. It's already been shown to work. Getting it to scale across an MMO is the next challenge, but even that is just details at this point.
Last edited:
Fingers crossed man! All that technogoobillygook better work!