Friday, July 9, 2021

Brave Design Notes 5: Dungeons

Art credit: Tony DiTerlizzi

Brave is a hack of Ben Milton's Knave, an old-school adventure game toolkit without classes and a lot more emphasis on equipment. The earliest changes I made were miscellaneous tweaks and houserules I added as I would run Knave, but at this point I've bolted on several advanced play procedures. While Knave is optimized for a DIY "rulings over rules" style of play, I still felt it was valuable to write down many of those rulings that I've made over the years and codify them. One of the best parts of the original Knave were the designer's notes, but I've taken them out because I needed to make room for new stuff and I assume that anyone playing my game would already be familiar with the original version anyway. Instead, you get my blog.

These notes are written for version 1.9, which you can find on the sidebar of this blog or by clicking here. These rules also make use of a resource called a "dungeon control panel," which you can find here.


This is the newest addition to the ruleset and one that I think is incredibly important. I'm a big believer in procedural play, and it pains me that so few RPGs provide procedures for their most common activities. Much of the depth of play that comes from the dungeoncrawl experience is tied directly to the rules in the procedure itself, not merely from the contents of the rooms making up the dungeon. I've described before about the difference between the macro-level challenge and the micro-level challenge that players experience while clearing out a dungeon, and the macro-level can't exist without some kind of structure.

That said, most people will just point you to the dungeon procedure in B/X D&D, which I personally have many issues with. Here's that procedure (taken from Necrotic Gnome's Old School Essentials):

If you compare them, you'll notice quite a few differences. There are a lot of specific things I don't like but overall my main criticisms are that it both fails to account for a lot of important concerns that would be relevant to the activity, while also being far too specific on the details for other things when it shouldn't.

Like, you know what sticks out to me the most about the OSE procedure? It has such detailed ideas about doors. Look, none of that material is bad. But it does strike me as incredibly similar to the ethos behind AD&D: codify specific rulings for specific situations rather than trusting the referee to make firm judgments about a gameplay element as common and flexible as a door. Like, why does it need to be written in the rules that "undead probably won't make noise," you know? I don't want to try accounting for every possible variable that can be attached to doors in dungeons, since that's something that referees should be encouraged to play around with.

Meanwhile why is nothing written here about how mapping and navigation works? That's something which is notorious for being done incorrectly by players and DMs who don't know any better, so I feel like spending a few sentences describing it could be a better way to use up space than to say, "locked doors need to be opened with a key or a lockpick."

So allow me to explain my own version and the rationale behind my design choices:

1. Actions
So the whole point of even dividing things into time chunks is to have some parameters for "how much activity the PCs can do before the next random encounter roll." And the best way to define the extent of activity within a turn is to create a unit, the action, and define what activities cost 1 action.

But 10 minutes is kind of a long time, so just letting the players do only one thing during a whole 10 minute period is a bit harsh. Plus, you know, you can multitask. Move and look for traps, you know? Search for secret doors and loot the bodies. Now, I've seen some dungeoncrawl procedures that impose penalties for each extra thing you're doing. "A party that's sneaking goes 1/3rd speed" or "if you run, you get a -2 on checks to notice traps" or whatever. "You go 55% slower while mapping" or something. I think that's pretty clunky and inelegant.

Instead, the cost of doing activities should come from the inherent tradeoffs of the action economy. Hence why I instead say that PCs can do two actions per turn. That way, it's easy to know exactly how many activities can be accomplished in 10 minutes, as well as how much their movement is reduced by each extra activity they do. If they chose to use both actions to move, they'd go further than choosing to use one action for something else instead. Makes sense, right? You get two actions. Decide how to spend them. You get the benefits of the ones you do and you don't get the benefits of the ones you don't do.
When a check needs to be made on behalf of the group, only one roll will be made by whoever has the highest bonus. If they have 1+ allies helping them somehow, they can have advantage.
This comes from me fucking hating moments of "skill dogpiling" in RPGs. I hate when a PC fails at something and then everyone else immediately asks to attempt it themselves. I'd also like if, when in a dungeoncrawl, the players are thinking of "the party" as the basic unit they're working with, rather than "the player character." They should think and work as a team, you know? Although I've considered upping it to 2+ allies helping in order to grant advantage. Not sure yet.

As for the specifics of how to resolve different activities, I'm a big believer in having a flexible core mechanic you can always fall back on. Having arbitrary X-in-6 rolls to resolve miscellaneous things which, by all reason, should be determined by the PCs' stats, is not my style. Perceiving things is a WIS check and disabling a complex, intricate trap is an INT check, you get me?

One of the purposes of the "dungeon control panel" (see below) is that the referee will write down the PCs' stats at the beginning of the dungeoncrawl, so that they can more easily make secret rolls on their behalf behind the scenes.

2. Movement
This is a weird one but I want to explain. So the standard old-school rule was that you could always move 120 feet in a 10-minute turn. This is useful for a lot of reasons. It splits the dungeon into manageable chunks. It's a much greater distance than the 30 ft you can cover in a combat turn, but it's still within a person's ability to mentally picture when looking at the dungeon map. A lot of games will reduce it by, say, 30 ft chunks for each level of encumbrance suffered or each extra activity or whatever, which is convenient because 120 is a good number for that. B/X D&D specifically says you move at the speed of your slowest party member, so if you have a single person wearing heavy armor in the party then your maximum speed is 60 ft, and it'll only get slower from there. So a big part of strategy in a dungeoncrawl is trying to optimize your speed and ground covered per turn, clearing out all the monsters before you haul the treasure out so you can take your time doing it.

However, it's... um... ridiculous? Like, this is beyond unrealistic. It's fucking bananas. I cannot allow this nonsense to go on any longer. I am generally not the kind of DM who ever prioritizes realism in my gaming, but you have to draw the line somewhere. When something is so far beyond reality like this, so at odds with simple facts of common life, it completely undermines your ability to see the game world as something which can even be understood rationally. And I am sick to fucking death of people trying to defend this and make up excuses for it. There are many attempts to justify it and none of them measure up to the task. Let's tear into this:

People often justify it by saying that this speed assumes the party is being careful and keeping an eye out for traps and mapping their surroundings and trying not to step in icky stuff and waiting for slow people to catch up and attempting to be quiet and trying to carefully observe the furthest edges of their lantern's light range and whatever else. But there are a couple problems with this.
  1. Some hardcore old-schoolers claim that they always operate on the assumption that all these things are happening, but then they totally don't actually do them at all. If the reduced speed is based off the assumption that the party is being careful to search for traps and secret doors, then they should never miss a trap or secret door. Never ever. Period. Not if they've slowed down to this rate. The only way they could be slowed down that much is if they were being thorough beyond the possibility of missing something. In which case, there basically are no secret doors, because there's a 0% chance that the party will miss them. In reality, the simple fact is that most DMs will deny to players the benefits of things like finding secret doors or traps or not being ambushed unless they hear the players specifically declare them. They don't get stealth benefits unless they say they want to sneak. Many DMs claim that the party is implicitly doing all this stuff but then punishes the party for not explicitly saying they are.
  2. This is then reinforced by those rulesets I mentioned that explicitly reduce movement speed for each extra activity, e.g. "Your 120' speed is reduced to 90' if you're looking for traps, and another 60' if you're looking for secret doors..." implying that the original 120' speed was meant to be an "unaffected speed." From the B/X Red Box: "though 60' per turn may seem very slow, it includes many assumed actions — mapping, peeking around corners, resting, and so forth" is a fucking lie.
  3. Even if you were doing all of those things, that still shouldn't slow you down this much. I mean come on. Standard walking speed is 3 mph, or 3,000 feet per 10 minutes. Rounding that down to a mere 120 feet?? 4% of your normal walking speed? Jesus, that's 2.4 inches per second. Inches. It is physically difficult to walk that slowly even if you tried. Even if you make frequent stops and stand still for a moment, you'd still have a difficult time not overtaking 120 ft after 10 minutes of doing that.
So for the DMs out there who really make good on their claims and actually grant the PCs 1) trap locations and details, 2) secret door locations, 3) free stealth against any monsters they may come across, 4) the dimensions of every room and hallway for the mapper, 5) all treasure instantly teleported into the PCs' pockets as soon as they enter the room, etc. then feel free to do all of those things every single turn just so you can justify your 120 ft movement speed. Personally, I'd rather let my players choose to walk if they'd like to, and only slow them down if they're spending their limited actions on specific benefits they want to gain.

And as for speed, I've compromised a bit. If you use both actions to walk, then you'll go the appropriate 3,000 ft a human being should be able to. If you only use one action to walk, it's reduced to 300 ft, a more manageable number for most purposes. Of course, 300 ft is still pretty long in a dungeon, and 3,000 ft is so long that in pretty much anything smaller than a megadungeon you'll probably be able to reach any room you want to within a single turn's action. But you know what?

That's realistic. And sometimes you have to bite the bullet and grant players the benefits of realism when it works in their favor.

But if they ever choose to use both actions to move and insist on just walking, nonstop, all the way to the end of the dungeon, then don't forget to spring every goddamn trap and ambush in their path. They'll quickly learn the reason why most PCs never take advantage of their 3,000 ft speed per turn.

[Also, I'm very interested in the design space of making dungeons at scales large enough that rooms are separated by hallways hundreds or thousands of feet long, with the whole dungeon spanning miles of Underworld. See this article for a bit of discussion on that idea.]

3. Mapping
[I have talked about this previously in this article on mazes, and while writing this post I stumbled across a similar article by the Angry GM about this, although his post about mapping is about a third the length of this entire series of posts on my game]

This is another thing which a lot of groups do poorly and for which there is a perfect solution that rarely gets written down. Let's review some common and incorrect methods people use, and then talk about why they're incorrect:
  1. Many groups just have the DM constantly describe and re-describe surroundings. Don't get me wrong, theatre-of-the-mind is probably my preferred way to play and it is a best practice for the DM to constantly re-iterate things for the players. But spatial reasoning gets cumbersome fast when it's held entirely in the mind, so it's hard to have complicated and interesting layouts if you never introduce any kind of visual.
  2. If they're using a drawn map, like a wet erase grid or something, then they might have the DM regularly go and draw the next chunk of the map as its revealed. This method is extremely common but it's incredibly tedious.
  3. If they're using terrain, then they might add new blocks of ground and walls as you go (similar to above) or they'll set it all up ahead of time and then cover up chunks of the dungeon with, like, tissues or something, removing them one by one. This is also a pain in the ass.
  4. They just provide the PCs with a blank map. This is okay to do sometimes because it definitely makes the dungeon experience different in a novel way, but I firmly believe that it shouldn't become the default. The experience of discovering the dungeon's twists and turns and the risk of getting lost is too valuable to give up.
  5. They play on a virtual tabletop and just embed the map itself on a background layer. Thus, the DM's master copy of the floorplan and the player copy are one and the same. This is fine for people who play that way I guess but I don't think that any answer which relies on a digital setup should be considered a "solved" problem. I've also run dungeoncrawls this way and I found that it made my players behave in a much more "video game-y" fashion, engaging with the space more by moving their tokens around and never asking for details about the rooms' contents anymore. It was a weird and frustrating psychological shift to watch happen.
  6. Maybe there's no map provided and the players do just have to use theatre-of-the-mind, but the players are drawing their own map as they go. This is an especially strong option if player mapping is treated as an in-character activity rather than a meta one, i.e. there must be a PC who has declared that they're mapping as their action in order for the player to be drawing anything. So far this is actually the best solution, but... then they make the fatal mistake. A lot of groups who do this instinctively think that the DM should provide precise dimensions for each room and then meticulously draw them out on grid paper. Some RPGs even directly encourage this. However, this sucks and is a shitty, awful method that no group should use. It's understandable for new players to make this mistake but it's infuriating to me when cranky old gamers encourage it because they've stubbornly refused to abandon it after all these years. This is especially frustrating because the correct method has been around since the 70s as well, so they should know better.
Except I do know why the old folks still do this sometimes. They were explicitly taught to. This is taken from the 1983 Mentzer Red Box, which is followed by a step-by-step tutorial that instructs players to practice copying the DM's copy of the map inch-by-inch:

Shame on you, Frank.

Alright, this is the correct way to map: the referee describes things to the PCs from a first person POV and players draw as they go, but there's no precision or dimensions unless they stop and take the time to have their character measure things. Humans can't easily eyeball the difference between 50 ft and 55 ft so it's unreasonable to grant them information that precise. In fact, humans are oftentimes pretty bad at telling the difference 5 ft and 10 ft.

Instead, the group is making do with flowchart style maps. They draw a box for each room and a line for each connection and jot down whatever other useful notes they want, but not much else. You know how we know this is a feasible and reasonable method from even the early days? Because when text adventure games were invented, this is what video gamers did. Here's an example of a player-drawn map from the game Colossal Cave Adventure:

Now of course, this example is of a very high quality. I imagine whoever made it was trying to make a clean, comprehensive map after several playthroughs and early drafts, breaking out the ruler and being thorough enough to even include two connections between every adjacent room, since the route "to" is not always a perfect inverse of the route "from." Here's a better example of what this technique probably looked like for most players in-practice mid-game, albeit significantly messier and sloppier than I hope is the average:

[EDIT: lmao I goofed. This next section is gunna be a bit embarrassing. Please see in the comments where Justin corrected me.]

Don't get the wrong impression: I'm not saying that this was the universal mapping method back then. It was common, but so too was the inferior method of spending hours and hours agonizing over precise measurements. An enlightening piece of history on this divide can be found in none other than the very first dungeoncrawl ever run: Blackmoor. In the Judges Guild's The First Fantasy Campaign, Dave Arneson's packaging of everything he used when running the original Blackmoor, you'll find a bunch of maps of the dungeons below the castle. As would be expected from any published dungeon adventure, there are maps for the DM that act as "perfect floorplans." They are "true" representations of the dungeon, the ultimate authority. They are detailed and well-measured, and are keyed for the DM to reference other material. Here's an example of one:

...but there's also THIS:

The ancients had wisdom!

That second map is a streamlined "flowchart" version of the first, the version drawn by the players. That said, I guarantee you that this isn't actually the drawing his players made mid-session. It's still way too clean and detailed, and was definitely drawn later for inclusion in this published form. But it demonstrates to us the type of translation that occurs between the DM's master copy of the map and the PC's approximation map when using this method I advocate. You'll even note places where the player version is mistaken or mixing in information from adjacent dungeon layers above and below (not to mention, it also just covers a lot more stuff to the north and a bit to the south, if you're having trouble seeing where things correspond).

And yet, I actually know for sure that this was a realization that was only made after Dave originally ran his game, at some point when they were making this product for publication. How? Because we have scans of the maps that the real Blackmoor players drew during those first few sessions, and indeed, they were using the inferior method. So it's more accurate to say that the ancients gained wisdom.


There are several advantages to this:
  1. It's fast and easy. The DM has less information to communicate and the PCs can draw it out in a couple seconds. In fact, the DM's description of the room no longer even needs to acknowledge the concern of mapping, because their basic narration is enough info for the mapper to go on. It's seamless.
  2. It will give the players accurate and useful information to make decisions and keep track of things, making mapping a thing worth doing.
  3. It still has enough uncertainty and room for error that genuine mistakes can be made, which is part of the challenge. Yes, that's right, the lack of perfect information in this method is a feature, not a bug. I'll explain that in a bit.
Don't get me wrong, the referee should still have their own master copy of the dungeon to keep private. It should look like a perfect floorplan, because it serves as the authority on what the dungeon is really shaped like. But the PC-created map should not look like a perfect copy of the master floorplans. Stealing this from that Angry GM article for a moment, here's a side-by-side of a referee master map versus the accompanying player-created map:

You'll notice that these PCs didn't notice every single connection, and they made some weird interpretations of certain connections. That's fine. That's good.

The potential to get lost is an important part of the fantasy of dungeons, conceptually. But how you "mechanize" the process of becoming lost and finding your way again is tricky. Some games have abstracted dungeons, so they can create a rule for, like, rolling a navigation check and then failing and suffering the "lost" status effect or something. I'm not talking about those sorts of games. I don't do that much abstraction. We're interested in old-school D&D-style gaming. The players will understand the dungeon space in terms of rooms, hallways, and their relationships to each other.

If you provide the players with a perfect map, whether that's a handout of the dungeon's floorplan or the terrain walls and floors on the table in front of you or the background image in your VTT, you are always removing the possibility of players ever getting lost. All they need do is look at the image and see where they need to go. The reason people get lost in real life is because they can't see the whole floorplan all at once. They can only see the room they're currently in.

Key concept: the only "true" image of the dungeon as a whole that can ever exist in the game must be one that exists in their heads, just like in real life. Any visualization provided needs to be potentially false. 

Think about it. What does it actually mean to "be lost?" It means that your mental concept of where you are and how that relates to the rooms around you isn't matching up with the reality of it. Or in this case, it isn't matching up with the DM's description they're giving of your current surroundings, which we take to be the most authoritative source of info there could be. How do you make a character feel that? Honestly, the only way to mechanize "getting lost" is to do it to the players themselves, and erase the diagetic barrier between player knowledge and character knowledge for a bit. You get meta. Thus, there is no formalized state of "being lost" in the rules, because "lost-ness" is a state of the player's mind.

Now here's where the imperfections of flowchart maps become valuable: in order to avoid getting lost, the flowchart map is usually sufficient. It gets the job done. That simple drawing makes the difference between cognitive overload and smooth sailing. So usually taking the extra time, in-game, to take precise measurements is overkill. BUT... occasionally it can make a difference. It matters when there are weird, specific subtleties in the dungeon's architecture that are deliberately designed to disorient players, taking advantage of the imprecision of their map and hiding the truth in the details.

If you've ever read descriptions of play in OD&D about players measuring angles and inclines and navigating deceptive architecture (the dwarf and elf classes even had built-in racial features to combat such things), that stuff all only works and makes sense assuming you're using this method rather than the others. "Tricky architecture" was a dungeon staple back then, but it wouldn't really be possible as a challenge if you're using exact dimensions or you're relying on terrain or a DM-provided drawing on a grid. You need a missing layer of information somewhere for the trickiness to hide within.

For example: most modern dungeons look like this. This dungeon, I think you'll agree, is definitely easy to provide exact measurements for if you want to play it that way. But it also won't produce any significant errors if you just simplify it to a flowchart instead:

But an old-school dungeon would look more like this, which is really difficult to describe without just simplifying things. "Well, the hallway is at kind of a weird angle, sort of diagonal to your current room... and then there's a sorta T-intersection a bit down the way but the other hall doesn't quite intersect perpendicularly..." and the best attempt at trying to capture all this on a flowchart-style map is, while likely the only thing viable, also inevitably going to create errors.

This is a type of challenge that basically doesn't exist anymore. It's fun and interesting and definitely the simplest and most sensible way of simulating the possibility of "getting lost" in a dungeon, but it can definitely be overdone. It's good for throwing a wrench into the players' mapping efforts, but if you do it more than once in a dungeon then it can undermine them completely. All it takes is two or three errors in the map for things to get thrown really out of place. I think that old-school dungeons were over-reliant on tricky architecture, but every now and then it can be a meaningful challenge that exploits the inherent limitations of flowchart mapping.

Sorry this took me a while to explain. It's an important issue to me and I want people to know about it.

4. Encounters
I'm far from the first person to argue that random encounters serve an important mechanical function, so I won't explain that yet again. But I also feel as though "encounter" is a more flexible concept than just "wandering monster." I also didn't feel it would be right to codify one be-all, end-all method of incorporating them, because some people use their own methods like overloading the encounter die (by Necropraxis) or adversary rosters (as popularized by Justin Alexander).

This is also an important spot to reiterate Advanced Darkness, as it's the moment where it probably matters the most. And of course, I believe that this sort of content is for players just as much as it's for referees, since it helps them see how the referee thinks and get on the same page.

5. Traps and Hazards
Once again, I felt like the B/X version was too strict in codifying rules that universally apply to traps, when traps could, instead, be treated as pretty flexible. I have no need for the distinction between treasure traps and room traps. Your trap might be a magic waterfall coming through the ceiling. It could be a series of small statues spread throughout the room. How do you classify either of these cases in the traditional treasure-room binary? What about traps like the legendary falling portcullis? Or the trap of taking the bait, entering a dark room, and getting ambushed by enemies? What type of traps are those?

I don't see an advantage to setting such arbitrary categories in place. The only point in me acknowledging the "room trap" as a concept is in reference to the sorts of huge, open-ended puzzles that some OSR folks prefer in their traps.

However, I disagree with the idea of doing away with the "detection" step. I mean, it's fine to have traps out in the open every once in awhile, but I still think they should be hidden by default for an important reason. I'll explain.

Many people have made the (accurate) observation that the process of finding (or not finding) a trap, as it's usually done, isn't good gameplay. If you rely on modern methods, you just roll a die and you find it or you don't, which is boring. Or the really modern method, passive perception, means that you don't even roll a die. The DM just consults your score and tells you if you notice something. Lame. If you rely on the old method, you describe how you're looking for traps. Definitely more interesting, but there's still an issue. When do you do those searches? If you never do them, then you'll run into every trap. But if you do them all the time, then the game bogs down and is awful. That's actually why they even invented passive perception to begin with! And neither of those is really a "choice." Either you get told about them automatically because of passive perception, or you search constantly because that's the only way to not get fucked. And if there's no cost to searching, then you'll definitely search all the time, because why wouldn't you? You're incentivized to bog the game down!

So here's the key: 1) there is a cost to searching for traps. Specifically, it uses one of your actions, and because you only get 2 actions per turn, every search for traps is another random encounter roll you're risking. Trying to be super thorough will get you killed by attrition alone. But it also can't be a crapshoot either. Which is why you also need 2) there is a pattern to where and how traps are hidden.

Thus, the challenge comes not just from the search process, but from knowing when it's worth it to search at all. There's always a cost to searching, so the measure of a player's skill at dungeoneering is not from being thorough, but from knowing how to optimize the way they spend their time. Minimizing their trap searches to only the times when it makes sense, which must be informed by an intelligent observation of the logic of traps. If you ever fuck up and run into one, you should always be able to look at it afterwards and think, "I could have seen that coming. It made perfect sense."

Once again, this is supported by 1) realism, 2) feasibility, and 3) game design.
  1. Where do traps in a dungeon come from? Someone had to construct them and place them. And making traps is difficult. It's both time-intensive and resource-intensive. Most people aren't expert engineers who can construct complicated room traps. So instead, they're more likely to learn one simple, cheap type of trap and then make it again and again and again because it's easy. If it can work once, surely it can work multiple times. And then, it also makes sense for them to place some kind of clue to the trap's presence. If you live in the dungeon and frequently traverse these halls, you need a way to reliably sidestep your own traps. When you recruit a bunch of interns into your evil gang, you tell them, "keep an eye out for the wolf rune on the walls. When you see it, there's a trap underneath."
  2. It helps the flow of play not get bogged down by constant probing. Once the players know where to search and how, then they'll be asking to less frequently and with less time spent brainstorming ideas.
  3. It creates a long-term challenge that spans the whole dungeon. Rather than each trap being solved individually, you're solving a series of traps as one unified challenge. You learn a little bit more with each one. You're rewarded for paying attention and reusing old information when you recognize situations where it's relevant. You can more easily "master" the dungeon. And of course, it means that traps aren't just coming out of nowhere.
This is a bit more work for the referee, I'll admit. This means that you need to also think about the clues that would indicate a trap's presence in addition to designing the trap itself. You need to be ready to casually mention at least one of those clues in any basic description of the area, and give a couple more if the players state that they're looking closely. And it's also only fair to the players that the very first trap isn't bullshit, so I like to have the players stumble onto a corpse right next to where the first trap of the dungeon is. They can inspect the area and pick up a few ideas about where traps are placed and how they're triggered.
Referee: "You see a skeleton in front of the doorway leading into the dungeon." 
Caller: "Where is it lying in relation to the door?"

Referee: "Just outside of it, like it was about to walk in but got knocked over."
Caller: "Does it look old? Any way to tell how it died?
Referee: "It's still got tattered clothes on, but the skull has been separated from the body."
Caller: "What's the doorway like?

Referee: "Stone, old, forms into brickwork with the walls and corridor."

Caller: "Hmmm can I inspect it closer? Any gears or runes or anything? Moving pieces?"

Referee: "Roll Wisdom."


Referee: "You notice brown stains on the wall. They've splattered horizontally. You've also noticed the mortar is missing between these two brick layers. Instead there's just a deep groove."

Caller: "Would the splatters be about, say, neck level?"

Referee: "Yeah, just about."

Caller: "Alright gang, working theory: a blade or buzzsaw or something is gunna pop out of that groove right there. Pay attention to the brickwork on the walls at about neck level, ya hear? Now let's look for a trigger of some kind..."
This is the exact sort of "information challenge" that requires critical thinking that OSR play is all about. I still like to rely on some degree of "character skill" and allow a check when I think it makes sense, but I think you'll agree that it was the player's brain that cracked this case.

Another thing that's important to make this work is that each successive trap should still be at least a little bit unique. If all of them are literally identical then the only trap that actually matters is the first one. Each trap after that would just be a formality, a puzzle already solved. But if, instead, you kept adding small twists here and there, you can maintain challenge without compromising the fairness of players relying on their prior knowledge.

This is a trick used all the time in video game design. Rather than trying to come up with a million fresh, unique challenges that are each used once, you instead come up with a handful of potent game elements and then use them in different configurations again and again and again. In this case, you come up with a really potent trap idea (good trigger, good effect, good way of being hidden, good clue to reveal its presence) and then you think of as many ways to use it as possible.

For example, I once designed a dungeon owned by kobolds who use a special poison dart trap all the time. It's like a little crossbow that's triggered by a pressure plate, and it shoots a cobalt-laced dart through some pinholes in the wall to target the person on the plate. Sounds pretty iconic, right?

It started out pretty simple and kinda obvious, but I kept making it slightly trickier every time. The first one's pressure plate was in a hallway so there was an obviously raised tile, but the second one's was in a room that had a completely trashed and broken tiled floor. Noticing a single raised tile was much trickier, so they had to look for the pinholes in the wall. But then the third one was in a similar room but that also had hundreds of pinholes in the wall, so the solution that time was to look for the pinholes with cobalt residue around them. Then, the fourth trap was a bit more like the first one in the hallway, but the pressure plate was placed directly underneath a doorway rather than in the middle of the corridor. A player who thought to inspect the door would definitely notice that it was weirdly flush with the ground, which was an inch or two higher in that one spot than in the rest of the hall (every other door in the dungeon had a distinct gap at the bottom, which players had already noticed), so they could have realized that it was a pressure plate. See how they have just enough clues to be able to make educated guesses about when it's worth the time to search, but it's also not just an easy "find the traps" button?

I think that alone is a pretty good foundation for traps being used in a fun and interesting way. I've acknowledge other possibilities of course. Sometimes traps are randomized and that can work. Sometimes you use the Angry GM's "CLICK!" rule to give players a bit of extra agency. Sometimes the trap uses a huge, complicated, clockwork mechanism and it's better to just let them make an INT check than to try verbally talking it out. But otherwise, consider how much of a dungeon's design can come down to just thinking logically about who owns it, what they're trying to protect, and how they'd go about it. If you want the players to treat the game world like a real place and think of it in those terms, then it only makes sense to design it that way yourself. It's a surprisingly reliable path to good level design.

6. Dungeon Resources
I've seen other Knave hacks that just copy and paste this stuff from Maze Rats but I've always felt that those tables didn't perfectly suit my needs. Too many tables for stuff that I don't need and not enough tables for stuff that I do, you know? Every DM is different, of course. Here I tried to include the things that I find most valuable for designing the dungeon, coming at it from different angles.

For example, I didn't need a list of room types all that much. It takes up a lot of space and no list like that can ever be even close to exhaustive anyway. Instead, determing the purpose of the dungeon will automatically imply many of the rooms you'll find within. When I design a dungeon that's meant to be a prison, I start researching prison floorplans to get an idea about what sorts of rooms there should be. Same thing with a laboratory or a museum or a hospital.

However, I do think it's valuable to include a list of "dynamic room types", which I typically don't think of on my own. Like many DMs, my brain is very skewed towards always having plain, boring rectangular rooms. That kind of thing kills the fun in combat, and all it takes is some interesting terrain to instantly make it more engaging and challenging. Of course, there's about a million ways to play with terrain effects, but I felt that "room features/shapes taken from real-life architecture" was a pretty good base to fall back on every single time. Lava and tangles and stalactites/stalagmites are more situational, but bridges and staircases and mezzanines are universal.

I've written about dungeon size before, in one of my more popular (and short!) articles. However, when I write about "large dungeons" in these rules, they would still fit the description of a "normal size" as described in that article. Megadungeons are a topic I plan to cover in the second core rulebook of Brave, so don't worry that these rules and resources mention nothing about stuff like restocking the dungeon and competing factions and stuff.

Obviously layout-related tricks are important to me, since I want the navigation of the dungeon to be a part of the challenge. I find that a lot of old-school folks are a little too reliant on the same few tricks and could stand to be a bit more creative. So of course I started with the standard Jacquaying techniques, but then brainstormed a lot more from there. And I insist that dungeons do not need to have every Jacquaying technique to be good and interesting. You usually only need a couple to add just that little bit of extra spice.

Similar with macro-level challenges. All of them are great ideas, but it's very easy to have too many good ingredients clashing with each other in a dungeon. They get hard for the referee to juggle. Just having one or two or three is usually enough.

I'm proud of the trap generator. Not to toot my own horn, but I think it's better than the one in Maze Rats. There's nothing wrong with that style of content generation, where you just provide a keyword or two to spark an idea. But its list of "trap effects" will always be limited by how specific each one is. I think it's more valuable to list every way in which a trap could harm or hinder you in broad terms, and then force the referee to come up with a novel means of achieving that. Likewise, those 12 clues are pretty dang good. If each dungeon has one recurring trap type with one clue, and you reuse the same dungeon theme once or twice, then those 12 clues could potentially last you 20+ dungeons.

Lastly, I like micro-dungeons and I want an easy way to quickly generate them. I'm not a member of the religion that closely adheres to the 5 Room Dungeon formula, but obviously it has insight. But rather than those who insist that the 5 Room Dungeon is perfect for a full session of delicious adventure with a taste of everything, I actually don't treat micro-dungeons as being an isolated experience. I prefer the experience of going through multiple micro-dungeons, meaning that no single one needs to check all the boxes on its own. As I explain in my post on dungeon sizes, sometimes a medium or large dungeon is equal in awesomeness and fun to, like, 5 or 6 or 7 micro-dungeons sprinkled throughout a valley. Think of shrines from Breath of the Wild versus temples in every other Zelda game. They both have strengths.

7. The Dungeon Control Panel
Skipping to the appendices real quick, this is a crucial piece of the dungeoncrawl formula to me. I don't remember when I first had this idea, but it emerged kind of gradually. Essentially, I am now in the habit of creating a control panel like this for pretty much every dungeon I run (not counting micro-dungeons). I consider it as important as having a map and room key. It's so much easier than packaging a dungeon in a book and having page flipping. Page flipping is justifiable for content that you use situationally, like room descriptions. But those macro-level challenges aren't attached to any single room, so they need to be written down somewhere that'll be in front of you the whole session, not just on some page early on you'll have to keep flipping back to.


I'm sure lots of people have been getting by just fine either not using a dungeoncrawl procedure or using the B/X one for all their needs. But I'm not satisfied with fine. And as I mentioned in "Game Design vs Level Design," while good and creative Level Design is essential and can never be fully substituted, the more challenge and choice you can build right into the core rules themselves then the more effort you save having to come up with original level challenges. You usually can't reuse puzzles or boss fights, but things like light supply, encumbrance, getting lost, random encounters, and so on will always add to the challenge.

If nothing else, let's all work to get those control panels more commonly used by referees. It's one of the single biggest quality-of-life changes I've ever made for running a game.


Go to part 6: Settlements


  1. I'm intrigued by your approach to traps, and will definitely try employing the "concept iteration" style of trap design next time I make a dungeon.

    The example dialogue was helpful in visualising how you run traps in Brave, but I wonder what the WIS roll was? I'm assuming it was a success, based on the information given by the Ref, but what would the player get if they failed?

    1. Great question! If they had failed the WIS check, the referee probably would have just said "you don't notice anything notable" or "No, definitely no gears or runes or anything."

      Thus, less useful info to work with, but still not hopeless overall because of the obvious evidence they can piece together from the body already. Still a fighting chance, but they'll probably have to suffer through another trap themselves before they get a clear picture.

      But it's worth saying that this step also would have been quite different if the players had asked about something more relevant than gears and runes. If they had specifically asked for bloodstains or something weird about the brickwork, then they'd probably automatically succeed and no wisdom roll would be needed. They just hadn't thought of those.

      So basically, I include a roll when they do something that COULD reveal another clue, but isn't guaranteed to. In this case, looking for similar clues in the same general area seems like it could plausibly reveal something they weren't even looking for (e.g. blood) but they could have totally overlooked it if their focus was more on gears and runes. Thus, uncertainty = roll time.

      I hope that makes sense.

    2. That makes sense, thanks :) Enjoying this series!

  2. That second Castle Blackmoor map is not "a streamlined flowchart version of the first." It's a map of the very large tunnel system around the primary dungeon.

    See the dotted lines labeled "LEVEL 4 BELOW BLACKMOOR CASTLE" in the aspect ratio of an 8.5 x 11 sheet of paper? That's where the first map (the Level Map) fits into the second map (the Tunnel Map).

    (Notice that the first map has a scale of 1 square = 10' and the second map has a scale of 1 square = 30', which is why the dotted line is 1/3rd the size.)

    See the tunnels running off the edge of the Level Map? Note how those line up to the tunnels on the Tunnel Map. (It's unclear why the two secret passages in the Level Map are indicated. The lack of the tunnel running north from Area 1 of the Level Map is likely just an error.)

    1. Aww jeez. When you spell all that out I see it plain as day. I goofed.

      I'm surprised that this post is getting any views since it's from a defunct draft of an old project. But I'll edit the post with a note just in case some other wayward traveler finds their way here.