Doubtful, it’s rather popular because for a long time, it was the only full fledged networking solution for Unity and easy to use.
It does have a serious drawback: it is not updating on discrete ticks which is inadequate for a network framework. It’s also said to scale badly with number of users, despite MMO frameworks built around it.
If you can manage to go low-level the best solution here really is Unity Transport, or any transport for that matter. Just a single point where you can get to decide when, what and how to send and receive data packets. This allows for important optimizations such as collecting all the transforms that changed in a frame and sending them out all bundled together, possibly compressed. There are traffic savings to be had doing so upwards of factor 5.
How many CCUs are possible has almost nothing to do with your choice of networking framework. Give or take a few bytes. And of course, like I mentioned above, you can’t afford to rely on any built-in conveniences like NetworkTransform if you truly want to scale beyond 100+ CCU.
How many CCUs a game can handle, assuming the same server-side hardware, depends 99% on your ability to code well and optimize CPU time, memory usage, and most importantly traffic. It may require making clever choices, ie reducing the update rates of anything past a certain threshold around a player, and not updating anything at all past another threshold. The network object visibility system many frameworks have can help you with this, but it still may require custom coding nevertheless.
You also need to think hard about what needs to be network synchronized, and what doesn’t. Many devs assume that the weapon a player is holding is also a networked object, and then they struggle with proper parenting, as well as moving the weapon between hand, inventory, and world. But really, only the world item is network synchronized, and it really doesn’t do anything other than waiting to be picked up. Once picked up, it’s just a matter of sending to other clients whether the weapon is equipped or not, and whether the player is firing or not - both of which the player object should handle, not the weapon.
Applaudable! And I’m sure it works great for motivation!
They can handle it, each on their own. It’s just a bunch of sprites and some network traffic. Although that traffic needs to be very well optimized because you’ll want them to still have a good experience on a slow network (3G or less).
Apart from that it’s mostly the dedicated server executable that needs to be able to handle 100 CCUs in terms of CPU time and memory usage. Say each player consumes 10 MB of memory on the server, times 100, the game would utilize 1 GB of memory. But you’d really want to run as many instances per machine as possible though, so in the case of an 8 GB server this would alread limit you to 7 instances (you can’t use up all memory to the last bit). Then those 7 instances need to be able to perform 700 players doing some things on just two CPU cores.
Those are Unity’s Multiplay server hosting specs: dual-core, 8 GB memory. Others vary but in essence, you want to be able to run the game on a low-cost system like a Google Cloud Compute machine (same as Unity resells to you in their service).
So the main challenge really is about supporting perhaps 10 or more dedicated server instances per machine even at 100% utilization, rather than a single instance on a single server supporting 100 players. You will want to be able to run multiple server instances, not just one, on the same cloud server to save costs. Each instance on the same server would only minimally increase costs, mostly additional traffic.