Match-making in a clustered environment

This question pops up often in the gitter channel. Currently there’s no cluster support for Colyseus.

The rough idea is to separate match-making server from room handler (game session) processes:

• Match-making should be a central unit to determine which server/node should the client join
• Vertical scaling: Room handlers can live on multiple processes
• Release version 0.5.0!

Any thoughts and ideas are welcome 😃

[endel]

Apparently, socketcluster solves pretty well scaling vertically/horizontally. I’m starting to investigate how to integrate the cluster module in the framework.

[darkyen]

I’m implementing my owns system for this and here are the highlights of my system and how I’m achieving those things. Although I did not have knowledge of Colyseus and this is a fairly simple system I implemented for my own requirements which is slightly similar to bucket sort. I’d also be happy if the more experienced people would like to loop into this. I’m currently porting this to use colyseus

I have an interface Requester (peer) which must implement a function getInfo which may return data about the peer. This function is called when initializing the peer and can be fetched from a database/in-memory adapter etc.

The Requester goes inside a bucket called Room. Each room has a function matches(arg) which accepts the info returned by Requester.getInfo and returns 0 - 1 to measure the suitability for the player in this room. In my simple implementation I have a min. skill level and max. skill level which which check if the user’s skill.

There is a singleton MatchMaker which does the actual match-making the algorithm for match making is as follows. Please note all the methods here are async and things can wait for completion.

Expand step:

• Every time a new peer arrives
  • Find the best room for the peer based on the matches.
  • If no match satisfies this criteria create a new room. This maybe left unimplemented if a single static list of rooms/servers is to exist.
  • Add player to the found or created room.
    • If the room is full start the room.
  • Increment time to wait for other people to join before we start the crunch step.

Crunch step:

• When we have waited long enough and the room cannot be started
  • If there are lower players waiting then needed.
    • Handle this (create a bot, tell player not happening, something else?).
  • For every room which is waiting expand the criteria.
    • This can be done either by merging rooms with closer avg. skill level.
    • Wait for next cycle.

The advantage of this simple algorithm is that it can read from a global state and as both getInfo and matches are provided by the developer. This can handle very complex scenario’s like ping to servers, multiple skill differences, team balancing etc in the matches method. Bonus is that this can live in its own package and can be independent of colyseus the matched players array can then be sent to the server & client in the “start” method handler which will then connect to one another.

The disadvantage is that this system will punish a game with lower number of clients and even more when the gamers average skill level is higher. This will require a centralized authority and will not very well (or at all) in disturbed environment. Although multiple instances can vote for a leader which decides the pairing and then initiates pairing on that master. Wait times can be reduced by making the clients and rooms wait aware so that they compensate for waiting clients.