Write AI Prompts for a Branching Narrative Game

A branching narrative game needs a state model before it needs more dialogue. Name the scenes, the choices that change persistent variables, the conditions that unlock later actions, and the endings those conditions produce. Then request one small story slice and check every reachable state combination. The prompts below use exactly two optional preparation actions, two Boolean flags, and one final interaction to resolve them.

The Last Light at Orison Observatory is an original fictional teaching design. Its mountain observatory, action slots, story flags, relay operations, and endings are written examples; they have not been built or tested. Use the graph as a template for your own idea, not as a report of an existing or tested game.

Map the choices before writing the scene

Start by drawing a small graph. A node is a scene or decision point; an edge is an action that moves the player to another node; a state variable remembers something that later changes an option or outcome. For each choice, record the starting value, the guard that allows it, the action’s effect, the next scene, and the feedback the player sees.

Dialogue can make two routes sound different while both lead to the same state. A graph exposes that problem early: if an edge never changes state, opens a new choice, or changes the ending, decide whether it is flavor or a consequential branch. Keep flavor if it adds character, but do not rely on wording alone to prove that a choice matters.

This example has a small, deliberate structure: enter the observatory, spend two preparation slots, return to one shared relay room, and resolve the flags in a final Commit. Rejoining at the relay keeps the story compact; the flags carry the meaningful differences forward.

Define two choices and four reachable outcomes

The player starts with exactly two optional action slots before the storm closes the access bridge. In either slot, choose Archive, Help, or Wait. Archive and Help each cost one slot and can each be chosen at most once. Wait consumes a slot without changing story state. Either order is allowed, so both preparations can be completed before the player returns to the relay room.

These rules make four flag combinations reachable: neither preparation, Archive only, Help only, and both. Wait is what allows a player to leave a slot unused without silently forcing a branch. The two guards prevent duplicate preparation, while allowing Archive then Help or Help then Archive. Return to the same relay scene after each slot so the later outcomes depend on state, not on an unreachable route.

At the relay, “repeat checksum” is enabled only when `logFound` is true, and “request manual retune” is enabled only when `keeperTrust` is true. An unavailable option stays visible but disabled with a short reason; attempting it changes nothing. There are no extra flags for relay substeps and no separate action budget. One final Commit resolves the operations represented by the existing flags, then transmits.

The ending follows directly from the two preparation flags:

The both-true case matters because one Commit must complete both enabled operations, in order, before transmission. A tempting shortcut is to introduce flags such as `checksumDone` or `retuneDone`; that would add hidden state the player and reviewer must track. Here the preparation flags are sufficient: they control which operations Commit resolves. The table is a paper model, not evidence that a playable build follows it.

Ask for a graph, one slice, then a route audit

Separate the prompt jobs. First request a state contract that names every route and guard. Next ask for one compact playable slice, or a structured design handoff if the chosen tool cannot represent the required state. Finally request an audit that enumerates all combinations without inventing observations. This keeps a branching narrative game prompt tied to transitions a creator can inspect.

Prompt 1: return the story graph

Design a branching narrative game slice for The Last Light at Orison Observatory.
This is a fictional concept, not a built or tested game.

The player has exactly two optional preparation-action slots before a storm
closes the bridge. In either slot, the only choices are Archive, Help, or Wait.
Archive costs one slot, can be chosen once, and sets logFound=true. Help costs
one slot, can be chosen once, and sets keeperTrust=true. Wait costs one slot
and changes neither flag. Either order is allowed; the player may choose both,
only one, or neither. Return to the same relay room after the preparation slots.

In the relay, enable “repeat checksum” only if logFound is true and “request
manual retune” only if keeperTrust is true. Keep unavailable actions visible
but disabled with an accurate reason; an attempted unavailable action changes
nothing. Add no relay-completion flags and no extra relay action budget.
If at least one flag is true, one final Commit resolves the operations allowed
by those flags in this order: checksum if logFound, manual retune if keeperTrust,
then transmit. If neither flag is true, Commit is unavailable and “take shelter”
ends the story with no transmission.

Return a node/edge table, starting state, guard and effect for every choice,
visible feedback, reset state, and ending table for all four flag combinations.
List any rule that is still ambiguous. Do not add routes, flags, or endings.

This asks for a complete graph contract, not long prose. Check that Wait can fill either slot, that both optional actions can be reached in either order, and that the relay returns to one shared state. If the answer leaves the “neither” case unreachable or adds a separate relay-step flag, correct the contract before requesting dialogue or art.

Prompt 2: request one playable story slice

Build one compact narrative-game slice from the approved state contract below.
Show the observatory entry, the Archive scene, the Help scene, a shared relay
room, and a take-shelter option for the neither-flags case.

Use exactly two optional preparation slots. In each slot, display Archive,
Help, and Wait. Disable Archive after logFound becomes true; disable Help after
keeperTrust becomes true. Keep the route order flexible. Show both flags in the
relay room and explain a disabled checksum or retune action without changing
state when attempted.

Provide one final Commit interaction, available only when at least one flag is
true. It must resolve checksum if logFound is true, then manual retune if
keeperTrust is true, then transmit. Do not ask for extra completion flags or a
separate relay action budget. Route the ending from the two existing flags only.
Include the no-transmission shelter ending when both flags are false.

Show the initial state, every scene transition, the change to each flag,
available and unavailable actions, result feedback, and reset behavior. Keep
dialogue short enough that the state changes remain clear. If the target tool
cannot represent these conditions or interactions, return a design handoff
instead of presenting a noninteractive story as a playable branching game.

Ask for a state display alongside dialogue. For this slice, readers need to see which preparations are complete, why an operation is disabled, and what Commit actually does. The prompt states requirements; it does not establish that a particular game maker implements them. Compare the returned interaction with the contract rather than assuming that branching dialogue equals persistent state.

Prompt 3: enumerate routes and compare actual observations

Audit the story graph against the state contract. Do not invent playtest results.

Enumerate these four starting relay states:
1. logFound=false, keeperTrust=false
2. logFound=true, keeperTrust=false
3. logFound=false, keeperTrust=true
4. logFound=true, keeperTrust=true

For each, report whether Commit is available, which operation(s) it resolves,
their order, whether transmission occurs, and the ending. Confirm that two
preparation slots can reach every combination using Archive, Help, or Wait;
that Archive and Help cannot each be chosen twice; and that a disabled action
changes nothing. Confirm reset clears both flags and restores both slots.

If I provide observed build behavior, compare it step by step with these
expected states and name the first mismatch. If I provide no observations,
return only a proposed checklist and mark results unobserved. Do not claim a
route passed unless the supplied observation demonstrates it.

The audit prompt tells the model what evidence is missing. Before you test anything, it can return expected transitions and a checklist. After a real observation, you can compare that sequence with the paper model and ask for one bounded correction; it cannot truthfully certify behavior from the prompt alone.

Find dead ends and choices that do not matter

Walk the graph from the initial state and verify that each combination has a legal path. Then check whether the resulting scene shows the consequence that the state table predicts. The observatory’s intended both-true ending is one possible result of the written rules, not a measured outcome.

Use the earliest mismatch to decide what to change. If an outcome cannot be reached, fix the graph or slot semantics before editing the ending dialogue. If the state is correct but a disabled option is confusing, improve the reason shown next to it. If all four transitions match the contract, then add story texture without changing the tested state model.

Move a written graph into a first creation pass

Once the graph is coherent, a focused natural-language brief can be a starting point for exploring a game idea. SEELE’s current Free AI Game Maker page describes plain-English game descriptions, review of playable 2D or 3D results, iteration in Workspace, and checking displayed generation costs and account options. That general workflow does not confirm persistent story flags, conditional narrative actions, or this observatory design.

Carry the node/edge table and the four-row ending matrix into the creation request. Then inspect the actual returned state, choices, feedback, and restart behavior. If a specific condition is missing, ask for that condition to be represented and check it again. If the chosen workflow cannot show persistent flags, keep the graph as a design handoff and evaluate it in a suitable tool before describing it as playable.

Add story depth after the graph holds together

Do not add a third flag just to create more dialogue. First make sure the two current flags can combine in all four ways, the relay options respond to them, Commit follows its defined order, and reset restores the opening state. Then add one scene or variable only when it creates a choice the existing graph cannot express. This keeps new branches tied to consequences instead of multiplying routes that read differently but play the same.

When your own story contract is ready, take the compact graph into the Free AI game maker, inspect what the result actually represents, and revise one state transition at a time.