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

  1. Content generation → seeded shuffle. Repeatable, debuggable, server-verifiable.
  2. Reward resolution → crypto RNG. Fresh entropy per pull, no predictable window.
  3. 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.

"Deterministic where the world must repeat; unpredictable where the reward must not."

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.