MaxCWhitehead
commented
1 month ago So right now for a 2-4 player game, we have 3 queues (rooms) (2/3/4 player) on matchmaker, and each match request is hashed into those adding a player. Players are immediately placed into room, and room starts immediately as they fill and cycle continues.
Thinking about some changes in how matchmaker processes requests / rough logic:
Store queues of players based on hard requirements, instead of queues based on player count that flush as soon as they are full (what we currently have.) With an update loop we can flush possible matches with some strategy:
- If enough players queued for fixed match size, start match asap
- If players with fixed size waiting for others, and players with no size specified, start match if possible.
- If only players with no size specified and >= max player count for game in queue, start immediately.
- If only players with no size specified, start match with available players (less than maximum) if one of them has been waiting too long.
-
If only players with no size specified that very recently queued, wait a fixed time to see if there are any more players before starting. (Or some other heuristic, possibly based on how often new players queue)
I think another advantage to having a queue of players vs immediately placing them into rooms as they request match is that we can apply other criteria such as matching based on their ping to each other. (How we do that exactly I'm not sure. Wondering how long it would take for them to establish ephemeral Iroh connections to each other and pinging.)
Right now player count must be specified explicitly. A player in a game that supports 2-4 players may not care how many players they play with, but currently are forced to select either 2/3/4 size match. If players don't make similar selections, we are kind of splitting the match making pool which may not be ideal.
Should allow a range in matchmaking protocol so player could select "Any" player count during matchmaking.