Dragna's Devblog: Reloading Skill Challenges

Skill challenges are weird.

To understand why, let’s rewind a second to D&D 4th edition, way back in Ye Olde Yonder Years of 2008-2013. 4e made a lot of changes to the standard D&D model that had emerged with 3e and 3.5—some of which were well-received, and many of which received lots of backlash.

One of 4e’s more understated changes was the addition of “skill challenges”—an all-new system of gameplay that explicitly focused on players’ skills (e.g., Athletics, Religion, or History), rather than their combat abilities. Instead of monster hit points, the players needed to reach a certain number of “successes” (i.e., successful skill checks) before a certain number of “failures” (i.e., failed skill checks).

If the players reached the requisite number of successes before the maximum number of failures, they succeeded in the skill challenge; if they hit the failure maximum first, they failed, and might suffer some penalty. During the skill challenge, the players could make any skill check they liked, so long as the DM had prepared it in advance, or (if the DM hadn’t prepped for that eventuality) they could reasonably justify its use.

Here’s where the weird part came in: because these skill challenges were so broadly defined, you wound up with a situation in which basically the entirety of the non-combat game (social encounters, navigation, surmounting obstacles, etc.) was accidentally abstracted away into the skill challenges themselves. For example, you might use a skill challenge to persuade a duke to send his army to defend a mountain pass, to find a hidden temple in an overgrown jungle, to scale a set of craggy mountain cliffs, or to sneak into a wizard’s college.

4e came and went, and 5e—a return to the traditions of 3.5—did away with skill challenges altogether, consigning them to the dustbin of history alongside things like healing surges and encounter powers. But the dream of a skill-based gameplay system never quite died, and DMs throughout 5e’s history have attempted to resurrect it once again.

I was, and continue to be, one of those foolish individuals.

Let’s see how it went.

Why I Don’t Like 4e’s Skill Challenges

While I loved the concept of a skills-based encounter system, the way that 4e implemented it never sat right with me. When it comes to D&D, I am fundamentally a simulationist—I enjoy it when the game that we’re playing is grounded in the actual play-by-play narrative events that the characters are doing “on-screen.” I don’t ask my DM if I can “make a Persuasion check”; I make an argument, and roll the dice if my DM tells me to.

To me, the dice are fundamentally a physics engine, not a narrative one—they represent that cosmic sense of chance that adjudicates the outcome of any distinct physical action in the world of the game. That clashes heavily with 4e’s approach, in which the order and presentation of the players’ actions doesn’t really matter so much as which actions they take.

In a 4e skill challenge, for example, you can try and overcome the effects of exhaustion before you’ve ever even started looking for the ancient temple. You can try and persuade the Duke to send his army before you’ve even identified the right kind of historical or personal argument to make.

It’s assumed that your characters are doing things in the world in line with the dice you’re rolling, but nowhere does anyone actually need to say what those things are. The 4e skill-challenge model gamifies and abstracts away the experience to the point where playing D&D better resembles a game than a roleplaying game—and that, for me, was huge problem.

To me, a skill challenge needed to reflect the structure of a combat encounter: a mechanical framework for adjudicating physical, narrative events in a linear, play-by-play structure that kept constant track of the current “game state” and updated it as the players succeeded or failed. And 4e just didn’t cut it.

Experiment #1: The Escape

The natural place to start trying to make skill challenges work was escape sequences—specifically, in the context of an escape sequence at the end of Death House inspired by a similar sequence I’d seen someone share on DM’s Guild.

This sequence was a lot of fun—the players had to use their skills, spells, and abilities creatively in order to quickly overcome the obstacles in their path before the house collapsed on top of them. Every success represented a quick and competent leap forward; every failure represented precious seconds lost to the clock. (“Failure” didn’t actually mean “failure”—it just meant that the players were assumed to have wasted additional time in overcoming the obstacle before them.)

This played well into my desire for a play-by-play framework for adjudicating non-combat actions; the players would need to use their skills to overcome each specific obstacle in turn, and their capability in doing so would dictate whether they made it out of the house or not.

There were two major problems, however. First, the sequence was highly nonlinear, with multiple possible routes of escape. Second, the stakes of failure were incredibly high—meaning that allowing the players to fail completely (and therefore TPK) was not an option.

The second issue was easier to address than the first: I decided to add “degrees of success,” such that the players had a maximum of 3 possible failures, and every failure beyond that point would mean the death of a single additional PC. (There are real game design issues with inflicting automatic PC death as a consequence of a single short and unpredictable encounter, and I would never do this again today, but suffice it to say that those issues were at most orthogonal to the problems of skill challenges themselves.)

The first issue was fairly tricky, and I never wound up solving it completely. I added additional obstacles in different places, trying to keep the total number of obstacles constant, but never really was able to account for the prospect of players doubling back if they took a wrong turn, or for players taking shortcuts through the dungeon (e.g., the trapdoor connecting the Death House basement to the Den of Wolves).

The nonlinear issue got even worse when I started working on a skill challenge for the Wizard of Wines winery. There was a linear path to the winery, but multiple possible entrances, and I needed to prepare different outcomes for each one. I was able to make it mostly work out (since at least the number of checks was constant no matter which route the PCs took), but it still felt incredibly messy.

Experiment #2: The Chase

Not long after I implemented these two skill challenges, I also tried adapting the system to a completely different situation in an avalanche encounter I’d been trying to add to Tsolenka Pass in Curse of Strahd. You can’t fight an avalanche, of course, but I wanted to create an opportunity for the kind of cinematic tension you get in a movie when the protagonists are running away from some natural disaster and they need to use their wits, tools, and abilities to do so.

This went…okay. I took a little bit of inspiration from the Chase rules in the DMG (which are, generally, absolutely useless, but somewhat fit here), and took an approach where the players started at position Y, the avalanche started X feet back, and the players had an action, movement, and bonus action in a normal-ish kind of combat. As they progressed, they’d have to bypass an assortment of additional obstacles—cracked ice, narrow bridges, stampeding elk, and so on. Once the players reached a certain distance from their starting position, they made a final check to climb a mountain cliff, and the encounter ended.

This seemed to work out reasonably well—better, in fact, than the Death House and winery sequences—in no small part because the players could actually see where they were on the map and could more easily see how their play-by-play actions affected the unfolding narrative. However, we ran into a brief issue when some of my players had the fly spell and wanted to know why they couldn’t just fly perpendicularly to the avalanche, and so remove themselves from the situation altogether.

Moreover, in both cases, I began to run into a particularly pervasive problem—the players just didn’t know what to do. This was an issue on all three of my first attempts.

For example—I began by implementing the 4e restriction of “the party can only use each skill once per skill challenge,” but that wound up being completely untenable. The spellcasters had a lengthy list of creative verbs that they could draw from (“Could I somehow use blade ward to do something here?”), but the poor martials had nothing more than Athletics, Acrobatics, and the swords on their backs.

4e advised DMs to prepare a broad array of possible skills for their skill challenges (“Allow your players to use History to argue that sending the Duke’s army to the mountain pass is good military tactics”), but in practice, players never discovered these because they had no reason to believe that it was possible.

I wound up in several situations where a player would plead, “Can I attack them with my sword?” and I’d have to reply, “No, this is a skill challenge. Do you have any other skills?” Then they’d look sadly at their character sheet, eyes glazing over their Nature, Perception, Investigation, and History proficiencies, and mumble something in the negative.

Even once I opened things up to allow multiple players to use the same skill (so long as each player only used that skill once themselves), the problem still remained. Players weren’t being creative or exploring their skills; they were spamming Athletics and Acrobatics checks and throwing up their hands whenever I encouraged anything more creative. Something wasn’t working.

Experiment #3: The Action Scene

In video games, there’s a concept called “quick-time events”—basically, the game throws you into a fast-paced situation (such as swinging from a vine or leaping to the next ledge), and you need to quickly press the right button(s) in order to execute the next task successfully. Sometimes, something bad might happen—like a vine snapping or a ledge crumbling—and you’ll need to quickly press another button(s) to try and alleviate the consequences.

This was my inspiration for my third take on skill challenges, which I published on FlutesLoot a year or two after completing the bulk of the original Reloaded.

The guiding principle of this approach was clean-up—trying to remove the mess I’d made across the three different experiments I’d previously done. I started by formalizing the concept of a “skill challenge” into “an action scene: an adrenaline-fueled dash to the finish line.”

I also formalized the physical play-by-play obstacles of a skill challenge—something that had never been present in the original 4e framework—into the concept of “complications,” which might be changing terrain, dangerous events, or sudden hazards.

Here’s how it worked: skill challenges had a certain number of rounds. Each round, a new complication would arise, forcing the PCs to overcome it in order to continue pursuing their overall goal.

One player could volunteer to overcome that complication (“I got this!”), thereby becoming the Active Player. If they succeeded, they got an additional success on the skill challenge; if they failed, they got a failure and the whole party or Active Player suffered some kind of penalty—usually damage. I also standardized the Active Player’s turn into the same action/bonus action/reaction setup I’d used for the avalanche skill challenge, and codified the rules for expending resources (e.g., using equipment was a +2 to the roll, using a minor spell or feature gave you advantage, and using a major spell or feature automatically succeeded).

This was a lot cleaner than the ramshackle, slapped-together challenges I’d been making before. Suddenly, there was a real system to use—a system that, I’m proud to say, is still #1 on Google Results for “how to run a skill challenge.”

Even so, it had real, substantial flaws. This system represented an unpleasant concession—moving away from the play-by-play system I favored and toward more of the abstracted montage experience I didn’t. You still couldn’t really account for nonlinear routes cleanly.

And players still struggled with creativity. You could lead a horse to water, but no amount of coaxing would persuade it to use a Nature check to jump over a tree trunk instead of Athletics.

To add insult to injury, something had been bothering me about skill challenges for a while now, and this codification finally helped me realize what: They were too short.

Combat encounters tend to take between 30 to 90 minutes each. Social encounters might take a similar amount of time, or a bit shorter if they’re fairly straightforward. Puzzles (assuming they’re good ones) might take 15 to 45 minutes to complete.

But skill challenges went quickly. Since you had <10 rounds and only one player acting per round, you wound up finishing them in 15 minutes or less—and usually less. As a result, they felt less like real gameplay than a brief interlude. They captured the sense of adrenaline I’d been hoping for, but that adrenaline came and went too quickly without making much of an impact. They felt like gameplay for the sake of gameplay—a montage of events that could have easily been skipped.

This model wasn’t working. Somewhere along the line, I’d made a fundamental miscalculation—a deep mistake that was breaking my entire approach.

I shelved this issue for a while, working on other projects while the problem slowly percolated in the back of my head. And then, like a good half of my ideas, the answer came to me in a familiar place: the shower.

The Revelation

One of the most often forgotten rules in 5e is the Multiple Ability Checks rule. Put simply, this rule states that players should automatically succeed on any check that it is possible for them to succeed on, so long as there is no consequence for failure and they spend ten times as much time as a single attempt would consume. This is, in a nutshell, 5e’s answer to the “take 20” rule of prior editions—spend extra time, and do as well as you possibly can on the skill check you’re attempting.

This rule is particularly important because you often wind up in a lot of situations in which players are attempting to surmount an obstacle (e.g., a locked or barred door) and have all the time in the world with which to do so. DMs who forget about this rule often wind up with awkward or embarrassing results, and tend to either force players to roll the same d20 repeatedly until they succeed or limit players to one roll each while allowing other players to make the same check after the first player has already failed.

(This gets very very strange when the barbarian with +5 Strength rolls a 9 to break down the door and fails to beat the DC of 15, and the wizard with -1 Strength rolls a 20 to break it down and succeeds with a 19 because the barbarian wasn’t allowed to try again. Was the wizard just stronger than the barbarian?)

Applying the Multiple Ability Checks rule solves this problem—but raises the inevitable question: Why do we even have those DCs anyway? Why do we care that it’s a DC 20 to pick this particular lock if the rogue can just take 10 minutes to do it without ever rolling a die?

This question has three possible answers:

1. It’s tradition to include DCs, even if they don’t really matter, and it might matter if a PC has a particularly low bonus or the DC is particularly high (e.g., 20 or above).
2. It’s a design oversight and someone messed up or didn’t think hard enough about it.
3. The DC is meant to be used in combat (i.e., a place where you can’t really afford to take ten times the minimum time for a single attempt).

Now, I personally lean toward some combination of A and B. There are lots of skill-check DCs scattered throughout official campaign modules in which the probability of combat happening nearby is approximately zero. But the existence of answer C reveals a startling fact.

Let’s rewind and ask ourselves: Why are we talking about the multiple ability checks rule and “taking 20”? What does this have to do with skill challenges?

What if I told you that 5th Edition D&D already has a mechanical system in place to adjudicate quick-time events and action scenes? What if I already told you that this system is well-equipped to handle discrete, play-by-play narrative actions? What if I told you that this system is also robust and suitable for both linear and non-linear situations alike?

What if I told you that this system is called combat?

The Final Experiment: The Combat Encounter

This was my final, crazy, (hopefully) genius plan: run skill challenges as combat-less combat encounters.

Or, to put it another way: steal the initiative system from combat encounters and use it to run skill challenges. Plop the players down on a battlemap, roll initiative, and you’re off to the races.

But how do you run initiative without enemies? I came up with two basic ideas:

1. Obstacles. Environmental terrain (e.g., pit traps) that are triggered when the players reach a certain point or take a particular action.
2. Threats. Creatures, objects, or other events that appear on initiative count 20 and either (a) immediately force the players to make a saving throw, (2) force the players to make a saving throw when they take a particular action, or (3) force the players to make a saving throw on initiative count 0.

To create a sense of progression and stakes, I also added two additional components:

1. Countdowns. Harmful or catastrophic events that take place when the skill challenge reaches a particular round (e.g., a collapsing house or an oncoming avalanche).
2. Complications. Harmful or foreboding events that (a) serve to signal that the end of the countdown is growing near, and/or (b) punish the players for failing to complete the skill challenge.

So you wind up with a skill challenge system that, in its simplest form, might look something like this:

• The players are in a cavern that’s flooding. It’ll flood completely at initiative count 20 of the 5th round (countdown). On initiative count 20 of rounds 3 and 4, the earth rumbles as more geysers of water burst from the floor, threatening to knock players prone (complications).
• When the players first reach a particular ledge, it crumbles and creates a gap in the path (obstacle). On initiative count 20 of the first round after the players cross that ledge, the stalactites overhead begin breaking from the ceiling, giving the players until initiative count 0 to prepare for their descent (threat). If the players ever fall in the water or start their turn there, they’ll need to make a Dexterity saving throw to avoid the ravenous swarms of quippers that lurk there (threat).
• To escape the cavern, the players must ascend a set of tangled vines (obstacle) and unlock or otherwise bypass a rusted iron gate (obstacle).

This solves the linearity and messiness problems—now, you have a real sense of play-by-play dynamics with an emergent narrative arising from the players’ individual actions.

However, I hadn’t yet solved the creativity problem—even with this framework, you’re still going to have lots of players who aren’t sure what to do on their turns. To fix that issue, I needed to take things another step further.

More than a year ago, I wrote a blog post discussing the concept of verbs. Here’s the relevant excerpt from the post’s introduction:

“In real life, a “verb” is something someone does. I run. You think. We build.

“In games, “verbs” are very similar, but with one notable caveat. Because games are, obviously, not real life, the only verbs that you can use in a game are the ones that the game gives you.”

The base D&D 5e game gives players their verbs in the form (mostly) of actions: Attack, Cast a Spell, Use Magic Item, Dash, Dodge, Disengage, Grapple, Hide, Shove, Help, Ready, and so on. The vast majority of these verbs are primarily combat verbs—Disengage, Grapple, and Shove are in fact only useful in a combat context.

No wonder, then, that it’s so difficult for players to find opportunities to use their skills—with the exception of Search (Perception) and Hide (Stealth), the game doesn’t give them any verbs with which to do so!

I began to wonder: What would a skill-based verb framework look like? I briefly perused the Pathfinder 2e actions list, but it wasn’t quite what I was looking for, with the exception of a few particular actions like Raise a Shield (lift your shield to defend yourself).

However, while I’ve historically been an opponent of Pathfinder’s bloat of rules, I was suddenly fascinated by the opportunity to expand the players’ verbs; rather than adding complexity to the Dungeon Master’s side of the screen, I wanted to add agency to the players’ side instead.

And so I began by asking ChatGPT to list all of the skills in 5e and then brainstorm 2-3 possible verbs for each skill. I got a few stinkers, but most of them gave me a jumping-off point that I could use to develop the idea further and propose some accompanying rules.

(Un)fortunately, I was sufficiently inspired that I wound up creating more than 30 new skill-based actions! (Oops.) At first I felt sure that players would be overwhelmed—until I came up with the idea of tying most (though not all) of these actions to player proficiencies in the relevant skills. For example, while “Balance” (which allows a player to cross a narrow or slippery surface) is available to all players, “Block” (which allows a player to use a shield to protect themselves and others) is only available to players with proficiency in Athletics.

(You can find a full list of these new skill-based actions, as well as a more formalistic explanation of skill challenges, in the DM’s Toolkit here.)

One of the fun (but tricky) parts of this development process was that I was firmly against limiting these new actions to skill challenges. After all, you can use the Hide action both in and outside of combat! Restricting players from using the Block action against a fire-breathing dragon felt both mean-spirited and entirely artificial.

As such, one of the fun parts of the post-design balancing and development was ensuring that none of these actions would outshine any real class features or abilities that consume real resources to use. I wanted to create actions that were, at best, sidegrades to things that the players could already do in combat, social encounters, and the world of the game at large—not strict upgrades that they’d feel obliged to use everywhere.

This proved especially difficult with some of the new social actions (e.g., “Appease,” which can convince a hostile creature not to attack you for a brief time), but I eventually reached a point where I felt fairly confident that the bulk of these actions would be more useful in a skill challenge than anywhere else, while still feeling sufficiently grounded in the world and game such that they wouldn’t break immersion or feel too abstract.

An hour or two after I’d finished drafting the new system and verbs, I playtested a revised version of the Death House escape sequence skill challenge with a pair of patrons in the Patreon Discord server. I’ll let their feedback speak for itself:

• “honestly, this felt like what i expect D&D to feel like. interactive, room for creativity, and fun”
• “yeah I'd say this is a winner of a system. it made me feel cool.”
• (from an onlooker) “Reading what transpired you can really see how fluid everything was, the level of creativity that came out, and just how much fun everyone was having. So excited to think about incorporating this into my game.”
• (from another onlooker) “I also read this whole thing. It made me want to play dnd. Good job everyone. 🙌”

Houston, it looks like the Eagle has landed 😎.

Epilogue

I wound up removing the skill challenges from Death House and the Wizard of Wines.

While the Wizard of Wines challenge never really made sense to me, striking the Death House skill challenge really felt like killing a darling—but it had to be done. This new system was too broad, too ambitious, too mechanically innovative to be included as part of a guide and revision to an official module. I couldn't simultaneously ask DMs to trust that I'd keep things elegant and simple while also stuffing in a brand-new mechanical system that I planned to use a maximum of three or four times across the entire adventure.

That doesn't mean, however, that skill challenges are gone from my games forever. Curse of Strahd isn't the right place for them, but action-packed adventures like Tomb of Annihilation might be a far better home. And in my own impending homebrew campaign, I'm sure that there'll be plenty of opportunities to include the dynamic action sequences that I want—and that my players will be more than happy to be the guinea pigs for my continuing experiments.