Part 2 in this series looks at how boss mechanics and phases get incorporated into a healing simulation.
- Part 1: Intro: Simulating healers & the factors that need to be taken into account
- Part 2: Boss fight mechanics & raid damage: how that affects healing models
- Part 3: Modeling actual healing. This is where we answer the BIG question: how do you sim healers?
- Part 4: Simming different heal styles & theorycraft
As a real (human) healer, you react to your environment. If the raid takes a ton of damage all at once, you use a big AoE cooldown. If a tank takes spike damage, you use an instant heal. If no one is under immediate danger, you HoT a few people or use small, mana efficient heal.
Every time you fight that boss, it seems like chaos. However, boss mechanics are very predictable and happen on a specific timer. That means it is easy to model into a simulator.
Each attempt on the boss feels chaotic because who gets hit and how many people get hit changes on each attempt. Some people run out of fires quickly, others don’t.
Our healing simulations can account for all of this. Below are some examples, but everything can be customized since the simulator is controlled by the open-source wiki.
Defining boss mechanics in the simulator
This is best explained by example. Let’s take a common boss mechanic where someone is randomly targeted to take a lot of damage, and that repeats on a timeline.
To create that spell in the simulator, I’d have to designate a target, when it happens, and how much it hits for. Not so bad, right?
To make that work, I would program the following variables into the boss script:
- Target: 1 random player, melee or ranged
- Time: target someone 15 seconds into the fight and repeat every 20 seconds thereafter, until phase two.
- Damage: 50% of ally health
To continue this example, let’s say some raid-wide damage happens at the start of phase 2. There are a few things I would program differently:
- Target: entire raid
- Time: start of phase 2
- Damage: 70% damage multiplied by a random variant (to account for differing health pools)
- Event type: Predictable AoE
Notice that the ‘Event Type: Predictable AoE’ flag shows up. This is important because it lets the simulator act like a human would, and it holds your big AoE heal until this event happens.
While the Single Target spell is predictable on a timeline, we don’t know who it will hit, so as a healer, it’s not possible to plan ahead. But for something like the AoE event, healers can plan ahead.
Sometimes it matters where each player is – maybe they take more damage from a mechanic, or maybe it affects the healing they get. The simulator accounts for both.
For example, sometimes when the boss casts an AoE spell, players take less damage the further away they are (like the transition phase for Garothi). In the simulator, we can program melee to take more damage than ranged if we want to assume they don’t run as far away. Or we could add an even greater variance in damage formula to account for some people running really far and others not so much.
In another example, some healing spells heal a group of players in a targeted area. We can define the number of players in an area and how far apart they are spread out.
Tanks also get special treatment in the simulator
Tanks are one of the most important targets to keep alive since a wipe is very likely if one goes down. So they’ve earned some special logic in the healing simulations.
Regular boss mechanics are easily programmable, like auto attacks and other single-target hits that focus on the tank instead of the rest of the raid. But let’s look at something a little more tricky and life-threatening.
Let’s say a boss applies a stacking debuff that causes the tank to take bigger and bigger hits. The tank starts to take critical, life-threatening damage at 4 stacks, but can’t swap with the OffTank until 6 stacks. Here’s how I’d program that into the simulator:
- Target: tank
- Time: start at 10 seconds
- Repeat: stack debuff every 3 seconds
- Max stacks: 6 (tank swap)
- Damage: 15% of tank’s health per stack
- Event Type: Tank
You might recognize the “Event Type” flag from the AoE example. This time, it is telling the simulator that is a predictable mechanic for the tank, who will be taking a large amount of damage. This lets the simulator plan ahead and pre-HoT the tank before she reaches 4 stacks and then gets ready to pop cooldowns and use big heals until the tank swap.
But what about that guy who stands in fire?
We all have a firestander on the team, don’t we? (I admit, I’ve stood in my fair share of fires, no judging here!) One common concern regarding healing simulations is, “You can’t predict when someone will stand in a fire.”
That’s true, you can’t predict it. Neither can a simulator.
So both humans and computers are in the same boat… neither can see the future. But we can simulate the chance of this happening, which would looks like this:
- Create a damage effect in the boss script – let’s call it “Fire Patch”
- Give Fire Patch a chance to target someone
- Once someone is targeted, give Fire Patch a chance to either do damage, or not do damage (to simulate someone who moves out of it). This could be adjusted to the average your teammates tend to stand in fire.
There’s also one more important thing to consider: we use healing simulations to determine what talents to use, what gear to pick, and which stats are best. And all of those things have to be chosen before the fight begins – you can’t change talents mid-fight to cast bigger heals on a fire stander. You can’t magically change all of your gems and enchants to haste mid fight so you can spam heals on a tank who’s about to die.
We have to make some decisions before the fight begins.
My advice is to choose one of the following strategies ahead of time, then use the simulator to account for that. For example, you might want to pick talents and gear assuming one of the following…
- Your team will execute the fight really well
- Some people on your team will mess up, but nothing drastic
- The number of fire standers in your raid will drive you crazy
If you pick the first option, you might end up with gear that does the most overall healing. If you pick the last option, you might end up with gear that has really high burst healing but not as much total throughput. You could even do something crazy and have one of your healers on the team gear assuming the worst, and everyone else gear assuming the best or somewhere in between. That way, if someone does take a huge spike in damage, you have a healer equipped to cover it.