Let’s say you write an amazing ECS game utilising the full power of your target or development platform.
Then you want to take it multi-player only the shear bandwidth needed to keep systems updated at 60hz is way too high…
How can you still have the raw power of ECS and run a networked game?
Examples: You could take advantage of ECS to…
Have many more moving parts to your game e.g. High Unit Counts, Fragmented Explosions.
You could have many more players or NPC’s in your game.
You could have a more dynamic world in your game e.g. waves, asteroids, growth, evolution.
A living breathing dynamic populated city.
The thing is ECS tends towards simple atomic systems, so you will be developing an interactive simulation, whereas Networking tends towards command based heirarchical systems.
How will we manage this architecural duality and still get the best performance across a range of hardware platforms in a networked game?
Side Note: What is the maximum bandwidth of your CPU is it Ghz * bits * Cores, or is it limited to DRAM Mhz * bits * 2 (dual channel) or Gflops and what does that equate to the potential of Burst/ECS in terms of bandwidth?
so when you are talking about bandwidth are you talking about the volume of etities that have to traverse a network or more about how those entities and systems get simulated on a server via P2P?. Im assuming the later but your use of bandwidth sounds a little ambiguous.
But for either I dont think ECS will take up too much bandwidth for either situation. At the end of the day its easier to make ECS more modular than OOP thus allowing you to dictate what is and isnt run/sent. For that alone ECS is a primate candidate for both scenarios.
If talking strictly about bandwidth, this is amount of data sent over network over time.
From that perspective, I don’t expect any difference, how OOP or ECS sends / receives data.
Your application sends as much data as you design to send. In either paradigm, can be sent single byte, or HD image.
What is making difference in my understanding, is immediate handling of data, when is sent / received to / from network.
ECS will be able surely make more relevant work and check, behind scene, than Classic OOP.
Have you seen last Unity talk, about network implementation in their FPS?
Why running network game specifically cost the “raw power of ECS”? Implementing any networking over any kind of programming will cost more resource. How is this specific for ECS?
You are suggesting that ECS is not suitable for network game because of (CPU?) bandwidth problem. Which implies that you think ECS take more CPU bandwidth than usual and there isn’t enough for CPU to process more commands for networking.
Why do you think ECS uses more CPU bandwidth than the old way? In my opinion, ECS should be able to achieve less command count because of SIMD compared to using the old way to write the same thing.
Why networking would be able to add more bandwidth to go over a certain threshold you are worrying about? That is, why just ECS is fine but as soon as we add networking it is not? Why the old way is fine even with a network? Is networking more costly spcifically for ECS and more than the old way?
I believe this is the answer to my prior question, but I don’t get it. Why “command based heirarchical systems” would specifically cost raw power of “simple atomic systems”? This sentence below suggest that you know that the two architecture/duality (network and ECS) is difficult to coexist. Please explain a bit? Why non-ECS game and networking does not have this problem?
Example A:
Imagine an RTS game where you want unit counts in the thousands per player as well as missiles, rockets, beams and bolts firring and you want to have 128 players. This is theoretically possible based on the ECS demos (well maybe 64 players but even then…)
However every missle launch and unit move has to go to the server and back to the clients at 60 hz.
For simplicity we update the float3 of all the entities along with a int for unit ID so thats:
16 bytes x 128 x 1000 x 3 = 6,144,000
or 6.14 Megabytes @ 60 hz = 368.64 Megabytes a second
or 2,949.12 Megabits a second (note most people only have a few megabits a second upload speed).
Example B:
Imagine a 3D asteroid style game with graphics an tens of thousnads of asteroids that collide and break apart and can cascade into deadly shards for the players. That’s right we want to have at least 64 players battling it out in this deadly field of asteroids.
Assuming similar networking to the RTS game we have:
16 bytes x ((32 x 3) + 100,000) = 1,601,024
or 1.6 Megabytes @ 60 hz = 96 MB/s
or 768.49 Megabits a second
This is just a couple of simple examples but my point is a game capable of running smoothly within ECS on good hardware could be a bandwidth hog when you move it to multi-player.
Of course you will build your game from the outset with multi-player in mind and not get carried away with the power of ECS and never have this problem.
Instead you will have more effects and juice in your game which just turns all that ECS potential into GPU based particles and effects.
You only syncing states periodically.
For deterministic system, you mainly handle user inputs.
Have you ever seen zero-k ? For less familiar maybe Total Annihilation, or later Supreme commander will ring a bell. There is a lot common between games.
It is a single threaded, written in lua over decade old game, driven mainly by voluntaries.
Is able handle games of 16 vs 16 player for whole world, with thousands of entities on single map. And whats more, even more player can join as spectator.
This game is 3D, so high is also taken into account, for projectiles, submerged, jumping, thrown and flying units.
Is deterministic and handles replays reliably, mainly by saving users inputs.
Therefore, every game replay is rather small files. All multiplayer games session weather short as 30min to even 2+ hours, are stored on the serve. So anyone can replay. And also are used, to players, who do non’t play fair play. Bans are based on replays and time stamp.
Btw game is free and now on Steam, since few months, if anyone is curious.
This is the result, when person do not familiarize self with a topic, before asking question.
I bet, my responses won’t be addressed by OP, since maybe are too technical. At least that was the usual case in the past.
these issues do not only apply to ECS but OOP as well. Much of the same thought process for OOP would apply to ECS. As far as your RTS examples go most online RTS games rely heavily on deterministic code. This way you only need to send small amounts of data and the client will properly simulate the world. Unity is trying to make a more deterministic Burst Compiler to guarantee determinism on all any platform.
Just for ref check this video out here from one of my fav games Star Citizen. In the top left you see some data that is used to create the faces. Because the system is run in a deterministic way you can use very little data to create drastic changes in the characters look. Now imagine trying to send the detail of every custom created character over a network everytime someone loads into your server. For a high poly mesh that would take way too much data. Enough data to eclipse the examples you listed. Thankfully they will never need to fully transmit every poly position. They would just send a small packet of data maybe 16k or something that defines the characters and let its internal systems work out the rest.
Ok, thanks for the explanation. You mistake is that you are trying to ECS-ifiy networking in a wrong way, because you think ECS is massive in amount of entity (than usual) and so the synchronization required for all of them must be massive (than usual). The way to turn network code to ECS should be just replacing a communication packet with some kind of entity. And replace a code reading them with systems. Normal game do not have a packet to sync a cosmetic particle location and so does ECS game. That packet should have already been designed to be small and make the game run deterministically regardless of ECS or not.
In addition to @5argon says - no one not sent raw data over network, always uses binary compression, and with small grouoped data and compression, data veeeery small.
Same way you create a networked game without it. You seem to be under the impression that ECS will be first time we can saturate a network connection, but we’ve been able to do this from day one for every network technology released.
One method mentioned earlier was client-side prediction. It’s primarily used to hide the negative effects of latency but it’s just as applicable for bandwidth because you’re transmitting less data (eg the direction and speed of an entity every few frames rather than the exact position every frame).
Compression is another great way to reduce bandwidth consumption. Supporting compression can be as easy as just passing your data through a DeflateStream (link to free asset below) before passing the data to the network library you’re using.
Finally, though it wouldn’t surprise me if there were more ways I just wasn’t aware of, you can restrict the data you pass to a client based on whether they need to know it right at that moment. If a unit is behind a fog of war, for example, you don’t need to know what it’s doing.
If you need support for replays you can always just alter or avoid techniques that get in the way of them. None of these techniques are set in stone nor are they all strictly required.
That said if we’re talking about PVP then you typically have a host server that ensures everyone is playing fairly. Since that server would need access to everyone’s data it can be responsible for providing the replay data to a client on demand.
i think it’s good to record the Player input’s command and use the command system to replay and simulate the gaming…so just need to record every tick’s input if command exist. right ?
so if use ecs we can build this logic systems to simulate the total game easy.
the server even don’t need to playing when pvp happens ?
I have never implemented such a complexity myself, but I keep a tab in case I’ll have to go there, here is my list from observation:
1- Let’s not forget culling, you cull data per clients “views”
2- determinism, which allow to reasonably guess missing data or probable future state, or compensate for delay by predicting “the present”. Also help detect bogus state.
3- compression:
a. data delta, you probably don’t need the full range of the data, given some known constrain (like max speed) you could probably use less bit to encode
b. packing, since you have less bit for data you can put more data in a single packet
c. pure compression, ye olde
4- low and variable update speed and size
a. low update speed, couple with determinism to recreate the game state
b. variable update speed for stuff that don’t need constant refresh, probably sort by priority (like threat, distance or animation)
c. variable data size, you can use delta for a certain number of entity, and periodically refresh their state with proper full data, since you aren’t sending full state at the same time at all time, you have reduce data load
5- command rather than state, if state can be guarantee to be in sync, you can just send command to the client, that can resolve many unit at the same time (let say you have unit organised in squad formation, sending a single command to the whole troop work with determinism to get the exact same end result), this is design sensitive.
6- player prediction, the player is mostly responsible for the randomness, so you can probably have metric based on the frequency of input of a player, and even send data from the client to reflect the player state to control the update rate, in fact it can double as cheat detection to find non human pattern, which mean it can also used with ML technique (as low as markov process) to figure out the player pattern based on the current context he is in. Also based on the current player state and prediction, couple with determinism, you can also try to predict the probable next view of that player and prepare the data to send.
First major step, is to ensure your 2d/3d engine is deterministic. From that point, if you know initial state of a game, you can exactly predict and evaluate, what will be future state in x time. This must provide, you can replicate exact states, on each player game, and os. Floating points may become your biggest enemy.
I’m just surprised that no one mentioned that code architecture in Overwatch is pure ECS
And I’d put it this way: It doesn’t matter what your architecture is, given that you have the same level of determinism, you need the same data to synchronize game instances.
If you can write on a sheet of paper what minimum data you need to figure out how to make two games look the same, that’s your network data right there.
And in fact, it is easier to use that network data and apply it to the game world in ECS because you can just replace or add a component and a system that does that without rewriting existing code.
Also, originally ECS was first made for a multiplayer game.
