1

I am trying to come up with a matchmaking algorithm based on player ratings for my game, and I am pretty sure the algorithm I have is not the best (or maybe doesn't even work), but have no idea how to improve it.

Suppose that I have 5 players, ABCDE, and I want to create a 2v2 match. Each party of 2 have their own ratings precalculated. Suppose that my algorithm is based on minimizing the rating difference between the two parties. DIFFRAT below means the absolute value of the rating difference between the 2 parties:

To start I would generate all possible matchmaking combinations and calculate their DIFFRAT. For 5 players, ABCDE, here are a few of the possible matchmaking combinations:

AB->CD (DIFFRAT = 2)

AB->CE (DIFFRAT = 0)

AB->DE (DIFFRAT = 1)

AC->BD (DIFFRAT = 4)

AC->BE (DIFFRAT = 5)

AC->DE (DIFFRAT = 2)

AD->BC (DIFFRAT = 0)

Currently, the match making algorithm I have would recursively pick the lowest DIFFRAT match first. Then remove the matches where the players already match made.

However, this is problematic when there are n players, and n/4 matches are to be created. This approach would always greedily pick the lowest DIFFRAT first, thus removing players from the better matchmaking options. In fact, this approach would probably prevent some players from finding a match as well.

What is a better way of implementing matchmaking than the one I have so far?

Mantracker
  • 111
  • 2
  • 1
    Welcome to CS.SE! Interesting problem. How large might $n$ be? If you wanted to create n/2 1v1 matches, then this could be solved by finding a maximum-weight perfect matching in an undirected graph (the weight of the edge between two players is the negation of their DIFFRAT). However here you want 2v2 matches, and I'm not sure how to solve that variant of the problem. You could use integer linear programming, but it might be too slow if n is too large. – D.W. Mar 11 '18 at 19:03
  • n would be depending on the size of the concurrent matchmaking players. Lets say 100? – Mantracker Mar 12 '18 at 02:53
  • You could try integer linear programming. It might be slow for n=100 (or it might not). Some ILP solvers have an option to terminate after a timeout and show you the best solution found so far, and that might be a way to find a non-optimal but maybe good enough solution. – D.W. Mar 12 '18 at 04:32

0 Answers0