Plan a Co-op Platformer with a Clear Prompt Sequence

A co-op platformer needs a clear shared condition: what each player does, when their actions count together, and what happens if one misses. Define that small loop before asking for a long level. Twinspan Relay below is an original paper-design example, not an existing build or playtest. Its 1.5-second pairing window and 4-second bridge are chosen to make the rules easy to inspect; they are not measured balance values.

Define the co-op contract

Write the action loop as a sequence of states, not a mood such as “make the players cooperate.” Twinspan Relay gives both couriers the same run and jump moves. At each relay, Player A must touch the blue pad and Player B the amber pad. The first correct landing starts a shared timer. If the second player reaches the matching pad in time, a short bridge appears; both players must cross before it retracts. The checkpoint moves forward only when both arrive.

This contract also says what failure looks like. A wrong pad, fall, or expired timer returns both players to their last shared checkpoint and clears the bridge. Neither player is left waiting alone or loses a life in this teaching design. If one reaches the checkpoint while the other is still crossing, it stays inactive until both are present. That keeps progress attached to the team state.

The table makes timing and recovery visible to both players. Before adding scenery or extra mechanics, confirm that each row names a trigger, a state change, and a next state. If “the bridge opens” is the only described result, the prompt still needs to say when it closes and how the team recovers.

Prompt 1: write the shared rules

Use a short contract prompt to settle the player count, screen scope, joint goal, and recovery rule. Ask for any unresolved assumptions instead of allowing a builder to fill gaps silently.

Plan a two-player local co-op platformer for one shared screen. Both players have the same run and jump moves; neither has a special ability. The shared goal is to cross three paired landing relays and reach an exit together.

For each relay, Player A must land on the blue pad and Player B on the amber pad. The first correct landing starts a 1.5-second pairing window. If the second player lands on their assigned pad before it expires, form one continuous walkable bridge for 4 seconds. Both players must reach the next shared checkpoint before the bridge closes. A wrong pad, fall, missed pairing window, or bridge timeout returns both players to the last shared checkpoint and clears the active timer and bridge. The checkpoint advances only when both players are there. The exit opens only after both players reach their matching final pads. Restart returns both to the starting checkpoint and clears every timer.

Return a state table for both player positions, assigned pads, pairing timer, bridge timer, shared checkpoint, and exit state. List any remaining assumptions. Keep the plan local and same-screen; do not add online networking, asymmetric powers, lives, or random events.

This prompt is a design template, not a record of a run. It asks the builder to expose the state you need to inspect. If the resulting control scheme assigns different buttons to the two controllers, check that both still have the same actions and that instructions identify each player's input before the first gap.

Write the one-gap prompt

Turn the contract into one small encounter with a start, an interaction, and a recognizable checkpoint. Keep one pair of pads and one gap so a confusing result has fewer possible causes. Specify what players can see before the jump, how the first landing starts the clock, and how the bridge communicates its remaining time.

In the Twinspan example, the two pads glow in different colors and sit on opposite ledges. The first matching landing starts the 1.5-second window; the second matching landing forms the bridge. The temporary path should be wide enough to read as a route, while the checkpoint beyond it remains inactive until both couriers arrive.

Prompt 2: request one relay

Keep the first build request narrow. Ask for a reset and a visible status cue alongside the movement, because both are part of the co-op loop.

Create a small local two-player platformer prototype from this rule contract. Use one shared screen, two controllers, and the same run and jump abilities for both players. Build one reachable gap with a safe start ledge, one blue landing pad for Player A, one amber landing pad for Player B, and a shared checkpoint on the far side.

Show both players, their assigned pad colors, the 1.5-second pairing window after the first correct landing, and a clear indication of the 4-second bridge timer after both matching pads are occupied. The bridge must be a continuous walkable surface. Advance the checkpoint only after both players touch it before the bridge closes. If a player falls, lands on the wrong pad, arrives after the pairing window, or misses the bridge timer, return both players to the previous checkpoint and clear the active state. Add a restart that returns both players to the start.

Keep the camera wide enough to show both players and the full gap. Include a compact controls screen. Do not add other gaps, collectibles, enemy attacks, special powers, random events, or online play. State which of these rules are implemented and which remain unverified; do not assume a successful build from this request.

A good specification does not guarantee an implementation. If you use it with a build tool, inspect whether the status cue changes at each trigger and whether the second player can still act while the first waits. Save the actual prompt and build version before comparing later changes.

Extend the route only after the first relay

Once a real one-gap build has passed the same-player and opposite-player checks, extend the route without changing the core rule. Reuse the pad colors, timer, bridge duration, reset, and checkpoint behavior. Vary one geometric feature at a time, such as gap width or landing height, so a later failure is easier to locate.

The extension prompt should preserve these invariants and ask for a route summary that shows the active relay and checkpoint. Do not add a new ability just because a later gap is harder; first decide whether the challenge is meant to test timing, communication, or movement distance.

Prompt 3: add two more relays

Only after the one-gap version has been inspected against its acceptance checks, extend the same local co-op route with two more paired landing relays and a final exit. Preserve the same movement abilities, blue/amber pad assignment, 1.5-second pairing window, 4-second bridge, joint checkpoint rule, miss/fall reset, and restart behavior. Change only the gap spacing, landing height, and scenery between relays.

Keep both players visible when a pairing cue appears. Show the current shared checkpoint, which relay is active, and whether each player is before the gap, on their assigned pad, crossing the bridge, or at the checkpoint. The final gate opens only when both players reach their matching exit pads. Return a compact route map and a list of state transitions. Do not add networking, new powers, enemies, or random rules. If no one-gap version has been inspected, return this as a planned extension and do not label it as verified.

Verify both player states

Write repeatable action sequences before deciding whether a co-op beat is clear. Record both players' starting positions, who lands first, the elapsed time between landings, whether the bridge opens, and whether the shared checkpoint advances. The values below are a paper calculation for Twinspan Relay, not observations from a playable build.

For the first relay, Player A lands on the blue pad at t=0; Player B lands on amber at t=1.0. One second is inside the 1.5-second pairing window, so the bridge opens at t=1.0 and expires at t=5.0. Both players reach the checkpoint at t=3.2, before it closes, so the example state advances. On relay two, Player B arrives at t=1.9, after the pairing window ends at t=1.5. No bridge forms, and both return to the previous shared checkpoint.

These expected states are acceptance cases to run on a real build later. They are not test evidence. A useful observation log records the rule version, both controllers, actions, timing, player positions, relay state, checkpoint, and result. If the result differs, keep the sequence unchanged while you diagnose it.

Revise the miss without changing the whole loop

When a pair fails, locate the first state that differs from the intended sequence. If a player did not see the pad assignment, improve the cue or camera framing before changing the timer. If the correct landing registers but the bridge does not open, inspect pad matching and timer start. If one player advances alone, fix checkpoint gating before adding more level content.

For a real revision, change one cause at a time and repeat the same action sequence. A camera adjustment should not also change the pairing window; a brighter pad should not also alter the reset rule. Keep separate notes for what you observed, what you think caused it, and what you changed. Without a build or player observation, present a proposed fix as a design idea, not a demonstrated improvement.

Prompt 4: ask for a focused revision

Using the actual action sequence and state log I provide, identify the earliest point where the co-op relay differs from the written contract. Separate an implementation mismatch from a visibility, camera, or control problem. Propose one small change, state what should remain unchanged, and write the same action sequence as a repeat check.

Do not invent player feedback, test results, or a successful revision. If no observation log is supplied, return a checklist of likely causes without claiming that any cause occurred. Preserve the shared checkpoint, pad assignment, timers, and reset rules unless the evidence specifically shows which one should change.

Use a small multiplayer scenario as the handoff

SEELE’s Multiplayer Game Maker page describes how to plan player count, roles, shared objectives, interaction rules, and one short scenario. It also says online play still needs project-specific implementation, networking, synchronization, hosting, and testing. That guidance can help frame a co-op concept, but it does not verify Twinspan Relay’s local controls or make the exact timing rules work. Inspect any actual result against both players' state changes before expanding the mode.

Start by writing the shared objective and one acceptance sequence. When you are ready to frame that short multiplayer concept, use the Multiplayer game maker. Treat the page as a planning handoff; confirm the behavior you need in the project you actually build.