Randomise run_seed on startup instead of defaulting to 123 #4

Merged

liamjd merged 2 commits from 1-run-seed-default into main

2026-08-15 12:01:53 +01:00

liamjd commented

2026-08-15 12:00:49 +01:00

Owner

GameState.run_seed defaulted to a fixed 123. Nothing wrote to it, so any code reading it would have generated an identical world every run while looking entirely correct — stable across launches, reproducible, plausible. A seed path that was never plumbed through would have been indistinguishable from one that worked, and the eventual debugging would have started in the terrain generator rather than here.

_ready() now randomises it, so an unset seed is honestly random: a broken seed path shows up as a map that changes when it shouldn't, which is a failure you notice.

Zero is no longer a sentinel — the autoload's _ready() runs before the main scene loads, so the field is never observably 0. The comment says so, to stop anyone writing a dead if run_seed == 0 guard.

Verification

Three launches, reading the autoload on frame 3 (reading it in _initialize() returns 0 — the tree has not run yet, which looks exactly like the randomisation failing):

run_seed=379470484
run_seed=2354805068
run_seed=3343245267

Note

The print() in _on_new_game_pressed() is temporary scaffolding confirming the value reaches GameState. It is replaced when the seed input is wired up in #2.

Closes #1

`GameState.run_seed` defaulted to a fixed `123`. Nothing wrote to it, so any code reading it would have generated an identical world every run while looking entirely correct — stable across launches, reproducible, plausible. A seed path that was never plumbed through would have been indistinguishable from one that worked, and the eventual debugging would have started in the terrain generator rather than here. `_ready()` now randomises it, so an unset seed is honestly random: a broken seed path shows up as a map that changes when it shouldn't, which is a failure you notice. Zero is no longer a sentinel — the autoload's `_ready()` runs before the main scene loads, so the field is never observably `0`. The comment says so, to stop anyone writing a dead `if run_seed == 0` guard. ## Verification Three launches, reading the autoload on frame 3 (reading it in `_initialize()` returns `0` — the tree has not run yet, which looks exactly like the randomisation failing): ``` run_seed=379470484 run_seed=2354805068 run_seed=3343245267 ``` ## Note The `print()` in `_on_new_game_pressed()` is temporary scaffolding confirming the value reaches `GameState`. It is replaced when the seed input is wired up in #2. Closes #1

liamjd added 2 commits

2026-08-15 12:00:49 +01:00

Update CLAUDE.md before starting the first branch fc8c760997

Randomise run_seed on startup instead of defaulting to 123 2c110493da

A fixed default made an unset seed indistinguishable from a valid one:
world generation would look correct and reproducible while never actually
reading the player's seed. Randomising in _ready() makes an unset seed
honestly random, so a broken seed path shows up as a changing map rather
than a convincingly stable one.

Verified across three launches: 379470484, 2354805068, 3343245267.

The menu print is temporary scaffolding to confirm the value reaches
GameState; it is replaced when the seed input is wired up (#2).

Closes #1

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

liamjd merged commit 4affa0a229 into main

2026-08-15 12:01:53 +01:00

liamjd referenced this pull request from a commit

2026-08-15 12:01:55 +01:00

Randomise run_seed on startup instead of defaulting to 123 (#4)