Write AI Prompts for a Detective Game, One Fair Case at a Time

Good detective-game prompts do more than request a mysterious room and a handful of clues. They define what happened, what the player can inspect, which facts can be connected, and when the case may close. Start with one fixed case and make its conclusion traceable to evidence. The small museum mystery below is a fictional paper design: its rule route is worked through by hand, and no prompt run, playable build, or playtest is claimed.

Make the conclusion traceable to evidence

A fair first case gives the player observable facts that support one specific answer. Before writing dialogue or branching suspects, decide what happened, then make each clue reveal a piece of that truth. State what an inspection adds, which clue pairs count as links, what those links unlock, and what happens after a wrong answer.

This keeps a prompt from hiding the game inside a vague request such as “make the mystery clever.” A useful brief can be checked step by step: can the player find each clue, connect the right facts, understand why the answer follows, and recover from a mistaken choice?

Write the truth before writing clues

For a first case, set the truth privately before drafting evidence. In The Label in the Drying Room, a crescent-notched brass exhibit label is missing from its gallery display at 16:20. A restorer moved it to a padded drying rack in the studio at 16:02, before a roof leak began at 16:05, and forgot to update its location. The label is safe; no theft or malicious act occurred.

The map has three rooms—Gallery, Central Hall, and Restoration Studio—and all are visible from the start. Discovering evidence does not build or reveal rooms. Keeping the map fixed makes this a clue-linking prompt problem, not a map-generation mechanic.

The image is an illustrative game state for the written design. It does not show a SEELE interface or an observed build. The four evidence objects are an empty display outline, a leak notice, the restorer’s work card, and the padded rack with the matching notched label.

Define clues, links, and the conclusion gate

Use one state contract for the whole case. A clue enters the notebook once; looking at it again cannot inflate progress. A link counts only when both clues support the stated relation. The work card and leak notice establish the order of events; the work card and rack clue establish that the same object reached the destination.

The two links answer different questions. The work-card/leak pair proves that the move predates the leak. The work-card/rack pair matches the distinctive crescent notch and establishes where that same label rests. Reversed selection is allowed, but an unrelated pair or duplicate link never increases the count.

Use a three-prompt sequence

Separate checking the rules from requesting the build. First ask for an ambiguity report, then provide a small implementation contract, and save the third prompt for a specific observation after a real build exists. That sequence gives the tool less room to invent mechanics and gives you a clear standard for reviewing its answer.

Prompt 1: check the case contract

Design a deterministic point-and-click detective game called The Label in the Drying Room.
The player investigates one fictional museum case on a fixed, visible map: Gallery,
Central Hall, and Restoration Studio. All rooms are visible from the start.

Truth: A restorer moved a crescent-notched brass exhibit label from the gallery
display to the padded drying rack in the studio at 16:02. A roof leak began at
16:05. The label is safe on the rack; the restorer forgot to update its location.
No theft or malicious act occurred.

Evidence: (1) empty gallery mount, (2) leak notice saying the leak began at 16:05,
(3) work card saying the restorer moved the crescent-notched label to the studio
rack at 16:02, and (4) the same notched label resting on the padded rack.
State begins with cluesFound=0/4 and linksSolved=0/2. Each clue counts once.
The work-card/leak pair records one timeline link. The work-card/rack pair records
one identity-and-destination link. Both links are required to open exactly three
conclusions: (1) a visitor removed the label; (2) the label is still in the gallery;
(3) the restorer moved the label to the rack at 16:02 before the leak. Only choice 3
is correct. Choices 1 and 2 leave the case open and show a neutral hint. Restart clears
clues, links, and answer but keeps the fixed map and case text. Do not invent more options.

Return a rule table, exact clue text, state transitions, conclusion choices, and an
ambiguity list. Do not add rooms, suspects, random events, timers, scores, or hidden
clues. If a clue does not support the answer, name the gap instead of filling it in.

Read the returned rule sheet before requesting a playable slice. Check that the notch identifies the same object in the work card and rack clue, that 16:02 is before 16:05, and that the conclusion stays locked until both unique links exist. If the answer introduces a different timeline or a fourth room, resolve that conflict before building.

Prompt 2: request the minimum first case

Build one small first-person point-and-click museum mystery from the approved contract.
Show the fixed three-room map, a magnifying-glass inspect action, a four-slot clue notebook,
and an evidence board that connects the exact clue pairs. Use a restrained icon-only UI.

At the start, show 0/4 clues and 0/2 links. Inspecting each of the four named objects
adds one clue exactly once. Connecting work card to leak notice sets linksSolved to 1/2.
Connecting work card to matching crescent-notch rack clue sets it to 2/2 and opens
exactly these three conclusions: (1) a visitor removed the label; (2) the label is still
in the gallery; (3) the restorer moved the label to the rack at 16:02 before the leak.
Only choice 3 closes the case. Choices 1 and 2 show a neutral review hint without losing
evidence. Restart returns to 0/4 and 0/2 and keeps the fixed map. Add no other options.

Do not add dialogue choices, a discovery-built map, a campaign, score, timer, combat,
randomized evidence, theft, or an accusation animation. Make the inspected object, link
feedback, locked/unlocked conclusion board, and restart result visible. Do not claim or
simulate a real product interface.

This request names the player action, object, state change, expected feedback, and exclusions. It asks for an inspectable mystery, not merely a moody museum scene. If a result shows the label but does not let the player inspect or connect evidence, it has not met this proposed interaction contract.

Hand-resolve the case and plan checks

Before relying on a generated result, walk the written rules once by hand. The arithmetic is small, but it catches a common mystery-design error: unlocking the answer before the decisive evidence exists. This route is a calculation from the fictional rules, not a run of software.

The opening map and empty mount establish the missing-object problem; the clock and rain-drop facts establish order; the notch ties the work card to the object on the rack. The conclusion is therefore a consequence of visible clues, not a guess that depends on a hidden suspect or a narrator’s reveal.

Use a short acceptance list to check behavior when a real playable build is available. Expected behavior is not observed behavior: record actual actions and results separately, then revise only after a mismatch can be repeated.

Revise from one observation

When a real build exists, do not ask for a broad “make the mystery better” revision. Record one reproducible action, the expected state, and the observed state. Then ask for the smallest correction that repairs that mismatch without changing unrelated clue rules.

Observed action: [one exact inspect, link, answer, or restart action]
Starting state: [cluesFound and linksSolved]
Expected state: [what the approved rule contract says]
Observed state: [what the build actually showed]
Change requested: Fix only the rule or feedback causing this mismatch.
Preserve: The fixed three-room map, crescent-notch identity, 16:02/16:05 timeline,
the other valid link, wrong-answer recovery, and restart behavior.
Return: The changed rule, the matching state before/after, and a check for this case.
Do not claim the change works until the same action has been repeated and observed.

Without a build and a reproducible observation, this remains a template. The hand route can show whether the design is internally consistent; it cannot prove that a generated interaction follows it or that players understand the interface.

Hand the brief to a creation workspace

The current SEELE Free AI Game Maker page describes writing a game idea in plain English, reviewing a playable 2D or 3D result, and iterating in Workspace. That is a general creation and review workflow, not a guarantee that the sample’s clue notebook, evidence links, or conclusion gate will be implemented. Bring the rule contract as input, inspect the actual interaction against the state route, and review the selected model, available Koin balance, and displayed cost before each generation.

If the result lacks an inspect action, the two distinct link responses, a locked conclusion board, or reset behavior, ask for that missing state directly. If the selected target cannot represent a rule, keep the contract as a design handoff and decide what to simplify. Do not treat a visual mockup or a plausible scene as proof of playable logic.

Start with one fair case

Fix the truth, name four observable clues, require two unique evidence links, and open conclusions only when those links support one answer. Use the hand-resolved route to check the design, then compare a real build with it before calling anything tested. When you are ready to shape a small game idea and inspect the result, open the Free AI game maker and bring your own focused brief. Review the actual output and refine one mismatch at a time.