Hey all, I’m Swol, the main theorycrafter for Ask Mr. Robot (AMR).  Most of you don’t know me by name, but I’ve been posting theorycraft here and there lately for interesting topics I run across when I have something useful to say that isn’t common knowledge yet.

Recently, some Feral Druid theorycrafters suggested that AMR was bad for feral druids, in general. When we asked them why they had that opinion, a big topic that came up was energy pooling.

In this article I am going to examine the theory behind energy pooling for feral druids and go into detail on how to test that theory. To do this, I will use the default Action Priority List (APL) found in the nightly SimC build and explain how it works.

And, I will also use an APL that I have developed which uses a different structure and, specifically, does not pool energy before using Rip. After this analysis, I will then provide a detailed comparison between the SimC simulator and AMR simulator for feral druids so that theorycrafters can comfortably trust and understand both tools.

The APL I created does NOT pool energy.

There has been some confusion on this and some vocal detractors have been spreading a rumor that my APL does pool. Look in the “Pooling Tests” section below for an explanation/proof that my new APL definitely does not pool energy.

Energy Pooling

This is a broad term that refers to any point in time where you could take an action, but instead choose not to in order to save up energy. As long as you don’t cap your energy, you won’t necessarily lose damage, and sometimes there can be a benefit to saving up energy. The document that I have been referred to multiple times is this document created by Guiltyas.

This document suggests that the optimal way to play a feral druid is to pool energy before using Rip. This allows you to immediately use 3 combo point generators following Rip, resulting in the highest possible uptime on Ashamane’s Rip (obtained via the Ashamane’s Bite artifact trait). A direct quote from the document on this topic:

“With the advent of Legion and the introduction of the ability “Ashamane’s Bite”, pooling is now crucial to optimal damage. Ashamane’s Bite has a 10% chance per generate cast (Shred, Rake, Moonfire, Swipe etc.) to proc an additional rip that mirrors the duration and power of your existing rip.

Therefore, your goal is to use generators quickly and get up to 5 combo points while your current rip duration is high, gaining a higher typical uptime of Ashamane’s Bite. While you cannot control the chance of Ashamane’s Bite occuring, by pooling you make the most of it.

Pooling to 100 energy will give you 3 chances to proc Ashamane’s Bite (once at 15s at the Rip’s application, another at 14s, then again at 13s), while spamming and not pooling would give you your first proc chance at 12.5s of the Rip.”

The key assertion I want to test is the idea that pooling is “crucial” to optimal damage. I think it is fairly obvious that playing like this will result in higher Ashamane’s Rip uptime – but how important is that to overall damage? Does overall damage increase? If so, how much? How much does the uptime on Ashamane’s Rip increase?

Quantifying what is “crucial”

One gray area we are going to get into with this discussion is how to quantify “crucial”. If APL A shows 600,000 DPS in SimC and APL B shows 605,000 DPS in SimC, is the play style of APL B critical to getting optimal damage?

To have any meaningful theorycraft discussion, we need to be a little honest with ourselves. No model of the game is perfect. No player is perfect. The difference between 600k DPS and 605k DPS is performing 1 or 2 sub-optimal actions over the course of an entire 5 minute fight.

My general guideline while doing theorycraft is that anything less than a 1% difference in simulated DPS is, for all intents and purposes, equivalent. There is no possible way a player could play the game enough to actually verify a 1% theoretical difference. Really, it would be impossible to empirically verify a 2, or even 3% difference, as the standard deviation in simulated DPS for a feral druid is between 4 and 5%.

But I know that simulation has become a sort of meta-game in WoW, so for the sake of discussion we’ll be optimistic and assume our models of the game are of a high enough fidelity to say that differences of more than 1% are meaningful (even though I’d personally extend that to 2%).

Pooling tests

I have created an annotated version of both the SimC APL and my final APL in this document, for those interested in the details, but not necessarily well-versed in SimC or AMR syntax:
Annotated Feral APls

By request, I will clarify the main difference between the two APLs, and why I am calling the SimC APL “Pooling” and the AMR APL “No Pooling”.

The SimC APL specifically pools energy before using any finisher. The only time a low energy Rip could be used is if Rip is not ticking or Rake will fall off in less than 1.5 seconds. The only time a low energy Savage Roar can be used is if Rake will fall off in less than 1.5 seconds. Ferocious Bite is held as an energy dump and used only when in danger of capping energy or when you have Berserk or will soon use Tiger’s Fury.

The Swol/AMR APL places no energy restriction on using Rip or Savage Roar. The only energy restriction placed on Ferocious Bite is that you must have enough for a max damage Ferocious Bite (50 Energy or 25 with Berserk). Ferocious Bite will not be used unless there is more than half a Rip left on the target. So, there are a few times when some passive, incidental pooling will occur if you have more than 12 seconds left on Savage Roar and less than 8 seconds left on Rip, but more than 4.8 seconds left on Rip. It will wait until Savage Roar drops below 12 seconds or Rip drops below 4.8 seconds to act. On average, this happens 2 or 3 times total in a 300 second fight.

If you want to convince yourself that no energy pooling is occurring in the Swol/AMR APL, add this line after Ferocious Bite:


That line will ensure that you never sit on your combo points for any reason. In those 2 or 3 rare cases where the APL would have waited, it will instead refresh Rip early. It doesn’t change the damage of the simulation because the case in which you would actually wait is so rare that it falls beneath even 0.1% margin of error.

Some confusion was being caused because I had added a line to my APL that was pooling energy once in a while when the conditions for Rip and Savage Roar were not met. I have removed that line from the APL and updated all of the tests in this blog post using the updated APL in the config file below that definitely does not pool energy.

For these tests, I’m going to use a 300 second patchwerk style fight with a 12.5% fight length variance. One of the largest hurdles for Theorycrafters working on APLs and comparing them is accidentally using different settings. For this reason, I have included config files for my simulations that include all of the relevant options, so that you can recreate the results.

  • Simulation using default Feral SimC APL (Pooling): 680,002 DPS (config file)
  • Simulation using default Feral Swol/AMR APL (No Pooling): 696,153 DPS (config file)

Since Guiltyas has been openly and vocally anti AMR and anti Swol’s Feral APL, I used his character for this first set of simulations. As we can see, Swol’s APL is simulating to higher damage. The DPS increase over the default SimC APL is about 2.4%, so, we’re going to consider that in the range high enough to take notice.

The theory proposed by Guiltyas is that Ashamane’s Rip has made pooling crucial to optimal damage. The SimC APL gets 41.2% Ashamane’s Rip uptime, with 95.7 ticks. The AMR APL gets 40.1% uptime with 93.6 ticks. It is tough to say in this case if pooling has actually created any noticeable difference in the uptime. So, now we need to work backwards and start stripping out some variables.

That set of gear has the 2 and 4 piece T19 set bonuses and two legendaries. The Chatoyant Signet and the Wildshaper’s Clutch. Also, the Stabilized Energy Pendant could have some effect as well. Lets do the same test, but take out all of these “special” effects.

Pooling tests with special effects removed

The new set of gear can be found here.
(I have the original gear commented out, so you can add/remove items for the subsequent tests easily.)

  • Simulation using default Feral SimC APL (Pooling): 620,925 DPS
  • Simulation using default Feral Swol/AMR APL (No Pooling): 617,847 DPS

The DPS difference here is about 0.5%. This is so close that the two APLs could be almost considered equivalent. But, I want to note the difference between Ashamane’s Rip.

  • The SimC APL result has 17.98 million damage with 38.4% uptime.
  • The Swol/AMR APL result has 17.25 million damage with 36.6% uptime.

That is a 2450 DPS difference (less than 0.5%). It could account for the difference between the two APLs, but, there are other slight differences as well. The SimC APL gets a little more Rake damage on average, but less Shred Damage. The differences are extremely minor – 2 or 3 extra Shreds vs 1 or 2 Rakes with better buffs. Overall, the differences are so small that we get back to my discussion above about what is really significant when looking at simulations.

One statement that I will venture is that pooling energy does not appear to be “crucial” to optimal damage. And, even if it were, Ashamane’s Bite is not the reason for it.

Pooling & special effects isolation

To be complete, we’ll look at some of the special effects in isolation and combination.

Adding just legendary ring back in:

  •  SimC APL (Pooling): 630,107 DPS
  • Swol/AMR APL (No Pooling): 634,381 DPS

We see a 0.7% difference in favor of not pooling. So, there is a chance that having such a high energy pool to begin with is making energy-pooling lose some value. I did some testing with this item, and found that you could be more aggressive with Ferocious Bite usage. In my APL, I have accounted for the item specifically and allow FB to be used as long as you’ll do max damage and more than half the duration of a Rip and Savage Roar is remaining. UPDATE: I not longer treat Ferocious Bite use differently depending on legendaries in the AMR APL.

Now lets add the set bonuses back in, but remove the Legendary:

  • SimC APL (Pooling): 654,745 DPS
  • Swol/AMR APL (No Pooling): 652,684 DPS

That’s a 0.3% difference, so the set bonuses don’t seem to affect the relative value of the two APLs.

With just the legendary hands on:

  • SimC APL (Pooling): 641,608 DPS
  • Swol/AMR APL (No Pooling): 642,962 DPS

Almost no difference, so this item might also favor less pooling very slightly. This makes some sense, since you can get back up to max combo points more quickly and avoid awkward Rip and/or Savage Roar down times.

Both legendaries, no set:

  • SimC APL (Pooling): 646,516 DPS
  • Swol/AMR APL (No Pooling): 658,413 DPS

That’s a 1.8% difference. It looks like the combination of these two legendaries is enough to make using the non-pooling rotation slightly more optimal.

Comparing APL modifications


The fact that the legendary hands let you build combo points up faster rewards a greedier use of energy, combined with slightly higher Shred usage, which is buffed by the 4 piece set bonus, possibly. The differences are so small that pinning down an exact reason for the difference is going to be difficult (or impossible). But, since the damage is so close, I’m fine with calling the two APLs equivalent for any practical purpose.

The important take-away here is that pooling to high energy before using finishers is unnecessary. It is not detrimental, but, it is also not “crucial” to optimal DPS.

Are stat weights affected by the two different APLs?

And, now, one final test: Do you get different scale factors using the different APLs?

SimC APL (Pooling):

Agility: 17.11
Mastery: 13.74
Versatility: 13.13
Crit: 12.58
Haste: 11.03
Error is 0.72

Swol/AMR APL (No Pooling):

Agility: 18.59
Mastery: 14.30
Versatility: 14.30
Crit: 13.26
Haste: 11.94
Error is 0.74

There is no difference here outside the margin of error. You won’t get different gearing choices between the two APLs. If you are wondering why you will often see different stat priorities using the AMR defaults than when creating stat scale factors with SimC, this article by Yellowfive explains the differences between stat weights and AMR’s machine learning – as well as delves into the history of stat weights and what SimC and AMR are actually calculating.

So, what IS crucial to Feral DPS?

A good way to test that is to start with a barebones APL and then build it up with the extra conditions until we find what truly matters. The barebones APL would simply maintain your DoTs and Savage Roar. I have found that the most important optimizations are:

  • Replacing weaker Rips with stronger Rips.
  • Spending combo points to refresh Savage Roar early instead of spending them on Ferocious Bite.
  • Allowing Rake to be refreshed a bit early with Bloodtalons up.

There are many more “micro-optimizations” to the APLs that will interest players, but, if your damage seems really low as a Feral Druid, look to those points first.

In before someone gets really mad: If it wasn’t clear up to this point yet, I’m not suggesting the default SimC APL that uses pooling is bad. I’m not suggesting that pooling energy as a feral druid is a bad way to play. I’m suggesting there is another way to play that is just as good, and, maybe with certain legendaries it is actually slightly better when you don’t need to save up energy for an add spawning or something of the like. Regardless, the two styles are close enough in value that a skilled player performing either perfectly will not be able to do enough empirical trials to determine a clear winner – this is why we use simulators.

Rake ticks, a secondary topic

Let’s take a quick look at one more statement from the notes I have been referred to in the link at the top of the article:

“If you have 5 combo points and are pooling but your Rake will fall off in 1 second, then you would wait until your Rake falls off and then immediately Rip and Rake. You would not lose ticks during this period because Rake deals direct damage as soon as it is applied and the tick time of rake is greater than your 1s global cooldown.”

You shouldn’t do this, and the SimC APL does not do this (and my APL doesn’t either). The DoT portion of Rake and the direct damage portion are separate. It doesn’t “tick” immediately, it does direct damage on cast, and applies a DoT. If you let the DoT fall off, the tick timer gets reset and you will lose fractional amounts of uptime and, incrementally, ticks.


Rake is ticking, ticks at time 8.0. It will tick one last time at 10.0. You are pooling for Rip. If you use Rip at time 8.9, then Rake at time 9.9, Rake will do direct damage at time 9.9 and refresh the Rake DoT. Rake will tick again at time 10.0 and last until time 20.0, ticking every 2 seconds.

If instead, you wait for Rake to drop as is recommended in that document and use Rip at time 9.1, then Rake at time 10.1, Rake will tick at time 10.0, drop off, do direct damage at time 10.1 and then tick at time 12.1. It will last until time 20.1. You have now created a 0.1 second gap in your Rake uptime.

There is no benefit to letting Rake drop – you will just create these small gaps in your Rake uptime based on how closely you can react to Rake dropping. Refreshing a DoT never makes you lose ticks unless you refresh outside of the 30% “pandemic” window. Letting a DoT drop always makes you lose uptime/ticks over the course of the fight. This is a very minor point, but, it illustrates how even good players who can get top parses don’t always understand every detail of game mechanics. Note that whoever wrote the SimC APL does not allow Rake to fall off while pooling for Rip. There is a condition on Rip to cast if Rake will fall off before the end of a Rip/Rake combo, avoiding the small gaps in uptime described above.

Comparing SimC to AMR

Simulators are models of World of Warcraft. A simulator has a lot going on under the hood. Somehow, the simulator needs to decide what action to take next based on an APL. There are a lot of complications involved in that process.

When do you check what action to take next? What information is available to you when you make that check? Do you mimic human limitation on that decision process? How do you advance time in the simulator?

Those are just a few of the questions that need to be handled. SimC and AMR are not identical models of the game! If you use the exact same APL in both simulators, the final DPS number will not be exactly the same.

This bring me to my first and most important point: The final DPS number that a simulator gives will never be the exact same number you would get in game.

Comparing the final DPS number from a SimC simulation to the final DPS number of an AMR simulation is only useful on a coarse level. If they are, say, 5% different – then that indicates there is likely a problem in one or both of the simulators. If the final DPS is 2% different… that could mean nothing at all. You then need to look at each ability and how much damage it does under different conditions, how many times it is used, etc.

As an example, lets look at the APL I created for feral druids and the first simulation from this article:

  • AMR APL in SimC: 694,863 DPS
  • AMR APL in AMR: 685,500 DPS

Same exact APL, slightly different results. Why? SimC will always get a couple more actions off compared to AMR. This is because we designed the AMR simulator to make decisions more like a human is required to make them.

AMR & SimC decision timing

AMR makes the decision about what action to take slightly before the current global cooldown is finished. Players have to do this in-game to avoid gaps between abilities. So, sometimes an edge case will be encountered in which SimC is able to choose an action based on information that would be unavailable to a real human player. The effect is extremely minor, but, it exists and will add up over the course of a simulation.

Energy-pooling rotations in particular work slightly better in SimC. Human players cannot use abilities at an exact threshold of energy. If you are waiting for, say, 100 energy – a human cannot and does not act at exactly 100 energy with any consistency or reliability. They will be a little over or under. In the case where the energy threshold is required to take the action (like waiting for 40 energy to Shred), a human will always be a tad “late” since you cannot queue up that action prior to having 40 energy. SimC will use that action exactly when you have 40 energy every single time without fail. Small things like this cause differences in the final DPS number. But, it doesn’t really affect theorycraft.

If you do the exact same set of tests I did above in SimC using AMR, you get the same results!

This is the SimC APL (Pooling) translated to AMR. Note that this only works for single target right now. Making this work exactly as written in SimC for AoE will take some more work, and will possibly be an article for another day.

This is my default (No Pooling) APL.

And, here are the tests for reference:

Full Gear:

No Special Items:

Just the ring:

Just the hands:

Both Legendary, No Set:

The final DPS numbers are slightly different, but, who cares? We don’t use simulators to tell us exactly how much damage we will do – we use them to figure out the best way to play and what gear to use. Both simulators are giving consistent results for those questions that really matter.

The other major hurdle is setting up a simulation that exactly matches between SimC and AMR, as far as settings, consumables, etc. This is the main reason I see some haters out there saying AMR is terrible, etc. They just aren’t setting up an apples to apples test! It’s hard. AMR has a nice GUI to make it easy to set up the simulation you want. SimC doesn’t. Confusion ensues. You just have to be very careful when setting up your simulation to make sure everything is the same.

Once you have it set up, there is also the issue of sharing the results. I constantly see people posting images or screenshots of SimC results. That gives us no way to recreate those tests, check the APL used, see what settings they had, etc. This is why I included config files in this article that include my SimC settings. So often I am seeing people post up a result that proves or disproves a potential theory, but then they offer no way to recreate that test. 

AMR was designed with easy sharing in mind. Each simulation result creates a unique link that is stored in our database. You can view that report at any time and share it easily with the url, as I did above. That report stores an exact snapshot of all of the game mechanics and the rotation at the time of the simulation as well. You can click on any spell or effect in the report to link to a wiki page that is a snapshot of its implementation at the time of the simulation.

AMR & SimC collaboration

I specialize in simulators and creating rotations for simulators. I have created rotations for every single spec in the game and have contributed to the “default” APLs in SimC for several specs. There is a common misconception that AMR is in competition with SimC. SimC is an open source simulator that I have been using for years.

The work I do and AMR in general is not diminished in any way by the existence of SimC – there is no reason for us to compete with the project. We collaborate regularly with people working on SimC. We share our findings with the developers of SimC, and they often share their findings with us as well.

The end result is more accurate simulations for the entire community. Which simulator you use doesn’t matter to me. As you can see, I did the analysis in this article using SimC, which I’m perfectly comfortable using. I developed my APL entirely using the AMR simulator, since that is what I work in the most, and then translated it to SimC – and observed the exact same results.

A good example of collaboration was this article itself. When the topic of energy pooling and Ashamane’t Bite was brought up, Guiltyas pointed out that we were letting Ashamane’s Rip proc at the full duration of Rip instead of the remaining duration, which would devalue his energy-pooling theory. He was right, so, I looked at some logs and fixed it up to match how it works in-game now. (It actually was proc’ing at full duration at one point, but blizzard changed it.)

As I did that, I looked at SimC’s implementation and noticed that it was allowing an extension of the Ashamane’s Rip via the 30% (pandemic) refresh rule if it proc’d while already active. The game actually clips it. This resulted in SimC’s uptime being a bit too long as well. After some perfectly civil interaction with Pawkets, he fixed it up in SimC and now both simulators are matching the game.

Good result for everyone.

One last item: If pooling energy doesn’t decrease damage, why not just change AMR’s default rotation to pool energy? Why go against the grain? Who cares, right? It would make the people who hate AMR really happy to hear me just cave and say they’re right, I was wrong, please forgive my small theorycraft.

This comes down to what I am using the simulator for. I’m not just doing one-off simulations or very focused stat scaling. I am running millions of simulations to back up a combination optimizer used by over a million people. Pooling energy is expensive in a simulator. My APL runs twice as fast as the SimC APL, gets the same damage, and picks the same gear. For my purposes, it is better. For my users, it is also better, because it would cost me twice as much to run people’s simulations with the pooling APL as a default, and make their custom gearing strategies take twice as long. People who want to use that play style can choose it, but there is no practical reason to default to it.

In conclusion, pool energy if you want to, or don’t! It is not crucial to Feral DPS. Use AMR to do your Feral theory, or use SimC. SimC and AMR are completely consistent when it comes to simulating feral druids; you will find the same results either way. In a perfect world, this article was convincing enough to put an end to the anti-AMR sentiment in the feral discord community, but I’m not known for my eloquent and persuasive writing, so I won’t get my hopes up TOO much.