Team creation algorithm via player preference

Question

I'm making a matchmaking client that matches 10 people together into two teams:

Each person chooses four people they would like to play with, ranked from highest to lowest.

Two teams are then formed out of the strongest relationships in that set.

How would you create an algorithm that solves this problem?

Example:

Given players [a, b, c, d, e, f, g, h, i, j], '->' meaning a preference pick.

a -> b (weight: 4)
a -> c (weight: 3)
a -> d (weight: 2)
a -> e (weight: 1)

b -> d (weight: 4)
b -> h (weight: 3)
b -> a (weight: 2)
...and so on

This problem seemed simple on the surface (after all it is only just a matchmaking client), but after thinking about it for a while it seems that there needs to be quite a lot of relationships taken into account.

Edit (pasted from a comment): Ideally, I would avoid a brute-force approach to scale to larger games which require 100 players and 25 teams, where picking your preferred teammates would be done through a search function. I understand that this system may not be the best for its purpose - however, it is an interesting problem and I would like to find an efficient solution while learning something along the way.

Answer 1

A disclaimer first.

If your user suggested this, there are two possibilities. Either they can provide the exact details of the algorithm, so ask them. Or they most probably don't know what they are talking about, and just generated a partial idea on the spot, in which case, it's sadly not worth much on average.

So, one option is to search how matchmaking works in other projects, disregarding the idea completely. Another is to explore the user's idea. Probably it won't turn into a good system, but there is a chance it will. In any case, you will have to do some experiments yourself.

---

Now, to the case where you are going to have fun exploring the idea. First, for separating ten items into two groups of five, there are just choose(10,5)=252 possibilities, so, unless the system has to do it millions of times per second, you can just calculate some score for all of them, and choose the best one. The most straightforward way is perhaps to consider all 2^{10} = 1024 ways to form a subset of 10 elements, and then explore the ones where the size of the subset is 5. But there may be better, more to-the-point, tools readily available, depending on the language or framework. The 10-choose-5 combination is one group, the items not taken are the other group.

So, what would be the score of a combination? Now we look at our preferences.

1. For each preference satisfied, we can add its weight, or its weight squared, or otherwise, to the score. Which works best would sure need some experimentation.

2. Similarly, for each preference not satisfied, we can add a penalty depending on its weight.

3. Next, we can consider all players, and maybe add more penalty for each of the players which has none of their preferences satisfied.

4. Another thing to consider is team balance. Since the only data so far are preferences (which may well turn out to be insufficient), an imbalance means that one team has many of their preferences satisfied, and the other has only few, if any at all. So, we add yet another penalty depending on the absolute difference of (satisfaction sum of the first team) and (satisfaction sum of the second team).

5. Sure there can be other things to factor in...

Based on all this, construct a system which at least looks plausible on the surface, and then experiment and experiment again, tweaking it so that it better fits the matchmaking goals.

Answer 2

I would think of a way to score proposed teams against the selections from people, such as scoring proposed teams against the weights.

I would try and optimise this by hill-climbing (e.g. swapping a pair of people and looking to see if that improves the score) if only because people could look at the final solution and try this themselves - so you don't want to miss improvements of this sort.

I would hill-climb multiple times, from different starting points, and pick the answer found with the best score, because hill-climbing will probably end at local optima, not global optima.

At least some of the starting points should be based on people's original selections. This would be easiest if you got people's selections to amount to an entire team's worth of choices, but you can probably build up a team from multiple suggestions if you say that you will follow person A's suggestions, and then person B's selection if needed, and then person C's selection if needed, and so on.

If you include as starting points everybody's selections, or selections based on priority ABCDE.. and then priority BCDE... and then priority CDEF... then you have the property that if anybody submits a perfect selection your algorithm will recognise it as such.

If your hill-climbing algorithm tries swapping all pairs of players to improve, and continues until it finds a local optimum and then stops, then you also have the property that if anybody submits a selection which is only one swap away from perfection, your algorithm will recognise it as such.