Vapourware Scam Citizen - Only people with too much money can become StarCitizens! WOULD YOU LIKE TO KNOW MORE?

[The_Sloth_Sleeps]

So how exactly is that supposed to work? If you fly somewhere they spin up a server with pregen proc gen world, then save that data, fly somewhere else, repeat?

Is the prior tech video somehow supposed to support this?

in 1.0 version called static server meshing world will be divided into zones and each zone will be handled by different server. So for example Planet A will be handled by server 1 and planet B by server 2. This is compared to now where whole system is handled by one server that tries not to fry up. That alone is not something that is not seen in industry the major difference is that this is completely seamless and you can send missile from server A that will arrive on server B to hit something.
That version alone can reduce server strain and multiply amount of people on server a lot. Say something from 100 currently into 1000s

2.0 version called dynamic server meshing will be like name suggest dynamic version of this where world will get divided in smaller and smaller chunks depending on load and servers will spin up and spin down depending on that load. Say you have 10000 people on planet, that's too much for one server so planet gets divided into different servers where oner server handles city second one outposts third one caves and last one surface stuff. But then you have still 5k people in city so city itself goes from one server and it divides works between more and more servers distric A will have separate server district B will have another etc. But then it might be that all 5k people will want to be in same disctric so district itself will get divided into more servers. So bar will be separate server, hotel separate server, corridor separate server. The whole point of this system is to enable massive amount of people in same place at the fidelity of what you can see they are trying to do including stuff like physics, destruction system and so on. And the most important part it all works in background seamlessly so player never notices it. This kind of version has theoretical capability to hold essentially all millions of players in the same world without any instancing.

Most of MMO games work on instancing where each server can handle so much people at the same time and can't handle more than X amount of people so you need to switch server essentially starting from start or interacting with completely different people.

Then there is cutting corners. For example you won't find in any MMO advanced physics because it is nightmare to have shitload of particles that all synchronize with clients and interact that would instantly make server cry, same with complex gameplay. You can have creature attack you but it's pathfinding will be very limited because server has to do not only few creatures attacking you but also everyone else on server.

Here in theory with their magical dynamic server meshing you can have true one world without instancing or cutting corners. In theory at least. Who knows if it will be possible, only attempt at it can show if it works or not.

Version 1 could have the problem of server overload, I don't mean just compute, but also network bandwidth to that server.
Those cool scenes with thousands of objects, each one needs a real time update. Any complicated objects moving between servers (like a huge spaceship) is potentially huge amount of state and data to transfer. Also players will want to "see" beyond server borders, so to some extent servers must be synchronized to neighbours. Probably no gun fights between borders either. Will require a lot of game design to avoid taxing borders heavily.

We know from other games, that this can work if you embrace the limitations, and that lag will arise. This seems unlikely to work with an open world that they are touting however.

Version 2 I don't believe its possible, as this has even more problems than Version 1. Indeed it could easily hold millions of players, provided none of them interacted. In most conditions there will be exponential growth of network traffic.

I know of several examples of this failed idea including:-
https://www.mmorpg.com/columns/pikko-server-technology-2000103219
And of course the Dual Universe.


Whats interesting to me is how (intentionally?) the problem is misrepresented by these guys. Its not a problem of scaling computation. Rather scaling network interactions. Plus of course, there network round time, which has to be insanely low for real time simulation. You have to complete jobs on time otherwise everything sucks.

Computation can scale reasonably well by increasing cores but you will always need to be shifting lots of data around on a VERY slow network bus. Compared to a CPU or graphics card bus, this is the key difference.

 

[Myobi]

Once I see it working with the “thousands” of players engaged in PvP with a bunch of mothers fuckers named 윤서, 태연 and 새롬 running amok with 800 ping blasting the sound of vacuum cleaners on their open mics, I'll consider buying an Idris.

 

[Irxy]

So how exactly is that supposed to work? If you fly somewhere they spin up a server with pregen proc gen world, then save that data, fly somewhere else, repeat?

Is the prior tech video somehow supposed to support this?

in 1.0 version called static server meshing world will be divided into zones and each zone will be handled by different server. So for example Planet A will be handled by server 1 and planet B by server 2. This is compared to now where whole system is handled by one server that tries not to fry up. That alone is not something that is not seen in industry the major difference is that this is completely seamless and you can send missile from server A that will arrive on server B to hit something.
That version alone can reduce server strain and multiply amount of people on server a lot. Say something from 100 currently into 1000s

2.0 version called dynamic server meshing will be like name suggest dynamic version of this where world will get divided in smaller and smaller chunks depending on load and servers will spin up and spin down depending on that load. Say you have 10000 people on planet, that's too much for one server so planet gets divided into different servers where oner server handles city second one outposts third one caves and last one surface stuff. But then you have still 5k people in city so city itself goes from one server and it divides works between more and more servers distric A will have separate server district B will have another etc. But then it might be that all 5k people will want to be in same disctric so district itself will get divided into more servers. So bar will be separate server, hotel separate server, corridor separate server. The whole point of this system is to enable massive amount of people in same place at the fidelity of what you can see they are trying to do including stuff like physics, destruction system and so on. And the most important part it all works in background seamlessly so player never notices it. This kind of version has theoretical capability to hold essentially all millions of players in the same world without any instancing.

Most of MMO games work on instancing where each server can handle so much people at the same time and can't handle more than X amount of people so you need to switch server essentially starting from start or interacting with completely different people.

Then there is cutting corners. For example you won't find in any MMO advanced physics because it is nightmare to have shitload of particles that all synchronize with clients and interact that would instantly make server cry, same with complex gameplay. You can have creature attack you but it's pathfinding will be very limited because server has to do not only few creatures attacking you but also everyone else on server.

Here in theory with their magical dynamic server meshing you can have true one world without instancing or cutting corners. In theory at least. Who knows if it will be possible, only attempt at it can show if it works or not.

That's not going to work. Well, it will work in case of large zones and will allow seamless transition, which is a fine gimmick, but at the cost of increasing server load, not decreasing it.
That is, it won't work in situations like in that video with a small scene divided into 3 servers. Instancing only makes sense when each instance is isolated, that is, they don't require any information from each other to function properly.
In that example each of the servers obviously neads to know everything which happens in the other ones to function properly. This is not only useless but also increases the overall load.

 

[Perkel]

Version 1 could have the problem of server overload, I don't mean just compute, but also network bandwidth to that server.
Those cool scenes with thousands of objects, each one needs a real time update. Any complicated objects moving between servers (like a huge spaceship) is potentially huge amount of state and data to transfer. Also players will want to "see" beyond server borders, so to some extent servers must be synchronized to neighbours. Probably no gun fights between borders either. Will require a lot of game design to avoid taxing borders heavily.

We know from other games, that this can work if you embrace the limitations, and that lag will arise. This seems unlikely to work with an open world that they are touting however.

Version 2 I don't believe its possible, as this has even more problems than Version 1. Indeed it could easily hold millions of players, provided none of them interacted. In most conditions there will be exponential growth of network traffic.

I know of several examples of this failed idea including:-
And of course the Dual Universe.

Whats interesting to me is how (intentionally?) the problem is misrepresented by these guys. Its not a problem of scaling computation. Rather scaling network interactions. Plus of course, there network round time, which has to be insanely low for real time simulation. You have to complete jobs on time otherwise everything sucks.

Computation can scale reasonably well by increasing cores but you will always need to be shifting lots of data around on a VERY slow network bus. Compared to a CPU or graphics card bus, this is the key difference.

I don't think the issue is server overload. In fact this is precisely tech to reduce server load not to increase it. ATM servers run around 5-10fps with 100 people in one system. If you add another 100 players it will further drop. And that is not the issue of server but how everything is handled. If there is 1 player at planet A and 99 players at planet B server still has to render planet A as if population was split equally. Now let those other 99 people run around the system and suddenly server has to render stuff everywhere. Since most of operation are server side not client side (anti-cheating) it means that server has to calculate pathfinding not client, server has to calculate bullet trajectory not client and so on.

With version 1 they are effectively spliting work. Previously server 1 would handle whole system but with this supposed 1.0 servermeshing in place same server will handle only small part of same system which should lead to either improved performance or vastly more people in same system.

Futher version 2 is basically dynamic balancing which is supposed to essentially either save cost or vastly expand players numbers. You can set up 1.0 version to have server for every ship, every room and so on but this would be expensive as you would have to run 100s of servers per system maybe even thousands. Version 2 whole point is to like i said balance out load. If planet A doesn't have anyone there then all servers will shut down and instead move over to some other place where there are more players.

The real problem in this is not server overload but syncing clients and servers and edge conditions.

So many servers running at the same time means they have to talk with each other in order to agree on what happened. You can't have dude shooting your from one server and your server not registering those bullets or registering those bullets flying into your direction with 500ms delay.

They have plan for that called replication layer. Essentially no server will be running game live. All of them are supposed to work kind of like clients themselves and their memory and their instances working as cache for other database which decides everything. This is why in case of server crashing they shown in video you supposedly can go back to exact same place you crashed and exact same state.

Either way. IF they will be able to do that then a lot of companies will be trying to get this from CIG.

 

[Crispy]

all millions of players in the same world without any instancing

 

[The_Sloth_Sleeps]

Version 1 could have the problem of server overload, I don't mean just compute, but also network bandwidth to that server.
Those cool scenes with thousands of objects, each one needs a real time update. Any complicated objects moving between servers (like a huge spaceship) is potentially huge amount of state and data to transfer. Also players will want to "see" beyond server borders, so to some extent servers must be synchronized to neighbours. Probably no gun fights between borders either. Will require a lot of game design to avoid taxing borders heavily.

We know from other games, that this can work if you embrace the limitations, and that lag will arise. This seems unlikely to work with an open world that they are touting however.

Version 2 I don't believe its possible, as this has even more problems than Version 1. Indeed it could easily hold millions of players, provided none of them interacted. In most conditions there will be exponential growth of network traffic.

I know of several examples of this failed idea including:-
And of course the Dual Universe.

Whats interesting to me is how (intentionally?) the problem is misrepresented by these guys. Its not a problem of scaling computation. Rather scaling network interactions. Plus of course, there network round time, which has to be insanely low for real time simulation. You have to complete jobs on time otherwise everything sucks.

Computation can scale reasonably well by increasing cores but you will always need to be shifting lots of data around on a VERY slow network bus. Compared to a CPU or graphics card bus, this is the key difference.

They have plan for that called replication layer. Essentially no server will be running game live. All of them are supposed to work kind of like clients themselves and their memory and their instances working as cache for other database which decides everything. This is why in case of server crashing they shown in video you supposedly can go back to exact same place you crashed and exact same state.

I don't understand the connection between a replication layer and a magic solution.
All a replication layer is a cached backup for rolling back to when crashes happen. And replication layers are still REALLY slow because they use some kind of networking bus.

 

[Perkel]

I don't understand the connection between a replication layer and a magic solution.
All a replication layer is a cached backup for rolling back to when crashes happen. And replication layers are still REALLY slow because they use some kind of networking bus.

This is their goal for networking structure. servers hold immidiate data which gets sent to replication layer which sits on top of servers and is holding LIVE data which is what clients interact with and database interacts with.

Basically everything talks to replication layer and you don't need to sync servers between each other as each server only syncs with replication layer instead of X other servers.

Replication layer doesn't calculate anything. It just keeps the state of game like player positions, bullet positions etc. If there is call to change something in database by server it will then talk to database update it but it won't keep that information on hand if not needed.

all millions of players in the same world without any instancing

sounds like bullshit yeah. The issue with servers is that keeping track of what player does is very easy, keeping track of huge amount of players over huge scale of word is hard due to inherent limits to mathematics when it comes to pathfinding etc. So this essentially means that a lot of players tracked by single server in very very very small space is very easy thing to do, keeping same people over vast distances is very hard thing to do. One server keeping track of single 10m x10m room/corridor whatever with 20 people is something you could do even in 90s.

Say you have station and each room, each corridor, etc. is separate server and in each room/corridor whatever you have 20 people. City will have around 500 rooms. 500x20= 10 000 players add to that say 20 cities (SC already has 4) with same setup 200 000 players add 100 outposts (rn game has around 50) with dozens of rooms let's say 100x20x20=40 000, 100 stations (game has around 26 right now (100 rooms) and you quickly arrive at 100x100x20= 200 000. Ignore stuff like space, land, caves and so on and even without those you arrive at nearly 500 000.

To run this you would have to use 500x20 + 100x20 + 100x100 = 10 000 + 2 000 + 10 000 = 22 000 threads / epyc 200thread cpu = 110 cpus / 2 dual socket servers = 55 servers

Obviously this is only networking side. Obviously you can't display 500 000 people at the same time on singular room in player view without any graphical tricks. They talked at citizencon that they will be effectively culling stuff in creative way from player view to keep FPS high.

Like i said if this thing will work they biggest obstacle is syncing everything together. And that seems to me impossible task to me. Too many problems with regions, replication layer could fail etc.

 

[Perkel]

To further make a point. Using Dwarf Fortress.

To play 3x3 embark you easily can do it easily with 1 core up to 200 dwarves and the amount of simulation beats even SC.
Which amounts to 300x300 (map) x 200(dwarves) pathfinding calculation which equals (if we would assume relative point of 1 and ignore complex math) which gives us 18 000 000 pathfinding points every frame

To play 100x100 embark you need CPU from future) because because despite increasing map size just by factor of ~33 you increase amount of pathfinding operation points from 18 000 000 to 10000 x 10000 x 200 = 2 000 000 which is not 33 more but 111 times more.

And this is JUST pathfinding. Add to that everything else and it compounds even more.

So:
keeping very small area in server with a lot of people = easy
keeping huge area in server with a lot of people = incredibly hard for server

 

[RobotSquirrel]

Except that those 18,000,000 points of path finding operations aren't needed due to "bad" (read it as bad = default) implementation. You don't need to calculate all 18,000,000 points, only the change in direction because its the same exact result - A* can be very wasteful. Plus you're using A* so you have options that could also reduce the performance hit even further (such as per-generating your paths to maximize reuse - eg. Every character can only enter a room through one door and one hallway, there's no reason to generate A* on every character, just generate a path from the hallway to the door and send it to every character instead). Also there's no need to run a path from one side of the map to the other when you can simple create a list of paths and only calculate when hitting each milestone saving you having to do one really big A* loop, better to split them into smaller A* loops as its less disruptive. This is normally how I optimize my A* implementation because it means then it can run in the background and keep the FPS high. Also never-mind that 18,000,000 points is still damn impressive.

That said however your point is valid, you only have so much in the tank that you can allocate to processing. There is just no way in hell with all the required computational power that SC will be single-shard no-instancing, and this is even with the fact that SC's pathfinding isn't A* meaning its probably even more expensive on computational cost.

 

[Perkel]

That said however your point is valid, you only have so much in the tank that you can allocate to processing. There is just no way in hell with all the required computational power that SC will be single-shard no-instancing, and this is even with the fact that SC's pathfinding isn't A* meaning its probably even more expensive on computational cost.

My point isn't about specific implementation of pathfinding etc. My point is that as you scale the word your computation goes up squared for 2D game and for 3D game cubed and for cpu it is much easier to calculate 10x10 than 10000000x10000000. By dividing everything into small bits you are essentially making everything very efficient. It is basically parallelism gpu style but for servers.

Like i said you are gaining thread/server performance but you trade that for latency, mismatching data etc. which is something i think it can't be done at scale they are trying to use it. In theory at least their idea is sound but real life latency is bane of every large project. People already have issues with static databases and software for 1000s of people that need to check with database stuff and here we have whole game.

I didn't talk about single shard. Imho it is impossible because you have latency between europe/US/oceania/asia.
But single europe shard ? or Us shard ? As long as everything works as they say ability to have milion player on single shard is possible. The issue becomes game design, latency, game rules etc.

 

[The_Sloth_Sleeps]

I don't understand the connection between a replication layer and a magic solution.
All a replication layer is a cached backup for rolling back to when crashes happen. And replication layers are still REALLY slow because they use some kind of networking bus.

This is their goal for networking structure. servers hold immidiate data which gets sent to replication layer which sits on top of servers and is holding LIVE data which is what clients interact with and database interacts with.

Basically everything talks to replication layer and you don't need to sync servers between each other as each server only syncs with replication layer instead of X other servers.

Replication layer doesn't calculate anything. It just keeps the state of game like player positions, bullet positions etc. If there is call to change something in database by server it will then talk to database update it but it won't keep that information on hand if not needed.

all millions of players in the same world without any instancing

sounds like bullshit yeah. The issue with servers is that keeping track of what player does is very easy, keeping track of huge amount of players over huge scale of word is hard due to inherent limits to mathematics when it comes to pathfinding etc. So this essentially means that a lot of players tracked by single server in very very very small space is very easy thing to do, keeping same people over vast distances is very hard thing to do. One server keeping track of single 10m x10m room/corridor whatever with 20 people is something you could do even in 90s.

Say you have station and each room, each corridor, etc. is separate server and in each room/corridor whatever you have 20 people. City will have around 500 rooms. 500x20= 10 000 players add to that say 20 cities (SC already has 4) with same setup 200 000 players add 100 outposts (rn game has around 50) with dozens of rooms let's say 100x20x20=40 000, 100 stations (game has around 26 right now (100 rooms) and you quickly arrive at 100x100x20= 200 000. Ignore stuff like space, land, caves and so on and even without those you arrive at nearly 500 000.

To run this you would have to use 500x20 + 100x20 + 100x100 = 10 000 + 2 000 + 10 000 = 22 000 threads / epyc 200thread cpu = 110 cpus / 2 dual socket servers = 55 servers

Obviously this is only networking side. Obviously you can't display 500 000 people at the same time on singular room in player view without any graphical tricks. They talked at citizencon that they will be effectively culling stuff in creative way from player view to keep FPS high.

Like i said if this thing will work they biggest obstacle is syncing everything together. And that seems to me impossible task to me. Too many problems with regions, replication layer could fail etc.

So basically synchronizing terrabytes of data from around the world, in milliseconds....hrmmm sounds plausible.

 

[SlamDunk]

25-minute recap of CitizenCon 2023:

 

[Myobi]

So basically synchronizing terrabytes of data from around the world, in milliseconds....hrmmm sounds plausible.

I mean, even if its possible, how many cunts running around will your PC be able to render without the FPS drop turn it into a power point presentation?

Because CIG is selling space ships with 100-man max crews while talking about "thousands" of players engaged in PvP...

 

[The_Sloth_Sleeps]

So basically synchronizing terrabytes of data from around the world, in milliseconds....hrmmm sounds plausible.

I mean, even if its possible, how many cunts running around will your PC be able to render without the FPS drop turn it into a power point presentation?

Because CIG is selling space ships with 100-man max crews while talking about "thousands" of players engaged in PvP...

Ya I think we can call bullshit on this tech due to any one of the twenty of so given reasons already.

I recall a company called Spatial OS who had pretty much exactly the same approach, but they still haven't actually made anything with it.

In fact the tech sounds really similar to how IMDG's (e.g. Hazelcast) do stuff. Of course those companies don't make absurd promises. Nor does banking data have to get distributed in the same way as game data.

 

[Irxy]

To further make a point. Using Dwarf Fortress.

I do not think such comparison is very useful, since dwarf fortress load comes from a complex ai simulation - which is not needed for MMOs, since all those roles are supposed to be taken by players, no?
Either way, the more I think about server meshing, the more it sounds a completely SC-specific issue.
The idea is simply to make dynamic instances to increase the hilariously low players per server limit, maybe they'll even reach Ultima Online numbers, who knows!
Which is in no way going to solve an issue of server overload if all those players decide to move into a single scene for some event.

 

[Grotesque]

 

[Perkel]

To further make a point. Using Dwarf Fortress.

I do not think such comparison is very useful, since dwarf fortress load comes from a complex ai simulation - which is not needed for MMOs, since all those roles are supposed to be taken by players, no?
Either way, the more I think about server meshing, the more it sounds a completely SC-specific issue.
The idea is simply to make dynamic instances to increase the hilariously low players per server limit, maybe they'll even reach Ultima Online numbers, who knows!
Which is in no way going to solve an issue of server overload if all those players decide to move into a single scene for some event.

Pathfinding was just example. There are ton of other stuff that also needs to happen. The point is that 10x10 is much easier to calculate for server than 100000x100000.

Also instancing means you can't interact with anything outside of instance. In case of SC approach someone is on some server but he can interact with everything else outside of that server. So it is not really instancing.

ATM SC has instancing in form of 1 server per 100 people.

 

[Perkel]

I don't understand the connection between a replication layer and a magic solution.
All a replication layer is a cached backup for rolling back to when crashes happen. And replication layers are still REALLY slow because they use some kind of networking bus.

This is their goal for networking structure. servers hold immidiate data which gets sent to replication layer which sits on top of servers and is holding LIVE data which is what clients interact with and database interacts with.

Basically everything talks to replication layer and you don't need to sync servers between each other as each server only syncs with replication layer instead of X other servers.

Replication layer doesn't calculate anything. It just keeps the state of game like player positions, bullet positions etc. If there is call to change something in database by server it will then talk to database update it but it won't keep that information on hand if not needed.

all millions of players in the same world without any instancing

sounds like bullshit yeah. The issue with servers is that keeping track of what player does is very easy, keeping track of huge amount of players over huge scale of word is hard due to inherent limits to mathematics when it comes to pathfinding etc. So this essentially means that a lot of players tracked by single server in very very very small space is very easy thing to do, keeping same people over vast distances is very hard thing to do. One server keeping track of single 10m x10m room/corridor whatever with 20 people is something you could do even in 90s.

Say you have station and each room, each corridor, etc. is separate server and in each room/corridor whatever you have 20 people. City will have around 500 rooms. 500x20= 10 000 players add to that say 20 cities (SC already has 4) with same setup 200 000 players add 100 outposts (rn game has around 50) with dozens of rooms let's say 100x20x20=40 000, 100 stations (game has around 26 right now (100 rooms) and you quickly arrive at 100x100x20= 200 000. Ignore stuff like space, land, caves and so on and even without those you arrive at nearly 500 000.

To run this you would have to use 500x20 + 100x20 + 100x100 = 10 000 + 2 000 + 10 000 = 22 000 threads / epyc 200thread cpu = 110 cpus / 2 dual socket servers = 55 servers

Obviously this is only networking side. Obviously you can't display 500 000 people at the same time on singular room in player view without any graphical tricks. They talked at citizencon that they will be effectively culling stuff in creative way from player view to keep FPS high.

Like i said if this thing will work they biggest obstacle is syncing everything together. And that seems to me impossible task to me. Too many problems with regions, replication layer could fail etc.

So basically synchronizing terrabytes of data from around the world, in milliseconds....hrmmm sounds plausible.

Replication layer only handles values. It does not handle textures and so on. So at best 100s of megs per second with huge amount of players which either way is split rather than same 100s of megs per client.

 

[Perkel]

all presentations edited into one video:

 

[AN4RCHID]

all presentations edited into one video:

The resource management and the UI stuff are looking really nice

 

[pOcHa]

i swear, if i hear "server meshing" just one more time...

is scam citizen web 3.0 of games?

 

[mediocrepoet]

i swear, if i hear "server meshing" just one more time...

is scam citizen web 3.0 of games?

Who cares? Pay now! Pay later! Pay often!

 

[RobotSquirrel]

which is not needed for MMOs, since all those roles are supposed to be taken by players, no?

That's not true for SC, Quantum is supposed to give NPCs "roles" in the background so that the server seems more alive than it actually is.
https://starcitizen.tools/Quantum_(game_system)

That said its one of those jesus techs again, there's no proof that Quantum will work at scale.

 

[The_Sloth_Sleeps]

To be entirely fair, in that video they make no promises about what this can or cannot do. They just say it will be an improvement over what they have currently - 50 players, but thats the only indication of performance they have.

Its still completely misleading to show a "demo" (or perhaps they are just concepts) of huge scale worlds and imply through suggestion that people are going to get those experiences in multiplayer, without some really really big compromises or limitations.

 

[Perkel]

someone managed to catch this:

star engine demo trailer starts with similar scene as wing commander