question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Match-making in a clustered environment

See original GitHub issue

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 😃

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:7
  • Comments:8 (6 by maintainers)

github_iconTop GitHub Comments

3reactions
endelcommented, Apr 29, 2017

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

2reactions
darkyencommented, Apr 14, 2017

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

IoT Service Clustering for Dynamic Service Matchmaking - PMC
Therefore, techniques that cluster services offline according to their similarity are critical for dynamic service matchmaking, discovery, and ...
Read more >
Application of Clustering In Matchmaking - IJSEAS
Abstract. Some persons make friends with others they have some attributes in common with. This type of friendship between two persons to a...
Read more >
cluster matchmaking | European Cluster Collaboration Platform
European Cluster Matchmaking leads to new innovations and collaborations In the last week of September, 175 clusters representing more than 15,000 companies ...
Read more >
Matchmaking: A New MapReduce Scheduling Technique
Abstract— MapReduce is a powerful platform for large-scale data processing. To achieve good performance, a MapReduce scheduler must avoid unnecessary data ...
Read more >
Matchmaking in reward-based crowdfunding platforms
Traditional clustering methods fail to accurately cluster the feature vectors of ... Business Strategy and the Environment; Annals of Operations Research; ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found