Solo adventure and co-op survival: how AneeMate keeps the experiences distinct
AneeMate's current development treats a personal adventure and a cooperative survival run as distinct contexts. The reviewed code includes a host-and-join flow for co-op and separate handling for run state and solo progress. That supports a concrete explanation of the work, but it does not establish public co-op availability, offline support or cross-play for every version.
If you are choosing how to play today, start with the current release information and official player guide. If you are following development, this article explains what the 20 October 2026 source snapshot says about the relationship between modes. It is not a launch announcement or a promise that every discussed menu exists in your installed build.
Keeping those expectations clear is part of a good player experience. A familiar island or creature does not mean that a shared session should inherit every rule of a personal save. Nor does the presence of network code prove that the studio has shipped a fully supported online service.
What makes a personal adventure different?
A personal adventure gives the player a continuing relationship with their progress. Returning to a home, checking a party or continuing an earlier task depends on the game understanding what belongs to that player over time. Those expectations remain important when another mode is introduced.
The public building and home guide describes the existing home-related loop. The new cooperative work should be read alongside it, rather than used to silently rewrite it. A temporary shared camp can use familiar themes without being the same stored place.
That distinction is a design choice with practical consequences. If someone tries a run with friends, they should not have to guess whether a new creature or a changed inventory will appear in their personal adventure afterwards. A clear rule is more valuable than leaving the most generous interpretation uncorrected.
A cooperative run has a shared beginning
The reviewed co-op menu includes hosting and joining. Its local-network discovery work can list a host for another participant on the same network, with a direct-address fallback in the implementation. This is a specific development path, not a claim of global public matchmaking.
LAN discovery, a platform invite, an internet session browser and cross-play are different capabilities. A code path for one should not be described as proof of the others. The source also contains an invite interface whose availability depends on the provider, so a final player guide must follow the provider and build that actually ship.
For a supervised test, the useful first check is simple: can the participants identify the same session and understand whether joining succeeded? That question should be answered before promising a frictionless multiplayer experience. We have inspected the flow for this article, but have not completed a packaged network test.
A lobby helps the team arrive together
Beginning a run is not only a connection event. Participants may load at different speeds, look at different menus or be unsure where the group is going. A lobby gives the experience a place to communicate readiness before the shared activity starts.
The source snapshot contains a portal-based waiting rule, visible waiting state and notices around departure. These are concrete mechanisms for coordinating a group. The exact timing and presentation are still development details, so this article does not publish them as fixed rules for every future release.
An illustrative example is a group in which one participant enters the departure area while another is still orienting themselves. A clear waiting message can explain what the group needs next. That is a model of the intended interaction, not a claim that we observed it working in a released session.
Shared run state should not silently become a solo save
The travel code treats returning from a cooperative run as a boundary. The reviewed implementation reloads the solo profile path rather than assuming that whatever happened in the cooperative world should become the player's permanent adventure state.
This distinction protects the meaning of a personal profile at the design level. It does not prove that every disconnect, crash or repeated transition is safe. Those cases require actual test evidence in the build under consideration. The article describes the implementation boundary without claiming complete reliability certification.
It also explains why apparently generous assumptions can be wrong. A creature used within a run is not automatically a permanent addition to the personal collection. A temporary camp piece is not automatically a new structure in the solo home. Transfer rules must be explicitly established, not inferred from familiar visuals.
Rewards have a narrower path than unrestricted transfers
The current reward component uses a separate record for a cooperative run's pending MATE and a later path into the solo profile. That is a more specific relationship than copying the entire session into the personal adventure. The implementation also distinguishes a repeated summary from a new result.
This article does not announce exact MATE amounts, a fixed daily schedule or a final reward balance. It also does not turn MATE into money. For the distinction between the in-game balance and the optional blockchain token, read MATE and QORPO explained.
The useful player expectation is that reward handling should explain what was earned, when it becomes available and what did not transfer. That explanation belongs in the build and its current documentation. Source code is valuable evidence of intent, but a reward screen and the saved result still need to agree in practice.
Leaving and losing connection are part of the mode
A cooperative experience needs to explain what happens when it ends unexpectedly. The reviewed travel code includes notices for a connection to the host being lost and for a participant returning to the menu after the lobby's departure flow. Those notices matter because the same final screen can otherwise conceal very different events.
A friendly explanation should help someone decide what to do next. Was the group still preparing? Did the session end? Is a new run needed? A player should not have to inspect a technical log simply to understand the broad outcome. Technical details can remain available for an authorised bug report without becoming the main user interface.
We are not promising automatic reconnection, host migration or recovery of every session. Those are substantial features with their own requirements. The source reviewed here does not justify announcing them, and an article about co-op should not imply them by omission.
Solo, offline and co-op are not synonyms
“Solo” describes who is playing an experience. “Offline” describes connectivity requirements. “Co-op” describes shared participation. A game can offer a solo activity while still using an account or online service. It can also have multiplayer implementation work that is not yet released to the public.
For that reason, this article does not infer offline support from the presence of a solo profile. It also does not promise that a LAN implementation will work across every home router or through a platform service. Current supported configurations need an explicit source.
The most useful answer to an availability question names the build, mode and supported context. If those details are missing, it is better to keep the answer open than publish a broad yes that sends players into an unavailable flow. That is a documentation standard, not a statement that the product must remain limited to its current implementation.
How to follow this development usefully
Read this mode comparison together with the co-op survival structure and shared-camp explanation. The first explains the rhythm of the run; the second explains supplies and defenders. This page focuses on ownership, joining and expectations between experiences.
The Live builds page shows repository activity. A release note or current build guide must establish what you can use. If you join an authorised test, report the build identifier, number of participants, transition attempted and the visible result. Never publish account credentials or private network information as part of a public report.
Can I play co-op now?
This source review does not establish public availability. Check the latest release information and the installed build. The systems discussed here are described as development work rather than a universally available mode.
Will everything I collect in co-op enter my solo adventure?
Do not assume that. The reviewed implementation separates run state and solo progress, with a specific reward path rather than unrestricted transfer. Final player-facing rules should follow the build that releases.
Does solo mean I can play offline?
Not automatically. Connectivity and account requirements are separate from the number of players. This article does not announce offline, cross-platform or console support.