OpenMU: a clean room server emulator for MU Online in C#

A rewrite on purpose, not a fork of decompiled code

OpenMU aims to create an easy to use, extendable and customizable server for a MMORPG called MU Online, and the most interesting sentence in the README is about provenance. The code is a complete rewrite from scratch, it is not based on pre-existing projects, and it is explicitly not based on decompiled server sources or their countless derivates.

That distinction matters more than it might sound. The MU Online server scene is dominated by forks of decompiled original sources, which means the licence status of most of them is murky and the code base is a derivative of something nobody is authorised to publish. A from-scratch implementation with a clean licence is a different proposition, both legally and technically, because every line has an author who can explain it. The MIT licence covers the whole project, and the README states it directly.

The scope is also stated. The server supports multiple versions of the game, but the main focus is version Season 6 Episode 3 using the English protocol, and the long term focus is the open source client MuMain, which supports a slightly extended network protocol. The project adds that parts of the software can also be suitable for the development of other games, even other kinds of games, which is the usual hedge for a component that could outlive its original purpose. The project is C#, the build runs on Linux with a dotnetcore workflow and a separate Docker workflow, and the network layer is published as NuGet packages, MUnique.OpenMU.Network and MUnique.OpenMU.Network.Packets.

No release, so the Docker image is the entry point

The README is blunt about the current state. This project is currently under development without any release, and the suggested way to try it is the available Docker image, linked to a getting started page in the documentation. The release history does list tags, with v0.9.0 tagged in November 2024 and v0.8.20 and v0.8.17 before it, all named as Tools Update releases, but the project's own statement is that there is no release to depend on. The last push to master was on 2026-10-19, so the branch is being worked on actively even though the tagged artifacts are old.

The documentation structure is thorough for a project without a release, and it is where the practical information lives. The getting started section covers requirements, ports, running with Docker or from source, connecting a game client, and test accounts, which is the first page to read if you are trying this out. The deployment section covers the deployment variants, HTTPS, start parameters and environment variables. There is an admin panel section with one page per screen of the server's user interface plus task oriented how-tos, and a server features section documenting features that have their own configuration, with the server-side AI bots as the example given. The development section covers architecture, the solution structure, the plugin system and contributing, and the reference section has the ports list and the generated packet documentation.

The code-bound documentation stays next to the code. The docs/ folder holds the packet descriptions and the game mechanics, and each project under src/ has its own Readme.md. That split is a reasonable convention, because a packet description is only useful next to the packet, and a website is better for the parts that change less often.

The plugin system and the admin panel are the extension points

Two mechanisms shape how you would actually use this. The first is the plugin system, documented in the development section, and it is what makes the word extendable in the project description real. A game server emulator that is a single binary with everything compiled in is a dead end for a community that wants to add features, so a plugin architecture is the difference between a project and a curiosity. The documentation for the plugin system lives on the website rather than in the README, so the specifics of the extension points are not visible from the repository root, but the fact that it is a first class documented concept says something about the intended design.

The second is the admin panel, which has a documentation page for every screen of the server's user interface. A server emulator that is only controllable by editing config files or a database by hand is one that only a technical operator can run, and the per-screen documentation implies a real interface rather than a set of endpoints. The server-side AI bots are documented separately under server features because they have their own configuration, which suggests the bot system is a configurable subsystem rather than a hard coded behaviour.

The NuGet packages are the third extension point and the one with the most reach outside the project. Splitting the network layer and the packet definitions into publishable packages means another project, or a tool, can use the protocol implementation without depending on the game server itself. For a game with a community of protocol researchers and private server operators, that is the difference between a codebase and a platform.

Running the documentation site and the development loop

The documentation website is a Docusaurus site living in the docs-website folder, and the README documents how to run it locally. It is a normal Node build.

cd docs-website
npm install
npm start

The top level layout tells you where the interesting pieces are. src/ holds the solution, tests/ the test projects, deploy/ the deployment material, and dev.sh at the root is the development entry point. The repository also carries an AGENTS.md, a CONTRIBUTING.md, a QuickStart.md, and a docs/ folder for the code-bound documentation. The README asks contributors, developers and non-developers alike, to read CONTRIBUTING.md before starting, and points at a Discord channel and the issue tracker as the places to ask questions, which is a reasonable thing for a project that expects outside help.

One thing the README does not settle is the build environment in detail. It mentions the Linux dotnetcore workflow and the Docker workflow, and the getting started page covers running from source, so the .NET version and the exact commands are in the documentation rather than here. That is a reasonable place for them, and it is also a reminder that this project expects you to read the docs before running it, which is normal for a game server with ports, protocols and test accounts to configure.

Where OpenMU is the wrong tool

Three cases argue against it. The first is running a game you need to be reliable. The project says plainly that it is under development without any release, and the newest tagged version is from November 2024 while the branch is being worked on daily. For a hobby server that is fine, and for a server with paying players it is not, because there is no versioned artifact to pin and no stability promise to rely on. The second is any game other than MU Online. The code is a general enough C# server that the project itself says parts of it could suit other games, but the packet handling, the game mechanics, the data model and the admin panel are all shaped around MU Online, and porting to a different game means rewriting exactly the parts that make it a server rather than a framework. The third is a legal question you should ask before starting. The README is explicit that this is a clean room implementation and not derived from decompiled sources, and the MIT licence covers the code, but MU Online is a commercial game with its own terms, and the game client, the art and the game data are not covered by this repository's licence. A private server operator is making a decision about game data and client distribution that the software licence does not settle for them.

On maintenance, the picture is a project with a small team and a large scope, which is a real risk in a domain where protocol compatibility is measured against an aging client. The daily commits and the Discord community are signs of life, but they are not a support commitment, and the tagged release trail stopped in 2024 while the work continued on master. The documentation discipline is the best signal of quality here, because a game server that is well documented is one where a contributor can find the entry point, and that is what keeps a project of this size from becoming unmaintainable.

Editorial conclusion

OpenMU suits someone who wants to run a MU Online server from a clean room implementation, or who is working on the open source client and needs a matching server, and who is comfortable with.NET and Docker. It does not suit a production operator who needs a stable release, since the project states it is under development without any release. Before you run it, read the getting started pages in the docs-website folder for the required ports and test accounts, try the published Docker image before building from source, and note that the last push was on 2026-10-19 while the newest tagged release listed is v0.9.0 from 2024-11-24.

Frequently asked questions

Official sources

1. License: MIT
2. MUnique/OpenMU on GitHub
3. Project website
4. README
5. Releases