How is matchmaking done at competitions? (Kind of a rant)

Competition
#102

We faced our toughest quals lineup we’ve ever seen at Greater KC this weekend, facing #1 seed twice (and never with), and #2 seed twice (and once with). In fact, our first match was against #2 + #3, and our second match was #1 + #2. And it was 36 teams with 12 quals matches each.

To be clear, I’m not posting this to whine. We performed amazingly well even though we still ended up #23 of #36, owing not just to the lineup, but bad luck (6 out of 12 matches, we were a bot down in some way), and the fact we had no hab 3 climb (our own decision and our own fault). But I can say that our lineup wouldn’t have been fair to anyone and I wouldn’t want to see any other team face it either.

However, I’m 100% behind a static pre-generated set of quals matches with teams randomly slotted in. Especially if these are calibrated to be well balanced. I think it would work out best for everyone.

1 Like
#103

The work of determining match separation, quality, etc. is 100% done by match maker. No volunteers can say “I want lower/higher quality matches this weekend.”

This disagrees with the Matchmaker White Paper, which says "The algorithm allows the user to specify a desired quality. " It may be that First has taken the decision away from the volunteer. If so, that’s not described by the whitepaper.

But, that leads to another question: why is quality ‘determined’ by matchmaker? Why is it not set to ‘best’ every time?

The schedule is determined by these inputs:

  • Match cycle times (time between starting match X and match X + 1)
  • Start/end times each day
  • Breaks (e.g. lunch)
  • Number of matches per team

It isn’t really the schedule that’s the problem; it’s the match assignments and their ordering. And, that does not depend on the first three of those bullets. It depends entirely on (a) the number of teams and (b) the number of matches. The set of {a,b} pairs is sufficiently small that “the” match ordering for {a,b} can be determined in advance with teams randomly assigned into the pre-determined schedule at the event. If, for whatever reason, a team withdraws, then just go to {a-1,b}. (Realistically, b would probably change also.)

There is evidence that the current scheme is not working as well as it could. At an event this past weekend, we were opposed to the same team 4 times, another 3 times and two others 2 times, but never in an ailiance with any of those teams. If “pairing uniformity” is a goal of the algorithm, it failed, at least in our case.

2 Likes
#104

This past weekend made me think this year’s algorithm is flawed.

I love 195, but playing against them 3 times in quals but never with them is less than fantastic. Not playing with or against 177 all weekend was also strange at a 38 team event. (then playing 195 in quarterfinals oof)

#105

Akash we can do you one better.

We (3467) had to face 1519 four times during qualifications at Pine Tree with three of them back to back and never with. The event was 32 teams. It was all good among friends and while we could gripe “they are x seed” the two teams were able to walk away 2-2. We saw other familiar faces including back to back alliance partners which was to be expected but FOUR was a new extreme I’ve never seen. I really didn’t care how good 1519 was on the field, and they are very good, but a schedule shouldn’t be capable of putting that out.

Dear FIRST, its time to make a better system for 24-40 team events.

1 Like
#106

FIRST takes away all inputs from the scoring table except for number of matches per team. The table cannot enter the quality of schedule, minimum match separation or anything else.

2 Likes
#107

Do you know what parameters are fed into the algorithm?

#108

This is the second week a team has played us 3 times.

7127 played 195 3 times in a row at WNEU on Sunday morning, and then ended up having to play us in quarters after that, making a 195vs7127 matchup 5 times in a row on Sunday.

I understand the quarterfinal matchup was unavoidable, but there is just no way that it was pure coincidence in the algorithm that placed 7127/5686 against 195 three times.

There’s something fishy here.

#109

2 Likes
#110

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.