d20 Encounter Checks & Clocks

Arnold K’s recent blog on Goblin Punch has sparked some discussion in my circles on using timers instead of random checks for wandering monsters and similar encounters. Going to throw my hat into the ring by looking at a sort of compromise: an encounter check whose likelihood increases over time. This is similar to something I wrote forever ago, except using a d20 in order to be consistent with a ruleset that uses d20 for resolving most tasks. I’m also going to explore using d20 with constant modifiers that do not increase over time, because I think it might also be useful.

Without further ado!

Simulations

I wrote a simple Python script to simulate a handful of encounter check algorithms:

• Traditional 1-in-6 check.
• d20 + 0 ≥ 20.
• d20 + 1 ≥ 20.
• d20 + 2 ≥ 20.
• d20 + 3 ≥ 20.
• d20 + 4 ≥ 20.
• d20 + 5 ≥ 20.
• d20 + T ≥ 20, where T is the number of turns that have passed.

The script attempts each algorithm 10,000 times and finds the average of how many checks are made before a random encounter finally occurs. Below were the results:

Algorithm	Average # Turns
1-in-6	6.023
d20 + 0	19.87
d20 + 1	9.903
d20 + 2	6.759
d20 + 3	4.997
d20 + 4	3.992
d20 + 5	3.343
d20 + T	5.297

The algorithms with constant likelihoods had very expected results. The 1-in-6 algorithm “terminated” roughly every 6 turns. The d20 check with a 5% chance lasted 20 turns, the one with a 10% chance lasted 10 turns, the one with a 20% chance lasted 5 turns, etc. The incremental check is the most obscure insofar as it does not have an obvious duration, but we find that it tends to last for just over 5 turns.

Now that we’ve seen the statistical outcomes, I’d like to go over some potential applications.

Variable Encounter Checks

We can use d20 plus a modifier based on the party’s current situation.

By Population Density

While looking at DnDNext, it seems like their first thought was to mainly use a target number which depends on the dungeon’s population density. Below is the table found in the March 2013 document, using modifiers rather than different target numbers.

Population	Modifier
Desolate	+1
Sparsely inhabited	+3
Typical	+5
Thickly inhabited	+7
Densely inhabited	+9

Or the one from August 2013:

Population	Modifier
Mostly uninhabited	+0
Typical	+2
Densely inhabited	+4

The presentation is better this way, but I still feel like it’s kind of arbitrary. It also seems like the likelihood of an encounter is extremely high in the March 2013 one, being 30% in just a “typical” region.

How about a remake in the spirit of the above? Roll d20 for a 6-mile hex’s population and the associated encounter check modifier, if you went that route.

d20	Population	Modifier
1-10	1-10	+0
11-14	10-100	+1
15-17	100-1,000	+2
18-19	1,000-10,000	+3
20	10,000-100,000	+4

This still is not my favorite, and I’m mostly including it for comparison (and also because I would have no reason to publish the population table, which I do like, otherwise). The average resultant modifier is +1, which would mean a 10% chance.

By Traveling Time

Actually, the first application I thought of was a hexcrawl where a 6-mile hex requires a variable amount of time to pass depending on its terrain, such as below:

Terrain	Hour Cost
Plains	3
Forests	4
Mountains	5
Roads	–1

The d20 check could be made with the number of hours required to pass through the given hex. For example, a mountainous hex with roads takes 4 hours to traverse and has an encounter check of d20 + 4 ≥ 20 (which has a 25% chance). On the other hand, a plains hex with roads takes 2 hours and an encounter check of d20 + 2 ≥ 20 (which has a 15% chance). Crossing two of the latter hexes has, overall, a 27% chance of triggering at least one random encounter. This means if you had a choice of crossing one mountainous hex or two plains hexes (each with roads), you have a slightly better chance (by 2% lol) of walking out of the mountains without encountering something. I think this is a fair tradeoff, and one that might be even more interesting if mountains had more dangerous encounters than the plains.

What I also think is interesting is that, for 8 hours of travel across a variable number of hexes, the number of encounters is similar (though not equal; compare 25% versus 27%). This means that the tradeoff is less to do with how many encounters are triggered in aggregate, than just with how much distance is traveled.

Incremental Encounter Checks

Using the d20 + T algorithm, we can start T at 0 and increase it by 1 for each turn that passes (or for each check passed). T could be decreased by d6 for each turn of rest, or even set to 0. The T variable could potentially be useful as a modifier on random encounter tables, since it indicates how much time has passed since an encounter; the greater the value of T, the more dangerous the resultant encounter is. T could be phrased as “alarm” or “dread” or something flavorful just for fun.

There's little to say about this since it's straightforward. I like it. One potential side benefit is that, if we are counting turns, it makes it easier to count down resources or spell durations as well (which is preferable to me compared to hazard dice).

Conclusion

This is really just spitballing! I think that, when using a d20, presenting different situations as modifiers rather than as different target numbers is intuitive so long as the modifiers correspond to numbers that have contextual significance (whether # turns since the last encounter, or # hours of travel).

I also think that the incremental check is a useful and non-arbitrary way of using d20 in dungeon encounter checks, while also plugging into the general game loop of exploration, encounters, and exhaustion. What I would probably do is use the hour-based check for hex crawls, and the incremental check for dungeon crawls.

By the way, you can replace much of the above with roll-low checks instead of roll-high checks. For incremental checks, you would check d20 ≤ T and start T at 1 instead of 0. For the hour-based variable check, I would use d20 ≤ # hours and just accept the 5% difference because that’s less important to me than directly using the # hours traveled.

That’s all! This was mostly an excuse to mathpost.