How to Roll Multiple Polyhedral Dice Online and Track Roll History

A dice pool is not a single random number

Rolling one die is a solved problem. Rolling a pool — three of one type, two of another, summed with a modifier, recorded so you can show the table what happened — is a different problem, and it has three parts that need to work together: the roll, the total, and the log.

The notation is worth stating plainly because it is the fastest way to get the wrong answer. A pool is written as a count followed by the die type. 2d20 means two twenty-sided dice, and the result is the sum of both, which ranges from 2 to 40 and is not uniform. 3d6 means three six-sided dice, ranging from 3 to 18. A mixed pool such as 1d20 + 2d8 + 3 adds a flat modifier to the sum of all the dice, and the modifier is applied after the sum, never to each die.

The sum is not uniform, and that matters at the table

A single die is uniform: every face is equally likely. A pool is not, because the middle sums can be produced by many combinations and the extremes by only one. Two six-sided dice have 36 equally likely ordered outcomes, and the distribution of their sum looks like this:

Seven appears six times out of 36, or 16.7 percent. Two and twelve appear once each, or 2.8 percent. Anyone who has wondered why 7 is the most common result on 2d6 now has the reason: it has the most combinations. A pool roller that reported each die and the total is showing you the raw data; the shape above is what makes those totals interpretable.

How the roll is generated

A client-side roller has three plausible sources of randomness, and they are not equivalent.

Math.random() is the obvious one. It is fast, and it is a pseudo-random generator — a deterministic formula whose output depends entirely on its internal state. It is fine for a board game. It is a poor choice for anything with an incentive attached, because the state of a well-known PRNG can be reconstructed from a small number of consecutive outputs, after which the sequence is predictable.

A cryptographically secure generator is the better option, and it is available in the browser without any library. The implementation used here draws a 32-bit unsigned integer from the platform's cryptographic source and maps it onto the die range:

roll = floor(random × sides) + 1

with the random value uniform on the half-open interval from 0 to 1.

There is a theoretical bias in that mapping, and it is worth quantifying rather than dismissing. A 32-bit source has 4,294,967,296 possible values, and no die count divides that number evenly. For a d6 the remainder is 4, so four faces are reachable by 715,827,883 values and two by 715,827,882 — a relative difference of about 1 in 700 million. For a d20 the remainder is 16, giving a relative difference of about 1 in 200 million. For a d100 the remainder is 96, giving about 1 in 43 million. Every one of those numbers is far below the point at which any dice game could detect it, and the correct conclusion is that the modulo issue is a non-issue at this range — not that it does not exist.

What the animation is actually doing

The tumble is theatre, and it is worth knowing exactly how much.

When you press roll, the real values are generated first, as a complete array, before any animation begins. The tumbler then displays a sequence of plausible faces — five frames, about 120 milliseconds apart — and after roughly 690 milliseconds it replaces them with the values that were already decided. The rendered outcome is therefore fixed at the instant of the click and cannot be changed by when you stop watching, how long the animation runs, or anything else you do on the page.

That ordering is the correct one, and it is also the honest one. A roller that animated first and computed the result at the end would give the user some control over the outcome through timing, which is the exact failure mode a random roller is supposed to eliminate. If a tool's documented behavior is that the result appears before the animation, that is a statement about its integrity, not about its performance.

Where the roll history lives

The log is the part most rollers get wrong, and the failure is usually about expectations rather than implementation. In a tool that requires no account, the history exists in the browser tab and nowhere else. It is not uploaded, not stored against your identity, and not available on another device.

That is the right trade for a gaming tool — no sign-up, no data leaving the machine — and it carries three consequences worth knowing before you rely on it:

• The log survives as long as the tab does. Reloading the page or closing it ends the record.
• It is per-session and per-device. The same roll history will not appear on your tablet.
• Clearing it is immediate and total, which is what you want between games and what you must remember before you clear it mid-session.

If a record needs to outlive the session — a campaign log, a tournament, a set of rolls you may need to justify later — the log is a convenience and not an archive. Note the results somewhere durable, or accept that the record ends with the tab. The scroll-back history is excellent for answering "what did I just roll" and useless for answering "what did I roll last Tuesday".

Rolling mixed pools and checking the working

• Enter the count and the die type separately, so 2d20 is a count of two and a die of twenty rather than a typed string the tool has to parse.
• Roll the pool in a single action rather than rolling each die separately. Separate rolls are harder to read back and easier to mis-sum when a modifier is involved.
• Check the total against the individual faces. The sum is the only derived value on the screen, and it is the one worth verifying if the number looks surprising.
• Use mixed pools with their modifiers written down before the roll. Deciding which dice to include after seeing the faces turns a random roll into a favorable one.

Everything above works on a phone as well as a desktop, because the whole roller runs in the page with no server round-trip and no account. The practical difference between a good pool roller and a mediocre one is not the randomness — that is the easy part — but whether it shows you the individual dice, the total and a usable history at the same time.