A social-deduction game prompt needs an information contract before it needs screens: define what each player knows, what a public clue narrows, how votes resolve, and what every ending does. Then ask for a build in small states and check it against explicit cases. Harbor Relay, the five-seat example in this guide, is an original fictional design worked through by hand. Its prompt templates have not been run; no generated build, playable sample, or playtest is being reported. You can reuse the visibility rules and acceptance checks without assuming that a creation tool supports every private-information detail. If you later build it, use the cases to inspect each transition.
Start with the information loop
Before asking an AI game maker for a social-deduction game, describe the loop that makes suspicion fair: assign hidden roles, create a public event, limit what the clue reveals, let players discuss, collect private votes, and resolve the win condition. The prompt should state both what the game shows and what it must keep secret.
A short contract prevents a common design gap: the story may say that players discover a culprit, while the rules never explain how a clue limits suspects or how a tie ends. Make those decisions first. Then use separate prompts for rule consistency, a first build, and one focused revision. The Harbor Relay walkthrough below is a paper design example, not evidence that any prompt has produced or tested this game.
Lock the rules before the interface
Harbor Relay uses one incident and one vote. Its public badge groups are fixed before a single Saboteur and four Keepers are assigned at random. Because the clue names a badge group instead of a seat, players receive useful evidence without learning the role directly.
| Phase | Private information | Public information and resolution |
|---|---|---|
| Setup | One Saboteur and four Keeper roles are shuffled among five seats; each role is shown privately in turn. | A and B have Crescent badges; C, D, and E have Spoke badges. The badges are public before roles are assigned. |
| Role handoff | The assigned player reads the role, taps Hide, then passes the device. | Role identity never appears in the shared incident log. |
| One outage | The Saboteur privately chooses a relay terminal and triggers the incident. | The log names the affected terminal and the Saboteur's badge group, Crescent or Spoke, but never the seat. |
| Discussion | No new role information is revealed. | Players have 90 seconds to discuss the log and make spoken claims. The game does not generate claims or decide whether they are true. |
| Secret ballot | Each active player privately votes for one seat. | No partial vote tally is shown. Once voting is resolved, a strict majority means more than half of active votes. |
| Verdict | The ejected seat's role is revealed only after a strict-majority choice. | Keepers win only if they eject the Saboteur. The Saboteur wins after a wrong ejection or a no-verdict vote. |
| Restart | All private roles are discarded. | Clear the assignment, incident, discussion timer, and votes; return to setup. There is no second incident or hidden tie-break. |
The handoff is deliberately small: one player sees one role, hides it, and passes the device. It describes local pass-and-play behavior, not online multiplayer or a security guarantee. An invalid target, duplicate ballot, or attempt to reveal a role before the vote resolves must not silently change the game state.
Prompt the clue and discussion loop
The badge trace creates two possible candidate sets. A Crescent trace points to A and B; a Spoke trace points to C, D, and E. The Saboteur is always in the named group, and every group contains at least one other seat. This is a deliberate information limit: the clue narrows suspicion without naming a player.
For a paper check, set B as the Saboteur. A Crescent incident leaves A and B plausible. The log says “Crescent” and identifies the affected terminal, but it does not show B’s seat or role. The same rule works for any random assignment: the candidate group is derived from the Saboteur’s public badge, not from a second secret clue.
Use a rules-contract prompt before asking for visuals. It should make the model repeat the privacy boundary and the win logic so omissions are visible before implementation:
Design a fictional five-seat social-deduction game called Harbor Relay from this exact contract. Seats A and B have public Crescent badges; C, D, and E have public Spoke badges. Randomly assign one Saboteur and four Keepers. Show each role privately in turn and require Hide before passing the device. The Saboteur chooses one relay terminal and causes one outage. The public log shows the terminal and the Saboteur's badge group, never the seat or role. Crescent creates candidates A/B; Spoke creates candidates C/D/E. The clue must include the Saboteur and at least one other seat, with no direct identity reveal. Allow 90 seconds of spoken player discussion; do not generate or adjudicate claims. Each active player submits one private vote for a seat. More than half of active votes ejects that seat and reveals its role; a tie or no strict majority is no verdict. Keepers win only by ejecting the Saboteur; the Saboteur wins after a wrong ejection or no verdict. There is one incident and one vote only. Restart clears roles, incident, timer, and votes. Invalid targets, duplicate votes, and early reveals do not change state. Return a phase table separating private and public information, list contradictions or missing decisions, and add no mechanics.Read the returned contract as a checklist, not as proof of a working game. If it changes the clue into a seat reveal, adds another round, or invents a tie-break, point to that line and ask for a correction before using a build prompt.
Prompt a first build one state at a time
Once the information contract is stable, describe the smallest interface that can expose it. A local pass-and-play prototype needs a role reveal and Hide handoff, one incident action, a public log, discussion timer, private ballots, a verdict, and a restart. Ask for clear state changes and accessible touch and keyboard controls, but do not assume the tool will implement the secrecy rules exactly.
Keep the build prompt literal. Avoid adding character abilities, extra clues, or online rooms just because they are common in the genre. The goal is to inspect whether this particular information loop remains understandable:
Create a simple 2D tabletop-style, one-device pass-and-play prototype for the fictional Harbor Relay rules contract. Implement only five seats, one randomly assigned Saboteur, four Keepers, the single outage, the public badge-group clue, 90 seconds of player discussion, one secret vote, a verdict, and restart. Show each role only to the current player, hide it before handing off, and keep roles out of the public log. During discussion, show the affected terminal and badge group without identifying the Saboteur. Keep vote choices private until every active player has submitted one valid vote. Resolve a strict majority as more than half of active votes; otherwise show no verdict. Reveal the ejected role only after resolution. Include visible feedback for all state changes, clear invalid-input handling, readable contrast, and touch and keyboard support. Do not add network multiplayer, computer-generated player claims, extra clues, rounds, scores, or a tie-break. Return the state flow and a list of behaviors that still need verification.This asks for a build attempt; it does not say one has been made. Review each screen transition as a separate question: who can see the role now, what is public, what vote state is hidden, and which exact condition ends the round?
Check the result with acceptance cases
Use observable cases rather than a general “looks right” test. With five active votes, a strict majority requires at least three because more than half of five is greater than 2.5. In the hand example, three votes for B eject the Saboteur and win for Keepers. Three votes for A eject an innocent and win for the Saboteur. A 2–2–1 split has no strict majority, so the Saboteur wins by no verdict.
| Case | Setup | Expected visible result | Failure signal |
|---|---|---|---|
| Role assignment | Start a new round with five seats. | Exactly one Saboteur and four Keepers; each role is shown only in its private handoff. | Wrong role count, or a role appears in the public log. |
| Crescent clue | Paper-set B as Saboteur and trigger an outage. | The log shows the terminal and Crescent; A/B remain plausible, with no seat named. | The log identifies B or excludes A. |
| Spoke clue | Paper-set C as Saboteur and trigger an outage. | The log shows the terminal and Spoke; C/D/E remain plausible. | The log names a seat or shows a candidate outside the group. |
| Keeper win | Five ballots; three or more identify B when B is the Saboteur. | B is ejected, the role appears after resolution, and Keepers win. | The role is revealed early or the wrong team wins. |
| Wrong ejection | Five ballots; three or more identify A while B is the Saboteur. | A is ejected and the Saboteur wins. | A wrong ejection is treated as a Keeper win. |
| Tie/no verdict | Cast votes as 2–2–1, so no seat receives more than half. | No one is ejected; the Saboteur wins by no verdict. | A hidden tie-break selects a seat or the round remains unresolved. |
| Invalid action and reset | Submit a duplicate ballot or invalid target, try a premature reveal, then restart. | Invalid actions do not alter state; restart returns to setup and clears roles, incident, timer, and votes. | A duplicate is counted, a role leaks, or prior state survives restart. |
These are acceptance cases for a future build, not reported test results. The outcome illustration below is also a concept: it shows a decisive three-vote choice and a role card turned after voting, not a software result.
Make one focused revision
If an acceptance case fails, name the case and the exact observed state. Do not ask for a broad polish pass that can change rules which already work. For example, if a role appears in the incident log, request a change to public-state serialization while preserving the role handoff, candidate group, ballot, and restart rules.
Acceptance case: [name the failed case]. Expected: [state and visible result]. Observed: [what the prototype showed]. Change only the rule or transition needed to fix this case. Preserve every passing behavior, including role privacy, the one-incident limit, the candidate group, strict-majority resolution, no-verdict behavior, and restart. Return the revised state mapping and identify which acceptance cases must be checked again. Do not claim the repair is verified until those checks are run.Keep the original case list beside each revision. A change is ready for another review only when you can state what changed, which prior behaviors were preserved, and what evidence would confirm the new state.
Use a game-creation workflow for the next step
SEELE’s current Free AI Game Maker page describes plain-English game input, a playable 2D or 3D first version, browser testing, and refinement with follow-up prompts. It advertises free Koins and says to review the displayed cost before each generation; its cost FAQ says to check the selected model, Koin balance, and displayed cost in Workspace. These are general workflow facts. The page does not document Harbor Relay, private hot-seat roles, or this social-deduction loop.
If you explore the idea in a game maker, start with the rule contract and acceptance list. Inspect what comes back for role visibility, clue scope, ballot privacy, and every terminal condition. Treat the result as something to verify, not a guarantee that a prompt preserved all details.
When you are ready to shape your own game brief, open the Free AI game maker. The Harbor Relay example and images on this page are fictional design material; they are not SEELE output or a claim of tested gameplay.
Social-deduction game prompt FAQ
What should I specify first in a social-deduction prompt?
Start with the information contract: who receives each hidden role, what becomes public, what a clue can and cannot reveal, and how votes resolve. Then define the win, tie, and restart states. A visual theme can come later; if the prompt does not define what players know at each phase, attractive screens cannot make the deduction loop consistent.
How can I keep a clue useful without making it decisive?
List the candidate set the clue produces and confirm that it always contains the hidden role plus at least one other plausible player. Harbor Relay’s badge trace yields two or three candidates depending on the group. That is a design choice for this example, not a fairness formula for every game; check what the clue reveals at each stage.
Does pass-and-play mean online multiplayer?
No. Pass-and-play means several people take turns using one device, with the screen hidden between private turns. It says nothing about networking, accounts, matchmaking, or remote play. Harbor Relay uses that local format as a fictional design constraint, and the product page does not promise that it implements this private-role handoff.
What happens if a vote is tied?
Choose the tie rule before prompting for a build. Harbor Relay has no hidden tiebreak: any vote with no strict majority produces no verdict, and the Saboteur wins. Another game could restart discussion or allow a runoff, but that would be a different rule and should appear explicitly in its contract and acceptance cases.
How do I check a first build?
Run one small case for each information boundary and terminal condition: role reveal, public clue, private ballot, correct ejection, wrong ejection, no verdict, invalid input, and restart. Record the setup and expected visible result before inspecting a build. If you have not run those checks, describe the cases as a plan rather than a tested result.
