by Mike Shea on 24 July 2017
Typical battles in D&D have a group of characters, usually four to six, fighting a similar number of monsters; from one to maybe twelve or so. What if we want to run really huge battles where our characters face dozens, maybe hundreds of foes? How do we figure out all the math without rolling forty 1d20 rolls?
Page 250 of the Dungeon Master's Guide gives us a set of guidelines for running large amounts of monsters against a group of players. We can simplify things by using the calculator above. This form helps us determine how much damage a specific character will take when that character is attacked by a large group of creatures.
Likewise, there are times when characters might cast spells or use effects that forces a large group of monsters to make lots of saving throws. We can use the same form to figure out how many monsters will make their save when the monster group is hit with an effect that forces a saving throw.
This abstraction for mob attacks and saving throws works well for large groups of monsters but what about tracking the hit points of the monsters in the mob? Is it really fun for melee characters if they can only attack one crawling claw at a time? Why can't they sweep away huge swathes of the things? How the hell do we efficiently track damage inflicted to thirty six ghouls?
We can steal the mook rule from 13th Age for this. Whenever the character inflicts damage to any one creature in a mob, any extra damage beyond the damage that drops a creature to zero hit points will carry over to another mob. If, for example, our fighter cleaves into a mob of crawling claws, inflicting 12 damage, he kills six crawling claws since each claw only has two hit points.
Obviously area attacks will be particularly effective against mobs. Since we're not likely to have one hundred crawling claw miniatures on a grid, we'll have to estimate how many monsters in a mob is hit by any given blast. 4x the number given in our guidelines for theater of the mind combat is a good start; about 16 for a fireball, 12 for a lightning bolt or burning hands. You can choose more or less depending on the circumstances and any bargaining ("sure, you can hit 30 of them but you have to drop the fireball on the whole party").
Many times, an area attack will kill any creature within the blast outright but sometimes we might actually have to track the damage done by an area attack. If the damage of a blast on a successful save is less than the amount of hit points of the creatures in the mob, we'll need to see how many in the mob makes their saving throw, as mentioned above.
If the creatures within a mob have hit points remaining after they take the damage of the spell, we can track it as we would normally.
If we want to simplify our damage tracking, we might use a hit point pool, another trick from 13th Age. Instead of applying damage to each creature individually, we can total the amount of damage the entire group within the blast took and figure out how many monsters that damage would have killed. For example, we're in a battle with twenty ogres (59 hit points each). Our wizard fireballs the ogres. We figure, based on the arrangement of the ogres, that he can hit sixteen of the twenty. He rolls his damage and it comes out to 30. 75% fail their saving throw (twelve of the sixteen). 12 times 30 (those that failed) is 360 plus 4 times 15 (those that saved) is another 60 for 420. The number of ogres killed by the blast is seven with seven damage remaining to one of the survivors.
Of course, this requires a bit of abstraction to explain why the other nine didn't take any damage even though they were within a fireball. That's the price of a hit point pool. If you plan to use it, its best to pull back the curtain and let the players know that you're using it, why you're using it, and how it works.
When we track this we track the number of monsters that are still alive and how much extra damage that group has taken. Any time it takes more than a single monster's hit points worth of damage, one of the monsters dies and we track the remainder. If enough damage is inflicted to kill more than one, we keep removing monsters and subtracting their hit points from the damage amount until the remainder is less than a single monster's worth of hit points. Thats the damage remainder.
If all of this seems too complicated and you want another approach for handling battles against a huge number of foes, you can go with the method of reskinning a larger monster into a mob of smaller ones. We talked about this previously in Creating High Level Swarms in 5th Edition Dungeons & Dragons. The short version is that you take a simple higher CR monster, like a giant, and describe it as a swarm of whatever monster you intended. You give it a couple of "swarm" traits to make it act more like a swarm and you're all set.
The Blog of Holding figured out that these mob rules can work well for mass combat as well. Using hit point pools for groups of monsters and using the mob damage and saving throw calculator, we could have a war between 100 skeletons, 50 guards, and 20 elven scouts. Each round, damage is applied to the group, so many are killed, and the amount of damage they inflict to the other side is reduced. We can take some lessons from the Unearthed Arcana Mass Combat Rules and have all of the damage applied at the same time rather than one group going before another to simulate the entire battle taking place. Personally, I'm not a fan of the rest of the UA mass combat rules but the mob rules work well in their place. With this system you could, for example, have an ancient red dragon fight one hundred hundred knights.
However we choose to deal with running large numbers of monsters against our group of characters, we'll have to make some compromises to abstract the battle. Either we're averaging out the number of hits a group of creatures will succeed with, we're adding significant amounts of time rolling for each creature, or we're bundling the creatures together into a bigger swarm-creature. None of these methods are perfect and its up to you and your group to find the method you all prefer.
Give them a shot.
Send feedback to email@example.com.