Probability Analysis
If your system uses dice, you eventually need to know the math. What’s the chance a character hits a target of 15 with a 2d6+3 roll? How does that chance scale if they add another die? How does a contested opposed roll between a 4d6 attacker and a 3d6 defender actually distribute? These questions have exact answers, and most authors solve them with a whiteboard and rough intuition. The result is magic systems and TTRPG mechanics that are imbalanced in ways the author doesn’t notice until playtesting reveals it — and by then, the system is in print, or the novel is drafted, or both. The probability analyzer in the Magic System module exists to kill this whole category of problem before it reaches the page.
It reads dice notation from your ruleset’s formulas and abilities, runs exact combinatorial analysis or Monte Carlo simulation depending on pool size, and gives you distributions, power curves, and opposed-roll probabilities as interactive charts. You can see, visually, whether a given roll is “usually” going to succeed, how sharply success scales with pool size, and how wide the margin distribution is for any contested roll. No external tools. No spreadsheets. No hand-rolled probability.
What it analyzes
Section titled “What it analyzes”Three distinct analysis modes, each tuned to a different question:
Single pool analysis. Given a specific dice pool — say, 3d6 or 4dF or 2d20kh1 — what does the distribution of outcomes look like? You get a histogram of every possible sum, the mean, the standard deviation, the minimum and maximum, the median, and the probability of meeting or exceeding each named difficulty class (DC) tier in your ruleset. If you’ve set up dice outcome bands (“1-3 = Failure, 4-7 = Mixed, 8-9 = Success, 10 = Critical”), you get per-band expected counts.
Power curves. Given a dice pool where the number of dice varies, how does the probability of success scale? A power curve is a line chart plotting success probability across pool sizes from 1 die to 50 dice, with a separate line for each DC tier. You see, visually, whether a system is linear (each die adds a similar chance), exponential (early dice matter most), or leveled (certain pool sizes are breakpoints). For authors designing systems with progression, this is the chart that answers “does my system’s advancement actually feel meaningful?”
Opposed rolls. Given two pools — attacker vs. defender — with optional flat bonuses, what’s the probability the attacker wins? What’s the probability of a tie? What’s the expected margin, and how wide is the margin distribution? Opposed rolls are the hardest analysis to do on a whiteboard because there are two pools of randomness interacting, and the intuition most authors have about them is usually wrong. The analyzer runs the convolution exactly (for small pools) or Monte Carlo (for large pools) and gives you the actual numbers.
The math engine
Section titled “The math engine”Two computation strategies, chosen automatically based on pool complexity:
Exact combinatorial analysis runs when the pool is small enough to enumerate — typically up to 20 dice with basic notation. The engine computes the exact probability of every possible outcome by walking the full combinatorial tree. Results are mathematically exact, not approximations.
Monte Carlo simulation runs when the pool is too large or uses modifiers (exploding dice, reroll, keep-highest-of-many) that expand the combinatorial space beyond what exact enumeration can handle in reasonable time. The engine runs tens of thousands of simulated rolls and reports empirical distributions. Results are approximations, but they’re tight enough that the difference between exact and simulated is within sampling noise.
The strategy is chosen automatically. You don’t pick it. The analyzer shows a small label indicating which mode it used (“exact” or “~100,000 samples”) so you know whether your result is theoretical or empirical.
What the charts look like
Section titled “What the charts look like”Each analysis mode has dedicated visual output:
Single pool. A histogram showing the probability of each possible sum. Bars are color-coded by outcome band if you’ve configured bands. A DC threshold overlay shows horizontal markers for each DC tier so you can see, at a glance, which outcomes exceed which difficulty. A summary card next to the histogram lists the statistical measures (mean, std dev, min, max, median, percentiles).
Power curve. A line chart with pool size on the X axis and success probability on the Y axis. One line per DC tier, each in a distinct color. Hover any point to see exact probability values. The shape of the curves tells you how steeply each difficulty scales — a system where the DC=15 line is flat from pool size 5 onward is a system where adding dice past 5 doesn’t meaningfully change your chance against Medium difficulty, which might be a design flaw or might be intentional.
Opposed rolls. A donut chart showing win / tie / loss percentages for the attacker. Alongside it, a margin distribution histogram — if the attacker wins, by how much? Margin matters because in some systems the margin of success determines the effect magnitude. A system where the attacker wins 55% of the time but with a very tight margin distribution plays very differently from a system where the attacker wins 55% of the time but sometimes wins by huge margins.
All charts are interactive — hover for exact values, click to drill in, resize to fit the panel.
Integration with ruleset definitions
Section titled “Integration with ruleset definitions”The analyzer reads dice notation directly from the ruleset’s formulas and abilities. When you run an analysis, you pick a source — a specific formula, a specific ability’s damage, or a custom pool you enter manually — and the analyzer uses the dice notation from that source as the pool definition.
This matters because it keeps the analysis tied to the canonical system. If you later change the Fireball ability to do 4d6 instead of 3d6 damage, running the analyzer on Fireball uses the new notation automatically. You don’t have to re-enter the pool or remember the old values. The analysis reflects the current ruleset.
Use cases
Section titled “Use cases”A handful of things the analyzer is actually useful for:
Balance checking during system design. You just designed a new ability. You want to know whether it’s over-tuned or under-tuned at different character levels. Run a power curve on the ability’s attack roll across pool sizes matching your expected level progression and see whether the curve hits the sweet spot (roughly 60-70% against appropriate-difficulty DCs) at each level.
Sanity-checking scenes during drafting. You’re writing a combat scene. The protagonist rolls 2d6+4 against a DC 15 target and misses. Is that plausible? Run a single-pool analysis on 2d6+4 and see — if the chance of hitting 15 is 8%, a miss is entirely plausible. If the chance is 92%, your scene needs to acknowledge that the miss was unusually unlucky.
Opposed-roll dramatic tension. A crucial fight between two characters. You want to know the dramatic weight — is one character obviously favored, or is it actually a coin flip? Run an opposed-roll analysis with their pools and the chart tells you.
Playtesting replacement. You’re designing a TTRPG system and you haven’t playtested yet. Power curves and opposed-roll analysis give you a preliminary sense of whether the math works before anyone rolls a real die.
What the analyzer can’t do
Section titled “What the analyzer can’t do”A few deliberate limits:
- No narrative modeling. The analyzer operates on raw probability, not on how rolls feel during play. A roll that’s statistically reasonable may still feel bad at the table because of pacing, expectations, or prior rolls. The analyzer can’t tell you how a roll feels.
- No character-level simulation. It analyzes individual rolls, not full combat encounters. If you want to know “how long will a fight between a level 5 wizard and a level 5 fighter last,” that’s a different tool — the analyzer only covers single-roll math.
- No homebrew dice. The engine supports standard polyhedral notation (d4, d6, d8, d10, d12, d20, d100) and Fate dice (dF). If your system uses something more exotic — a custom card deck, a random table lookup, a qualitative resolution mechanic — the analyzer can’t help. You’d need to fall back on Monte Carlo simulation outside the module.
- No gameplay branching. A roll that triggers a reroll that triggers another effect can be hard to model exactly. The engine handles basic reroll and exploding dice, but deeply branching mechanics may require Monte Carlo fallback or manual analysis.