CoopAndreas: cooperative multiplayer for Grand Theft Auto San Andreas

What the project is, and the disclaimer that frames it

CoopAndreas is described as a cooperative multiplayer modification for Grand Theft Auto San Andreas that is in active development, and the readme opens with the two things everybody looks for in a game modification: a community and a statement of what the project is not.

The community is large by the standards of a modification, with a Discord server of twenty-five thousand members and a video channel, and the readme says videos, pictures, news, suggestions, and communication all live there. That is a project with a real user base rather than a hobby experiment.

The disclaimer is the part worth reading carefully, because it is unusually precise. The mod is an unofficial modification, it will only run if you own the game, and none of the publisher's game files or assets appear in the repository, since everything in it was written by the project. It has no connection to the publisher or to the parent company, all rights to the original game and its intellectual property belong to them, and the project states that it exists for study and for non-commercial use, and that anybody who runs it has to respect the terms and the licence of the publisher.

Every clause of that is there for a reason. The no-assets clause is the one that keeps a modification out of copyright trouble, and the non-commercial clause is a deliberate narrowing of the project's own ambition. Combined with the requirement for a legitimate copy, the disclaimer is a coherent position: the repository contains code that only works with a game you bought, it contains none of the game, and it is not sold.

The repository has a separate privacy file as well as the licence, and the code is under the copyleft licence, which for a modification whose whole purpose is to be shared with other players is the right choice.

The last push was on 2026-10-19, there are no tagged releases, and the topic tags give the same picture: cooperative play, the networking library, the game, the modding and multiplayer tags, and the plugin SDK.

Four binaries, and the build that produces them

The building section is written for Windows, and it starts with the toolchain: a C++ package in a recent Visual Studio, and the xmake build tool.

The interesting decision is the choice of xmake rather than a hand written build script or an existing game mod framework. A modification of this size, with a client, a server, a proxy, and a launcher, needs a build system that can produce several targets with different settings, and xmake is a scriptable one that does that without a separate configuration language. The repository has a single build definition file at the root, which is what that looks like.

The client and the server build first, and there is a convenience in that step.

# Build client DLL
xmake --build client

# Build server binary
xmake --build server

If the environment variable pointing at the game directory is set, the client library is placed into the game directory automatically. That is a small touch that saves every user the step of finding the output and copying it, and it is the kind of detail that tells you the build instructions were written by somebody who actually followed them.

The remaining two targets are the ones that make the mod work at all, and they are the subject of the next two sections. The launcher, which starts the game with the right command line arguments, and the proxy, which is the piece that gets the code into the game process.

So the whole build is four separate outputs: a client library with the game side of the logic, a server binary that runs the authoritative simulation, a proxy library that loads the client into the game, and a launcher executable that starts the game properly. A reader who has never built a game modification will notice that none of this is optional and that the pieces have a strict order of dependency, which the readme respects by numbering them.

The proxy, and the trick that loads the code

The proxy is described as required, and its job is stated in one sentence: to load, that is to inject, the main library into the game executable.

The method is a classic loader trick, and the readme spells it out in three steps. Go to the game directory and rename an existing library file. Build the proxy project. Then rename the proxy's output to the original name and copy it into the game folder.

xmake --build proxy

The reason it works is that the game already loads that library for its own reasons, and the operating system loads libraries by name from the executable's directory first. So the game asks for a library, gets the one next to it rather than the system one, and the proxy loads the real implementation and forwards everything else.

This is why the original file has to be renamed rather than replaced, and why the build produces a file with the exact expected name. The renamed original is not a backup that you might want to delete; it is the library the proxy will load the real one alongside, so that everything the game asks of that library still works.

The readme is careful about the consequences of the build process: the output has to be renamed to the expected name by hand and copied into the game folder. There is no automatic step for it, and the reason is that the copy targets the user's own installation, which the build cannot know about.

The launcher exists for a related reason. The readme says it is required to start the game executable and pass the needed command line arguments, and later it turns out to be the place where a serial key is entered, after which the game is launched and the user is asked for the server address and port. So the launcher is the front door to the whole thing: it handles the key, it starts the game, and it starts it in a way that the proxy and the client can then find each other.

Together the two pieces are a small piece of process engineering. The proxy solves the problem of getting code into a process you do not own, and the launcher solves the problem of starting that process correctly with the arguments the mod needs.

The script compiler, and why the game side is not all native

The fourth build step is different from the others, and it is the one that tells you the mod is not purely a native library.

The step is called for the main script file, and it needs a separate tool: a script compiler for the game's own scripting language, with the plugin files for it copied into the tool's installation folder. The readme says this adds the project's opcodes to the compiler, so the tool is extended to understand the mod's own commands, and then the main script is opened in the compiler, compiled, and the generated files are copied into a directory inside the game installation.

So the game side of the modification is partly script and partly native code, and the script is the part that talks to the game's own engine. That is a sensible split for this kind of modification: the parts that need to hook into the engine's script interpreter are written in the engine's scripting language, and the parts that need to do network work are written in C++.

The two extra build tools in the repository tree are the evidence. There is a directory for the plugin files for the script compiler, and a directory for the scripts themselves, alongside the client, server, proxy, and launcher directories, plus a shared directory for the code both sides use and a third party directory for the vendored dependencies.

The formatting and linting configuration at the top of the tree, a formatter configuration and a static analysis configuration, together with an editor configuration, say that this is C++ written by people who care about how it is written. The presence of a static analysis configuration for a project of this size and this age is a good sign, because the alternative is a codebase where nobody dares to change the networking code.

The readme's own summary of the build is a good description of the whole project: the client, the server, the proxy, the launcher, and the script, with the game directory as the place they all end up.

The task list, which is really the design document

The longest part of the readme is a task list, and it is the most technically revealing document in the repository, because it enumerates every behaviour that has to be synchronised between two players.

The first block is the project setup and the connection, both marked done, and then the on-foot synchronisation: walking and running, jumping, climbing, crouching, which is listed with a note that the crouch desync was fixed, and hitting and fighting. The weapon synchronisation follows, with holding a weapon, aiming, a lag shot synchronisation that uses key presses and therefore has poor accuracy, and a shot synchronisation in which every bullet is synchronised.

That last pair is the design decision that explains the whole project, and the readme states it without dressing it up. There are two ways to synchronise a shot. You can send the input, in which case the two players see slightly different shots because their latency differs, or you can send the outcome, in which case both players see the same shot. The lag version is the first and the second is the newer one, and the readme's comments say which is which.

The list then covers the interface layer: player information, a health bar, an armour bar, a nickname, a weapon icon, an explosion, and then a long run of vehicle behaviour, with spawning and deletion, entering and exiting, colour, paint job, tuning, hydra thrusters, plane wheels, turret aim and shot, the horn, the keys, which provide steering angles and braking, position and speed and orientation, health, damage status, and doors.

And then the individual vehicle states, each one a line: the locked state, the engine state. Then chat, time, weather, key synchronisation, and rendering, with text rendering and sprite rendering, and the character customisation: the tattoo, the clothes, the haircut.

The current task block is the same list with the open items marked, and the granularity is the point. Pickups are not done, and within pickups there are the collectible items, the static weapons and armour, the static bribes, and the drop, and within drop there is the money and the weapons. The jetpack synchronisation is partly done, with the flight working and the pickup outstanding. Cutscenes are partly done, with a vote to skip. The map synchronisation has the mission icons done and the player map pin outstanding, and a fix for the proportions outstanding. The wanted level is entirely open. The statistics synchronisation is a long list of the game's own statistics, from body fat to muscle to weapon skills to fight styles to money, and the breath level bar is still open.

And further down, the lines that are not quite serious: a task to synchronise the idle animations, and a note asking whether the reader knew about the funny animation triggered by a particular key combination. There is a task to synchronise a moon sniper rifle shot that changes size as an in-game joke.

That is what a real networking layer for a game looks like when somebody writes it down honestly: a hundred and fifty small state variables, each of which is a bug waiting to happen, each of which somebody has to decide about.

What is still missing, and how the project is organised

The open tasks are worth reading as a roadmap, because they say where the project is going and what a contributor could pick up.

The networking gaps are the interesting ones. Vehicle synchronisation is open in several specific ways: forcing the hydraulics, and trailers. Passenger synchronisation is open for the radio and for the gamepad support, and there is a task for an on-screen keyboard for chat with a gamepad. There is a task for the cheat code synchronisation, which is a real design question rather than an oversight, since a cheat typed by one player has to do the same thing for the others.

There are tasks for the wandering non-player characters, with position, rotation, and speed done and the in-vehicle case outstanding, and the in-vehicle case is marked with a note that it is good luck, warrior. There is a task for the enemy gang groups, and one for the parachute jump, and one for the stunts, and one for the slow motion effect that only one player sees. The chat reactions task even points at the texture file that holds them.

And then there is the list of smaller fixes, which is the most honest section in the document: a task to fix the mouse, a task for widescreen, a fast load that is done, a task to fix models loading as a green polygon which is related to streaming the entities in and out, and a task for smooth interpolation of movement and rotation, of which the weapon aim interpolation is already done. There is a task to synchronise the aim of the non-player characters, and one to synchronise their shots, and one to synchronise their tasks.

The missions section is the same pattern. A handful are marked done, with names from the game, and a handful are open, and one line is just a dash, which suggests the list ran out before the work did.

The repository layout matches the build. There are the client, server, proxy, and launcher directories, the script directory and the script compiler plugin directory, a shared directory, a third party directory for vendored code, and the build definition file at the root.

And there is a line in the readme that tells you how the project wants to grow: anyone who wants something to work on is pointed at the issue tracker rather than at the list itself. The task list is the design document, and the issues are the work queue. The server build instructions for Linux are a single word, which is the last honest signal in the document: the project is a Windows-first effort, and the Linux server build is the one thing that has not been done yet.

Editorial conclusion

CoopAndreas fits a player or a group who own the game and want to play it together, and a developer who wants to read a real networking layer for a game without an official multiplayer mode. It does not fit somebody who has not bought the game, since the project is explicit that you must own the game and that it ships none of the original assets. Verify first which operating system you are on, because the server build instructions for Linux are still marked as to do, that you can build with the required toolchain, and that the script compiler step is not optional, since the game side of the mod is compiled from a script rather than being entirely native.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Tornamic/CoopAndreas on GitHub