Jump to content

  • Log In with Google      Sign In   
  • Create Account


Max players with unity server


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 30 January 2013 - 02:23 AM

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.

Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 14299

Like
0Likes
Like

Posted 30 January 2013 - 05:16 PM

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


#3 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 30 January 2013 - 07:07 PM

Thanks, sounds good.

#4 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 01 February 2013 - 01:05 AM

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



#5 Kylotan   Moderators   -  Reputation: 3329

Like
0Likes
Like

Posted 01 February 2013 - 07:36 AM

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."



#6 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 01 February 2013 - 04:16 PM

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.



#7 SimonForsman   Crossbones+   -  Reputation: 5804

Like
1Likes
Like

Posted 01 February 2013 - 05:26 PM

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, 01 February 2013 - 05:33 PM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#8 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 01 February 2013 - 06:26 PM

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, 01 February 2013 - 06:37 PM.


#9 SimonForsman   Crossbones+   -  Reputation: 5804

Like
0Likes
Like

Posted 02 February 2013 - 06:55 AM

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, 02 February 2013 - 07:00 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#10 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 02 February 2013 - 06:40 PM

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.



#11 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 02 February 2013 - 09:58 PM

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.



#12 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 07 February 2013 - 11:12 PM

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.



#13 wodinoneeye   Members   -  Reputation: 679

Like
0Likes
Like

Posted 08 February 2013 - 08:18 AM

"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, 08 February 2013 - 08:21 AM.

--------------------------------------------Ratings are Opinion, not Fact

#14 ApochPiQ   Moderators   -  Reputation: 14299

Like
1Likes
Like

Posted 08 February 2013 - 11:36 AM

Unity is going to barf with 6000 players in a single physics space.

#15 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 08 February 2013 - 05:25 PM

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.



#16 ApochPiQ   Moderators   -  Reputation: 14299

Like
0Likes
Like

Posted 08 February 2013 - 06:40 PM

I'm not deeply familiar with how well PhysX scales, but you're likely to run into a lot more problems than just separating your collider groups into simulation islands.

#17 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 08 February 2013 - 06:56 PM

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, 08 February 2013 - 07:23 PM.


#18 Butabee   Members   -  Reputation: 212

Like
0Likes
Like

Posted 08 February 2013 - 09:11 PM

I guess another thing I could do is disable static object colliders when nothing is near them.

 

Does Unity physics use any sort of space partitioning?






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS