zumos2 wrote:Another issue I see is people leaving pops because they know who they are facing. I don’t know the reason why the RoR-team made it so you can see who you are facing when the queue pops, but I think it would be better without it. Making a good matchmaking system when people just leave when they see hard opposition is never going to work. And that is exactly what I would like to see: a good match-making system. I’m not an expert in this, but I think there are definitely opportunities in making a good matchmaking system.
This was debug text for my benefit that I never got around to removing. It appears if a scenario pops with at least one group having been matched. It can be removed if it is causing issues.
zumos2 wrote:<role balancing>
The scenario manager algorithm attempts to balance roles only when adding solo players. I'm planning to refine this a little for groups, both by using the composition of a group as a weight when adding to the queue (to ensure that for example a 3 DPS group is prioritized below a balanced group) and by ensuring that the composition which comes closest to resolving any existing role imbalance in a scenario is used for a given player count fill slot, rather than the composition which includes the highest number of players in an individual group.
The matchmaker logic for groups is, broadly:
- For both sides, try every unique combination (i.e. NOT permutation) of group sizes which add up to a number between 2 and the maximum player spots left in the scenario, using the first available groups in each sublist and prioritizing combinations with the highest individual value for size
For example for 6 players:
[6] Priority 1
[4, 2] Priority 2
[3, 3] Priority 3
[2, 2, 2] Priority 4
- For any unfilled slots, use first group value encountered when descending from that slot (for example, empty 5 and 6 player slots above a 4 would use the 4 combination that was found)
- For any such slots, check with the solo queue whether or not any shortfall in players could be addressed using solo players, and if so, mark these slots as usable
- For a given slot X on realm A, check whether there exists such a slot Y on realm B which can be used with X such that the final playercount in the scenario is within 1 on either side, and if no such pair exists, return
- If a slot contains only groups, add immediately
- If a slot requires solo players, add the groups first, then attempt to pull solo players to match any role imbalance
Someone will probably ask: Why only match the first groups? Two reasons:
- It's a scenario queue, not a scenario pool - priority is given to those who queued first to preserve the important Queue Time element
- Optimization - Trying every permutation of groups in the queue, which would optimally solve for balance, is expensive, especially if balance needs to be compared (vector magnitude operations)