I heard Unity isn't very good for something like an MMO, but I guess that depends on just how a game is made. Right now I use the networkview components to synch player's transforms. Players out of a certain range of each other have their networkviews disabled. Using this method can anyone estimate how many players one server can support for a shooter with network updates happening at 12 a second plus sparse RPC calls? How big are the updates the network views send for transforms? I'd like to have one Mega server but I'm not sure it's possible. I may have to limit the enabled network views even if players are fairly close to each other. Although the way the game is designed, there isn't really a reason for mass gatherings besides maybe some players arranging big fights.

You need to know three basic things:

• How big each update is in bytes (easy to capture with Wireshark or similar tools)
• How the number of updates scales with number of players - naive is O(n^2) which is impractical for large groups
• How much bandwidth you expect to budget - i.e. how many bytes/sec can each client handle, and more importantly, how many can the server handle

If you can assign metrics to that, basically all you have to do is solve this equation:

update_growth_function(num_players) * update_size_in_bytes = bandwidth_budget

Thanks, sounds good.

For anyone wondering... The typical networkview monitoring just the transform send 36 bytes per update. Found here: http://docs.unity3d.com/Documentation/Components/net-MinimizingBandwidth.html

Hmmm, if only 36 bytes are sent per update, it seems like a fair amount more than 100 could be supported for an action game with a moderate update rate. I'm aiming for a 1MB/sec connection speed.

Butabee, on 01 Feb 2013 - 23:15, said:
Hmmm, if only 36 bytes are sent per update, it seems like a fair amount more than 100 could be supported for an action game with a moderate update rate. I'm aiming for a 1MB/sec connection speed.

The problem is the server, if you have 10 players and sync their 36 byte transforms 15 times per second the server has to send 9x10x36x15 bytes of data each second (thats 47.46 kbyte/s or 379kbps (37.9kbps per player)

with 20 players at the same updaterate you get 19x20x36x15 ~= 1600kbps (80kbps per player) (now its no longer possible to host the game on a DSL connection with 1Mbps upload, players can still play just fine with even a really weak 256kbps connection). at 50 players you get 49x50x36x15 ~= 10Mbps worth of bandwidth for the server (Still acceptable). at 100 players you'd hit ~40Mbps on the server at that update rate with just a single transform per player being synced. (Do you see where this is going ?) , 100 players in this scenario still only requires players to have a 400kbps connection (or one that never drops below that really) but the servers bandwidth requirements can start to making hosting difficult in some areas.

at 200 players the server bandwidth can hit 199x200x36x15 ~= 163Mbps, this is now pretty much impossible to host on a consumer connection (Allthough some regions have 1Gbps consumer connections now it is still fairly rare) and hosting costs for a commercial grade connection will be very high.

For an action game you probably want to update transforms atleast 15 times per second and you will have to send quite alot of other data aswell (a single transform per player isn't really enough for most games) so in order to keep the bandwidth usage on the server at a reasonable level you need to be a bit smart about it.

1) Keep the number of players in a given area low, the more players you got in a single area the more data your server has to send to each of them. (if you have 200 players on your server each playing in groups of 4 in their own little instance your server will only need to send 3x200x36x15 bytes/second instead of the 199x200x36x15 it would have to send if all 200 players were in the same area and able to see eachother)
2) Adapt the update rate based on distance or relevance. If playerA and playerB are far from eachother but still able to see eachother you can reduce the rate at which you send playerAs transforms to playerB and vice versa. (Not sure if unitys network views do this for you or not), if the game prevent rapid turning you could also avoid sending updates for things that lie too far outside the FoV

The exponential growth in bandwidth usage on the server is one of the harder problems to solve for large scale multiplayer games and it is the reason so many FPS games cap out at 64 players (Beyond that you will need a design that effectivly prevents large numbers of players from gathering in a single area or atleast discourages such gatherings so that they don't happen unless all players want it(and the inevitable lag that will follow) to happen), you might also have to write your own networking code rather than relying on Unitys network views (Unless they are more flexible than i've assumed)

Oh, damn, for some reason I was thinking I'd only have to send players*update rate*update load from the server to players. Looks like I'll have to scale it back.

You can't adjust update rate on a networkview basis. Wish I could but nope. Unity's networking isn't real flexable.

I want to keep things as simple as possible and use the default networking. Kinda sucks but oh well.

Butabee, on 02 Feb 2013 - 01:25, said:
Oh, damn, for some reason I was thinking I'd only have to send players*update rate*update load from the server to players. Looks like I'll have to scale it back.

You can't adjust update rate on a networkview basis. Wish I could but nope. Unity's networking isn't real flexable.

I want to keep things as simple as possible and use the default networking. Kinda sucks but oh well.

There are a few more scalable networking solutions available that you can use instead, Photon is pretty popular, very scalable and not that difficult to use. you can also use .Net sockets directly. (Sockets or custom networking modules are not available for iOS/Android unless you buy the pro version).

For now I've managed to lower the update rate to 5 per second while simulating movement on both sides but the load also whent up by 12, although it's still a win. So that should allow a bit more players.