Note that I’m not going to go through the derivation step by step here.  I’m just going to list the equations we need, and then analyze them.  If you want to know where a particular expression comes from, you’ll have to slog through reading parts 1-4.

Required Equations from Part 1:

In part 1, we built up the normalized scale factors :

where , , , , , , and are the factors that convert rating to percentage for armor , hit, haste, crit, mastery (in this case, rating->mastery), parry, and dodge, respectively.  is the armor mitigation factor,

,

where is a constant that depends on player and target level, and is the player’s armor.  is the avoidance mitigation factor,

,

where is the player’s total (post-DR) avoidance.  is the block mitigation factor:

,

where is the probability that an unavoided attack becomes a guaranteed block, is the critical block chance as determined from mastery,  is the player’s total block chance, and is the player’s block value (30%).  has the form,

,

where we’ve implicitly defined the Shield Block buff duration and the Shield Block cast rate , which will be defined later on in the rage generation section.

We also have the factor , which represents the avoidance mitigation factor’s scaling with dodge and parry:

with being the player’s post-DR dodge from sources subject to DR, and and being the avoidance diminishing returns coefficients.  We’ve assumed here that dodge and parry are properly balanced.  And we have the factors , which represent the scaling of the block factor with respect to different stats:

where we’ve incorporated definitions from the differential block factor equation:

as well as factors from the equation for :

and the factor representing diminishing returns on block:

where is the mastery-to-block-chance conversion factor (1.5%) is the player’s post-DR block chance due to mastery (i.e. the part that’s subject to DR), and and are the diminishing returns coefficients for blocking.

We’ve also used , which is the mastery-to-crit-block conversion factor (1.5%).

In the expressions for we’ve defined some factors which represent the scaling of the SB cast rate with different stats.  These will be defined in the “Part 3″ section.

Required Equations from Part 2

In part 2, we modeled the rotation.  We defined and , the melee and spell hit factors:

And used a stochastic matrix method to determine the steady-state probability factors:

We then determined the cast rates for different abilities:

And we defined some differential cast rate factors :

.

We then went on to calculate the effects of parry-haste, giving us definitions for the auto-attack rate:

in terms of the incoming attack rate , and two more definitions that represent haste and parry-haste scaling of auto-attacks:

Required Equations from Part 3

The shield block cast rate is found from the rage generation equation (link):

,

where is the enrage buff uptime, is the player’s base auto-attack rate, is the player’s auto-attack rate after haste and parry-haste effects, the rate of regular shield slams, the rate of Sword-and-Board-affected Shield Slams

where , , and are the hit, dodge, and parry caps (7.5% each), and and are the player’s hit and expertise percentages.

The found in the expressions come from the derivative of the Shield Block cast rate equation, and are:

where we’ve made use of the following definitions from the Enrage derivation:

Tying it all together

At this point, you might expect that I would start back-substituting expressions.  There are two reasons I’m not going to do that.  The first is that these expressions are complicated enough that doing so is futile.  It’s hard to get any useful information out of these expressions once they become too complicated to read. It’s a little easier to glean intuition by simply evaluating all of the different factors we have and understanding why they’re positive, negative, small, large, etc.

The other problem is recursion.  If you were paying close attention, you might have noticed the following quandary:

So depends , which depends on , which depends on , which depends on…. .  This isn’t a simple thing to solve analytically, and the expressions will end up getting even worse in the process. A similar situation happens for haste, mastery, hit, and dodge when we try to evaluate and .

It’s much faster to use recursion to do this numerically.  Basically, we make a guess at , and then evaluate the whole chain, recalculating at the end.  We then take the new value of and repeat the process.  We do this until a certain tolerance threshold is reached – say, the maximum change in value of any of these variables changes by less than %.  It turns out that only takes around 12 iterations, so it’s not particularly time consuming.

Numerical Calculation

The code I’m using to calculate the results can be found here:

derivations_warr.m

You can see that I’ve more-or-less reproduced all of the equations from this post, and written small loops to handle the recursive definitions.  The input values I’m using are:

(5% base miss/dodge/parry plus 10% dodge and parry from DR)

Numerical Results

Plugging those in and multiplying by for ease of analysis, we get the following stat weights:

Parry and dodge rank at the top, as expected.  Parry pulls ahead of dodge by virtue of increased rage generation through parry-haste, but it’s a pretty small effect.  Mastery doesn’t fare too badly for warriors, but it’s definitely not as attractive as dodge and parry.  I was actually a little surprised at how well mastery did, figuring that the Shield Block mechanic would suppress it some.  In fact, it does – about 80% of mastery’s value comes from the raw mitigation of more critical blocks.  Only about 12% comes from increased block chance, and the other 8% comes from increased Shield Block uptime (via more critical blocks increasing Enrage uptime).

Hit and expertise help increase rage generation and significantly impact Shield Slam casts (by reducing Revenge misses/dodges/parries), so it has a strong effect on resource generation.  Note that armor is actually ahead of mastery in terms of itemization, because you get 4 armor per itemization point.  Haste and crit both provide some increased resource generation (from auto-attacks and Enrage uptime, respectively), but they’re both weak effects.

While we’re at it, let’s see what Shield Block and Enrage uptimes look like:

That’s an incredibly large uptime on Shield Block.  Most of this is due to the changes in this last beta push – doubling the Enrage bonus and reducing Revenge’s cooldown both had a significant impact on rage generation.  Let’s quickly look at the breakdown of rage sources:

So our net rage generation rate is 8.09 rage per second, and the majority of it is coming from Enrage-buffed auto-attacks.  Shield Slam is only accounting for a little over 2 RPS because we’re at low hit/exp.  At 7.5% hit/exp, we jump up to about 9.7 RPS, a little over 7.5 of it from auto-attacks and 2.5 from Shield Slams.  At that level of hit/exp, Shield Block uptime reaches 97% – nearly block-capped.

This is a bit of a problem, in my mind.  Shield Block is rather powerful because it forces block-cap for a fixed time period, and we’ve seen how unbalancing that was in Cataclysm.  If warriors can successfully reach 90%+ uptimes on Shield Block, it will become a balance problem.  I’m not sure what the solution is – nerfing the duration on Shield Block would do it, but that would make Shield Block a bit more timing-intensive too.  Lowering rage generation rates seems like the simplest way to do it.  They could keep the Revenge change, since that makes the rotation more interesting, but drop the auto-attack accumulation rate so that it’s on par with Shield Slams.  That could be achieved by dropping the Enrage bonus, or by keeping Enrage at 50% but dropping the normalized rage generation from auto-attacks from 5/second to 3/second.

Conclusions

In this series, we’ve seen that the warrior equations are much more onerous than the paladin ones due to the complications of parry-haste, Enrage, and auto-attack-based resource generation.  Nonetheless, we slogged through it to get stat weights, and those stat weights seem reasonable given what we know about warrior mechanics.  The dodge/parry values aren’t highly inflated because Shield Block’s guaranteed block effect doesn’t get consumed, unlike the Paladin version.  And since warrior mastery isn’t simply block chance, it interacts with their active mitigation and keeps mastery attractive.  They still see a mitigation benefit from hit/exp, haste, and even crit due to faster rage generation, but those effects are all weaker than the increase from “true” tanking stats.  All in all, the system doesn’t seem too bad.

The real eye-openers are the rage generation levels and subsequent Shield Block uptimes we’re seeing in the model.  If accurate, those suggest a potential balance problem as warriors gear up and can afford to reach hit and expertise caps.  Of course, there could still be changes in the pipeline for warriors, so it’s too early to tell.

1. Enrage Mechanics

The Enrage buff increases rage generation from auto-attacks by 25%, so we need an accurate model of it if we intend to get accurate estimates of rage generation.  Normally, buff uptimes are fairly simple – a buff with a single potential trigger has an uptime of

where is the probability that the effect doesn’t proc ( is the probability that a proc does occur), and is the number of proc chances that occur during the buff’s duration.  The logic behind this is pretty straightforward – the probability of having N failed proc chances during the buff’s duration is , and if that happens, the buff will fall off.  You can rigorously show that this is the correct formula using a Markov chain, if you’re so inclined.  Since this is a well-established result, we’re not going to repeat that here.

However, Enrage is more complicated than this, because Enrage has three proc mechanics.  It can proc from critical strikes (so auto-attacks, Shield Slam, Devastate, Revenge, and Thunder Clap in our model), critical blocks, and from automatic crits through the interaction of Ultimatum and Glyph of Incite.  And on top of all of that, Berserker Rage grants the enrage effect on-demand.

1.1. Multi-Sourced Uptime Equation

Let’s ignore Berserker Rage for a moment, and handle the three proc mechanics.  Using the same logic as the simple example, the buff will drop off if we get no successful procs from any of the three mechanics during the buff duration, so our uptime should look like:

,

where , , and are the “failure” chances for critical strikes, critical blocks, and Ultimatum procs, respectively, and , , and are the number of times each of those events can happen in the 6-second buff duration.  We can write explicit expressions for :

Where is our crit chance, is our crit block chance, and is the Ultimatum proc chance. The expressions for are:

Where we’ve used our definitions of and from last time, and included the glancing blows chance .  Here, we’re assuming that the warrior will only ever use Heroic Strike if it’s free (i.e. 0 rage coast), and Glyph of Incite guarantees each of those will be a crit.  If the glyph isn’t used, is no longer necessary, and regular Ultimatum-induced crits can be folded into by adding a 1.3 to the coefficient of .

Note also that is complicated by the fact that we have different miss rates for each attack source.  Shield Slam, Devastate, and Revenge are all melee attacks, while Thunder Clap is a spell, and auto-attacks have an extra chance for glancing blows (which cannot be crits).

Berserker rage can be trivially included in this, as it gives 20% uptime automatically.  If we treat this as a stochastic event (i.e. random), then our expression for enrage uptime is

In theory, you might be able to do a little better than this by saving Berserker Rage and using it only when your stochastic (i.e. random) Enrage effects aren’t active, but it’s not likely to be a big improvement.

1.2. Derivatives of q and N

We’re going to need to differentiate , so it will be to our benefit to calculate the contributing differentials and .  The are very simple:

where is as defined in part 1.

The derivatives of are much more annoying, so we’ll do them one at a time:

There are a few simplifications we can make to this expression.  We know that from part 2.  We also know that is all of our GCD-based casts except for Battle Shout, thus

Using all of these, along with our definitions of , , , , and from part 2, we have:

We can define a few abstraction factors to help clean this up:

is even worse, because it’s got in it.  Let’s crank through that:

And, again, saving you some algebra:

,

where

,

and I’ve used the definitions from part 1.

is quite simple:

which simplifies to

.

Now, we have all the derivatives of and that we need to complete our Enrage model.  All that remains is to differentiate our expression for and plug in the results from this section.

1.3. Differentiating E

Unfortunately, differentiating is a bit of a pain.  The problem is that both and differentials come into play, which makes the results a bit cumbersome.  To differentiate, we’ll make use of the identity:

Doing so gives us:

We can simplify this some by pulling out a factor of :

We can simplify this further by noting that and plugging in our results for :

Unfortunately, the expression balloons a bit when we plug in the :

But by combining terms and abstracting, we can get a reasonably manageable form:

Which is our final form for , and completes our model of Enrage effects.  Note that while there seem to be a lot of negative signs in these expressions, it’s because all of the natural log factors are negative.

2. Rage Per Second Calculation

At long last, we’re ready to construct our rage generation equation.  The basic form will be:

The easiest is , which is just

,

and since it’s a constant, its derivative is zero.

2.1. Shield Slam Rage Generation

Shield Slam is also fairly straightforward,

The term in brackets is the base SS rage generation rate (maximum 2.8 rage per second at hit- and exp-caps). The derivative is then,

Using our expressions for and from part 2, we have:

2.2. Thunder Clap Rage Cost

Thunder Clap is also not particularly difficult, since we’ve already developed an expression for :

Differentiating gives us

.

2.3. Auto-Attack Rage Generation

Finally, the expression for auto-attacks is:

Note that each melee attack generates a normalized amount of rage .

Differentiating gives us,

2.4. Combined Rage Generation Equations

Combining all four of these expressions, we have:

which simplifies to

.

The Shield Block cast rate is simply .  We could differentiate this directly, but it’s a little easier to just combine the individual differentials worked out earlier:

Which is, of course, annoying to deal with, so we abstract some:

We then plug in our expressions for and :

Combining terms, we have

The change in the rate of Shield Block casts due to a change in rage generation is simply , and we’ve already defined the expression for in part 1:

By inspection, we can now define the as follows:

And finally, we have a complete model of warrior block mechanics.  In the next post, I’ll collect all of the expressions we need in one place and plug in numbers to see how the different stats compare.

1. Rotation Modeling

The first step in this process is to determine exactly what the warrior rotation looks like.  We can make a few assumptions here:

• The warrior dumps all of their rage into Shield Block
• We don’t care about DPS, so we’ll use the highest-rage-per-second rotation

The primary source of rage generation is Shield Slam (SS), which generates 10 rage.  However, it generates 15 rage if cast during a Sword and Board (SnB) proc.  So the rotation will revolve around maximizing SS casts.  The most efficient way to do that is with a simple Priority: SS>Revenge>Devastate

In this model, we cast the abilities as soon as they’re available, following the priority order given.  If you do that, you can break the rotation down into four possible sub-sequences:

• 1: SS-Revenge
• 2: Devastate-SS-Revenge
• 3: Devastate-Devastate-SS-Revenge
• 4: SS(SnB)-Devastate-Revenge

This may look funny, but the idea is reminiscent of a Markov chain.  Every time we cast Revenge, we get a branch, and #1-4 are the only four possible branches we can enter.  For example, we always start with #1.  If that Revenge triggers SnB, we always jump to #4 (SS-Rev-SS(SnB)-Dev-Rev), and if it doesn’t we’ll always jump to #3 (SS-Rev-Dev-Dev-SS-Rev).  Thus, we can find the steady-state probability of each sequence occurring using the concept of Stochastic (or Markov) matrices.  We construct our transition probability matrix P:

In this matrix, each element represents the probability of transitioning from state to state .  To find the steady-state probabilities, we just calculate in the limit as .  In fact, we don’t even need to go very high in – the matrix is identical for :

Thus, we have a 24% chance of being in state #2, a 16% chance of being in state #3, and a 60% chance of being in state #4.  We can use this information to calculate the generated rage per second.  State 2 generates 10 rage in 4.5 seconds, state 3 generates 10 rage in 6 seconds, and state 3 generates 15 rage in 4.5 seconds, giving a net Rage Per Second (RPS) of (10/4.5*0.24 + 10/6*0.16+15/4.5*0.60) = 2.8 rage per second.  This is the maximum rage generation rotation for warriors now that Revenge has a 4.5-second cooldown.

There’s an additional complication though – we haven’t accounted for Revenge misses.  That reduces the transition probability to state #4 from to , and increases the other transition probabilities from to .  Here, is our base chance to miss (7.5% against a boss), and are our base chance to be dodged/parried, and and are our hit and expertise.  Since this term in parentheses (which is our melee success probability) will show up fairly often, let’s define a placeholder for it.  While we’re at it, we’ll define one for our spell success probability () as well:

Once we include this, the steady-state probabilities are analytically:

and their derivatives are

We can then represent this rotation by writing down the cast rates for certain abilities.

1.1 Shield Slam cast rates

Starting with the highest priority, Shield Slam:

We’ve divided this up into rates for “regular” Shield Slams and Sword and Board Shield Slams .  By deconstructing the weighted average we used above, you can show that

.

We’ll also want the variation of each of these terms, so let’s calculate them right away:

with

1.2 Revenge cast rates

We can also quickly figure out Revenge’s cast rate,

using the same technique.  Note that we’re assuming here that Revenge is always available, which is a pretty safe assumption if you’re tanking.  It turns out we won’t need either of these values, but they’re good to have lying around.  The derivatives of are identical to that of , so

.

1.3 Thunder Clap and Battle Shout cast rates

Devastate is a little trickier, because we’ll be replacing some Devastate casts with Battle Shouts and Thunder Claps.  So let’s work out those first.  Shout is easy – it’s just

.

Thunder Clap is slightly trickier.  Ideally, we would cast it every 30 seconds to keep up the Weakened Blows debuff.  However, it’s not automatic.  If it misses, we’ll cast it again as soon as it’s available (6 seconds).  So the proper way to write it would be:

.

In other words, it’s the weighted average based on hit/miss chances.  Note that I’ve assumed it misses as a spell for this rather than as a melee strike.  I’m not sure if this is correct, but it’s easy to fix if we find out that assumption is wrong.  This simplifies to

,

and the derivative  is

,

with .

1.4 Devastate cast rates

Now for Devastate.  In the scenarios above, we cast Devastate at a rate of

,

with a derivative scaling of

,

with

.

However, we need to subtract off to account for Thunder Clap and Battle Shout:

From this we can immediately see that

,

We could substitute in our expressions for and , but that doesn’t make the expression too much easier to work with, so we won’t bother.  At this point, we have a complete model of the warrior rotation.

If Shield Slam and Battle Shout were a warrior’s only sources of rage, we’d be done here.  Rage generation would simply be the rage from Shield Slams plus the rage from Battle Shouts minus the rage used to maintain The Clap.  And that would be really simple. But we’re not so lucky, because warriors also generate rage from auto-attacks.  And that leads to a number of problems.

First, we need to accurately model melee swings, which means we need to care about parry-hasting.  That’s a non-trivial problem, and will be the focus of the second half of this post.  The other issue is that Enrage increases rage generation from those auto-attacks during its effect, which means we need an accurate model of Enrage uptime.  And to do that, we need to account for all sources of Enrage – critical strikes, critical blocks, and even the interaction of Ultimatum with Glyph of Incite.  We’ll deal with the Enrage modeling next time.

2. Parry Hasting

Parry-hasting as a mechanic can be extraordinarily complicated in the general case.  I’ve worked on this problem before, and the matlab code has a function that specifically models parry-hasting.  If we wanted to treat the problem completely generally, it wouldn’t be possible to come up with a nice analytical formulation.  However, we’re going to limit our scope to a single situation – tanking a single raid boss – which makes it possible to analytically represent parry-haste.

The mechanics of parry-haste work like so: When you parry an attack, your swing timer is reduced by 40% of its un-hasted value, unless that would reduce the swing timer to below 20% of that un-hasted value, in which case it reduces the swing timer to 20% exactly.  That’s a little clumsy, so let’s consider an example.  If I have a 2.00-speed weapon, my swing timer is 2 seconds.  If I parry the boss when there’s 1.9 seconds left on my swing timer, it reduces my swing timer by 40% of 2 seconds, which is 0.8 seconds, leaving 1.1 seconds remaining on my swing timer.  If I parry when there’s 0.9 seconds left on my swing timer, it can’t reduce my swing timer by the full 40% because that would drop itbelow the 20% threshold (which is 0.4 seconds).  So instead, it drops the swing timer to 0.4 seconds exactly, giving me 0.5-seconds of parry-hasting (only 25%, instead of 40%).  If I parry an attack when there’s 0.4 seconds or less left on my swing timer, there’s no effect at all.

Thus, the average amount of parry-haste you get from a single parry is 24%.  There’s an additional complication, which is something we call “Doubly Degenerate Parry Events” (DDPEs).  This is when you parry two attacks in rapid succession, and that ends up causing some attrition in parry (the second parry is less effective, necessarily).  However, we’re going to consider a boss with a swing timer between 1.5 and 2.0 seconds, which eliminates the possibility of DDPEs.  So we can ignore that problem.

Generally, one would represent parry haste by a set of coupled equations linking the boss attack rate to the player auto-attack rate .  However, since bosses no longer benefit from parry-haste, the equations are considerably simplified, and the coupling is one-way:

Here, is the coupling constant that represents the effect of parry-haste.  If we ignore DDPEs, we can represent as:

To get some intuition here, is the binomial probability distribution representing having successful events out of trials, with a success chance of .  In our case, , the chance to parry the incoming attack.  Thus, the first term represents the parry-haste we gain if the boss only attacks once during the swing timer and we parry that attack.  The second term represents the gain when there are two boss attacks during the swing timer, and the expression in brackets is the probability that we parry exactly one of those attacks (which is 1 minus the probability that we parry neither minus the probability that we parry both).

The text expressions can be converted to analytic expressions if we define

,

which is the average number of parry-haste opportunities we have in a hasted swing timer.  The chance of having one incoming attack is then just , and the chance of having two incoming attacks is .  In addition, we can substitute in the exact form of since our cases are fairly simple.  This gives us an expression for that looks like this:

and substituting in our expression for , we finally have:

To give you some idea of how big an effect this is, assume a boss swing timer of 2 seconds, a 2.6-speed weapon, and 10% melee haste.  Then , , , and .  That takes a hasted swing timer of 2.3636 seconds and reduces it to 2.228 seconds, on average, or about 5.74% faster auto-attack speed (i.e. 5.74% haste).

What we’ll need for our derivation, in addition to the expression for and , are their derivatives:

and, saving you some algebra on :

If we combine these expressions, and define some abstraction variables, we get

where

Which is what we’ll need to develop our expression for rage generation, which will turn into an equation for the Shield Block cast rate .

It’s important to include parry-haste if we want a reasonable expression for .  Without including parry-hasting, we’d be over-valuing haste by about 10% (, while ) and we wouldn’t have the parry-specific scaling of rage generation that differentiates it from dodge.

In the next post, we’ll tackle the Enrage problem, and tie it together with parry-haste and the warrior rotation developed in this post to complete our expression for rage generation.

Boy was I wrong.

The warrior calculation is far, far worse than the paladin one, for subtle reasons.  It’s somewhat ironic, because the calculations for how warriors spend resources are much easier, just as I thought they would be.  The problem is that their resource generation is a tangled, unimaginably awkward mess.  Primarily because of two specific complications: the Enrage mechanic and parry-haste.  At several points within the calculation, I thought about deftly avoiding both of those problems through approximation techniques.  But in the end, my curiosity got the better of me, and I treated both of them in full, with as little approximation as necessary.  Unfortunately, that’s 8 hours of my life I’ll never get back.

But in any event, the warrior calculation is complete, and I’m going to publish it in 4 parts.  In this first part, I’ll go through the basic framework, which is very similar to the paladin calculation.  In the second part, we’ll dig into the warrior rotation and tackle the problem of parry-hasting.  The third part will deconstruct the Enrage mechanic and develop the expression for rage generation.  And then in part 4, we’ll tie everything together, plug in numbers, and see how things work out numerically.  I’ll probably skip the Monte-Carlo sim this time, so there likely won’t be a part 5.

A Word On Notation

In the paladin calculation, I was a bit haphazard with variable names.  This came back to bite me a few times, and in retrospect I would have done a few things differently to make it clearer where certain factors came from.  Luckily, I’ve since developed a slightly better set of variable-naming conventions, which turned out to be essential to making the warrior calculation manageable.  I’m going to use the new notation here, so be aware that certain variables (ex: ) won’t share a meaning between the paladin and warrior calculations.  If Blizzard ends up changing our active mitigation mechanics, I’ll have to re-do the paladin calculation, and at that point I’ll update our version to the new notation.

1. The Incoming Damage Formula

As for paladins, the incoming damage formula can be written:

Where is net damage taken, is damage intake before mitigation/avoidance effects, is the spec-based mitigation factor (Sanctuary for paladins, Defensive Stance for warriors, ), and , , and are the armor, avoidance, and block mitigation factors, respectively.  We’ll define each of those shortly.  To see how damage varies with different stats, we’ll want to perform implicit differentiation on (1):

and don’t vary with rating, so we divide through by those to normalize.  Thus, to determine how damage varies with stats, we need to define all three of the mitigation factors and differentiate them.  The armor and avoidance factors are easy, and identical to the paladin version, so we’ll start with them.

1.1 Armor Mitigation Factor

The armor factor works exactly the same way it does in Cataclysm.  An amount of armor grants mitigation equal to

,

where is the armor constant (32573 for an 88 boss).  The armor factor is then

,

and differentiating we get

where we’ve defined to put this in a form reminiscent of the other factors we’ll encounter during the derivation.  can be thought of as a “rating-to-percent” conversion factor for armor, since that’s what will represent for rating .

1.2 Avoidance Mitigation Factor

Avoidance is only slightly trickier due to diminishing returns (DR).  In addition, we can no longer treat dodge and parry as identical, as we could in the paladin calculation.  So we’ll just keep track of them both.  Let our warrior’s total avoidance have the form:

where , , and are miss, parry, and dodge from sources that aren’t subject to DR, while and are parry and dodge gained from sources which are subject to DR.  The avoidance mitigation factor is,

,

and differentiating this gives us

To express the post-DR differentials in terms of rating, we need to differentiate the diminishing returns equation:

which gives us

.

Here, and are the diminishing returns coefficients for dodge, and is the pre-DR amount of dodge corresponding to post-DR dodge.  Parry follows an identical equation.  If we assume that the player has balanced dodge and parry (such that ), then we can simplify this slightly by introducing an avoidance dependency factor :

such that is

.

Again, and are our rating-to-percent conversion factors for dodge and parry.

1.3 Block Mitigation Factor

The block mitigation factor is more complicated, just as in the paladin case.  We start from the expression:

,

which can be re-arranged to the simpler form

.

In this expression, is the probability that an un-avoided attack becomes a guaranteed block.  is the critical block chance, as determined from mastery.  is the player’s total block chance, and $B_v$ is the player’s block value.  Note that by definition, since we’re representing critical blocks explicitly with . If we differentiate , we have

,

where we’ve defined the factors

.

We still need to develop explicit expressions for , , and to complete the derivation.  The last two are easy, so we’ll tackle them first; is where the complications turn up, so we’ll save that for later.

1.3.1 – Block Chance derivative

Block chance can be written

,

where is block chance from sources unaffected by DR (so, base block and Bastion of Defense) and is the post-DR block chance from any other sources (which, as far as I know, is only mastery).  The diminishing returns equation for block is identical to that of avoidance, but with different coefficients and :

.

Just as we did for avoidance, we can relate to :

.

is related to a change in mastery () by , where is the mastery-to-block-chance conversion factor (1.5%).  To put this in terms of rating, we use , where is the rating-to-mastery conversion factor.

Bringing this all together, and noting that , we have

,

where we’ve defined as

These last two equations complete the factor .

1.3.2 – Crit Block derivative

Critical block chance can be expressed in the form,

,

where is crit block from other sources and is crit block from mastery.  I’m assuming there’s no diminishing returns on crit block; luckily if this is in error it’s a simple fix.  Differentiating, we have

,

where is the mastery-to-crit-block conversion factor (1.5%).

1.3.3 – Shield Block derivative

is complicated because it depends on many different things.  The expression for itself is not particularly onerous:

with representing the Shield Block cast rate, and the duration of the Shield Block buff.  Note that is also the uptime of the Shield Block buff.  Differentiating , we get,

The next step would be to start calculating and , and plug those results into and .  Unfortunately, that’s the hard part of the calculation, and requires some complicated modeling of parry-haste and Enrage mechanics.  We’ll tackle that in parts 2 and 3 of the series.  For now, we cheat: we’ll use the answers in abstracted form.  This works because we know the form of the answer, so by defining variables to represent the stuff we haven’t worked out yet, we can continue the calculation and get to the end.

Let’s assume that has the form:

,

where I’ve used to represent a small change in hit, a small change in exp, a small change in haste, a small change in mastery, a small change in dodge, a small change in parry, and a small change in critical strike (yes, crit is a mitigation stat for warriors).  Note that these are changes in percentages; thus is equivalent to a rating change of , and so on for the other factors.  The variables are just like our earlier factors of or , in that they represent the effect that a small change in a particular stat causes in .  The can (and will) depend on any of the input variables.  Finding suitable expressions for will be the objective of the next two blog posts.

In the meantime, we can use these results to put in a more convenient form:

,

where we’ve defined the as:

With these definitions, we can go back and finish defining , and subsequently finish the derivation (symbolically, at least – we’ll need the before we can start plugging in numbers).

1.3.4 – Constructing the Block Factor derivative

Substituting our expressions for , , and into $dF_b$, we have:

We’re going to do another round of encapsulation here to keep the expressions manageable.  Thus, we’ll write as

,

with the following definitions for the :

We can now take these definitions that describe and combine them with our earlier expressions for and to come up with scaling factors for the different ratings that describe their relative value at reducing .

1.4 – Normalized Scale Factors

Starting from , and substituting the differentials we’ve worked out, we have:

Combining terms, we can write this in the form:

,

where we’ve defined the normalized scale factors as:

These are the normalized scale factors that we need to calculate to compare different stats.  At this point, it’s a simple matter of taking our initial conditions (i.e. the player’s avoidance, block, etc.), calculating all of the factors we’ve defined, and plugging them in.  Except, of course, that we need to develop expressions for the first, which will take some work.  Next time, we’ll start figuring out how to express by looking at the warrior rotation and the effects of parry haste.

<edit> Since publication, I’ve found that I made an error defining .  This considerably simplifies part of the calculations.  I’ve updated to accurately reflect this new definition.  Apologies for the confusion, if it caused any.

The Monte Carlo method is a very common technique in statistical simulation. The basic idea is that you have a system with a random element that makes it sensitive to fluctuations.  It could be a random process, such that the same input gives different outputs based on the state of the system (some quantum mechanical situations are like this), or it could be a deterministic process that has random inputs.  In either case, the Monte Carlo method involves generating a bunch of random numbers and looking at the output of the system.  By doing this enough times, you can determine if there are statistically significant trends in the output data.

In our case, we have a random process – combat.  We start from the same initial conditions (everything off cooldown, no buffs, etc.), but the process itself contains randomly-determined results based on combat table rolls.  Thus, our Monte Carlo simulation basically simulates combat – we track a bunch of cooldowns and buff durations, and make combat table rolls that affect the results.  By running the simulation long enough, we can get pretty accurate stochastic averages for the values we’re interested in.

Simulation Details

You can find the code for the Monte Carlo simulation here:
montecarlo.m
montecarlo2.m
montecarlo3.m

The basic idea is that it tracks the boss swing timer, the cooldowns of CS and J, the uptimes of both SotR buffs, Divine Purpose, and Grand Crusader, as well as the GCD.  It runs in timesteps of 10 milliseconds and keeps track of whether the boss attack is a hit, miss, or block (as well as the type of block – “gblock,” “sblock,” or regular block).  It makes combat rolls for avoidance and block to determine these outcomes, as well as random rolls for Divine Purpose and Grand Crusader.  The logic is such that it will prioritize CS>J>AS(only if GC available), and it won’t cast J if there’s <0.2 seconds left on the CS cooldown (I needed to do this because J scales slightly better with haste, resulting in it coming off-cooldown a little earlier and mucking up the rotation).

Finally, I’ve put some code in there to handle our assumptions from Part II.  It will cast SotR whenever we have >3 holy power or a Divine Purpose proc, but it won’t re-cast SotR until the guaranteed block is used.  This risks “wasting” some holy power generation, but in practice that happened 0 times in any of my simulations because we’re not pooling Holy Power to 5.  We can go back later and see how this changes if we do pool holy power simply by changing the conditionals on SotR, but by coding it the way I did, we should see the best possible agreement with the model.

Note that our other assumptions – namely that our uptime is based on a single application estimate and that everything can be approximated as occuring at nicely-spaced intervals – are not being adjusted for.  So if there’s any significant inaccuracy introduced by those assumptions, they should show up in the data.

Simulation Results

Now let’s look at the results.  I’ve used the same input values as the analytical derivation.  First, let’s look at what we get with those inputs:

Plot showing the distribution of hit sizes with the current model. 29.8% of attacks are avoided (0 damage), 29.3% are "gblocked" (0.25 damage), 18.7% are "sblocked" (0.5 damage), 3.8% are blocked regularly (0.7 damage), and 18.4% aren't blocked at all (1 damage). DTPS is out of a possible 50 (1 damage every 2 seconds, multiplied by 100).

If you’ll note, these values are extremely close to the ones in the analytical derivation.  With 10,000 minutes of combat, the Monte Carlo manages to match and to the analytical model to three decimal places.  differs slightly in the fourth decimal place, but is a little bit higher than the 6.4 predicted by the analytical model.  My guess is that this is the error due to discretization – namely that in the model, we don’t consider the coolown on SotR and use a stochastic time average for Divine Purpose.  In the numerical sim, SotR’s 1.5-second cooldown keeps it from bunching too tightly, and ends up pushing back SotR casts in cases with multiple DP procs.

The graph also shows some of the features that made mastery so weak in our analytical model.  Only 40.9% of attacks are even eligible for block as a result of the two-roll system, so that inherently almost halves block’s effectiveness.  We’re only blocking 22.5% of all attacks (18.7% “sblocks,” 3.8% “regular blocks”), giving 22.5%/40.9%=55.01% block, right in line with our input block chance.  59.1% of all attacks are avoided or end up being guaranteed blocks.

Now let’s look at what happens when we add 600 rating of various sources (I’ve skipped armor here, because I didn’t bother to include it in the Monte Carlo).  The simulation runs for 10,000 minutes of combat for each stat, which is still not enough to get wonderful accuracy for such a small change in rating, but enough to make sure we’re correct in at least the first significant digit.  Here is the reduction in DTPS (multiplied by 100 to make the numbers more reasonable) that occurs when adding 600 rating of each type:

Dodge:    0.9285
Hit:    0.6835
Exp:    0.6226
Haste:    0.4955
Mastery:    0.2948

Again, these seem to validate our values from the analytical calculation.  Dodge is well ahead of Hit/Exp.  Hit and Expertise should be identical, but even with 10k minutes per stat, we have some statistical fluctuations.  Haste lags behind hit/expertise, and mastery still brings up the rear.  So this, combined with our pin-point accuracy on and suggests that the analytical model is quite accurate indeed.

Finally, let’s take a look at variance.  A 10,000-minute fight isn’t realistic, because most fights last on the order of 5 minutes.  How do , , and vary from fight-to-fight for short encounters?

This plot shows the distribution of G and S values for 500 different 5-minute (combat time) simulations. G varies significantly less than S, as S is more dependent on the spacing and timing of SotR casts and boss attacks.

As we see here, can range from about 0.32 to 0.55 depending on attempt.  But varies quite a bit more than that – from as low as 50% to as high as 100%.  The standard deviations here are 3.69% (for ) and 9.63% (for ).  Plots for and are shown below, but they don’t really tell us much that we didn’t already know.  HPG varies based on hit/expertise and Grand Crusader procs, and SotR casts inherit that randomness and add a little Divine Purpose noise.

This histogram shows the variation of the SotR cast interval T_{SotR} under the same conditions as the previous plot.

This histogram shows the distribution of HPG rates for 500 different 5-minute (combat time) simulations.

Conclusions

This has been a short post – mostly because I’m rushing to finish this before heading out for the weekend.  But I think the point was to validate the analytical model with a numerical simulation, and I don’t think there’s any doubt that we’ve done that.  There are some interesting statistical questions we could answer with this code, but that will have to wait for another time.  In any event, we now have two conclusive pieces of evidence – an analytical model and a numerical simulation – that the current model of Paladin blocking makes mastery our dump stat.  Let’s hope that this is enough to convince Blizzard that change is needed.

First, we need to recap the equations we’ll need to proceed.  There are a lot of them, but I don’t want to make readers sift through the last few blog posts just to find the definition of a term, so we’ll summarize them here.  If you’ve been following along the whole time, feel free to skip to the next section.

The damage taken formula is:

where is the pre-DR incoming damage, and the armor, avoidance, and block factors are defined as:

,
,
.

is the armor constant, is the player’s armor, is the player’s total avoidance, is the player’s block value for the guaranteed block from SotR (75%), is the block value during the SotR buff (50%), is the default block value (30%), and is the player’s block chance as read off of the character sheet. and are variables that describe SotR mechanics as defined in the first installment:

is the duration of the SotR increased block value buff.  The SotR cast rate and incoming blockable attack rate are:

where is the divine purpose proc chance (0.15) and is the boss’s swing timer.  is our Holy Power generation rate from all sources:

Here, , , and are miss, dodge, and parry caps, respectively, and , , and are our hit, expertise, and haste percentages. and are our CS and J cast rates, and is the Grand Crusader proc rate.  is the HPG rate from Blessed Life, or from any other non-rotational sources.

Last week, we defined the differential of , which represents the change in damage intake:

And calculated the differentials of each factor implicitly to find their dependence on ratings:

where is our character’s post-DR dodge chance (ignoring base dodge), and are the avoidance diminishing returns formula coefficients, and is the rating-to-percentage conversion factor for stat $i$ (i.e. for haste, for dodge, etc.).  The block factor was particularly ugly, so we defined the following additional quantities to make things a little easier to work with:

where the only new variable we’ve introduced is , which is the portion of our post-DR block chance that was subject to DR (in other words, , where is our base block chance at 0 mastery.

Developing Relationships  Analytically

The next step is to start generating relationships between the different stats.  If we substitute in our new expressions for , , and into the expression for and group terms according to rating type, we get the following expression:

In the past, we’ve then set equal to zero and explicitly worked out formulas that equate one stat to another.  For example, if we wanted to see how much haste rating gives as much damage reduction as a given amount of mastery rating, we’d set all of the other to zero and solve:

which gives the simple solution

I chose that particular combination because a lot of factors cancel and make it easy on us, but you could do the same for any of the different combinations and get a similar (albeit uglier) expression.

That was fine in Cataclysm, because we were only looking at three major stats: avoidance, mastery, and armor.  With N stats, there’s different combinations, which for N=3 and k=2 is just three: avoidance vs. mastery, avoidance vs. armor, and mastery vs. armor.  However, now we’re looking at six stats: armor, avoidance, hit, expertise, haste, and mastery.  For N=6, there are 15 different combinations.  At that point it becomes less efficient to derive explicit relationships between each pair of stats, and more efficient to find some way to normalize the contribution of each stat so we can look at their relative weights numerically.

In other words, it will make a lot more sense to choose realistic character stats and calculate the factors and , and see which one is bigger.  Not only will those tell us how haste and mastery compare, but if we want to compare either to a different stat (say, avoidance) we only need to calculate the equivalent factor for that stat, and we instantly know how it stacks up to both.

So we define the normalized damage reduction factors as follows:

What do these factors represent?  Well, each one is the net damage reduction that you gain from one point of rating .  So tells you the damage reduction of one point of mastery rating, one point of haste rating, and so on.  The nice part about this is we can simply write a program that does the annoying work of evaluating the messy expressions in the first section of this post.  We feed the program a few easily-understood input parameters like armor, avoidance, and so on, and it spits out the six values we’re interested in.   So let’s do that.

Developing Relationships Numerically – Inputs

First, we need to define our inputs.  Since we don’t have stats at level 90 yet, let’s make some estimates based on stats at level 85 fighting a level 88 boss.  We’ll assume that the player has 30% avoidance 15% of which is from dodge.  We’ll also assume they have 55% block chance, 40k armor, 2% hit, 2% expertise, and 10% haste.  That gives us the following variables:

Based on the level difference, we have the following values for the hit/expertise caps and armor coefficient:

We also have the block value tiers we defined earlier:

And we know the rating->percentage conversion factors for each stat (noting that the percentages are in decimal form):

The diminishing returns coefficients for avoidance and blocking are also necessary:

(~65%)
(~135%, courtesy of Pagezero at Tankspot)

And we have some assorted constants to define:

Finally, we need to assume a boss swing timer.  Let’s choose 2 seconds:

Developing Relationships Numerically – Outputs

I’ve written a MATLAB script file that defines all of these values and then calculates the expressions we’ve worked out.  First, we need to pick a rotation, because that determines and .  For this example, we’ll choose “SotR>CS>J>AS>Cons>HW,” which tends to maximize holy power returns (thus giving the best results possible for hit/exp/haste).  In this model, you cast CS on cooldown, so

Judgment gets pushed back every so often, however, which gives it an effective cooldown of 6.75 seconds (which you can work out by hand as well).  Thus,

.

To see how accurate our HPG modeling is, let’s compare it to the matlabadin FSM code, which gives very accurate rotation information.  Plugging those values into our formula with 10% haste gives us a HPG rate of

,

in perfect agreement with the FSM code.  Thus, we can feel certain that our formula for is correct.  So far so good. Based on the HPG rate, our model says we should have a SotR cast rate of

,

or one SotR every 6.64 seconds, again in agreement with the FSM code.

Our formulas for and give us the following uptimes:

That’s pretty incredible – 43% of the incoming attacks that we don’t avoid are guaranteed to be blocked by SotR at 75%, and we’ll have the +20% block buff up for 83% of the ones that aren’t avoided or guaranteed.

But I know what you’re really interested in is the normalized damage reduction factors .  So let’s jump right to them.  Since the values come out to be pretty small, let’s define

which is the net benefit of 100000 rating instead of 1 rating.  Note that we’re not really trying to model stacking of any of these ratings – we’re just multiplying the results by so they’re easier to compare (otherwise we’d need to use scientific notation).  The results are:

Wait, hold on, is that right?  These results are saying that mastery is in dead last place, behind hit, expertise, haste, and even armor (remember that we get 4 armor per itemization point, so it’s actually got a per-itemization value of .

Yes, sadly, it’s correct.  I’ve double-checked it a few times now, and I think I’ve caught and fixed all of the errors in the derivation.  Unless something about our mastery changes significantly between now and release, mastery is going to be our dump stat in MoP.

O Mastery, Why Hast Thou Forsaken Us?

To understand why mastery performs as badly as it does, we need to drill down a little farther.  Let’s look at the values that go into :

So there’s part of the problem: is smaller than the others by a factor of 4 to 7, depending on what we’re comparing it to.  Note that all of the have an armor factor (i.e. ), an avoidance factor (i.e. ), and a block factor (either or one of the ).  So the fact that is at least four times lower explains why block performs so poorly.

But why is so low?  And not just in the mathematical sense – what mechanically is going on that causes to lag the others so much?  To see that, we need to drill down further.  Let’s look at the “block prefactors,” or the factors that go into the expression for :

What do these tell us?  is the multiplier that relates a small change in to a small change in .  serves the same purpose for , and for (and thus mastery).  From this vantage point, it looks like block isn’t faring so badly.  We can see that SotR’s guaranteed blocks have a fairly large effect, but good old block seems to be OK.  Of course, the devil is in the details – it’s not the that are the problem; the problem is that a fixed amount of rating gets you a much bigger change in than it does in .

To see why, let’s look back at our equations for , which I’ll repeat here:

Now, just look at the parts in brackets, because it turns out the factors out front are almost identical for dodge and mastery, and about half that size for haste and hit.  For hit/exp , haste , and dodge , they contain a term with (which is large) over (which is small), which subsequently makes the first term very large.  This first term is characteristic of the effects of that stat on the SotR portion of block mitigation – that factor of comes from (or , depending on how you look at it).

These factors also have a second term that represents the effect on the 6-second block value buff, with .  Even though is small, it turns out the second term is actually larger than the first due to the other factors.  For hit and haste, the first term evaluates to around 1.4, the second is about 1.73.  For dodge, the first term is around 0.6 and the second is 1.36.

So hit, expertise, dodge, and even haste are all strong stats because they feed into our active mitigation, both by increasing the amount of guaranteed blocks we get and increasing the uptime of the SotR block value buff.  Hit, expertise, and haste all do this in the obvious way – they increase Holy Power generation, which lets us use our active mitigation tool more often.  Dodge does it a little more subtly, by reducing – essentially, the more you dodge, the fewer incoming attacks you have that are eligible for block, increasing the percentage of them that become guaranteed blocks.

But look at .  It’s just got a lonely factor of , which is 2x-4x smaller than any of the individual factors inside the brackets in the other .  It’s propped up a little by having a better rating->percentage factor , but not nearly enough to let it catch up to the other stats.  And the reason is because it has only a very weak interaction with our active mitigation.  In fact, our active mitigation actively undermines mastery by making it less useful.  The more guaranteed blocks we get, the less important mastery becomes.  If you bump up the hit and expertise values used in the calculation, you increase the importance of and the value of goes down by a few percent.

That said, we can’t blame it all on active mitigation.  Certainly diminishing returns plays a part, as does the two-roll system itself.  The diminishing returns on block are about twice as bad as the diminishing returns on avoidance; is almost half as large as , because we’re much higher on the DR curve for block than we are for avoidance (partly because avoidance is split between two DR mechanisms – dodge and parry).  And the two-roll system reduces the effectiveness of block chance inherently, like we’ve discussed before.

But the dominant factor in mastery’s demise as a damage mitigation stat is our active mitigation.  It introduces an interesting feedback mechanism between avoidance and our active mitigation that allows avoidance to double-dip (hence the second term in – note that each term of is larger than , , or ).  The more we avoid, the stronger SotR’s guarateed blocks get, so adding dodge rating gives us less damage due to avoided attacks and less damage due to a higher percentage of 75% blocks.

Where do we go from here?

I’ve already been advocating a change in our mastery, partly because I was worried it would be too weak (little did I know – even I didn’t expect it to be this bad), and partly because block chance isn’t really all that exciting.  It wasn’t exciting in Cataclysm either, but the presence of a block cap made for interesting gearing choices, much like the hit or expertise cap does for a DPS.  Mastery in MoP fails to even have that level of “interesting.”  It’s just another passive total damage reduction stat, like dodge or parry, but less efficient.

The solutions I’ve been advocating on maintankadin have all included mechanisms that couple mastery with our active mitigation.  At the time, I didn’t realize how critical that coupling would be, but the number-crunching we’ve done in this post shows that it’s even more important than I could have guessed.  It’s essential, in fact, because our active mitigation accounts for a much larger part of our survivability than our “last resort” block chance does.  In a future blog post, I’ll look at some of the possible ways we could introduce this coupling and make mastery an interesting and useful stat.

In the next and final part of this series of blog posts, we’re going to build a numerical Monte-Carlo simulation to validate our analytical model and figure out how reasonable the various approximations we’ve made along the way really are.  That may not happen until Friday, though, both because I’ve yet to write the simulation and because I’ve been monopolizing the blog for the better part of a week.

In the last post, we worked out the basic math modeling of our new block mechanics.  That was actually the hard part, believe it or not – getting the model right is the biggest part of the job, and the most likely place to make mistakes.  And we did have to make a few approximations to get there, but they should all reasonably good approximations.

Now, we need to take that modeling and calculate relationships between the different inputs.  That takes a bunch of calculus, but it’s mostly straightforward plug-and-chug operations.  So while it’s a lot of equations and math, it’s not terribly complicated or interesting math.  In fact, after going through it, I’ll tell you that it’s incredibly tedious and ugly as hell.  But we’re going to have to do it anyway, so let’s get down to it.

To recap from last time, we have the following equations:

, , and are the armor, avoidance, and block mitigation factors, respectively.  is the probability of any given attack being a guaranteed block due to Shield of the Righteous (SotR).  is the probability that an attack which isn’t a guaranteed block occurs during the uptime of the other SotR buff, which gives increased block value.  is our character sheet block chance, is our character sheet block value (30%), is our block value during the SotR buff (50%), and is our block value for the guaranteed block (75%).  is the rate at which we cast SotR, is the incoming attack rate (which we’ll see shortly is actually a little different than the swing timer because of avoidance), is the duration of the SotR block value buff, is our Holy Power generation rate, and is the Divine Purpose proc chance (15%).

Got all that? Good.  There will be a quiz on it later (not really).

A Word on Assumptions

In the comments of the last post, Weebey pointed out a few aspects of the derivation that looked fishy.  And rightfully so, I did have to make a few assumptions, and I wasn’t as clear as I could have been about what they were.  Any good derivation should come part and parcel with a good degree of error analysis.

Let’s quickly go over the assumptions we had to make in the previous post too.  First, we’re assuming that we never waste a SotR cast – that every cast gives us a guaranteed block.  However, if we cast SotR twice in a row without blocking something in-between, we don’t get 2 blocks later – the buff just refreshes, it doesn’t stack.  So there’s a chance we’ll get some clipping, which will cause some attrition in .  In other words, we’d need to scale down by an attrition factor.  That’s going to be tedious though, and it shoudn’t happen very often since SotR is off-GCD and can be timed based on Holy Power pooling, so we’re ignoring that for now.  When we get around to the numerical simulations (Part 4, at this rate), we’ll see how big an effect this is, and whether that’s a reasonable approximation.

Technically our expression for is a small approximation too, because we’ve based it on a model of a single application of the buff.  Since subsequent applications add duration rather than refreshing it, it should be a very good approximation, but the same variability that applies to will have a subsequent effect on .  Again, we’ll have to wait for the numerical simulations (or do some ugly combinatorics) to see how much error this introduces.

In general, we’ve treated everything in this derivation as nice and regular – boss attacks and SotR casts come in nicely-spaced intervals.  That in itself is an approximation, because in combat scenarios those things vary quite a bit.  That leads to bunching, which leads to the same sort of attrition seen in and causes a greater variance in the values of and from fight to fight.  You might get two or three SotR casts in a row, or you might get none for 10 seconds if you miss all of your Crusader Strikes.  We should have a pretty good estimate of the stochastic behavior, but if the variances are large we might find that individual encounter-length data sets deviate significantly.  The numerical sims will give us some information on that detail as well.

Finally, in the last post (which I’ve since updated) I originally said that was the boss attack rate, or the inverse of the boss’s swing timer .  That’s not strictly true, because we’ll avoid some of those attacks, and since the SotR buff ignores avoidance, the effective attack rate as it pertains to blocking will actually be lower (or equivalently, the effective swing timer will be higher).  The reason I ignored this in the last post is that only shows up in the expressions for and , so those two parameters encapsulate the effect.  That made it a little easier while working through the derivation by hand, but looking at it now I realize that it makes the whole thing a lot more confusing to understand.

Thus, I’ve gone back and edited Part 1 to make it clear that is the effective attack rate rather than the “true” incoming attack rate , and similarly for the “effective” and “true” boss swing timers and $T^{(0)}_{\rm att}$.  The rigorous definition of is then

.

This is the definition we’ll use when we plug in numbers.

The Incoming Damage Formula

OK then, it’s time to start the calculus portion of the derivation.  What we’re interested in is the change in incoming damage, which is the derivative of .  We’ve never specified whether represented raw damage or damage per second, and it doesn’t actually matter which – the equation is the same either way.  Taking our very first equation and performing implicit differentiation, we have:

Each of these terms represents a relative change in damage taken due to a small change in that factor, either armor (), avoidance (), or block ().  We’ll have to evaluate each of those differentials to relate the change in the factor to the underlying change in armor, avoidance rating, and mastery, respectively.

Armor Factor

The armor factor is easy – it’s unchanged from how it currently works.  The armor mitigation factor is just one minus the amount of mitigation we get from armor, and has the form

where is your armor and is the armor constant, which is 32573 for a level 88 boss.  Therefore,

and

.

Simple enough!  We can use this equation to directly relate a change in armor to a change in the armor mitigation factor .

Avoidance Factor

Next up is avoidance, which is a little trickier for two reasons: diminishing returns (DR) and rating conversions.  First of all, we’ll make the assumption that we only care about one type of avoidance – say dodge.  The equations are symmetric in both, so finding the results for one is equivalent to finding the results for the other.  We need to express the avoidance mitigation factor a little more specifically though, to isolate the part of avoidance affected by DR.  So we’ll define it like this:

.

Here, is all of your avoidance from miss and parry, as well as any dodge sources that aren’t affected by DR (ex: base dodge).  is the post-DR dodge value, so we need to relate that to the pre-DR dodge value, which we’ll call .  The relationship between those two is,

,

where and are the diminishing returns coefficients for dodge (or parry).  I’ve given them subscripts because block uses the same DR equation, but with different coefficients – this way we can keep them straight.  Differentiating this equation gives us,

which can be re-arranged to give

.

and if we solve the DR equation for and substitute, we get the most convenient form:

This is convenient because it expresses the change in post-DR avoidance $dA_d$ in terms of the change in pre-DR avoidance , the post-DR dodge value , and the constants and .  We know the constants, and we can read off of the character sheet.  The pre-DR dodge value is very simply linked to rating:

where is the amount of dodge rating we’re adding and is the conversion factor relating dodge rating to dodge percentage (176.72 at level 85 in Cataclysm).

Differentiating and plugging all of this in, we get:

Which is our final expression for

Block Factor

Finally, we need to attack the block differential.  This is by far the most complicated because there are so many factors to consider.  We see why when we differentiate :

Grouping terms, we can simplify this to

To continue, we need the derivatives , , and .  The first is easy, the last two are a bit ugly.  Let’s do the easy one first.  Block uses the same diminishing returns formula as avoidance, but with different coefficients.  Since is our post-DR change in block chance, we’ll let our pre-DR change in block chance be , and the DR coefficients will be and .  We then have:

where is the portion of our block which is subject to diminishing returns (at this point, everything but our base block chance).

is related to mastery rating very simply:

Thus, our final form  is

.

depends on the amount of mastery rating added , the rating-to-percentage conversion factor for mastery (which is 179.28/2.25 = 79.68 at level 85), our post-DR block chance, and the DR coefficients for block.  Yes, that’s the simple one.

Now for the tricky ones.  What does look like?

So for , we need to go further and find the change in SotR cast rate due to all potential factors – that means haste, expertise, and hit will show up in there.  We also need the change in effective incoming attack rate, which will depend on avoidance.  We’ll come back to those two later.   Continuing on, the differential ends up looking like this:

where I’ve saved you a bit of tedious algebra and simplified the form some.  Or as a textbook would say, “the derivation is left as an exercise for the reader” (man I hated when textbooks did that).  So also depends on the differentials of and , as expected.

will depend on avoidance, and it’s actually fairly straightforward, so we’ll do that first.  is the “true” boss swing timer, so that’s invariant, giving us .  Using our earlier definition of , we have:

Which relates to our fundamental avoidance quantity, dodge rating.

depends on .  So we need to find out how depends on haste, expertise, and hit. That expression looks something like this:

Where I’ve used to represent the hit cap, for hit, for dodge cap, for parry cap, for expertise, and for haste.  and are the cast rates for Crusader Strike and Judgement, respectively, before the effects of haste rating.  The first term is the HPG rate due to Crusader Strike (which can miss, dodge, or be parried) and Grand Crusader.  Since Grand Crusader grants HP on-cast rather than on-hit, it’s simply a linear scaling of our CS cast rate, so I’ve used to represent that. Note that this makes another assumption – that we don’t waste any GC procs.  That’s a fairly safe assumption in the 4.5-second CS system, though.

The second term is HPG due to Judgment, which is on spell miss, but gets contributions  from both hit and expertise anyway.  The final term is any income we might get from the Glyph of Blessed Life, but it could also incorporate any other constant income that’s unrelated to hit, expertise, or haste.

The reason I say it will look “something like this” is because I haven’t been careful to enforce hit and expertise caps in these expressions, partly because that would make the expressions a lot uglier to read.  We don’t really need to worry about that though, as we can just assume we’re not silly enough to be stacking hit or expertise past their relevant caps.  There are edge cases where this could happen (e.g. you have 7.5% hit and more than 7.5% exp, in which case exp suddenly becomes half as effective as it normally would be), but we’ll assume we’re not in those conditions (and handling that special case is easy to do in post-processing anyway). Differentiating, we have:

Or, using our definition of to simplify a bit,

.

, , and still need to be expressed in terms of their rating equivalents, but that’s fairly straightforward since they’re all linear:

And there we have it.  From here we can substitute backwards to express and in terms of the rating quantities , , and .  That’s another task I’ll leave as an exercise for the reader, but I’ll quote you the results:

We have one final task: substitute these expressions into the one for so that we have one expression that links to , , and .  This is not a pretty job, so forgive me if I skip the messy algebra and quote you the result:

….  W T F.  So much for the nicer, simpler, easier-to-understand block mechanics, eh?

This is, frankly, way too much algebra to conveniently lug around.  We’re going to need a more compact way to write this if we’re going to get anywhere with it.  So we’re going to define a few constants to help us with that.  They are:

The factors , , allow us to put our original equation for in a simpler form:

.

And the factors , , , and , which represent the block scaling factors for hit/expertise, haste, dodge/avoidance, and mastery, respectively, allow us to put our final expression for in a very simple form:

This is going to be much easier to work with.  With this expression for , along with the previously-derived expressions for , , , , , and all of the sub-factors we’ve defined in this post, we can finally start making comparisons between the different stats.

Unfortunately, that’s going to have to wait until next time, because this blog post is already much too long.  Next time (Part 3), we’ll summarize the equations we have, and start plugging in reasonable numbers to see how the different stats stack up against one another.  Then, in Part 4, we’ll use a simple Monte-Carlo simulation to see how well this analytical model holds up to a simple numerical model, which will tell us how well the assumptions we’ve made in this analytical model hold up under more realistic conditions.

Editor’s note: Since publication, I have found one or two minor errors in the calculation – mostly transcription errors that occurred, either in my hand-calculations or when converting into LaTeX format for the blog post.  I have updated the post with these corrections without annotation.

It’s also worth noting that our mechanics will be changing in the near future, according to a new forum post by Ghostcrawler.  The previous version had us gaining 25% block value and one guaranteed block for 6 seconds.  The new version will have us gaining 45% block value for the guaranteed block (total of 75%) and 20% block value (total of 50%) for the remainder of the buff duration.  I’m modeling the new mechanics, though it’s fairly trivial to convert this derivation to the old mechanics if things change down the line.

The formula for time-averaged damage taken per second (DTPS) is

is the net damage taken per second after all mitigation and avoidance effects
is DTPS before all mitigation and avoidance effects
is the armor mitigation factor, calculated the usual way
is your decimal avoidance from all sources, after diminishing returns
is the “block factor” which models blocking mitigation.

As I said in an earlier blog post, this differs from the old one-roll system because it converts a combined avoidance/block factor like into two multiplicative factors and .  In that earlier post, I gave an explicit form for the block factor: .  If we ignored Shield of the Righteous (SotR), is just your block value (30%) and is your character sheet block chance.  However, SotR throws a wrench into everything.  We can still express it in a form similar to the one given above, but with more complicated expressions for the average block value and average block chance .  And we’ll find that there’s no compelling reason to do so, as there’s a different form that gives more insight into what’s going on anyway.

To calculate , we start with the following expression:

Let’s go through this term by term.  The first term is the chance that we are guaranteed a block by Shield of the Righteous () times the amount of damage we take when that happens , where is our block value for the guaranteed block (75%).  After distributing, the second term is , which is the chance that we don’t get a guaranteed block multiplied by our block chance $B_c$ multiplied by the probability that the SotR buff is active multiplied by the damage taken during that buff , with being our block value during the 6-second SotR buff (50%).  In other words, this term represents the chance that we aren’t guaranteed a block, but block anyway during the 6-second duration of the SotR block value buff.  There’s a subtlety here involving that complicates matters, but we’ll come back to that later.

The third term is , which represents the chance that we aren’t guaranteed a block, but do so anyway without the SotR buff active.  And the final term is , which is the chance we don’t get a guaranteed block and that our natural block mechanism fails us, forcing us to take a full sized hit (damage taken = 1).  Those are the four possible outcomes of the system, each weighted by their individual probabilities.  And in fact, it’s easy to show that this expression is correct: let and equal zero, and the expression sums to 1, just as one would expect for a sum of probabilities that spans the space of possible outcomes.

With a little bit of algebra, we can put this in one of two simpler forms:

           (1)

or, equivalently

       (2)

Each expression gives slightly different intuition. The first expression says your block mitigation factor is just one minus the mitigation from guaranteed blocks minus the mitigation from non-guaranteed blocks, with an average block value based on SotR uptime . In other words, it breaks it down by the type of block – guaranteed versus not guaranteed.  The second expression breaks it down differently, by the amount of block value.  In this case, the factor is one minus the mitigation from blocks of size minus the mitigation from blocks of size minus the mitigation of regular blocks ().  The coefficients of each term are simply the probabilities for blocking each amount.

As I said earlier, we could put this in a form by defining the overall chance of blocking .  With that definition, we get the following form for :

.

But this version doesn’t do much for us – it’s no simpler an expression than (1) or (2), and it doesn’t give us any additional insight into the meaning of the terms.  So for any of our calculations, we’ll start with one of the numbered equations.

We already know , , , and from the character sheet.  All that remains is to calculate and and we have a complete analytical expression describing the new block mechanics.  Let’s proceed to do that.

Calculating is fairly straightforward. The probability that any given attack will be a guaranteed block is simply

where is your SotR cast rate, and is the incoming blockable attack rate, or one over the time between blockable attacks .  Note that this is a little different from the boss’s attack rate because of avoidance.  It’s actually , where is the boss’s “true” attack/swing timer. So we need to assume a boss attack speed to get useful results, which is annoying, but do-able. Since SotR is off-GCD, we can estimate the SotR cast rate pretty straightforwardly as your HP generation rate divided by three, or

However, is complicated  slightly if we want to include talents.  Holy Avenger is actually fairly easy since it can be modeled as a simple increases to your average HPG rate. Divine purpose is more irritating, because it’s a 15% chance on every SotR to proc the effect. So it modifies the SotR cast rate as follows:

where I’ve let be the DP proc rate in case it changes. Solving for SotR:

Luckily, , is easily calculable (analytically or via simulation) for a given rotation and haste value.  So we can get the information we need to calculate .

looks very tricky, but ends up being deceptively simple.  My first attempts were pretty ugly, involving double-integrals of a comb function multiplied by a rect function. And they were correct, but I realized afterward that the resulting expression was something I could have guessed using geometry. So I’ll give you the easy version:

The duration of the SotR buff is . The uptime of the buff is , bounded by (i.e. if the product ever goes above 1, it equals 1 because we cap out at 100% uptime).  The number of boss attacks that occur during the buff is , bounded by .  So far so good.

But isn’t the probability that the SotR block value buff is active (i.e., it’s not the uptime).  In fact, it’s the probability that the buff is active for attacks that weren’t already guaranteed to be blocked due to the other SotR buff.  So we need to account for the guaranteed blocks. The rate of guaranteed-blocked attacks is just , bounded by , and the rate of non-auto-blocked attacks is , bounded by .

To calculate properly, we need to find

or their equivalent rates. Which is:

You might notice that this expression looks questionable, in particular the denominator.  If , it looks like .  In fact, it doesn’t, because the numerator goes to zero in that situation as well.  This is why I was careful about specifying the bounds of each term earlier on – in the limit where , the term approaches its upper bound of , and the expression approaches 1.  That’s good, because it’s what you’d logically expect – if you’re casting SotR as often as the boss is swinging, the buff should be up for every attack (though note that in this limit as well, making this a bit of a moot point).

This expression for is the last piece of the puzzle, because we have all of those values already. From this point it’s just a matter of doing some substitutions and taking some derivatives.  In the next installment, I’ll make those substitutions and derive the expressions that will tell us how mastery stacks up to dodge, parry, hit, expertise, and haste.

I really liked Cataclysm a great deal, and I cared deeply about having some compelling raid encounters to finish off what has become my favorite WOW expansion so far. I especially wanted to kill Deathwing dead considering he’s been making a big nuisance of himself for the last 18 months or so. I was ready for an epic finish! So I’m going to give you my thoughts, one by one, on each of the bosses of Dragon Soul and T13. We’ll all be staring at these encounters until Mists of Pandaria, after all, so let’s chat.

H Morchok

You know, I realize that the devs know a lot more than I do about the psychology of gaming and what gamers find fun, what makes us start playing and keep playing once we’re hooked on this crack of a game. I have to imagine that encounters along the line of Morchok (and Shannox in Firelands, and half of ICC H) are part of this decision making process. They’re easy for a reason. The devs probably think, “The first encounter in the zone needs to be easy. That way once a guild starts in on heroic modes, they get that gratifying boss-dead feeling right away. Even if that guild proceeds to get stuck on the next one, at least they’ll get one dead, and feel good.”

That’s not my fun. I think it’s kind of insulting when the first heroic boss is much easier than the final normal encounter. But I’m not the target audience for Morchok. It kind of sucks to write off a boss every tier though.

H Yorsahj & Zonozz

To be honest, they were two of my favorite fights that I’ve ever worked on. They had all the things that I like in a fight. They had moving parts. They had strategies that could differ from guild to guild depending on how you chose to do them. They both had add phases that required off-boss time combined with an enrage timer that guilds were likely to see while they worked on the fight. They each had positioning checks and failure checks that would wipe you when you fucked them up. The only thing I didn’t like about these fights is that Moshne always marks me for Zonozz and sometimes stealth marks me after the fight has begun, which makes it really embarrassing when I lose count of how many black phases we’ve been through and go off and kill adds like a retard.

Some of my fondest memories of this tier involved our work on both these bosses. The early work on Yorsahj, talking through as a raid which ooze to kill on every combination, and then changing our minds as the fight got cleaner and we decided to focus more DPS on the boss. Sitting in melee chat on Zonozz talking through interrupts on the eye stalks or discussing how many adds to kill that week. Knowing that I had to move efficiently, DPS efficiently, use cooldowns smartly and use personal survivability cooldowns too. I know these were early fights, which was a shame, but I thought they were both pretty cool.

H Hagara

I actually got a sneak peak at Hagara before it went into Dragon Soul, and I was very impressed at all the moving parts that had been put into this fight. I thought it looked so very cool, and so promising on heroic! Different phases, positioning requirements that changed based on phase and a great deal of organization required before going in… it looked like a lot of fun. I thought of it as the flagship encounter for the tier, and of all the fights we would see I was most looking forward to seeing it. But it ended up being, surprise, the second easiest fight on 25. It was the Staghelm of DS. Why? Tuning. All the interesting mechanics in the world won’t save a fight when they don’t matter.

Those Hagara mechanics were a joke. They could be fucked up, healed through, cheated, and otherwise ignored even in last tier’s gear. What if the whole raid actually had to DO ice phase? What if tombs or Ice Lance really had to be handled perfectly? What if she had come with a harsh enrage timer so you had to be damn precise about how quickly each phase went? None of these things were true. She took messy and imprecise play and rewarded it after about 50% effort with a kill. She was my least favorite encounter in DS, and that’s a shame, because I thought she looked so very impressive. Instead, the best that can be said about Hagara is that she has annoying mechanics. Not hard. Annoying. And what irks me so much about Hagara is that that didn’t have to be true.

H Ultraxion

I loved this encounter. I’m not going to lie. I thought it was amazing. Sometimes there is something really compelling about a rock bottom simple encounter with one serious performance check: the enrage timer. Ultraxion was just super fun. Maybe it’s because I was DPS for the first time this tier and I loved the challenge of just being a DPS. Maybe it’s because there were little things that were not difficult, Fading Light, but that rewarded you more and more for being as precise as you could be. Maybe it’s because ret paladins were just OP here. Well, I thought it was awesome. I don’t want all my encounters to be simple but it’s really nice to always have one. And there were some moving parts on Ultrax; fading light meant you had to pay attention, and it rewarded you more and more for being more precise (and immediately punished you with death and embarrassment if you cut it too close). I even got to be in a cooldown rotation, too. I just liked it from start to finish. But I’m a DPS, and more than that, a ret paladin; Ultrax was our fight. It was our house, and we weren’t sharing with anyone but the fire mages. Blizz hadn’t nerfed Gurth yet, either. Geez, no wonder I liked it.

H Blackhorn

I remember doing this fight and immediately thinking of it as The Redemption of Gunship. I liked this fight. Which is funny, because this fight was the least melee friendly fight we did. It was very annoying to get in melee range of everything I needed to deeps, especially those drakes, and also to soak puddles. If I wasn’t extremely careful I might find myself spending half of the time in phase 1 just running around like an idiot from add to add, or standing out of range. But I respected it for that same reason. Ret had a couple really friendly fights; it’s totally ok to have a couple that aren’t so good for us. Any idiot ret can faceroll out 75% of Simcrafted dps on Ultraxion and feel like a superstar because they’re still on the top of their meter. But you actually need to have some care and precision to do well on Blackhorn as melee, precision in movement and in really paying attention to where you are. In some ways that’s almost more fun. I didn’t always succeed, but I always felt challenged. Anyways, I liked it a ton, I thought it was a pretty fun fight to do.

The bad part about Blackhorn was that it was the first of three buggy encounters. Fake fire all over the place. Invisible boss romping around killing your raid if you wiped and someone feign-deathed. Ugh.

H Spine

You can’t talk about H Spine without talking about The Nerf, so let’s discuss it. I don’t know how I feel about it. On one hand, I HATE seeing fights nerfed before we see them. I bitched and moaned so much when it was nerfed, and nerfed so hard. On the other hand, this fight was broken. The 18 second tendon burn mechanic is one of the stupidest mechanics that Blizzard has ever seen fit to place into an encounter. Blizzard doesn’t balance DPS classes around 18 second burns, they just don’t, and then they toss a fight in there that requires six burns for success? So incredibly dumb.

For the record, our kill was February 10th, the second week post nerf. We had to work hard for it, very hard but it’s almost pathetic how little work we had to put into it compared to the guilds that had slaved for hundreds of wipes before us.

We fall into a strange category because of the fact that we are hardcore in attitude yet in some ways aggressively casual about limiting the time that we pump into the game. That’s the point of raiding three nights a week– and there are other guilds like us. If you sort 3 night guilds on WOW Progress, you’ll find that not a single 3 night guild killed Spine pre-nerf. Several were close. Three of those guilds killed it immediately, on their first raid night post nerf. But no one had it before. We put three weeks of work into it, and we were the sixth US 3 night guild to take it down.

I have to wonder… Could we have done it pre nerf, without altering our roster, without alts? We raid with 4 mages, 2 rets, 3 rogues, 2 shadow priests. I think we’re all strong players who would have been precise, who would have come to put out 95%-100% of what was effectively possible. Maybe we could have done it. Maybe not.

We will never know, because Blizzard gutted the fight when they nerfed tendons by 15% and the whole thing 5% at the same time. It became doable without alt stacking at all. Basically Blizzard turned a 400 pull fight into a two-to-three week fight for a normal, reasonably serious raiding guild.

“Fixed?” “Gutted?” I’ve heard both adjectives applied to it. I’ve fought the argument on both sides. I think both are true.

Regardless of what you thought of The Nerf, I think we can all agree that Spine was a shitty fucking encounter. It was a glorified trash gauntlet with a brief, stupid, broken burn mechanic. That does not an interesting fight make. I don’t think it’s the worst encounter in DS, but it’s certainly not very compelling.

I’ll admit that I, personally, enjoy doing that fight. I get a job to do, and I generally love fights where I have a special task, and I get to kill bloods and count them and pay attention to where they are, and adjust my cleave carefully – and I can wipe the raid if I cleave retardedly, and I get to bitch and moan at anyone doing any more cleave than me. So I like it. But that doesn’t make the fight not suck.

H Madness

Frankly I don’t remember a whole lot about this encounter. Some might say that’s not a surprise because there was nothing really all that memorable about it (they’d be right, it was pretty boring). Others might remind me that our Madness kill video features yours truly running into an explosion in true Retardadin form, and then Lay On Handsing herself back to full in panic mode. I don’t know what those people are talking about. That totally never happened. I have blocked it out of my memory.

I remember one thing about Madness: Thrall dropping people. Over and over and over. That was, by far, the hardest mechanic.

We spent more time theorycrafting how precisely to jump from platform to platform to avoid losing someone on the jump than we did working on any other mechanic in this boring encounter.

Opinions varied. My raid leader was adamant that stopping (to reset your position), and then strafing was the way to go, but he admitted to us that that was just his guess. We also experimented with jumping in the middle of the platform, or jumping in specific places. We made sure we didn’t use any abilities that gave us speed boosts, supposedly those contributed to the problem. In the end, we never really came up with a system that effectively put everyone on their desired platform without inexplicably falling to their deaths. Geez, it’s too bad Blizzard didn’t put a backup plan in there, like “if the game can’t figure out where you are, default to your old platform,” eh?

As for the rest, it was pretty boring. Platforms 1, 2, and 3 were yawn. I hate encounters that are boring for 10 minutes. Why does Blizz do this? So an encounter that starts off boring is compelling design? Is that supposed to make the fight feel epic? Whatever. Platform 4 at least had a couple different failure points where you could fairly effectively wipe the raid with a mistake, and then a DPS check on the end that was there to ensure that everyone was alive. That was about it. The joke is that once you’ve killed Spine, grats on your Madness kill.

It wasn’t really the way I wanted to remember the end of my raiding experience in Cataclysm.

Conclusion: A big dragon does not an epic encounter make.

Looking back on the last 18 months of World of Warcraft, I suppose I really was looking forward to the end. The big bad boss. The final encounter. Deathwing had killed us all over Azeroth and I was ready to kill his ass dead. I was definitely, definitely ready to cap off an expansion with my favorite group of people. And to have that epic encounter consist of Spine and Madness was simply disappointing in the extreme.

Even if I liked some of the encounters in DS – even if I enjoyed doing about half of it – those last two fights were just… depressing.  Even if you count them together as one long encounter in two parts, they suck. There are no redeeming features about them. They were designed as boring fights – on paper, they’re just not that interesting. I can’t understand how Madness in particular made it past the design phase. They’re just long and repetitive. The execution was incredibly poor, too – the broken nature of Spine, the bugs that continue to plague Madness. To have these fights represent what we were working towards since Deathwing split the world wide open was just plain sad.

Recently I was reading a Wow-Insider DS Retrospective and couldn’t believe how heavily I disagreed with it. I honestly didn’t think we were raiding the same instance.

I challenge you to find one heroic mode raider who can tell you with a straight face that they thought Spine and Madness were epic. Go ahead on down to the comments and disagree if you are one of these people – I’d love to hear that someone else was less disappointed than I was. In the end, they sucked.

So the grade I’d give DS as a whole is: Mediocre.

Just mediocre. Not very memorable, with an extremely disappointing finish.

Now tell me what you thought.Did you like any of the fights in DS? Did you find that the whole thing was a disappointment like I did?  What did you think?

I’m pretty sure I know what everyone expects me to say, especially following Meloree’s really moving post last week on the demise of tanking. It would be pretty easy to say that I stopped tanking because Blizzard has made it boring, and that’s generally the commentary I get. Tank friends tell me things like, “I’m jealous you’ve switched to DPS,” or “I totally understand why you switched to DPS.” But that’s not why I switched. At least, I don’t think it was. I think I just found the spec I’d always wanted to play.

History

I have always tanked. Always. I have been prot spec since I started playing my paladin, from leveling to 5 mans to raids. Going ret never even crossed my mind. In late Wrath, I eventually picked up some offspec gear for one tank fights, and I hated it. Ret back in Wrath went like this: you had five abilities, and you pushed whatever was off cooldown that did the most damage. That was it. There was no buff management. There were no procs. There was nothing else interesting about it. It was boring. Now, tank-wise, 96969 was boring too, but in comparison, tanking was 100 times as fun: I got to move mobs around and position and cooldown either on schedule or in response to damage, and stress about getting the job right, because my mistake would mean a raid wipe. I loved the difficulty and the responsibility of being a tank. It was so much more engaging than DPS ever looked. DPS had the easy job, and I enjoyed my hard job.

I was a prot paladin. That’s who I was! It was my identity!

In T11, I joined Something Wicked and became one of three tanks.

Obviously if there were three of us, I wouldn’t just be tanking all the time. When I joined, I told Moshne I had never been ret, but I would learn if I had to. He told me that he wasn’t going to require me to have a ret spec. However, it was probably in my best interest, because I would sure be a lot less likely to sit if I had one. So I sat down to build one and eventually began to discover Cataclysm ret for the first time.

I didn’t use it much, because I tanked almost everything in T11. A three-tank roster worked really well back then. On the rare occasion that I wasn’t tanking, as promised, I rarely got sat, so I did get some offspec time. Which was good, because new-style ret was very complicated! I had a lot to learn.

The hardest fight I saw as ret was Heroic Ascendant Council. I talk about this fight a lot as being the most difficult fight in T11 for us. We decided to kill it before we killed Cho’gall or Sinestra, and it was a real pain in the ass. That fight will live in my memory as the biggest learning experience for me. It was the first time I’d encountered the particular kind of frustrating difficulty unique to fights like AC, the type of frustration that makes you want to throw your headphones at the wall because the same old shit happens over and over. I had moments where I was fucking retarded. I had a moment or two of glory. But there were just so many wipes… there is not too much more to say about that fight; anyone who did it, hated it. I hated it even more since I was offspec.

I rarely sat at all; I was there the whole time. It had nothing to do with how good I was, because I was still pretty terrible, and ret was also pretty trash DPS in T11 anyways. But we run a pretty small roster, and we had a couple of weeks of tight attendance when we struggled to throw 25 bodies at raids. Well, that is why people have offspecs. I had to step it up! I still sucked by the end of it, but damn, I learned a lot from being ret on that boss.

I don’t remember being ret much otherwise in T11. T11 was a really great tier for tanks, and I was happy. I was still a tank, just one with an offspec.

T12 and Blizzcon: Things change for tanks.

T12′s seven fights were such a disappointment after how much fun T11 had been. Several are one-tank on normal, and one is still single-tank on heroic. We three tanks still shared out the jobs pretty evenly and tried to make things fair while also picking the right people for the right jobs, but it was rough. I quietly claimed for myself the two  tanking jobs I really wanted, which were Alysrazor and Baleroc. They and Beth are the only fights I end up tanking. Three is not a lot of fights. Not at all.

Blizzcon 2011 occurred in the middle of T12, and I got to talk to a lot of devs while I was there. After I was done berating them for Rhyolith (WORST FIGHT EVER), I had to ask them: what the hell are you doing with your tank design? I’m in a three tank guild, and Firelands sucks after T11. How many tanks are we expected to run? They gave me a pretty straight answer as blues go; it’s obviously not a huge secret. T12 is the intended design in terms of raid composition. The one to two tank fight design is here to stay.

Well, I wasn’t sure what that meant for our tanking corps. Firelands was really depressing. I know a lot of people hated DS more, but I honestly disliked Firelands the most this expansion. It felt to me, especially some weeks when we were in the middle of progression and I ended up tanking just two (or even one) fight that week, that I wasn’t doing much tanking at all.

But increasingly I didn’t really have a problem with that… because I wasn’t sitting, so I was ret, and that meant more and more time to get to know this increasingly interesting spec. Ret got more and more fun as I started to understand it better and play around with what I understood.

The breaking point was H Rag. I was retribution, and once again, I was there the whole time. Unlike AC, Rag was a 400 pull boss, and also unlike AC, I was there on Rag because (I think) I had to be there. I was enough of an asset to the raid as ret that my presence was generally a good thing. That meant I was ret for the vast, vast majority of what I remember in Firelands…. and that was fine with me.

Why I love Retribution (the Cataclysm flavor) –

It’s a lot of fun. First of all you have two resource systems, and if you play ret like I do, you actually have to watch your mana so you do have to manage them both. Secondly, you have to maintain Inquisition. Holy Power can seem a little random, but once you’ve played ret enough you end up getting a feel for the heartbeat of the rotation– this is especially important when Judge generates it too, because the HP is a bit delayed. You get two wonderful procs with different results to spice up the rotation, and a gap closer attached to a core ability, and several fun cooldowns. All sorts of toys!

Ret on a target dummy is pretty interesting, but Ret in the real world so much more fun. I end up ignoring CLCret’s recommendations on a fairly regular basis. I use Consecration and Divine Plea at my own discretion. I try to time my Judgement for a movement boost, or time my movement with a Judgement boost, every time I have to go anywhere. Inquisition refreshes are something I think a lot about, too. What am I doing in the next half minute? When am I next using my cooldowns? Has anything procced right here? Do I want to hit one more button for one more holy power? Smart inquisition refreshes can make life either easier or much more annoying. Then there’s the obvious situations like building up resources for any burn moment. The list goes on. Ret is one of those specs that really rewards a lot of thinking about the entire course of the fight.

And I haven’t even talked about my favorite part: cooldowns. Back when I was really learning how to not suck at ret during H Rag, cooldown management was pretty much the most important part about being ret. That’s the whole point of being a ret – stack your cooldowns and BURN! We had five different cooldowns to time at five different times as well as a rotation change due to Heroism. I loved it. I loved it so much.

I also just generally found myself very much enjoying the role of a DPS. It’s a lot more difficult than it looks from the boss crotch, at least on heroic mode fights. Gone were the days when I was a tank and looked at the DPS core and thought, “heh, they have the easy job.” They don’t. I was more often thinking, “thank god I don’t have to do that.” Or, “I’m so glad I get to be DPS here.” DPS also die much, much more quickly than tanks when they make a mistake. I guess that happens when you don’t have a team of dedicated healers! And there is the constant pressure of the enrage timer. It was such a challenging role, and it was challenging in a unique way every GCD that I was a DPS. And unlike tanking, it remains interesting throughout farm.

I rather enjoyed it. I looked back at Firelands and it was clear to me that I’d enjoyed my time as a DPS a lot more than my time tanking. And so I began to think…

Should I maybe  ask about going mainspec DPS next tier?

But I’ve always been a tank. This was a weird thought. It took me a while to get around to it. First of all, I didn’t know if I was good enough to handle it.  I had justified a ton of mistakes to myself, and have throughout this blog post, as “It’s only my offspec” or when I did well, “That’s pretty good for my offspec.” Could I handle it without the cushion of offspec to give me a convenient excuse for messing up? So I first went to our mainspec ret Warden, someone you paladins have probably seen on Maintankadin– a friend whose judgement I trust completely. He was all in support once I asked his opinion, and so I was quite excited. I still had more to learn, but doesn’t everyone?

Then I went to the other tanks. I was aware that if I switched to mainspec DPS, they would be most heavily affected because I’d be removing any opportunity for them to sit back and be offspec. Our warrior, Omegal, assured me he was fine with always tanking, and I believed him. I was more concerned about our DK Shiramune.  Apparently before he became Something Wicked’s unkillable beast of a DK main tank, he had a previous life in Wrath as an ass kickingly parsing DPS. Since I often heard about what a great DPS he had been, and since I knew he quietly parse chased as tank spec, I certainly wanted to make sure I wasn’t taking any opportunities away. I probably asked him on about 100 different occasions, just to make sure he was telling me the truth instead of being nice. He pretty much reassured me that he really enjoys tanking and has no desire to do anything else. I eventually believed him. DK tanks appear to have the most fun after all.

Reassured that my fellow tank chat bretheren would not be unhappy if I took all the DPS opportunities for myself, I next went to my raid leader. Moshne is rarely shy with his opinion. Considering he is the person who has to put the raid together each evening, I was certain he’d tell me if the option was on the table at all, and if so, whether it would be more effective (or very stupid) to run either 3 tanks or 2 rets next tier.

Unfortunately for my peace of mind, he refused to make a call. I had a lot of conversations with him and in a pretty impressive feat of topic avoidance, he managed to never tell me what he would prefer I did once. He did talk to me at great length about what I personally wanted, which was very useful coming from a friend, a raid leader, and another hybrid with two raiding specs. But he refused to give me anything resembling a leader-like opinion on what I should do next tier. I straight out asked him what would be better for the raid and guild, several times, and he just countered it with, “Well, what do you want to do?”

Very unhelpful. What I wanted to do was not make the decision.

So I was left alone. I put it off for as long as I could. Change is scary for me. But in the end, I had to make the decision and I chose to go ret for real. No one had given me a reason not to, and I could handle it. I might as well be true to what I thought I wanted to do.

I switched for Dragon Soul.

I was immediately nervous in my first raid as a mainspec DPS, but that faded away in about five minutes. Being ret felt exactly the same as Firelands, minus the switching specs all the time and someone bitching about auras or buffs being missing, plus faster gear.

Then the most lovely thing happened. RNG smiled upon me and lo, it was good. I managed to pick up 4pc tier paladin gear, Gurth, and the trinket in the very first week or two of raids. Wow. And let me tell you, Ret got some buffs… it got some pretty damn amazing buffs. With all that gear so very early, and everyone else still sitting in Firelands gear,  well, I wasn’t holding back the raid’s DPS at all and that was a very nice feeling. Everyone else soon scaled up there as they got their hands on some gear too, but those first few weeks were a lot of fun and I definitely gained a lot of confidence.  And with ret parsing quite well in those early days as well as being pretty optimal for several fights, it has suddenly become a lot more reasonable to keep two on the roster. One day fairly recently while we were working on Spine, someone told me that our roster was naturally stacked because we ran two rets – because, who does that? I laughed for a while…

A couple weeks in, Moshne says in vent, “I’m glad you went ret. That’s what I wanted you to do all along.” and went on to give exactly the reasons I’d asked him about before, like, how dumb it would have been to divide tank gear up among 3 people, and how much more effective it was to have 2 tanks, etc.

I was pretty mad. “I WANTED YOU TO TELL ME THAT THE WHOLE TIME!! WHY DIDN’T YOU JUST SAY THAT IN THE FIRST PLACE?!”

“Of course I didn’t tell you… If I told you what I wanted you to do, you would have just done that.” He was very proud of himself for carefully not revealing to me what he actually wanted me to do. Or he was just trolling me… sometimes I just can’t tell.

But I loved it. It was so the right decision. I actually had no desire to tank anymore at all, once I switched – I have gotten over it since then, and I’m back to being a useful hybrid, but for a month or two I was so very, very happy to be mainspec DPS that I didn’t even want to look at my tank set. I am pretty glad that everyone else was patient with me, especially our other ret paladin who (gasp) had to use his tank set once or twice and helped me be selfish and not-tank.

I wonder about why I switched sometimes.

In some ways I got really lucky. I was lucky that neither of my other fellow tanks really had a burning desire to DPS. I was lucky that they also didn’t want me to be tank to take some of the stress off (I live in fear of one of them missing a raid). I was lucky that nothing in DS really required a paladin tank, or sucked with a DK or a warrior. I was lucky that, thank god, ret got the buffs it needed to be a competitive spec, competitive enough to run two. I was lucky to be in a raid with a ret paladin who carefully taught me how to be a good ret for a year, because I absolutely needed the company and the help. I’m pretty happy all those things ended up being true so I could play the spec I wanted to play.

It was definitely the right call, no question about that. But sometimes I wonder– was it because Ret was the spec I’d always meant to play? Or have the changes to tanking had more of an impact than I think they have? It’s no coincidence that I was half-and-half in Firelands and got to compare DPS and tank.

I’m not sure. I am only sure of one thing: I’m a ret paladin now, and I love it!