DOTS NetCode for MMORPG

I want to use NetCode for MMORPG-scale games, but I'm not sure if It's a good fit for this purpose. My task is to make sure that there can be from 1000 to 3000 players on the same server at the same time, but according to the description of NetCode, at the moment It can handle about 80 connections. In the future, as I understand, they promise to process 80+ connections, but how much more than 80 will it be? Will it be enough for my purposes, or should I use my own network solution?

 

MMORPG networking is very specific. In my experience (which is very near to none in practice, as I mostly did research about it), you generally want to have ver lightweight algorithm in order for your server to be able to process those 3000 players without blowing up. From what I know, the current NetCode is oriented toward the "MOBA" game-style, and the last time I checked, they talked more about 16 players than 80, but my info are probably outdated.
Their goal is to provide a network solution with authoritative server, client prediction, reconciliation, rollback etc... This is something very important for say, FPS or actual MOBA, but you most probably want to avoid that for an MMO architecture.

For example, again from what I know (did that research about 8 years ago), World Of Warcraft movement system uses simple "commands" for movement where the client send messages to the server like "I start to move in that direction"
"I stopped", and the server simply replicate this to the players around.
This means there's is no "world state" being sent (full or delta) at specific time.
Of course there are probably some "sync point" or some information sent to ensure simulations doesn't get too offseted (this is why you can sometime see your mate "teleport" around when the connection is bad). In addition, the server probably also check some kind of validity for the movement (when the game launched, you could cheat and teleport in the world by sending false info to the server).

I think the NetCode is absolutely not built toward the idea of an MMORPG, and I believe there's something about an MMO architecture on their (long time) roadmap.
If I had to make an MMO today using Unity, I would probably try out their "Transport" package with a very simple "command" system like Wow did in their early days, adding complexity and security on the way.

I hope not to be too wrong.

 

Thanks for the answer! I will look for solutions.

 

The question is not if Netcode can handle it but how much CPU stress a rollback netcode/actual simulation puts on the server. (it's a lot with 2-3k players) Which means, lots of server costs and thus, not advisable.
MMO netcodes don't revolve around precision and even anti hacking as much as rollback so the approach is very different. Most MMOs, even AAA, you just send a position and the server believes you. You can see with that alone how much they try to keep the cost and simulation time low. Sometimes there's not even a real simulation.

Currently I think you'll have more success for MMOs with frameworks like Unet/Mirror, etc... Keep it simple and scale from there.

 

For a networking stack to be MMO ready there are some stuff needed
1- the net lib should be able to handle lots of connections and messages per second
2- it should be able to do prioritization based on area of interest and other mechanisms so each client should only receive the data related to people around him and not more
3- the server should not implement memory and/or CPU heavy techniques like rollbacks.

Take a look at big world and hero engine and their docs as good examples. The new transport however can be tested and if it works then you might be able to start from there but I doubt that they tested it in MMO scale yet, this said however they are building an open world shooter to test these things I guess so unity will build at minimum a fortnite like multiplayer game internally with say 50k objects and 100 players and will try to make it work. if that happens then probably using transport layer or a heavily modified netcode will be the way to go. keep the heavily modified with a grain of salt since I don't know how customizable and modular the netcode will be. if it becomes possible to disable rollbacks and change the way snapshots are generated then you might be able to use a really good version of it without much modifications

 

this is a very good question, anyone got info on using it to sync swarms of entities to a smaller amount of player ? (like < 30 players) any idea what would be the expected capacity in the current state of the system ?

 

Unity transport in theory should be fine. Networking itself is mostly IO bound. But that they aren't testing it for larger scale means it probably has issues. And they closed off the source, so not really a great option for using in an mmo at this point.

But you won't be running thousands of players per server on Unity, for other reasons. Most mmo's use regions/zones, so you have a natural partition that reduces the number of players to at most several hundred. And Unity can only run a single scene/map at any one time. If you are thinking open world/float origin, think again there also. Shifting as most understand it in the context of Unity isn't an approach that will work on the server, and other approaches that can work are complex to say the least. Realistically not doable for a small team with no domain experience.

So realistically you are probably looking at around 200 or so max players in a region, maybe half that in npc's.

So all told you are probably better off using something like this that also has reliable messaging:
https://github.com/nxrighthere/ENet-CSharp

Or take a C/C++ networking library and pair it with something like this.
https://github.com/networkprotocol/reliable.io

As a point of reference we use .net core server side with our own C networking and the above mentioned reliableio library. Our networking and reliable message handling is single threaded and can handle around 5k concurrent connections pushing 60 messages per second each. Which is roughly double what our design peak is per server.

 

1) How do you handle Physics & Collisions on Server side if you are using .net core and not the Unity itself?
2) In case you are using a different physics framework.Are you getting a deterministic result ?
3) using Unity Headless builds isn't enough ? Why?
4) I think the DOTs will fix all these problems when it will be more stable.
Eg: Tiny package will be the perfect way of having Headless, Costless and Fast Servers.

@artyomik14
5) Personally i never tested the Transport Package at a high scale (thousands of connections) but i think with good Technics of separating players and environment Entities using regions to limit the data sent to each entity this package can handle thousands of players. (just my opinion) at this stage i think only Unity can really answer this question correctly.

 

Hi, bringing my unexperienced self on the mater,

I think DOTS will handle quite well separation of player, you can use ISharedComponentData for region/Map and if need be you could probably wire up something more convoluted with several worlds.

As for the fact that unity only run one scene map at a time, first I'm not sure it's accurate whe nusing dontdestroyonload it's represented as a scene in the hierarchy, hinting me to think it can handle multiple scene at a time just fine. And event if not hte case, the subscenes will certainly help move toward more flexibility.

You also seem to imply that the source code for the transport layer is not publicly available but the transport package is available through the package manager, you should be able to see the sources just fine.
If I miss understood and you were refering to sealing classes and private attributes, well you have the source so nothing stops you from cahnging what you need. you can even give feedback to unity as to why you need those cahnges. If they see a real use case, I'm sure they'll think about it. An if by any chance you are doing something wrong, you'l probably get some explainations as to why you should do that.

 

The C source is closed. It was initially open then they stopped providing it it. This is an issue if you want to integrate anything else in C with it like reliable messaging. The reliableio library I mentioned for example uses callbacks for sending the message to the network.

Reliable messaging is best handled all in C otherwise you cross the native/managed boundary a bunch unnecessarily.

 

One of the advantages of reliable.io is full control over retransmissions, the library itself is basically a flexible NACK-based notification layer, so buffering of reliable messages is up to you, works best in scenarios where packets are shuttle across endpoints continuously, not very suitable for turn-based games.

As for scalability in the Unity, just as Chris said, you have to distribute workload across small nodes/instances, monolithic architectures is where Unity falls apart because of its constrained environment. The data-oriented stack is not helping here because it aims fine-grained processing which is an opposite thing to coarse-grained server systems.

When you are building something truly scalable, you are bound to network I/O anyway, so you have to step over it. As one of the options, you can use a high-performance platform-specific network API such as Registered I/O on Windows and io_uring on Linux. These APIs not requires specific NIC, but you still need good hardware to benefit from it. Depending on how these APIs are approached, you can achieve a great throughput, here's one of my implementations that allows to fully utilize 1Gbps Intel NIC transmitting more than a million packets per second over the network using UDP. This should be a good starting point.

 

Note that game-specific high-level abstractions play a very important role as well in terms of flexibility, efficiency, and performance. There's nothing off the shelf in Unity, including 3rd-parties that provides this for truly scalable virtual worlds.

 

Can you briefly elaborate why do you think DOTS approach is not suited for networking? I never really wrote robust networking game layer, but from this point of view, it seam as beneficiary that you get to select only subset of data in quick and easy manner and pack it for transmission. ECS is sort of based on DB querys from my point of view.

 

This is a quite complex topic, so long story short: server architectures (and games in general) is not about moving 100,000 boids in parallel in the most efficient way, it's about a balance and harmony of all systems with different granularity. When you are obsessed with only performance, blindly chasing the idea of the high speed, you are by definition building a foundation that doesn't meet the above requirements. When the way of how you are approaching data, the concurrency model, and other aspects are shaped to solve very specific problems, you are building yourself into a corner.

 

You could try https://improbable.io/multiplayer-networking out of box sample runs 200 first person shooter bots/players. I imagine it could handle a lot more simple mmo players.

 

Not sure why most of the people think "...oh, parallel" when it comes to DOTS. But I don't see parallelism as most beneficial advantage of DOTS. You could have offloaded native data calculations on another thread even in the past, it was just not this easy. IMO, main thing is ECS and the fact that you don't need to cache instructor pointer and function params while jumping far and wide across the RAM, just for the code part, plus handle cache misses because you have lots of useless data in it. Which you get if you are hard-core OOP guy, which I am, don't get me wrong.

That's why I see DOTS as advantage when it comes to packing data for transfer, and only the actual data you need. The problem here is that you need to have the same kind of approach on server. Again, never wrote a line of code for game networking, I might have more credits to comment about this in a couple of months when I get there.

 

There's a ton of expertise needed for a MMORPG server but I think we can agree, when the simulation runs more optimized that's a big plus and that was something Unity wasn't able to do previously. If you wanted high concurrency with somewhat of a simulation you had to make your own server and now we slowly start to get the option to write a scalable simulation server directly in Unity.
Of course you're right when you actually build a monolithic approach in Unity but why would you? And when talking about monolithic, sometimes you can't break your architecture apart any further, mostly the simulation servers, so sure, you can build all those scalable services like login, chat, matchmaking, lobbies. I suppose you could even make these services in Unity but there's better tech for that.
Anyway, I just want to say for MMORPG simulation servers, DOTS feels a 100% fitting. It'll lead to an eventual Fortnite clone that runs on a Unity simulation server. There's no denying there are more puzzle pieces on the table than just the sim server but that's more the nature of the beast when it comes to MMOs or something that has 100s of players in general.

 

Unity is not a scalable environment for a server DOTS or no DOTS.

Game engines are based on a game loop, and DOTS is based on having a single synchronization thread. That is quite the opposite of what you need to scale on the server.

Server scaling is focused around being able to respond to requests in a timely fashion. Serving potentially tens of thousands of requests per second or more.

At scale what probably matters the most is what is your standard deviation. The patterns you need to use to scale at low standard deviation over many cores is different then what DOTS does. DOTS uses the same core principles any good concurrent system does, ie single writer. But from there it uses approaches that work great for a client or small scale server stuff, but not so good for any real server scale.

In a vertically scaled server environment your networking would either be single threaded or possibly a number of pinned threads. Those basically just send batches of requests to other threads. Several ways to structure the flow but basically you synchronize at the batch level. Global sync points are the bane of server scaling. You have to synchronize at multiple points on different threads. The key is using strategies that reduce how often as well as partitioning the work so you synchronize as few threads as possible.

Now that said you don't need to vertically scale server side. Most games don't and that's smart big picture. You can't afford to engineer every game for what will work best and be most efficient in production. It doesn't work like that in the real world. What you can afford pre launch is an entirely different thing then what you can afford post launch with some success. Your engineering cost as a percentage is completely different. I've worked on games where we easily paid high 5 figures per month that better engineering would have reduced by a significant amount. Quite a few games have scenarios like that.

 

Forget about it.

 

I'd say that generally anything which intends to have a couple of thousand players online at the same time in a shared world will need a custom solution. Basing something like an WoW-style MMORPG on NetCode built for ~200 players is not a good idea. Not because the NetCode isn't good (I'm sure it is) but because it was not built for thousands of players.

The type of synchronization techniques that you use differ massively between something like an MMO and a high player count FPS.

On the topic of using DOTS runtime or not for an MMO it's hard to say - when what Joachim explained above reaches production ready status I'm sure that will be great. I would not recommend trying to build an MMO server inside of DOTS running inside of the normal unity player at the moment simply because of how tied it is to the main thread, certain synchronization points, etc. - it will kill your scalability. However if, as Joachim explained above, we get the ability to run inside of pure .NET Core, manually managing simulation threads and world instances, etc. that would probably work really well.

My current MMO backend work is being done inside .NET Core simply because it feels a lot more stable and less volatile than the current state of DOTS/Unity C#, I'm sure that will not last forever and it'll calm down, but the current rapid speed of change and the instability that comes with it is too much for me personally.

 

Good to hear the direction it's going in. Thread per world seems like it would provide what is needed to scale.

If the DOTS compiler is too restrictive that might be an issue with server oriented libraries. I noticed that in the recent 2019.3 releases they tightened things up so some reflection api's are now throwing platform not supported exceptions. Correct for .net standard 2. But for a server environment that's sort of an issue.

 

Actually it would be at runtime where accessing reflection would fail. But i'm a bit confused about how it runs on top of .net core but still has restrictions.

 

@snacktime I'm not sure if you are implying that most MMOs run multi-threaded simulations for a part of the world/zone or not but if you do i really wonder where did you see that because most architectures AFAIK simply use small zones with single threaded logic and usually they have to sync anything with other threads only if some entity is crossing boundaries or simply they only synchronize these with other processes.
I'm telling this based on not only my experience but also from the slides that you can find out from GDC sessions of alikes of guild wars 2 and … The only exception is EVE Online perhaps which runs an actor based simulation using Erlang and stackless python.

Sorry if you mean running other things in other thread independent of the simulation thread and like running netcode in 1 thread, sim in another and say database requests on another and …

I personally tried to do distributed simulations using Orleans, I know you did with your aka based server and even big companies did but AFAIK not as many games in production successfully did so. writing game simulations without global frame sync points is hard to wrap your head around and scaling them to multiple machines without saturating the network before gaining perf benefits is a very hard problem. Improbable is the remaining company which is trying to do it as a middleware and yet I cannot judge how successful they are at the challenge

 

I was thinking of either games like fortnite or mmo's like ours that have thousands of zones. We intentionally designed an mmo with a different type of scale. In most mmo's players can purchase housing or small land plots. In our game those are entire zones with a lot of solo play attached to their design. The scale is actually needed to generate the resources that are used in the shared gameplay.

We actually use MS Orleans for most stuff off the hot path. Hot path is completely local. Players just connect to the server hosting the zone they are in. If they connect to a zone on another server we just reconnect the client to that server. Vertical scaling is to deal with the thousands of zones paradigm, where the player base can easily be spread over many zones. Plus some minimal simulation that is running even when no players are around. We don't try to move zones around at runtime or anything really fancy actually. The architecture is fairly straight forward.

 

And PlayFab with 2 Fv2 free servers monthly.

Someone even made a guide how to integrate their sdk with Mirror: https://docs.google.com/document/d/1ZgtDsgTcccyj25jSZgQPJ3_gnUCaOqQoJ9cvay2IfV4/edit

Hope to see similar stuff for Unity netcode + multiplay in the future. Free tiers for multiplay and chilliconnect would greatly increase users base.

Are there any games made in Unity that use Multiplay? I find it a bit weird that Unity acquired them but still lacks features to make online games.

 

Edit: check out DOTSNET.

.NET Core would be huge.
Not sure if you are aware, but right now any type of async networking doesn't scale to >80 connections in Unity because of the Mono backend. For example:

• SocketAsyncEventArgs are extremely fast and scale to thousands of connections outside of Unity. Inside of Unity you get 100+ seconds latency after around 80 connections.
• async-await sockets are fast and easy to use (instead of threads) outside of Unity. Inside of Unity, they scale to around 80 CCU as well
• BeginSend/BeginReceive socket functions: same.
• The Asset Store uploader tool is limited at around 3.5MB/s upload because it uses async sockets for HTTP. See my post on the publisher forum.

Unity uses a custom synchronization context to run all async/await code in the main thread. This is not the issue - even when I replace the context so async runs in multiple threads, the problem remains.

Additionally, Unity's Mono backend has issues with non-blocking TCP sockets which sometimes are actually blocking. There is even a workaround class in Mono's sockets that is supposed to detect that problem - but it only works 90% of the time.

The way we scaled past that with Mirror was to use native C sockets like you do with your new transports. That's a bit cumbersome on Android/iOS/etc. So net core would be extremely useful. This will be a great!

---

Also, I think people greatly underestimate Unity's performance when it comes to MMOs. Even with MonoBehaviours we can do around 1k CCU already. We ran a worst case stress test with 500 connections, everyone broadcasting to everyone else (which is kind of insane) - and it worked:

If DOTS is only 10x faster than MonoBehaviour, then we are looking at 10k connections with 100k monsters basically for free. At Unite someone showcased using DOTS in their zombie shooter - with Jobs & Burst it was 22000 times faster. That's EvE online scale right inside of Unity and C#.

---

To summarize, I believe there are only 2 things holding us back for 10k+ connections MMO scale networking:

1. We need NET Core (but we can work around this with native C sockets for now)
2. Stability: right now, if my server is affected by a critical Unity bug there is a 50% chance that it will be fixed and backported to an LTS version around 6-12 months later. Packages being open source makes this a lot easier already. But it's still a bit of a risk to run a game server in Unity.

 

@Joachim_Ante Are there any plans in unity to support simulations which each part of the world is simulated in a different process or World (ECS world I mean)
Things like highly performant octree implementation and a backing entity store which serves all worlds? I know this is a very hard and challenging problem but just curios to know if you are trying to do things like t hose (Just enabling people to do things like that on top of unity is huge so don't get me wrong )

We at MuchDifferent were trying to uild such a thing called Pikko Server on top of single threaded Unity and unreal which we failed to market and sell and the tech had lots of limits but it never left my mind that this could be possible with a better networking library and more performance and a good framework which allows async processing of many game messages/events

 

@Joachim_Ante Are there any plans in unity to support simulations which each part of the world is simulated in a different process or World (ECS world I mean)
Things like highly performant octree implementation and a backing entity store which serves all worlds? I know this is a very hard and challenging problem but just curios to know if you are trying to do things like those (Just enabling people to do things like that on top of unity is huge so don't get me wrong )

We at MuchDifferent were trying to uild such a thing called Pikko Server on top of single threaded Unity and unreal which we failed to market and sell and the tech had lots of limits but it never left my mind that this could be possible with a better networking library and more performance and a good framework which allows async processing of many game messages/events

 

Yes just the fact that object handovers between worlds doesn't require executing serialization/deserialization code is a huge improvement. It has been one of our serious bottlenecks alongside unity not being able to host a part of the scene in one zone and another part in another (this one is solved with sub-scenes as well)
Another and very important one was reliable message protocol performance and its memory allocation needs to be able to respond fast with very low latency to local network requests was another but going to .NET core even if theoratically Unity's networking layer doesn't solve this one can use other network libraries for inter-process/machine communications.
Doing the Octree and the DB of course can be done fully outside of unity as we did in Erlang in PikkoServer and doesn't have to concern you, this said DOTS is a very good platform for that with burst and jobs now

 

Fundamentally the approaches are not that different if you were to scale both vertically.

Horizontal scaling generally uses service oriented architectures for everything that in some form persists back to a database. The database is the primary reason why you need that design. There are multiple concerns there. One is just the number of connections to the database. Another is connections to other services like memcache, maybe another custom service.

Vertical scaling inherently aggregates traffic. So it changes what is the best approach significantly. If you get enough aggregation then you don't need separate services for the purpose of scaling. You might still have some cases where you want it separate but it's no longer imperative that you do so. In some cases it becomes very beneficial to handle it locally.

Traditional doesn't equate to good or better. Easy to use concurrency aka DOTS certainly isn't traditional in games. Burst isn't traditional. When talking about what is good or better then it needs to be on the merits with specifics that have some basis.

Fortnite is traditional they scale horizontally last I knew. They actually majorly screwed up their db design, took them several weeks to fix it at launch. Not just normal bugs or even specific to big scale. A lot of nobody should do that ever sort of thing.

You can't look at what studios do for what is a good way to do it. Very few in the AAA realm do it well. Not trying to knock them there are reasons, it just is what it is.

 

Ah ok nice, I'm going to have to give tiny a try now.

 

@snacktime Look you cannot simply look at the problem from the lens of is it vertical scaling or horizontal and assume that the problems are the same
If you want to vertically scale a game like fortnite, having a single threaded high perf fortnite sim which doesn't block other threads and receives/sends a batch of commands/updates using the network thread with a good latency can vertically be scaled with say n-2 number of other threads where n is the number of hyper-threads available and you pin a networking thread to a core.

but

In a MMO these sessions need to communicate with each other, hand over objects to each other, send and receive global messages with each other and also handle a much bigger simulation and more number of players. I'm not talking about the metagame here at all which can tolerate much more latency and is fundamentally different due to that.
A MMO server of the usual kind where there is a big world and thousands of players in the world has to communicate between the players and the communication is not always local. you sometimes are on a mount and can see a bigger portion of the world, sometimes you are broadcasting a spell which affects 4000 objects or crosses zone boundaries. x number of players are crossing zone boundaries per second. you cannot afford rollback In most cases due to the number of things happening at the same time (number of entities and players) … to vertically scale this you need to make your sim as lightweight as possible and as fast as possible, you need to make object handovers as fast as possible, you need to have a performant netcode as well with 99th percentile latency which is tolerable and these call for different designs (netcode is the exception maybe)

In fortnite you don't have many of these problems or they are simply not as hard due to different number of objects in the world and many of them being static. Even fortnite however had to create their replication graph for efficient processing of their object count due to it gong that high to 50k.

In addition to the mentioned and the need for much smarter AOI and prioritization management which again requires fast processing on the CPU and just doing it locally doesn't fix many of these problems. some of them are not local some are heavy enough which it will cause them to benefit from going wide on cores with a good job system and small jobs which doesn't introduce higher than tolerable latency on any of them which means some stuff have to become asynchronous services which run on another machine/process

 

How about making an actual commercial game where your tech and the company is under risk of failure, like Epic? These demos are just basic smoke research, I'm making them over the last decade, commercially successful multiplayer games and technologies behind them is absolutely a different story. You are not losing anything in this case, unlike your customers.

 

Sat down and worked through this today. Few rough edges with integrating codegen on your own .net core project, but other then that it just worked. Very nice to have that option now.

 

it is great to see you guys working in new network solution with scalability
i been waiting this for ages. looking forward to your/team incredible work & for even bigger connections >500-1k and i wont be surprised if u working towards this.
been working in online games for awhile with other solutions but i'm targeting mmo for now. and seems dots doing the job.
as for the moment i have plan to work with 2020.1 and i'm waiting the full reliable release to work with dots & Netcode after. as from what i see there alot of changes happening which is why i didn't use it yet.

keep up the good work! thanks.

 

the really question is will this solution be able to handle 1k to 10k connections in single powerful server in the future , dosen't have to be same area but with huge map and at least 500-1000 players to be in same area fighting and the other 9k somewhere else and with like 10k to 50k Npcs and mobs around the world, is the dots Netcode and Team have that in mind. and are you guys heading towards this. @Joachim_Ante as i used older network solutions most of em have scalability problem and most of them are not lightweight so i hope this solution bring something better.

 

Turns out that DOTS/ECS is quite capable of MMO scale networking.

With DOTSNET & Apathy I can send 50,000 moving monsters to a player @ 24 FPS, running both server & client in the same process (=100k Entities), on my 2018 Laptop(!).

Video: https://gyazo.com/332832d1c94875fea616b0a63dab4d28

Screenshot:
DOTS is so ridiculously fast that there is currently no low level transport that can keep up with it:

• Apathy can send around 50,000 Entities to a connection
  
• LiteNetLib can send around 20,000, but becomes too slow at that point
• libuv can send around 5,000 Entities before its buffers get full

Currently researching more transports/optimizations to reach 100k. Might be doable with some good compression already. The current bottleneck is simply socket buffer size.

Will run a 1000 true connections test soon. To launch 500 clients we need around 90 CPU cores on Google cloud, and they didn't increase my CPU limit yet. Note that even MonoBehaviour can handle 500 clients with the right transport, so DOTS/ECS should be very interesting.

Realistically, with a dedicated server, on a good machine, with a reasonable area of interest, DOTS/ECS should be able to simulate millions of networked entities.

Really impressed by DOTS/ECS performance. Thanks @Joachim_Ante and team. Finally I can make my MMO. Most exciting technology I have ever seen. Burst is magic.

 

Did you actually try Unity.Networking.Transport?

 

Last time I checked it was fully unreliable. Would need at least a reliable channel to be interesting for MMOs, e.g. 'buy from item store' / 'put point into strength stat' / etc. messages.

The C code also allocated in each sendto call, which usually doesn't scale. They use a new socket backend in Unity 2020, but there is supposed to be a bug that wasn't fixed yet.

 

Such Nice Work! with Dotsnet, but the really question is , did you try use other things like animator , sending rpcs like fire balls between the connections , my point here is sending more data other than just positions and rotations between those cubes. like they need to fight each other or something with every cube have ther own hitpoints and all data need to be live. also would be cool if u try this with like characters with animations and stuff.

nice work btw Cheers.

 

Thanks. What you see are the humble beginnings
Will spend a few more days on low level transport performance, and then add more features to slowly move towards full MMO.

 

good to hear! , also i'm not sure if u moving towards something like ummorpg , but it would be interesting to see fast action or hack and slash rpg this time with this cool system if so, instead of click wait target system. something different u know it would be good example for dots net.

but yea developing the system first is good start and better for different games.
looking forward for Dotsnet future!

cheers

 

@Joachim_Ante you should hire @vis2k to the net team , we need more great mmo solutions in this engine
we been waiting such solutions for ages.
this guy epic.

 

To drop some help here since I saw the thread in a search again.
It is important to have a networking layer which can send messages as fast as possible but hardly that is the thing stopping MMOs from scaling.

For a MMO to scale the latency of your messages should be smaller than a x in your most busy area with the most busy type of gameplay possible and that means you are bound by your gameplay code and logic as much as you are bound by client bandwidths and how much they can receive among other factors. Yes you need to move beyond unity's/Mono's socket limits but a C lib with a thread pool and job stealing can handle that for you.

To scale to 1000 players or more however you need to solve the challenges much harder with either design or much more complex technology regarding how to simulate game logic as fast as possible on the server and when to send each entity's data to a client and calculate this later thing fast as well. To send eficiently to clients you need to run complex logic on the server which is a really big pain point and that is why we don't have modern MMOs having large scale 1000 player battles in a small area.

We tried to do this with pikko server back then at MuchDifferent in a FPS and to deal with the chaos our main problem to solve wasn't how to send messages fast (we were using Erlang on the server and did this easily) but in which unity process run the logic for each entity, how to communictate across process boundaries between entities (when you shoot near a boundary is a common example) and also send which data to each client.

You need some sort of geo-partitioning octree/... and also a very performant database on top of your single threaded processes or between your ECS worlds.

Now DOTS make these challenges much easier to solve but still physical limits of light speed (literally physical limits) and also the amount of bandwidth available will limit you so clever game design would always be needed until a set of new technologies become available/made which allow you to have a shared view of the world which can be updated very fast from multiple writers (worlds/processes) and determine what to send to clients fast as well. Still companies like improbable.io are trying to solve this nd EVE online developer and another company called hadean.com are trying to do it as well.

This is generally to show what tool is solving what part of the problem.

 

thanks for joining the topic @Ashkan_gc as for now im using Dotsnet from dev @vis2k but im also curious of what we will have in terms of dots animation-animator and how will they work with netcode, are they next gen- automatically calculate positions points of the body like mesh animation and sent to clients? and how light they are to be sent to the network, also like @Ashkan_gc said we could have hundreds of thousands of entities etc using dots but im curious to see how would netcode and dotsnet handle such thing by bandwidth side, like what we expect to handle such thing 100Mbit - 1Gbit - 10Gbit?. i would like to hear word from @timjohansson @vis2k about that and the future of the Dots-netcode , also would be cool if we have tools to calculate bandwidth need in terms of upload(sent) and download(receive) speed by message/packet size from each of the player and the npcs. so you have idea of what to get in terms of server bandwidth need. (in other words local bandwidth test tool)

would like to hear more about this thread and where we heading

thanks everyone for the hardwork.