AneeMate shared-camp building: supplies, defenders and a reason to return
AneeMate's shared-camp development connects building resources, food and creature defenders around one place the team uses together. The current source separates what feeds the camp from what pays for construction, and tracks the creatures guarding it. This is a development explanation checked on 20 October 2026, not a claim that the full system is released in your current build.
The appeal of a shared camp is easy to describe: the things a group brings back should change what the group can do next. Making that work requires clear destinations, understandable costs and feedback that explains a creature's role. Otherwise, collecting can feel disconnected from building and defending.
For the broader session structure, read the co-op survival development overview. If you are looking for the personal home loop described on the current website, use the existing building and farming guide and official gameplay documentation. The two contexts should not be treated as interchangeable.
Start with a shared place, not a shared mystery
A camp needs a recognisable centre and a clear reason to return. It can hold structures and supplies, but its most important function is to make the group's situation understandable. A player arriving with materials should not have to ask which invisible system owns them or whether another person's construction can use them.
The reviewed camp component tracks a centre, a radius, a level and supplies. Those values describe the shared run camp as a system rather than a collection of unrelated decorative objects. The interface and environment still need to communicate that boundary to players in the actual build.
That is also why an early concept render is not a construction catalogue. The illustration above expresses the theme of gathering and returning. It does not establish that each visible structure is an available recipe or that every depicted prop can be placed by a player.
Food and building materials solve different problems
The implementation separates a food pile from a resource pile. Food supports the camp's creatures; building materials support construction and camp progression. This gives a player a more specific question than simply whether the group has enough of a universal currency.
Suppose an illustrative group returns with plenty of timber but little food. That group may be able to consider construction while still having a different need around its defenders. The separation makes gathering choices easier to discuss. This example explains the relationship; it does not report a measured balance problem or prescribe an optimal released strategy.
A good interface should make the distinction visible before someone deposits an item. It should also explain what changed after the contribution. The code includes separate counts and player notes, but inspecting those pathways does not prove that every prompt, localisation and input binding has been validated on the target build.
Depositing should feel like completing a useful task
In the reviewed source, an interaction at a pile moves the corresponding carried food or building materials to the camp. That connects a bag of gathered items to a shared use. The player-facing question is whether someone can understand the move without fearing that their items simply disappeared.
Feedback needs to answer both what moved and where it went. A contribution can be technically correct and still create uncertainty if the camp display updates elsewhere or the player receives no explanation. A message about having nothing relevant to deposit can also be more helpful than a button that appears to do nothing.
For an authorised test, describe the situation precisely: the build, what you carried, the pile you approached, the input used and the result shown. Do not send account secrets or private personal details in a public report. A reproducible interaction is more useful than a broad assertion that deposits are broken.
Building draws from the shared resource context
The current camp interface includes a check for the required construction materials and a path to pay the full cost from the resource pile. This is a different ownership model from assuming that every piece is paid only from the builder's personal bag.
That difference creates a coordination question. A team may want to agree on a useful next structure rather than spend the same shared stock on competing plans. It does not require a permanent leader role, a final permission system or a player trading market. Those are separate features and are not established by the code reviewed here.
The implementation aims to check a whole cost rather than treat an incomplete payment as a successful construction. Whether the full building flow behaves correctly still needs testing across the relevant session conditions. This article does not claim that we ran a multi-client construction test or established an exploit-free economy.
Camp level and guard capacity are connected
The camp's resource contribution and level are linked to the capacity for creature guards in the source snapshot. That gives improvement a potential purpose beyond changing the appearance of the settlement. A stronger camp context can alter what the group is able to support.
Exact costs, capacity values and progression speed are not final promises in this article. They belong to the build under test and can change. Publishing an internal default as a permanent strategy would create confusion when a balance pass changes the relationship.
The durable player question is what an upgrade unlocks and whether that benefit is visible. A level number alone is less helpful than a clear explanation of the new capacity or option. That is a proposed usability criterion, not a report of completed player research.
Caught creatures can become camp defenders
The reviewed implementation can route a caught creature into an available guard slot, with another path when the camp is full. This makes the camp relevant to catching decisions during a run. It also means that a player needs feedback about the creature's destination.
Without that explanation, a useful event could feel like a missing catch. The source contains notes for a creature joining the camp and for a full camp sending it to the run party. Those notes express the intended distinction. The actual presentation should still be checked in the build players use.
Guard behaviour is more than standing at a marker. The component includes feeding, strength, fighting and recovery relationships. These are development systems. They are not a guarantee that a particular species is the best defender or that the final guard balance has been settled.
Feeding gives the return journey another purpose
A food stock connects gathering to the state of camp creatures. The source describes guards moving to food, eating and receiving run-specific progression. It also distinguishes a guard resting from one that is actively contributing. This creates feedback a team can potentially read as part of its preparation.
An original model scenario is a group choosing between another distant trip and a short return with supplies before pressure rises. The decision becomes meaningful if the camp's needs are understandable and the consequences are fair. The code relationship makes that scenario plausible; only a real test can establish whether the pacing actually supports it.
Do not assume these run-specific systems rewrite your permanent collection or personal home. The camp component explicitly belongs to the cooperative run context. The solo and co-op comparison explains why the distinction matters for expectations about saves and progression.
What should testers and readers look for?
Look for a coherent journey: gather something relevant, return to a readable camp, understand the contribution and see how it affects the next decision. Test the ordinary path before debating elaborate endgame strategies. A loop that is difficult to explain in its first minutes is unlikely to be improved by a longer recipe list alone.
For a report, separate what you expected from what happened. A camp design question, a missing visual cue and an incorrect resource total require different investigation. Our testing feedback article explains how to make an observation useful without inventing a diagnosis of the underlying bug.
Can I use this as a guide for the currently released build?
Treat it as a dated development explanation. Check your build notes and the current official guide for available controls and recipes. No public release of this complete co-op camp system is announced here.
Does a co-op camp replace my personal home?
The implementation discussed here belongs to a shared run. A personal home and a temporary session have different persistence needs. Do not assume that their buildings or inventories are merged.
Where can I follow changes?
Use AneeMate Live builds to follow recorded work, then read the applicable release information for availability. The source basis of this article is the shared camp component and its construction, guard and player-notification interfaces in the 20 October development snapshot.