围绕复杂模拟设计每日浏览器游戏

A player opens a turn-based game and faces two different problems: understanding the rules and deciding what to do first. A detailed simulator can solve the first problem faithfully while leaving the second entirely to the player.

This article examines a different starting point: constrain the preparation, preserve the decisions inside the game, and make interruption and experimentation understandable. The useful design question is how to reduce the effort of starting without removing the reasons to think.

The evidence comes from a local TypeScript implementation and controlled tests using @pkmn/sim 0.10.11. This is a source-based design analysis, not a retrospective backed by user interviews or retention data. The implementation demonstrates mechanisms; whether those mechanisms help new players remains a hypothesis to test.

Make the first decision smaller than the ruleset

Building a team can be strategically interesting. It also asks a newcomer to make many interdependent decisions before seeing any consequences. A daily format can move some preparation into the application: provide a six-member roster and let the player choose the starting member.

That does not make the simulation shallow. Moves, switching, items, abilities, and status effects still matter. It moves the initial question from “What should I build?” to “What can I do with this?”

The local implementation associated with daily red pokemon supplies a concrete example: game/lobby.ts generates the roster, while game/TeamPreview.tsx exposes its details and the lead selection. These are observations about the inspected source, rather than a verification of the deployed website.

The preview divides information into moves and stats/ability tabs. Selecting a member exposes its details; in a fresh session, that selection also chooses the lead. This is a useful form of progressive disclosure: the player can inspect the available decisions without reading every numerical property simultaneously.

Combining inspection and commitment has a cost, however. Someone may inspect a member without intending to start with it. The interface therefore needs a visible lead marker and clear wording. During resume, the implementation instead labels selection as inspection and marks the original lead. The same visual component has different semantics because the underlying session already exists.

The proposed first-session loop is deliberately narrow: inspect the roster, choose a lead, make a move, and read the consequence. That is a design target, not a measured onboarding result. A useful usability study would check whether players can explain why their first action produced its outcome, rather than merely whether they reached the battle screen.

A daily challenge needs more than a date-derived seed

Daily seeding is already covered on Zenn, for example in this browser-only daily challenge implementation. The additional question here is what should remain stable when the player changes views, retries, or crosses midnight.

The inspected generator hashes a namespace, date key, and data version, then performs a seeded shuffle of the player pool and selects six members. Repeatability depends on the same date, version, pool contents, and ordering. A seed alone does not freeze the rules or data.

The date key uses the device's local calendar date. This makes rollover correspond to local midnight, but it does not create one simultaneous global challenge boundary. Two people in different time zones can legitimately see different date keys at the same instant. A globally synchronized competition would need a different time policy.

More subtly, the lobby prioritizes an unfinished non-practice session even when its date is yesterday. That separates two meanings of “today”: the challenge currently available and the challenge the player already started.

There is a real tradeoff in preserving yesterday's session: it takes priority over starting today's challenge. That policy deserves explicit interface wording. Continuity is valuable only if the player understands which challenge they are continuing.

This is repeatable local play, not authoritative competition. The client controls its date and storage, and no server adjudication is established by these mechanisms. A seed is useful for reconstructing an experience; it is not evidence that a submitted result is trustworthy.

Separate the recorded attempt from the learning loop

A daily result and an invitation to experiment serve different needs. If every retry replaces the recorded result, the meaning of completion becomes ambiguous. If retries are prohibited altogether, players lose an immediate opportunity to apply what they learned.

The implementation resolves that tension by making a completed challenge's replay a practice session. freshJournal retains the roster, accepts a selected lead, clears actions and outcome, and marks the new configuration with practiceKind: "daily-replay". The result-recording path excludes practice.

Notice what is reset: the attempt, not the challenge. Keeping the team makes the next attempt interpretable. A different lead or move can be compared against a familiar starting situation. Generating a completely new roster would answer a different question.

Practice generation also has an explicit run identifier. Re-entering its view does not advance that identifier. This seemingly small detail prevents a navigation action from changing the object the player was reasoning about.

Two alternatives are reasonable. Unrestricted fresh random games prioritize variety but weaken direct comparison. A strict one-attempt format makes the daily result simple but limits rehearsal. Separating the recorded attempt from practice retains a stable reference point at the cost of more states and more careful labels. These are design tradeoffs inferred from the implementation, not a claim that alternatives were evaluated with users.

Let the product contract define the state boundary

“Resume my game” is a product promise with technical consequences. The durable representation needs to describe the session independently of whatever React component happens to be mounted.

Here, a journal stores a configuration and player actions: move, switch, or forfeit. A Worker owns the live BattleSession. On initialization, it creates a session from the configuration and applies the saved actions in order.

This gives a compact conceptual boundary:

saved configuration + ordered actions
                  ↓
         Worker-owned simulator
                  ↓
       state updates → presentation

The existing Worker client uses request identifiers, pending promises, and a 45-second timeout. Those details support an asynchronous interface; they do not establish a speed improvement. A timeout also does not, by itself, cancel computation. No browser latency benchmark was run for this article.

Reconstruction through actions avoids persisting a live graph of engine instances. Its cost is dependence on compatible engine behavior, data, AI decisions, and random-number consumption. Longer action lists also require more replay work, although this article does not measure that cost.

Saving complete engine snapshots could reduce replay work, but couples persistence to the engine's serialization format. A server-authoritative session could offer shared authority, but introduces infrastructure and a different failure model. For a local single-player experience, configuration plus actions is a useful boundary when compatibility is treated explicitly.

The source validates journal structure and configuration version, and the load path checks tracked engine versions. Rejection is not migration. A version number only protects a boundary if changes to replay-relevant behavior are reflected in the compatibility policy. It does not preserve an old engine automatically.

The companion test exercises the same reconstruction idea with one legal move. This is an excerpt from runnable TypeScript, inside a test that creates and destroys both sessions:

    const move = original.snapshot().moves.find(m => !m.disabled)!;
    assert.ok(move, "scenario must offer a legal move");
    const actions: Action[] = [{ kind: "move", slot: move.slot }];
    for (const action of actions) original.act(action);
    for (const action of actions) restored.act(action);
    assert.ok(original.snapshot().turn > 1);
    assert.deepEqual(restored.snapshot(), original.snapshot());
    assert.equal(restored.battle.prng.getSeed(), original.battle.prng.getSeed());
    assert.deepEqual(restored.history, original.history);

This checks more than an unchanged initial screen: both sessions actually advance. It still demonstrates only one same-version action sequence, not every battle or historical save.

A preview must not change the thing being previewed

The state boundary also matters inside the simulator. The AI evaluates possibilities using a cloned battle. Conceptually, those calculations should not change the real battle's random state or history.

A controlled experiment exposed a narrower failure than “the clone is broken.” The current adapter calls Battle.fromJSON(battle.toJSON()). In the installed dependency, serialization assigns state.log = battle.log, and deserialization assigns battle.log = state.log. New battle objects can therefore retain the original log array.

In a fixed two-participant scenario, advancing the clone left the original turn and random state unchanged but appended 11 lines to its log. Successful reconstruction of behavior did not establish ownership isolation.

An experimental text boundary, Battle.fromJSON(JSON.stringify(original.toJSON())), detached the log and left the original serialized state unchanged after the same simulated turn. The test first initializes the existing adapter's constructor-name compatibility setup; the text conversion is not presented as a complete replacement adapter.

This alternative is confined to the example. The application source was not patched, and no production incident or player-visible effect is asserted. The engineering lesson is broader than this library: a promise such as “inspection changes nothing” needs mutation tests, not just a check that a preview returns plausible output.

Verify the promises before polishing the surface

The companion files include five controlled checks and use the repository's existing lobby regression suite. Run from the repository root with its dependencies installed:

node docs/daily-red/zenn/ideas/verify.cjs

The following observations are generated from the controlled checks, rather than estimated:

The lobby suite additionally checks fresh battle resources, selected leads, explicit practice regeneration, and completed-result handling. TypeScript checks cover the example and the scoped game sources. These are local checks; they do not exercise browser storage failures, Worker scheduling, cross-tab races, deployment, or human comprehension.

For someone building a similar application, a useful construction sequence is to implement one valid session first, then make its identity explicit, then add reconstruction, and only then add alternate modes and presentation. This is a recommendation based on the dependencies between those contracts, not a reconstruction of this project's development history.

The next product investigation should concentrate on the remaining uncertainty: can a newcomer identify the lead, distinguish resume from replay, and explain the first turn? Observing those tasks would test the proposed reduction in starting effort. Neither deterministic seeds nor passing tests answer that usability question.

A small daily game still contains substantial complexity. The design opportunity is to decide which complexity the player should confront now, which should remain available on inspection, and which the implementation must absorb. Stable session identity and honest recovery semantics give that decision a concrete engineering foundation.