Whether there's a personal pool, server pool, vast ocean or whatever, let's consider this:
The system can not make loot unless activity occurs.
Therefore, loot is based strictly on our activity.
If we accept that the system wants to give a roughly 90-95% back long-term (amounts vary and I'm not gonna debate the exact %)
Then, if there's a backlog of tt return that's not been given yet
and there's some trigger that tells the system to dump the available contents to reach proper return yield
A big payout (mega-uber, ATH, etc.) occurs in proportion to the amount of reserves, which as I laid out above, is based strictly on the quantity of activity the player(s) do.
So more low-return activity = more built up for large payout. But whether it goes to the person who lost it or some rando is under debate.
At this point, the reserves are dry and the random loot math may be more likely (but not guaranteed to) score lower to build it back up for the next time.
At least, that's how I might make a loot system designed for 1 or multiple players on 1 or multiple servers where specific activity and output is unknown before hand.
I think this only counts for the highest multiplier (or one of the multipliers).
There is no need to do this with all mutlipliers since the number of multiplied loots is in direct correlation with amount of loot events which is direct correlation with the amount of activity. Less activity means less multiplied loots.
You just need a system that works on any scale and has a buffer variable.
So, while it is very plausible that there is such a "back log multiplier", I believe there are at least 2 or 3 multipliers that are based upon other conditions.
(time, place,...)
Now, I believe that the chance that someone gets a multiplier or combination of multipliers is dependent on that avatars history of getting multipliers.
Taking what
@WoenK said in consideration it might be that a multiplier is not anymore guarantied but a chance to get an extra multiplier exists.
A loot event could be seen as a sequence like this:
- Base loot (0.25-2.5x cost)
If multiplier then grand a chance on a mini (2-10x) --> trigger/wave multiplier
- if historic multiplier return is low then add multiplier 25-250x --> fairness multiplier
- if "lootpool" is plenty then a chance on another multiplier 40x --> lootpool multiplier (lootpool for each profession?)
Above might be a simplification or not. Basically for most loot events the system doesn't do much. And when the conditions are met for a mini, then it checks your chance to get more.
If the "loot server" lags, you can't repair or drill a claim without lag because each action causes a decay that is calculated and stored. I think if a user session ends that session variable (or variables) might be written and stored, similarly how your latitude and longitude are stored. (note that height isn't stored, that's how we used to make people towers that climbed into the sky be relogging.)
Since everything happens in the player session of the server (much like how every user in a php website has it's own session), it is not only easy to achieve this; it is very likely.
@JohnCapital That's how I would implement things