AneeMate Co-op starter choice: a development test plan
A Co-op starter choice needs more than a selection screen. Both players must reach it at the right time, confirm independently and receive the intended result in the shared session. AneeMate's 30 October development notes describe work on that flow and a host-and-client verification plan. They do not establish a public release.
The notes were inspected on 31 October 2026 and explicitly identify outstanding compilation and gameplay verification. This article explains the intended interaction and the checks needed to evaluate it. It does not announce starter availability in your installed build, a launch date, new rewards or a particular starting inventory.
Why the timing of a choice matters
A selection screen asks for attention and input. If it appears while an introduction or loading presentation still owns that input, the player may not understand whether the game is waiting or stuck. The development plan therefore treats the handoff into selection as part of the feature, not as decoration around a finished menu.
For a player, the important result is a clear opportunity to choose. For a tester, the corresponding question is more precise: when the preceding presentation finishes, can this player make and confirm the intended selection? Record each player's experience separately rather than assuming the host's successful choice represents the whole session.
Host and client are two observations
A shared session contains more than one view. One player can reach a screen while the other is still in a transition. A useful verification plan checks both roles and confirms the resulting state for each. The development notes call for that distinction; this article does not claim those checks have passed.
The Co-op development overview explains the broader mode context. The starter-choice work is narrower. It concerns the beginning of a run and the handoff from a player's decision to the shared session, not the entire Survival loop or every way a friend might connect.
Model example: different choices, same clear handoff
Imagine a fictional prototype test with two players. Each reaches the selection screen, chooses a different available option and confirms. The reviewer records whether each player returns to the expected session state and can identify the result of their own choice. No specific creature is promised by this example.
This makes the test more informative than both players repeatedly choosing the same option. Distinct choices help the reviewer see whether the two decisions remain separate. The comparison should still use the same build and documented starting state, so an unrelated change does not become part of the explanation.
If a choice appears confirmed but the result is unclear, report both moments. A recording of the selected option and the following state is more useful than a final image alone. Do not infer a successful grant or a missing creature solely from a menu closing; inspect the result the test plan actually asks you to confirm.
Keep run state separate from a long-term collection
The development note discusses a Co-op run flow. That should not be expanded into an account-wide collection claim. A result inside one mode does not automatically establish persistence elsewhere, a change to ownership or synchronisation with the website.
For the separate web feature, the Matebook checklist explanation describes local browser marks. For team composition, the party-planning article discusses choosing around an objective. These are related concepts, but none should be used as proof that a new starter-selection flow is already available or connected to every other system.
What the test record should contain
Use one record for the session and a short observation for each player. Include build, role, starting state, the point when input became available, the selection and the visible result. Mark a failed transition separately from a disputed option or a confusing presentation. Those are different findings with potentially different owners.
If a transition must be repeated, use a documented reset procedure in the test environment. Do not assume leaving and rejoining behaves like a clean first start. This article does not prescribe a reconnect exploit or promise that state survives a reconnect. Those conditions need their own explicit verification before they become player guidance.
Questions about the starter-choice work
Can I expect this screen in the public build today?
This article does not establish that. The source reviewed is a development plan with verification still outstanding. Use current official release information for availability rather than a repository message alone.
Which starter should a player choose?
This is not a starter ranking. The current purpose is to explain the selection flow and its verification. It does not provide an unsupported list of starting options or claim one is best.
Is Co-op the same as the solo adventure?
They are distinct contexts. The mode-differences article explains why a feature in one context should not automatically be assumed in another. Offline availability is a separate question again.
Where can I follow the actual game?
Start with AneeMate gameplay for the official overview and the AneeMate journal for focused explanations. Development notes can show what the team is working to verify. A public release claim needs the additional evidence that the relevant build has actually shipped.