A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent.
This is a technical development note, not a claim that a game score predicts an athlete’s real performance.
Store the decisions, not just the result
The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build.
A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves.
Test invariants across many runs
The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that:
- Eight distinct players were selected.
- All eight traits are present, and no player remains to be drawn after completion.
- The overall game score stays between 0 and 99 and matches the shared rating function.
- Packing and unpacking the share state returns the original state.
- Recomputing the fictional career returns the same output.
- The ten simulated seasons sum to the displayed career earnings.
Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up.
Reject impossible histories
A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected.
The tests also cover malformed encoded payloads and unexpected fields. Local state is useful for a casual game, but it is not an anti-cheat system. A competitive leaderboard would need a separate trust model.
Make daily challenges explicit
Daily challenges use a validated UTC date to derive the seed. The tests reject impossible dates and check that changing the date without the matching seed invalidates the state. This avoids treating a player’s local midnight as a universal boundary.
What these tests do not establish
Determinism proves repeatability, not realism. The career is an entertainment simulation, not a forecast. Unit tests also do not replace mobile interaction testing, data-quality review or permission checks for third-party assets.
Project reference: HoopTrait.
For developers working on small games: what would you version first when introducing a new scoring model—the replay format, the dataset, or both?
Drafted with AI assistance and checked against the project’s Lab test source.