1
\$\begingroup\$

I have a pretty good understanding of how to scale servers but there's one thing I can't quite be sure about is how to manage a lot of players in a concentrated area.

If I have a server which is using multiple threads and processes as long as you limit the amount of players that can join a single game instance then this can scale indefinitely by adding more servers and placing it behind a load balancer.

But MMO games don't work that way because it's broken down into zones that anyone can connect to. So if a massive amount of players all decided to connect to the same zone it would put all of the stress on 1 server.

If you tried to spread the load across multiple servers then you'd run into problems of having to share information between the servers (Such as if player X was connected to sever 1 then all of his movements would also have to be passed on to the players connected to server 2 since server 1 and 2 are managing the load for the same zone).

So I was wondering how do you go about solving this problem? Do you just keep on ramping up the specs for the server on heavily populated zones? Or is there a fast and efficient way for multiple servers to manage the load for the same zone and efficiently share data between the two servers?

\$\endgroup\$
  • \$\begingroup\$ While I can't help you with the technical details, it's pretty much a known fact that a game like World of Warcraft, for example, uses multiple blade servers to host a single "realm" or "zone". I recall reading an article about how they can shift load dynamically: e.g. when a new instance is released, or a special event is taking place, they give that particular zone much more power. In a situation where you need more power, I think this is the only solution. Sharing information between the servers shouldn't be an obstacle with datacenter-grade intercommunication. \$\endgroup\$ – Ivo Coumans Feb 16 '17 at 12:44
  • \$\begingroup\$ Read CCP's Eve-Online dev blogs. \$\endgroup\$ – Almo Feb 16 '17 at 15:42
2
\$\begingroup\$

Are you already familiar with technologies that exist like redis? Server architecture is definitely a complicated subject and it's good that you're planning it out now, but you might be worrying without cause and underestimating the amount of throughput possible with a well-written scalable backend.

In my experience, it's better to have servers set up to handle their own zones, but written in a way so that in the future, it's easy to modify a particularly busy zone to run multiple load-balanced servers. At that point, each server on the zone should be handling around 1000-2000 concurrent connections, and propagating player data using something like redis between the nodes.

Another common solution I've seen (particularly on popular minecraft servers) is to tweak the actual game design to limit the amount of players on a single server. To do this, have multiple load-balanced servers for the same zone, but allow the player to see what server they're connected to, and only render player data within that server. The result is multiple "realities", where each server independently has a different crowd of players in the same apparent area, but this reduces server stress and gives the flexibility of allowing the player to switch freely between servers if they want. If you do allow them to switch (in order to meet with a friend or something), impose a maximum player count per server, and you'll have a hard limit of how much each server should ever have to handle.

You should at least get a working game and run some simulation tests with a few hundred or thousand client connections to get actual performance specs before worrying where you should go from there. It's possible that there might not be an issue at all.

Also, before you concern yourself with the massive numbers of players you're asking about, consider that your game might not ever be that popular. I mean no offense, it's just relatively rare to develop a "hit." So instead, focus on more important issues like good game design, so that you'll be able to worry about this later on.

\$\endgroup\$
  • \$\begingroup\$ I'm not building an MMO, these are things I've been wondering \$\endgroup\$ – user1157885 Feb 16 '17 at 13:05
  • \$\begingroup\$ @user1157885 your question history would suggest otherwise. I appreciate the feedback, but I do consider my answer to be pragmatic. I did elaborate more on a specific server architecture I've found success with if that helps though. \$\endgroup\$ – Patrick Roberts Feb 16 '17 at 13:12
  • \$\begingroup\$ Server architecture is knowledge of tecnologies and deployment, while theorically all that stuff is "easy" configuring machines is really a big problem, so going from theory (technologies) to deployment is always a very big step. Better be prepared \$\endgroup\$ – GameDeveloper Feb 16 '17 at 13:53
  • \$\begingroup\$ It is no benefit to anyone litigations on SE. Misunderstanding is common, exactly in the same way when a Client meet a IT professional, it is responsability of both parties to understand the each other needs (mostly this task is for the IT professional in reality, but very professional clients are not uncommon, especially if they are coming from industry). Misunderstanding is never a problem as long as you quickly resolve it in a pacific and polite way. Revenge downvoting etc will be early catched by mods/automatic filters etc. \$\endgroup\$ – GameDeveloper Feb 16 '17 at 14:15
  • \$\begingroup\$ Yeah you're right, I shouldn't be so hostile. It just grinds my gears when people jump to conclusions, then look through post history to come to even more incorrect conclusions. The question was purely out of curiosity because I have an interest in it and it wasn't something to easily google so I wanted to hear the opinions of others. \$\endgroup\$ – user1157885 Feb 16 '17 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.