Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

For this post, we'll assume my game is multiplayer chess as it essentially requires the same functions. User logs in to the server and requests a game - the server provides a simple matching service and once done, they start the game. They get 30 seconds timed by the server per turn with 6 players in each game and however many spectators (probably very limited).

I would like to know how you would scale this.

I've considered two options:

Option 1

1) Main server to handle login / match making (which regardless of user numbers should be a fairly easy task)

2) Start new Node servers for each game that close when the game ends.

I'm not entirely sure how this could be implemented yet. (i.e. would the user connect to the main server still and the requests just be passed to the new server or would the user change connection to the new server and then back again when done? changing connection would reduce the load even further and as the two servers won't require communication between them, should be fairly simple)

Option 2

Have 1 Node server and somehow scale it.

--

Suggestions / input?

I'm planning on hosting on Amazon AWS and am well aware that the chances of my game even warranting this level of detail are probably nil but I'm taking this as a learning opportunity.

Thanks.

share|improve this question
    
Well, your players are making one move (which is just a few bytes) every 30 seconds. That's really not much traffic. I think it will really take a while until you get performance issues. –  Philipp Dec 27 '12 at 17:34
    
I don't deny that. As I say, learning curve. I have now read up on pub/sub with redis which looks like it could do what I was saying. Main server for everything. Pub/sub. Game server to handle all the games - therefore allowing for multiple servers to be set up if required. –  Chris Evans Dec 27 '12 at 20:06

1 Answer 1

up vote 2 down vote accepted

General way to handle this is to allow multiple game servers to be spun up, and whenever a new game is started, one is chosen and the client is told to connect to that server. You can then add and remove game servers as necessary to scale horizontally, essentially limited by only by hardware/bandwidth capacities.

Scaling up the login servers can be done by using round-robin load-balancing on your servers, which can be achieved at the DNS level, or via a hardware load balancer (generally not cheap, though some data centers offer use of a shared load balancer for a price). The same can be done with the match making servers.

You can also deal with this per region. That is, your customers in China might be using a different set of servers in a Chinese data center while your customers in North America might be using a set of servers in a data center there. Or if NA is where most of your customers are, you can split up the data centers between the east and west halves of the continent.

Things get tricky when it comes to sharing data between your servers. In these cases, it is generally better to have a middle layer between the main game/logic servers and the backend storage. That is, don't have your game servers access a database to look up player information. Instead, create an internal API (using REST over HTTP, or an AMPQ infrastructure, or what have you) that servers use to communicate with backend services. The advantage of this approach is that it makes physically distributing your services easier. You might want those match making and game servers split between China and NA, but you might want all account information to be centralized so players in each region can friend each other and start direct matches with each other (of course one of the two players will be using a non-ideal game server for their location, but no way around that). With an API, you can have your Chinese data center game servers talk to a local API proxy that caches requests made to the "authoritative" servers in NA, allowing distributed operation with good horizontal scalability and a single primary data store for user accounts.

Keep in mind that you'll want to limit that as much as possible to infrequently changing data, since you'll need to do all writes to the primary data center to avoid collisions. That is, you can't share user accounts between a NA and a Chinese datacenter is both can create accounts locally, since two users might try to create a user account with the same name in both regions. Since you'll be forced to use one data center as the authoritative master for this data, that means creating accounts in other regions will be a tad bit slower. Account creation is generally not something that needs fast response times, so that's not a huge deal; if you're trying to track play stats for every move in your game, though, it might become an issue. For cases like that, you'll want to aim towards a data design that allows merging data later in bulk, rather than needing to keep a real-time data set in an authoritative server.

All that said, you probably don't need to worry too much. A simple turn-based board game style of thing is not going to be particularly data intensive, and your odds of getting lucky and being successful enough to have so many users that one server can't handle the load is pretty small.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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