Go to Part 1

DUNGEON MASTER BEST PRACTICES

I gave up on player mapping — particularly player mapping from theater of the mind — in the ‘90s, for all the reasons we’ve discussed: The pace-killing metagame complexity of clearly communicating oddly-shaped rooms and passages, which in turn encourages the design of “standard” floorplans (simple, rectangular rooms and straight corridors aligned to the compass points) which ironically undermine the very type of gameplay that player mapping is supposed to be leveraging.

Around 2009, however, I came back to player mapping. The best practices I describe below are not necessarily a “one true way” for handling player mapping (and you should feel encouraged to experiment and find what works for you and your group), but over the past decade and a half while running games for dozens of different groups, they’re not only what I’ve found makes player mapping work; they’re what I’ve found makes player mapping thrive as a unique and valuable part of the game.

First, if they choose not to map, that’s OK. It’s their choice. You’re not their nanny.

What’s important is that, if they choose not to make map, you don’t help them out. Don’t say stuff like, “Well, you can easily find your way back to the chamber with the giant ankh.” Instead, say, “Okay, you want to go back to the chamber with the giant ankh… which way do you go?”

In other words, if you want navigational information (in the form of the map) to have value, you need to actually let them navigate.

After they get lost trying to backtrack a couple times, they’ll figure it out. Or they’ll come up with some other scheme, like marking the walls with chalk or trying to leave a breadcrumb trail. Or maybe it’ll turn out one of them is a savant who can memorize the whole dungeon without a map at all. That’s all great: The point of player mapping isn’t producing the physical artifact; it’s to have the players engage deeply with a scenario by making interesting navigational choices.

With that being said, there are ways to prompt the idea of mapping to players who may not realize that it’s an option:

• The 1974 edition of D&D does it by including mapping equipment in the equipment list and having mechanical structures for mapping (e.g., a rule that you can’t map when fleeing from combat).
• Put a pad of graph paper on the table next to the pencils and dice as a resource for the players to use.
• Give the players a partial map of the dungeon as a prop. For example, they might find the map in the pack of a dead adventurer, thus (a) establishing that mapping is something adventurers do, (b) showing that the information on the map is useful, and (c) giving them the opportunity to begin mapping by just continuing to draw on the partial map.
• Just tell the new players, “Mapping the dungeon is something a lot of adventurers do.”

Everything else is about how you can clearly and effectively communicate the dungeon environment to the players. (This is, of course, good praxis even if the players aren’t mapping: The players have to be able to understand the game world and what’s happening around their characters if they’re going to roleplay.)

Describe things from the character’s POV. So rather than using compass directions, for example, I’ll say things like, “straight ahead,” “the door on the left,” or “the corridor angles to the right.” In my experience, this is more immersive for the players (since it encourages them to visualize the world from the perspective of their characters instead of some sort of “top-down” GPS signal) and also creates a challenge for the mapper, who will need to maintain proper orientation. (Or invest in a tool like a compass to help them do so.)

Use imprecise measurements when describing the dungeon. Instead of “the hallway is thirty feet long,” I’ll say stuff like:

• “You go twenty or thirty feet down the corridor.”
• “The hall goes for thirty, maybe thirty-five feet before ending in a stairway down.”

The same thing goes for rooms: It’s a chamber a couple dozen feet across or a room that’s about twenty feet wide and a little longer than that.

You might even drop measurements entirely; for example, “You go down the corridor a bit and then…” In my experience, though, this almost always prompts the mapper to ask, “How far is a bit?” and you’ll end up defaulting back to, “Maybe twenty or thirty feet.” This back-and-forth is a time-waster, so you’re probably better off cutting to the chase. (But your mileage may vary.)

By featuring imprecision in your descriptions, the players implicitly get the message that they shouldn’t sweat the details of the map: They don’t need to worry about making the map perfect because they CAN’T make the map perfect… unless they need to make the map perfect.

If the players want something more precise than a rough estimate of distance, then they will need to seek precision in character. If they want to know exactly how long a hallway is, then they need to explain how their character is taking that measurement.

In a dungeon environment, this should almost always come with a cost, usually either in equipment (e.g., expensive surveying equipment that also chews up encumbrance slots), time (e.g., in the form of additional random encounter checks or a progress clock being ticked), or both. The important dynamic here is that if the players want more precision in their map (for whatever reason), then they need to choose to pay the cost and have their characters actually perform the required actions. It turns a metagame distraction into a meaningful part of the narrative, while also making sure that this additional focus and time is generally only expended when there’s a reason to do it and also heightened player interest in the results.

You will likely find it useful to have a formal procedure for this (e.g., getting precise measurements for a single room or a 60-foot length of corridor requires one dungeon turn; or twice that if they don’t have the proper tools). It might involve a skill check, but that’s probably not necessary. You can, of course, adjust this procedure depending on exactly what resources and methods the PCs bring to bear on the problem.

Note: Just like when you’re running traps, there’ll be situations where there is no meaningful cost (and the PCs know it). For example, maybe the PCs have cleared out all the monsters in the dungeon and now they want to take their time double-checking everything. When that happens, it’s okay to sort of “zoom out” and rapidly resolve their survey at a broad scale. (What you have here is an example of empty time — a period devoid of meaningful choices — and you want to resolve it quickly and move forward to the next set of interesting choices.)

Of course, if the PCs only THINK they’ve cleared out all the monsters, you can just apply the normal cost while they’re blithely whittering their way around the dungeon.

When the players take precise measurements, don’t hesitate to just draw out the area for them. I’ll sometimes keep a pad of graph paper on hand specifically for this. In other cases, I’ll just draw it directly on their map. No need to fuss about here: They put in the work to get precision, so give it to them in whatever way works best.

Even during normal exploration, if the players are struggling with a weird-shaped room or anything of that ilk, you can quickly clarify things with a quick sketch of the room shape and hand it to them. When I was running Dave Arneson’s Castle Blackmoor, for example, the primary entry chamber was so gloriously byzantine in its design that I had a small sketch of the room’s shape paperclipped to my maps:

Whenever a new set of players would venture into the dungeon, I would just hold up the sketch.

On the other hand, don’t feel like every inaccuracy you see on the players’ map is a problem you need to solve for them. My general rule of thumb is that, as long as it’s a mistake that a character standing there could make, I’m not going to intervene. But if they are making an error that their characters definitely wouldn’t make, just use a visual reference to clear it up. The goal here is not some sort of stringent purity test where you adamantly refuse to use any sort of visual reference.

To help avoid confusion in the first place, make room dimensions the first thing you describe. These can be general (“it’s a wide, long hall with a vaulted ceiling” or “beyond the door is a small office”) or numeric (“you see a square room about twenty-five or thirty feet across ”), but by leading with the room dimensions and shape you’re creating a “canvas” that both the mapper and the other players can “paint” the rest of the room description on.

Note: As noted above, if you don’t give numeric dimensions, you may find that the mapper is always going to ask for them. I tend to default to just including them, but this can vary quite a bit on your group and your mapper.

After establishing the “canvas” of the room, make exits/entrances either the first thing or the last thing in the room description. This essential navigational information is the backbone of the dungeon adventure, and by making them essentially the first or last thing in the room description you make it much less likely that the players will lose track of where they can go. (Remember that the structure of a dungeoncrawl ultimately boils down to: Do stuff in a room until you run out of stuff to do, then pick an exit and go through it to find another room.)

Finally, pay attention to common descriptive phrases that confuse your players and then figure out a way to describe those things in a way that ISN’T confusing.

For example, I’ve found that “there’s a thirty-foot hallway with two doors at the end of it” creates confusion, so I make a point of saying either, “There’s a thirty-foot hallway with two doors facing you at the end of it,” or, “There’s a thirty-foot hallway with two doors facing each other at the end of it.”

Which phrases are common will depend on your own descriptive habits, and which ones are confusing (or clear!) will depend on your group. Which is why this ultimately boils down to being aware of when things go awry, and then making a mental note of how you can avoid that friction in the future.

Next: Mapping and VTTs