Hey everyone!
What exactly is the limitation that makes NGO only suitable for small scale games?
Is it in the NGO layer? Or in the Transport layer?
Does that mean limited number of Players (1-4) or limited number of total networked objects?
What happens if I were to connect 100 players? Would it support just 2 Players but 100 networked Enemies?
Thanks!
4 Likes
Currently NGO Unity Transport has a StackOverflowBug at the MaxPacketQueueSize configuration. BUGREPORT
This makes the system unable to support large amount of messages at the same tick. With large amount of clients a even larger amount of messages will be needed to be send from server towards client and each client needs to receive more packages due the number of clients to synchronise.
The biggest problem is actually the client spawn, since the server tries to send the current world state towards the client. This worldstate is ALL the current information, so NetworkObjects, NetworkVariables, Transforms, NetworkLists …
If the server cant send that in a single tick the client synchronisation is unreliable and the server will cut the connection towards that client.
We tested that and the largest amount of clients (which do nothing instead of receiving a new color from the server) was ~214 Clients on a single server. All clients that tried to connect afterwards just couldnt connect. If the NGO system cant send a reliable message in time, the client will be disconnected since the server cant sync that client properly anymore.
But like I mentioned, those Clients did nothing. If you increase the to send messages, the client number will shrink aswell.
We had another project in which we let the clients walk,jump,rotate and shot on each Tick. A number of around 40 Clients was stable in the short run. But keep in mind that this was also the worst case scenario.
I hope that information could help you! 
3 Likes
Oh interesting, so it’s a question of too much data in a single packet.
If that’s the only limitation then it sounds like it would be possible to still support larger scale games by just being clever and limiting how much data is synchronized as soon as a player joins and instead sending the full game state over several packets through RPCs.
1 Like
Another thing that may limit the scale of games made with NGO is that some features expected for large-scale games are not implemented (yet). For example, there’s no AOI (area of interest) system, so everything in a scene is always synchronized, which can be taxing on bandwidth if there’s a large number of networked objects.
Also, the current design of NGO makes heavy use of reliable and ordered delivery in the transport, which also has bandwidth constraints (we need to track if packets we send have been received, and there’s a limit to the number of such packets that we can track at any given time).
4 Likes
Hello @itisMarcii and @simon-lemay-unity . Thanks for the info.
Just to know if I have it clear.
If in a game, I want to synchronize only the path of a ball or a bullet (Transform), currently, the data that will be sent includes the whole gameobjects in the scene in every tick (game status update)?
Thats not the case. Only on spawn the client will synchronise every needed information like positions. Afterwards, without NetworkTransform, the client will not synch any position if you dont tell him to.
So if you move, on server, an object from point A to B. The client, without NetworkTransform, will not synch that object from A to B. You need the server to send the client a message to do so.
The NetworkTransform does that for you. It synchs the Transforms which you told him to. Its also server authoritan, which means that changing the position on client will not synch the position on server. Only from server to client the synchronisation will occure.
1 Like
Is this a problem with the Unity transport or NGO in general? Could I overcome this bug by using a different transport layer like steam networking?
That specific stack overflow bug is in Unity Transport. So yes choosing a different transport would avoid it.
1 Like
Hi, do you think that it would be better for someone to try fix this on its own(the initial overflow and adding an AOI) or it would be better to just wait until Unity implements the AOI and fix the Overflow?
What I mean with this is what would take longer, is it better to wait Unity to do it or do it myself?
The stack overflow bug should be fixed in version 1.3.0 of com.unity.transport, which was just released.
Regarding an AOI system, I’m not sure what the timeline is regarding us providing one. The best I can tell you is that it’s on the roadmap. But before you start writing your own, my advice would be to test the current Netcode solution with something representative of the game you wish to build (in terms of world size, number of networked objects, number of players, update frequency, etc.). You may find out that you don’t need an AOI system at all, or that other bandwidth optimization techniques are sufficient for your purposes.
2 Likes
I have an open world MMO (working on it). Lets say one area (zone, level, whatever) can support only 50 players simultaneously because of limitations on NGO, coding, zone complexity, etc. But 100 players want to be in that area. If I had a dedicated server through UGS etc. would it be possible to allow all 100 players in that zone by having two instances of the same zone OR would many of those players simply need to wait until someone left the zone before they could sign in…or would the game simply crash, etc?
I’m at the front end of networking and I’m trying to understand it as best as possible.
I’m making similar MMO game. World in my game is split to small locations. Each game server can handle several rooms (=location instance). And I’m going to allocate a new game server instance if allocated game servers are full. So players are always able to enter location.
But I have only prototype and have not tested performance of this solution
This part is something I actually fixed in my free “Netcode Plus” asset on the asset store, also for my Survival Engine Online asset.
What i did is completely rewrite NetworkObject class and instead when server spawns it will batch the objects in small “groups” and only spawn a certain amount per network tick.
It would probably need some optimization though, that’s why i came to this forum trying to figure out in another thread to ask some questions .
Also it probably doesn’t make it work for large scale games with tons of players but at least it fix that specific issue of sending everything at scene start, and also makes it much easier to work with netcode. So it doesn’t solve the “too many client” issue, but it definitely allows to create much bigger scenes.
I explained a bit what i did here:
https://indiemarc.gitbook.io/netcodeplus
The most useful thing I added IMO is the ability to share data (like save files) BEFORE the objects in scene start spawning/syncing.