Define the survival contract before adding systems
A co-op survival crafting prompt needs more than a setting and a list of recipes. Name what each player can do, how supplies enter the shared inventory, which actions consume them, when danger advances, and what ends the run. Then use one short scenario to check that both roles matter to the same outcome.
Reedwatch Camp below is an original paper-designed teaching example. Its two-player, shared-screen setup, turn order, resource amounts, and warmth values are proposed rules for explaining a prompt workflow. No prompt was run, no playable build or session was supplied, and no real multiplayer behavior was tested. Treat the numbers as illustrative inputs, not balance advice.
Start by writing the shared goal in one sentence: gather two materials, combine both roles’ work into one windbreak, and finish it before shared warmth reaches zero. That sentence gives the prompt a result a reader can recognize and gives each later rule a reason to exist.
| Contract field | Reedwatch rule | What the player should see |
|---|---|---|
| Players and order | Two local, shared-screen roles each choose one action per round. Resolve Player A, then Player B. | Whose action is active and when the round ends. |
| Distinct roles | Timberhand gathers Timber or sets posts. Reedworker gathers Reeds or weaves the screen. | Role, tool, legal actions, and distinct work areas. |
| Shared goal | Install one windbreak using 2 Timber and 2 Reeds while warmth remains above zero. | One team inventory, two build flags, and one shared outcome. |
| Pressure and end | At each round end without a completed windbreak, warmth falls by 1 from its starting value of 3. At 0, the team loses. | The cold check and a clear win or loss state. |
This contract keeps “co-op” observable: each player owns a needed resource and a necessary part of the craft. It also prevents the survival pressure from becoming a decorative timer with no consequence.
Make resource ownership and shared inventory explicit
In Reedwatch, the Timberhand carries a short hatchet and may gather exactly 2 Timber or set the windbreak’s two posts. The Reedworker carries a hand sickle and may gather exactly 2 Reeds or weave and fasten the screen. Neither can perform the other role’s gather or build action. There are no private inventories, extra materials, or hidden travel costs.
Both materials go into one shared satchel that starts empty. Each legal gather action adds its full amount; each build action consumes its own material amount and sets a persistent work flag. The two build actions may happen in either order or in different rounds. The windbreak is installed only when both flags are set. If a player attempts a role-locked action or a build action without its required materials, that action slot is used but the state does not change.
Keep gathering and crafting separate in the prompt. If a role can gather and build in the same action, the round trace cannot show whether the other player’s contribution mattered. A one-action rule makes the tradeoff legible: gather now, build if the shared materials allow it, or wait.
Resolve the cold front in a fixed order
State the timing rule before giving the example: Player A acts, Player B acts, then the cold-front check happens. If the windbreak becomes complete during that round, it blocks that round’s warmth loss. Otherwise, warmth decreases by 1; reaching 0 ends the run before another round begins. The completed shelter does not restore warmth already lost.
The baseline below begins at Round 1 with warmth 3, an empty satchel, and no build progress. Every value follows from the proposed rules; this is a hand calculation rather than an observed run.
| Round | Player A | Player B | End-of-round state |
|---|---|---|---|
| 1 | Gather 2 Timber. | Gather 2 Reeds. | Satchel: 2 Timber, 2 Reeds. Shelter incomplete, so warmth 3 → 2. |
| 2 | Set the posts; spend 2 Timber. | Weave the screen; spend 2 Reeds. | Both flags set before the check. Windbreak installed; warmth stays at 2. Team wins. |
A delayed gather shows how the same contract handles recovery. If the Reedworker waits in Round 1, the team loses one warmth after that round. In Round 2, the Timberhand can set the posts while the Reedworker gathers Reeds; warmth falls again to 1. In Round 3, the Reedworker can weave while the Timberhand waits. The windbreak completes before the check, so the example wins at warmth 1. If the Reedworker waits again instead, warmth reaches 0 at the end of Round 3 and the team loses.
The decision comes from ordering, not from an invented bonus: gather both materials first for the safer baseline, or accept a second cold check after one player delays. If your intended game should allow a larger recovery window, change the starting warmth or the tick rule explicitly, then recalculate every row.
Write a prompt that can be checked
Ask for one small scenario before adding weather types, tools, food, combat, or a production chain. Include inputs, action limits, state updates, failure behavior, and the expected output. This paste-ready prompt describes only the Reedwatch paper design; it has not been run in SEELE or any other game maker.
Design one small two-player, shared-screen, turn-based co-op survival crafting scenario called Reedwatch Camp. This is a design specification, not a request to claim an existing build. Each round, Player A acts first and Player B acts second; then resolve one cold-front check.
Shared state at reset: warmth 3; 0 Timber; 0 Reeds; no posts; no screen; Round 1; Player A acts first. The team wins when the windbreak is installed while warmth is at least 1. If warmth reaches 0 at a round-end check before the windbreak is complete, the team loses. Restart restores the full reset state.
Player A is the Timberhand. A may choose exactly one action each round: Gather Timber adds exactly 2 Timber to the shared satchel, or Set Posts spends exactly 2 Timber and sets the Posts Ready flag. A cannot gather Reeds or weave the screen.
Player B is the Reedworker. B may choose exactly one action each round: Gather Reeds adds exactly 2 Reeds to the shared satchel, or Weave Screen spends exactly 2 Reeds and sets the Screen Secured flag. B cannot gather Timber or set the posts. The two build actions may occur in either order or different rounds. Install the windbreak as soon as both flags are set.
Wait is legal for either role. An unavailable or role-locked action uses that player's action slot but changes no resource or build state. After both actions, if the windbreak is still incomplete, reduce warmth by exactly 1. If it has been installed this round, skip that round's cold-front reduction. Do not restore previously lost warmth.
Show the current round, active role, each chosen action, shared Timber and Reed counts, both build flags, warmth, the end-of-round check, and the win/loss result. Keep the playspace compact: one log patch, one reed bed, and one central campsite. Do not add private inventory, extra recipes, health, food, combat, durability, crafting queues, production buildings, movement costs, online networking, or other survival systems.
Return a role/action table, a round-by-round trace for the baseline and one delayed-Reeds case, and a short checklist for reset, invalid actions, cold-front timing, and both terminal states. If any requested rule is ambiguous or cannot be represented, identify it instead of silently changing it.Check that the output preserves the order of operations. In particular, the second player’s action must be able to complete the shelter before that round’s cold check; otherwise the stated Round 2 win cannot occur. If a result changes that timing, correct the prompt or the rule table before expanding the scenario.
Use fixed cases to check both roles
Before judging whether the scenario feels tense, verify that each written action produces the intended state. Use the same reset state for each case, change one action at a time, and compare the expected result with any actual result only after a build exists. The table below is a proposed acceptance plan, not a report of testing.
| Case | Action sequence | Expected state from the written rules |
|---|---|---|
| Baseline win | Round 1: A gathers Timber; B gathers Reeds. Round 2: A sets posts; B weaves. | Warmth 2; both materials spent; both flags set; shelter installed before the Round 2 check; win. |
| Delayed but recoverable | Round 1: A gathers Timber; B waits. Round 2: A sets posts; B gathers Reeds. Round 3: A waits; B weaves. | Warmth 1 when shelter completes before the final check; win with no warmth restored. |
| Missed deadline | Round 1: A gathers Timber and B waits. Round 2: A sets the posts and B gathers Reeds. Round 3: both wait. | Shelter incomplete; warmth 1 → 0 after the check; loss before Round 4. |
| Invalid action | At reset, A tries to weave the screen or sets posts without Timber. | Action slot is used; inventory and flags do not change; the normal round-end cold check still occurs. |
| Restart | Restart from either terminal state. | Round 1, A first, warmth 3, empty shared satchel, and both build flags clear. |
If the numbers differ, first identify which written rule the result violates: resource count, action ownership, action order, construction completion, or warmth timing. Change one rule at a time and recalculate the baseline and failure case. Passing this paper check establishes internal consistency only; it cannot show that controls are readable, the implementation follows the prompt, or the challenge is enjoyable.
Use a multiplayer maker to shape the scenario
SEELE’s official multiplayer page describes a planning workflow around player count and mode, useful roles, a shared objective, interaction rules, and one short scenario to review. It also states that online play still depends on implementation, networking, synchronization, hosting, and testing. The page does not establish that this exact shared-screen, two-controller scenario is implemented or verified.
Bring the contract, not a claim of a finished game: specify the player setup, what each role can do, how both use the shared satchel, when the cold check resolves, and what counts as a win. Review any result against the state table. The product page is about planning, so keep the prompt and the hand checks responsible for the exact rules.
When you are ready to outline a multiplayer concept, open the Multiplayer game maker and adapt the prompt to the scenario you want to plan. Confirm the current workflow and inspect any output yourself; this article makes no claim that the example has been generated or tested.
Choose the next check, then expand
For a first pass, keep the contract small enough to resolve by hand: two role-locked actions, one shared recipe, one pressure rule, one reset, and two terminal outcomes. Once those pieces agree, choose a single next question—such as whether a third round is too punishing—and change only the rule that controls it. Do not add a new system until you know what decision it should create.
Reedwatch Camp is an original instructional paper model with concept illustrations. It is not a tested game, a SEELE-generated result, or evidence of working local or online co-op.
Frequently asked questions
Is Reedwatch Camp a playable or tested example?
No. Reedwatch Camp is an original paper-resolved teaching scenario. Its actions and warmth values are internally calculated from the rules on this page, but no prompt execution, generated build, play session, or user test was supplied. Use it as a specification exercise, then verify your own implementation before describing behavior as observed.
Do both players need a unique task?
They need a meaningful contribution to the shared goal, though not necessarily a completely exclusive ability. Here, the Timberhand owns the posts and the Reedworker owns the screen; both materials are required. That makes their contributions visible. If either role can complete the recipe alone, decide whether that is intentional and update the contract and acceptance cases.
Does the multiplayer maker guarantee local or online co-op?
No. The official page describes planning player count, mode, roles, objectives, interaction rules, and a short scenario. It says online play still requires implementation, networking, synchronization, hosting, and testing. Do not treat those planning details as proof that a specific local or online mode is available in a generated result.
Can I change the warmth or recipe values?
Yes. The values are teaching inputs, not a recommended balance. If you change warmth, gather amounts, recipe costs, turn order, or the moment of the cold check, recompute both the baseline and the delayed case. Keep the same reset and win/loss definitions while isolating one change so you can see which rule altered the outcome.
