Underwater survival is easier to prototype when the player has one route, one retrieval goal, and two readable limits. Start with a surface dock, a shelf, and one trench. Give each valid action a known oxygen cost, make deep exposure visible in a second counter, and decide exactly when failure is checked. Then separate your AI requests: first the rules, next the smallest playable slice, and only later a repair request tied to observed behavior.
Blueglass Reach is an original fictional design used for a hand-calculated teaching example. No prompt has been run and no playable build or test exists. Its oxygen and seal values are invented game settings, not real diving guidance.
Make one dive the scope
A first underwater prototype does not need a world map, an oxygen economy, base building, or several kinds of sea life. It needs a short journey where the player can tell what they are trying to retrieve and whether they can return. Blueglass Reach uses one diver and a sealed survey capsule: descend, scan, collect, and make it back to the Moon Pool.
Keep the route small enough to inspect as a sequence of locations rather than a coordinate system. D0 is the Moon Pool surface dock. D1 is a rock shelf between the pool and the trench. D2 is the Blue Trench, where the capsule rests. Movement is legal only between adjacent nodes. The same route is used to descend and return, so every cost can be checked before any art or extra objective is added.
| Node | What the diver sees | Route decision |
|---|---|---|
| D0 — Moon Pool | Surface dock, tether anchor, and the only safe return point | Start here; win only by returning here with the capsule |
| D1 — Shelf | A broad ledge between clear upper water and the darker trench | Move one edge at a time to D0 or D2 |
| D2 — Blue Trench | One sealed survey capsule and a narrow route back up | Scan, collect, or leave; no refill or repair is available |
This is a single-player, single-dive slice. It deliberately leaves out co-op roles, persistent progression, linked settlements, crafting, and a renewable resource loop. Those systems would answer different design questions and make it harder to tell whether the first return route works.
Write oxygen and pressure costs before prompting
Set the starting state and action order before asking a tool for a scene. In this example the diver begins at D0 with oxygen 8/8, suit seal 5/5, no scan, and no capsule. Every valid action costs one oxygen. A valid action that starts or ends at D2 also costs one seal point, once even when a move crosses the D1–D2 edge. Invalid actions are rejected before either cost is applied.
The deep-exposure rule is a simple game token, not a simulation of a diver or suit. The real-world premise is narrower: NOAA says water pressure increases with depth by about one atmosphere for each 33 feet (10.06 meters) descended. That direction of change can motivate a rising-depth challenge, but it does not validate the made-up seal counter, its one-point step, or any equipment or safety conclusion. The NOAA pressure explanation supports only the physical premise.
| Rule | Design contract | What to inspect later |
|---|---|---|
| Move | Move to one adjacent node only; pay 1 oxygen, then apply 1 seal cost if the move starts or ends at D2 | Position, oxygen, and seal after each edge |
| Scan | At D2, once only; pay 1 oxygen and 1 seal, then set scanned to true | The capsule is revealed and both counters update once |
| Collect | At D2 after scanning, once only; pay 1 oxygen and 1 seal, then set capsuleCarried to true | The floor socket empties and the diver carries the capsule |
| Wait | Legal at any node; pay 1 oxygen and the D2 seal cost when waiting there | No objective progress; counters still change |
| Invalid action | Reject non-adjacent movement, early or repeated Scan, or early/repeated Collect without changing state | Position, counters, and flags stay exactly as they were |
| Terminal check | After a valid action, check oxygen or seal at zero first; only then check for D0 with capsuleCarried | A zero resource is a loss even if the diver reached D0 on that action |
Resolve each valid turn in the same order: subtract one oxygen, apply movement or objective change, subtract one seal if the action began or ended at D2, then check loss before win. Do not let a successful pickup erase its cost or let a return count as a win after oxygen has reached zero. Reset is a control that restores the full initial tuple; it is not a free in-dive action.
The image marks the exact post-Collect decision: the capsule has left its socket, the diver holds it, and the upward route remains open. The two remaining seal points are enough for one D2-to-D1 ascent and leave one point for the final swim to D0, because the D1-to-D0 move does not touch the deep node.
Turn rules into three AI prompts
Do not put world-building, implementation, and testing into one oversized request. Each prompt below has a different job and an output you can inspect. These are copy-ready templates, not prompts recorded from a model run. Keep the rules unchanged between them so a later observation can be traced to a specific request.
Prompt 1: ask for an implementation contract
Design a small original single-player underwater survival prototype called Blueglass Reach. Before writing code, return a concise implementation contract for only this route: Moon Pool D0 ↔ Shelf D1 ↔ Blue Trench D2. The diver starts at D0 with oxygen 8/8 and seal 5/5. A sealed survey capsule is at D2. Every valid action costs exactly one oxygen. Move only along an adjacent route edge. Scan once at D2 to reveal the capsule. Collect once at D2 only after scanning. Wait is legal but makes no progress. A valid action starting or ending at D2 loses one seal point exactly once; an invalid action costs nothing and changes nothing. Resolve: oxygen cost; action effect; one deep-exposure cost if applicable; failure if oxygen or seal is zero; otherwise win only if at D0 carrying the capsule. Reset restores the initial state. Return the state schema, action preconditions, transition order, win/loss conditions, and a compact test table. Do not add multiplayer, a base, crafting, oxygen refills, persistent progression, random values, or extra map nodes. Label the numerical values as fictional design settings, not real diving guidance.Check the returned contract against the node graph and cost order. It should reject an attempted D0-to-D2 jump, a second scan, and a collect before scanning without changing a counter. If the rule table adds a free action or applies the seal cost twice on a single D1–D2 move, correct the contract before asking for a build.
Prompt 2: request the smallest playable slice
Using the Blueglass Reach contract below, build the smallest playable one-dive prototype in your available game runtime. Show a third-person diver, the three connected depth locations, a scan target at D2, one collectible capsule, and a clear return route. Provide one-step adjacent movement, a single-use Scan, a gated Collect, a no-progress Wait, and Reset. Keep oxygen and seal values visible as simple counters or pips; show scan, pickup, failure, and return feedback with distinct, readable states. Implement the action order exactly: reject invalid actions without cost; spend oxygen; apply the action; subtract one seal if the action starts or ends at D2; check oxygen/seal failure before checking the D0-with-capsule win. Do not add a base, another diver, a crafting economy, a second objective, random rolls, or a pressure/medical simulation. Return the build or code plus how to run it and a short manual test checklist. Mark every case as unverified until someone actually runs it; if this runtime cannot provide a playable build, state that limitation rather than claiming success.This request asks for the interactions and feedback that make the rules inspectable; it does not guarantee a tool will implement them. If a real build is later returned, test the node edges, the scan gate, the pickup, both counters, failure ordering, and reset. Keep any unobserved behavior marked unverified.
Prompt 3: compare observations and request one repair
Review the actual Blueglass Reach build and the run notes supplied below. Do not infer a pass from the design brief. For each supplied case, list expected state, observed state, evidence supplied, and pass/fail/unverified. First compare: (A) the six-action safe route from O8/S5 ends at D0 with capsule carried at O2/S1; (B) after collecting, Wait then ascent reaches seal 0 at D1 and loses; (C) the same safe route from O6 reaches oxygen 0 on the final action and loses before the win check; (D) Collect before Scan is rejected without changing state; (E) Reset restores D0/O8/S5/no scan/no capsule. If an observation is missing, mark it unverified. For a failure, propose the smallest code or rule change that restores the contract, then list only the affected cases to rerun. Do not add features or report a test as passed unless the supplied run notes visibly establish it.
Actual run notes / screenshots / state log: [paste only after a real run; otherwise leave blank and report “not executed”].The third prompt is evidence-gated. With no actual run notes, its correct output is a list of unverified checks and no claimed pass. That rule keeps a hand calculation useful as a target without dressing it up as a prototype result.
| Prompt job | What it should return | Acceptance check |
|---|---|---|
| 1. Rules | State schema, preconditions, transition order, terminal rules, and compact cases | Every listed action and cost matches the contract; no extra system appears |
| 2. Playable slice | A small route with movement, scan, collect, feedback, counters, and reset | The player can see which input changed which state; absent features are reported honestly |
| 3. Validation / repair | Expected-versus-observed results and one narrow correction if a real mismatch exists | Missing observations stay unverified; only affected cases are rerun |
Paper-check the return route and failures
Before asking for code, trace the route one action at a time. Start at D0 with oxygen 8 and seal 5. The safe path has six actions: move to the shelf, descend, scan, collect, ascend, and return. Only actions that start or end at D2 spend seal, and each valid action spends one oxygen.
| Step | Position | Oxygen | Seal | Scan / capsule |
|---|---|---|---|---|
| Start | D0 | 8 | 5 | No / no |
| Move to shelf | D1 | 7 | 5 | No / no |
| Descend to trench | D2 | 6 | 4 | No / no |
| Scan | D2 | 5 | 3 | Yes / no |
| Collect | D2 | 4 | 2 | Yes / yes |
| Ascend to shelf | D1 | 3 | 1 | Yes / yes |
| Return to Moon Pool | D0 | 2 | 1 | Yes / yes — success |
The route succeeds because both counters remain above zero when the diver returns with the capsule. The scan and collection consume two separate actions. The descent and ascent each count as one deep-exposure action; crossing D1–D2 does not spend two seal points.
Two close alternatives test the terminal order. If the diver waits at D2 after collecting, oxygen falls from 4 to 3 and seal from 2 to 1. The next ascent reduces them to oxygen 2 and seal 0, so the run loses before any return can count as a win. If the same six-action route starts at oxygen 6, the last move reaches D0 with oxygen 0 and seal 1; failure is checked first, so it loses. Starting at 7 instead leaves oxygen 1 and seal 1 at D0, so that route wins under the written rules.
This outcome image is a concept rendering of that terminal state. The green dock light is feedback for the fictional arrival, not evidence that a generated prototype has returned the diver or that a pressure mechanic works.
Revise only from observed behavior
If a real build differs from the contract, write down the first state that diverges. Record the input, starting node, oxygen, seal, scan flag, capsule flag, expected next state, actual next state, and the evidence you observed. A later failure may be caused by an earlier cost or flag that changed incorrectly, so do not start by rewriting the whole prompt.
- Locate the first mismatch. Compare the actual result to the matching row in the paper trace, not to a vague impression that the dive felt wrong.
- Name the smallest rule involved. Examples include adjacency, the scan prerequisite, a once-only action, the single D2 seal cost, or loss-before-win ordering.
- Ask for one targeted repair. Keep unrelated controls, scene layout, and costs fixed so the next observation isolates the intended change.
- Rerun only affected checks. A change to the Collect precondition needs the early-Collect case; a change to terminal order needs the zero-oxygen return case.
- Keep the result status honest. A design table is expected behavior. A prompt is an unrun instruction. Only recorded behavior from a real build can support a pass claim.
Without an actual build and run notes, stop at the paper contract. Do not invent an expected screenshot or describe a proposed fix as tested. When you later provide a real tool with the three prompts, inspect its output yourself, check the current model and displayed cost, and report the result that is actually visible.
Start a first underwater survival prototype
Begin with one returnable dive. A short node route, one objective, and an explicit failure order give you a small target to build and inspect. The hand trace is a baseline for your own test, not proof that a build already follows the rules. Once you have a concise brief, use the Free AI game maker to explore a first playable direction, then review what actually works and what needs another pass. Before submitting a generation request, review the selected model, available Koin balance, and displayed generation cost in Workspace.
Frequently asked questions
What is the smallest underwater survival loop to prototype?
Use one diver, one route with a surface point and a deeper objective, and one return condition. Give the player a small number of readable actions and state values, then trace how each action changes them. A compact slice helps you see whether the goal, route, and failure condition are understandable before adding creatures, crafting, or a larger world.
Does the seal counter model real diving pressure?
No. The one-point seal loss near D2 is a fictional game rule chosen to make the return route easy to calculate. NOAA supports only the broad physical fact that pressure increases with depth, at roughly one atmosphere per 33 feet of descent. The counter is not a model of physiology, equipment, safe limits, or underwater practice.
Why should invalid actions leave all values unchanged?
Rejecting an invalid move or an early Collect before charging resources gives the player clear feedback about the rule they missed. It also creates a deterministic check: if a rejected command changes position, oxygen, seal, or flags, the implementation has drifted from the contract. You can choose a different rejection design, but state its cost and test it explicitly.
When should I ask for a prompt repair?
Ask for a repair after a real observation identifies the first mismatch between expected and actual state. Include the action, starting values, expected result, observed result, and a single rule to change. Keep unobserved cases marked unverified, and rerun the checks that depend on the changed rule before treating the correction as successful.
Have these Blueglass Reach prompts been run or playtested?
No. They are reusable prompt templates for an original fictional scenario, and the route calculations are worked by hand from the rules in this article. No model execution, playable build, or playtest is represented here. Use the trace as an acceptance target for a future build, then report only states you actually observe.
