Happy Megadungeon Monday!
We’re in an odd place in our Megadungeon design. Last time, we discussed the idea of building our toolkit – our piles of mechanics – so that when it comes time to design individual days of adventure and encounter spaces and whatever, we can mostly just assemble our bits and pieces. And that leaves us in the position of having to build piles and piles of things and stuff. We need to build monsters and magical items and hazards and obstacles and gates and keys and discoveries and traps and things.
But, that isn’t all, because we also have a few bits of unfinished mechanics floating around that we’ve also said “we’ll worry about later.” Well, we’re reaching the point now where we can’t just keep saying “later” anymore. And one of the biggest mechanics that we’ve left unfinished is the thing we’re calling the “wandering monster mechanic.” So, let’s see if we can figure out how that thing is supposed to work.
Encapsulation and Designing Around Nonexistent Systems
Way, way, waaaaayyyyyy back, we decided that we wanted to have a wandering monster mechanic. Sort of. I mean, we’ve been calling it that. But we’ve also been pulling off a little bit con. Because we never really made any decisions about how it might work except for the idea that it would involve “rosters” of some kind. Seriously. Think back. What have we really said about the wandering monster mechanic?
Nothing, right? Not really. The only thing we really ever did was say “we’ve got these particular problems and the best way to solve them is some kind of way of make monsters randomly happen sometimes in the dungeon.” And, after that, we took it as read that we would have such a mechanic. We accounted for it in our experience calculations and concluded that it could potentially throw everything off. And that’s why we made random encounters – or rather defeating monsters in combat – worth a paltry 10% of the XP that D&D otherwise instructs us to award. And, when we designed our progression, we made some assumptions about just how many random encounters would probably crop up.
And that’s actually a really handy trick in game design. Or rather, it’s a really handy trick for design in general. It’s an idea that comes from computer programming – and particularly an approach called “object oriented design” – that’s called encapsulation. The basic idea is this: any complicated game system, like, say, a megadungeon, can be seen as the sum total of a bunch of different bits and pieces. So, we’ve got a map divided into zones and encounter spaces. And we’ve got gates and keys. And we’ve got enemy rosters. And we’ve got discoveries. And we have rules for exploration. And we have rules for combat. And so on. Each little separate piece has its own job to do.
The thing is, if we tried to design a whole goddamned megadungeon all willy nilly, it’d be a mess. We’ve talked about that before. But we’ve been very systematic. And part of that systematic approach has been looking at each individual piece of the design as its own thing. When we designed the experience progression and figured out how many encounters would exist on our map, we didn’t think about how it would relate to the combat rules. Hell, we didn’t even assume those encounters would be combats. We just figured that day 1 would have six things that would occur in fixed locations and would be worth XP when the party dealt with them. In point of fact, the same chart could easily have been used for a character-driven murder mystery filled with interrogations and clue-hunts. The gates and keys could have been leads in the story. Instead of Day 3 ending with the discovery of the skeleton key, it easily could end with the discovery that the murderer was a patron of a particular tavern and lived in a certain neighborhood. That would open up a whole new slew of points of exploration.
And that is the idea behind encapsulation. Each part of the system is its own, separate thing and it cares as little as possible about the rest of the system. The XP and plot progression doesn’t care about the actual plot. The plot doesn’t care how many encounters are worth how much XP. The combat system doesn’t care about enemy rosters. And so on.
Now, of course, things DO interact. For example, the plot progression tells us something about the levels of the challenges the party will face. And those levels will inform them monsters on the rosters that play a role in the story. And those rosters will provide the monsters for particular encounters. But, encapsulation also encourages us to design things to interact as minimally as possible. For example, a roster is just a list of monsters belonging to a particular faction. An encounter space or a combat encounter doesn’t care how the rosters work or how they are organized. All they need is to receive monsters off the list.
This may not seem like a big, clever point, but allow me to demonstrate how useful it actually is. Suppose we decided, halfway through designing the whole dungeon, that we didn’t like kobolds after all. Instead, we felt the dungeon should feature gnolls or evil halflings or lizard folk or drow. If we just designed the dungeon one encounter at a time, we’d have to go back through and redesign everything. But, with encapsulation, all we have to do is design a new roster. We’d make sure it matched the previous roster’s level and filled the same roles as the previous roster, but in theory, nothing else about the dungeon would have to change. We could just replace all the monsters from Roster A with monsters from Roster B.
For that matter, we could reuse a lot of the work we’ve already done to design a whole different dungeon. The XP progression could be entirely the same. We would just change the gates, keys, plot, and factions. Same structure, new story.
And it also allows to design stuff piecemeal. We can design monster rosters one week, magic items the next, map out areas of the dungeon next week, and come up with hazards the following week. We can bounce back and forth.
Of course, in order for this to work, we do have to have some sense of what the different pieces DO and how they interact. That way, we can leave space for them to interact as we design things.
For example, we have this vague idea of organizing our dungeon denizens by roster or faction. We’re not sure how we’re going to come up with those lists or how many monsters of what type will be on each list. But we do know some of the things rosters will do. First, they will provide assets for encounter building. So, this encounter space will have a “level 1 kobold encounter” and that space will have a “level 9 demon encounter” and we can use the rosters to fill in the details later. Second, they will provide a sense of progress by becoming “active” or “inactive.” So, when the kobolds are defeated forever, the kobold roster is turned “inactive” and never provides encounters again. And when the party opens the floodgates and accesses the lower halls, the “demon roster” will become “active” because those beasts can again wander the ruins. Thirdly, those rosters will provide the monsters for “wandering encounters.”
With just that understanding that rosters are a thing and this is what they will do, we can work as if they already exist. Hell, I could map the whole f$&%ing dungeon right now and just write notes like “level 3 plant monster encounter” in this room or “level 8 demon encounter” in that room and fill it all out later.
The same with gates. I don’t need to decide all of the ways the flow of water blocks access or allows access to parts of the dungeon. All I need on my map is a note that says “blocked until water flows” and then, once I figure out how water actually works in the dungeon, I can fill in that room.
If you’re familiar with the idea of “procedural generation,” you might already realize that what I’m doing is building a way to procedurally generate a dungeon and then generating it. Except, instead of writing a computer program to generate the dungeon, I’m using my brain to generate the dungeon using the exact same tools.
And THAT is why we’ve been able to talk about a nonexistent wandering monster system and a nonexistent roster system, knowing both of them would interact, and knowing what they would, but not bother figuring out how the systems actually work.
Wandering Monster Systems Are Stupid
Now, let’s switch gears. Because it’s time to stop pretending that the wandering monster system exists and time to start building it. And the first thing we want to recognize is that wandering monster systems are pretty crappy. When you think about wandering monster or random encounter systems from bygone eras, they all look pretty much the same. And the system is actually kind of kludgy and stupid when you get down to it.
Here’s what I think of when I think of wandering monsters and random encounters in D&D.
First, you have a time interval. Every time a certain time interval passes, you roll a die to determine if a random encounter happens. There’s some fixed chance, right? If one happens, you pull out another table and roll another die. And that will tell you what the party actually encounters. And often, that entry will entail one MORE die to determine how many monsters show up.
On top of that, the chance to encounter random monsters is modified by the party activity. Either the chance to have a random encounter is modified based on party activity. If the party is being loud, for example, they might take a +1 on the die to see if an encounter happens. Alternatively, there’s a list of actions the party might take that will trigger an immediate roll for a random encounter. Breaking down a door, for example.
I have two problems with this system overall. The first is that timekeeping is a pain in the a$&. No one wants to be bothered with it. Timekeeping sucks. And timekeeping in our dungeon sends the wrong message. We don’t want the party afraid to take their time to explore the dungeon. We just don’t want the party staying in place for too long.
The second is that the amount of die rolling seems unnecessary. There’s up to three different die rolls to determine a random encounter. And it seems like we could economize somewhat.
What DOES work well in that system is the idea of random encounters being “triggered” by certain events. That is to say, “when the party does X, Y, or Z, roll for a random encounter.” The problem is, such a trigger list can get really complicated if you let it. Any system that we’re asking the GM to use has to be simple enough that the GM can eventually start to remember it in their head. If there’s ten things that can cause random encounters, the GM will forget the list. But if there’s three things, the GM can be trusted to handle that. Especially if they are pretty simple things.
But let’s forget everything we know about preexisting wandering monster and random encounter systems and start with a blank tabula rosa and see if we can’t reason out a good system for our dungeon.
What Our System Should Do
Whenever you design any sort of mechanical system, the first and most important thing you want to do is figure out exactly what the system is supposed to do for the game. That helps you figure out ways to implement the system and it also helps you identify unintended side effects. For example, suppose we didn’t think through our wandering monster system but simply made it time based like the systems of old. If players figured out the GM was tracking time and throwing dice for random monsters every ten minutes, they would feel rushed. They might not be willing to spend time poking and prodding an interesting room or reading runes or learning the history of the dungeon. That’s the exact opposite of what we want.
So what DO we want from our random encounter system.
First of all, we want the dungeon to feel alive. And we want to accomplish that in two ways. First of all, we want the dungeon to repopulate itself. When the party clears a room of nasty kobolds and then returns to the same room later, we want there to be a chance giant rats or carrion crawlers or something else has moved into the room. Second of all, we want the party to get a sense that the dungeon environment is changing in response to their explorations. Once they’ve defeated the kobolds, they shouldn’t encounter anymore kobolds. Once they’ve opened the crypts, we want them to see undead wandering around.
Second of all, we want the party to spend as much time exploring the dungeon as possible. We don’t want them to spend time idle. We don’t want them to sit around doing nothing. And we don’t them retreating from the dungeon for days or weeks at a time. We want them to push forward. We want them to feel like they can explore, but we don’t want them to feel like they can sit on their a$&es.
Third of all, by the same token, because we’re building shortcuts and alternate paths into our dungeon, we want backtracking to hurt a little. Sure, backtracking is a part of the game, but we want the party to only backtrack as much as they have to find new areas or to find shortcuts and hidden paths. When they find a shorter way between the entrance and the current area of exploration, it needs to feel like a reward.
Fourth of all, we want a bit of verisimilitude. In order to make the game feel like it’s actually representing a real world, we want the dungeon to feel like it responds in a logical way. So, if the party stands around loudly arguing or ringing a dinner bell and screaming “here monsters, come and get it, fresh meat,” we want something to show up to kill them.
Fifth of all, we also want a wandering monster system we can play with in the game. That is to say, we might create traps and hazards that specifically summon random encounters. So, we want a system we can trigger in the game. We want to be able to tell the GM “if the party upsets the shriekers and they start making noise, roll for a random encounter.”
And that is ALL we want the random encounter system to do. If we let it do anything else, there’s a danger of unintended side consequences.
Trigger Warning: Random Encounters
Essentially, looking over that list, we can see that basically, we need a random encounter system that is triggered by a few simple contingencies. That is to say, if the party takes certain actions, that will trigger a check for a random encounter.
For example, whenever the party enters a previous explored area, we want a chance of a random encounter. That, by itself, touches off most of our goals. It repopulates previously explored areas, it doesn’t spawn encounters if the party is exploring new areas, it makes backtracking painful, and it makes the dungeon feel alive. See, the party will never know when they wander into a NEW room whether an encounter was planned or not. So, a random encounter in an unexplored room doesn’t look any different from a fixed encounter. But having encounters pop up in rooms the party previously explored and emptied shows that the dungeon is changing.
Second, if the party takes a short rest or otherwise stops doing anything for an hour or more, we want a chance of a random encounter. That will keep them moving.
Third, if the party does anything the GM deems as loud or likely to attract a monster, the GM can roll a random encounter. That covers the verisimilitude.
And fourth, if the text of the adventure says “check for random encounters,” the GM checks for random encounters.
And that’s it. No time keeping. Nothing more complicated than that. Enter a previously explored area? Check for random encounters. Short rest or otherwise stand around for an hour or more? Check for random encounters? Be exceptionally loud or stupid? Check for random encounters. That’s a pretty simple list the GM can keep in his head, though we’re going to come back to that idea in a moment. Because the “previously explored room” thing is actually secretly more complicated than we might first realize.
For now, let’s go with that, though. Three simple triggers: previously explored room, short rest or stand around, be exceptionally loud or stupid. And we’ll add the condition that random encounters only happen in unoccupied areas. So, if the party is in the middle of a fight, that isn’t going to draw another encounter. That’s just a huge, unfun pain in the a$&.
Rosters, Rising Tension, and Dice Economy
Now, here’s where things get interesting. So far, all we’ve decided is that we check for random encounters under specific conditions. But we haven’t figured out how to check for random encounters. But we do know a few things: random encounters are tied to “active” and “inactive” rosters, we want as few die rolls as possible to check for random encounters, and, broadly speaking, as the game goes on, we want the number of random encounters to rise as tension rises.
First, let’s think about our rosters. So far, all we’ve thought about in terms of rosters is that are lists of monsters grouped by faction. So far, we’ve been thinking about them as a design tool – a way to design our dungeon – but what if they are also a tool for the GM. That is to say, what if the rosters are actually THINGS. Like, they have stats.
Now, I’m talking about anything complicated like faction hit points and zones of control or anything like that. But we already know that every roster has one stat the GM has to track: active or inactive. And that means that the roster – and I’m going to start calling them factions from here on out to give them more of a reality in the game – that the faction exists as a game object that the GM has to be aware of.
So, what if each faction has a list of random encounters. That is to say, the Kobold faction has a list of a dozen or so random encounters. When a random encounter occurs for that faction, the GM simply pulls one of the encounters off the list and uses that. If they are well-organized and presented, that can make it very easy to quickly put the encounter in the game. Say, if each “encounter” has a half-page spread. The GM can just flip to that page and run the encounter from it.
The GM can reuse random encounters, since they are really just groups of enemies. The players probably won’t care. They might not even notice.
But, now here’s the next bit of magic. We want to make the random encounter system as easy to implement as possible. Instead of remembering a specific rule like “on a 1-2 on a d10, there’s an encounter, now roll on some random table to figure out which faction, and then roll to pick an encounter for that faction,” what if we could somehow meld some die rolls together.
For example, what if each faction had a number. (1) Vermin, (2) Kobolds, (3) Undead, (4) Plantoids, (5) Demons… etc. That’s just part of the stat. Each time the GM checks for a random encounter, they roll a die. Whatever number comes up, that’s the number of the faction they will encounter. And if that faction is inactive, nothing happens. That means all the GM needs is a numbered list of the factions. He rolls, say, a d10. It comes up a 4. That means plantoids. Plantoids are active, so a plantoid encounter happens. If a 2 comes up, that means kobolds. But if kobolds are dead, there’s no encounter. The chance of the encounter is ALSO the type of encounter.
Furthermore, the more factions that become active, the more dangerous the dungeon is to wander. Because we have some optional factions the party MIGHT destroy, that means they can actively reduce the chance of having encounters just by eliminating some factions.
Because we know roughly when different factions will become active in the story, we can also design our factions around specific levels. Vermin will always be low-level encounters. Thus, they are active from the beginning. The undead start wandering around level three. So they can be more dangerous. The demons don’t start wandering until the party is around level 7 or 8, so we can build those encounters to those levels.
That seems like a really simple, economical way of handling random encounters, doesn’t it? When the party does one of three things, roll a die. Whatever the number, check if that faction is active. If so, use one of their encounters. Otherwise, nothing happens.
Of course, this revolves the idea of using a much larger die than the number of factions. So we might use a d20 knowing that there are 10 or fewer factions in the game and, at most times, fewer than 5 will be active. That means the party will have about a 20% of having a random encounter in any previously explored room. Let’s see if we can think through how that will play out.
Each time the party leaves and reenters the dungeon, they will have to pass through some number of previously explored ADVENTURING DAYS. And here, I’m referring to ADVENTURING DAYS the way we’ve been using them as specific chunks of the dungeon space. If the party takes an efficient path as they pass through a previous ADVENTURING DAY, they will probably pass through four or five ENCOUNTER SPACES. That means, for each previous ADVENTURING DAY they pass through, they are likely to have ONE random encounter. If you look closely at our map, you’ll notice that the interconnections, shortcuts, and backtracking mean the party will rarely pass through more than TWO previous ADVENTURING DAYS to continue their explorations. Again, that assumes they take efficient paths. And that means, each day of continuing exploration means ONE TO TWO random encounters are likely.
That means our system actually jives very nicely with our plans. Assuming we have 10 total factions, limit active factions to about 5 or fewer, and use a d20, the chances of random encounters will be pretty much on par with our projections if the party is smart and efficient. It’s not perfect. Random encounters may be slightly more common than we anticipated, but we can compensate by ensuring that random encounters are always lower level than the faction level would otherwise expect AND that they are easy for their level. That makes them nuisance encounters that bleed few resources unless the party is foolish, wasteful, or inefficient.
Don’t Be Gone Too Long
This system is nice and all, but there’s one last goal it doesn’t address: it doesn’t discourage the party from wandering away from the dungeon for too long. We don’t want the party spending weeks in town ignoring the dungeon. And, if they do, we want the dungeon to get more dangerous. Well, we can build a very simply modification to the system.
If the party spends too long away from the dungeon – and, until we figure out things like travel time and where the local settlement is, we can’t say how long is too long – we can roll a different die for random encounters. Imagine, for example, if the party is gone for two weeks, instead of rolling a d20 for random encounters, the GM rolls a d10. That means that random encounters are twice as likely, especially if many factions are active.
So, we have a modifier to the system. If the party has been gone “too long,” roll a d10 instead of a d20 for random encounters. After the party retreats and returns, it can go up to a d12. After the party retreats and returns again, it goes back to a d20. Sure, the party COULD game the system by having one encounter and running away to let the die scale back up, but they probably won’t figure out the system to that degree.
Encounter Spaces, Factions, and Trying to Make Life Easy
So, we have the bare skeleton of a random encounter system. Whenever the party enters a previously explored room, takes a short rest, or does something loud and stupid, check for random encounters. Roll a d20. If the number on the die corresponds to an active faction, the GM puts a random encounter from that faction in the room. If the party has been away too long, the die roll is a d10 instead. The next day it becomes a d12. The day after it becomes a d20 again.
But what actually happens when a random encounter spawns. And what constitutes a “room?” Well, fortunately, we’ve divided our dungeon into arbitrary units called “encounter spaces.” An encounter space could be one room or three connected rooms or a series of tunnels or whatever. But because these are overt divisions in the dungeon that will be keyed for the GM, the GM knows exactly what a room is.
If the party enters a space and the GM determines a random encounter is present, the GM can simply put that encounter in space. If the party instead does something like resting in that space, the GM has a bit more discretion. The encounter COULD wander in on the party while they rest. But if the party barricades themselves in a small room or other subsection of an encounter space, the random encounter could be waiting outside the door or in the hallway or it could try to break down the door because it hears the party or whatever. We will leave these sorts of details up to the GM. Likewise, if the party is being loud or stupid, the GM can decide where and how to spawn the encounter within the encounter space.
Now, we’ve talked about creating safe areas in the dungeon where the party can rest without danger. We can flag specific encounter spaces in the dungeon as “never having a random encounter.” Thus, if the party rests in Room X or is Loud and Stupid in Room Y, they are never in danger of getting jumped by plant monsters. But now we wander into an area of unintended complexity: flagged rooms.
See, here’s the thing: we can flag rooms as having or not having random encounters. But we’re also flagging rooms as explore or unexplored. Remember, players only have random encounters in previously explored rooms. And, as simple as our random encounter system is, that adds a layer of complexity. But one that we can easily deal with at the product level.
Here’s a question: players have character record sheets to keep track of their characters; is it unreasonable to provide the GM with some sort of adventure record sheet? Or maybe a few sheets. For example, a random encounter sheet that provides a numbered list of factions, a bulleted summary of the rules, and then a checklist of encounter spaces that the GM can check off as “explored”? That same checklist could also gray out encounter spaces that never have encounters.
That’s a way we can make life easier for the GM. Even though our system is pretty simple, we can provide a tracking sheet that makes it easy as possible for the GM to work with it. And that tracking sheet also allows for another option. If the GM wants to PREROLL for all of the previously explored rooms to see if there are encounters BEFORE the next session, they can do that. The GM can use the system at the table to determine random encounters on the fly OR use the same system to restock the dungeon between sessions.
Sure, that’s a presentation issue. But there’s no harm in thinking about it now.
Is That It?
Now, it may seem a little odd to pronounce the random encounter system “done” at this point. But it is. At least, as done as it needs to be. And frankly, we could have saved most of the mechanics for later. But looking at it has helped us figure out a few things. For example, it tells us approximately how many factions we have to deal with and how many we can keep active at one time assuming the party handles the dungeon well. And it has also helped us cement the idea of rosters and turn them into factions as a game construct. And while there are a few specific questions left to figure out (like how long is too long), for the most part, the system is basically designed. We know how it works and we know where it interacts with other parts of the game. And we know now we can construct traps and encounters in our dungeon that “call” the random encounter system in various ways.
So, that’s that.