Build an Asymmetric Co-Op Game With AI Prompts

An asymmetric co-op game works when players hold different information and each has an action the other cannot take. Start with one shared goal, define what each role can see and change, and make the result visible to both. Then ask for one small encounter and a way to inspect its rules before you expand it.

The prompts below use Lantern Relay, an original cave-rescue teaching concept for two local participants communicating by voice. It has not been built or tested. Its Keeper reads a route map and changes one remote shutter; its Delver turns one physical mirror and reports the beam segment they can see. Those are design assumptions for the example, not claims about SEELE features.

Start with the dependency, not the character classes

Before you name roles, complete one sentence: “We reach [shared goal] only after one player uses [private information] to take [action], and the other uses [different information] to take [different action].” If either action can disappear without changing the solution, the roles are different in name but not yet interdependent.

For an asymmetric co-op game prompt, write the shared goal first, then define an information boundary and an exclusive action for each role. Include the moment when one player needs the other’s report, plus feedback that confirms what changed. This keeps “different abilities” connected to an actual puzzle loop instead of a pair of unrelated character descriptions.

One documented example of split information appears in the official remote-play guide for Keep Talking and Nobody Explodes: the Defuser sees the bomb but not the manual, while the Experts use the manual without seeing the bomb. Lantern Relay uses a different setting and rules; the useful design question is simply what information must cross between roles before an action can succeed.

Give both roles a necessary job

In Lantern Relay, the Keeper knows the fixed cave route and the remote shutter options, but cannot see which beam segment is currently lit. The Delver sees the live beam and one physical mirror, but cannot see the route map or operate the shutter. The Delver adjusts that mirror and calls out the observed segment. The Keeper uses the report to select the matching shutter setting. Only then can the beam reach the rescue gate.

This is a role contract: each side has private information, an action tied to that information, and a reason to communicate. Before writing a full prompt, fill in the table with nouns and verbs a player can point to. “The Scout is fast” is not enough; “the Scout sees the pressure plate and can hold it down” gives the other role a specific dependency to use.

The table also reveals a common failure: if the Keeper’s map already shows the live beam segment, the Delver’s report carries no new information. If the Delver can reach the goal by adjusting the mirror alone, the Keeper is an observer. Close those gaps in the rules before adding dialogue, extra rooms, or character progression.

Use three prompts to move from rules to one room

Keep the requests separate so each answer has one job. First define the role contract. Next request a compact playable interaction or, if the chosen tool cannot support the required controls, a structured design handoff. Finally ask for an evaluation plan that waits for your real observations. The following AI prompts for an asymmetric co-op game are templates: replace the bracketed fields and keep the example’s untested status in mind.

Prompt 1: define the role contract

Design a co-op game concept for exactly [player count] players.
Shared goal: [one sentence describing what the group must accomplish].
Communication assumption: [how players exchange information].

For each role, state:
- what information only that role can observe;
- which action only that role can perform;
- what state changes after that action;
- what signal the role can report to the others.

Show the dependency in order: information, report, partner decision,
action, and shared feedback. Give one short encounter with a starting
state, valid actions, success condition, failure condition, and reset state.
Then remove each role in turn and explain whether the encounter remains
solvable. If a role can be removed without changing the solution, revise
the dependency. Do not add rooms, progression, or extra systems yet.

Return a role table, one state-transition table, and any rule that still
needs a design decision. Do not claim that a game has been built or tested.

This first request asks for a design contract, not a polished world. Check that every role has something to notice, something to do, and a report that affects the partner’s next decision. If the answer invents an implementation detail you have not chosen, leave it as an open decision rather than treating it as settled behavior.

Prompt 2: scope the first room

Create a design for one cave-rescue puzzle room called Lantern Relay.
This is a fictional teaching concept for two local participants who
communicate by voice. This prompt has not been run or tested.

Shared objective: route the beacon to the rescue gate.
Keeper view and action: the Keeper sees a fixed route map and the remote
shutter options, but not the live cave view or current beam segment. The
Keeper alone can change one remote shutter setting.
Delver view and action: the Delver sees the live beam and one physical
mirror, but not the route map or remote shutter state. The Delver alone
can rotate that mirror and report which beam segment is lit.
The route map gives possible paths, while the Delver's report identifies
the current beam segment. The Keeper needs that report to choose the
matching shutter. Both the mirror and shutter must be set correctly before
the beam reaches the rescue gate.

Show the start state, each legal action, invalid-action feedback, the
success state, a failure or timeout state, and a reset to the start. Keep
one physical mirror and one remote shutter. Do not add combat, inventory,
campaign progression, online networking, voice-chat software, or a second
room. Keep each role's information separate in the proposed views.

If the available build tool cannot represent two local inputs or separate
views, return a structured mechanic and interface handoff instead of
presenting the concept as playable. Flag any mechanic that needs a decision.
Return a state table and a short acceptance checklist.

After the response, read the state table before judging its art direction. Ask whether a mistaken shutter selection produces a visible, recoverable result; whether the Delver can report a beam state without seeing the Keeper’s map; and whether the Keeper can use the report to choose a meaningful next action. If the tool or runtime cannot express those constraints, the design handoff is still useful, but it is not evidence of a working co-op build.

Prompt 3: evaluate observations you actually collect

Review the observations I provide for this one-room co-op design.
Do not invent player actions, playtest notes, or successful outcomes.

Design contract: [paste the agreed role table and starting state].
Observed sequence: [paste only actions and responses you recorded].
Expected result: [state the rule-based outcome].
Actual result: [state what the players or build showed].
First point of confusion: [quote or describe the earliest ambiguity].

Compare the observed sequence with the contract one step at a time.
Name the first mismatch, explain which rule or signal it concerns, and
suggest one bounded revision. Preserve the room, roles, and all unrelated
rules. If the observation is missing or ambiguous, ask what to record next.
Do not say the design passed unless the supplied observation supports it.
Return the changed line, what should now be observable, and one follow-up
check for a future session.

The inputs matter more than the word “evaluate.” Without an observed sequence, the model can only suggest a design check, not report how players behaved. When you do collect observations, include the intended result and the first confusing moment; that lets a revision target the smallest mismatch instead of rewriting both roles.

Check whether both players matter

A role table describes intent; the room still needs observable checks. Walk through the encounter from its starting state and ask what each player knows at every step. The checks below are a proposed review method for your own design, not results from a Lantern Relay playtest.

Make one change at a time. If the report is ambiguous, clarify the signal before adding a hint system. If a role is idle, reduce the number of steps between its observations and its actions. If the goal is hard to read, improve the beam or gate feedback before adding another puzzle. A narrow revision preserves the parts you still want to evaluate.

Revise from a real observation

Once you can observe a design with players, write down four things: the action, the expected result, the actual result, and where someone first hesitated or misunderstood. Avoid conclusions such as “the Keeper was boring” without a moment to inspect. A note like “the Keeper could choose either shutter before the Delver reported the beam” points to a specific dependency that can be changed and checked again.

Keep the rest of the room fixed while you revise that rule. Then repeat the same starting state and see whether the report changes the partner’s decision. This does not prove a design is balanced or broadly usable; it gives you a traceable next question. Until you have actual observations, phrase the issue as a risk to check, not a result of a playtest.

Take a focused brief into a creation workflow

After the paper contract is coherent, you can try the focused idea in a game-creation workflow and inspect what it produces. SEELE’s current Free AI game maker page describes plain-English game descriptions, review of playable 2D or 3D results, and iteration in Workspace. It also tells users to check displayed generation costs and account options. Those general workflow details do not verify local co-op, two simultaneous local inputs, voice communication, or this fictional room.

Carry the shared goal, first player action, scene states, and feedback into your request. Then inspect whether the result actually represents each control and role before you treat it as a co-op prototype. If the available workflow cannot express two player views or inputs, use its output as a design starting point and plan a suitable implementation separately. For the puzzle itself, the AI puzzle game maker page is relevant to framing one rule, visible clue, solving action, and outcome; it does not establish multiplayer support.

A good first result is the smallest thing you can inspect against your contract. Keep the room only if each role contributes information or action, invalid choices explain themselves, and the success state visibly follows from both roles. If those checks are not met, revise one rule or request a design handoff before expanding to a second room.