A Walk in the Dark A look in to the mind of an RPG designer


The 11th Skeleton

With the release of the Dungeons and Dragons 5th Edition Starter Kit and Player's Handbook, I have decided to convert my long languishing adventure "The Coming Dark" to 5E. But, unlike other publishers who will remain nameless, I am not going to rush it out there, and no one's going to see a thing about it until (1) the licensing options are given, and (2) the Dungeon Master's Guide is released.

That being said, I have started to try and figure out how 5th Edition works in terms of creating adventures. In 4E, creating balanced encounters was rather simple because everything was equally balanced - given an equal level, five monsters were an even match to five PCs - but that's not exactly the case any more. Now it's more like 3.5E and earlier versions, where a monster's difficulty is reflected in an obscure "Challenge Level" which is extremely hard to calculate. I mean, after you stat up a monster how do you know what CR Challenge Level to give it?

That led me to wonder about balance in general, specifically how balance is determined. 5th Edition had an unprecedented amount of playtesters, so they had access to a variety of groups that could test and retest things in the hopes that they could determine what is balanced and what is unbalanced. But there's an inherent problem with that: not every group is the same, and not every player is the same. If an exploit exists, it will take a small handful of "high end" players to find it... so if something is taken advantage of by so few, is it really a balance issue? Can the game be unbalanced by something you're not even aware of?

So I thought about how some things could be experimented with... and the programmer in me realized that this is no different than load testing an application. When you do that, you don't run it a few times and see what happens. You run it a LOT of times and get the average results.

So I decided to create a simulator.

Combat Simulator


In the first scene of "The Coming Dark", the players are set upon by a large group of skeletons. But how many is enough? At what point does the encounter go from being a cake walk to a crushing defeat?

So I wrote a program to simulate 50,000 combats between two groups: the five pre-generated characters that are included in the Dungeons and Dragons 5th Edition Starter Kit versus an indeterminate amount of skeletons. How many skeletons does it take before the players are likely to be on the losing end of the battle?

The small little program I wrote takes a few considerations:

  • All the attacks are basic attacks. Every class uses its preferred melee attack except the rogue (which uses his shortbow) and the wizard (which uses the cantrip ray of frost).
  • The noble fighter and cleric are the "preferred" enemies of the attacking skeletons. These are the front line defenders, and likely the ones that stand between the skeleton and the wizards. Only when they both fall is the rest of the party at risk.
  • No high end magic of any kind. Needless to say this would quickly sway the encounter in the player's favor.
  • No healing. No action surge, no cleric healing, no potions, etc... again, this is something the players have that the skeleton's don't. This also means that the players will not use any limited resources during the combat.
  • No one gets advantage or disadvantage on any roll. For that reason, the rogue never deals additional sneak attack damage.
  • A natural 20 deals double the normal damage. I know this isn't precise, but it's easier to code.
  • All the damage is rolled; no averages are used.
  • The skeletons have an AC of 12 and 6 hit points each. They have a shortsword as a weapon, which gives them a +3 to the attack roll and deals 1d6+1 damage on a hit.
  • The PCs are the five defined in the starter kit: Noble Fighter (greatsword), Folk Hero Fighter (bow), Cleric (morningstar), Rogue (shortbow), and Wizard (ray of frost).
  • Since he deals bludgeoning damage and the skeletons are vulnerable to it, the cleric deals an additional die of damage on a hit. Again, not precise... but easier to code.


I ran 50,000 iterations of each combat, adjusting the number of skeletons from 6 to 12. The simulations yielded the following.

# of Skeletons PC Wins PC Losses
6 49258 742
7 47238 2762
8 42606 7394
9 35178 14822
10  26024  23976
11  17060 32940
12  9388 40612

So, in a nutshell, the 11th skeleton is quite the badass. Players could more or less handle ten of them, but when that 11th one steps in things go to crap pretty quickly.

So what did we learn from this exercise?

  • It's very possible for PCs to trash a modest amount of low end minions without having to fire their big guns.
  • The above doesn't use healing at all, which means that even if the PCs get dinged about a bit they are still able to recover. PCs can win an encounter with 8 skeletons over 80% of the time and immediately go into the next encounter.
  • Dailies, spells, healing potions and other consumables - things that the monsters generally don't have - tip the scales considerably in favor of the PCs.
  • If you walk into a room with 6 skeletons in it, you can probably dispatch them fairly easily. As glorious as it might be, you don't have to nuke the whole room.

Until more concrete guidelines for monster creation and encounter balancing come about, I'll keep using this simulator and try to get a feel for how things should be. Over time, I might improve the simulator more and more so that it's more representative of each PCs actions in an encounter. Who knows? Maybe this will end up being a full on AI framework?

I can't help but wonder if WotC does this sort of analysis. Like I said above, sure they have tens of thousands of playtesters but it's such a diverse group with so many different situations that it may be hard to quantify. Not to mention that, if you present a specific combat situation to two separate groups, 99% of the time you'll get two different approaches and two different outcomes.

Can't wait to try this out on goblins and kobolds...


If you're curious, you can view the C# source code for the simulator HERE.