Why RPPM trinkets feel too... random, and an alternate design proposition.

[Deleted]

More details on the changes :
http://us.battle.net/wow/en/forum/topic/8197741003

[Hellfury]

Breath of Hydra is still shit out of 20 pulls Iam doing now on HC boss, got 2 procs at start.

And as demo if it doesnt proc at start my damage automatically becomes shit, getting very frustrated.

[Surutcra]

Yep, saw that today. This fits into the model I've designed so the math will be straightforward to do (expect results tonight, ~6PM PST).


Copy/Paste from my post on the EU official forums as a response to this (I really hope they read this one) :

I welcome the change because it is obviously an improvement over the current RPPM system !

However I am a bit disappointed because there are still a few important issues with it that I believe could have been easily avoided :

[ul]
[li]The time-between-procs probability distribution will still have high variance (this change only dampens the long tail of the distribution, it does not remove the relatively high chance to proc right away)[/li][li]Unless you're adding some normalization constant you did not mention in the equation, the average time-between-procs is not 60s / (RPPM_rate * (1 + haste)) anymore. This also makes it unclear what you mean by "AverageProcInterval" in your formula ![/li][li]The 1000s cap seems excessive, this means if you really want to maximize your chances of proccing your trinket right away at pull you need to wait for ~17 minutes ! If you want to keep that high a cap, I would advise to cap the TimeSinceLastSuccessfulProc when entering combat, i.e. do TimeSinceLastSuccessfulProc = max(TimeSinceLastSuccessfulProc, T) where T is a reasonable value (less than 3-5 minutes at least). However 0.5 RPPM trinkets will not proc right away at pull for sure even if you wait long then ![/li][/ul]

I had investigated the issue myslef and came up with another solution very close to this one, except it does remove the high chance of immediate proc, resulting in a somewhat centered gaussian-ish probability distribution for the time-between-procs.
It is basically done by making the instant probability a ramp (this new system is constant then ramp) :
P = TimeSinceLastSuccessfulProc * TimeSinceYourLastChanceToProc * Constant
With a normalization constant ensuring that the average time-between-procs is 60 / (RPPM_rate * (1 + haste))

I cannot post images but I will link to a few probability distributions once I get the math done about this !

I cannot post on the US forums, but I really hope some of the guys on teh development team that worked on this system will read this and maybe even respond / address these concerns !

[Nitwit]

The 1000s cap seems excessive, this means if you really want to maximize your chances of proccing your trinket right away at pull you need to wait for ~17 minutes !

Shouldn't be a concern. Assuming you're not chain-pulling (i.e. 1-2+ minute between pulls) The chance to proc an rppm trinket at the start of an encounter should be just as high as standard ICD/proc chance trinkets (if not higher), and the chance to proc will continue to climb until you get your first proc.

[Hellfury]

Shouldn't be a concern. Assuming you're not chain-pulling (i.e. 1-2+ minute between pulls) The chance to proc an rppm trinket at the start of an encounter should be just as high as standard ICD/proc chance trinkets (if not higher), and the chance to proc will continue to climb until you get your first proc.

it is, do you even have one to say that, because iam getting 2-3 mins between pulls and still barely procs at start

[rezoacken]

According to the post linked by Zumzum they now use the same formula as before but multiplied by this:

Max(1,1+((TimeSinceLastSuccessfulProc/AverageProcInterval)-1.5)*3))

You can put this in Excel and see that this becomes negative when (TimeSinceLastSuccessfulProc/AverageProcInterval) is too low. That's why they added a MAX function so that it takes 1 everytime the right side is below 1.

To be honest, this is a band-aid hotfix. Here's why:

-First the 1.5 factor and 3 have no statistical meaning. 1.5 just mean that this new factor does nothing until you go beyond 150% of AverageProcInterval. There's no justification for this 50%. Nor for the slope of 3. Pongueur's constant A from his formula is so that the Expected average remains the same as before. Something Blizzard doesn't even bother with.

-Secondly, the basic chance (pre-150%) is the same as before BUT with a better chance post-150%. This mean a 1RPPM trinket, is no longer a 1RPPM trinket. The expected value of the time until next interval will be below AverageProcInterval. And the number of proc will be higher on average.

-This reduce the right tail of P(t+dt>T>t)/dt the density but still does not center it. I didnt do the maths but the time is probably now bimodal (2 local maximums). I'll verify. Which is just.... weird. This will shift the probability function for the number of procs to the right (better average) and reduce the variance a little (this is good).


I'm still convinced the OP idea is a more elegant way of doing it. This is a band aid fix, it removes the right tail of the density for T but it gives it a lower average, 1RPPM has no meaning. Also it must be noted that since they added TimeSinceLastSuccessfulProc in their function, there is no computational reason why they would not be able to do what OP suggest.

[Surutcra]

Shouldn't be a concern. Assuming you're not chain-pulling (i.e. 1-2+ minute between pulls) The chance to proc an rppm trinket at the start of an encounter should be just as high as standard ICD/proc chance trinkets (if not higher), and the chance to proc will continue to climb until you get your first proc.

That's not exactly true. Take a 0.5 RPPM trinket and say, 20% haste. (0.6 RPPM with haste). Then the AverageProcInterval is 100s, which means you start getting a bonus chance at 150s.
So, depending on the time you wait before the pull :
- < 2 min 30 s : usual chance.
- 3 min (180s) : 1.9x usual chance.
- 4 min (240s) : 3.7x usual chance.
- 5 min (300s) : 5.5x usual chance.

Edit : And everyone knows the "usual chance" is pretty low for such a trinket !

[rezoacken]

Will you remake an analysis with this added multiplier ?

[Surutcra]

Will you remake an analysis with this added multiplier ?

Here you go !



Results for the new RPPM system

Important results :
After this change...
- RPPM effects will proc 13% more on average (at constant base RPPM rate R).
- the time between procs T will be 20% less random (in terms of relative standard deviation).
- Trinkets are guaranteed to proc on pull, provided they did not proc for a sufficient time.
- Very unlucky streaks will be way less likely, but lucky streaks remain just as likely.



To visualize the change, here is a graph of the proc chance per unit of time for the three systems : old RPPM (blue), new RPPM (red), Smoothed RPPM (green) :


You can see that the proc chance is very similar to the old one, it only differs after 1.5 minutes (with 1 RPPM), at which points it turns from a constant to a ramp.



And now with the analysis, we have :
dP = h(t) * dt

With :
h(t) = max(1, 1 + (C*t - 1.5) * 3) * C
h(t) = C + 3C² * max(0, t - t0)

<=> h(t) :

for 0 < t < t0 : h(t) = C
for t0 < t : h(t) = C + 3C² * (t - t0)

Constants [Here, t0 is the time when the chance to proc starts increasing] :

C = R*H/60
t0 = 1.5/C
C*t0 = 1.5

Let's compute the probability density f(t) for T (time between procs) :

with g(t) = P[T > t], similarly the smoothed RPPM case :
(log g)'(t) = - h(t)

We define H(t) the integral of h(t) that takes value 0 when t=0 :
H(t) = C*t + 3C²/2 * (t - t0) * max(0, t - t0)
<=> H(t) :
for 0 < t < t0 : H(t) = C*t
for t0 < t : H(t) =  C*t + 3C² * (t - t0)² / 2 = C*t + 3C² * (t - t0)² / 2
We then have g(t) = exp(- H(t))
and the probability distribution f(t) = - g'(t) = H'(t) * exp(-H(t)) = h(t) * exp(- H(t))

.
f(t) = h(t) * exp(- H(t))

With H(t) :

for 0 < t < t0 : H(t) = C*t
for t0 < t : H(t) = C*t + 3C² * (t - t0)² / 2

We can compute the average time between procs :

E[T] = Integral(0, infinity)[t*f(t)*dt]
E[T] = Integral(0, infinity)[t * h(t) * exp(- H(t)) * dt]
E[T] = ValueBetween(0, infinity)[-t * exp(- H(t))] - Integral(0, infinity)[- exp(- H(t)) * dt]
E[T] = 0 + Integral(0, infinity)[exp(- H(t)) * dt]
E[T] = Integral(0, t0)[exp(- C*t) dt] + Integral(t0, infinity)[exp(- C*t - 3C² * (t - t0)² / 2) dt]
E[T] = I_1 + I_2

I_1 = ValueBetween(0, t0)[- exp(-C*t) / C]
I_1 = 1/C * (1 - exp(-C*t0))

For I_2, variable change u = t-t0
I_2 = exp(-C*t0) * Integral(0, infinity)[exp(-C*u - 3C²*u²/2) * du]
This integral is a bit complicated to calculate, so I will trust this website with the result :
I_2 = exp(-C*t0) * sqrt(Pi/6) * 1/C * exp(1/6) * ValueBetween(0, infinity)[erf((3*C*t+1) / sqrt(6))]
Where erf is the error function

Finally :
E[T] = 1/C * { 1 - exp(-C*t0) * [ 1 - sqrt(Pi/6) * exp(1/6) * ( 1 - erf(1/sqrt(6)) ) ] }
E[T] ~= 1/C * [1 - 0.5181 * exp(-C*t0)]
E[T] ~= 0.8844 * 1/C

Results confirmed by numerical testing !

.
==> E[T] ~= 0.8844 * 1/C
With the classic RPPM system, 1/C was the average.


Conclusion : This change to the system will make the trinkets proc 13.07% more frequently than their announced RPPM rate would suggest.


Probability density of T (time between procs) for the three systems : old RPPM (blue) vs. new RPPM (red) vs. Smoothed RPPM (green) :



This further indicates that this change only affects the tail end of the distribution. In addition, I concur with rezoacken that having the probability density of T reach a local minimum then rising again does feel clunky !




And now let's compute the variance / standard deviation / relative standard deviation :

E[T²] = Integral(0, infinity)[t² * h(t) * exp(-H(t)) * dt]
E[T²] = ValueBetween(0, infinity)[- t² * exp(-H(t)) * dt] + Integral(0, infinity)[2t exp(-H(t)) * dt]
E[T²] = 0 + Integral(0, t0)[2t exp(-C*t) dt] + Integral(t0, infinity)[2t exp(-Ct - 3C² (t - t0)² / 2) dt]
E[T²] = I_1 + I_2

Using wolfram :
I_1 = 1/C² * 2 * (1 - exp(-C*t0) * (1 + C*t0))
I_1 ~= 0.8843 * 1/C²

For I_2, variable change t' = t - t0 :
I_2 = exp(-C*t0) * { Integral(0, infinity)[2*t0*exp(- Ct' - 3C²t'²/2) dt'] + Integral(0, infinity)[2*t'*exp(- Ct' - 3C²t'²/2) dt'] }
I_2 = exp(-C*t0) * { I_3 + I_4 }

Using wolfram :
I_3 = 1/C * exp(1/6) * sqrt(2*Pi/3) * t0 * ValueBetween(0, infinity)[erf((3C*t + 1)/sqrt(6)]
I_3 = 1/C² * exp(1/6) * sqrt(2*Pi/3) * C*t0 * (1 - erf(1/sqrt(6)))
exp(-C*t0) * I_3 ~= 0.3226 * 1/C²

Using wolfram :
I_4 = - 1/C² * exp(1/6) * sqrt(6*Pi)/9 * ValueBetween(0, infinity)[erf((3C*t + 1)/sqrt(6)] + 6/9 * 1/C² * ValueBetween(0, infinity)[exp(-C*t*(3*C*t+2)/2)]
I_4 = - 1/C² * exp(1/6) * sqrt(6*Pi)/9 * (1 - erf(1/sqrt(6))) + (6/9) * 1/C² 
exp(-C*t0) * I_4 ~= 0.0771 * 1/C²

So that :
E[T²] ~= 1.2840 * 1/C²
Var[T] = E[T²] - E[T]² ~= 0.5018 * 1/C²
Std_dev[T] ~= 0.7084 * 1/C
Rel_std_dev[T] ~= 0.8010

Results confirmed by numerical testing (finally) !

.
Var[T] ~= 0.5018 * 1/C²
Std_dev[T] ~= 0.7084 * 1/C
Rel_std_dev[T] ~= 0.8010

Which is clearly not as good as the smoothed RPPM system (Rel_std_dev[T] = ~0.523), but still a decent drop in relative standard deviation from the previous system (Rel_std_dev[T] = 1).



I believe the results to be accurate and I cross-checked them everytime I could (with numerical calculations & simulations). However, given the complexity of the integrals involved, it's totally possible I made some mistakes. Please point out anything that looks suspicious to you.

[rezoacken]

Looks like I was right and that it is just weird now. They just patched another density to the old one making for a very clunky system.

[Surutcra]

Yes, however it is also a clear-cut 13% buff to the procrate of all effects (unless they made additional undocumented changes like an additional normalization constant, or if the ExpectedTimeBetweenProcs is not 60/(R*H) but something else)

This in cunjunction with the 5% buff to the base RPPM rates of Int trinkets makes them more attractive, though no better from a gameplay perspective.

[Eizwakh]

If I have understood the RPPM model right, the proc chance on trinkets is now a random event with no ICD and has a streakbreaking functionality built in.

I extend this to mean that at a certain point of time, your chance to proc <trinket> is x% and if you dont, the next instant it improves to (x+dx)%.

But since the chance to proc is an independent and identically distributed R.V. across events at that given instant, having more events happening for you at a given instant would give you more shots at procc'ing that trinket at that instant.

Theoretical example:

Elemental shaman with Flame Shock up on single target - 1 tick every 2 seconds, and casting a spell every second (rather far-fetched and radical, but lets bake in overload and all the jazz). So every 2 seconds, the shaman has 4 events going.

Affliction Warlock - UA + Agony + Corruption + Malefic Grasp - 3 DoTs ticking every 2 seconds and Malefic Grasp ticking every second - plus it causing every DoT to echo every 2 seconds - so the number of events = {3(DoTs)*2(1:real+1:malefic echo)} + 2(malefic) = 8 events going over 2 seconds.

If each event has a probability x (<=1) of triggering a proc, at instant t, then the shaman has 2x probability of triggering it while the warlock has 4x probability of triggering it (normalized to a second).

This means the shaman has a higher chance to fail and hit instant t+dt where he'll have a 2(x+dx) chance of trigger it. But remember, on relatively lesser chance of the lock failing, he'll have a 4(x+dx) chance of triggering the proc.

So, by induction, the lock has a faster streakbreak than the shaman and also a higher flat out spot probability of triggering a proc.

If this is so, is this intended? Why the imbalance?

If it is not so, please point out where my reasoning is wrong (with blue post backing please).

[Surutcra]

If each event has a probability x (<=1) of triggering a proc

This is the error in your reasoning. With the RPPM system, if you attack twice faster (like in your example), each attack has half the chance of triggering the effect, because the proc chance is proportional to (currentTime -timeOfLastChanceAtAProc). You can check (or trust me that) for relatively high frequencies of attack, this results in the same proc chance per unit of time in both cases.


From ICD to RPPM, long story short :
- Old trinkets used to work this way (each candidate event has constant chance of actually triggering the effect).
- The problem being as you pointed out that classes that have a higher frequency of candidate events will trigger the effect more often.
- To balance this out, the concept of ICD was introduced, and the proc chance can be relatively high (say > 15%) because however quickly you attack, you can't get more than one proc every ICD seconds.
- However, with high proc chance and an uptime controlled mainly through ICD, the proc get less and less random. In fact you can be so precise in predicting when you will get procs that you can start planing around them, instead of reacting to them.
- This is the issue that pushed the developers into the idea of the RPPM system, that can deliver actually random (i.e. unpredictable) procs with no dependency on the attack frequency.
- The problem of this system is that it can be... too random. When the expected total number of procs on the course of a whole fight gets relatively low (and trinket effects are usually powerful enough that they cannot happen 20 times in a fight and still be balanced), two extreme situations arise. You can get very lucky and proc twice or three times in a row, because there is no ICD preventing you from doing so. Or you can get very unlucky and not proc at all over very long periods of time, because the proc chance per second is pretty low.
- Players quickly got frustrated about two things. One being the terribly unlucky streaks, the second being trinkets not proccing quickly after the pull like ICD ones used to.
- The developpers chose to address these by introducing a "bad streak protection", which basically greatly decreases the odds of very unlucky situations.
- However the RPPM mechanic remains very random overall, to the point that it can still have huge impact on your individual performance (you can easily check on simcraft that DPS variances have jumped by 50 to 100% across the board because of the introduction of RPPM trinkets).
- I still feel that the system is a bit too random and should be modified to reduce the chance of lucky streaks (right after a proc, it's actually more likely that your next trinket proc will happen between now and the next second than between the 60th and 61st seconds, does that seem right ?).
- I feel like I have proposed a solid option in this thread, but the future mainly lies in the hands of players : if everyone is fine with high randomness and there are no complaints about it, then things will remain the way they are (and they aren't that bad either, to be totally honest).

[Deleted]

I think the increased chance at the start of the fight should be pushed further and ensure an automatic proc at the pull, because there is still 1 pull in 5 (or 10) where they just don't proc at all and you are pretty much ****ed.

- However, with high proc chance and an uptime controlled mainly through ICD, the proc get less and less random. In fact you can be so precise in predicting when you will get procs that you can start planing around them, instead of reacting to them.

Was that really a problem ? :/ It promoted good play more than today imo (but I think this debate already took place on these forums )

[Teye]

Not sure if anyone brought this up yet, but imo the major flaw with RPPM is that it increases everyone Haste weight by so much. Its really obnoxious to have multiple specs start stacking haste right when they got RPPM trinkets.

---------- Post added 2013-04-29 at 12:34 PM ----------

Breath of Hydra is still shit out of 20 pulls Iam doing now on HC boss, got 2 procs at start.

And as demo if it doesnt proc at start my damage automatically becomes shit, getting very frustrated.

How high is your Haste? It honestly sounds like you don't have nearly enough; At 12k mine procs 100% on the pull.

[Brusalk]

Not sure if anyone brought this up yet, but imo the major flaw with RPPM is that it increases everyone Haste weight by so much. Its really obnoxious to have multiple specs start stacking haste right when they got RPPM trinkets.

---------- Post added 2013-04-29 at 12:34 PM ----------



How high is your Haste? It honestly sounds like you don't have nearly enough; At 12k mine procs 100% on the pull.

I hate RPPM with every fiber of my being.

It promotes sloppy play and discourages smart play by not being able to plan around procs.

[Teye]

I hate RPPM with every fiber of my being.

It promotes sloppy play and discourages smart play by not being able to plan around procs.

Was that really a problem ? :/ It promoted good play more than today imo (but I think this debate already took place on these forums )

I agree with both of you, wholeheartedly. The old system required planning, the new system is just mashing buttons in reaction to your Weak Auras popping up.

[Surutcra]

I think the increased chance at the start of the fight should be pushed further and ensure an automatic proc at the pull, because there is still 1 pull in 5 (or 10) where they just don't proc at all and you are pretty much ****ed.

- However, with high proc chance and an uptime controlled mainly through ICD, the proc get less and less random. In fact you can be so precise in predicting when you will get procs that you can start planing around them, instead of reacting to them.

Was that really a problem ? :/ It promoted good play more than today imo (but I think this debate already took place on these forums )

I totally agree with you on the first point, whatever system they choose, you should get a guaranteed proc at pull provided you waited about the expected time between procs (and not 2-3 times that duration as it is today).

As to the "planning vs. reacting", it's ultimately a matter of personal preference, and we obviously differ on that point ;-)

The only "argument" I can formulate is in favor of my preference is that the game feels boring without meaningful random elements messing up with your gameplay, because you can and should do the same thing over and over again, try after try.

However I do feel that the current system is too random, resulting in a bit frustrating experience that your performance can vary a lot from attempt to attemp, not because you got procs at different times or used them more or less efficiently, but simply because you got a very different amount of procs.

[Deleted]

There is just too much RNG in this game at the moment. For example when we progress Lei-Shen heroics: If i don't get Lei-Shen trinket proc at the opening my DPS will be 150-170k instead of 210-230k before the first intermission. Now it doesn't matter too much if this only happens to me(or any other lock). But if this happens to few locks and some other random dps guy, we won't get to intermission phase in time and we can wipe. Well, we can always use bloodlust at the beginning to guarantee to get the boss to 65% in time, but it's just so stupid to have to use lust because of one trinket not proccing in the opener for few players.

And affliction warlock is now propably most RNG spec in game. It's just so huge difference if you have metagem+2 trinkets proccing same time with Dark Soul(+lust+berserking+any boss mechanic like Primal Nutriment/Fluidity)

[ati87]

I like the new system, having a proc every 45 secs was boring and not really effected my gameplay.

I do however dislike that I sometimes get a new proc (my hydra trinket and enchants) before the old one has fully expired