Multiplayer ECS/DOTS with about 450 players per Scene

Unity Engine
, ,
1

Im currently working on a 3D multiplayer shooter rpg game with atleast 500 enemies and 5k-10k bullets.

At the moment im porting it to ECS/DOTS for performance reasons.
But the real end goal is to have a multiplayer game with about 400-500 players in a starting area(Scene) with no enemies, and then about 100 people in another Scene with enemies.

Just to be clear, the players in Scene A will not be able to interact with players in Scene B, they might both be instanced on the same server though.

Scene A will be a sort of safezone with no enemies, but because there are at max 400 to 500 players, each able to shoot say 20 bullets a second, it would peak at 10.000 bullets a second, ofcourse it wil be extremely rare that all players in the safezone will randomly start shooting at the same time, but it can happen.

Then take into account, the use of special abilities, like throwing a bomb, or creating a particle effect around the player, or boosting all players attack in a certain radius of the player performing the special ability. This can all also happen in the safezone.

To make things more performant in Scene B, lets just call it the Forest, im aiming for a 100 to 120 players with 500-100 enemies, it will be a big open forest type map, which means players will be spread out all over the place, with enemies inbetween them also moving and shooting at them, so again you could expect in the range of 5k-10k active bullets with just 100 players in the Dungeon Scene and about 500-1000 enemies max, whichever is feasible.

My question is, since netCode is primarily being built right now for max 80 players, what other networking solution should I use for this specific project, considering Im using ECS/DOTS? (for atleast Enemies, all bullets, players and maybe special abilities)

TL;DR:
I’m making an online MMO type game, with about 400-500 players and 0 enemies active, OR 100 players and 500-1000 enemies active in a different Scene(like a dungeon). Considering the need for like 8k-10k active bullets all over the dungeon map because players will be spread over a very large area, all of them fighting different enemies, which also fire a lot of shots back.

My questions are twofold,

  1. I want to make atleast all the bullets, the enemies, the player and maybe the players special abilities with ECS/DOTS.
    Should I keep the inventory, items, equipment, map, trees, player stats, player health etc, on MonoBehaviours, or should I make a pure ECS game, considering the end goal is to make it into an MMO as described above, the real question is, in which case would the networking be easier? Pure ECS networking, or Monobehaviours+ECS networking?

  2. Considering question 1. What networking solution should I use?

Thanks, I appreciate the help.

2

To even bite such scale multiplier, you need understand principles and limitation of the network bandwidth.
You should build first some basics prototype to see what you can and can not do.
Then use DOTS net solution, to learn how it works and what you can do with it.
Once you understand problems and challenge, you should recognize, if to use UDP, or TCP protocols.
And finally, you can considering using custom socket solution, for best performance.

The thing to be in the mind, you need send over the network only needed data and when is needed. Not all data every frame.

1 Like
3

You picked the biggest mountain there is to climb in game development today from production and operation standpoint today. MMOs. A Shooter MMO nonetheless it seems.

There is so much involved here. Even if you forget Runtime performance and DOTS for a second. The entire Networking Stack that can even remotely come close to delivering scale of MMO on Production ready Standards , in fact even experimental, doesn’t exist out there for Unity landscape. Unity’s own ECS NetCode solution is barely aiming for sub-100 Player count for e.g and that for short session based games like FPS.

You gotta pretty much build one from scratch and/or hack-do with commercial solutions that can have hefty charges and are no where end-to-end production ready. If you start doing some research on just basic networking fundamentals to get a multiplayer game working right , there are so many fundamentals that you gotta account for like Delta Snapshots , Client Prediction/Reconciliation , Lag Compensation , Interest Management etc etc that’s going to be intense work on its own.

Of little understanding i have of MMOs , a lot of them have their servers written separately like a standalone .NET application to be as fast and lightweight as possible.In MMO your server application gotta be persistent and i doubt Unity can deliver persistence-stability for over long duration like weeks and such where you would be dealing with integer overflow etc. Then there is whole issue with server boundaries when going for seamless worlds where u gotta work with sharding if you ever delve into that.

Do your research , start small.

5 Likes
4

Isn’t that exactly the next big Unity sample project being worked on? Multiplayer Open World Shooter? I remember reading here something about that.

5

Blizzard’s Overwatch uses an ECS structure in C++, so I assume their performance would be somewhat similar to DOTS. But if I recall correctly, they said they wouldn’t raise the 12 player capacity even for custom games for stability reasons. So if I were a betting man, I’d say things would turn a bit unstable around that amount of players. But I guess it all depends on how complex your game is, how much data needs to be sent, what parts of your game run locally vs what runs on the server, etc etc. My guess is that if Unity’s own Netcode solution can only support up to 80 players, third party solutions would have difficulty supporting more than that as well.

I hope you’re remembering correctly, that would be a pretty cool sample! Though I hope they do update the older samples, a lot of them are outdated (FPS sample is more than a year old, even though they said it would get updated at the end of last year) and some are even completely broken.

6

Actually, I coincidentally just found something about exactly what you were referencing: this was mentioned in the 2020 roadmap.