63 replies to this topic

[Deathlike]

yrrot, on 10 April 2018 - 05:00 PM, said:

Random thought: is QP solo building one team at a time? I've seen that mentioned somewhere by other folks here, and it doesn't make sense from an initial development of a solo drop system. It *does* however make a ton of sense if it's the product of splitting out the solo and party queues. Group queue building a 12 man team from random groups (and previously including solo players as fill), then matching two 12 mans seems like what this MM would be doing in the background--especially given legacy implementations/code.

If that's the case, then the "just swap players from one team to another for balance" isn't as simple. It doesn't leverage the legacy code, and requires new developments that likely are risky to the existing MM code.

To my understanding, that is kinda the explanation I've gotten, which totally makes no sense from a match building standpoint (the idea of building a team on one side before constructing one for the opponents - this is something PGI has said previously at one point in time - either way, this isn't really a group queue viable method). The best way to start is to attempt distributing "equal" skilled players based on criteria and split it on both sides. Trying to construct a team before "finding matches on the opponent's side" amounts to various levels of lunacy because then it can struggle to find a compatible match with someone that is actually good. It causes certain things like "unintentional team stacking" or the opposite "constructing really bad teams off the bat" which if you apply any understanding of the player skill and "guessing" which team is going to win... well, at least you'll have a gig in gambling or predictions.

Edited by Deathlike, 10 April 2018 - 06:31 PM.

[yrrot]

It makes more sense in the context of the MM used in Beta. Making a valid team with weight class balance out of valid, variously-sized parties works better than trying to do those things after grabbing 24 players. As in, it's the only way to enforce those rules without making lobbies of 24 get stuck in a no-go situation.

In the old Elo system, they could then matchmake the complete team to the closest total skill team available and use the difference for adjusting Elo ranks after the game. It just makes sense to do it that way for the old implementation.

The current solo and group queue using that style of matchmaking then is in line, I guess, with what was already there.

From PGI's perspective, it's got to be a risk/reward decision. The time and energy to put programming resources into basically rewriting the MM from ground up with different assumptions (balancing after matching, etc) vs the benefits to match quality. I'm wondering if the rate of stomps was comparable in the Elo system, even with the higher search times. If it is, then it's pretty much "Eh, this is a close enough approximation of the more complicated system".

[Nightbird]

Deathlike, on 10 April 2018 - 06:25 PM, said:

This would've been something that should've implemented or discussed thoroughly when PGI was messing with the MM. At this point the skill needed to accomplish that is closer to Lostech (the last known decent programmer they had in Karl left for Amazon after all).

The programming part is easy actually. They can dump the data they have to me, whatever they have is fine. PGI already has stats like kills, average match score, bunch of other stuff. I run my statistical model on my own system, and crunch out a formula like (Pilot Battle Value = A*KDR + B*AvgMatchScore + C*whatever + ...). All they'd need is the coding skill to crunch out the number, kids stuff. The modelling stuff that calculates A, B, C, etc I can do easily with my software but would be impossibly expensive to build from scratch.

Deathlike, on 10 April 2018 - 06:29 PM, said:

To my understanding, that is kinda the explanation I've gotten, which totally makes no sense from a match building standpoint (the idea of building a team on one side before constructing one for the opponents - this is something PGI has said previously at one point in time - either way, this isn't really a group queue viable method). The best way to start is to attempt distributing "equal" skilled players based on criteria and split it on both sides.

PGI doesn't have a formula to assign skill correctly anyways. It doesn't matter if they build 1 team at a time or 2 teams at once.

[Zergling]

yrrot, on 10 April 2018 - 05:32 PM, said:

As for the WLR discussion: while it is true that a large sample set should mitigate the randomly bad teammates from dragging down one's personal WLR more than anyone else's, how large of a set is that? I'm not a statistics expert, but the law of large numbers isn't talking about ~1000, it's talking about 100's of 1000's.

Once the odds of a player's W/L being due to random chance becomes ridiculous (like odds of it occuring in the '1 in millions, billions, trillions or greater' range), it is safe to say the sample size is large enough.

Eg, if Win/Loss result is a 50/50 coin toss, then odds of at least 60 wins in 100 battles (1.50 W/L) is 1 in 92.
That could certainly occur with a large number of players, so it is safe to say that isn't a large enough sample.

Increase that to at least 600 wins in 1000 battles (still 1.50 W/L) though,and odds drop to 1 in 21.58 billion.
Those odds are so low, it is safe to say that random luck is not having an influence anymore.

yrrot, on 10 April 2018 - 05:32 PM, said:

Basically, larger groups of players inherently have better organization and teamwork, and often higher average skill. Grouping up as such, inflates WLR because their combined advantage will outweigh the skill of most of the other groups they match against. Even well organized mediocrity can overcome a few higher skilled players and mop up the rest, essentially. Since there seems to be a lot of semi-casual, small groups in queue, I think larger teams might often run into less organized groups more often than they run into other large, organized groups. Since we can't split out group play from the WLR, it loses some clarity.

Which is why W/L is only really used on its own for comparison between known solo queue players, or between different group queue teams.