DEV Community: Gowtham R

One Seed, Same Puzzle for Everyone: Seeded RNG for a Fair Daily Challenge

Gowtham R — Tue, 09 Jun 2026 14:04:21 +0000

A few months ago I built a daily brain-training game with prize tournaments — ten small cognitive games, a fresh challenge every day, and a leaderboard that decides who wins real rewards. The first design question wasn't about graphics or game feel. It was this:

If everyone is competing on a "random" puzzle, how do you make sure everyone got the same random puzzle — and that nobody can lie about their score?

Those are actually two problems, and they pull in opposite directions. Fairness wants the randomness to be shared and predictable — every player on a given day should face the identical challenge, or the leaderboard is meaningless. Anti-cheat wants the server to be able to independently verify a score without trusting the player's device. The thing that solves both at once is a seeded RNG.

This post is about that pattern: how a single short string makes a "random" puzzle identical for every player and recomputable on the server, why I deliberately made the seed public (the opposite of what you'd do for a high-score game), and the one game that broke the whole model and forced me to think differently.

A quick note on stack: my client is Flutter (Dart) and my backend is TypeScript edge functions, so that's what the snippets look like. But the idea is language-agnostic — it works the same with Kotlin, React Native, or anything else. The trick isn't the language, it's getting two different runtimes to agree on what "random" means.

The core idea: randomness from a string

A normal random number generator gives you different numbers every time, which is exactly what you don't want here. If my phone rolls a different set of math problems than yours, we're not playing the same game, so comparing our scores is nonsense.

A seeded RNG fixes this. You give it a starting value — the seed — and from that point it produces a fixed, repeatable sequence of "random" numbers. Same seed in, same sequence out, every single time, on every device. It only looks random; it's completely deterministic.

So the daily challenge seed is just a human-readable string:

2026-03-16-speed_calc

Date, plus the game name. That's it. Everyone playing Speed Calc on March 16th derives their puzzle from that exact string, so everyone gets the exact same equations in the exact same order. Tomorrow the date changes, the seed changes, and a fresh challenge appears for everyone at once.

String dailySeed(DateTime date, GameType game) {
  final dateStr = DateFormat('yyyy-MM-dd').format(date);
  return '$dateStr-${game.seedName}';
}

There's no server round-trip to "fetch today's puzzle." The client can generate the whole challenge offline from the date, and the server can regenerate the identical challenge whenever it needs to check a score. The seed is the single source of truth, and it weighs almost nothing.

The RNG itself

The generator is small on purpose. It takes the seed string, hashes it with SHA-256 to get a stable starting state, then runs a classic 48-bit linear congruential generator — the same constants you'd recognize from older Java Random implementations:

class SeededRandom {
  int _state;
  static const int _mask = (1 << 48) - 1;
  static const int _multiplier = 0x5DEECE66D;
  static const int _increment = 0xB;

  SeededRandom(String seed) : _state = _deriveSeed(seed);

  static int _deriveSeed(String seed) {
    final digest = sha256.convert(utf8.encode(seed));
    final byteData = ByteData.sublistView(Uint8List.fromList(digest.bytes));
    return byteData.getInt64(0).abs();
  }

  double nextDouble() {
    _state = (_state * _multiplier + _increment) & _mask;
    return _state / (_mask + 1);
  }

  int nextInt(int max) => (nextDouble() * max).floor();
  int range(int min, int max) => min + nextInt(max - min);
}

Nothing here is cryptographically fancy, and it doesn't need to be — the goal isn't unpredictability, it's reproducibility. The most important comment in my entire codebase lives right above this class: "same seed always produces the same sequence across Dart and TypeScript." That cross-runtime guarantee is the whole foundation. If the Dart client and the TypeScript server ever disagree about what number comes next, everything downstream falls apart.

On top of the raw generator there's a seeded Fisher-Yates shuffle, so a game can pre-generate a pool of, say, 30 equations and shuffle them deterministically. Both client and server build the pool, shuffle it with the same RNG calls in the same order, and walk through it with a cursor. As long as both sides consume the RNG identically, they stay in lockstep forever.

Why I made the seed public (and when you shouldn't)

Here's the design decision I want to call out, because it's the opposite of what a lot of anti-cheat advice tells you to do.

For a high-score game where each run should be unguessable, you'd want a secret, per-run seed issued by the server right before play — so the player can't precompute or predict the run. Unpredictability is the security property there.

A daily challenge is the inverse. The seed is derived from the public date, so it's completely predictable — anyone can work out tomorrow's seed. And that's fine, because fairness, not secrecy, is the goal. Everyone facing the identical puzzle is a feature. Knowing the seed in advance doesn't help you cheat, because the seed only tells you which equations you'll get — it doesn't solve them for you, and it doesn't let you submit a fake score.

That last part is the key, and it's where validation comes in. A public seed is only safe if the server independently recomputes the result instead of trusting the client. The seed makes the puzzle fair; the server-side recompute makes the score honest.

Validation: the server recomputes, then verifies

Every score submission goes through a validate-score function before it counts. The shape is:

Authenticate and rate-limit the user (caps per minute and per hour, enforced in the database so they survive cold starts).
Check the request signature. Each submission is HMAC-SHA256 signed with a secret compiled into the app, plus a timestamp and a one-time nonce. The server rebuilds the signature over nonce.timestamp.body, compares it in constant time, rejects anything older than a 10-second window, and burns the nonce so the same request can't be replayed.
Recompute the puzzle from the seed and check the player's answers against it. That third step is the payoff of the whole seeded design. For Speed Calc, the server re-derives the exact same shuffled equation pool the player saw — same seed, same RNG call order, same ranges — and checks each submitted answer against the equation it knows was on screen. The client's reported score is never trusted; it's recomputed.

The catch is that the two sides have to generate equations identically, in two different languages. Here's the same level-2 equation (addition or subtraction, operands 1–50, subtraction arranged to stay non-negative) in the Dart client and the TypeScript server:

// Dart — client
Equation _level2() {
  final isAdd = _rng.nextInt(2) == 0;
  if (isAdd) {
    final a = _rng.range(1, 51);
    final b = _rng.range(1, 51);
    return Equation(expression: '$a + $b', answer: a + b, difficulty: 2);
  } else {
    var a = _rng.range(1, 51);
    var b = _rng.range(1, 51);
    if (b > a) { final t = a; a = b; b = t; } // keep result non-negative
    return Equation(expression: '$a - $b', answer: a - b, difficulty: 2);
  }
}

// TypeScript — server. MUST match Dart exactly: same RNG call order, same ranges.
case 2: {
  const isAdd = rng.nextInt(2) === 0;
  let a = rng.range(1, 51);
  let b = rng.range(1, 51);
  if (isAdd) return { expression: `${a} + ${b}`, answer: a + b };
  if (b > a) [a, b] = [b, a];
  return { expression: `${a} - ${b}`, answer: a - b };
}

Look closely at the order of the RNG calls — nextInt(2) for the operator, then range(1, 51) twice — because that order is the contract. The server has to pull values off the generator in precisely the same sequence as the client, or the two pools diverge and a perfectly honest player's score fails to validate. The comment in the server file isn't decoration; it's a warning to my future self.

For nine of the ten games, this is clean: the puzzle is pure logic, there's a single correct answer per question, and the server can reproduce it exactly. And then there was the tenth.

The game that broke the model: Reaction Tap

Every other game is computed. An equation has one right answer. A scrambled word unscrambles to one word. A pattern has one next step. The server regenerates the puzzle and checks your answer against a known-correct value. Simple.

Reaction Tap isn't like that, and it was genuinely the hard one to figure out. The game shows a target after a random delay and measures how fast you tap it. The delay is seeded — the server can regenerate exactly when the target appeared. But the score depends on your reaction time, which is a human measurement the server never witnessed. There's no "correct answer" to recompute. I couldn't validate it the way I validated the other nine, and that's the part that took me a while to get right.

The realization was that you stop trying to recompute the score and instead validate the boundaries of what's physically possible. The server still advances the RNG through every round to stay in sync (each round consumes three values — the delay and the target's x/y position), but the actual checks are about plausibility:

const MIN_REACTION_MS = 100;

const tooFast = reactionMs < MIN_REACTION_MS;

// A sub-100ms reaction can never legitimately be a correct hit
if (tooFast && answer.correct) {
  return { valid: false, reason: 'reaction below human minimum — cannot be correct' };
}

// Points are recomputed server-side, never trusted from the client
const points = tooFast ? 0 : Math.max(0, Math.min(1000, 1000 - reactionMs));

Negative reaction time is impossible, so it's rejected. A reaction under ~100ms is faster than a human nervous system can actually respond, so it can't count as a legitimate hit — a tap-ahead bot or a patched timer would show up here. And the points themselves are recomputed from the reported time with the same formula the client uses, so a client that fibs about its score gets overridden.

It's a different shape of validation — verifying a plausible range instead of recomputing an exact answer — and it's the case that taught me the seeded-recompute pattern has a hard edge: it works beautifully for anything deterministic, and not at all for anything that depends on real-world human timing. For those, you fall back to trust boundaries.

What I'd take to the next project

If you're building anything where players compete on shared randomness:

Derive shared puzzles from a seed, not from a per-device random call, so everyone genuinely plays the same thing and the server can reproduce it.
Pick your seed's secrecy to match your goal. Public, predictable seeds for fairness (daily challenges). Secret, server-issued seeds for unpredictability (high-score runs). Same tool, opposite settings.
A seed is only safe if the server recomputes the outcome. Sharing the puzzle is fine; trusting the score is not.
Watch out for anything that isn't purely computed. Reaction time, sensor input, anything measured rather than derived — you can't recompute it, so validate the physically-possible range instead. The seeded RNG ended up being maybe sixty lines of code. But it quietly answers both of the questions I started with — is this fair, and is this real — and that's most of what a competitive game actually needs.

Don't Trust the Score: Building Server-Authoritative Validation for a Prize-Based Mobile Game

Gowtham R — Mon, 08 Jun 2026 14:08:00 +0000

When there's no money involved, a cheater in your game is mostly an annoyance. A leaderboard gets polluted, someone brags about a fake high score, you sigh and move on.

The moment a score can be converted into a real prize — a gift card, a draw entry, actual money — that calculation changes completely. Now a "high score" is a withdrawal request. And the uncomfortable truth I had to start from while building a mobile arcade game where gameplay earns entries into prize draws is this:

Any client-side game can be modified by a motivated attacker.

That's not pessimism, it's just the reality of shipping a game on someone else's device. The APK can be patched to submit fake scores. Methods can be hooked at runtime on a rooted device. Old winning requests can be replayed. Local timers and collision checks can be edited. And the backend endpoint that records scores can be called directly with a forged payload, skipping the game entirely.

So the design principle the whole system is built on is blunt: the game client is an input device, not an authority. It is allowed to tell the server what the player did. It is never allowed to tell the server what the player earned.

A quick note on stack before we go further: my client is built in Flutter and my backend runs as TypeScript edge functions, so that's what the code samples look like. But nothing in this post is Flutter-specific. The model — server-issued seeds, deterministic gameplay, server-side replay, one-time run IDs — applies exactly the same whether your client is Flutter, Kotlin, React Native, or Unity. The language changes; the principle doesn't. Treat the snippets as illustration, not prescription.

This post walks through how I built that — the seed-and-replay model that makes it work, the specific checks that close off each attack, and the things that turned out to be harder than I expected.

The naive version (and why it dies instantly)

The obvious first design is the one almost every tutorial shows you:

Player finishes game → app sends { score: 4820 } → server saves 4820

This is fine for a casual leaderboard. For a prize game it's indefensible. There is nothing stopping anyone from opening up a network inspector, watching that request, and replaying it with score: 999999. You haven't built a game backend, you've built a "type your own prize" form.

The first instinct people have is to "sign" the score on the client, or obfuscate the app, or add a Play Integrity check and call it done. None of that fixes the core problem, because the secret used to sign lives on the device the attacker controls, and integrity checks tell you the binary looks legit — they can't tell you whether the player actually survived 45 seconds or cleared six lines. You can't patch your way out of trusting an untrusted machine.

The only thing that actually works is to stop trusting the score and make the server compute it.

The core idea: deterministic seeds + replay

Here's the model I used.

Every game in the app is deterministic. Given the same starting seed, the game world unfolds identically every single time — the same Snake food spawns in the same cells, the same Tetris-style pieces come out of the bag in the same order. There's no "true" randomness in the gameplay loop; everything random is driven by a pseudo-random generator that's seeded from a single value.

Because of that property, the server and the client can run the exact same game from the exact same seed and get the exact same world. That's the whole trick. If the server can reproduce your game, the server doesn't need to believe your score — it can recompute it.

The flow looks like this:

Player starts a mission. The client calls start-mission-run. The server creates a one-time run, generates a fresh random seed, stamps a rules version and a 15-minute expiry, and returns the seed to the client.
Player plays. The Flutter game seeds its RNG with the server's seed and runs normally. While playing, it records a compact transcript of the player's inputs — every direction change, every move, rotate, hold, and hard-drop, each tagged with the game tick it happened on.
Player submits. Instead of sending a score, the client sends the transcript, a hash of that transcript, and the run ID it was issued.
Server replays. submit-score loads the run, takes the original seed, re-runs the player's recorded inputs through a server-side copy of the game logic, and computes the authoritative score and completion itself. The score the client claims is, at best, used for analytics. It is never what awards a prize.

The deterministic RNG

The piece that makes all of this possible is small and unglamorous — a seeded pseudo-random generator that behaves identically on Dart (client) and on the Deno/TypeScript backend.

The seed comes in as a string, so first it gets folded into a 32-bit integer (an FNV-1a-style hash), then each "random" value is produced by a classic linear congruential generator:

function seedInt(seed: string) {
  let hash = 2166136261;
  for (let i = 0; i < seed.length; i++) {
    hash ^= seed.charCodeAt(i);
    hash = Math.imul(hash, 16777619);
  }
  return hash >>> 0 || 1;
}

function nextRand(state: number) {
  return (state * 1664525 + 1013904223) >>> 0;
}

Nothing exotic here — and that's the point. It's deterministic, it's portable, and it produces the same stream of numbers on both sides as long as both sides advance it the same number of times. When Snake needs to spawn food, both the device and the server call nextRand and map the result onto the grid the same way:

function nextFood() {
  let candidate;
  do {
    rng = nextRand(rng);
    candidate = [rng % cols, Math.floor(rng / cols) % rows];
  } while (occupied(candidate));
  return candidate;
}

Same seed, same sequence, same food. The server can sit down and play your exact game from your exact inputs.

What submit-score actually checks

Replay is the heart of it, but on its own it isn't enough. The submission endpoint is layered, and each layer closes off a specific attack. Here's what a score submission goes through.

Rate limits, including one-time IDs. There's a burst limit and a daily limit per user, but the important two are the single-use ones: the clientRunId and the server-issued run ID are each capped at exactly one submission per day. That's what makes a replay attack pointless — resending a captured winning request just gets rejected as a duplicate.

await enforceRateLimit({
  action: "submit-score:server-run",
  key: `${user.id}:${body.serverRunId}`,
  limit: 1,
  windowSeconds: 24 * 60 * 60,
});

Run state and expiry. The run has to actually exist, belong to this user, match this mission and game, still be in the issued state (not already submitted — otherwise it's a 409 already submitted), and not be past its 15-minute expiry. A stale or reused run never reaches the scoring logic.

Transcript hash. The server recomputes a SHA-256 over the submitted transcript and compares it to the hash the client sent. A mismatch doesn't necessarily mean malice, but it gets recorded as a risk flag — and risk flags matter, because:

The replay decides everything. The server feeds the seed and the player's inputs into its own copy of the game and produces the authoritative score, duration, and completion. A mission only counts as completed when the replay succeeds and there are zero risk flags. Anything flagged — hash mismatch, rules version mismatch, a replay that doesn't add up — doesn't get auto-rewarded; it gets held for review.

Play Integrity, bound to the payload. On Android, the app fetches a Play Integrity token right before submitting and binds it to a hash of the exact score payload. The server decodes that token using Google's API (server-side — on-device checks are bypassable), confirms the binary is a recognized Play build on a device that meets integrity, and stores the verdict. Crucially, this is treated as one risk signal among many, not as proof of a legitimate score. Integrity tells you the app and device look real. It cannot tell you the player earned the points.

The part that was harder than I expected: Block Drop

Most of the games were straightforward to make replay-safe. Block Drop, my Tetris-style game, was not. It has the biggest state space of anything in the app — a full board, a bag of upcoming pieces, plus moves, rotations, holds, and hard-drops — and all of it has to reproduce identically on the server. So it became the game that ate most of my time, and it broke in two separate phases.

The first round of problems was the gameplay itself. Before I could even think about validation, Block Drop had UI glitches I had to chase down — pieces and board state not behaving the way they should on the device. That's the unglamorous reality of this kind of game: you can't validate a game that isn't yet behaving correctly, because you don't have a stable "correct" to compare against. So step one was just getting the game to play right.

Then I fixed the UI, and a second class of problems showed up — the server-side validation ones. With the game finally behaving on the phone, the server replay still didn't line up with what had happened on the device. And this is the trap with a game this complex: it's not enough for the game to look right on screen. The server has to land on the exact same board state the player saw, from the same seed, after the same sequence of inputs. Any tiny divergence between how the Dart client and the TypeScript server handle a piece compounds, and by the end of a run the two sides disagree about the score entirely.

The fix that mattered was a design decision: don't trust the client's summary of what happened, replay the board itself. An earlier instinct is to let the client report higher-level events — "I cleared these lines" — and have the server tally those up. But the server can't actually verify a reported line-clear; it just has to take the client's word for it, which defeats the whole point. So Block Drop's replay is board-state based. The server regenerates the deterministic piece bag from the seed, applies the player's recorded controls one tick at a time, and works out the line clears itself from the resulting board:

function lockPiece() {
  // place the current piece into the board grid
  // then clear completed lines based on the actual board,
  // not on anything the client reported
  clearLines();
  spawn();
}

If you take one thing from this section: the hardest part of server-authoritative validation isn't the security idea, it's the determinism. Making the same logic produce identical results in two languages, across two runtimes, every time — that's the real work. Block Drop is also the game I'd tell anyone to test most aggressively, precisely because its state space is large enough to hide a desync you won't notice until a real player's score quietly fails to validate.

What I'd tell anyone building a game that pays out

If you're putting real value behind a score, here's the short version of everything above:

Never let the client be the source of truth for anything that earns money. It reports inputs. The server decides outcomes.
Make your gameplay deterministic from a server-issued seed, so the backend can independently reproduce and score the run.
Issue one-time run IDs and reject duplicates. This is what neutralizes replay attacks, and it's cheap to build.
Treat Play Integrity / attestation as a signal, not a verdict. It catches tampered binaries and sketchy devices. It does not prove a score is real.
Don't auto-pay flagged runs. Server-authoritative scoring plus conservative eligibility plus manual review on high-value events is what keeps the economy honest. None of these individually is clever. Stacked together, they move you from "anyone can type their own prize" to "you'd have to defeat a server that already knows what should have happened." For a game where a high score is a withdrawal request, that's the bar.