Game Dev
Seeded shuffle vs crypto RNG — what game devs actually use
Two kinds of randomness live inside almost every shipped game, and confusing them causes real bugs. A seeded shuffle lets you replay the same level on the same seed. A cryptographic RNG makes each pull fresh and unpredictable. The skill is knowing which drawer each system runs from.
Reproducibility: the seeded world
Roguelikes, daily quests and speedrun-friendly games want stable content. Give a shuffle a seed, and the same seed always returns the same order — great for a familiar board, a shareable "today's run", or deterministic servers. If your game justifies leaderboards, side with seeds: two players on identical seeds must see identical worlds or the board lies.
Honesty: the crypto world
The moment randomness touches money, rank or loot boxes, reproducibility becomes a liability. A deterministic drop table is a leak — players who map the seed know exactly when the epic item lands. Here you switch to a cryptographic source with no seed to reconstruct.
A two-draw architecture
- Content generation → seeded shuffle. Repeatable, debuggable, server-verifiable.
- Reward resolution → crypto RNG. Fresh entropy per pull, no predictable window.
- Player-facing coincidence → either, but never shave a seed from client wall-clock.
Keeping the two separate lets you ship deterministic modes without dragging security-critical RNG through them. For prototyping the shuffle half, paste a list into randzen's shuffle mode to eyeball output before you write the seed logic.
The wall-clock trap
Seeding client randomness from Date.now() is the single most audited mistake in indie game code. It predicts, it cross-desyncs, and it's trivially brute-forced. Either use a real seed pipeline for content, or reach for a cryptographic pull for rewards. The randzen generator demoes both halves in a tab — no server involved, seed or no seed.