coop-anything hands your coding agent a playbook for making games co-op

A repository you point an agent at, not a program you run

Co-op Anything is a repository whose content is instructions. The pitch is in the project description: point your AI agent at any single-player game and play it with friends, online or in splitscreen, with an MCP server and a playbook that let an agent reverse engineer, fix, test, ship and share what it learns.

The framing matters, because there is no binary to install and no library to import. The repository holds an AGENTS.md file, a set of skills under .agents/skills with a parallel copy under .claude/skills for Claude Code, a playbook directory of guides, a games directory with per-game write-ups, and a tools directory that holds the MCP server. The primary language recorded for the repository is C, which fits the binary work that dominates the harder path, and the licence is MIT.

The audience is a player who owns a game that was never co-op, plus a coding agent that will do the reading, the reversing and the testing. The project names the agents it expects to work with, including Claude Code, Codex, Gemini CLI, Cursor and OpenCode, and the quick start is a prompt you paste into one of them.

What it produces is a shipping artefact, not a patch you apply blindly. The pipeline ends with automated tests that use real game clients, an install package a friend can install in one click, and Steam relay networking so they can join without port forwarding.

The quick start is a two line prompt

The quick start section does not contain commands to run. It contains a prompt to give your agent:

Read https://github.com/cranebeaker/coop-anything and follow AGENTS.md.
I want to play <game> in co-op with my friends.

The agent then follows AGENTS.md and the skills, and the rest of the work happens through the agent's own tool use. This is a workflow description rather than an installation guide, and it is the clearest signal about what kind of project this is: the deliverable is a set of procedures that an agent executes, with a human deciding which game to aim at.

The second piece of setup is the MCP server, which is the part you do install. The Co-op Anything MCP lets any agent search the co-op directory, detect a game's engine from its install folder, read the playbook and skills, and validate contributions. Claude Code picks it up from the repository's .mcp.json file, and for other agents the documented command is:

claude mcp add coop-anything -- python <clone>/tools/mcp/coop_mcp.py

Setup instructions for Codex, Gemini CLI and Cursor live in the playbook's mcp document. There is a specific recommendation for the binary work as well: pair the project with a reverse-engineering MCP such as REA, installed with npx rea-agents setup. The division of labour is stated plainly, Co-op Anything knows what to do and REA looks inside the game.

Two paths, reviving a mod or building from zero

The agent takes one of two paths, and the project presents them as a table because the choice changes everything about the effort involved.

Path 1 is finishing what exists. It applies when a co-op mod exists but is buggy, stalled or abandoned, which the documentation says is the case for most loved games. The method is to find the last build, mine its bug reports from issues, forums and Discord, audit the code, fix it as a separate package, test it and ship it. The skills involved are coop-research, coop-revive and coop-qa, and the guide is the document on reviving abandoned mods.

Path 2 is building from zero, for the cases where nothing usable exists. The method is to reverse engineer the game and its engine, hook in, show the second player, synchronise enemies, world and story, handle level changes and saves, then test and ship. The skills are coop-reverse-engineer, coop-build-from-zero, coop-networking and coop-qa, and the guide is the document on how co-op mods work.

Both paths converge on the same ending: automated tests with real game clients, an easy install, Steam relay networking, and a pull request back to the main repository. That last part is the reason the project is a repository of shared knowledge rather than a private project, every finished game becomes a write-up and a set of reusable techniques.

The repository layout supports that. Alongside the skills and the playbook there are directories for data, research, templates and games, plus a DIRECTORY.md that appears to be an index, and a CONTRIBUTING.md and CLAUDE.md.

The engine decides the approach, and the table is the point

The section titled What you can co-op is a table mapping game families to techniques and tools, and it is the most technically dense part of the documentation.

For games on an engine that already has multiplayer, such as Unreal 1 and 2, Source, id Tech and X-Ray, the approach is to make the single-player logic run on the existing netcode with script mods, using script source, SDK compilers and mod packages.

Bethesda games on Gamebryo and Creation use a script extender plugin with host-authority sync, reusing designs in the style of Tilted Online, with SKSE, F4SE or xNVSE, Ghidra and REA. Unity games are handled with Harmony patches through a mod loader and a networking library in C#, using BepInEx, MelonLoader, dnSpyEx and Il2CppDumper. Unreal Engine 4 and 5 take Lua or C++ mods built on an SDK dump of the game's classes, with UE4SS and Dumper-7.

The proprietary families, RE Engine and FromSoftware among them, are hooked with DLL injection, extending the game's own online features where they exist, using REFramework, MinHook, Ghidra, REA and x64dbg. Decompiled or open source games, such as N64 decomps, KeeperFX, OpenMW and source ports, get networking added directly in the code.

Console only games, PS1, PS2, N64, Dreamcast, GameCube, Wii and GBA among them, need a decomp or a recompiled PC port first, or else emulator netplay, or a memory-sync mod between two emulators. The last row is the one the documentation calls the hardest path: a closed binary with nothing else available means full reverse engineering of state, saves and levels, using REA, GhidraMCP, ida-pro-mcp, Frida and Cheat Engine.

Console ports, emulator netplay and the split-screen route

Most of the games people actually want to play together are not PC games in the modern sense, so the console routes matter.

The documentation points to two separate guides, one for emulator co-op and one for decompiled or recompiled PC ports, and it names the Ocarina of Time co-op work as the route that took the second path. The tools listed for that route are N64Recomp and XenonRecomp for recompilation, PCSX2 PINE for PlayStation 2 emulation, the Dolphin Memory Engine for GameCube and Wii, and BizHawk or mGBA Lua scripting.

Couch co-op on a single PC is handled separately, through the split-screen guide, which builds on Nucleus Co-op on Windows and PartyDeck on Linux and the Steam Deck. Both of those are described as open source, and the split-screen approach is a different proposition from networked co-op because it removes the networking problem entirely.

The games list shows the range that has been attempted or is in progress. Deus Ex from 2000 is described as released, with the HX co-op mod revived, a fix package, Steam relay and an automated test suite. Fallout: New Vegas, Zelda: Ocarina of Time, which is described as fully synced, Dungeon Keeper and S.T.A.L.K.E.R. Shadow of Chernobyl are in progress.

The community list is longer still, including Mega Man X and Mega Man X4 through recompilations, Pilotwings 64 in splitscreen, Crab Champions, Stacklands, Half Sword, Enter the Gungeon, Clive Barker's Jericho, Poppy Playtime, Divinity II in splitscreen, Command and Conquer 3 in campaign co-op, and Far Cry 2.

The endgame is a test suite, a package and relay networking

Two parts of the pipeline are worth pulling out, because they are what separate this from a personal multiplayer patch.

The first is automated QA. The playbook has a document on automated QA, and the description of it in the documentation is tests with real game clients. A co-op patch that has been tested only by one person on one machine will break on a different machine, so the tests exist to catch the cases where the second player desyncs, the world state diverges or a save does not survive a level change.

The second is networking and distribution, and the choice of Steam relay is the interesting part. The documentation states that friends install it in one click and join over Steam without port forwarding. Port forwarding is the classic reason people give up on co-op mods, because it means every player has to log into their router, and relay sidesteps that entirely by routing the session through an existing service that players already have accounts for.

The contribution model ties it together. A finished project ends with a pull request back to the main repository, which is how the per-game write-ups, the engine tables and the skills accumulate. The games directory holds a README for each game with what was done, the release link and the write-up, and the repository also carries a research directory and a templates directory for starting a new game from a known pattern.

The one thing the documentation does not present is a schedule. There are no GitHub releases for the repository itself, the last push was on 2026-10-22, and the work is organised around which game you pick rather than around a release train.

An MIT licensed playbook with a licence-free dependency on effort

The administrative picture is simple. The licence is MIT, the repository is not archived, and the last push was on 2026-10-22, so the work is current.

What the project does not provide is any guarantee that your game will be finished. The table of engine approaches is a map of techniques, and the entries in the hardest column, closed binary with nothing else available, are honest about what they involve: full reverse engineering of state, saves and levels, using REA, Ghidra, ida-pro-mcp, Frida and Cheat Engine. An agent can drive that process, but the size of the job is measured in hours of tool time and in how well the game resists the hooks.

The alternative to using this project is to write your own co-op mod from scratch, with your own engine-specific tooling and your own testing approach, which for a game with a strong existing mod ecosystem is strictly worse. The other alternative is to use a co-op mod that already exists without going through this pipeline at all, which is worth checking first, because the documentation itself says most loved games fall into the path 1 category where a fix package and a test suite is the work.

The realistic reading is that coop-anything is a productivity multiplier for one determined person or agent pair, not a general solution. The games listed as released or in progress are the evidence of what it can do, and the per-game write-ups under games/ are where you can judge whether the effort for your own title is likely to land.

Editorial conclusion

coop-anything suits a player with a specific single-player game and an agent that can spend hours on it, and it is the wrong tool for a weekend project, since the pipeline ends in automated tests with real game clients, an install package and a pull request rather than a quick prototype. Before starting, read AGENTS.md and the skills in .agents/skills, and check the games table, because for a game that already has a co-op mod the reviving path is far shorter than building networking from zero.

Frequently asked questions

Official sources

1. cranebeaker/coop-anything on GitHub
2. Issues
3. License: MIT
4. README