A solo-player prototype that works is a trap. You hand the build to two friends, add a second spawn point, and watch twenty hours of careful tuning come apart in four minutes: the ammo pickup that was a relief now gets grabbed by whoever is closest, the pressure plate puzzle solves itself because one player can just stand on it, the boss that demanded dodge timing dies while it is still in its intro, and both players spend the fight shouting "where are you" because the camera can only frame one of them.
Co-op is not a feature you bolt onto a single-player game. It is a different design target that happens to share your codebase. Here is a practical way to design it on purpose, with the decisions and numbers to write down before anyone implements anything.
Pick the co-op fantasy first
"Two-player support" is not a design goal. Pick one of these and let it decide the arguments later:
- Company. The point is not being alone. Difficulty barely rises; presence is the feature — Unravel Two, most couch platformers.
- Competence split. Asymmetric roles and interlocking tools; players need each other's capabilities.
- Coverage. Same toolkit, more ground to cover. Players divide a map or a job list under time pressure — Overcooked's kitchens, extraction shooters.
- Chaos. The other player is a physics object and a liability. Friendly fire on, laughter over fairness.
Write the chosen fantasy at the top of your mechanics doc in one sentence. When someone later asks "should players be able to carry each other?", the answer falls out of it: yes for chaos and company, probably no for coverage, because it collapses the division of labour you just paid for.
The resource question: shared, split, or mirrored
Every pickup, currency and consumable needs an ownership model. Decide it per resource type, in a table, before your first co-op playtest. Mixing models is fine; leaving them undecided is not.
| Model | How it works | Good for | Failure mode |
|---|---|---|---|
| Shared pool | One counter both players spend from | Company, coverage | Hoarding; the generous player ends up under-equipped |
| Split on pickup | One drop becomes one unit for each player | Company co-op, drop-in play | Loot loses weight; nothing feels scarce |
| Instanced | Each player sees their own drop from the same source | Loot-driven RPGs | Trading becomes a design problem you now owe players |
| First-come | Whoever touches it gets it | Chaos | Race behaviour, resentment, back-seat driving |
| Mirrored progression | XP, unlocks and quest flags apply to everyone | Any game with progression gates | Carried players arrive at content they cannot play |
A concrete rule that works in a lot of games: split consumables, share objectives. Health and ammo are per-player so nobody feels robbed by a pickup; keys, door flags and story progress are global so the group never desyncs and has to replay a section.
Scale encounters with three knobs, not an HP multiplier
The lazy scale is health × players. It produces fights that last twice as long and change nothing about how they play. Use three separate knobs and tune them independently — this is exactly the kind of thing that belongs in a balance sheet with one row per encounter and one column per player count:
- Count. More enemies, not tougher ones. This is the knob that actually creates work for a second player, because two threats can occupy two players.
- Pressure. Shorter telegraph gaps, more simultaneous attackers, more area denial. Raise this last; it punishes the weaker player hardest.
- Durability. Health and armour. Raise this least. A sensible starting ratio is 1.0 / 1.4 / 1.75 / 2.0 for one through four players — deliberately sub-linear, because two players also do more than double the damage once they stop dying.
Boss phases need their own pass. If a phase ends at 50% health and your 2-player boss has 1.4× the health, that phase now runs 40% longer in real time. Define thresholds as time-or-health — "phase 2 at 60% health or 45 seconds, whichever comes first" — so pacing survives any party size.
Also cap target commitment. An enemy that picks one player and stays locked on for 10 seconds has removed the other player from the fight; retarget on a 3–4 second timer, or after any hit from a second player.
Failure, revives and the death spiral
Downed states are the single biggest difficulty lever in co-op, and teams usually ship whatever they implemented first. Specify these four numbers and then tune them in playtests:
- Bleed-out timer — 20–30 seconds is enough tension without becoming a phone-check.
- Revive channel — 2–4 seconds. A real decision under pressure, but not a cutscene.
- Self-recovery — one free self-revive per encounter, or none. Nothing kills a session faster than two players stuck 30 metres apart with no out.
- Full-wipe rule — checkpoint restart is the honest answer; a respawn-at-entrance drip feels generous and silently removes the encounter's teeth.
Then watch for the inverse problem: if reviving is cheap, players simply trade downs until the boss dies. Escalating cost fixes it — each revive in an encounter cuts the next revived health from 100% to 60% to 30%.
Camera, space and the readability tax
Shared-screen and tethered-camera games pay a space tax that is easy to forget during blockout:
- Set a tether distance and respect it in level geometry. If the camera can hold players 18 metres apart, no corridor junction should reward walking 40 metres in opposite directions.
- Audit readability under two sets of effects. Your hit flash, dodge trail and heal burst read beautifully alone; stack two on one target and check whether the enemy's wind-up is still visible. If it is not, thin or desaturate the ally VFX rather than toning down the enemy tell.
- Give every player a persistent locator — an off-screen arrow or a silhouette through geometry. "Where are you" is a design bug, not a player problem.
Drop-in, drop-out and the ugly cases
Write down the answers now, because they shape save data:
- Player 2 joins mid-level: spawn where, with what gear, at what progression level?
- Player 2 leaves mid-boss: does the fight rescale live, or finish at the current scale?
- Who owns the save? Does a guest keep their loot, their quest flags, both, or neither?
- Does a guest's completed objective count toward their own campaign?
The last one has real consequences for how people play your game, and it deserves a line in your decision log with the reasoning attached — not a shrug six months later when a player asks why their progress vanished.
The co-op playtest checklist
Co-op bugs hide from designers, who play well and play with people being nice. Structure the session:
- Run one pair of mismatched skill levels — an experienced player with a first-timer. Watch for the carry: does the weaker player act, or follow?
- Run one pair with no voice chat. Everything that only works with talking is now visible.
- Have one player go deliberately AFK for 60 seconds mid-encounter. Can the other finish? Should they be able to?
- Try to break every gate: can one player get past a two-player door, skip a pressure plate, or soft-lock the pair on opposite sides?
- Count revives per encounter. More than three and your fight has no fail state.
- Note every time someone says "where are you" or "did you get that". Those are your two biggest UI gaps.
Keep these runs tagged separately from your solo playtest notes — if you track sessions in GameDesignerX, a co-op tag on the playtest records makes it obvious when a difficulty complaint is actually a party-size problem rather than a tuning one.
Write it down in one page
The co-op spec that survives production is short: the chosen fantasy in one sentence, the resource ownership table, the scaling ratios per player count, the four failure numbers, the tether distance, and the drop-in answers. Six items, kept next to your mechanics and balance docs rather than in a chat thread — every one of those numbers gets re-argued at least twice, and the second argument is much shorter when the first is written down.