Start with a loop you can resolve
To prompt an island-survival game, define one short goal, the actions a player can take before danger arrives, the quantities gained or spent, the order events resolve in, and the condition that ends the run. Then turn those decisions into a prompt sequence with an acceptance check for each step. That gives you something concrete to compare with a future build.
This guide uses Driftwake, an invented solo island-survival slice with one shelter recipe and two storm nights. Its names, rules, quantities, and example outcome are author-created teaching material. The prompts below were prepared for this article and were not submitted to a game generator. The ledger is a manual calculation, not a playtest, a generated result, or a playable Driftwake build.
The useful deliverable is a small design contract: three actions before each night, fixed gathering amounts, an exact shelter recipe, a clear water-and-storm order, and a two-night finish line. Keep that contract visible while you write the prompts.
Choose one survival goal and one place to start
“Make an island survival game” is a theme, not a first slice. A first prompt needs to say what the player is trying to accomplish soon, which pressures matter, and which systems can wait. Driftwake asks one solo castaway to prepare for two storm nights. It does not include combat, rescue, multiplayer, a permanent base, or progress carried between runs.
| Design choice | Driftwake rule | Why it belongs in the first slice |
|---|---|---|
| Goal | Survive two storm nights; finish after the second night. | A short finish line makes it possible to reason through the full loop. |
| Player and mode | One castaway, one solo run, no shared base or multiplayer rules. | Every action changes one visible state instead of adding coordination rules. |
| Pressure | Water is consumed each night; storms threaten health unless shelter durability remains. | Water and shelter create a decision about how to spend three actions. |
| Deferred systems | No factory, persistent ecological response, scenario editor, or between-run progression. | Those larger systems can be explored after this first loop works; each would add another set of rules and checks. |
These exclusions keep the example focused on one short run. Naming them helps prevent a first prompt from drifting into a different project.
Prompt 1: set the first-slice boundary
Design one fictional solo island-survival game slice called Driftwake. The player is one castaway preparing for exactly two storm nights. Define one finish condition: survive the second night with health above zero. Keep the setting to one tropical clearing connected by walkable paths to a shoreline driftwood site, a palm grove, and a freshwater spring. Exclude combat, rescue, multiplayer, factories, permanent progression, and a large crafting tree. Return a short scope brief with the player goal, starting state, locations, main pressure, and explicit exclusions. Flag any missing rule instead of inventing a new system.Check that the result names a goal the player can reach in a short run and a small set of places tied to useful actions. If the output adds a campaign or multiple players, remove that scope before defining resource numbers.
Define the daily actions and resource contract
Next, make every action legible in the same units. In Driftwake, the player receives three daylight actions before each night. Gathering includes the walk to a nearby source, so movement does not quietly consume a fourth action. Each gathering action adds a fixed amount, and crafting spends one action plus the listed materials.
| Action or rule | Cost and result | Check before using it |
|---|---|---|
| Gather driftwood | One action, including walking to the shore; gain 2 driftwood. | The shore route is reachable; no extra movement action is charged. |
| Gather palm fiber | One action, including walking to the grove; gain 2 palm fiber. | The grove route is reachable; no extra movement action is charged. |
| Collect water | One action, including walking to the spring; gain 1 water. | The spring is reachable and the quantity added is explicit. |
| Weave a lean-to | One action; spend 3 driftwood and 2 palm fiber to create durability 2. | Do not spend materials if the player cannot afford the whole recipe. |
| Daily cap | Exactly 3 actions before each night; resources cannot go below zero. | Stop accepting actions when the run ends or the action cap is reached. |
Gathering driftwood and palm fiber once each produces the exact recipe cost, so the third action can build the lean-to before Night 1. That is a meaningful choice: a day spent gathering water instead would leave the shelter unfinished, while repeat gathering is allowed but still uses one of the same three actions.
Prompt 2: lock the loop and resolve order
Using the approved Driftwake scope, define the exact resource and action rules. Start at health 3, water 2, driftwood 1, palm fiber 0, shelter durability 0, and three daylight actions. One driftwood action gains 2, one palm-fiber action gains 2, and one water action gains 1; each includes travel to its nearby source. Weaving costs one action plus 3 driftwood and 2 palm fiber, and creates shelter durability 2. At each night consume 1 water first; if unavailable, lose 1 health. If health reaches 0, end the run immediately and skip the storm. Otherwise, if shelter durability is above 0, reduce it by 1 and block storm damage; if not, lose 1 health. End immediately at 0 health. The player has exactly three actions before each night, resources never go negative, and the slice ends after surviving Night 2. Return a state table for each action and each night, then list assumptions.Review the returned table against the starting values, fixed gains, recipe, and order. A useful result says what happens when water is absent, when a recipe is unaffordable, and when health reaches zero. “The shelter helps during storms” is not precise enough to check.
Show the state that makes each choice understandable
A player should be able to see why a gathering action matters before spending it. For this design, feedback should identify remaining daylight actions, health, water, driftwood, palm fiber, and shelter durability. After crafting, the recipe materials are gone and two storm charges remain. At night, water resolves before shelter protection or health loss. These are proposed interface requirements, not a description of an existing SEELE interface.
The mechanism image represents the exact fictional state after the two gathering actions and the craft: health 3, water 2, driftwood 0, palm fiber 0, all three daylight actions spent, and shelter durability 2. It is a concept scene for explaining the authored rule, not a capture from a game.
Prompt 3: make action feedback useful
For the Driftwake rules contract, propose an in-game feedback plan for the player choices and night resolution. At each daylight action, show remaining actions, health, water, driftwood, palm fiber, shelter durability, the nearby reachable resource, and the result of choosing it. After crafting, show that 3 driftwood and 2 palm fiber have been consumed and that durability 2 remains. At night, show water being consumed before shelter protection or health loss; if missing water reduces health to 0, end immediately without resolving the storm. Do not invent buttons, labels, or features from a real product. Return the state shown before and after each decision and keep all values consistent with the rules.Check that the feedback changes when the player gathers, crafts, or resolves a night. Decorative bars that do not tell the player what changed are not enough. If you later build the interface, inspect whether each displayed value agrees with the actual game state rather than assuming the prompt made it correct.
Hand-resolve the two nights before adding systems
Apply the rules once by hand. The route below uses two gathering actions and one craft on Day 1, then one water, one wood, and one fiber action on Day 2. Each day uses exactly three actions. Since the shelter starts with durability 2, it blocks one storm-health loss on each of the two nights.
| Point in the run | Action or resolution | Health | Water | Wood | Fiber | Shelter durability |
|---|---|---|---|---|---|---|
| Start, Day 1 | Initial state | 3 | 2 | 1 | 0 | 0 |
| Day 1, action 1 | Gather driftwood; gain 2 | 3 | 2 | 3 | 0 | 0 |
| Day 1, action 2 | Gather palm fiber; gain 2 | 3 | 2 | 3 | 2 | 0 |
| Day 1, action 3 | Weave lean-to; spend 3 wood and 2 fiber | 3 | 2 | 0 | 0 | 2 |
| Night 1 | Water 2→1; durability 2→1 blocks storm loss | 3 | 1 | 0 | 0 | 1 |
| Day 2, action 1 | Collect water; gain 1 | 3 | 2 | 0 | 0 | 1 |
| Day 2, action 2 | Gather driftwood; gain 2 | 3 | 2 | 2 | 0 | 1 |
| Day 2, action 3 | Gather palm fiber; gain 2 | 3 | 2 | 2 | 2 | 1 |
| Night 2 | Water 2→1; durability 1→0 blocks the second storm loss | 3 | 1 | 2 | 2 | 0 |
| End | Two nights survived; slice complete at dawn | 3 | 1 | 2 | 2 | 0 |
The day actions total six, three before each night. The shelter absorbs both storm hits by spending one durability point per night; the castaway remains at health 3. The example ends after Night 2 at dawn, so there is no third daytime action phase. All values are hand-calculated expected states from the fictional contract.
Turn the contract into checks and failure cases
A prompt should ask for outcomes that can be judged. Use a short list of edge cases before expanding the map. These are planned acceptance checks for a future implementation, not tests that were run here.
| Case | Expected result | What the case catches |
|---|---|---|
| Crafting with missing material | The craft action is rejected without spending an action or subtracting a partial recipe. | Prevents negative inventory or an incomplete shelter. |
| Water unavailable, health 1 | Lose 1 health and end at zero immediately; do not resolve shelter or storm. | Checks the first night-failure gate. |
| Water unavailable, health above 1 | Lose 1 health, then continue to the shelter/storm step if the player is alive. | Separates a survivable water loss from a terminal one. |
| Shelter durability above 0 | Reduce durability by exactly 1 and block that night's storm-health loss. | Checks one protective charge per night. |
| Shelter durability 0 | Lose 1 health to the storm; end immediately if health reaches 0. | Checks the unprotected branch and terminal state. |
| Action cap | After the third daylight action, resolve night; no fourth action is accepted. | Prevents movement or crafting from bypassing the budget. |
| Second night survived | End the slice at dawn after Night 2, without a third day of actions. | Keeps the finish condition consistent with the scope. |
Ask for an expected-state table, not just a paragraph of feature descriptions. If a future build disagrees, record the state immediately before the mismatch, the action taken, and the expected versus observed result. Then revise the smallest conflicting rule and recheck the relevant cases. Do not say an acceptance check passed unless a real build was observed.
Prompt 4: request acceptance checks and a targeted revision
Using the final Driftwake contract and hand-resolved two-night table, create acceptance cases for: missing craft materials, no water at night with health 1, no water with health above 1, shelter durability 1, shelter durability 0, the three-action cap, repeated gathering, and surviving the second night. For each case, give the starting state, one action or resolution, exact expected ending state, and whether the run ends. Check every arithmetic result. If a state conflicts with the contract, name the exact rule and propose the smallest correction. These are plans for future checks, not evidence that the game has been run or tested.Refine a vague prompt without inventing a result
A v0 design request such as “make a tropical survival game with crafting and storms” omits the action budget, recipe, and resolution order. An author-written v1 can add only those missing constraints: three actions before each night, fixed gathering gains, a shelter that costs three wood and two fiber, and water resolving before storm protection. This comparison is a simulated prompt clarification, not an actual model response or a claim that a prompt improved a generated build.
Keep a short change note beside your prompt. Write down which ambiguity you removed, what value or sequence you added, and how you would check it later. This creates a trail from the first idea to a precise contract without implying that any software already follows it.
Bring the scoped brief to a game maker
Once the rules and hand table agree, describe your own game idea in plain English to a game maker, then inspect the playable first version it returns. SEELE's current Free AI game maker page describes turning a plain-English idea into a playable first version, testing it in a browser, and refining it with follow-up prompts. It supports 2D or 3D games, offers free starter Koins, and says to review the cost before each generation.
Those product facts describe a general creation and review workflow. They do not establish that Driftwake or the prompts in this article were generated, implemented, or tested. If you try your own prompt, compare the visible action and night states with your contract before adding another resource or hazard.
Start with one loop you can audit
Keep the first version focused on the survival decision: gather enough materials, decide whether to build, reserve actions for water, and survive the next storm. State each cost, gain, and end condition so a reader or future player can follow the same rule without guessing.
Take the scope, resource contract, and acceptance checks into the Free AI game maker when you are ready to shape your own project. Review what it returns before you continue building.
Island survival AI prompts FAQ
What belongs in the first island-survival prompt?
Name one short survival goal, the starting state, the actions available before each hazard, resource costs and gains, and the exact success or failure condition. A small contract gives a future build something specific to show. Keep extra systems such as multiplayer, permanent progression, and large crafting trees out until the first loop is understandable.
Why write the action and resource rules before asking for a prototype?
A prompt that says only “gather, craft, and survive” leaves action costs, material quantities, and event order open to interpretation. Define those values first so you can compare the resulting states against a ledger. This catches contradictions in the design before you spend time adding scenery or secondary systems.
How should the night resolve if the player runs out of water?
State the order and failure check explicitly. In this fictional example, water is consumed first; if it is unavailable, health falls by one. If health reaches zero, the run ends immediately and the storm is skipped. Otherwise resolve shelter protection or storm damage, then check health again before checking the two-night win.
Were the Driftwake prompts run or the example tested?
No. Driftwake is an invented teaching design, the prompt templates were prepared for this article and were not submitted to a game generator, and the two-night table is hand-resolved arithmetic. There is no generated Driftwake game, playable build, playtest, or measured result here. Treat the table as expected values for a future comparison.
How do I check whether a shelter recipe fits the action budget?
List the starting materials, the gain from each gathering action, the recipe cost, and the actions remaining before the hazard. In the example, two gathering actions produce the exact three wood and two fiber needed, leaving the third action for crafting. Then carry the shelter's durability through each night to confirm what it protects.
