Write AI Prompts for a Co-Op Escape-Room Game That Requires Teamwork

Make both players necessary to the first puzzle

A co-op escape-room prompt should say what each player must do and how their actions combine. Start with one shared clue, two player-bound consoles, and one synchronized confirmation rule. Then define what a correct pair changes, what a mismatch resets, and how the exit opens. A co-op label alone does not prevent one player from solving the room for both.

Bellglass Vault is an original teaching design for that prompt sequence. It has one room, one public three-symbol clue, and two local players at separate consoles. The rule trace below is hand-resolved; no prompt was run and no playable or tested build was supplied.

Before describing brasswork or atmosphere, state the cooperative contract:

This contract gives each player a necessary action without hiding information from the partner. The mural is public, so cooperation comes from separate console ownership and timing rather than an unseen clue only one player can read. The local keyboard bindings below are proposed design inputs; they are not evidence that a specific product or build supports dual controls.

Define console ownership and the shared clue

Give the players different controls for their assigned consoles, and say when a dial locks. Player A cycles the west dial with A/D and confirms with F. Player B cycles the east dial with the left/right arrows and confirms with Right Shift. Each dial offers crescent, wave, or star. Both players read the same mural order; the consoles do not contain private clues.

On a confirmation, lock that player's symbol and start a 3-second timer. When the partner confirms, resolve the pair immediately:

Reset only the active attempt after a failure. Do not erase a lamp from a previously solved symbol, charge a life, or start a separate room timer: none of those rules belong to this example. Stating the recovery in the same prompt as the success path prevents the game request from inventing a different penalty.

Show the matching action and its feedback

The interaction is a short state loop: both consoles start neutral; the first confirmation locks one dial and starts the timer; the second confirmation either advances the clue or resets the attempt. After the first correct pair, the mural's next target becomes wave and the first of three door lamps stays lit.

One hand-resolved example: Player A confirms crescent at t=0. Player B confirms crescent at t=2.4, inside the three-second window, so lamp one lights and both dials reset for wave. On the wave step, Player A confirms wave at t=0 while Player B confirms crescent at t=1.0. The mismatch resets both dials; lamp one remains lit and wave remains the target. Both may retry wave. This is arithmetic over proposed rules, not a user or playtest result.

The mechanism image shows a different moment: wave is the active target, Player A has staged the matching symbol and is waiting, and Player B has selected wave but has not confirmed. Only the first door lamp is lit. If Player B confirms wave before the window ends, step two succeeds; a late or different confirmation resets just this attempt.

Keep the feedback tied to state: a lamp lights only after a correct pair; a mismatch leaves the current lamp and clue step unchanged; a timeout clears the pending selection. Avoid adding a countdown to the whole room when only the pair window is part of the design.

Prompt for one room in deliberate stages

Ask for the rule table before requesting the finished room. Then request one local two-player puzzle with the three-symbol sequence, separated consoles, confirmation window, recovery, and exit. Do not combine the prompt with an inventory, campaign, hidden-role clues, or online networking. The templates below are design prompts; they have not been run in a game maker.

Stage 1: return the rule contract

Design a one-room cooperative escape puzzle for two local players sharing one screen. Before describing art or adding features, return a state table with: player count and mode, each player's assigned console and controls, the clue both players can see, the current symbol step, when the confirmation timer begins, the exact success condition, mismatch behavior, timeout behavior, exit condition, and restart state.

Use one public mural that reads crescent, wave, star. Player A owns the west console and cycles its dial with A/D, confirming with F. Player B owns the east console and cycles with left/right arrows, confirming with Right Shift. Each console offers the same three symbols. A confirmation locks that dial and starts a 3-second window. Advance only when both players confirm the same correct current symbol within that window. Any mismatch, shared wrong symbol, or timeout unlocks both dials, clears the timer, and keeps the current step. After three correct pairs, light all three door lamps and open the exit; the room is complete only when both players cross. Restart clears all lamps, returns to crescent, unlocks both dials, and resets them to neutral.

Do not add private clues, lives, a room-wide timer, online play, or a penalty not stated here. Identify any control or state conflict instead of silently changing the contract.

Stage 2: request a focused prototype

Create a small, single-room, same-screen local co-op escape-room prototype from the approved contract. Place two player avatars at clearly separate west and east brass consoles, with the same crescent → wave → star mural visible from both positions and one sealed exit with three lamps.

Bind Player A only to the west console: A/D cycles its three glyphs and F confirms. Bind Player B only to the east console: left/right arrows cycle its glyphs and Right Shift confirms. Each confirmation locks that selection and starts the 3-second pair window if it is the first. The second confirmation succeeds only when it matches both the partner's selection and the current mural glyph before time expires. Then light exactly the next door lamp, advance one symbol, unlock both consoles, and reset both dials to neutral.

On a mismatch, both players confirming the same wrong glyph, or a 3-second timeout, clear the pending selections and timer but retain the current clue step and already-lit lamps. Do not subtract lives or advance the room. After the star pair, light the third lamp and open the exit; require both players to cross to finish. Restart returns to crescent with all lamps dark and both dials neutral.

Show the current shared target, each selected glyph, which console is waiting, the pair timer, and the door lamps using readable in-world feedback without relying on generated words. Return the control mapping and expected transitions for crescent, wave, star, mismatch, timeout, final exit, and restart. Keep the puzzle to this room and these rules. Do not add networking or claim that the controls are supported until the actual result is inspected.

Stage 3: revise only a failed pair check

If an actual build later fails a check, supply its exact action sequence and observed state. Then ask for one bounded correction. For example, if a real result advances after one confirmation, revise the pair condition and repeat that sequence; do not invent tester feedback or change the clue order and timer at the same time.

Verify both players and the final exit

Use acceptance cases that distinguish one-player progress from a genuine pair. These are planned checks, not passed results. For each real attempt, note the active symbol, who confirmed first, both selected symbols, the visible timer, the lamp count, and the next state.

On a real accessible build, check that both players can read the same clue, the assigned controls cannot be swapped, and a one-sided confirmation never lights a door lamp. If the generated result cannot represent separate local inputs, record that limitation instead of calling the interaction playable.

The outcome illustration corresponds to the hand-resolved goal only: crescent, wave, and star have each been confirmed in pairs, all three lamps are lit, and both explorers cross the open exit. It is not a screenshot of a generated escape room.

Use the multiplayer page to scope the scenario

SEELE's current Multiplayer Game Maker page describes planning a short scenario around player count and mode, a shared objective, player roles, and interaction rules. It recommends checking whether each player has a useful action and whether the result is clear. That makes it relevant for framing Bellglass Vault as a small co-op scenario; it does not establish that these console bindings or a generated local multiplayer room will work.

The same page states that online play still depends on implementation, networking, synchronization, hosting, and testing. Keep Bellglass Vault local and same-screen, and do not imply that a prompt handles those online requirements. SEELE’s general game-creation categories are broad; they do not document or guarantee this exact two-console interaction.

Bring the player count, common clue, console ownership, pair window, failure reset, and one acceptance question. Inspect the actual result and review its displayed generation cost before continuing. The planning page and prompt do not prove that the console controls or a playable co-op result are supported.

Add another room only after both players can finish this one

Write one shared clue, give each player a necessary action, and specify what a match, mismatch, timeout, and restart change. Keep the first prompt to one room. Add more content only after the actual result shows that both players can contribute and the exit follows the written state rules. Bellglass Vault remains a fictional hand-resolved design, not evidence of a generated or tested game.

Use the Multiplayer game maker to frame one short cooperative scenario, then inspect what the current result supports.

Frequently asked questions

What makes an escape-room puzzle genuinely cooperative?

Each player needs a necessary action, and the rule should say how the actions combine. In Bellglass Vault, each player owns a separate console and the door advances only when both confirm the correct public symbol within the same window. The example is a design choice, not a universal definition or a tested claim about what players prefer.

Should co-op players have different clues?

Not always. A shared clue can still require cooperation when players have separate controls or must coordinate timing. Bellglass Vault gives both players the same mural and assigns each one console. Use private clues only when the design depends on players sharing information, and state exactly how each clue changes a decision.

What should happen after one player confirms late?

Define the timeout before prompting. This example clears both pending selections, keeps the same clue step, and lets the pair retry without losing a life. A different design could use another consequence, but the prompt and acceptance checks must agree about when the timer starts and whether old progress remains.

Can an AI prompt guarantee online co-op?

No. A prompt can describe the player count, shared goal, and interactions, but it does not prove that networking, synchronization, hosting, or separate-device play has been implemented. SEELE's current multiplayer page also identifies those online requirements as implementation and testing work. Inspect and test any actual networked result before making a capability claim.

What should I test before adding more rooms?

Check that each console responds only to its assigned player, a correct pair advances exactly one clue, a mismatch and timeout recover identically, previous lamps remain lit, and restart clears the room. Then verify that all three correct pairs open the exit and that both players must cross. Until a real build is available, keep these as planned checks.