Sign in to follow this  
Butabee

Max players with unity server

Recommended Posts

Butabee    274
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.

Share this post


Link to post
Share on other sites
ApochPiQ    23005
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

Share this post


Link to post
Share on other sites
Kylotan    9872

From: http://answers.unity3d.com/questions/8597/how-many-players-does-unitys-built-in-networking-s.html

 

"In general, for most or all types of games - unless you're making major mistakes during design / development, up to around 20 players should be quite safe. [...] If you're very careful to make your game design "network-efficient", you can probably create an action-based multiplayer game based on Unity networking with a few more players. I think 50, maybe 100 should be doable unless everyone sees everyone all the time."

Share this post


Link to post
Share on other sites
Butabee    274

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.

Share this post


Link to post
Share on other sites
SimonForsman    7642

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) Edited by SimonForsman

Share this post


Link to post
Share on other sites
Butabee    274

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.

Edited by Butabee

Share this post


Link to post
Share on other sites
SimonForsman    7642

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). Edited by SimonForsman

Share this post


Link to post
Share on other sites
Butabee    274

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.

Share this post


Link to post
Share on other sites
Butabee    274

If anyone is having problems with network.instatiate leaving old copies of disconnected players around you have to make an RPC call with the RPCMode set to allbuffered that calls Network.RemoveRPCs Network.DestroyPlayerObjects. This only works if the objects were instatiated by a player.

 

This problem was driving me crazy for a whole day before I found a post about it buried in the web.

Share this post


Link to post
Share on other sites
Butabee    274

I've worked around the network views and pretty much do everything with RPCs. I also limited the amount of players that each player can receive updates for a second on the servier side.

 

With this I should be able to support 6000+ players assuming the server system can handle the physics. The networking could at least handle it... still not sure about the CPU and memory requirements.

Share this post


Link to post
Share on other sites
wodinoneeye    1689

"Players out of a certain range of each other have their networkviews disabled."

 

Now if you can guarantee that  N+1 players dont decide to all be in the same proxiimity   (the old problem)

 

Shrinking areas (radius) that players can see ? -- If throttling update rates gets too infrequent too fast ....

 

----------------------------------

 

 

"6000+ players"    unfortunately systems like this can bottleneck very quickly  (at lower numbers than you expect)  and sporadically (which even a fraction of the time can make the game unplayable)

Edited by wodinoneeye

Share this post


Link to post
Share on other sites
Butabee    274

I'm thinking I can turn off the colliders too and only send verty sparse player updates. Only smooth movement is based on the built in physics. I should be able to disable colliders for players outside viewing distance of others.

Share this post


Link to post
Share on other sites
Butabee    274

I tried turning off the colliders, and the player would crawl back to the old position at the time the collider was enabled when I tried moving.

 

I guess I'll see how low I can get the physics step without messing things up.

 

I'm also using character controllers for NPCs and players which aren't as strenuous as something like a rigidbody would be.

Edited by Butabee

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this