How to plan a shared base with friends

Agree on what must work before discussing the finished design

Start with the job the shared space needs to do: hold storage, support a production step, house the team or make a particular activity easier. Separate the essential footprint from decoration and later expansion. A beautiful complete plan can be difficult to start when nobody knows which part matters first.

Check the actual plot, unlocked structures and server rules together. Different assumptions about available space or resource multipliers can invalidate a material list before anyone leaves the base. Name who can approve a change to the shared layout, especially if it affects work someone else already completed.

Keep one layout as the current version

Use a planner to draft the footprint before spending materials in game. Give the current revision a recognisable name and date, and put it somewhere the group already checks. A screenshot is often enough for people who only need to understand the arrangement; they do not all need editing access.

When the plan changes, say what changed and which old instructions no longer apply. Keeping several drafts without naming the current one creates unnecessary gathering and rebuilding. A shared link can make communication easier, but check whether it shows a saved version or a changing workspace before relying on it.

Assign missing inputs, not vague jobs

Turn the plan into a few entries with an item, quantity, owner and status. Distinguish material still needed from material someone is already gathering and material delivered. Otherwise two players can each see the same shortage and spend the evening solving it twice.

Check intermediate ingredients before dividing the work. A component may already include materials counted elsewhere in the recipe. Pick one working bill of materials and resolve those overlaps once. Leave an explicit unassigned entry when nobody wants a job instead of assuming someone will eventually do it.

Make a reversible first change

Build a small usable section before committing the entire layout. Walk through it, check movement and access, and ask the people using it whether it solves the original problem. A staged approach catches a poor arrangement before the group spends all its materials reproducing it.

Keep normal backups when you control the world and know how to restore them. Treat save editing, importing and server configuration as separate operations with their own risks. A layout planner does not authorise changing a shared world, and a group member's enthusiasm does not replace the host's agreement.

End with a hand-off someone else can use

Before leaving, record what is built, where reserved materials are stored and which input remains the bottleneck. Link the current plan rather than posting another unexplained draft. Someone returning tomorrow should be able to help without asking the whole group to reconstruct the project.

If priorities change, close the old project deliberately and release its reserved stock. The point of a shared plan is to make playing together easier, not to create a second job. Keep only the detail that prevents confusion or repeated work.

• We agreed on the first usable result.
• There is one current plan.
• Each missing input is assigned or explicitly unassigned.
• The next player can see what changed and what remains.