Update: There is now a continuation of this post here, which gets into some more detail and trickier topics.
About a year ago I did a few posts in a series I called “Theorycraft 101″. The basic point is to have post outlining basic computations/formulas I use in making spreadsheets and like, so other people who do these things don’t have to reinvent the wheel. I think there’s often not a lot of communication across classes on these things, so I want to make non class-specific references for things that come up a lot.
For reference, here are the past ones:
- Mana Regen formulas (out of date)
- Basic Regen vs. Throughput analysis (still relevant, and probably a good read for people who were interested in the recent Spirit post)
- Haste breakpoints, simple version (still valid if you use the new haste constant of 42,500.0)
- Haste breakpoints, advanced (with update) (still all correct, but EJ seems to be having a problem with its LaTeX plugin so you might not be able to read. Binkenstein has recently posted a similar explanation)
Today’s Topic: Proc Uptime
Blizzard recently posted a description of a new system for procs, used for Windsong and presumably other similar new enchants. We’re going get to the details of the new Windsong at the end. For now, some short background.
Effect that have a % chance to proc on each attack/heal have one main issue. Different classes have wildly varying amounts of combat events, so they are hard to balance cleanly. There are two main types of solutions:
1) Put a long cooldown on the proc (such as the typical 45-60 seconds found on trinkets), and make the expected proc time very low. That way even if it varies wildly (2 seconds for one class and 5 seconds for another), the actual average time between procs might 62 seconds for one person and 65 for another–close enough to avoid balance problems.
2) Use a system that scales the proc chance based on how often a class has attacks or other combat events. This is where the “PPM” (procs per minute) concept comes from–procs whose actual % chance to fire varies based on attack speed. But this is very hard do in practice since classes have so many mechanics other than autoattacks/nukes that weapon speed and/or cast time are not good estimates of how often you get a chance to proc. This is where the new system comes into play.
I’ll address each in turn below.
These are very easy to work with if you’re making a spreadsheet. Since the cooldown is dominated by a large constant (the ICD) all you have to do for a very good estimate is find that constant. This is done quickly in one of two ways:
1) Check Wowhead since someone’s probably done it already (e.g. Zen Alchemist Stone–55 seconds)
2) Go to a target dummy, use /sw to open the stopwatch, and just check the time between procs a few times. Remember, you don’t need a large data set and an average. You just need to find the minimum time to within about 5 seconds, and a few trials usually makes it clear.
Then, your uptime is simply Duration/Cooldown.
For a slightly better estimate, add a short delay to the ICD representing the time it takes to get an actual proc. You’ll need to find the proc chance (often the wowhead spell database entry for the actual buff effect will have it), and roughly estimate how often you attack.
The new system outlined in the blue post above is basically an attempt to normalize the proc rate of an ability no matter what the user’s distribution of attacks over time is.
The chance of an attack (or heal) to trigger the proc is equal to
- PPM is the buff’s built-in PPM constant.
- H is your haste factor (1 + your average haste %)
- T is the time since the last attack that gave a chance to proc.
- D (used below) will be the duration of a buff
I’ve seen people misread this. The system is not based on the time since your last actual proc (i.e. this is not a corrective effect that makes you more likely to get a proc if you haven’t had one recently). It simply takes into account, every single time you attack/heal, how long it’s been since the last time you had a combat event that gave a chance to proc.
Here’s the concept they’re getting at. You have 1 PPM proc and 0 haste. If you attacked once per second exactly, each attack would have a 1/60 chance to proc. But if your attacks are distributed irregularly over time, it does something fancier. Say one second goes by without you attacking. Then during that one second, you “bank” 1/60 chance to proc. That chance will be “used” whenever you next attack. So if another second goes by and then you attack, you’ll have 2/60 proc chance “stored” and that will be the proc chance on that hit. Basically, proc chance accrues at the correct rate with each passing moment and every time you attack, the correct chance is assigned based on how much you’ve built up since the last time.
The end result of all this? If you want a solid estimate that ignores the one little quirk of no-cooldown procs (the chance of an overlap), it’s perfectly simple, since the game accounts for all the variation already:
(I didn’t discuss above why H is there, but basically, PPM-based procs are meant to improve if your haste increases. Since otherwise, this system would completely cancel out the benefit of added haste as you attack more quickly, they build H right into the proc chance).
More Elaborate PPM: Overlaps and Poisson
Let’s say you want to elaborate a bit. The only real problem with the above estimate is that a PPM-style proc can fire twice in a row and waste part of the first buff. If the proc rate is relatively small, this won’t happen often enough to disturb the above approximation. But, since the result is pretty interesting mathmatically, and easy enough to throw into a spreadsheet if you’re making one, I’ll outline it here.
The underlying assumption here is that the new PPM system turns procs into a Poisson process. Poisson processes are events that happen at a certain average rate, with each event being independent of the last (an example is nuclear decays), and their statistics are well-understood. This is a good model for WoW procs as long as the attack rate is very high compared to the time intervals being examined (see appendix for more on this). So in the case of Resto Druids who spam out combat events constantly, it’s almost perfect, but even slow attack classes fire off a number of combat events during, for example, the 12 second duration of Windsong.
I’m not going to get into details here, just one key fact. If a Poisson process occurs, on average, (lambda) times in a certain time interval, then the chance of having it happen zero times in that interval is
(This is for all those of you who learned about e in high school trigonometry and wondered what you’d ever use it for)
But wait–that’s all we need. At any time, the chance of Windsong being up is simply one minus the chance that it has not fired in the past 12 seconds. But since we know that the mean procs per minute is PPM*H, the means procs in a 12 second interval is PPM*H*(12/60). Therefore, Poisson gives us our uptime:
Basically, in any spreadsheet or other model you’re doing for any class, as long as you know your haste, just drop in that formula for Windsong or any similar buff and you’re good to go.
P.S. Windsong itself has one unique quirk. It’s actually 3 separate procs (crit, haste, or mastery). So even though the post describes it as having PPM = 2, what you really want to model it as is 3 procs each with PPM = 2/3. This will account for the fact that each of the 3 Windsong buffs can stack with each other, but only overwrite if you re-proc the same one.
Here’s just one pretty interesting aside for the math-inclined.
Let’s say you did have a constant attack rate, or are modeling something like Flurry that lasts for a fixed number of hits rather than a fixed time. Then, your logic might be that you have the buff unless none of your past N hits procced it (with proc chance P). Therefore your uptime is
A formula that’s been used in various classes’ spreadsheets for a long time.
Let’s do something interesting. Assume that your attack speed (x) changes, but with proc chance per hit and number of hits during the relevant duration adjusted accordingly. Basically, vary the attack rate while holding constant the mean procs per second (p) and the time window of interest (t) Then we might have something that looks like
Since the proc chance per hit is px, and the number of attacks in the time window is t/x.
Now what happens if your attack rate goes to infinity (i.e. time between attacks goes to 0). Well, if you remember your calculus, you may recall that:
So rearranging very slightly and applying to the above:
But tp is the procs per second times the time window of interest, which is the expected number of procs in the time window, which is .
So, as attack rate approaches infinity, our proc uptime is:
Which is the same as what we got from the Poisson model above. Pretty nifty.