This is actually a good idea in concept, but the real problem from a programming point of view is the mix of different party configurations and the imbalanced need of various jobs.
I mean if you think of it as if we're all individual people queuing, you could imagine that it just fills slots as "first-come, first-serve," with slots for each job category. In that scenario, the closer you get to the "front of the line", the sooner your number is likely to come up; in that sort of world, a "defer" option that lets others step in front of you could work. But if you're a tank or a healer, and there aren't enough of those to go around, your deferral could essentially have the same effect as a withdrawal to all the other players involved, because unless it so happens that another tank or healer shows up, they just have to wait for you anyway. So, "defer" is good for high-supply roles (since there are plenty of people in line behind you), but bad for high-demand roles (since one deferral makes a lot of people wait). (Perhaps you could make it so that the defer option is only available if there are others available who could readily fill your place.)
When you add party configurations, it can get more complex, because they don't necessarily actually get placed at the back of the line. The queue system is going to generally try to form parties as quickly as it can, so if you're a party of 6 and needs two more DPS, you may get those two DPS immediately even while there are 5 other players who were waiting for 1 healer or something. And back to the scenario above, if you're an individual queuer who defers, that still may not allow the group to move in front of you, because they may not have a gap that matches the slot you were filling.
Because of all this, there can't really have an indicator that's like "you're in position <x> out of <y> in line" (which would let you know how likely you are to be "called" soon), because it's a constant flux. The system would be constantly evaluating every single combination it can come up with given what it has to get as many people in as quickly as possible, of course prioritizing those who have been waiting the longest. (That's why you can kind of see it sometimes coming up with a combination, trying to make it work for a while, and then abandoning it to come up with a different combination.)
Anyway... it's an interesting puzzle to think about.
As was discussed in this thread before, from a system point of view, the party is the queue entity. When one person in the queue withdraws, it's exactly the same as if every single one of those members had withdrawn. So while people may not like that they share in the punishment when it's not directly their fault, from a systematic point of view, it's the equitable thing to do. It's a punishment that attempts to discourage every occurrence of match failure. (In other words, whether you consider it "fair" all depends on who you consider as the party who was most wronged: the other people in the party, or the non-party people in the queue. The system is more worried about the latter than the former, because it assumes that the people in the party have more chance of interacting with each other.)


Reply With Quote

