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.