Name the job of chance
Chance can select a harmless visual variation, choose among equivalent routes or determine a high-stakes reward. If a random event can end a run, tell the player what kind of risk exists and offer a cue or decision where possible. If chance only changes scenery, it may need little explanation. Write down the player expectation before implementing the roll; surprises are enjoyable when they vary a rule the player understands.
Protect meaningful choices
Check whether a player can respond to the outcome. A random obstacle may be fair when it appears early enough to avoid; the same obstacle can feel arbitrary if it arrives after the last possible input. Avoid letting random rewards erase the value of deliberate play unless swinginess is part of the intended design. For repeated rewards, consider whether a dry streak or duplicate result would still feel acceptable from the player’s perspective.
Test distributions and perception separately
Log outcomes during testing and compare observed variety with the distribution you intended, but do not assume a short sample proves a probability. Ask players if it felt fair and what they think influenced the result. Those are different questions: implementation can match its target while the experience still feels biased. MDN notes that JavaScript Math.random returns pseudo-random values and is not suitable for security-sensitive use; game fairness and security are separate concerns.
Questions about fair randomness in games
Does random mean unpredictable to every player?
No. Players may infer patterns or notice streaks even in a random system. Explain the relevant rule and test how outcomes are perceived over repeated sessions.
Can I use Math.random for game outcomes?
It can supply pseudo-random values for ordinary game variation, but MDN warns that it is not cryptographically secure. Do not use it for security-sensitive decisions.