Competitive design has a target: make the better player win more often. Co-op design has no equivalent, and that absence is why most co-op is one player’s game with a second player attached to it.
The problem competitive does not have
In a competitive game, the opponent scales automatically. Put a strong player against a strong player and the challenge is correct without anyone tuning it.
In co-op, the game has to be the opponent, and it has to be the right opponent for two people whose skill you do not know, whose gap you do not know, and who may be playing for different reasons.
That is three unknowns rather than one, and there is no matchmaking to solve it. The two players are already in the room.
The skill gap is the core constraint
A co-op game tuned for two players of similar skill breaks when the gap is large, and most real co-op has a large gap – a person introducing a friend, a parent and a child, two people who play very different amounts.
Three responses exist, and each has a cost.
Scale to the strongest. The weaker player becomes a spectator, or worse, a liability. This is the default outcome when nobody designs for it.
Scale to the weakest. The stronger player is bored, and boredom in co-op looks like one person rushing ahead and doing everything.
Give them different jobs. The only answer that works, and it is expensive because it means designing two roles rather than one difficulty curve.
Asymmetry is the actual technique
The games that handle a skill gap well almost always split the work rather than the difficulty.
One player does the thing requiring execution; another does the thing requiring attention. One drives, one navigates. One fights, one manages resources. The roles are not equally demanding, and that is the point – a role can be matched to a player rather than a difficulty slider being matched to an average.
It also produces the thing co-op is for. Two people doing the same thing in parallel is single player with a witness. Two people doing different things that depend on each other is a conversation, and the conversation is the experience.
The cost is that you are designing two games that have to interlock, which is why systemic design and co-op design fail for the same reason: the interactions multiply.
What failure looks like
Three recognisable shapes.
The carry. One player completes the content while the other follows. Common in action co-op where the only role is “fight” and fighting scales with skill.
The bottleneck. Progress requires both players to succeed at the same thing, so the pair moves at the speed of the weaker one at every step. Exhausting for both.
The split. The two players stop interacting because the game never requires them to, and it becomes two single-player sessions in the same world.
The third is the most common in sandbox co-op and the hardest to design against, because the freedom that makes the sandbox good is the same freedom that lets players stop needing each other.
Minecraft’s accidental solution
Minecraft is the most-played co-op game in the world and it has almost no co-op design in it. There are no roles, no scaling, no shared objectives.
What it has instead is a world that persists and a set of tasks with very different demands. One player mines, another farms, another builds, another does redstone – and they do that because the tasks are genuinely different, not because the game assigned them.
The roles emerge from a wide task space and shared consequences. That is the cheapest possible implementation of asymmetry, and it works because the world is the thing both players are invested in rather than a level they are clearing.
It also depends on something being expensive. If materials were free, there would be no reason to divide the labour, and the division of labour is the entire co-op design.
The question worth asking
For anyone designing co-op: what does the second player do that the first player cannot do at the same time?
If the answer is “the same thing, faster”, the game is single player with a difficulty modifier. If the answer names a different activity, there is a co-op game there.
And a follow-up, which catches the most common failure: if the two players have very different skill, does one of them stop mattering? A design that answers no to that has solved the hard part, and almost nothing else about co-op is hard.
Drop-in, and the other hard problem
Everything above assumes two players who started together. The harder case is a player joining a session already in progress.
A drop-in player has none of the context, none of the progression, and frequently none of the equipment. Games solve this badly or not at all – the usual approach is to hand the joining player a snapshot of the host’s progress, which works mechanically and leaves them without the understanding that progress represented.
The games that handle it well give the joining player a role that does not require context. Something useful they can do immediately, from which the understanding follows. That is asymmetry again, applied to time rather than to skill.
It is also why persistent-world co-op handles drop-in better than level-based co-op: the world does not have a progress state a newcomer is behind on, only a place they have not been yet, which is the same property that makes a sandbox forgiving.
Images: Dead Cells, Hades and Subnautica project galleries.