Answer first: make one outing complete
A cozy exploration prompt needs more than a gentle color palette and a quiet setting. Give the player one action to repeat, a route that shows where to go, a forgiving way to recover, and a finish the player can recognize. Those rules make the first request easier to inspect than a long list of scenery and mood words.
Mossglass Crossing is an original paper-designed example for this guide: one paddler, one calm inlet, three ordered buoy gates, and a final cove dock. The route, controls, sample prompts, and expected states below are fictional design material. No prompt was run and no build or playtest was supplied, so the example demonstrates how to specify and check an idea, not a verified playable result.
Keep the first outing small enough to describe in a few sentences. If a requested feature does not change the player’s next choice, the route state, recovery, or ending, leave it out of the first pass.
Turn the calm mood into playable constraints
“Cozy” can mean different things to different creators. Translate it into behaviors that can be checked: no timer, damage, fuel, or lost progress; broad gates that are easy to read; and a recovery action that returns the kayak to safe water without undoing a completed gate. The route still has order and a destination, but it does not punish a slow turn.
For Mossglass Crossing, the cove dock is visible from the launch and the channel has no forks. Each gate pair sits across the route. A calm wake and a small buoy bob acknowledge a valid crossing. The feedback is local to the action, so the example does not need a timer, score, collectible, journal, or elaborate HUD to tell the player what changed.
These are choices for this proposed design, not universal rules for cozy games. If a different idea depends on optional discoveries, social encounters, or open-ended wandering, add those only after deciding how they affect the player’s route and what counts as a satisfying stopping point.
Write the rule contract before the scenery prompt
Before asking for detailed rocks or reeds, define how the player moves, what counts as progress, what recovery changes, and when the outing ends. Naming the crossing direction and next gate prevents a later gate from counting early or a backward pass from silently changing the result.
| Rule | Mossglass proposal | Expected response |
|---|---|---|
| Starting state | Begin at the launch with routeProgress = 0, checkpoint at launch, and completion false. | The first gate is the next objective; the cove dock is visible farther along one channel. |
| Controls | Hold Forward to paddle; Left and Right steer; Back paddles slowly in reverse; Recover repositions the kayak; Interact is for the final dock. | Each key has one stated effect; steering does not itself award progress. |
| Ordered crossing | Pass through the gap of the next buoy pair from its approach side. Valid forward crossings advance Gate 1, then 2, then 3. | Progress increases by one and only once per newly reached gate. A wrong-way, skipped, or already-passed gate changes no progress. |
| Feedback | On a valid crossing, the buoys bob slightly and the wake carries through the gap. | The player sees a small response tied to the action; no numeric HUD is required for the design. |
| Recovery | Touching a shallow bank stops the kayak. Recover places it in safe water beside the latest passed gate, or back at launch if progress is zero. | Position changes; routeProgress and completion do not. |
| Finish and restart | Interact ends the outing only at the cove dock when progress is 3. Restart from any state returns to launch, sets progress to zero, clears completion, and restores the launch checkpoint. | An early dock approach cannot skip gates. Restart gives the same known initial state. |
The state transition can be summarized in one sentence: only crossing the next gate in the forward direction changes routeProgress; Recover changes location only; the dock completes the outing only at 3/3. Keep that sentence beside the prompt while writing the scene.
This image is a concept depiction of the authored 2/3 state, not a game screenshot. It helps the reader see how physical landmarks can communicate ordered progress without adding a counter before one is needed.
Use a three-prompt sequence
Separate rule clarification, the first build request, and later correction. Each prompt should state its input, constraints, expected output, and how the reader can check that output. The first two prompts below can be adapted before a build exists; the third is only for use after an actual observation.
Prompt A: expose unclear rules
I am planning a small single-player cozy exploration game called Mossglass Crossing. This is a fictional design brief, not a report of an existing game.
The player starts beside a launch dock in a kayak. The goal is to pass three buoy pairs in order through each gap from the approach side, then interact at a visible cove dock. Forward paddles, Left and Right steer, Back paddles slowly in reverse, Recover moves the kayak to safe water beside the most recently passed gate (or the launch at 0/3), and Interact is reserved for the final dock. A valid forward crossing of the next gate adds one to routeProgress. Wrong-way, skipped, and duplicate crossings do not change progress. Recovery changes position but not progress. The dock completes the outing only at 3/3. Restart restores the launch state and clears progress and completion.
Do not design scenery or build yet. Return: (1) a state and transition table, (2) any ambiguous or conflicting rule, (3) expected results for a wrong-way Gate 1 crossing, an early Gate 3 attempt at 0/3, a recovery after Gate 2, and an early dock interaction. Do not silently invent rules. Label all proposed choices as design decisions, not observed behavior.Read the ambiguity list first. Decide any open choice yourself before asking for a build; otherwise a later result may follow an assumption you never intended.
Prompt B: request the minimum route
Build a small single-player, third-person real-time 3D kayak exploration prototype from this design specification. The setting is one calm limestone inlet with a launch, one continuous channel, three wide buoy gate pairs, and a final cove dock. Use an adult paddler in a reddish wooden kayak. Keep the first pass compact and readable.
At reset, place the kayak at the launch with routeProgress = 0, completion = false, and the launch as the recovery point. Hold Forward to paddle; Left and Right steer; Back paddles slowly in reverse; Recover returns the kayak to safe water beside the latest passed gate or the launch; Interact is for the final dock. Only a forward crossing through the next gate's gap increments routeProgress by one, once. Wrong-way crossings, early later gates, and duplicate passed gates do nothing. Recovery changes only position. Interact completes the outing only at the cove dock when routeProgress = 3. Restart restores the full launch state.
Show simple nonverbal feedback when a valid gate is crossed, such as a slight buoy bob and the wake passing through the gap. Keep the channel continuous with safe margins. Exclude timers, damage, fuel, collectibles, branches, NPCs, weather, journals, resource systems, scoring, and extra quests. Do not add mechanics that change progress or completion.
Return a short restatement of the controls and state rules with the prototype. If a rule cannot be represented or must be changed, list that difference explicitly. Do not claim the design has been implemented or tested unless it has actually been built and checked.This is a request to try a defined prototype, not evidence that a workspace will implement the controls or gate logic as written. Compare any real output with the contract before expanding the art or route.
Prompt C: revise one observed mismatch
Use this only after you have an actual build and have repeated the same check. Do not invent an observation.
Reproducible action: [exact input and starting state]
Expected state from the written contract: [progress, position, completion]
Observed state in the build: [what actually happened]
Change only the smallest rule or control needed to correct this mismatch. Preserve all other listed rules. Before editing, explain which state transition is wrong. After editing, state exactly how I should repeat the same check. If you cannot confirm the result by inspecting or running the build, say what remains unverified rather than reporting success.Prompt C is a reusable correction format, not a claim that this example has produced an observed mismatch. Only a real action and result can fill its observation fields.
Hand-resolve one route, then check it
Use one short trace to see whether the written rules agree with each other. This is a manual calculation over the proposed rules, not a game run or playtest.
| Step | Player action | Expected state |
|---|---|---|
| Start | Begin beside the launch dock. | Progress 0/3; launch is checkpoint; completion is false. |
| 1 | Paddle forward through Gate 1. | Progress becomes 1/3; Gate 1 is the latest checkpoint. |
| 2 | Steer through Gate 2. | Progress becomes 2/3; Gate 2 is the latest checkpoint. |
| 3 | Drift into the shallow bank and press Recover. | Kayak returns beside Gate 2; progress stays 2/3; completion stays false. |
| 4 | Paddle forward through Gate 3. | Progress becomes 3/3; completion is still false until the dock interaction. |
| 5 | Reach the cove dock and press Interact. | Completion becomes true with a calm landing response. |
The expected sequence is 0/3 → 1/3 → 2/3 → recover at 2/3 → 3/3 → dock complete. Recovery changes location but not route progress; docking changes completion only after all three forward crossings. The image is a concept rendering of that proposed ending, not evidence of a completed game.
| Check | Action from a known state | Expected result |
|---|---|---|
| Wrong direction | At 0/3, pass through Gate 1 from its far side. | Progress remains 0/3. |
| Skip ahead | At 0/3, pass forward through Gate 2. | Progress remains 0/3; Gate 1 is still next. |
| Duplicate gate | At 1/3, recross Gate 1 or circle through it again. | Progress remains 1/3; Gate 2 remains next. |
| Recover at zero | At 0/3, touch a bank and press Recover. | Return to the launch; progress remains 0/3. |
| Recover at two | At 2/3, touch a bank and press Recover. | Return beside Gate 2; progress remains 2/3. |
| Early dock | Approach the cove dock at 2/3 and press Interact. | The outing does not complete; progress remains 2/3. |
| Restart | Restart after completion. | Return to launch with 0/3, completion false, and the launch checkpoint restored. |
These are acceptance checks a reader can run against their own build. Until then, they remain expected outcomes derived from the stated rules, not observed results.
Make one evidence-based revision
If an actual result differs from the expected state, record the starting state, exact input, expected outcome, and observed outcome before changing the prompt. Then revise only the affected rule or control and repeat the same action. For example, if a valid Gate 2 crossing leaves progress at 1/3, inspect how the crossing direction and next-gate condition were described before adding a new map or reward system.
Keep expected and observed values separate in your notes. A paper trace can show that the specification is internally consistent; it cannot show that a generated control feels responsive, a gate is easy to cross, or a player understands the feedback. If you do not have a build, leave the observed field blank and treat the next step as a plan.
Hand the brief to a creation workspace
The current Free AI Game Maker page says a creator can describe a game idea in plain English, review a playable 2D or 3D result, continue iterating in Workspace, and check displayed Koin costs and account options before generation. Those are general workflow details from the product page. The page does not document kayaking, ordered buoy gates, checkpoint recovery, the exact controls here, or a successful Mossglass Crossing run.
Use your own short contract as input, then inspect what the workspace actually returns. If its result changes a crossing rule, recovery state, control, or completion condition, compare that difference with the table above and decide whether to change the prompt or the design. The capability category names are broad planning references; they do not guarantee that this specific route will be built as written.
Carry the contract into your next step
Before adding a second route or a new activity, check five essentials: player action, ordered landmarks, progress change, recovery behavior, and finish condition. A compact route with these pieces gives you a clear first request and a specific way to judge an actual result.
When you are ready to shape your own game idea, open the Free AI game maker. Bring a brief you can inspect, review the result and current generation cost in the workspace, and treat every unverified mechanic as an open question until you check it.
Frequently asked questions
Is Mossglass Crossing a playable or tested game?
No. Mossglass Crossing is an original paper-designed teaching example. The route trace is hand-resolved from the rules in this article; no prompt execution, generated build, user session, or playtest was supplied. Use it as a specification exercise, then verify your own build before describing controls or route behavior as observed.
Should progress decrease if the kayak crosses a gate backward?
Not in this design. Only a forward crossing through the next gate increments progress; a wrong-way, skipped, or duplicate crossing leaves the value unchanged. If you want players to retreat and lose route progress, describe that as a separate rule with its own trigger and feedback instead of letting the gate crossing direction imply it.
What should recovery change after the kayak touches a bank?
Here, Recover changes position only. At 0/3 it returns the kayak to the launch; after a valid gate it places the boat in safe water beside the latest passed gate. Progress and completion remain unchanged. If your game should reset some progress on recovery, name exactly which state resets and add a check for that case.
How can a calm route still give players a clear goal?
Use landmarks and an ending without adding a timer. In this example, three visible gate pairs give the player a next destination, while a distant cove dock shows where the outing ends. A forgiving recovery reduces the cost of a steering mistake, and local wake feedback acknowledges a valid crossing without adding score pressure.
Will a prompt guarantee that the route works in a game maker?
No. The official product page describes a general idea-to-playable-result workflow, but it does not verify these kayak rules or promise a particular control, gate, or recovery implementation. Inspect the actual result against the written checks. If no build exists yet, describe the prompts and checks as a plan, not as a tested outcome.
