Question Netcode and UGS Lobby - Number of Players

So, there is no code based/hard coded restriction on how many players you can have...but there are bandwidth and platform/hardware limitations that will "naturally restrict" how many NetworkObject instances you can have. It really depends upon how many other spawned NetworkObjects there are, the average bandwidth/processing cost per instance, and the targeted platforms.

Some general (but not "official") scenarios I have seen:
*** Performance and bandwidth impacted: This means you can begin to see an occasional drop in frame rate and should be considered the "ceiling" for NetworkObjects that are constantly sending/receiving updates.

Desktop/Console Platforms:
With all instances continually sending transform updates (position and at least 1 axis of rotation) with no animations or other processor consuming components.

Player instances are included in the instance count.
(Using full precision transform updates)
10-200: Perfectly fine
200-400: Slight impact on bandwidth and main thread performance
400-600: Noticeable impact on bandwidth and main thread performance
600-800+: Performance and bandwidth impacted.(Using half precision transform updates)
10-200: Perfectly fine
200-400: Mild impact on main thread performance
400-500: Mild impact on bandwidth and noticeable impact on main thread performance
500-700+: Performance and bandwidth impacted.

Mobile Platforms:
Really, it depends upon the range of mobile devices they are planning on targeting... but generally speaking you could cut the above numbers in half and be relatively safe.Of course, this is all based on the assumption that every instance has some form of transform delta every network tick. You could have 100's of instances that are event driven (i.e. a door opening, a torch being lit, etc.), so in reality the number is really based on "how many things will be sending updates per network tick" which is heavily dependent upon genre and implementation. Regarding any hard-set limit on the number of players, theoretically you could have 100's of players but that wouldn't leave much room for other NetworkObject instances.

Optimizations:
The most commonly expensive thing to synchronize in a netcode product is an object's transform. NetworkTransform allows you to help reduce the bandwidth cost in various ways:

Per-Axis Selection: When using full precision float values, you can select which axis you don't want to synchronize on a regular basis.
Delta Thresholds: The delta threshold determines how much of a delta between the previously sent axial value and the current value is required before it sends an update. The higher the delta threshold the more spread apart (depending upon an object's axial rate of change/velocity) the updates and the (generally speaking) less bandwidth consumed. This is a value you need to configure specific to the object in question (i.e. how fast does it move or rotate) relative to your configured tick rate. If the object moves in 1 unity world space unit per second and you are running at 60 frames per second, then you could most likely get away with a 0.01f-0.0333f delta position threshold when running at a TickRate of 30 (a new network tick is generated every 33.3333ms). But then that also depends upon what kind of accuracy you want to have. This is something you should fine tune using a development grid that is divided into your minimum world space units of movement in order to determine the best setting.
Half Precision: At the cost of slightly increased processing time per instance, you can cut the cost of a full transform update by close to 50% in regards to bandwidth per instance. Of course you lose a bit of precision (accuracy), but the NetworkDeltaPosition takes the loss of precision into account and continually adjusts for it (within a +/- half precision accuracy range per update).
Quaternion Synchronization: If you plan on parenting things and having complex nested hierarchies with different rotations between parent(s) and children, then you most likely want to do full quaternion synchronization to avoid gimble lock related issues. Of course, this comes at the expense of having to synchronize the entire quaternion when there is a rotation on any of the Euler axis.
Quaternion Compression: Unless you really need the uber-precision in rotation, this is a really good way to compress a full quaternion update down to an unsigned integer at the cost of a little bit more processing time per instance.
​

The Multiplayer Tools package provides you with additional profiling information to determine the bandwidth cost of an entire network(ed) prefab. You can use this to determine the bandwidth and processing cost of a network prefab instance. In reality, you would only need to do this for things that move around a bunch, can have frequent state (i.e. NetworkVariables) changes, or could frequently send/receive RPCs. For the things that don't frequenty have any form of state change and/or message processing (i.e. RPCs), you can exclude initially as they won't be the "brightest fire" in determining your total NetworkObject budget.

Regarding Players:
There are various ways to handle how a player controls their in-game avatar... with a client authoritative model the local input drives the frequency in which the player's avatar will send transform updates to the host/server (that broadcasts those changes to the other clients). While a server-authoritative model the player's local input is sent to the server (typically via RPCs) and the server broadcasts the result of the input's impact on the player's avatar's transform (i.e. moving in a direction) to everyone (including the player owner).The client authoritative model can be trickier to visually align changes (i.e. client prediction can help to synchronize this), but it has less of an impact (per player) on bandwidth and the server/host processing costs. The server authoritative model is easier to visually align changes (i.e. all motion originates from the server so updates are half RTT), but can consume more bandwidth and processing (i.e. processing users' RPC input updates, applying the motion to each player's avatar, and then broadcasting the updates to all clients).


The big walk away from all of this is that there is no pre-defined limit for number of players, but you will want to do some bandwidth and processing/frame-time consumption rate analysis before arriving to the maximum number of players you can have with all of the NPC and other non-player related NetworkObjects in your project.

 

Specifically for Lobby, the membership limit is 100, which is also the Relay connection limit: https://docs.unity.com/ugs/en-us/manual/relay/manual/limitations

For NGO, you may need to increase default UTP settings to reach high number of network objects and/or players:

- max packet queue size
- max payload size
- heartbeat timeout
- connect timeout
- spawn timeout

Finally, implementing network object visibility can significantly increase the scalability of the experience, both in CCUs and network object quantities:

https://docs-multiplayer.unity3d.co...y/#:~:text=​,to a netcode/network perspective.