MirrorNG is a high level Networking API for Unity.

MirrorNG is built and tested for MMO Scale Networking by the developers of Cubica.

MirrorNG is optimized for ease of use and probability of success. Projects that use MirrorNG are small, concise and maintainable.

With MirrorNG, the Server & Client are ONE project (hence the name). Instead of having one code base for the server and one for the client, we simply use the same code for both of them.

• [Server] / [Client] tags can be used for the server-only and client-only parts.
• [Command] are used for Client->Server, and [ClientRpc] / [TargetRpc] for Server->Client communication.
• [SyncVar]s and SyncLists are used to automatically synchronize state.

What previously required 10.000 lines of code, now takes 1.000 lines of code. Therein lies the magic of Mirror.

I have worked on Mirror for over a year, I am the one that came up with the name and the second contributor. It has served me well and there are some really smart people working on it.

However, the project is not moving forward as fast as I would like. There is a big emphasis on keeping backwards compatiblity, which is really good for many users, but it is seriously slowing me down.

Mirror relies heavily on manual testing. Manual testing does not scale. I can cover so much more code with automated tests, and have much more confidence on my changes. This will require large breaking changes that will be hard to swallow for many people, but at the end of the day I should be able to reduce the amount of defects significantly. While there has been signficiant progress in improving test coverage in Mirror, the code is not designed to be tested, which which limits how much can be done. This can be fixed, but not without breaking changes.

Mirror makes heavy use of singletons, which is considered an anti-pattern. Singletons are especially problematic in Unity 2019.3. A lot of people will disable domain reloading which completely breaks singletons.

Mirror has very poor error handling. Many methods return true/false to indicate success/failure and use Debug.LogError to report errors. Debug.LogError is not testable, there is no way to write a test to make sure errors are detected. Since day 1, C# has had a much better mechanism to handle abnormal conditions: Exceptions. Methods in MirrorNG should either succeed or throw exceptions if something is wrong with full explanation. This lets the developer catch the exception and take action: display an error message to the user, report it to your servers, report it to google play, etc...

Mirror is distributed in the unity asset store and github. Both of these are majorly inconvenient to work with when you want to stay up to date. I am developing a game, and I spent significant amount of time just updating Mirror in my game. Fortunately Unity has a new mechanism that eliminates most of the pain: Unity Package Manager. There has been resistance in Mirror to distribute it using UPM.

There is not a whole lot of innovation in Mirror anymore. Just bug fixes. I have a very difficult time getting any new feature merged. I have tons of ideas of things we can add to make things easier and better, most of them get shut down.

I want to adhere as much as possible to the SOLID principles. Many things in Mirror do not.

Mirror is all about simple code. Yet many things are unnecesarily complicated. The code can be a lot simpler by using modern C#: Exceptions, async/await, events. We have already significantly reduced cognitive complexity.

Mirror has it's own code conventions based on personal preferences. I would rather follow official C# code conventions. Anybody that speaks C# should feel right at home with this code.

Code review takes too long in Mirror. I think code reviews are top priority.

These are some notable differences between Mirror and MirrorNG:

• [Done] CI/CD pipeline. Tests are executed with every pull request, quality is enforced
• [Done] Unity package manager. Makes it easier to install and upgrade MirrorNG in your project
• [WIP] Code quality, the goal is to turn this green. Help welcome. This will have a great impact on reducing the amount of defects.
• [Done] Make it work in unity 2019.3.0 with domain reload turned off
• [WIP] Allow connection to multiple servers simultaneously
• [WIP] Error handling via Exceptions
• [WIP] Events instead of overrides for lifecycle events

Check out our Documentation.

If you are migrating from UNET, then please check out our Migration Guide. Don't panic, it's very easy and won't take more than 5 minutes.

The preferred installation method is Unity Package manager.

If you are using unity 2019.3 or later:

1. Open your project in unity
2. Click on Windows -> Package Manager
3. Click on the plus sign on the left and click on "Add package from git URL..."
4. enter https://github.com/MirrorNG/MirrorNG.git#upm
5. Unity will download and install MirrorNG

If you are using unity 2019.2, you can use openupm or you can manually add the url to your packages.json file.

Alternatively you can download it from Download Mirror

We included several small example projects.

MirrorNG supports many different low level networking transports:

• (built in) Tcp
• (built in) https://github.com/ninjasource/Ninja.WebSockets (Websockets)

So many quotes to chose from. This one in particular really encapsulates why this exists:

“All code is guilty, until proven innocent.” – Anonymous

I assume every line of code I write is broken in some random obscure corner case. The only way to ensure it's quality is by testing. I don't have time to test my software, I would rather the machine tested it for me while I work on something else. So the big theme of MirrorNG is to improve on automated testing. I am a big proponent of Test Driven Development and I want to bring this practice to Unity networking.

There are several ways to contribute to this project:

• Pull requests for bug fixes and features are always appreciated.
• Pull requests to improve the documentation is also welcome
• Make tutorials on how to use this
• Test it and open issues
• Review existing pull requests
• Donations

When contributing code, please keep these things in mind:

• KISS principle. Everything needs to be as simple as possible.
• An API is like a joke, if you have to explain it is not a good one. Do not require people to read the documentation if you can avoid it.
• Follow C# code conventions.
• Follow SOLID principles as much as possible.
• Keep your pull requests small and obvious, if a PR can be split into several small ones, do so.

Pull Requests for bug fixes are always highly appreciated. New features will be considered very carefully and will only be merged if they are the most simple solution to the given problem.