Resolution Mechanics — The Engine Room of the Game
A quick note before we start.
Resolution mechanics sit at the center of almost every tabletop RPG. They determine how uncertainty is handled, how often players roll dice, and what success or failure actually means in play.
Because of that, this post is a little longer than the previous ones.
The goal here isn't just to explain the system used in Threshold. It's to walk through the design choices that led to it. Resolution mechanics are effectively the backbone of a game system. Once they are set, many other rules grow out of them: attributes, skills, combat pacing, difficulty scales, and how tension appears at the table.
So before getting into the specifics of Threshold, it's worth stepping back and looking at what I needed the resolution system to do in the first place.
What Resolution Mechanics Actually Do
Every tabletop RPG eventually reaches the same moment.
A player attempts something uncertain.
Maybe a character tries to climb a crumbling tower wall during a storm. Maybe they attempt to stabilize a dying ally. Maybe they try to read the motives of someone whose intentions are carefully hidden.
At that point the game has to answer a question:
What happens next?
Resolution mechanics are the procedures a game uses to answer that question. They translate fictional uncertainty into mechanical outcomes.
The specific tools vary widely—dice, cards, tokens, towers of wooden blocks—but the purpose is always the same. They determine whether an action succeeds, fails, or produces something in between.
The shape of that system has a profound effect on the experience of play. Some systems emphasize unpredictability and dramatic swings. Others favor reliability and modeling competence. Some prioritize narrative consequences over tactical precision.
Changing the resolution mechanic often changes the feel of the entire game.
What I Needed From Threshold's Resolution System
When I started designing the resolution mechanics for Threshold, I had a clear set of constraints based on the ability score and skill systems I'd already committed to.
I needed a system where:
Characters could improve without becoming untouchable. Advancement should feel meaningful, but it shouldn't remove risk entirely.
Competence felt reliable without becoming predictable. Skilled characters should succeed more often, but uncertainty needed to remain present even for experts.
Failure produced momentum rather than dead ends. I didn't want binary pass/fail outcomes. Partial successes and failures with consequences needed to be built into the core system.
The math stayed visible and direct. Following the principle from the ability scores post, I wanted the numbers players saw to be the numbers they used—no hidden conversions or lookup tables.
Those constraints immediately ruled out some approaches and pointed toward others.
The Options I Considered
I spent a lot of time analyzing how different resolution systems behave, particularly how their probability distributions shape the experience of play.
Flat Distributions: The d20 Model
The most familiar approach is the d20 system used in Dungeons & Dragons. Every result from 1 to 20 has exactly the same probability of appearing.
I've played enough D&D to know what this feels like at the table. The flat distribution creates dramatic swings. Experts can fail spectacularly, and novices can occasionally succeed through sheer luck. That volatility supports cinematic moments, but it makes competence feel inconsistent.
For a game built around grounded protagonists who grow through experience, that didn't fit. I wanted skilled characters to feel skilled, not just lucky.
d20 distribution
Bell Curves: The 3d6 Model
Systems like GURPS roll multiple dice and add them together, often using 3d6. Because many dice are combined, results cluster toward the middle.
The bell curve produces something different. Skilled characters succeed more reliably, while extreme results become rare. This models competence well, but it has its own tradeoff: the math gets heavier. Addition slows down resolution, and modifiers pile up quickly.
More importantly, scaling becomes a problem. To keep difficulty meaningful as characters improve, you have to inflate both the target numbers and the bonuses. Eventually you're adding +15 to beat a target of 23, and the actual dice rolls start to feel ceremonial.
3d6 distribution
Dice Pools: Counting Successes
The third approach I examined was dice pools, where multiple dice are rolled and each die can contribute a success independently.
Games like Shadowrun, Blades in the Dark, and World of Darkness use variations of this pattern. The number of dice rolled reflects a character's competence, and results are interpreted by counting successes or selecting the highest die.
What appealed to me about dice pools was how they scale. Adding dice to the pool gradually increases reliability without requiring inflation. A character with 6 dice is meaningfully better than one with 3 dice, but they're still operating in the same mathematical space. The dice themselves don't change—just how many you roll.
This aligned with the horizontal progression model I wanted. Characters don't grow from rolling d6s to rolling d20s. They roll more dice, more reliably.
Expected Successes vs Pool Size
Other Models I Looked At
I also examined more unusual resolution systems to see what they prioritized.
Dread replaces dice entirely with a Jenga tower, creating physical tension during horror scenes. The tower's instability mirrors the characters' precarious situation, and every pull reinforces the genre. His Majesty the Worm uses tarot cards for action resolution, where the symbolic weight of each card adds interpretive depth to outcomes. Genesys uses custom dice with symbols instead of numbers, allowing a single roll to produce success, failure, advantages, and threats simultaneously.
What all of these systems have in common is that they integrate the feel of the game directly into the resolution mechanic. The dice aren't just producing numbers—they're reinforcing tone and genre expectations.
That's powerful, but it comes with a cost. Custom dice require learning a new symbolic language. Tarot cards demand interpretation. Jenga towers create physical tension but can't be used for every roll without losing impact.
For Threshold, I needed something that could handle frequent tactical decisions, environmental pressure, and long-term play without becoming unwieldy. The resolution system had to support the game's themes without slowing down adjudication every time someone climbed a wall or swung a sword.
Distribution graphs for 2d6 (PbtA, Traveller), 2d12 (Daggerheart), and 2d10 (M.E.G.S, Draw Steel) and 2d20 (Modiphius) systems, all of which I considered.
Dice pools offered the right balance. They could scale elegantly, they used familiar tools, and they left room for the fiction to reinforce tone rather than demanding that the mechanics do all that work alone.
Why Dice Pools Fit Threshold
Dice pools solved several problems at once.
They allow characters to improve by becoming more reliable, rather than by inflating numbers to extreme levels. Additional dice gradually increase the likelihood of success while still allowing unexpected outcomes.
They support the grounded protagonist philosophy. A character with 8 dice in their pool is experienced and capable, but they're not superhuman. They can still fail. They can still be caught off guard.
They also make partial success easy to model. Instead of binary pass/fail, the number of successes naturally creates gradations of outcome. That became the foundation for the outcome tier system I'll explain below.
How Resolution Works in Threshold
Once I committed to dice pools, the core resolution process came together quickly.
The flow is straightforward:
A player declares an action.
If the outcome is uncertain and meaningful, a roll is called for.
GM sets Target Number (TN)
The player builds a dice pool from their attributes and skills.
Dice are rolled.
Results are evaluated by counting successes.
The number of successes is compared to the TN.
The final result falls into one of four outcome tiers.
Why Four Tiers?
I settled on four outcome tiers after testing several variants. Three felt too binary—you either succeeded or you didn't, with only one middle ground. Five created too much interpretation overhead and slowed down adjudication.
Four tiers gave me enough granularity to make partial success interesting without bogging down play.
The tiers work like this:
Critical successes produce exceptional outcomes or avoid complications. Successes achieve the intended result cleanly. Partial successes accomplish the goal but introduce costs, complications, or delays. Failures mean the attempt doesn't work—but they often create new problems or reveal information.
This structure allows the system to produce more nuanced outcomes than a simple success-or-failure model, which was one of my core design goals.
Building the Dice Pool
Dice pools in Threshold are constructed from three elements:
Attribute Quality determines the number of base dice.
Domain determines the die size (d6, d8, or d10).
Skill ranks add additional dice to the pool.
Every die showing 5 or higher counts as a success.
The choice of 5+ as the success threshold was deliberate. It creates approximately a 40–50% success rate per die depending on die size (33% on d6, 50% on d10), which sits in a useful middle ground.
If the threshold were lower—say, 4+—dice pools would succeed too reliably too quickly, flattening the risk curve and making advancement feel less meaningful. If it were higher—6+—early characters would struggle to generate any successes at all, and the system would feel punishing rather than tense.
At 5+, a small pool of 2–3 dice feels uncertain but not hopeless. A larger pool of 6–8 dice feels capable but not guaranteed. That's the reliability curve I wanted: competence matters, but it never removes risk entirely.
This approach creates a balance between specialization and flexibility. Skills increase the number of dice rolled, while attributes influence the quality of those dice.
The result is a system where characters improve primarily through greater reliability, not through exponential scaling.
Target Numbers and When Rolls Actually Matter
Once the dice pool is defined, the system needs a way to interpret the results. That role belongs to the Target Number (TN).
In Threshold, most tasks fall into the following difficulty bands:
However, the numbers themselves are only part of the system.
A common pacing problem in tabletop RPGs is rolling for actions that should never meaningfully fail. Dice are rolled simply because rolling dice feels like participation.
That instinct is understandable, but it weakens the resolution system.
The outcome tiers only produce interesting results when all four outcomes are genuinely possible and distinct.
If failure carries no consequence, or if a critical success wouldn't change anything meaningful, then the roll isn't doing useful work.
The principle I kept coming back to was this: only call for a roll when all four outcome tiers are plausible.
If success is guaranteed, resolve the action without rolling. If failure is unavoidable, the attempt simply fails—no need to touch the dice.
Because of that principle, tasks with TN 1 rarely require rolls during normal play. They exist primarily for situations where a character is impaired, disadvantaged, or working under extreme pressure. Most meaningful rolls occur at TN 2 or higher, where uncertainty actually matters.
This keeps the dice focused on moments of tension rather than slowing the game with unnecessary checks.
Example: Two Approaches to a Locked Door
Two characters encounter a locked door blocking their path. The door is sturdy wood, and the lock looks a bit rusty. One character wants to pick the lock quietly. The other wants to break it down.
The Thief (Finesse specialist, precision approach)
This character relies on Wit (Mind Domain + Finesse Quality) and has trained extensively in Skullduggery.
Finesse Quality: 3 = 3 base dice
Mind Domain (Primary) = d10s
Skullduggery rank 2 = +2 dice
Final pool: 5d10
The GM sets the Target Number at 2 for picking the rusty lock. The rust makes the mechanism less precise and easier to manipulate.
The thief rolls: 6, 1, 7, 3, 3
Counting 5+: two successes (6, 7)
Result: Success. The thief meets the TN exactly and opens the lock cleanly and quietly.
The Barbarian (Force specialist, brute force approach)
This character relies on Might (Body Domain + Force Quality) and has some training in Athletics.
Force Quality: 3 = 3 base dice
Body Domain (Primary) = d10s
Athletics rank 1 = +1 die
Final pool: 4d10
The GM sets the Target Number at 3 for breaking down the sturdy wooden door. It's solid construction and will take real effort.
The barbarian rolls: 2, 7, 5, 4
Counting 5+: two successes (7, 5)
Result: Partial Success. The barbarian has successes but falls short of the TN. They break through the door, but it takes longer than expected, makes a tremendous amount of noise, or splinters the door frame badly enough to alert anyone nearby.
What This Shows
Both characters rolled similar pool sizes (5d10 vs 4d10) and got the same number of successes (2). But because they approached the problem differently, the outcomes diverged.
The thief's method had a lower TN because picking a rusty lock is relatively straightforward for someone with the right skills. Two successes were enough for a clean result.
The barbarian's method had a higher TN because breaking down a sturdy door requires significant force. Two successes got them through, but with complications.
This is how the system rewards different approaches. The choice of how to solve a problem matters as much as raw capability. A character optimized for precision can accomplish things quietly that would be loud and messy for someone relying on brute strength—even when both characters are equally competent in their own domains.
Player-Facing Rolls
Another structural decision in Threshold is that players make all the rolls.
When characters attack an enemy, players roll to hit. When enemies attack them, players roll to defend.
I tested both approaches during early playtests. Having the GM roll for enemies felt more traditional, but it consistently created dead air—players waiting to see what happened to them rather than actively responding. Player-facing rolls kept everyone engaged, even during enemy turns.
There's also a narrative reason. The story ultimately follows the characters. Their decisions and reactions drive events forward. Structuring the system so that players make the rolls reinforces that perspective.
An additional benefit is practical. Because players handle the rolls tied to their characters, the GM can focus on describing the world, portraying NPCs, and managing the broader flow of the scene.
What Comes Next
With the resolution system established, the next question is how characters actually interact with the world mechanically.
What can characters do on their turn in combat? How do attacks and defenses work in practice? How does the environment create pressure beyond just raising target numbers?
The next post will focus on combat structure and action economy, showing how the dice pool system translates into tactical decisions at the table.
What I Worked On
This stage of design focused on refining how actions are resolved at the table.
Much of the work involved stress-testing different probability models and evaluating how dice pools behave. I built spreadsheets comparing expected success rates across different pool sizes and target numbers. I ran sample combats on paper to see how often partial successes occurred and whether the four-tier outcome system actually produced the variety I wanted.
The biggest challenge wasn't the math itself—it was figuring out when the system should be used at all.
What Went Wrong
Early drafts encouraged rolling too often. If players constantly rolled for trivial tasks, the outcome tiers lost meaning and pacing suffered. More fundamentally, it trained players to expect dice for every action, which made it harder to establish narrative flow.
The other issue was target number calibration. Too many tasks defaulted to TN 3, making difficulty feel samey. I needed better guidance on spreading tasks across TN 2, 3, and 4.
I also tested different success thresholds (4+, 5+, 6+) to find the right reliability curve.
What I Changed
The biggest shift was reframing when rolls happen at all. The system now explicitly treats rolls as tools for resolving meaningful uncertainty—not routine procedures. Only call for a roll when all four outcome tiers are genuinely possible and distinct.
That principle reshaped how the TN table works. TN 1 exists primarily for impaired or disadvantaged situations. Most meaningful tasks start at TN 2 or higher.
Testing confirmed that 5+ as the success threshold created the reliability curve I wanted—small pools feel uncertain but not hopeless, large pools feel capable but not guaranteed.
What I'm Testing Next
The next step is observing how these mechanics behave in actual play with real groups.
Specifically, I want to test:
How quickly players internalize the dice pool system without extensive explanation
Whether target numbers feel intuitive during play, or if GMs struggle to calibrate difficulty on the fly
Whether the "only roll when all outcomes matter" principle holds up in practice, or if groups drift back toward rolling for everything
How the system performs across different play styles—tactical groups vs narrative-focused groups
Paper testing and spreadsheets can only tell you so much. The real test is whether the system supports the kind of play I designed it for when people actually sit down at a table.
Questions
When you play RPGs, do you prefer resolution systems that emphasize dramatic swings or consistent competence?
How often do you find yourself rolling for trivial actions at the table? One of the design goals of Threshold is making each roll feel meaningful rather than routine, and I'm curious how other groups handle that balance.
Have you played games with player-facing rolls? Did it change how combat felt, or did you find it awkward?
