What does another player actually change?

The initial realization / Batched jobs

Cooperative progression is also task scheduling.

The first way I described this was “batched jobs that increase the bandwidth for progression.” There are more people who can collect things, so there are more operations we can perform toward a goal. Somebody needs food. Somebody needs materials. Something needs to be built, transported, repaired, or defended.

Thinking through it further, it is also task scheduling. Who does what? What needs to happen first? Which jobs can happen independently? What is everybody waiting on? If I am alone, I am arranging that work around one person’s time, attention, and ability to move through the world.

In Sons of the Forest, someone can decide to go spear fishing and fill up the meat rack while somebody else handles building materials. In SCUM, somebody can hit a pharmacy for the group’s medical supplies while others handle different survival jobs. Those are different game examples, but they illustrate the same observation: people can be doing different things in different places and still contribute to a larger shared goal.

Remove the other players and the jobs still make sense. I can get food. I can collect materials. I can go looking for medicine. I now have to decide what to do first, what to postpone, and what I am willing to leave unattended while I do something else. That is where The Forest fits into cooperative progression for me: the survival work still exists, but a group can distribute it.

More people do not automatically mean proportionally faster progression, either. If construction is waiting on one specific material, sending everyone to collect something else does not solve that problem. The group has more capacity, but it still has to schedule useful work. Some jobs have prerequisites, some jobs can happen together, and some things only need one person doing them.

Personal play / Specialization within a tribe

Having a role in the community is not the same as having an exclusive capability.

I played ARK on a private server a friend paid for, with four or more of us. We became a small community with tasks: gathering what we needed, capturing and training dinosaurs, and keeping the tribe going. I became the narcotics expert, with bio-toxin and my otter. We were organizing work around our tribe rather than operating at the scale of a full server.

The otter mattered. It was basically a living scarf: carrying it helped with temperature protection when I went after jellyfish for bio-toxin or traveled through cold areas. That was part of how I prepared for the job, not just a pet I happened to bring along. The otter’s insulation benefit helped with the environmental conditions; the jellyfish’s ability to stun players was a separate danger involved in getting the resource.

That gave me a recognizable role in the group. I had knowledge and a setup suited to a particular job, and the work contributed to what we were doing together. But this was specialization through experience and division of labor, not an exclusive player class. Another person could take over the task if they learned how and prepared for it. The group could rely on me without the game requiring that I alone supply a mechanically unique contribution. In this part of our play, the structure was largely parallel work organized through coordination.

The biggest difference in playing privately was having no PvP raiders. It took away the pressure that made the long grind feel like a job, and we could organize our efforts around what our group wanted to do. Removing that pressure mattered, but it did not necessarily change the tasks themselves. I could enjoy being useful to the group and still get tired of repeating the work that sustained it.

Across games built around these recurring jobs, I have found myself listening to music or reading while playing. That is a personal account of fatigue, not evidence that everyone finds the work uninteresting. Parallel cooperation is a familiar pattern in the games I play, and I am burnt out on it. The issue is not that it fails to count as cooperation. It is that cooperation so often gives us more capacity to do more chores. That is part of why I want to explore relationships where another player changes what I can do or the conditions I act under, rather than primarily helping process a larger workload.

Parallel work / Stocking and sorting puzzles

The batched tasks are the co-op game.

A particularly literal example is the wave of stocking and sorting games appearing on Steam. There is a store. There is a huge mess of products. Pick something up, identify where it belongs, and put it on the correct shelf. Repeat until the space is organized. I think of these as stocking puzzles: the challenge is recognizing, locating, and arranging things, rather than necessarily running the finances, customers, and checkout of a retail business.

Supermarket Chaos, released in June 2026, is a close match. Its store page describes thousands of scattered products to return to their proper locations, with solo play and cooperative organizing for up to four players. It also explicitly removes time limits and game-over pressure. Megastore: Tidy Up Together, released on September 2, 2026, similarly supports solo and online cooperative sorting. Its description specifically encourages dividing the store between players and assigning different departments. These are examples of the work itself being distributable, not just games that happen to have a multiplayer option.

The setting does not have to be a supermarket, either. Wand & Order: Tidy up the magic shop! frames cooperative organizing around sorting wands, tarot decks, and potions, with spells unlocked through tidying. Museologist: Tidy Up the Museum! provides a related single-player reference: scattered fragments must be identified and fitted back into museum objects. It is not a co-op example, but it shows how the recognition, placement, and restoration loop can form an experience on its own. The museum and magic-shop settings make “retail work” too narrow a description of this broader pattern.

And then there is Sort Them Ducks. The pile is literally rubber ducks: identify their categories and return them to the correct shelves. Correct placements earn money for upgrades that improve carrying, movement, and finding matching ducks. Like Museologist, its Steam feature list identifies it as single-player, so it belongs here as a reference for the underlying task loop rather than a shipped co-op example. It makes the distinction especially clear: sorting is already the game; parallel cooperation describes how that work can be distributed when a game supports multiple participants.

This is also a documented release trend, rather than just an isolated example. In August 2026, PC Gamer covered the growing wave of object-sorting games, including further releases scheduled for August and September. As a sign of audience interest, that report put Librarian: Tidy Up the Arcane Library! at a peak of 29,469 concurrent players. That figure concerns one sorting game, not the size of a cooperative audience, but it gives context for why the format is attracting attention.

My reading of the cooperative stocking loop is straightforward: another person adds another worker to the same backlog. I can sort one section while they sort another. The basic operation remains identifying, carrying, and placing an item. What increases is the amount of that work the group can perform at once. This is the original “batched jobs that increase the bandwidth for progression” observation in a very visible form: the pile gets smaller and the shelves fill up.

These games strip parallel cooperative work down to a very simple form: a shared backlog of independently completable tasks. Another player does not necessarily introduce a new capability or change how a task is solved. They give the group more capacity to perform those tasks simultaneously. The cozy framing makes working through that backlog together the experience itself.

The batched tasks are not just a supporting activity within the co-op game. They are the co-op game. In a survival game, collecting and sorting supplies can feed into building, preparation, or exploration. Here, processing the backlog is the central activity and a visible measure of progress. A huge mess of objects becomes an organized space. This is a stripped-down cooperative structure, not a claim about production cost or quality, and individual games can add abilities or other interactions beyond that foundation.

Task scheduling still matters. Do we divide the store by department, group similar products before carrying them, or finish one area together before moving on? Those choices can reduce repeated searching and unnecessary travel. They add coordination to parallel work; they do not automatically make each placement dependent on a complementary action from someone else. If another player leaves, the remaining sorting jobs are still executable. The workload has changed hands, rather than a required role disappearing.

“Para-coop,” as shorthand for parallel cooperative work, describes something more useful here than dismissing the experience because it is inexpensive or fun with friends. It identifies what the additional player contributes without pretending that this is the only thing they contribute. The conversation, shared satisfaction, and decisions about how to tackle the mess can matter even when one person could eventually stock every shelf alone. Parallel describes the work, not the value of the experience.

The scaffolding

Four structures for examining cooperative play

These are the structures I am using to describe what another participant contributes. They can overlap within a game, or even within an encounter. Gathering supplies and defending the place where we store them may ask different things from the same group.

Session structure, objective ownership, and progression ownership still help explain a game. Are we contributing to one base? Advancing our own characters? Meeting up for an event? Those details sit underneath this scaffolding. They explain how the cooperation is organized without replacing the question of what another participant materially contributes.

Cooperation, withdrawal, and defection

What happens when somebody stops doing their part?

Another way to examine the four structures is to look at what happens when cooperation breaks down. My initial thought was that defecting in parallel play could be almost inconsequential: somebody splits off and builds their own base, or decides to do a different job by themselves. The remaining player can still do those same kinds of things.

But splitting off is not necessarily defecting. If someone goes fishing alone and brings food back to the shared meat rack, they are still contributing. They are working in isolation while remaining coordinated toward the larger goal. Being in a different place, or choosing a different job, does not tell me whether they have stopped cooperating.

I need to distinguish independent contribution, withdrawal from the shared project, and deliberate defection. Somebody might start their own base and leave the group to its work. Somebody else might take the group’s supplies to build that base, or withhold a contribution while continuing to benefit from everybody else’s work. Those choices have different consequences even when the construction mechanics remain the same.

These are differences in how the effect reaches the other players, rather than a ranking of how much damage someone can cause. A person abandoning a resource run just before a deadline can cause a parallel task to fail. A person taking shared supplies can do substantial harm. But when the work is replaceable, the remaining player can often say, “Fine, I will do that job myself.” With a required complementary role, that may no longer be an available response.

Systemic interdependence adds another possibility: the person can remain involved while using the relationship against you. In the Handler proposal, leaving the session deprives the Host of assistance. Deliberately providing a false code or concealing a discovered route could instead change what the Host believes and what they decide to do. If the design permits remote control, manipulating a door at the wrong moment could change the situation directly. These are possible failure modes to examine, not betrayal mechanics I have already decided to add.

Game theory adds a question about incentives: what does each person gain or lose by cooperating, withholding their contribution, or pursuing another outcome? In the Prisoner’s Dilemma, cooperation and defection are defined within a particular arrangement of choices and payoffs. I would need to establish those incentives before claiming that a cooperative encounter fits that model. A mistake, a disconnect, and a deliberate betrayal can produce similar mechanical consequences while being different behaviors.

Robert Axelrod — The Evolution of Cooperation provides the game-theory reference for choices, payoffs, and repeated interaction. The four-structure comparison above is my proposed application to game design.

Can I absorb the missing contribution by doing more work myself, or does another person control something my next action depends on? And if they keep participating but work against me, what can they change?

Personal play experience / Fallout 76

I played in a private world. I got to level 65 and launched a nuke solo.

This is why Fallout 76 is useful to the argument. I was playing by myself in a private world. I reached level 65 and launched a nuke. I also killed Scorchbeasts alone, and went into the Pitt by myself without initially understanding it as a group-oriented activity. I thought I was going to another map location and doing things there.

My shorthand was that, if I remove the cooperative components, it is still another Fallout game with monetization and cooperative play. I was exploring, looting, fighting, building, and developing my character. The underlying activities were already functioning for me alone.

The nuclear launch is a useful example of the distinction I am making. In my run, one character could satisfy the authorization requirements: Enclave membership, the nuclear keycard, and the launch code. I did not need a second person to supply a separate authorization. The requirement belonged to my character’s progression and access.

Where things got hard was objectives that were basically “protect all these things from getting destroyed.” Several things need attention at once. I have to move between them, prioritize threats, and accept that something might be getting attacked while I am occupied somewhere else.

Another person can cover a different location or respond to something I cannot reach immediately. That is a material advantage, and it connects directly to scheduling and coordination. I may be able to perform every individual action while still struggling to perform all of them within the available time.

Tactics, required contributions, and mechanical relationships

Resident Evil 6 and Army of Two are doing different things with a partner.

In my reading of Resident Evil 6, another human brings their actual skill and judgment into the combat system. Their timing, positioning, and decisions matter. They can respond while I am occupied, and we can coordinate around the situation. The basic game remains recognizable, while the tactical possibilities change.

Army of Two is the example that made me want to preserve systemic interdependence as its own part of the scaffolding. With aggro switching, one participant draws attention and changes the other participant’s opportunity to move or act. The game represents that relationship in the combat system. Who is attracting attention, who can exploit it, and when should those roles change?

It Takes Two is the reference for required complementary participation. The question there is what each participant contributes to a particular sequence, and why one participant cannot provide the whole solution. More effort from one side does not necessarily advance the group when the other side still has a required part to perform.

Baldur’s Gate 3 provides another useful comparison. Its party structure can function under one player’s control or distribute control among several humans. Within this framework, that supports a primarily coordinated reading of its cooperative play: removing another human does not necessarily remove the party’s available actions or progression capabilities. It changes who makes the decisions within those systems.

Independent judgment, priorities, mistakes, and unpredictability are part of that social experience. They can change the course of a session without requiring a different underlying gameplay structure. The distinction is between the capabilities the game makes available and the shared experience of deciding how to use them. A story can continue under one person’s control while ceasing to be an experience shared with another player.

Larian — Multiplayer Information describes players joining a single-player adventure by taking over a companion.

Party play / The experience also changes

The jobs can stay the same while the game feels very different.

I still think of Lethal Company and R.E.P.O. as party games at heart. They have cooperative work and centralized progression, usually organized around a quota. People can split up, collect things, and contribute toward the shared target. A lot of that work is parallel.

But part of what makes the game fun is what happens between people while they attempt it. Somebody panics. Somebody makes a terrible decision. Something frightening turns into something ridiculous because of how another person reacts. Playing alone can feel much scarier and much more tedious, even when I am still performing the same basic jobs.

That belongs in the analysis too. Being structurally parallel does not mean another person changes nothing about the experience. It tells me how the work functions. The social interaction helps explain why I want to perform that work with other people in the first place.

Extraction systems / Shared survival and individual progression

A shared survival problem can contain different player goals.

The audience evidence discussed in the extraction-economy case study establishes the relevance of PvE to this analysis. That study cites a reported Tarkov audience distribution of 50% PvE, alongside evidence of interest in PvE from ARC Raiders players. Extraction has an audience for experiences in which the environment supplies the opposition. The design question here is what cooperative relationships those systems can support.

In an extraction session, players can share an immediate need to survive while pursuing different progression goals. One player may need an item, another may need an objective completed, and another may prioritize recovering enough value to prepare for a future run. Cooperation involves deciding how to pursue those goals together and when to leave.

This supports coordinated play through route planning, covering another player, sharing knowledge, and allocating resources. A failed attempt can still produce shared learning. A successful attempt can primarily advance one participant while others supply assistance. The contribution of another player can therefore be evaluated through the decisions and opportunities they enable, as well as the amount of work they perform.

Individual goals also allow interests to diverge. Prioritizing a valuable GPU over the group’s agreed objective can redirect the raid. Downplaying an item’s importance can lead another player to surrender a resource relevant to their current progression. Where an action changes access or the conditions of an engagement or extraction, it can alter the options available to the remaining players. Whether these actions constitute defection depends on the group’s agreement and the action’s consequences.

These interactions can move from coordination toward systemic interdependence when one player’s contribution or decision materially changes another’s resources, information, access, or available actions. The analysis needs to identify that connection in the particular encounter. A shared objective alone does not establish it, and players performing similar actions can still develop different responsibilities through their knowledge, equipment, or position.

Removing hostile human opponents does not remove independent judgment or conflicting priorities among teammates. PvE can retain assistance, negotiation, trust, and opportunism while environmental threats create reasons to cooperate. This supplies a systems-based explanation for cooperative appeal alongside the audience evidence; the mode distribution itself does not measure which of these relationships drives retention.

Teaming / Alliances formed during play

The people you enter with do not have to be the people you leave with.

There is another part of this: cooperation does not have to begin in the lobby, and agreeing to cooperate does not remove the opportunity to betray someone. A player encountered as a potential enemy can become someone worth helping, following, or extracting with. They can also turn against the person who trusted them. What matters here is the meaningful decision: what does choosing to cooperate, continue cooperating, or betray someone change for the other player?

A PMC and a player Scav cooperating in Escape from Tarkov are explicitly teaming, with a potential betrayal opportunity. Cooperative extracts give that relationship a mechanical purpose. At an exit such as Pinewood Basement, the PMC and Scav can satisfy the extraction condition together. Someone who could have been a threat instead supplies a contribution needed to use that exit. But agreeing to extract together is not a guarantee that both will honor the agreement. A player can accept the risk of approaching, reveal their position, or follow the other person toward the exit, while the other still has an opportunity to turn on them.

This goes directly into the systemically interdependent structure. The players are making decisions about each other that affect survival, exposure, and access to extraction. Continuing to cooperate preserves an opportunity; withdrawing can remove that opportunity unless another partner is found; betrayal can end the other player’s run. The extraction condition is locally interdependent, but the relationship is more than two people satisfying a condition. One person’s decision changes the conditions under which the other person is playing. Trust matters because there is something consequential to do with it.

Warzone’s DMZ made another part of that relationship explicit through assimilation. Players could join an opposing squad during the match rather than remain bound to the group they entered with. This did not require being eliminated first: the launch overview describes rival squads negotiating an alliance, combining their efforts, and gaining protection from friendly fire once assimilated. A decision to cooperate changed formal team membership, not just what players said to one another.

The system also allowed squads to grow beyond their starting size. DMZ launched with trios and assimilation up to six players; Season 06 later reduced that maximum to four. Its Plea for Help mechanic connected rescue with recruitment, too. The Season 04 Reloaded notes document a change from automatically joining the rescuer’s team to receiving an invitation after revival. The exact rules changed, but rescue and allegiance were both things the designers could connect through the game’s systems.

That is what makes the feature meaningful here. An encounter does not have to resolve only as a fight, an escape, or two groups ignoring each other. It can change who participates in the rest of the run. A player can gain help pursuing an objective, a group can recover from a loss, or someone can choose a new alliance over their original one. That last possibility also changes the question of defection: it can mean moving support to another group, rather than simply wandering off to work independently.

The contrast with conventional PvP rules is important. Teaming is treated as cheating and a bannable offense in established competitive games: Fortnite prohibits teaming in solo modes, while PUBG lists teaming among offenses that can receive a permanent ban. Those rules protect the competitive arrangement players entered. But they also illustrate a design assumption worth examining: people outside the assigned team are opponents, and cooperation across that boundary is a violation rather than an available strategy.

If that assumption is carried into pre-production as a given, a PvP-first design can exclude these relationships before they are considered as viable gameplay. Decisions about helping an opponent, negotiating safe passage, changing allegiance, or risking betrayal become problems to prevent rather than possibilities to design around. The opportunity is to think beyond the social contracts that competitive games normally establish. Which boundaries need to remain fixed, and which could become meaningful player decisions? Where could PvE threats give opponents a reason to cooperate, and what happens when their interests stop aligning?

That does not mean simply removing an anti-teaming rule from an otherwise unchanged competitive game. It means designing the permissions, incentives, information, and consequences together, so players understand what kinds of alliances and betrayals are possible. Tarkov’s PMC–Scav cooperation leaves trust exposed to betrayal; DMZ’s assimilation formally recognizes the alliance and disables friendly fire within it. These are different choices about what cooperation permits and protects. Across the four proposed structures, questioning those starting assumptions opens room for different cooperative experiences. Teaming is not a fifth structure. It is an example of how a relationship normally prohibited by a competitive ruleset can instead become a source of meaningful, systemically interdependent decisions.

Information is part of the mechanics

“I have the code. I can’t enable it from my end.”

Imagine the Handler hacks a router and can investigate what is connected to it. They find information about a door and tell the Host: “Oh, so the code for the door behind the bookshelf is 286014. I can’t enable it from my end.” The Host still has to find that door and physically enter the code.

There is a whole sequence of play in that. The Handler gains access, discovers devices or records, investigates something relevant, and works out how the finding relates to the Host’s situation. The Host can see and touch things the Handler cannot. The Handler can investigate information the Host does not currently have. Their contributions meet at the door.

I would separate discovering something, inspecting it, and controlling it. Finding a device on the network does not have to mean I can read everything it contains. Reading a door code does not have to mean I can remotely open the door. Those permissions give the relationship somewhere to go: I can tell you what I found, but I may need you to physically act before either of us can get further.

A possible complication is that the record only identifies “Archive Access 03.” The Host sees a bookshelf and a keypad. We have to work out whether we are looking at the same thing. The camera feed, a label on a controller, or the room’s position on the map could help connect those pieces. That investigation gives both people a reason to pay attention and communicate.

This adds scope: an interface, connected systems, rules about access, and possibly hacking minigames. But I do not need a separate minigame for every device to make the role useful. A small, consistent set of ways to discover, inspect, and control things could support several different problems. The information itself needs to be useful enough to investigate.

Where this relationship could go

A horror spaceship or a megacity gives us different games to play.

This is why I think there is more room to explore these cooperative experiences. I am interested in taking the kind of role we associate with a fictional assistant or an AI companion and giving another person an actual game to play inside it. They investigate, make decisions, misunderstand something, or notice something the person in the field missed. The information comes from somebody working through a problem with you.

Imagine that relationship on a spaceship, with the kind of horror setting I have in mind when I say Dead Space. One person is physically moving through the ship. The other is trying to understand what is happening through the ship’s systems and the feed from that person’s camera. They can be together in the operation while experiencing very different kinds of uncertainty.

For example, a system might report that a compartment is empty, but the field player hears something inside. The Handler has to work out what “empty” actually means in that interface. Is it a current sensor reading? An occupancy record? Is the sensor even working? The field player may need to look at a damaged panel or reach another connection before the Handler can tell. That is a proposed encounter where the information has limits, and both people have to decide how much to trust it.

The Handler could be worried because the feed only shows what the field player is looking at. The field player could be worried because the Handler has gone quiet while investigating something they cannot see. Communication can offer reassurance, but neither person necessarily has enough information to guarantee that the next room is safe. That gives us something to explore about cooperative horror beyond simply adding another armed person to the corridor.

Now put the same relationship in a megacity, something in the direction of Judge Dredd or Cyberpunk. A building can become a space the Host moves through and a collection of systems the Handler investigates. Apartments, service corridors, elevators, security desks, and private networks can all offer different points of access.

In that version, I could imagine the Handler finding a maintenance record that identifies a route through another floor. But access to one building’s router would not automatically expose the entire city. The Host might have to reach a security office or another connection point to extend the investigation. Meanwhile, the Handler can work out which destination is worth the trip. Each person’s discoveries help determine the other person’s next job.

These are possible settings for the relationship, with different pressures to design around. On the ship, I would want to explore uncertainty, trust, and what each person cannot see. In the city, I would want to explore access, investigation, and finding a useful route through several connected spaces. The cooperative scaffolding lets me describe what the players are doing in either version without assuming they must share the same interface or perform the same actions.

Apply the removal test

Solo completion should remain technically possible all the way through.

For this proposed genre template, I want the Host to have a non-zero chance of functionally completing the entire game without another person. Being able to move around or finish the opening encounter alone would not satisfy that requirement. There needs to be a technically possible path to the end, even though the Handler can materially improve the Host’s chances of getting there. That is a design target to test, not a measured completion rate.

The Handler can unlock things that contribute to success. An armory can provide supplies the Host would otherwise have to survive without. A side passage with fewer enemies can preserve ammunition, health, and other resources for later encounters. Useful information can help the Host choose where to go and what to prepare for. Those benefits can accumulate across the game.

The solo Host does not need an equivalent way to unlock every Handler benefit. The armory could remain inaccessible and the easier passage could stay closed, provided there is still a route that can be completed without them. If a mandatory progression gate has no solution without a Handler, however, the proposed end-to-end solo possibility has disappeared.

This also means I should compare the full consequences of Handler participation. Successful work can improve the Host’s situation, while defined errors can make a particular encounter more dangerous. The balancing question is whether the information, access, and resources the role can provide meaningfully support success across the run. A second person’s presence alone does not guarantee a better outcome on every attempt.

The Host can technically finish alone. With a Handler, another person’s gameplay changes the conditions under which they try to finish. That is the systemic relationship this template is built around.