The Duckov Coop Mod synchronises a whole game session over UDP

The feature table is really a synchronisation surface

The interesting part of this project is not that a single player game can be played together, it is the list of what has to be kept in agreement once it can. The feature overview is organised by what gets synchronised. Player sync covers position, actions, appearance, equipment, health and player names. AI sync covers enemy spawning, movement, state, damage, death and health bars. Combat sync covers guns, melee, throwables, damage and status effects. Loot sync covers drops, loot boxes, pickups and scene containers. Scene sync covers doors, destructible objects, paid interactions, lottery devices and challenge triggers. Vehicle sync covers vehicle state, riding, control and refuelling. And the multiplayer flow covers room version checks, map change voting, reconnection and death spectating. Read that list as a checklist of what a co-op session has to reconcile, and you can see why the mod is a real piece of engineering rather than a networking shim.

HarmonyLib for patching, LiteNetLib for the wire

Two open source libraries do the heavy lifting, and both are named in the acknowledgements. HarmonyLib is the runtime code modification framework, which is how a mod alters the behaviour of a game it does not have the source for, and the project depends on it through 0Harmony.dll in the Shared folder. LiteNetLib is the UDP networking library, and it is the second file in that same Shared folder, LiteNetLib.dll, alongside the first. Choosing UDP for the transport is a deliberate trade for a game like this, because the traffic is a continuous stream of positions and events where a dropped packet matters far less than a delayed one, and where a reliable ordered channel would turn a player's movement into a queue. The project targets .NET Standard 2.1, and it uses the game's own assemblies, which the build instructions say are referenced automatically from the Duckov_Data\Managed directory.

The version check is a feature, not an edge case

The multiplayer flow lists room version checking among its supported features, and the important note at the top of the README explains why. The current published version is the official release v1.3.6, players who take part in online play should install the same version, and it is recommended to back up important saves before updating or testing. The release history shows how often that matters, with 1.3.5 on 2026-08-24, 1.3.6 on 2026-08-28 and a 1.4.0-Pre on 2026-10-04, and the last push was on 2026-10-19. A mod that synchronises game state across peers cannot tolerate a protocol change mid-session, so the version check is the mechanism that stops a mismatched client from connecting, and the instruction that every player must run the same version is the user-facing half of that mechanism. The save backup advice is a separate warning about a different risk, since a mod that touches the game's own data can interact badly with an existing save.

Building it, and the environment variable that has to be right

Ordinary players never build this, because the mod is distributed through the Steam Workshop and the quick start is four steps: subscribe to the mod in the Workshop, start the game and enable the mod in the mod management screen, confirm that everyone in the session is on the same version, and have one player create a room that the others join. Developers need more. The prerequisites are Visual Studio 2019 or later, a .NET SDK that supports .NET Standard 2.1, and the game installed. Before the first build you set the game root directory in the DUCKOV_GAME_DIRECTORY environment variable, either by running SetEnvVars_Permanent.bat from the project root and typing the full path, for example C:\Steam\steamapps\common\Escape from Duckov, or by adding the user variable by hand in the Windows environment variable settings, and then you close and reopen Visual Studio or the shell so the value takes effect. The game path may contain spaces or parentheses, such as Program Files (x86), and the script handles that. To confirm the variable is set, run this in a new command prompt:

echo %DUCKOV_GAME_DIRECTORY%

The most common build failure is the variable pointing at the Duckov_Data or Managed subdirectory instead of the game root, and the fix is in the troubleshooting section of the README.

The solution, the shared folder and where the output lands

The build itself is a Visual Studio operation. You open EscapeFromDuckovCoopMod.sln, select the Release configuration and build the solution, and the output goes to EscapeFromDuckovCoopMod/bin/Release/. Before that, the Shared folder has to contain the two dependencies, 0Harmony.dll and LiteNetLib.dll, since the game's own assemblies are referenced from Duckov_Data\Managed automatically. The repository layout is a standard .NET solution tree, with the main project directory EscapeFromDuckovCoopMod, a separate EscapeFromDuckovModApi directory, a Shared directory for the binaries, a Localization directory, a Directory.Build.props at the root for shared MSBuild properties, the .sln file, the environment variable batch script, a CHANGELOG.md, and a pair of READMEs, one in Chinese and one in English. The existence of a separate ModApi project and a Localization project is the kind of structure that tells you the mod is organised for more than one language of players and for a public interface other code can call.

A modified AGPL, and the three clauses that are not AGPL

The licence is the part of this repository that deserves the most careful reading, because it is a modified AGPL 3.0 rather than the AGPL 3.0. The project publishes the full licence text in LICENSE.txt and the additional terms in LICENSE_RESTRICTIONS.txt, and asks that you read the licence file in full before using or distributing a derivative work. The three headline requirements are stated directly. Commercial use is forbidden. Closed-source use on a private server is forbidden. Attribution to the original authors is required. A modified AGPL is still an AGPL-derived licence, but it does mean the permissions you are used to from an ordinary AGPL project are narrower here, and the private server clause in particular overlaps with a use case that AGPL normally allows, which is running a modified version for a group of users over a network. A team that wanted to build on this mod commercially, or to run a private server from a private fork, cannot, and the restrictions file is where they would find that out.

What this project is not, and where it stops

Three boundaries. The first is that the audience is narrow. This is a mod for one game, distributed through the Steam Workshop, built against a specific .NET Standard 2.1 target with Visual Studio 2019 or later, and depending on two third-party DLLs that have to be present in a Shared folder. The techniques are portable, the artefact is not. The second is the version lock. Because the session synchronises game state, every participant has to run the same version, and with a 1.4.0 pre-release in circulation alongside 1.3.6, the practical advice is to stay on the published release for a session and treat the pre-release as something to test on a separate save. The third is the licensing, and it is the one that constrains reuse rather than use. For a project that wants a permissive licence, a codebase this well organised would be an awkward thing to start from, because the AGPL base and the three extra clauses travel with the code, and rewriting a cooperative multiplayer mod is not a weekend.

Editorial conclusion

The Duckov Coop Mod is a good reference for the parts of a cooperative game mod that are hard, which is that a shared world means synchronising more than the player avatar, since enemies, loot, doors, vehicles and even the room's version check all have to agree, and the feature table in the README is a useful inventory of that surface. It is the wrong thing to build on if you need a permissive licence, because the project ships a modified AGPL 3.0 that adds a ban on commercial use and a ban on closed-source private server use. Before you use it, install the same version as everyone else in the session, since the mod states that players should run identical versions and asks for a save backup before updating, and read LICENSE_RESTRICTIONS.txt, because the extra clauses are not part of the AGPL text you already know.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Mr-sans-and-InitLoader-s-team/Escape-From-Duckov-Coop-Mod-Preview on GitHub
3. Project website
4. README
5. Releases