It’s a conundrum to be sure.
Setting a minimum queue period which was too long would feel like an unfair and unnecessary inconvenience – too short and you’re not guaranteed to get enough players in the queue to properly separate out the players attempting to form a premade group.
But ultimately a cross server premade is still just a glorified pug. You can do a lot less to control a composition from that standpoint.
I guess I imagined it like a pool of players, each attributed with a number which represented their place in queue. The game isn’t going to generate an instance immidiately even though it has 10 players – it might wait until it has a randomly generated number of players in queue which is odd like… 27 or uh… 32, and then randomize the order and initiate instance invitations for a range of numbers which corresponds to the # of players required to fill the maximum # of instances that can possibly be filled with the # of players the initiation variable could potentially fill; leaving what remainder might exist in the player pool and mark any player who was in the initial pool with a modifier which guarantees his/her order variables will fall within the randomly generated selection range the algorithm intends to use for the next phase of invitations.
(as to eliminate the chance they miss multiple invitation phases in a row)
So if the new instance initiation variable is… uh… 19, the players who missed the first set of invitations’ queue order variable will fall within the range of whatever numbers between 1 and 19 that the queue intends to use to generate invitations for the 1 instance it can create with 19 players at the point in time during which 19 players are finally waiting in queue.
19 seems somewhat low in my opinion, given that players could hypothetically be queuing with many more than that – 19 was simply an example.
You’d have to set the invitation initiation variable to be within certain parameters based on the number of average players who queue, over what would seem like a reasonable period of time, to fill the pool – like an average, + or - a range which seemed reasonable enough for randomization.
If people did ultimately successfully fill premades using a dynamic system such as this, the average range of the pool would adjust itself to make it significantly more difficult over the course of multiple attempts, and then reduce as that pressure subsided (after people became aware that their attempts to premade had been largely unsuccessful); such as to require less players joining the queue pool prior to initiating instance invitations.
So long as the system wasn’t widely abused for that purpose, it would have very little effect on queue times at all.
Maybe it’s just filling 1 instance at a time, but holding a pool of players back for a period of 1-3 minutes or so, and maintaining a certain number of players as seems reasonable by an average measurement of time.
So it’s got 60 people waiting for an instance, it’s going to randomly generate 10 numbers between 1 and 60 and raise those who were not chosen to priority 2 and re-order them. It waits until it’s got a certain # of additional players to add to the queue in order to maintain a large enough queue (which it determines according to the average rate of players queuing per minute)
You could add an extra probability variable for higher priority players every time a wave went out so you’re assigning players with “priority 2” 2 numbers. and priority 3, 3 numbers. players with prio 4 have 4 numbers. eventually those guys are gonna get picked.
there’s 54 people in queue boom, choosing 10 numbers between 1-54, modified by the probability of player priority, checks conditionals.
Did more than 3 players from a single server get chosen? yes? this player had higher priority, throw this one back, generate a different random number… etc.
Raise those unchosen to priority +1, add a number to the range in their honor, upon reordering them, etc.
idk… Sounds complicated. The first way sounds more realistic but also more easily exploitable. It ultimately depends on the rate players are queuing up for battlegrounds over time, and how we define a reasonable queue period, given that there’s technically enough players to make an instance right then and there.
It’s entirely possible that instances will be able to be created at the same rate, only the system has to be pre-loaded with a player pool. So people will only really experience delays just subsequent to a server reset or something of that nature – when the queue is legitimately empty of players.