We all know more people want to play DPS than tank.
If you want to play DPS in a 2-2-2 comp there are really only two solutions:
Be willing to play some games on other roles.
Wait for tanks to become available, effectively tanks play 2 games so that you can play 1.
A different solution would be to merge all the queues together, so that there is only one queue. You still have separate SR’s but there is only one queue.
You can still selecting your preference for role: #1 - DPS #2 - Support #3 - Tank
However the matchmaker only guarantees DPS players will get the #1 choice about 50% of the time (this guarantee should be possible given the current 6:1 ratio of priority pass).
The matchmaker could also guarantee you get your #1 choice if you are in a group of 3 or more players and you are the only person to pick that roles as the #1 choice in your group (obviously for full 6-stacks it would be 2 per role).
The final piece of the puzzle would be that if players are throwing games in roles they don’t want to play the MM would only put those players in their preferred choice - however the queue times for “throwers” would get longer since they are no longer balancing the queue times for everyone else.
Noticed this first. Don’t you mean the other way around?
Edit: Damn you, you caught it and edited it before I could even finish my response.
I had an idea that’s pretty close to this and think would be a great way to rework the queue as a whole.
The issue right now is that when you select more than one role, you functionally know which role you’ll get based on what has the shortest time to wait, usually tank. For example, I could queue for support and tank right now but 9 times out of 10? I’m still getting rank if that’s the most in demand one, no matter if I showed that my willingness to play both roles is equal.
It doesn’t allow for people to really queue for multiple roles and show a preference of one over the others at the same time.
My proposal would be kinda an in between of the current system and your system.
You still pick the roles you want to play (that way people that either only want to play one or don’t like one of the roles can show that) but instead of just ordering them in terms of preference, you also put how long you’re willing to wait.
For example, let’s say I want to play damage the most, then support, then tank (mostly in order to go in the order of most to least popular and to make it most likely I don’t get my first two choices). I can order my choices in that way and then I set time intervals. It would start with just queuing me for damage and then I could say “if I am waiting for more than 5-10 minutes, add support to my pool”, if I’m waiting after my next time interval? (Say another 15 minutes). Then I can tell them to also add tank.
This way players who are willing to play all three roles can pick more than one at a time without just getting the least in demand one because “fast queues”. They could pick any role they want to play but also be putting them in order of desire and putting the threshold of time they’re willing to wait for each or realistically the wait time at which getting a game matters more to the player than getting a specific role. That time interval would be different for every player as well as the level of desire for one role over the others.
Not only do I see the issues that robot wizard point out for this part but how does the matchmaker determine if someone was throwing on an off role? Did they lose a bunch? Doesn’t necessarily mean they’re throwing. Bad stats? Doesn’t necessarily mean they’re throwing. If it’s by player reports then the throwers will and should just be banned/suspended instead of just saying “here’s what you wanted.”
Just let the people who specifically want to play a role pick it but know they’ll be waiting a while.
With respect to detection of throwers, it would be a combination of:
In game stats
W/L ratio
Endorsements
Reports
…
It’s advantageous not to define the exact mechanism, because we don’t want people to know how to “Game the system”.
But I do have one other “dirty secret” which is that there are actually two options for the matchmaker:
They could be punished by giving them a slow DPS queue.
Or there is some slack in the system, so that throwers could actually be rewarded - by giving them a “fast” DPS only queue.
Note: The “fast” queue is actually just normal speed, locked to only select DPS.
I know everyone here will be like:
You’re insane why would you reward throwers…
But it’s for the overall good of the system specifically, both solutions prevent them throwing in the tank queue.
In short for “soft” throwers we could detect them and get them out of the way with the fast queue, but for particularly bad throwers, they get the slow queue.
I will also acknowledge there is nothing I can do for very high SR players.
Simply put there are to few people playing tank at the GM level, so there is no-one to incentive at that level - their DPS queues will be slow no matter what.
I’ll post the same alternative solutions I cried for a year ago:
They could have soft-locked things in-match. Stuff like “too many snipers” “too many shields” “too many builders” in “role-queue” if you’re the last to pick. And if there is negative feedback, you tune those restricts patch-on-patch instead of hero bans or any other kind of lockdown.
Or a kind of “at most 3 of 1role” rule: so 303 and 141 or 402 would be blocked, but 312, 132, 213 etc would be allowed.
We know why they did handcuffs, and it was wrong. It was so fundamentally against what fps gamers and gaming stand for, but then again so are rigged no-reset ladders. OWL is ded and game is ded now - but at least there is OQ. We run a lot of 132 and 141 here and it’s great.
That is 100% against the creed of every professional systems designer ever. Anyone worth a SoCal paycheck takes ownership of their product/service. The end-user is never at fault. You design for all/worst-case inputs. Systems 101.
Framing the problem, scope, requirements, and bounding your i/o are the type of questions a junior systems engineer would ask on day1, or in an interview. Putting your hands up in the air and saying “it’s the user’s fault” sends you straight to the parking lot “good luck in your job hunt”.
But these eventualities are well-defined. Meaning we don’t ever validate all of them, only the worst-case combinations. There is a finite set of actions a user (or set of users) can take. In this context, we’re talking about queues and SR changes. You accept/reject some numerical amount of abuse when you design the system.