Make a Card-Based Survival Game with AI: Balance Cards Against Survival

To make a card-based survival game with AI, make every play compete between keeping a need above zero and moving toward rescue. A fixed hand, two actions each day, two persistent needs, and one rescue track can create a complete first loop without a shop or random draw. The key is to state exactly when cards resolve, when needs fall, and when a run ends.

Whiteout at Relay Nine is an original paper design about a weather observer sheltering in an alpine signal hut. Its rules and images are teaching examples, not a built game or a playtest. Use the state route as a design simulation, then compare a real prototype with the same checks before describing behavior as tested.

Make card choices carry the survival loop

A card-based survival game needs more than resource icons on a hand. Each card should change a need, protect it from a known cost, or advance an escape goal. The player then has to decide what to address now and what risk to accept until the next turn.

In Relay Nine, a slide blocks the mountain pass. Noor has three days before a search team reaches the station, but the hut still needs heat and food. The player sees the same four action cards each morning and chooses exactly two different cards. There is no shuffle, hidden weather modifier, shop, or extra resource in the first slice. That makes it possible to trace a decision from card to state change to outcome.

Start with only three tracks: Warmth, Rations, and Signal. The first two are needs that can reach zero; Signal is progress toward rescue. Keep each visible at all times. The player should be able to see both the immediate effect of a selected card and the risk that remains at dusk.

Define cards, caps, upkeep, and endings

Write the action contract before adding a deck. Each card is a daily action and can be used once before dawn restores the hand. A card occupies one of two action slots. Apply card effects first; then resolve dusk. Need tracks cap at 3 and clamp at 0.

At dawn, restore all four cards and keep the three tracks. At dusk, subtract 1 Warmth unless Patch Roof is active, reset that shield, and subtract 1 Ration. Clamp both needs at zero. If either is zero after upkeep, show failure before another dawn. After the third dusk, rescue arrives only when Signal is 2 and both needs remain above zero; otherwise Noor is still stranded.

The order matters. If the game checks rescue before dusk, a player might win with a need that falls to zero moments later. If it applies upkeep before the two card effects, the same run may fail even though both cards should have resolved first. Keep this sequence visible in the prompt and acceptance test.

Prompt one small playable slice

Give a game maker a precise starting state, input, state transition, and observable result. Do not ask it to “make survival feel tense” and leave the action rules open. These prompts are reusable design templates; they have not been run through SEELE and do not prove that a particular tool implements the requested mechanics.

Prompt 1: close the rules model

Design a deterministic card-based survival game called Whiteout at Relay Nine.
The player is Noor, sheltering in an alpine signal hut for three days.
Persistent state: Warmth 2/3, Rations 2/3, Signal 0/2; roofShield=false.
Show exactly four cards each dawn: Tend Stove, Cook Rations, Patch Roof,
Repair Signal. The player selects exactly two different cards per day.
Cards may each be used once per day and return at the next dawn.

Tend Stove adds 2 Warmth; Cook Rations adds 2 Rations; both need tracks
cap at 3. Patch Roof blocks the next 1-point Warmth loss at dusk, then clears.
Repair Signal adds 1 Signal, capped at 2. Resolve cards before dusk upkeep.
At dusk lose 1 Warmth unless shielded, then lose 1 Ration; clamp at zero.
If either need is zero, fail before the next dawn. After Day 3 dusk, rescue
requires Signal=2 and both needs above zero. Otherwise Noor remains stranded.

Return a rule table, one screen layout, the exact end-of-day order, and
acceptance cases. Add no draw pile, shop, event, hidden modifier, or resource.
If any rule conflicts, list the conflict instead of inventing a new rule.

Read the returned rule table before asking for more content. Check that there are two slots, the correct caps, the same upkeep order, and both end conditions. If an answer introduces extra weather, health, or a shop, remove that scope before requesting an interaction.

Prompt 2: build the first action screen

Build a focused first slice from the approved Relay Nine rules.
Show Noor at the hut workbench, the four action cards, two empty daily slots,
Warmth, Rations, Signal, the day number, and an End Day control.
Make the two selected cards resolve before upkeep. Disable a second use of the
same card in one day. Show card effects, then dusk losses, then the end check.
Keep needs at 0–3 and Signal at 0–2. On a zero need, show a failure result.
After Day 3, show rescue only if Signal is 2 and both needs are positive.
Add a reset that restores Day 1 and the starting values. Do not add other
resources, random draws, upgrades, or mechanics not listed in the contract.

The prompt names the player action, screen state, expected feedback, exclusions, and end conditions. If the target cannot implement this sequence, ask for a design handoff rather than accepting an interaction that merely resembles the concept.

Prompt 3: compare a build with the expected route

Audit this prototype against the Relay Nine state contract.
Do not claim a rule passed unless the supplied observation shows it.
Check this route from a clean reset:
Day 1: Tend Stove + Repair Signal.
Day 2: Cook Rations + Repair Signal.
Day 3: Tend Stove + Cook Rations.
For every action, record the starting state, card effect, dusk upkeep,
and ending state. Confirm the expected sequence is W2/R1/S1, then W1/R2/S2,
then W2/R2/S2 with rescue after Day 3. Also check that Patch Roof blocks
only one Warmth loss and that restart clears it.
If no playable observations are supplied, return the expected checklist and
label all implementation results unobserved.

Keep expectation and observation in separate columns. A prompt describes what you want; it does not establish what a generated version did. When you do test, repeat the same route from reset so a mismatch has one likely cause to inspect.

Balance daily needs against rescue progress

With two card slots, every Repair Signal play displaces an action that could protect Warmth or Rations. The sample route uses one signal action on each of the first two days, then spends both Day 3 actions on survival. Each state below is calculated from the rules, not measured from a game.

The Day 2 choice is the tightest point: Warmth will fall to 1, so the player must use Day 3 to restore it before dusk. Signal reaches its cap at 2, so another repair would waste a slot. A different legal route can use Patch Roof to block a Warmth loss, but its shield must be consumed at the next dusk and cannot protect the hut twice.

The visual should agree with the table: Cook Rations and Repair Signal occupy the two slots, all three ration pips are lit, and the Warmth track still shows a risk. If your prototype shows an extra ration pip, uses the signal card twice, or resolves upkeep early, check the state transition before changing the balance values.

Use a paper balance pass when no test evidence exists

Without a playable build or recorded observation, the comparison below is a paper exercise based on the written rules. It shows whether this proposed route is internally reachable; it does not show how a generated game behaves or how a player responds to it.

Start with a baseline that permits only one card action per day and keep the same starting state and dusk rules. A signal-first route plays Repair Signal on Days 1 and 2. After Day 1, the state is W1/R1/S1. After the Day 2 signal, the state reaches W0/R0/S2 at dusk and the run ends before rescue can arrive. Prioritizing a need instead leaves too little action capacity to complete the two-point signal goal while keeping both needs positive.

This calculation checks whether the written route is internally reachable. It does not tell you whether a player understands the controls, whether the generated interaction follows the rule, or whether the game feels tense. A real build still needs a repeatable route check and observations from play.

Diagnose the first run instead of adding more cards

Use the same starting state and test one failure at a time. A card effect that appears to work can still hide an order bug: a track may update after upkeep, a capped signal might overflow, or an old roof shield may carry into the next run. Compare the visible state after each step with the table, not only the final rescue screen.

After a real test, record the starting values, the two cards, every visible change, and the first point where the result differs. Ask for one focused revision and repeat the same route. The paper table is useful because it tells you what to compare; it cannot supply the missing observation.

Take the rules into a first creation pass

The official Free AI Game Maker page describes writing a game idea in plain English, testing a playable 2D or 3D result in the browser, and refining it with follow-up prompts. Its FAQ says SEELE Workspace shows the selected model, available Koin balance, and displayed generation cost before submission. This is general workflow guidance, not a guarantee that SEELE implements the fictional Relay Nine card economy or survival rules.

If the result lacks a visible hand, action slots, dusk sequence, or restart behavior, ask for the missing piece directly. If the target tool cannot represent persistent needs or ordered upkeep, keep the contract as a design handoff for another build step. Do not call a visual card mockup a playable survival loop until you can observe the rules changing state.

Add an event only when the base run is readable

Keep the first run deterministic until you can trace the three-day route and one failure. Then add one weather event or a new card only if it creates a decision the four-card hand cannot express. For example, a forecast might make Patch Roof more valuable on one day, but it should not silently change the existing dusk order.

Once you are ready to shape and review your own idea, open the Free AI game maker and bring the action contract with you. Keep needs, card effects, and end checks visible through each iteration so a new mechanic adds a choice instead of obscuring the survival loop.