Suggestion: Allow queueing for multiple timecontrols at once

[IsaVulpes]

As one gets closer to the rating edges, player count drops off sharply, increasing queue times. In particular when looking for some of the less popular timecontrols (ie longer ones), the queue times ramp up quite a bit (at bad hours, they might take longer than the game will)

However, often one doesn't actually care too much which TC exactly one ends up in. For example, I like playing [Rapid with Increment], but to me it's not of particular importance whether that turns out to be 10+5 or 15+10 (in practice, that'll mean that I majorly queue for 10+5, as the queue times are shorter there - which in turn means that the 15+10 queue time gets even longer for everyone else).

As such, I would propose some way of queueing for multiple TCs at once: If I could select both 10+5 and 15+10, and land in whichever found a game quicker, queue time should logically go down by quite a bit (even moreso if my parameter is just "longer game", and I get to queue for 10+5, 15+10, 30+0 & 30+20 all at the same time), plus having the extra benefit of populating the smaller queues for everyone else (see above: currently, everyone who would be fine with either 10+5 or 15+10 just searches for 10+5, which makes it hard for 15+10 seekers to find a game; if they all queued for both, there would be more 15+10 games overall).

If two players that both queued for multiple TCs of the same category match up (eg player A searched for 5+3, 10+0, 10+5; player B searched for 10+0, 10+5, 15+10; they are matched in Rapid - now either 10+0 or 10+5 would be valid pairings), I think either randomising it (coinflipping whether they play each other in 10+0 or 10+5) or defaulting to the longest valid TC (as it's rarer to get games there) makes sense

Thank you for your consideration! :)

[ornicar]

I tried it before and found it very difficult to synchronize the different pools to avoid race conditions where more than one seeks are accepted at once.

[link2xt]

I tried it before and found it very difficult to synchronize the different pools to avoid race conditions where more than one seeks are accepted at once.

I am not familiar with the code, but this sounds like the code needs larger refactoring to place everyone in a single pool and match time control, variant etc. in the same way as the rating. Internally it should be possible to place requests like "match Chess960 with 10+5 or 10+0 time control and rating [-250, +100], or standard chess with 3+2 or 30+0 time control and rating [-500, +500]". Not necessarily in the UI, but the backend should allow it.

[link2xt]

By the way, chess.com implements it in the UI by allowing you to queue more offers while you are waiting for previously placed ones. So you can create some unpopular variants first and then keep adding more popular ones until you are matched.

[370417]

I've given this some thought recently, and I think it's doable. To be clear, queuing for multiple time controls would be for pools only, not for the lobby.

Basic idea: put everyone in the same pool, as suggested by link2xt. We already build a graph of players in a pool, so we can encode time control preferences by only setting edges between players who have picked the same time control.

Problem: pools attempt matching periodically (aka the wave system), and each pool currently has a unique period between match attempts. This is because the current pool system uses the period to control how many players are matched at once. If too few players are available at every match attempt, they will face large rating differences. If too many players are available, they will face longer waiting times. Each pool has a unique period because each pool's queue has a different popularity. There is no universal period we could pick for a global pool.

Solution: don't rely on period to control how many players are matched at once. Instead, avoid matching players who haven't been waiting for very long. This allows matching to happen more frequently without compromising match quality.

Pros:

• Allows for selecting multiple time controls at once.
• The distribution of wait times might become narrower, math willing, since we would have more control over matching.

Cons:

• More complex.
• More expensive. Matching is an O(n^3) operation where n is the number of players, and a naive implementation would make n go up a lot. Plus we would be running matching more often.

At the cost of even more complexity, there are solutions for maximum-cardinality matching in O(sqrt(n)m) time where n is the number of players and m is the number of edges between players (Wikipedia). There are a few options, and all of them are complicated, apparently. Of course better time complexity does not equal faster in every situation. But I think an algorithm bound by edges instead of just vertices seems promising, as the global pool's graph would be a lot less dense those of the per-time control pools.

At max I'd guess roughly 400 players might be queuing at any given time. At that scale, choice of algorithm probably does not matter for performance.