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.
“blank tabula rosa” – Did you deliberately write that to infuriate us?
At least he didn’t say “Blank Tabula Rasa.” Now that would have been redundant.
I’m betting auto-correct had something to do with that.
Functional Design (FD) is good but Object Oriented Design (OOD) is a terrible thing.
Functional Design encourages independent parts that minimally interact with other parts, allowing for encapsulation and other good things to happen.
Object Oriented Design encourages generic answers that are then applied to problems. Rarely is the generic answer also optimal. OOD allows large teams to work on large problems, so AN answer beats NO answer- but for one person working on a design, even a large design, it can be problematic.
Angry has specifically called out using generic monster stats under “new” monsters- instead, the monster should be designed from the ground up. This is functional design. (It can share mechanisms with other monsters, such as the “monster within a monster” Angry designed at one point, but the mechanism should be minimal- a specific mechanism to fit a specific use.)
Saying each faction is the same, goes into a table, can be swapped in and out, etc., is object oriented design. Things are already subtly lost, such as the ability to vary the reactions of factions- for example, have the demon faction called by magic use and the plant faction called by water & nutrient availability in a room. Angry has already alluded he expects other bumps he’ll have to iron out- I propose that some may be due to OOD being used instead of FD.
In my experience as a software engineer OOD goes wrong when people don’t understand what they’re doing or why they’re doing it.
“have the demon faction called by magic use and the plant faction called by water & nutrient availability in a room”
The whole series has been written under the assumption that the amount of tracking, rolling, etc should be kept minimal for the GM. Imagine your suggestion in practice: Unless you want to let the GM handwave this (which any GM can chose to do, anyway), you need to rebalance probabilities accordingly due to encounter space properties.
These things can be done by a computer administering a dungeon. For a GM, that’s a lot of hassle for an outcome that might never be seen, just like making the GM play a mini-game off-screen about the factions that the players never see. It’s one of the more if not most expensive options of creating the illusion of the “alive dungeon” and according to the original design goals laid down for the series a clear failure and basically random over-engineering of a detail that will not matter much in game.
It also produces in all likelihood a rather unconvincing outcome. D&D groups use magic _all the time_ – this is D&D after all. This would factor in the demon faction too heavily. For some factions there are no logical “enhancers,” creating more differences between factions to handle. And so on.
Beyond this – this is a discussion in a roleplaying forum. Just because Angry borrows a concept from software design do we truly need to geek out in a way that basically constitutes an off-topic discussion of how software should be designed, then by strained analogy transferring it over to game design, then declaring some things as “shoulds” that are rather arbitrary personal choices? “monster should be designed from the ground up” is not an universal truth after all – for a mega dungeon designed by one person you need to invest your development time in a sane way. Overengineering too many details for little gain when looking at the whole will just doom the whole project of never seeing the light of day. If we must use such analogies, this is “premature optimization” – trying to craft every little piece in an assumed ideal way without considering the interaction of all pieces, without identifying this detail as important first (like really fixing something or really adding fun during playtests), and without consideration for the fact that crafting many perfect little pieces does not necessarily make a perfect product altogether.
Okay, okay. Fair enough, I fell into the same trap! 😉
Well, I’m talking control system design, not software- which I claim IS what Angry is doing, not an anology. I agree with everything you talk about as standard goals- simple design, minimal control efforts, a top down approach to design. However, I will ask that whatever Angry’s reasons were for designing monsters that way, is it perhaps reasonable to think that factions (groups of monsters) may share that same design goal?
Long time reader, first time poster! Had a though about the economy of dice: wouldn’t it be more economic to create a d100 table, with the 10s result representing factions and the Ones result representing specific encounters? That way you have a single roll that determines both which faction and which specific encounter while maintaining the general approach of Active/Inactive factions determining whether an encounter occurs.
Nothing’s stopping you from rolling both the faction d20/12/10 and encounter d10 at the same time
Since the d100 is in practice 2d10s of different colours (or one with extra 0s on all the faces), I find it a little counterintuitive to call it a “single” roll. Sure, some people have the golfball version, but that’s a novelty.
This also constrains your list of encounters per faction to fit within your d100 space, which – if the baseline is a d20, with each faction getting 1 number – means only 5 encounters per faction by default, plus no ability to adjust the dungeon for extended adventurer absence by swapping the d20 for a d10/d12.
I can see where you’re coming from, especially if you’re playing online and can just roll a d47 if that’s the probability space you want to work with, but you do lose some degrees of freedom with that “single” roll.
I don’t understand why Angry is including random encounters at all, considering how he’s said time and again that random encounters are unfun and basically qualify as a punishment.
Is there no other system that could be put in place to accomplish the mentioned goals? Or does this just handle the verisimilitude better than the other options (whatever they are)?
I think that’s just it, though. From fairly early on in the design process, he decided that Wandering Monsters were a punishment. So clever characters who don’t often backtrack or make the most of their time don’t necessarily suffer from this punishment.
The alternative would be leaving the rooms empty or having them “auto-stock” after a new faction shows up. This breeds a certain level of unbelievability and/or predictability. So yes, the Wandering Monster mechanic is a punishment, but it’s also a tool for immersion. Angry loves his immersion.
Clever players don’t suffer *much*. They still suffer, and the random encounters will still suck. And they’ll still give actually insulting levels of reward. And Angry did all of that intentionally to achieve a list of 4 things he detailed in this article. Wandering monsters mostly achieves them, but in an intentionally unfun way.
Necessary evil? Is there really no other mechanic or set of mechanics that could achieve this stuff? Angry’s said in these Megadungeon articles that players don’t mind contrivances as much as GMs seem to think, so why not allow some contrivance to justify a more fun mechanic?
I reckon the random ecounters will suck only if the GM sucks. That’s been my experience over the years I’ve been playing RPGs–and I began playing Way Back When.
Don’t those two goals conflict with each other? If the monsters seem like just a thing that happens in the dungeon, how will the players pick up on the ‘random encounters as punishment’ aspect?
Or is it expected that players will recognize this intuitively and clever players will figure it out more concretely?
Since the random encounters will use a similar faction list as the planned encounters the players will figure out very quickly that the randoms are giving 1/10th the EXP and loot that the regular encounters are, especially if you give EXP at the end of the encounter or an EXP tally sheet or a rundown of what discovery/encounter earned them how much EXP.
The punishment part is basically why random encounters works better.
Players will want to avoid random encounters, so if they’re a little smart, they will have to get how to minimize them : don’t stay away too long but (mostly) don’t rest in the dungeon, value shortcuts and backtrack only when needed.
The “minimize backtracking” part is a little puzzling to me, though. Of course, there is the incentive of XP for new discoveries and beating optional encounters, which counter-balance the burden of random encounters in previously explored areas. But that means the players will have to take notes of what could be hidden rooms BEFORE they know there’s a key (which will some times comes much much later). Explicit doors with physical/magical keys are easy to remember, but given the nature of most keys (killing the plant-monster, the water-rerouting, or even getting the fly ability), most of it is probably lost to them. So they will probably need to reexplore entirely some known areas to notice new paths, and the random encounter system is designed to make reexploration kind of painful.
Maybe that could still work since not every group is supposed to do 100% of the dungeon anyway, but still the incentive/punishment may be a little harder than necessary, and most group may end up not reexploring that much.
The backtracking thing confuses me as well. In general, not being allowed to go to certain places (or at least not allowing yourself because you want to avoid punishment) is the antithesis of exploration.
Anyone who has played both Final Fantasy, with random encounters, and Chrono Trigger/a Tales game, with monsters present and visible on the map that you can avoid, should understand the difference. In Final Fantasy you do not want to look around. You do not want to explore. Occasionally you will stand in place for several minutes at a time trying to remember the details of the room right next to you because you don’t want to walk there and trigger a battle.
In a tabletop, that almost certainly will translate to players standing there for half an hour or more, looking over the map they have of the dungeon and trying to remember the details of each room, instead of a 5 minute montaged sweep of them. And they’re going to miss a lot of things by not being allowed to re-explore them. And, if they’re anything like me, they’re going to feel resentful that they’re being punished for exploring AND for not exploring.
I think you’re overestimating how much of a punishment the random encounters will be. It’s about a 1 in 5 chance if the maximum number of factions are active, and it will be a short, not-too-difficult encounter. That wouldn’t put me off going back to an are a to unlock something new, personally. Risk/reward and all that.
My problem here is that it’s made a punishment out of a core mechanic of the game.
The game is fun, and enjoyable, and we’re going to punish players by making them play more of it?
Maybe I’m unique in how much I hate random encounters. They do nothing to advance the story, deliver lore, or encourage role play, and are usually mediocre as far as mechanical challenges go. They are overtly a boring waste of time. Not *too* much time and not *too* boring still sucks.
And I had somewhat expected Angry’s eventual article on his random encounter system to either bring up a brilliant system to make it not suck, or provide an explanation for why the suck simply has to be.
Kiqjaq, it seems to me that you are accidentally missing a few points that Angry is trying to explain. I apologize if I am wrong, but here are a couple of things that you may want consider:
Everything advances the story, since the story is about what the PC’s are doing and stumbling into kobolds that are searching for intruders is something the PC’s can do.
How the players choose to deal with the (kobolds/Situation) is exactly what roleplaying is, as Angry has stated in a previous article, and nothing stops the GM from adding a tidbit of information from another area the PC’s haven’t explored yet (either because they chose to avoid death hallway to certain death, or forgot death hallway even exists, or just to foreshadow what horrors/treasures lie ahead). Details like a statue or map from another part of the complex or even a book/note written in a language that may or may not be the kobold’s own can be found as treasure in the encounter’s pockets.
Again, you are free to disregard this but I think your understanding and games can be made better (or at least, hopefully not worse) with this information.
Also, the point of random encounters in the dungeon is for realism. No tribe of humanoids is going to just sit in the same room/area waiting for things to happen, and vermin or animals will prowl around looking for scraps. Players will expect these things (without ever realizing that they are Expecting these things), but the crappy EXP per encounter keeps them from clanging down the hall with a marching band to try and get to level 20 instead of searching the dungeon.
Meh. Those are Angry’s definitions, not the ones we lowly normal people use. Roleplaying is the talky talky bit and nothing more. Story is the sum of the plot beats and nothing more. Etc. (Angry’s definitions are probably more useful, but human communication isn’t based on logic.) Plus the random encounters aren’t allowed to have any cool lore drops as I understand them, because Angry already has a Discovery category figured out with calculated numbers and XP rewards, and I don’t think we want to leave it to pure chance whether or not those actually get used.
And realism is highly overrated. If I wanted realism I’d go outside. *cough* Anyways, all that’s needed for realism is that the enemies behave appropriately. Encounters that move are good for that, yeah, but those encounters don’t need to be punishment. You could simply have the “real” encounters, at least the ones that aren’t terrain dependent, change location occasionally. Or even script a few encounters so that they happen in previously cleared rooms.
To me, stocking the dungeon with an infinite number of kobolds is the opposite of realism. If there are only ~50 kobolds in the temple (or whatever), then why can the PCs fight 200 of them if they walk around enough?
“To me, stocking the dungeon with an infinite number of kobolds is the opposite of realism. If there are only ~50 kobolds in the temple (or whatever), then why can the PCs fight 200 of them if they walk around enough?”
Dude, you should really look at this article from this awesome person:
https://theangrygm.com/schrodinger-chekhov-samus/
TL;DR – In a Dungeon, the player do not know how many monsters there are untill you, the GM, tells them so. So untill they defeat the “source” of the kobolds, you can have as many as you need in your dungeon.
Of course, Angry’s system does not imply that EVERY room the players backtrack in to will be repopulated, and that it would be kobolds. But that COULD happen. And as a GM, I think that is awesome! And of course, if I feel that it is breaking the game, I can just skip it or chage for other faction. After all, I’m not bounded by the rules.
You skip encounters that don’t involve interesting choices or affect the player in some way.
Encounters that don’t involve interesting choices but affect the player should be glossed. (Going shopping, etc)
The story isn’t affected by the 100th kobold you slaughter, and that kobold doesn’t offer a player a chance to make interesting choices about his character’s actions.
I’m talking myself around to the random encounters being, after about the 3rd time a particular one comes up, ‘The room has a group of wandering kobolds in it. What’s your strategy [fight] [sneak] [parlay] ? ((roll)) Ok, you successfully dealt with them / you fail to deal with them, and suffer 2d10 hp damage while murdering them. Moving on.
It seems to me that a more efficient way to handle “restocking” would be to have a high (>25%) chance to restock a room if it has been vacant for a while. For example if players backtracked through rooms of this days or the previous days adventure path, the rooms should be still clear. But if they come back to Day 2 on Day 5 or so they should find that something has colonized the now vacant room
The more you have to track, the less efficient it is. Efficient is not the word you are looking for.
It will largely depend on how well things are called out. If there’s a comment about the walls being overgrown with vines, that would have the problem, but if the description is of a doorway through which an impenetrable thicket of thorned vines are growing, then they’ll likely have it marked on the map. Considering Angry’s focus on making the discoveries feel like a major reward, I’d imagine he’s angling for the latter. I wouldn’t be endlessly surprised if at least one was blocked weakly enough that the party could get through early to get that pavlovian action going in the party’s head. Similar situation for flight, you can call it out, and maybe make one balcony or whatever accessible with a grapnel and line (and potentially a bit of puzzle solving)
So glad this series is back again. I’m loving the thought process and more importantly the articulation behind each article. I’m learning so much.
One thought on the “Away too long” mechanic.
If you’re already providing the GM with an ‘adventuring sheet’ why not say that the next [x] random encounter rolls use D10 and leave it at that? The sheet will help GM’s track that, and you can pick any number you want, and can apply modifiers if you feel it benefits the game overall, like 5 + the number of weeks the party is away from the dungeon.
Another option is that if you are already developing the adventure with the concept of ‘adventuring days’ as a (more or less) self contained segment of the dungeon, the ‘Gone too long’ mechanic can be something like “Use D10 for all random encounters for the next adventuring day”. Or next 2 ‘adventuring days’, or whatever you want.
It is amazing how you seems to make all sorts of vague ideas, thoughts and gut feelings of mine tangible and accessable. Maybe thats why your right way of gaming seems agreeable to me, on some uncouncious level it’s all familiar to those notions in the back of my mind and the floor of my gut that i have not been able to put into words.
I think it is absolutely wonderful that you are taking time to teach us all your way of gaming.
As i have stated before i plan to use your megadungeon series as some sort of blueprint for creating a campaign, because we all know by now that any adventure is a dungeon and if that is true then it follows that a series of adventures making up a campaign is a series of dungeons or one big mega dungeon. Boom. love it!
And i’m even gonna change the genre from fantasy to sci-fi and from dungeoneering to spacetraveling in a famous warmace manythousand setting and use planets/systems/spacestations as adventuring day areas.
the devil will be in the details, figuring out the exact gates, keys etc… I might have to alter the progression chart as character progression is completely different than d&d so im gonna have to make my own progression meassurements. oh well now im droning on ..
Nice to see some of the blanks filled in.
A comment about the random encounters in new rooms, though – surely the players will know the difference between random encounters and fixed encounters, since the fixed encounters will be worth full experience and the random encounters won’t?
I imagine that wouldn’t be a problem from a game perspective – if anything it teaches the players that combats in new rooms are the only ones worth full experience. It might affect immersion, though, unless there’s a clear distinction in-world between the wandering monsters and the fixed encounters.
I can’t believe how addictive is this series of articles! Thanks Angry.
If I get it right, random encounters are mostly there to teach the players that some behaviors are better than others (finding alternate exits over backtracking, for instance). These are punishments for being loud, stupid, slow or inefficient. However, aside from seeing their resources taxed (which regular encounter achieve too), the only way for players to know they’re being “punished” is the amount of XPs earned for the encounter.
Some DMs, though, only give XPs at the end of a session, some others before long rests; some don’t even hand out XPs, using the milestone system.
In those cases, I wonder if random encounters would ever be seen as a punishment, as it would be blended with a bunch of regular encounters.
I mentioned earlier but if you give a rundown of what earned the group Exp that session they will catch on to the punishment, even if it is a little bit more bookkeeping on your end (though not much more than keeping track of what Exp yielding Encounters/Discoveries they have passed).
You could just tell your players, up front, that random encounters are worth much less than regular encounters?
I can’t speak for other groups, but I expect my players would probably just say “oh, that’s a cool system”, and accept it as given.
Don’t you want to only check for random encounters for entering areas that haven’t been explored in the current adventuring day? So that the players can retreat from the dungeon for Long Rests without running into stuff having re-populated behind them?
If you don’t check for random encounters on ways they have already explored that day then the group doesn’t have much incentive to try and search for a shortcut back, though if they happen to stumble over it then they would gladly take it. Removing that would eventually have them know that the way out is always safe, as one of them will always figure it out, and then they can just take the whole dungeon one encounter at a time and blow all of their resources/spells/mastery-dice/what-have-you on the fight because they can always retreat and heal before continuing. That removes a lot of the tension of “can we make good progress today and still have enough resources to get to camp?” and only removes bookkeeping for the GM, the same bookkeeping Angry is trying to minimize already.
To me that’s too much loss for little gain but your mileage is free to vary.
So I’ve been thinking about the rosters, and what they could specifically be, like level range and so on. Angry has mentioned a few of them, but there are still just as many blank spots, and I’ve been brainstorming a bit.
We have rosters one through six from Angry with
1. vermin
2. kobolds
3. undead
4. wasps/burrower insects
5. plantoids
6. demons
The other ones I’ve been able to come up with have been
7. elven/dwarven magical defenses – I’m imagining dwarven-made elf-enchanted and carved turrets and patrolling golems. They fit with the lore pretty well, and sound like they could be interesting.
8. Some sort of crystal-themed roster. The mined crystal pieces scattered about the ruins by the elves and dwarves reach a critical mass after growing enough and animate? Could be dead bodies with crystals growing out of them, it could be rubble/furniture with the crystal holding it together?
9. Underwater encounters will need to be a thing, but I don’t know if Angry will have them be their own roster or just have underwater encounters for each roster and use them and needed.
10 is a little more mysterious for me. I can’t think of anything else that would really be thematically appropriate. I think these 8 (9?) might work out pretty well anyway, especially after we pull out the big plan and start looking at level ranges to see when rosters will switch on and off. As a side note – I don’t imagine that we will ever need very many level 1 wandering monster encounters, as they won’t really have the opportunity to run into too many.
Vermin will be all low-level encounters, most likely. Always active, or at least in the more common areas.
Kobolds will probably have a roster range of level 1 to level 5, ending on day 9 when the queen is defeated.
Undead will start appearing when players are either level 2 or level 3 on the second day. We can start the roster at level 3 encounters, and they will continue to appear until the corrupting spirit is laid to rest at either level 8 or level 9 on day 20. We can end the roster at level 8.
Wasps are tricky as they player could eliminate them earlier. I’d plan for the roster to span level 1 to level 9. They could be eliminated at level 5, due to the nature of day 8, but they also might be left until right before day 22. \\
Plantoids should be level 1 to level 4 or so. They detoxify the great tree and render this roster inactive on day 7, level 4 or 5. We want the players to feel powerful if they have been exploring all the optional content, plus these will be easy for their level so as to not suck up too many resources.
Demons – level 7 to level 12. Opening the floodgates (day 12, level 6) will make these active, and killing the demon queen (day 26 level 11/13) will end it.
The magical defenses would be level 4 to level 9 or so. They could be active in the areas after the kobolds have left, as well as provide an instory reason as to why they have not progressed too far. Trigger this roster on day 6, after the arcane runekey is found. I’d put a master rune or something behind a fly gate or a dimension door gate to render the rest inactive.
Crystal -effected things would appear later in the game, in the deeper sections, say level 6 to level 11? The flooded underhalls would be the first place they appear, as the elves brought the crystal there to work, but the majority would be later in the caverns.
Those eight feel like enough to me, game-wise. you have five lower-level ones, and 4 higher-level ones that will be active. The decreasing number as the game goes on is appropriate, I believe
Let me know what you guys think! I’ve been planning along with Angry for a while now, but this is my first post on his website. I’d appreciate any feedback.
I like these ideas. Thank you for sharing!
If I recall correctly, the Source of the Flow is a rift to the Plane of Water. Elementals and/or amphibious creatures could find their way through and form the aquatic faction.
The tenth faction could a grab-bag of different monsters and animals that have made a home within the ruins: ankhegs, cockatrice, dire animals, etc. The dragon and her kobolds were almost certainly not the first creatures to settle here, and having a bunch of beasts defending their burrows and dens or out hunting for prey would help sell the party on the old, abandoned ruins bit.
In a previous article, regarding Lockpicking, you said that players arbitrarily weren’t allowed to attempt to pick the same lock more than once, because you didn’t want to make your wandering monster system time-based.
Now I’ve been agonising over this for weeks, expecting you to come up with some brilliant reason as to why exactly this was the case.
Instead, you outright state that spending an hour in one place triggers a random encounter roll.
So why not just say that lockpicking takes half an hour?
That way, you get one free attempt, but trying a second attempt would trigger a random encounter roll.
I was wondering if you had considered adding some sort of un-lockable encounters for the random encounter table. maybe some sort of tough miniboss encounters, that have to first be unlocked by player action, and are escapable. maybe they can be de-activated by defeating them. For example, I’m thinking of something along the lines of “The players pry open the clearly warded against evil sarcophagus and release the Last Elven Hero. The cursed warrior who helped seal away the big bad. Now his section on the random encounter table is active. Pull that hidden switch and you open up the secret door to the acid wasp nest. Kill the Hero who continuously raises undead warriors just before he pops in on the hero’s and he get’s knocked off the random encounter table. Destroy the nest, and the acid wasps get deactivated as well.
I think this could also drive home the idea that player actions affect the dungeon. And maybe even teaches the lesson that there are unforeseen consequences to their actions, which adds an additional layer of verisimilitude.
That’s actually a very interesting idea, because when you think about it it’s essentially a scripted encounter that occurs at a random time.
I like the simplicity of this solution.
About the only thing I have a problem with is the “Loud” immediate check. Not because being loud and stupid should be discouraged, but because if bashing on a door for a round is loud enough to trigger a check, then a combat encounter should surely also trigger another roll (which, obviously has some grisly consequences if implemented).
Oh, sure, this is a “gamist” abstraction with a specific design intention — I get that. I don’t have an issue with the mechanic, only the logic used to justify it.
As an aside, the mega-dungeon seems to have some faction-specific areas, and inter-faction relations (e.g. Kobolds might hate Plantoids etc). If that’s the case, the wandering monster system might lead to situations that strain credibility …
“How’d these Kobolds get all the way down to the Demon pits? ‘Hey little guy, are you lost?’ ”
“Wait – I thought we were deep inside the Eternal Tree? Why are we being attacked by Kobolds? Why did the Plantoids let them wander around in here?”
This might not end up being an actual problem for the game, depending on the specifics. It could even be an opportunity for the encounter to be something other than combat.
I thought about solutions for this : Add location modifiers to the die roll; Writing the re-usable encounters with more information in them (e.g. If this encounter is in the Blah Area and Faction Blah is still Active then do this .. ).
But most of the solutions I could think of risked adding too much complexity for little gain.
Perhaps a couple of sentences for the GM at the start of the Wandering Monster section covering common sense would be sufficient.