• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Butabee

Max players with unity server

17 posts in this topic

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

Share this post


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

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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?

0

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  
Followers 0