This here’s the last of the three four brief, introductory essays that set us up to build a pretty good dungeon, though, after that nightmare delve into players’ psyches, I can’t really say brief anymore, can I?

Whatever.

The goal here is still to build a dungeon adventure that allows the players to do some on-their-own exploring, but which ensures all the paths they can possibly take present a good, balanced game that’s fun to play. To that end, we’ve already talked about mapping paths through dungeons and how players pick the paths they take.

Now, it’s time to look at the Matrix in the code. It’s time to bring the game’s mechanical needs into this.

You see, part of what makes for a good, balanced game that’s fun to play comes from the game engine it’s built on. In. Whatever. That’s actually how this whole project started, remember? We talked about adventuring days and how they’re good things from a gameplay perspective, provided you, yourself, keep the right perspective in perspective.

I know some of you reject that hypothesis, but my new policy is not to negotiate with rejects, so facts are facts, and you’re just wrong, and I won’t be explaining why.

Today’s topic, which actually will be pretty brief, is checkpointing. That’s how you build an adventure — be it a dungeon or otherwise — around your game system’s mechanical expectations.

The Best Moment in Dark Souls

Oh lawd, he talkin’ Dark Souls again.

Yes. He is. Shut it.

If you’ve played the original Dark Souls, you probably remember a very significant moment that comes reasonably early in the game. It’s the kind of moment that shocks the hell out of you and stays with you for years. It not only showed you what Dark Souls really was, at its core, but also perfectly encapsulated the subgenre that Dark Souls would come to define for more than a decade.

You know the moment I mean.

It’s when that second fucking gargoyle woke up and killed you. That moment was everything you needed to know about what Dark Souls was and what every game like it would be forever.

Or maybe it was the moment when you lost the 10,000 souls you’d gotten by finally killing the taurus demon because a scaly flamethrower on silent, leathery wings instakilled you to death because you dared to cross an open bridge under an empty sky with no visible threat nearby.

If you instead watched some self-proclaimed game design expert on YouTube deconstruct the original Dark Souls, you probably remember a very different single, defining moment that comes in the early game and showed what Dark Souls really was, at its core, and perfectly encapsulated the subgenre that Dark Souls would come to define for more than a decade.

It was the moment you kicked a ladder and were able to climb down a tower back to the bonfire in Undead Burg.

Or maybe it was the elevator back to Firelink Shrine. Same difference.

Remember, kids, lots of things can be true at once, and self-proclaimed expert YouTube essayists don’t see the world like normal human people do.

That moment — the bonfire one — is a perfect example of checkpointing and, while we Game Masters tend to think of checkpointing as something icky that video games have to do and that has no place in real games for real gamers, checkpointing is actually really important if you want to make pretty good adventures. The fact is that, between that whole game mechanical challenge design thing, and all that player behavioral heuristic in navigational situations bullshit, you just gotta checkpoint. You can’t not.

You’ve Reached an Article Checkpoint; Leave a Comment

A checkpoint is a deliberate opportunity created by a game designer for the player to rest, bank their progress, or take a detour or diversion.

I don’t think I have to explain take a rest, do I? It’s game speak for recovering all the resources you spent to get to this point.

Progress-banking ensures that if something goes really wrong, the player won’t have to replay all the shit they did to get back to where they are now. In video games, that’s respawning, right? If you die, you don’t have to start the whole game over; you get to try again from your last checkpoint.

Of course, tabletop roleplaying games don’t do respawning. We’re real gamers. We do Permadeath Ironman Steelsoul Runs. They’re all we do. Unless we have thousand-gold-piece diamonds or whatever. But, even so, banking progress is still a thing. It’s weak now because pussy game designers keep ignoring things like random encounters and dungeon restocking, which is total horseshit, but that’s not a hill for me to die on today.

Even so, in tabletop roleplaying games, banking progress is more about saying, “If you had to retreat or if you took a detour or if you had an emergency, you wouldn’t have to retread old ground to get back here.”

Creating space for detours and diversions is kind of a consequence of both the rest thing and the progress-banking thing. If you’re allowed to pause your forward movement and you have a place from which you can easily pick up again, you’ve got the perfect opportunity to clean up some side quests or explore some unexplored side paths or do some maintenance or advancement or bookkeeping or buffing or whatever. Checkpoints let you say, “Since we’re stopped anyway and we can pick up from this point…”

That’s all really good stuff. Designers want those things in their games. Hell, they even need some of those things in their games. Recovery is a mechanical necessity in any game with expendable resources and endurance as game mechanics. Progress-banking mitigates risk, but also provides dopamine hits of the “You got this far; yay for you,” variety. You need those hits in any game the players can’t win in one session or three encounters or whatever. Detours and diversions let the players pace the action and exercise agency over exploration while also creating space to take care of mechanical maintenance and other “needs of the system” crap.

Long story slightly shorter: it’s good for gameplay if the players stop every so often to recover, bank their progress, and do side things. Checkpoints are deliberate spaces in an adventure that let the players do just that and, more importantly, help them decide when it’s a good idea to do so.

I Can Stop Whenever I Want

I hear your brain gears grinding and I can smell smoke. I know what you’re thinking. You’re thinking that, in tabletop roleplaying games, players can stop and do all that checkpoint shit whenever they want. They can always head back to the dungeon entrance and return to camp and sleep off the day, for example. Or, if they’re already in the wilderness, they can just camp where they’re at. Or they can head back to town. Or they can even lock themselves in a room somewhere and just checkpoint-in-place.

Given that, why should you, the adventure designer, do the checkpointing for the players?

Before I continue, note that this doesn’t count as negotiating with rejects. I’m using a rhetorical device here to introduce an instructive point. That’s different.

First, let me say this: the idea that the players can trivially rest in hostile territory for any length of time at all is complete and utter horseshit. It’s bad gameplay. Even if they cleverly drive some spikes into the doorjamb, they should still have a stressful, white-knuckle couple of hours of barely any sleep. No group should consider resting in a dungeon as anything other than a desperate last resort that’s half-likely to lead to disaster. I reject it as a possibility, and you should too.

A pretty good dungeon doesn’t let the players rest unmolested inside of it.

Yeah, yeah, no true Scotsman, blah blah blah, no negotiating with rejects, suck it.

Moving on…

Think about all that player psychology shit we covered last time. Specifically, think about the whole completion bias thing I explained. Also, think about how I said that players absolutely hate going backward. If the players do not feel safe resting in a hostile environment, the only way to rest is to stop making progress toward completion and to go backward. They’ll do it if they want to, but most players resist it far more than they should, and they feel like it’s a failure when they do it.

That last bit is actually pretty frigging unfair. If the game says, “Players can handle five encounters before they need a rest,” resting after five encounters shouldn’t feel bad. Ever.

There’s also a nasty death spiral component to all of this. The farther you delve, the more progress you lose when you retreat, psychologically speaking. Which means, the longer you adventure, the less you want to stop, and the more dire an emergency has to be before you’re willing to do so. Resting should feel bad if you do it after just one encounter, and it should feel good if you do it after ten.

This, by the way, is why that fifteen-minute workday nonsense isn’t nearly as common an issue as screaming internet morons would have you believe. It’s not even as common as it should be. In fact, it’s most likely an issue when resting doesn’t mean going backward or losing progress. In other words, the safer it is to rest in hostile territory, the more likely players are to rest all the time.

The point is, left to their own devices, players will either try to rest continuously or never. They’ll resist resting until the direst of emergencies. Neither of those is a rational, agency-driven choice. They’re both the result of brain wiring and learned habits and gameplay incentives. So this whole resting decision thing isn’t really a strategic or logistical gameplay challenge any more than walking away from the craps table in a casino is a logistical gameplay challenge. Resisting a compulsion is not a challenge; it’s just willpower.

Thus, it’s simply good game design to build deliberate checkpoints into the game. It’s just creating opportunities to rest and bank progress and do side shit without all the compulsive mental noise that gets in the way of good decision making.

The Power of Properly Placed Checkpoints

Checkpointing isn’t just necessary, it’s powerful. When you, as a game designer, decide when and where the checkpoints are, you’re doing a lot of very powerful gamefeel tweaking.

If the checkpoints are far apart, for example, your players will feel driven to push farther between rests. That can make for a more challenging experience, but it also makes the checkpoints feel more rewarding. Contrarily, if you push the checkpoints closer together, that can make for a less demanding gameplay experience, but it also lets the players unload more resources in every encounter and thus feel like superpowerful badasses. You’re not just adjusting the gameplay feel, but in very long adventures, when the players start to build an unconscious sense of how far they need to push between one break and the next, you can regulate the playfeel.

Checkpoints are also progress markers. They’re moments when the dungeon itself says, “Good job for getting this far. Give yourselves a pat on the back.” That means they’re tension managers. Checkpoints relieve tension, and checkpoint starvation creates stress.

If your goal is to make the best path through the dungeon feel good to play, doesn’t this seem like the sort of shit you need to think about? It kind of does, doesn’t it? This is a big deal.

Opportunity is Not Coercion

It’s worth noting here that there’s a difference between providing an opportunity and forcing an action. Just because the players hit a checkpoint, that doesn’t mean they’re going to rest. If they’re feeling good and have their momentum up, they’re likely to keep pushing forward. In fact, checkpoints can encourage the players to push a little harder because it means there’s less to lose if they’re forced to turn back. That’s why you’ll hear players say, “I know we could rest here, guys, but we’re doing good. Let’s keep pushing forward, but mark this spot on our maps.”

Likewise, checkpoints don’t stop players from seeking rest when they need it. If an emergency happens between checkpoints, the players are still totally allowed to make the painful choice to stop moving forward, head backward, and rest. It’s not that players won’t do that; it’s just that they’re kind of stupid about it, and sometimes perverse incentives create bad compulsions, which is kind of messed up.

If anything, the presence of checkpoints makes players more likely to choose to go backward because they may not have to go all the way backward. They only have to go to the last checkpoint. Moreover, once your players figure out checkpoints are a thing, it gives them something to seek sideways when they start feeling drained.

So, checkpoints don’t compel behavior, they just give the players more ways to make reasonable, rational, non-compelled, non-compulsive, non-compulsory choices.

Noice, right?

Paths and Depth

Tell me this, oh, homebrewer Game Master: how do you map a dungeon? When you’re making your own little adventures for your little friends, how do you draw the map? Do you just draw a bunch of rooms and connect them with doors and halls and whatever? Or do you maybe think about what the dungeon should look like and then just draw that? If the dungeon’s a temple, you draw a temple, and if the dungeon’s a castle, you draw a castle.

If you take either approach, you’re in the vast majority, and you’re also thinking about this shit totally wrong.

To build a pretty good dungeon using all the tricks I’m talking about, you’ve got to think about your maps as sequences of gameplay. You’ve got to think about them as paths and path segments.

Instead of putting the guard room here and the larder there and the caves over there and the chief’s room off the gathering hall over yonder and then sprinkling in the fights where they go, you instead want to think like, maybe this…

Okay, so the players are always going to start in the guard room. That’s where the entrance is. After that, the dungeon branches into two wings. This wing has the larder and the caves beyond. That wing has the living quarters and ends with the chief’s room.

Doing it that way, you can keep track of something called depth. That’s a measure of how far the players have to go in terms of mechanical, costly gameplay challenges like traps and fights and obstacles and other encounters, between one major navigational decision and the next.

In that dungeon above, I might decide that there are always guards in the guard area. If the players leave the dungeon and come back, they will always face guards. That’s one normal encounter. Since I know the game can tolerate four or five encounters per adventure day, that leaves me three or four encounters in each wing before the players hit the end of that path and are compelled to end the delve and start from the beginning again.

You can see how this shit’s super vital if you want to do proper checkpointing. It lets you ensure that, no matter what direction the players choose to go, assuming they behave rationally and do all the path completion and recontextualization things most players do, the game will never demand they go through more encounters I think they should be able to handle based on the challenge I’ve decided to present before they hit a checkpoint or are forced to go backward.

Do you get that?

Obviously, once you start seeing dungeon maps as paths and path segments, you can do all sorts of mechanical tweaking. You can account for side paths and random encounters and rooms that restock and keep it at whatever difficulty level you think it belongs at. This shit gets especially important when you build really big dungeons that actually demand backtracking and retreading.

But the basic idea is just to see your map as path segments of certain depths, where the depth reflects the number of costly or risky encounters the players have to deal with from one end to the other.

Checkpoints on Tabletops

Up to now, I’ve been describing checkpoints as totally abstract things. Worse, I keep invoking video game checkpoints like bonfires, benches, save stations, midpoint flags, and so on. That crap doesn’t work, though, because we can’t rely on mechanical abstraction and contrivance in tabletop roleplaying games. So what might checkpoints look like in non-video game worlds?

Well, the short answer is that they can look like anything. The longer answer involves abstraction. Just bear with me here. I’ll make it all make sense.

First, let’s classify checkpoints. We’ll start with the simplest, the safe space checkpoint. That’s just a spot in an adventure that’s safe enough to checkpoint in.

“But Angry, you said to never let the players rest in hostile spaces.”

No, dumbass, I said to never allow the players to choose to rest anywhere they want in hostile territory. Don’t let players make their own checkpoints. That’s bad. Game designers creating deliberately safe places to rest? That’s good. See the difference.

Building a safe space checkpoint is pretty easy — there are lots of ways to do it — but it has to be more than just a room with a door and a lock. Something needs to make it special. Maybe it’s hidden. Maybe it’s difficult to access except by one easily defensible route. Maybe it’s magically protected. Perhaps a shrine to the god of travel in a grotto behind a waterfall that’s been undisturbed for centuries.

The salience rule matters. The room has to scream safety. Especially if you’ve trained your players to treat any room in any dungeon as unsafe. As you should.

The problem here is that I can’t do the creativity part for you. I’ll talk more about that below. For now, just know the easiest checkpoint is the safe space checkpoint, but also know it’s the weakest and least useful of the checkpoints. It’s only really good for resting and maintenance. It doesn’t protect progress, and it doesn’t let you wander too far to the side.

Next, there’s the shortcut checkpoint. Remember the Dark Souls ladder? The Firelink Shrine elevator? Those are shortcut checkpoints. In fact, Dark Souls, Demon’s Souls, and Bloodborne are masters of the shortcut checkpoint. Hell, Bloodborne is a master class in pretty good dungeon design based on path segments and checkpoints. More so than any other game in the franchise. I could probably talk about its maps for hours.

Shortcut checkpoints are easy to imagine. They’re just paths between the room you’re currently in and some earlier room of the dungeon. The key feature is that they can’t be used until you reach the other side. Barred doors and gates locked with mechanisms instead of keys are classics, but there are lots of ways to do shortcut checkpoints. You can make passages that just can’t be spotted from one side unless you know they’re there, or high-up passages that are extremely difficult to climb up to unless you drop a rope or ladder from above. Secret doors easily visible from the back work too.

The side door checkpoint is similar to the shortcut checkpoint, but it provides another exit from, and therefore another entrance to, the dungeon. It’s easier to imagine how the party might be unable to find or access such passages from the outside, but once they find them on the inside, they can be used and reused. Imagine, for example, that there’s this multilevel cave complex honeycombing the bedrock walls of a natural valley. There’s one big, visible entrance at the head of the valley, but as the players explore, they find other cave entrances that were hidden on ledges, or by folds in the rock, or overgrown with foliage. Cool setup, right? Of course, if you handed the players a map and said, “Here’s a valley and ten visible entrances to the Caves of Confusion, which are all basically indistinguishable holes in the rockface, so which do you want to explore,” you’d kind of ruin the whole fucking thing, wouldn’t you? But no actual, professional game designer employed by any major roleplaying game published in this day and age would ever fuck up the design to that degree, would they? Huh!? Would they?! You’re awfully quiet over there, Mr. Arman?! What do you think?! Don’t you think that’d be a colossal fuck up of great design potential?!

… sorry. I don’t know what got into me there.

Finally, there’s the fast travel shortcut. That’s basically just a side door shortcut without the step count, and it illustrates what I said about the need for creativity. Because what I’m describing now aren’t constructs, they’re functions. Checkpoints aren’t things, they’re needs that a pretty good dungeon must satisfy. Part of the job of building a dungeon is making sure it fills all the needs.

Thus, if I’m building an extraplanar dungeon complex that is based on teleporting between different fragmentary nodes of different outer planes all anchored together in some astral hyperspace somewhere, I’ll probably build a feature right into the dungeon that allows specific teleportation circles to be linked temporarily to a quick-return gate that the players can work out early how to use.

Meanwhile, if I’m building a dungeon that’s the elven equivalent of the Swiss Family Robinson’s tree fort hundreds of feet above the Sequoiasylph forest floor, I can include anchored-in-place ladders or stairs or elven winch-hoisted elevators the players can lower to the ground as they find them.

The mechanical side of this shit is knowing about depth and path segments and checkpointing and placing checkpoints and path-ends properly for the adventure you’re building and the system you’re building it for. The thematic side is imagining the dungeon as a thing in the world and figuring out what features would allow for safe spaces, shortcuts, side exits, or fast travel, and how you can incorporate them.

That’s the actual art of this pretty good dungeon design shit. My dungeon needs to meet certain mechanical criteria; how can I make sure it does while still making it feel like a thing in my world?

Let’s Build a Pretty Good Dungeon

Paths, segments, depth, path-ends, and checkpoints together comprise the last part of this pretty good dungeon puzzle. Think about dungeon maps in terms of paths and know their depth. That is, know how many costly and risky challenges lie along each. Ensure no path asks the players to go deeper than they should be able to go before they need a checkpoint or before a dead end or obstacle forces them back to an earlier checkpoint.

It’s just that simple.

And now that the end of my finger is mostly regrown and I can draw crappy diagrams again, we can start the actual design process.

Coming soon.