Traditional fantasy roleplaying games

Overloading the encounter die

The nature of the random encounter check is that of a timer. While it is not a literal countdown (since random results are mathematically independent), it simulates one. It is the danger clock, always ticking, giving meaning to the decision to search (or not), investigate just one more room (or not), or engage in any other potentially fruitful exploration activity.

There are a number of dynamics within the game that seem structurally similar to the periodic encounter check. Randomizing when light sources expire has also been suggested in several different places. Many systems as written specify that PCs should rest every sixth turn (though I have never once seen this in practice). Torchbearer imposes conditions on characters as turns pass to represent exhaustion and the abstract effects of other dungeon hazards. John B. suggests sometimes interpreting a random encounter as a monster spoor rather than an actual encounter.

Why not put all these things together systematically? Consider the following rule:

When the party moves into a new area or spends time on an exploration activity, roll the encounter die and interpret the results as follows.

Encounter

Percept (clue, spoor)

Locality (context-dependent timer)

Exhaustion (rest or take penalties)

Lantern

Torch

One might object: does this not lead to absurd results such as torches going out on the first turn or PCs needing to rest on the second turn? Well, yes, but you are an intelligent human, so ignore results that do not make sense. A result should be interpreted as not “X happens,” but rather as a prompt. A result can be deferred, but only so many times. The weight will naturally build up in the back of your mind as events proceed. As a guideline, ignore results above 3 for the first 6 or so turns.

You could have a general “light source” entry and just pick one light source randomly each time (this has the advantage of not having all torches go out at once), but I prefer to distinguish between the two main types of light sources given their differentiation on the equipment list. Conceptually, I think it helps to have different spaces in your short term memory for each, as you can have the sense that 5 has come up several times already and know that is relevant for lanterns. Torches should probably go out almost every time a 6 six comes up and lanterns should deplete approximately every third or fourth result of 5.

“Locality” is meant to be used for area-specific state that should be kept separate from standard random encounters. Examples: water rising, the stalker drawing nearer, a prisoner loosing an appendage to the torturer, doors locking behind PCs, and so forth. The possibilities are limitless and make every location potentially mechanically different in a way that is player-salient.

In addition to streamlining gameplay and decreasing intrasession bookkeeping, such a procedure also decreases null (“whiff”) results. Almost every turn result means something. This may or may not always be a good thing. Maybe there is something to be said for not having something happen on every roll. However, given how dungeon exploration tends to play out in real (player) time, I suspect this is about right.

The results table could be replaced with a custom one for a given location, but the above spread seems like a reasonable default to me.

Post navigation

16 thoughts on “Overloading the encounter die”

I’ll consider that. I already use 1-2; perhaps combining this with my existing system of sending a token round the table, changing after every room explored or combat scene. So, you get a result on 3-6 only after that many scenes have changed (in which case torch should be 4, rest should be 5 and lantern 6?)

Only other thing: should making noise really wear down torches and lanterns?

That token system sounds reasonable, though it is probably limited to in-person play. In practice, I don’t think one would need to keep strict state regarding when the numbers come up (which is what token passing does, right?), as long as the die itself is rolled reliably per area/scene. I suspect that just rolling the die would be enough to jog the right bits of memory, though I admit to not having tried this exact system yet. My one major concern is that memorizing 1 = encounter is much easier than internalizing a 6 entry table.

I would not use this table for “noise” encounter checks (or other encounter checks that are not due to time passing). Really, none of entries 2 – 6 inclusive are an appropriate response to making a racket, so that kind of roll can remain 1 in 6 (or whatever), probably.

I like it. I’ve also been toying with the idea of making the encounter roll a literal count-down, that is a result of non-encounter indicates how long until the next encounter. I’d have to fiddle with the math a little but it seems to me you could arrange it so that while on average you get the same number of encounters per period you could eliminate the meta-gaming (a la Order of the Stick where the PCs know that having had an encounter they cannot have another for a certain period) and have it sometimes work out that a new encounter falls in the middle of something the party is already engaged in.

A bit late to this one, but I really dig it and had a couple thoughts I wanted to add.

One, perhaps to integrate more of a sense of time, encounter tables could be structured to take advantage of an ascending dice chain. So turn one d3 on the table, turn two d4, turn three d6. The results clearly based in the passage of time, such as light sources going out, are put in the higher numerical spots and cause the dice chain to reset once rolled.

Another thought would be tie this into a deck of playing cards rather than dice. A while back I wrote a couple posts on the math of using cards for wandering monsters, I may have to revisit and incorporate this as well. Perhaps one suit corresponding to light sources and torches going out every time the DM gets to 21 in that suit.

Thanks! I am happy with how it played on monday. It seemed very straightforward, and the pacing of the light source exhaustion also felt correct without requiring keeping any state.

Interesting idea about rations. The time scales are a bit different, as I usually think of a day’s worth of rations being one encumbrance slot. But perhaps that could be tweaked somehow to fit (maybe make it a “ration check” to see if the ration is actually exhausted?), as I like plugging more resources directly into the clock.

Torchbearer does something similar with rations by making the first step on the health track be “hungry” (or something like that; it’s been a while since I read that system).