I am in the phase of designing a mmo browser based game (certainly not massive, but all connected players are in the same universe), and I am struggling with finding a good solution to the problem of distributing players across processes.
I'm using node.js with socket.io.
I have read this helpful article, but I would like some advice since I am also concerned with different processes.

Solution 1:
Tie a process to a map location (like a map-cell), connect players to the process corresponding to their location. When a player performs an action, transmit it to all other players in this process. When a player moves away, he will eventually have to connect to another process (automatically).

  • Easier to implement


  • Must divide map into zones
  • Player reconnection when moving into a different zone is probably annoying
  • If one zone/process is always busy (has players in it), it doesn't really load-balance, unless I split the zone which may not be always viable
  • There shouldn't be any visible borders

Solution 1b: Same as 1, but connect processes of bordering cells, so that players on the other side of the border are visible and such. Maybe even let them interact.

Solution 2:
Spawn processes on demand, unrelated to a location. Have one special process to keep track of all connected player handles, their location, and the process they're connected to. Then when a player performs an action, the process finds all other nearby players (from the special player-process-location tracking node), and instructs their matching processes to relay the action.

  • Easy load balancing: spawn more processes
  • Avoids player reconnecting / borders between zones


  • Harder to implement and test
  • Additional steps of finding players, and relaying event/action to another process
  • If the player-location-process tracking process fails, all other fail too

I would like to hear if I'm missing something, or completely off track.


2 Answers 2


This is a very vague question, but I'll mention the things you haven't really mentioned and need to consider:

  • If processes are unrelated to location, that could mean a lot of internal network traffic for pretty much every action your game handles. Ideally a process should have some sort of internal coherence so that it can minimise network traffic; another way of doing this is to have different processes handle different types of activity, so that information private to that activity never has to hit the network.
  • You need to consider how to process events that involve more than one person. Can one player trade with a player on another server?
  • When reconnecting to a new process, you don't necessarily have to have disconnected from the old process. (You are allowed more than one network connection, after all.)
  • If you have to query other processes to collect information about them as the result of an action, what does the first process do while it waits for responses? What if new information arrives while you're waiting for the responses, and can it invalidate one or more of the responses?
  • When you need to save important values to disk, which process is responsible for that? And if it is variable, how do you decide?
  • You are assuming the 'load' falls on these back-end servers - but what about the central server in Solution 2? If every player and every action goes through that server then it may not matter how many back-end servers you have.

I don't understand the idea of splitting players across different processes. It sounds like a very premature optimisation which isn't needed.

Surely it's best to have a single server process which everybody connects to, which has enough capacity to handle all the players at once (you plan for < 10k concurrent players, right?)

There is probably still a need to avoid sending irrelevant updates to all players, but that's still quite feasible.

Personally, I'd suggest that you make it work, test it with 10k players, then attempt to optimise it as needed, rather than having some ludicrously-complicated optimisation built-in to the design before it even works for 2 players!

  • 1
    \$\begingroup\$ The ideal is a single server process but the reality is that it's very difficult for one process to support 1000 or more concurrent players - and by the time you know that you have 1000 concurrent players rather than 100 players you won't have the time to perform optimisation. Beyond that, it's unlikely that you can support more than 5000 no matter how well-optimised the code. The only way to scale is 'out' rather than 'up', and that means starting with a different approach. \$\endgroup\$
    – Kylotan
    Commented Jul 1, 2012 at 20:29
  • \$\begingroup\$ In this way you can justify anything. Performing such an optimisation is not infinitely hard, and if it proves unnecesarily it will avoid a lot of problems later. \$\endgroup\$
    – MarkR
    Commented Jul 1, 2012 at 20:41
  • 1
    \$\begingroup\$ Not 'anything', just this type of game. There is plenty of empirical evidence about how many concurrent players one server can support, and it is not enough for a game that expects thousands of players. Therefore you have to assume a multiple-process model, which require different algorithms for almost everything. \$\endgroup\$
    – Kylotan
    Commented Jul 1, 2012 at 20:54
  • \$\begingroup\$ Right now I have a multiplayer demo working, so I'm not totally insane. The thing is, I DO plan for >10k players. One process alone will NOT be able to handle the entire universe/world. There can't be multiple worlds by design, so the world has to be split up into zones, managed by different processes. \$\endgroup\$
    – Gipsy King
    Commented Jul 2, 2012 at 8:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .