You don’t represent most pvpers or players for that matter.
Cause if you did well…we wouldn’t have to look far to see why the game is in decline.
In my opinion you just have a high opinion of yourself, in a game whose reputation and replay ability are tenuous at best compared to the modern market of games out there.
That isn’t the same thing as stacking a BG with 30+ people.
Blizzard removed the ability to queue as a raid. It’s incredibly safe to say that this type of play isn’t intended. Based on that, communities stacking a bg by queueing a bunch of 5 mans at the same time is clearly working to circumvent that.
I think the deserter buff should go up with a timer for those who just purposely leave a Battleground. I do think something should happen with that there.
I imagine what it comes down to is it would be too costly to investigate and enforce any workarounds for getting into solo queue content as a group.
Short term at least.
Long term, if a lot of people enjoy the content and 90% are getting pushed away by 10% of people exploiting solo queue in this way, then maybe it shouldn’t be considered too costly.
Why would it be too costly to have an increasing queue drop penalty past the first 3? They have it in Overwatch 2. It wouldn’t be much harder than the current penalty they have for leaving a bg.
It just isn’t something the community has forced them to do yet and they have disengaged from working on pvp too much.
I really think the costs are not in the fixes, but rather in just paying attention to this part of the game.
I assume the problem would be with people syncing their joins outside of the game in discord.
You can come up with something to combat that, but coming up with something that also wont have false positives gets a lot more difficult. And in the corporate judicial customer service world of guilty until you accept you’re guilty, you need to be really careful about false positives.
They have to drop queue multiple times when it doesn’t pop for them. So you get 6 groups of five. They say 1 2 3 queue…then 3 pop, the others don’t. They drop queue and do it again, until they get enough in. If you count the queue drops and start implementing a rising delay it breaks their system. Do it account wide, not character wide, and it solves the problem.
Most people don’ drop a queue when it pops that often so i won’t bug them but would stop the whole system to get in. It won’t be perfect, but it has a low cost, low pushback answer to massively minimize the issue. Also, you could log the info and start to make rules on it for people who keep doing it…ie anyone that gets a 24 hour ban you start watching for bad behaviour.
Sounds like most of that could help given your assumptions, but I’m pretty sure the quoted part is off the table. Any solution that requires on going hourly work is probably going to be too expensive for them.
Another thing that might help is shuffling the applications up instead of first in first out. You queue, you get held for 30 seconds to a minute, then you get shuffled into the queue with people that signed up 60 to 90 seconds prior.
That would actually work. You could still let 5 mans play together, but you could treat the 5 man group like a single player and no queue them into another player.
So you’ll need to maintain a rolling list of players you’ve been teamed with. Which probably doesn’t exist. And if WoW was one monolithic computer with global access to all data from anywhere, sure, just a couple lines of code would be possible.
But most likely it’s not one monolithic computer with omnipotent access to all data.
So you’ll need access to that data at the match making service, which may or may not be easy. You’re still on a regular shard at the point you try an join so you’re probably passing a reference to your character to that match making service that lives in some other process, most likely on some other computer, that may or may not have granular access to your character data to do this check.
And if you want to not be able to defeat this by logging off and logging back on, it will need to be part of the characters saveable record, not just your live record on the shard or your client. And changing the shape of a characters saveable record ( Database stuff ) is probably what causes the long maintenance Tuesdays.
And once that’s all solved you still need to handle what happens in the fail situation where there is someone you’ve played with recently. And also consider that a bunch of people that just finished a match might naturally all join at the same time…
So it can be done, but it’s very unlikely it would be a few lines of code. But you do have promise as a project manager.
The question is where? On your client, in an add on on your client, on the server in your character record, on the server in some other match record? At what scope, and with what persistence?