Modified FIFO (First in, first out). Here's a likely flawed, brute force, inefficient example (but the underlying logic is sound!) that would prevent logjam and large groups jumping the line:
Say 15 objects in the queue, Q1 - Q15, each with the a value from 1 - 12 (number of players in each queued object).
Begin with knowing the number of Qs in the queue, listed as Q1 - Q(x), which would be Q1 - Q15 in this case.
Start with Q1. players=Q1. If players=12 a drop is formed. If players<12 then
players=players+Q2. If players>12 or players<12, then players=players-Q2. If players=12 a drop is formed.
players=players+Q3. If players>12 or players<12, then players=players-Q3. If players=12 a drop is formed.
players=players+Q4. If players>12 or players<12, then players=players-Q4. If players=12 a drop is formed....
This cycle continues until a drop is formed from the first person in the queue and any other single Q in the queue or no drop can be formed after cycling through Q15. If no drop can be formed then
players=Q1. players=players+Q2.
If players>12 then players=players-Q2 [would proceed to Q1+Q3+Q(x) combinations unless Q1+Q3>12, and continue skipping invalid combos as needed, but I'm not going to type out all that]. If players=12 a drop is formed (not going to happen since it didn't the first time), else players=players+Q3(now Q1+Q2+Q3).
If players=12 a drop is formed, else players=players-Q3.
players=players+Q4 (which is now Q1+Q2+Q4). If players=12 a drop is formed, else players=players-Q4.
That continues trying to make a group from Q1+Q2+Q(x). If no group is formed then it would try Q1+Q3+Q(x). Then Q1+Q4+Q(x). That trend continues until it tries Q1+Q14+Q15 and can't form a drop.
Then it tries in groups of 3+1: Q1+Q2+Q3+Q4 to Q1+Q13+Q14+Q15. Then groups of 4+1, 5+1, etc. After all that it would move on to Q2 as the start instead of Q1 and do the whole thing over, then start with Q3, then Q4, etc.
Players/groups that leave the queue before drop formation have their Qs removed from consideration. Once a drop is made it reorganizes the Qs to be Q1-Q(x) sequentially, those that have joined the planetary queue are added to the next round of creating a drop, then the next round of forming a drop begins.
Not very efficient. It wouldn't perform every possible permutation because, for example, if Q1+Q2>12 then it wouldn't need to calculate Q1+Q2+Q(x), but it could still end up performing a lot of calculations if there was another Tukayyid or a large influx of CW players.
In most cases it wouldn't take long though provided there was some way to make a drop. Even 50 groups of varying sizes in a queue would find drops quickly, it just doesn't seem efficient for the server hardware. Just as inefficient but prioritizing the first players in the queue would to start by adding Q1-Q(x), e.g. Q1+Q2+Q3+Q4+Q5+Q6+Q(x), as needed before trying to make smaller groups, a variation of the first long example in reverse. Both would make the 12-player group at the end of the line wait until there was literally no other way to make a drop.
---------------------------------------------------------------------------
Alternatively, the system could do the FIFO it does now but keep in mind the pools of each drop number (groups of 1-11). If a logjam occurs it could wait 15 seconds(variable) for the drop to fill normally then simply compare pools if the drop isn't formed. It would likely start with the largest for simplicity (and because the groups make the jam), then checks other pools for a combination that forms a drop.
In the OP image it would take the 7 then check for a 5 and form a drop. If there wasn't a 5 it would check for a 4+1, then a 3+2, then a 3+1+1, then a 2+2+1, then a 2+1+1+1, then finally 5 1's. It would prioritize the first in each pool but still prioritize larger groups.
Almost 6am here so I'm expecting there to be errors in what I wrote above. If I was just rambling because I couldn't sleep: Math will help solve the problem. Apply Combinatorics.
Edited by Divine Retribution, 17 March 2016 - 06:07 AM.
0
