OR  Zero-K Name:    Password:   

Do the matchmaking queues work?

8 posts, 222 views
Post comment
Filter:    Player:  
14 days ago
I'm asking because I tried using it and, after several minutes with one other person also queued up for a 1v1, the game had still not started. I guess there might be a limit regarding the difference in skill levels, but if so it would be nice if this was made clear and if the game told you if there's currently anyone of an acceptable skill level queued, instead of just the raw number of players in there.
+0 / -0
I believe there is a max +-500 ELO rating range difference
+1 / -0
13 days ago
The widest matchmaker rating gap I have on record is https://zero-k.info/Battles/Detail/784161 between (at the time of the match) a 2521 rated and 1352 rated player, a difference of 1169.

I cannot find any hard limit looking through the infrastructure repository, but I am not confident enough in my ability to search the infrastructure repository to say that there is no hard limit.
+2 / -0

12 days ago
Ratings get squished a bit towards 1500 (at 2521 you're considered about 2200-2300). This squish is exponential so there is no "hard" limit on the difference but would take really high absolute values to produce high differences.

Ratings shown can be less than the raw value due to variance, as you wait in the queue the raw value starts being considered (so the 1352 dude could've been a, say, 1700 who hadn't played for a long time and thus had high variance).

After those effects are applied there's a limit (I don't have access to its value at the moment).
+2 / -0
12 days ago
I'm going by the ratings recorded in the startup script section of the replay file, which appears to be to the raw value:

Knowing that the transformation is exponential made it a lot easier to find relevant functions (there are only five uses of Math.pow under ZkLobbyServer):

I'm assuming that the EffectiveMmElo used by the LobbyServer is as computed in https://github.com/ZeroK-RTS/Zero-K-Infrastructure/blob/master/ZkLobbyServer/LoginChecker.cs#L220
There seem to be other functions used in ZkData, and matching behaviour might be a bit weird (but not broken) if those are used instead, since width checking does seem to assume that EffectiveMmElo is no larger than RawMmElo, which recently would no longer be the case if it's just the Ladder rating used instead.

Computing the post-squash difference, using the raw values (so when both players have been waiting for at least MmWidthGrowthTime):

>>> 1500-(1500-1352)**.97
>>> 1500+(2521-1500)**.97
>>> 2329.382695419218-1372.6045656267563

Would this be accurate?
+1 / -0
12 days ago
I suppose I should mention that I later found out the person who had been waiting on the queue with me was NorthChileanG, who is much more experienced.
+0 / -0
There's also this bit which would make the lower dude 1500, for a difference of 829.

Apparently the max width at the moment is 550 (100 baseline + 450 after 240s). There's also a cap of minimum 10% win chance (which for duels should limit the difference to about 380). Possibly those values were larger when that game happened, or maybe the WHR breakage which happened somewhere around that time affected it.
+1 / -0

9 days ago
Minimum win chance only applies to team games.
+2 / -0