| 1 |
Does the MM kick people out of the queue when a (room-based) game starts? Does it offer games to people already playing a game (if it doesn't actually kick them out or if they just re-enter)?
|
1 |
Does the MM kick people out of the queue when a (room-based) game starts? Does it offer games to people already playing a game (if it doesn't actually kick them out or if they just re-enter)?
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Perhaps something to try would be to make MM-queued people already playing ineligible for a game (as if they were outside rating threshold with everybody else), but still in the queue (so eligible again inbetween room games). Then there is no downside to just queuing to MM before entering the pot. You won't ruin anybody's game, and nobody will ruin yours, by rejecting due to already being in a game.
|
3 |
Perhaps something to try would be to make MM-queued people already playing ineligible for a game (as if they were outside rating threshold with everybody else), but still in the queue (so eligible again inbetween room games). Then there is no downside to just queuing to MM before entering the pot. You won't ruin anybody's game, and nobody will ruin yours, by rejecting due to already being in a game.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
Some further minor changes would likely be needed as well, but maybe these are not needed for the core idea:
|
5 |
Some further minor changes would likely be needed as well, but maybe these are not needed for the core idea:
|
| 6 |
* prevent race conditions. Perhaps people in rooms that are not yet ingame but are undergoing a !start vote are ineligible. Perhaps !votestart asks the MM to proc, and if there is anybody in the room that gets an invitation the votestart is delayed. Perhaps in an autohost, the usual no-vote period and the subsequent forced !map/!start votes are delayed to let MM work.
|
6 |
* prevent race conditions. Perhaps people in rooms that are not yet ingame but are undergoing a !start vote are ineligible. Perhaps !votestart asks the MM to proc, and if there is anybody in the room that gets an invitation the votestart is delayed. Perhaps in an autohost, the usual no-vote period and the subsequent forced !map/!start votes are delayed to let MM work.
|
| 7 |
* perhaps mark people differently, eg. instead of "8 people queued" it's "3 queued, 5 busy ingame" so it doesn't look dead but also not bugged when it doesn't make a game.
|
7 |
* perhaps mark people differently, eg. instead of "8 people queued" it's "3 queued, 5 busy ingame" so it doesn't look dead but also not bugged when it doesn't make a game.
|
| 8 |
* perhaps have the MM itself delay an iteration after a lobpot ends by say 30s, to give people some breathing room. Or maybe the invitation lasts a bit longer than usual, idk. Basically, replicate the little breathing room the lobpot gives.
|
8 |
* perhaps have the MM itself delay an iteration after a lobpot ends by say 30s, to give people some breathing room. Or maybe the invitation lasts a bit longer than usual, idk. Basically, replicate the little breathing room the lobpot gives.
|
| 9 |
* perhaps if MM drags you out of a lobpot, the pot remembers your waiting list position. So if you come back to the same room after the MM game you aren't disadvantaged.
|
9 |
* perhaps if MM drags you out of a lobpot, the pot remembers your waiting list position. So if you come back to the same room after the MM game you aren't disadvantaged.
|
| 10 |
\n
|
10 |
\n
|
| 11 |
This avoids the pitfalls of previous attempts:
|
11 |
This avoids the pitfalls of previous attempts:
|
| 12 |
* it would still require manually clicking the MM button in the MM tab, there is no popup prompt or anything. This is good because it prevents randoms from not paying attention, clicking the popup to go away, and then ruining the game by exiting.
|
12 |
* it would still require manually clicking the MM button in the MM tab, there is no popup prompt or anything. This is good because it prevents randoms from not paying attention, clicking the popup to go away, and then ruining the game by exiting.
|
| 13 |
* it is not forced. If nobody in the lobpot is queued, they keep all 32+ people.
|
13 |
* it is not forced. If nobody in the lobpot is queued, they keep all 32+ people.
|
| 14 |
* it obeys people's exact preferences. If everybody in the lobpot somehow signs up for the 1v1 MM, it immediately makes 16 1v1s afterwards (as opposed to split that makes two 8v8s and that doesn't split further). This also somewhat prevents the case where sad lobs from the low skill half plead for the other half to exit (since the MMs are exactly the size the people inside want them to be, they don't want more).
|
14 |
* it obeys people's exact preferences. If everybody in the lobpot somehow signs up for the 1v1 MM, it immediately makes 16 1v1s afterwards (as opposed to split that makes two 8v8s and that doesn't split further). This also somewhat prevents the case where sad lobs from the low skill half plead for the other half to exit (since the MMs are exactly the size the people inside want them to be, they don't want more).
|
| 15 |
*
it
still
has
the
built-in
MM
quality
control
that
won't
make
a
stupidly
imbalanced
game.
This
is
another
part
of
preventing
sad
lobs
from
getting
not
what
they
wanted
and
exiting.
Bad
MM
games
can
still
rarely
happen
but
in
that
case
we
should
tweak
the
MM
algo
regardless
of
the
lobpot
case
because
MM
also
works
standalone.
|
15 |
*
it
still
has
the
built-in
MM
quality
control
that
won't
make
a
stupidly
imbalanced
game.
People
can
pick
wide/regular
queues
to
declare
how
good
of
a
game
they
expect.
This
is
another
part
of
preventing
sad
lobs
from
getting
not
what
they
wanted
and
exiting.
Bad
MM
games
can
still
rarely
happen
but
in
that
case
we
should
tweak
the
MM
algo
regardless
of
the
lobpot
case
because
MM
also
works
standalone.
|
| 16 |
* it doesn't require the arcane knowledge of obscure !commands, it uses the existing MM GUI.
|
16 |
* it doesn't require the arcane knowledge of obscure !commands, it uses the existing MM GUI.
|
Vote to split Teams - All Welcome into 2 smaller teams rooms?