Megadungeon Monday: The Philosophy of Design

Print Friendly, PDF & Email

May 23, 2016

Happy Megadungeon Monday!

Last week, we wrapped up our tour of the megadungeon. At least, we wrapped up our tour of the preplan for the megadungeon. We know basically the layout of the place and how the players should progress. We have a sense of the critical path. Moreover, we know where the players will be free to deviate from the critical path. We know where shortcuts and side paths and optional paths should be. And now it’s time to design the nuts and bolts. It’s time to dig into rules and mechanics. Because, ultimately, as good as our plan for the dungeon sounds, plans don’t impress players.

But, it’s time to take a digression down Design Philosophy Boulevard. Before we start putting mechanics down on paper, we need to think about HOW we’re going to design things. I know that sounds like preplanning, but this is different. We’re going to talk about design philosophy and what things our design needs to accomplish. Personally, this isn’t something I’d spell out as part of the design process, but this series of ideas is so central to HOW we’re going to be creating things that leaving it out would be a major omission. So settle in. Here we go.

There’s a weird truism when it comes to designing a game. As much as you want the game to evoke certain emotions, as much as you want it to delight the players, to draw them in, to excite and engage them, that’s not something you can actually design. A game designer can only create mechanical elements. The trick is to come up with the right mechanical elements in the right combinations so that when players engage with those elements through gameplay, they will feel the emotions and excitement and engagement that you wanted them to feel.

Mechanics vs. Crunch

Now, when we talk about mechanical elements, we’re not just talking about game rules. We have to be a little broader. In the RPG space, we differentiate between mechanical elements and story elements. We differentiate between fluff and crunch. And frankly, that’s a crappy distinction that does us very little good. A game element, a mechanical element, is anything that the players can interact with in some way. The rule for ability checks is a mechanical element. It translates an action a player chooses into a die roll and determines an outcome. But an NPC is also a mechanical element. The player can interact with that NPC, talk to it, make choices about how to deal with it, and those choices create outcomes.

But this is where things get REALLY bizarre. We honestly have a lot of f$&%ed up ideas in RPGs. First of all, that fluff/crunch dichotomy isn’t super useful because it leads us to treat certain things as NOT game elements because they are matters of fluff. Something like a book that the PCs can read and learn backstory information, we think of that as a fluff element, as lore, backstory, and so on. An NPC that players can converse with without die rolls, challenges, or opposition? That’s fluff. If it doesn’t touch a die or have a number, we put it in the fluff column.

A Tale of Two Players

But the fluff/crunch distinction highlights another f$&%ed up, incorrect, and misleading idea about RPGs. Assuming we define a game element as anything a player can interact with in the game and everything else we define as atmosphere or ambiance or set dressings, where do we stick the backstory of kobolds? If we say that kobolds were a slave race created by Tiamat to serve chromatic dragons and that they are invested with her avarice and her cunning and that they hold dragons in fearful awe or worshipful contempt, where does that fall? Is that a game element? Or is it window dressing?

Allow me to blow your f$&%ing mind here. It is a very important game element. Because there is a player that interacts with that information and uses it to make decisions or to determine the outcome of actions. That player is the GM.

We don’t think of the GM as a player. After all, the game is divided between Game Master and Player, between Player-Characters and Non-Player-Characters. But the GM IS a player. Our game has to engage the GM. The GM has to want to run it. And the GM also interacts with the game elements to have a play experience. Now, the GM often plays for different reasons and the GM IS playing a different game, but the GM still has to be engaged.

The motives of a particular NPC may not be the sort of thing that a player-player can interact with directly; player-players may never even know those motives or discover them. But the GM-player does. The GM-player is going to use those motives to make decisions. The GM-player is going to use the game elements to decide how to run the game. And the GM-player’s interaction with the game is going to shape the game experience, not just for the GM-player, but also for the player-players.

This is a SUPER IMPORTANT point that no one ever talks about even though we all know it’s true. Consider the GM who likes running an action-packed dungeon delve filled with monsters and fights and looting and pillaging and strategic combats and puzzle solving. If you hand the GM an adventure with ten complex NPCs and with huge amounts of backstory and lore and complicated motivations and interactions and intrigue, how long will THAT GM run THAT adventure?

That statement is just to prove that GM engagement is a thing and we would never disagree that it’s a thing. Fortunately, we can usually count on the idea that the GM and the player-players align somewhat on their motives. That is, the GM likes running the sort of adventures the player-players want to play. Therefore, the GM will probably automatically enjoy running a WELL-WRITTEN adventure that appeals to the player-players that GM has already attracted.

My point is just this: a lot of things we dismiss as fluff ARE actually game elements. They represent ways that the player-players and the GM-player interact with the game we’ve designed. And, hopefully, they lead to a fun game for all parties.

And that’s good because, as a game designer, we can only interact with the players – ALL OF THE PLAYERS – by way of game elements. All of the clever plans and fun ideas are useless if we can’t create game elements that the right experience.

And that means that a GOOD designer has to think about a lot of things whenever they add anything to the game. First, how do the player-players interact with the game element? Second, how does the GM-player interact with the game element? Third, how does the game element FEEL to the player-player? To the GM-player? How does the game element create the engagements that we want? Does it do anything we don’t want? Does it get in the way of anything? And almost all of these things are tradeoffs.

Depth vs. Complexity

When we design, say, a wandering monster system, it’s important to spell out what we want it to accomplish for both the players and the GM. And we have to decide if its approachable and useful for the GM. For example, imagine we want to create a living dungeon that transforms and repopulates itself constantly, one that feels like a living ecosystem in a constant state of flux. We COULD demand that the GM use a complex set of rules between each session to repopulate the dungeon, to play out battles between different factions, to determine resource usage, and so on. And that would certainly make the dungeon feel realistic and alive. But most GMs would probably hate that system, though there are a few that wouldn’t. It would create a lot of between session work and a lot of record keeping. Now, if we were REALLY married to that system and felt it was the only away to accomplish our goals, we would find ways to make it fun. Find ways to make it like a solo game where the GM can actually make decisions for different factions and roll dice and resolve actions and participate in a changing story. That would certainly help engage the GM in the idea of the living, realistic world. But, at the same time, that engagement might not be enough to offset the workload.

In terms of game design, we can think that as a balance between complexity (how difficult the system is to understand and to use) and depth (the sum total of all of the possible outcomes and ways to play that make the game interesting and unique). When we design mechanics, we want to get the most depth (the broadest spectrum of possibilities) with the least amount of complexity (how difficult the system is to work with).

And that equation works for EVERYTHING. Again, it isn’t just about rules. I can give a three-page backstory and psychological analysis for each NPC. That will certainly make for more depth of interactions. The GM will have all sorts of ways to make decisions for the NPCs, to be better able to understand them, and consequently be able to bring them to life. And, as a result, the players will experience a greater depth of experience. But the GM will have to read all of those backstories, remember them, and make consistent decisions based on all the little bits. And, again, the depth-to-complexity ratio is f$&%ed up.

Differently Engaged

But let’s go back to the OTHER example for a second because I want to illustrate another point. Let’s talk about that wandering monster simulation that balloons into a life sim. Let’s say we do make it fun enough to create a game for the GM and we think most GMs WILL engage with it happily. Just pretend we manage to pull it off. Okay?

Now, the players will experience a living, breathing world and they will think it is so cool how the dungeon keeps changing. And, on a subconscious level, they will appreciate the inherent consistency and logic even if they never overtly notice it. They might even start to recognize patterns and use those patterns to their advantage. But, at the very least, this will play into their engagement with the world as a living, breathing world.

Meanwhile, the GM gets to play this cool little minigame where he gets to decide actions for the different factions and resolve conflicts and manage resources. The GM basically gets to role-play as the world and it has a real impact. This will engage the GM in a very different way than it does the players. While the players feel like they are exploring a real world, the GM feels like they are creating and controlling the development of a world. Moreover, if the GM identifies with particular factions more than others, they might strive to favor some factions over the other. It might create a sense of challenge and role-playing freedom. In essence, the GM will experience in creation what players experience in the act of playing.

Now I am not arguing for this complicated system, though I’m starting to think it might be neat if it were well-executed and it might be worth a future experiment. But for now, it just serves to illustrate a point about engaging the player-player and engaging the GM-player. Most game mechanics will engage the GM and the player in different ways.

Approaching Some Kind of a Point (Or Halfway Point)

So, what can we conclude from all of this? First of all, game designers can only design game elements. A game element is anything that any player can interact with. By designing game elements and combining them and executing them in specific ways, we hope that the interaction of the players with the game elements will create particular types of feelings. We have to be aware that two different types of players will be engaging with our game: player-players and the GM-player. They will engage with different parts of the game and they will enjoy the game for different reasons. We can assume most GMs will get maximal enjoyment simply from running a game of the type they like to run for players who like the sort of game we’re developing. But we can still wreck the GM’s engagement with the game by asking them to deal with too much complexity or simply by making the game boring to read and run.

But THAT isn’t quite the point. That was just a sum up. Because now we have to look at another piece of the puzzle.

The GM as Furniture

I’m going to go out on a limb here. I’m going to say that most published adventures think of the GM like furniture. Or like a computer. Most published adventures are written as games for the GM to execute for the players. They treat the GM like a Playstation or an Xbox, or, gods forbid, a f$&%ing PC (personal computer, not player-character). The only thing any publisher ever says about the GM is “we want to make it easier to run our games.” That’s the equivalent of saying “we optimized our game to minimize the load times.” That’s basically comparing the GM to a loading screen.

Now, that’s not a BAD goal. But it’s kind of a MINIMAL goal. And honestly, most published adventures only pay that goal lip service anyway.

One of my secret goals for this project is not just to design the most fun old-school dungeon-crawl meets exploration-based-gameplay adventures in the history of role-playing games, but also to rethink how adventures are designed and presented. And part of that is to recognize that the adventure has to engage the GM. It doesn’t just have to be easy to run, it has to be fun to run.

Moreover, I recognize that a lot of this adventure is about putting together a very specific combination of mechanical elements in order to create a specific play experience. The thing is, I’m relying on the GM to execute those mechanics to create the right play experience. So, I’ve got to idiot proof things a bit. I’ve got to make sure that dumb GMs can’t f$&% up my beautiful designs.

Design for Presentation

“But, Angry,” you might say, “aren’t you jumping ahead to presentation? Didn’t you say just last week we have a nice, bulleted list of design tasks to deal with and that we’re not going to worry about presentation for a long, LONG time?” And to that, I say “shut up.” Seriously, haven’t you people learned not to question me yet? Holy f$&%.

First of all, let’s consider the idea of interface in games. If you look at board games and video games, you’ll notice that A LOT of f$&%ing thought goes into how to present the game to the user. Boards, tiles, cards, rulebooks OR heads-up-displays, overlays, menus, tutorial menus, hunts, and even signifiers like the screen getting splotched with blood to indicate injury and flashing to tell you where that injury is coming from. THOSE are interface elements that allow players to engage with your game. Designed well, they are intuitive, easy to grasp, and perhaps they even sink into the background so the player doesn’t consciously notice them. Designed poorly, they become an obstacle to your game. A simple graphical icon on a card might wreck your game experience if players can’t easily remember that the red triangle is money and the blue square is energy. Now, swap them with a green dollar sign and a yellow lightning bolt and bam, the player doesn’t even need to be consciously aware of the elements.

Role-playing games have two basic interface elements. The first is massive books where you can only look at one page at a time (or two pages if they happen to be side by side) and there is a massive loading time to pull up specific information that usually involves flipping through pages or flipping to an index or table of contents to locate a particular memory address and then manually moving through the entire pile of data until you fight the memory address and then visually searching approximately 500 words of text for the specific data you need. The second is character record sheets, which, nowadays tend to be a combination of actual useful at-a-glance numbers and (with alarming frequency) lists of references to massive books where you can… yaddah yaddah yaddah.

The thing is, I have never gotten the sense that any single thing written into any RPG has every been created with an answer to the question “how are people going to be able to USE this at the table” already answered. Take monster stat blocks for example. I do not believe for one f$&%ing moment that anyone thought about how stat blocks should look before they decided what stats monsters needed. No. I’m pretty sure they decided what stats monsters needed and then struggled to format it afterwards.

Now, I’m not going to say I’m going to redesign stat blocks. If we make a D&D 5E adventure, we’re stuck with a certain expectation for monster stats. And GMs now expect stat blocks to look a certain way. But for the various mechanical elements of the megadungeon adventure, we’re going to design things with one eye firmly fixed on how it will be used by players and GMs.

So, let’s take a quick look at a few of the tasks on our bulleted list and see how the presentation might inform the design. Or rather, how the INTERFACE might inform the design.

Designing the Map

We need to map our dungeon, right? And so far, we’ve really only considered how the map should be explored. We’ve said things like “we can break it into chunks of encounter areas” and “we want the players to remember this location” or “the players will appreciate the presence of this shortcut.”

But when you look at dungeon maps, they are pretty much always presented the same way. The map is designed on a room-by-room basis. Each room is numbered. The GM has to reference the room number on the map, reference the room number in the big ole wall of text, and often transfer the room to a battlemat or grid.

As for the players, we’re relying on them to really understand the layout of the dungeon. We’re relying on them to remember landmarks and understand basic relationships between the different spaces. That will drive exploration and decision-making and also highlight rewards like shortcuts and new areas to explore.

Our room, though, isn’t designed in a room-by-room format. It’s designed in zones, days, and encounter spaces. And while it isn’t necessary important for the GM to understand all of the nuances of the design of the physical adventure space, we might be able to USE that design to make the adventure easier for the GM to navigate and present. I mean, here’s one question: how do we number and key our locations?

From the player perspective, do the players have to draw a map of the dungeon? Will we require that? Expect it? Encourage it? Make it optional? Can we design the space to make it easy to remember and understand? Can we design it to make it easy to map? Can we provide tools that might make it easier to map?

If we consider these questions AS we’re designing the map instead of after or instead of just ignoring them, we can create a better game experience for the player and the GM.

Building a System for Wandering Encounters and Respawns

What about our wandering encounter and respawning system? We know we want some way to have monsters wandering the dungeon and reappearing in cleared rooms. And we know we will probably base it on monster factions. But we don’t want it to create a burden on the GM nor do we want it to slow down the game. Traditionally, these systems require the GM to keep track of time and make a random roll after so many time intervals to determine if there is an encounter and then another roll to determine what encounter happens? Is that the best way? Is timekeeping the biggest factor? Is there some better way to handle it?

Beyond that, such systems usually involve tables in some standalone section of the book. Usually an early chapter about “how to run this adventure” or an appendix. Is THAT the best way? Can we find a better way?

And considering the way we want this system to drive exploration, is there a way we can make it somehow visible to the players? Is there a way we can show the players that it’s happening in a way that will create the same sort of tension the characters would feel without explicitly explaining a whole bunch of rules.

Creating Magic Items and Other Gate Keys

We will be creating a number of unique magical items to help create a sense of advancement and achievement while also maintaining a careful flow over the players’ explorations. But we don’t want these items JUST be to keys. Some of them are, sure. But others are real treasures and we want them to make the players feel powerful. And while many of them mirror abilities that some classes eventually gain access to, we want our items to feel unique and special without allowing them to overshadow class abilities.

How do we create items that manage that? Moreover, how do we make them easy to understand? And how do we make them memorable? How do we pair the magical item and the gate in such a way that the players instantly recognize the devices as solutions for the various obstacles? Items that give particular stat bonuses may be boring, but they are easy to remember because they get recorded right on the character sheet. No one forgets their +1 sword gives them a +1 if their attack bonus is already calculated to include it. But players have a tendency to sometimes dumb weirder magic items in their pack and forget they exist. If the players do that in our adventure, it’s going to turn the thrill of exploration and discovery into a slog of backtracking, wandering, and flailing around trying to figure out where to go next.

And Then Reality Kicks You in the Dice Bag

Now, despite the fact that we’re going to be designing all of our game elements with an eye toward how the players (the player-players and the GM player) will interact and interface with them and despite the fact that we’re going to be thinking through presentation WHILE we design instead of after it, the fact is we can’t think TOO hard about presentation. It something we want to be aware of, sure, but it’s something we can’t be married to just yet.

Why? Well, because, frankly, when we get around the presentation and publication stage, we are going to discover we probably have to work around hardware limitations. That is to say, we might love the idea of breaking our adventure down into a poster map and six little books and a couple of reference sheets and a tri-fold screen and shoving it all in a box, but that might be cost-prohibitive when it comes to actually publishing and selling the whole damned thing.

But we’ll have to figure that part out when we get there. For now, we just want to ensure that our mechanics lend themselves to the best possible interface we can eventually build.


Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

13 thoughts on “Megadungeon Monday: The Philosophy of Design

  1. I dealt with similar ideas when publishing some simple modules of my own because I am not very happy with information-presentation in existing modules, at least those I’ve read. I also think it’s very rewarding work which alone can make a module memorable to the GM. I really don’t like reading modules from beginning to end and extract all the info into how I would run it. Especially the “this is a room, this is what happens in this room” format I find very unhelpful. So, I do look forward to your solutions for these problems.

    I guess it can help to involve graphical artists actively in the question “How do I present this information?” Too many products are first written, then handed off to a layouter and some artists. But the presentation is almost a done deal by then. For example, if I not only have one map, but one similar-themed space as a map together with my representation, then my brain engages differently with it. I hate having to turn back to a map, and I often copy or print out the map for cross-referencing, but what I really would like is to never have to. Maps. Flow diagrams. Anything but just “module text, unrelated illustration for overall mood, module text, ad nauseam, appendix, maps.”

    In a mystery adventure, I want parts of the overall flow diagram. Where do I go from this scene? What are the individual elements enabling these transitions? In a dungeon adventure, I want all rooms that act like a unit (like a set of caverns occupied by the same goblin tribe) described together, with a map fragment of only that part. Individual room descriptions matter less when the tribe reacts as a unit and also as small separate bands, units, patrols. Give me as GM some hooks as to how the tribe reacts, some examples of how the interactions gets rolling and how it escalates. All the nitty gritty details, treasure locations, window dressing one can still add after showing me the frame, the structure, all the important things.

    I didn’t have the required money to design as I want to. I guess as an indie you have to be able to invest this time together with a graphical artist because you’re both in the same boat for whatever reason or it doesn’t happen. But I feel many modules would benefit from a team approach instead of there being either only the lone author or only the authors of the text work as a team. I guess pen & paper RPGs generally suffer from their poor marketability in that regard. My personal guess is the “you give me 20 pages of text with this deadline” approach still dominates and most experimental stuff is somebody’s labor of love. I would prefer more design teams than individual authors, but that seems to be more true for rules, not for adventures. I see many Kickstarters just saying “we will commission X to write Y” but I think these commissions just limit the amount of creativity. I know there are strong writers out there, but I don’t think anybody will pioneer a new, better representation of RPGs that way.

    Teams always bring a risk of “lowest common denominator” approach, but I don’t believe in the single “creative genius” either. Lots of good games in profitable industries are made by teams these days. I would wish that luxury on pen & paper as well.

  2. One thing I’ve seen missing in published modules is the theorycrafting on why things are the way they are and how the pieces work together. There’s some great stuff out there that lines up the themes well, but if you don’t tell the DM about it, there’s a good chance they’ll miss how it works.

  3. Finally someone has the clarity to say: “Dungeon Masters are players too”. I’ve seen it before, when a unhappy/disinterested DM translates directly into unhappy players and wasted time. Great perspective in this article!

  4. That boxset sounds awesome. I hope it can be within budget.

    Hmm – how about the Angry Megadungeon Deluxe Edition? 🙂

  5. I was kindof disappointed with this article, and it took me a while to figure out why. It seems like at the end of the day, it was meandering and didn’t really go anywhere. Unlike most Angry articles that talk about a problem and then talk about some solutions and the why’s of those solutions, it was an entire article where the conclusion seemed to be “Yeah, I guess we should try to pay some attention to this problem”.

    It didn’t help that it came in with an aggressive tagline about game mechanics and how game designers don’t even know what they are, which was a concept that was almost entirely missing from the article, which spends most of its time talking about game elements, which is a superset of game mechanics, and… I dunno. This article does not seem to live up to the usual high standards.

    • That’s one thing I’ve noticed about this series, since it is a series, angry is less concerned about single articles being complete in and of themselves. I have a feeling that this will come up on a case by case basis, which is why it doesn’t seem to be a common thought now.

    • I figured if I took the time now to lay out an entire design philosophy once, I wouldn’t have to keep re-explaining it in pieces as parts of different game mechanics. As Grimsly observed below.

      This series has been extremely tricky for me. It is always hard to figure out WHY you think a certain way and WHY you make the decisions you do. Interestingly, sometimes, I don’t even realize why I’ve done something until I try to explain it in these articles. Originally, I set out to use the design philosophy as an introduction and work through one of the specific design problems, but as I thought it through, I realized there was a much deeper set of ideas at work. And, because I want to be clear, I decided to spell them out.

      As for the whole “most game designers don’t realize some things are game mechanics,” that idea is explained in the next few paragraphs where I point out that things like backstory elements, motivations, and monster lore are TECHNICALLY game mechanics. They are interactive bits of the game that shape the experience. Most folks in RPGs think of mechanics only in terms of dice and numbers. They don’t realize that the “designing mechanics” is a lot broader for a table-top RPG. That’s all I was trying to get across.

      • Ah; I was confused, because you use the term “game elements” which I view as distinct from “game mechanics” for the very reasons you lay out – mechanics are mechanical. They are processes. Elements are just…things. That are part of the game.

  6. One way to do fog-of-war and mapping for players would be to have room stickers. When they explore a room, you add the sticker for that room to their blank sheet of paper, and they gradually build a map. The campaign book’s DM map gives instructions on how the stickers are to be laid out and where the connections are.
    This would save time and effort for DMs and players compared to having to draw out dungeon maps.
    DMs may still have to draw out battle maps on 1 inch grids or whatever, but I don’t have any ideas for that.

  7. Great to hear your ideas around magic items, as they can certainly become rather bland. But what are your thoughts about money? 5e seems to hand out money liberally, but has very little to spend it on, particularly in a megadungeon.

    The best thing I can think of is a mini-game of hiring henchmen, possibly using the NPCs in the Monster Manual with pricing based on their CR – would you rather have a bunch of Guards or just one Knight? And having to pay them based on number of rests would add an extra incentive to keep on going!

    But that’s going to mess with the balance of the encounters, of course.

  8. Love this. I’m running PotA right now for a group, and they seriously needed a user experience designer or editor to go over their product. It’s so clunky at times, and there’s no introduction or expectations sections to their dungeons.

  9. Love the content Angry! Long time listener, first time caller and all that jazz…

    One thing I loved from my days as a young whipper snapper of a GM/PC was the old Dark Sun Modules and their pair of flip books. One full of evocative images for the PC’s and one full of master maps for all the locations that the GM will be sending them to. I really really love the idea of an Angry Deluxe Edition Boxed Set with all the bells and whistles. In fact, I wonder if it would be worthwhile considering crowdfunding as a way of funding the final product, as all those neat things like the poster maps and what not would seem to make for good “stretch goals”. Another thing worth thinking about now, since you have a very well defined sense of room/zone/adventure day sizes, would be how much you could fit on a A4 sized ready made battle map. I think this might be a good way to define what the players can see at a given moment, but of course the cost may again begin to get prohibitive.

  10. This thing about the user interface has been in my head since your article about abbreviating the stat blocks. When I started in 3rd edition I read every single book I could put my hands on. I was young, and I was in love. Only with your article I fully realized that any sane person would have backed off at the idea of reading even the three core books. Actually, I myself remember having a great deal of difficulty to grasp some combat concepts at the time, and reading over and over with little improvement. The books did a terrible job. It’s a surprise I’m here today.

    For that I really appreciate your intention to make things easy to approach for both GM and players.

Leave a Reply to Paul HuttonCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.