Make a Card-Based Narrative Game with AI: Start With One Story Loop

To make a card-based narrative game with AI, give each card a story job: what it lets the player share, what state it changes, and how another character responds. A compact first loop can use four cards, two message slots, one reply, and a reset. That is enough to show why a card matters without starting with a large deck or several branching scenes.

The example below, The Last Postcard, is an original paper design about a printmaker named Iris and her brother Eli. It has not been built or playtested. Use it as a rules model, then compare your own playable result with the expected states before calling any behavior tested.

Make every card change what the story can say

A narrative card is more than a dialogue choice with a picture frame. It should do something the reader can point to: reveal a detail, make a promise, ask a question the other character can answer, or change what a later scene knows. If two cards always produce the same reply and state, merge them or give one a distinct consequence.

For The Last Postcard, Iris is preparing one message for Eli, who moved across town after a family disagreement. The hand is fixed; there is no random draw in the first slice. Iris fills a Memory slot and a Reply slot, then sends one message. Each selected card can be used once in that message.

Begin by separating the roles of the two slots. A Memory card supplies context Eli can refer to. A Reply card determines how Iris responds. The guard on Question matters because an honest question about a shared detail is different from asking about something Eli has not been told.

This contract gives each card a slot, a precondition, and a visible consequence. It also tells the builder what must stay consistent: a disabled Question card cannot still send a question or change a flag.

Close the valid pairs before adding more scenes

Write the legal combinations down before drafting dialogue. There are three valid pairs and one invalid pair. A short response for each valid pair is easier to inspect than a large branching script whose state rules are hidden in prose.

Do not let the reply text imply a flag that the chosen cards did not set. In particular, Blank Page + Promise does not produce an answer to a question: no Question was played. The disabled pair also needs a reason, so a player knows what is missing rather than assuming the card is broken.

Keep only two carry-over values in this slice: detailShared and promiseMade. After Eli replies, a small handoff panel can show which values a later scene would receive. That panel is a state preview, not a second playable scene. Reset clears both values, restores the fixed hand, and returns the two slots to empty.

Prompt the smallest card-to-reply loop

Ask for the interaction and its state transitions, not just a premise and a mood. A useful prompt names the starting hand, the two slots, what each card changes, when the send action is valid, and what a player can inspect afterward. Keep the first requested result narrow enough to check in one sitting.

Prompt 1: turn the idea into a rule contract

Design a one-scene card-based narrative game called The Last Postcard.
The player sends one message from Iris to her brother Eli.
Start with exactly four fixed cards: Postmark, Blank Page, Promise, Question.
The player fills one Memory slot and one Reply slot, then selects Send.
Each card can be used once in the message; no draw, discard pile, or extra card.

Postmark sets detailShared=true and shares the riverside place and date.
Blank Page leaves detailShared=false.
Promise sets promiseMade=true.
Question is enabled only if detailShared=true; otherwise keep it visible,
disabled with the reason “Share a memory first,” and make it change nothing.

Resolve Postmark+Promise, Postmark+Question, and Blank Page+Promise with
different replies that match their flags. Reject Blank Page+Question.
After one reply, show the two carry-over flags in a handoff panel. Reset must
clear both flags, restore the four cards, and empty both slots.
Return a compact state table, the message flow, and acceptance checks.
Do not add another scene, random draw, or unlisted flag.

This prompt first asks for a contract, which is useful even if the target tool cannot implement every rule in one pass. Check that all three legal pairs have a response, the fourth pair is blocked, and the reset state is explicit. Fix contradictions here before asking for a playable interaction.

Prompt 2: request one inspectable interaction

Build one focused card-message interaction from the approved contract.
Show the four cards, Memory and Reply slots, Send, the current two flags,
Eli's response, and Reset in one readable scene.
Require the Memory card before enabling a Reply card. Do not let the player
send a card twice or send Blank Page+Question. Show the exact disabled reason.
After Send, move the used pair out of the hand and show Eli's matching reply.
Display detailShared and promiseMade in a next-scene handoff panel only;
do not add or imply a second playable scene.
Keep the riverside print shop and apartment as the setting, and use short
dialogue that does not claim an unplayed card effect. Make the card selection,
state changes, and reset visible. If a requested rule is unsupported, return
the limitation and a design handoff instead of silently changing the rules.

Expect the visual arrangement to help you notice state, but verify the interaction itself. Can you select the Memory card first? Does Question change from disabled to enabled only after Postmark? Does the message use the selected pair, then show the matching reply? Those are build checks, not assumptions that follow from the prompt.

Walk a paper revision without calling it a playtest

A prompt can specify a rule and still leave an unclear player action. In this design, Question starts disabled when no memory is shared. A bare disabled state does not explain how to make it available. Revise the design copy to show the reason, “Share a memory first,” while keeping the card visible and leaving state unchanged on an invalid attempt.

This is a paper iteration: the rules and expected response are compared on paper. It is not an observed user test, a generated game result, or evidence that a product implemented the guard. In a real build, watch whether a player can identify the required card and whether an invalid attempt leaves both flags untouched.

The copy change does not alter the story rule. It gives the player a route to the missing context. Keep that distinction clear when you ask an AI to revise a prototype: a usability hint should not secretly set detailShared or send a message.

Check state, response, and reset

Trace each legal pairing from a clean start. Confirm that the selected cards disappear from the active hand after Send, that Eli's reply matches the pair, and that the handoff panel carries only the two defined values. Then reset and repeat. A readable response is not enough if it contradicts the selected cards or if a previous run changes the next one.

Record what you actually observe: the starting state, cards selected, feedback, response, and reset state. If one result differs from the contract, change one rule or prompt at a time and repeat the same route. Do not label a paper prediction as a pass from a playable build.

Carry the card contract 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 supports a general creation workflow only; it does not establish the exact card hand, persistent flags, conditional dialogue, or fictional Last Postcard rules.

Compare the result with the acceptance checks above. If card state or the disabled Question rule is missing, ask for one focused change and inspect it again. If the tool returns a story layout without the required state behavior, keep the rules as a design handoff for another build step rather than describing it as a working card-based narrative game.

Add another card only when it creates a new choice

Keep the first hand fixed until the three legal pairings, disabled state, reply, carry-over panel, and reset are easy to trace. Add a new card only when it changes what Iris can communicate or what Eli can respond to. A new illustration or a different wording alone does not need another state variable.

Once your own build behaves as intended, you can use SEELE's Free AI game maker to start shaping and reviewing your game idea. Keep the card contract beside each iteration so the story response stays tied to the choices that caused it.