Daily Netwalk Seeds: Reproducible Boards and Fair Scores
A daily puzzle has a stronger promise than "here is a random board." It promises that players who arrive independently are solving the same challenge. That requires more than putting today's date in a heading. The date must control every random decision that changes the board, the day boundary must be unambiguous, and score claims must distinguish locally stored results from server-verified competition.
Daily Netwalk uses a date string as a seed for a small pseudorandom generator. The seed selects the network topology and the scrambled starting rotations, so loading the same UTC date reproduces the same 7 by 7 challenge. The puzzle still runs entirely in the browser. This guide explains what that design guarantees, what it deliberately does not guarantee, and how players can compare attempts honestly.
1. Random-looking is not the same as unpredictable
A pseudorandom number generator starts from an integer state and repeatedly transforms it into a sequence of values that look irregular. Given the same initial state and algorithm, the sequence is identical. That repeatability is undesirable for passwords but ideal for a shareable puzzle. The generator does not need secret randomness; it needs varied, reproducible choices.
Ordinary play can use the browser's default random source because a new, ephemeral board is the goal. Daily play has a different contract. Every choice that affects the challenge must draw from the seeded sequence: frontier-edge selection, any topology adjustments, initial rotations, locked-tile decisions when the mode uses them, and fallback selections. One stray call to an unseeded random function can make two players receive different starts despite sharing the same date.
2. Turn a readable date into generator state
The Daily challenge begins with a canonical string such as 2026-09-01. A small string hash processes its character codes and produces a 32-bit integer. That integer initializes the seeded generator. Hashing is useful because the human-readable date remains easy to display and debug, while the generator receives a fixed numeric state.
A hash collision is theoretically possible because infinitely many strings map into a finite 32-bit space. For one puzzle per day, this is not a practical fairness problem: even if two distant dates happened to share a state, everyone on each date would still receive the same board. The hash is an identifier-to-state converter, not a cryptographic proof or a security boundary.
3. Define the day with UTC
Local midnight happens at different moments around the world. If each browser uses its local calendar, a player in Shanghai can enter the next challenge many hours before a player in New York. That may be acceptable for a personal streak, but it does not support the claim that one worldwide board changes at one shared moment.
Daily Netwalk therefore derives the year, month, and day from UTC. At 00:00 UTC the date seed changes everywhere. A player may see that transition in the morning, afternoon, or evening depending on location, but the underlying boundary is common. When debugging an unexpected board, record the UTC date rather than only the wall-clock time shown by the device.
4. Feed one random stream through the full pipeline
Reproducibility is easiest when the random source is passed into every function that needs a choice. The board generator should not reach outward to a global random function. It receives a function named, for example, rand, and uses it to select the next frontier edge. The scrambling stage uses that same function for rotation offsets. Mode-specific cleanup also uses it when several legal changes are available.
The order of calls matters. Adding a new random choice near the start shifts every later value in the sequence, producing a different board for the same date. That is not inherently wrong, but it means a deployment can change today's puzzle. A mature daily system can version the generator and include the version in the seed, preserving archived challenges while allowing future algorithms to improve.
5. What counts as the same board?
Two players have the same challenge only if the solved topology, server position, tile modes, locked states, and starting rotations match. Sharing only the solved network is insufficient: one scramble might place many tiles one click from correct while another requires three clockwise clicks, changing both move count and visual deductions.
Canvas size, colors, and device pixel ratio do not change the logical board. A phone and a desktop can render the same masks at different physical sizes. Input method also does not change the state transition: a valid tile action rotates one quarter-turn. These separations let the logical board be compared independently of presentation.
6. Reproducible does not automatically mean equally easy
A seeded generator guarantees agreement, not calibrated difficulty. One day's tree may expose many forced corner chains; another may contain ambiguous interior junctions. Both can be 7 by 7 and require very different reasoning. That natural variation is part of a daily puzzle, but it complicates comparisons across dates.
Fair statements compare players on the same date and mode. "I used 42 moves today" can be compared with a friend's attempt at the same daily board. It should not be treated as proof that 42 moves on Monday was better than 48 on Tuesday without considering board structure. Long-term statistics can normalize against a known minimum or a distribution of attempts, but the current local game does not claim that level of analysis.
7. Separate move efficiency from solve speed
Move count and elapsed time measure different skills. A low move count rewards planning before clicking and avoiding unnecessary full rotations. A low time rewards rapid recognition and input. A player can optimize one at the expense of the other. Someone who studies the board for a minute before the first move may finish with excellent move efficiency but a slower clock.
For a friendly comparison, share both values and the mode. Also mention whether undo or reset was used if that matters to your group. The browser's interface records its normal counters, but there is no reason to turn a casual puzzle into an opaque rule dispute. Agreeing on the comparison before playing is more meaningful than inventing strict rules afterward.
8. Understand local personal bests
The game stores daily best information in the browser's local storage. This keeps the experience fast and private: no account, email address, or remote leaderboard is needed. It also means the record belongs to that browser profile. Clearing site data, using private browsing, switching devices, or using another browser can remove or separate the result.
Local storage is convenient memory, not tamper-proof certification. A technically knowledgeable user can edit local values, change the clock, or modify client-side code. Therefore a shared score is a social claim, similar to telling a friend your time on a printed puzzle. The site does not present local results as an independently verified global ranking.
9. What a verified leaderboard would require
A competitive leaderboard would need a different architecture. A server would issue a challenge identifier, know the generator version, validate submitted move sequences, rate-limit attempts, and decide how to handle pauses or network interruptions. It might sign challenge data so clients cannot substitute an easier board. Privacy and abuse controls would become part of the product.
Even then, perfect anti-cheat protection in an open browser is unrealistic. A player can inspect client logic or write a solver. A sensible system would define the level of trust it offers, separate casual and verified categories, and avoid collecting more personal data than necessary. Netwalk's current account-free design intentionally favors immediate play over formal competition.
10. Test determinism directly
The core regression test is simple: generate a board twice from the same date and compare every logical field. The solution masks, rotations, locks, server coordinates, size, and mode must match. Then generate a range of different dates and confirm that the set contains meaningful variation. A test should also replace the default random function with one that throws, proving that seeded execution never falls back to an unseeded source.
Timezone tests should run the same instant under several local timezone settings and demand the same UTC seed. Boundary tests should cover the instant before and after 00:00 UTC. Generator-version tests should preserve a few known date fixtures, so an accidental algorithm change is visible during development rather than discovered by players.
11. Use seeds as a debugging tool
Reproducibility helps quality as much as sharing. If a player reports an impossible-looking daily board, the date identifies the input needed to rebuild it. A developer can inspect the exact topology, run reciprocity and reachability checks, and preserve the seed as a regression case. "It happened once on a random board" becomes a concrete test.
The same technique works outside daily mode. A future share feature could encode generator version, mode, size, and seed in a compact puzzle identifier. The identifier should describe the board, not include private player information. Anyone could reconstruct the challenge while personal times and move histories remain local unless deliberately shared.
12. A fair Daily checklist for players
- Open the Daily Netwalk page and confirm the displayed date.
- Use the same mode when comparing with another player.
- Compare attempts from the same UTC date, not merely the same local evening.
- Share moves and time because they measure different tradeoffs.
- Treat browser-stored personal bests as convenient personal records.
- Do not describe a local score as server-verified or globally ranked.
- If a board appears wrong, report its UTC date, mode, and browser.
A trustworthy daily puzzle is built from explicit boundaries. Deterministic generation makes the challenge reproducible. UTC makes the date shared. Clear score language prevents a friendly local record from masquerading as certified competition. Together, those choices create a daily ritual that is simple without being vague. For the generation stage beneath the seed, read how Netwalk builds a solvable board; for practical play, use the constraint walkthrough.