Mirror - Open Source Networking for Unity

Community Showcases
1

2749068--701343--mirror_icon_1200x630_M_smaller.png
2749068--701343--mirror_icon_1200x630_M_smaller.png1200×630 202 KB

( Mirror) (Mirror LTS) (Forum ) (Discord) (Docs) (Sponsors)

Stop worrying about networking. Because we do.

Mirror
Mirror is a high level Networking library for Unity, compatible with different low level Transports.

Mirror is for small indie games & large scale MMOs, made by the developers of uMMORPG and Cubica.

Mirror is optimized for ease of use & probability of success.

We needed a networking library that allows us to launch our games and survive the next decade.

Architecture

The Server & Client are ONE project in order to achieve maximum productivity.
Simply use NetworkBehaviour instead of MonoBehaviour.
Making multiplayer games this way is fun & easy:

public class Player : NetworkBehaviour
{
    // synced automatically
    [SyncVar] public int health = 100;
   
    // lists, dictionaries, sets too
    SyncList<Item> inventory = new SyncList<Item>();
   
    // server/client-only code
    [Server] void LevelUp() {}
    [Client] void Animate() {}
   
    void Update()
    {
        // isServer/isClient for runtime checks
        if (isServer) Heal();
        if (isClient) Move();
    }
   
    // zero overhead remote calls
    [Command]   void CmdUseItem(int slot) {} // client to server
    [Rpc]       void RpcRespawn() {}         // server to all clients
    [TargetRpc] void Hello() {}              // server to one client
}

There’s also NetworkServer & NetworkClient. And that’s about it .

Low Level Transports

Getting Started
Get Unity 2018/2019 LTS, download Mirror on the Asset Store, open one of the examples & press Play!

Check out our Documentation to learn how it all works.

Popular Games made with 2749068--734071--2020-11-11_14-14-16.png

Population: ONE


Zooba


SCP: Secret Laboratory


Naïca Online


Laurum Online


The Wall

Development & Contributing
Mirror is used in production by games ranging from small indie projects to large scale MMOs that will run for a decade or more.

10 years from now if your players encounter a networking bug and most of our contributors already moved on, someone will need to fix it. Therefore it is of utmost importance for us to follow the KISS principle in order for our games to survive.

Keeping the next decade in mind, contributing fixes / tests / improvements is highly appreciated while new features have a low probability of being merged.

At this point, what we don’t add to Mirror is more important than what we do add to it!

62 Likes
2

If it contains a better designed and stable and documented LLAPI to use, i would like to pay.
Also, Websocket support is needed.

2 Likes
3

I would buy a NetworkTransform fix alone. 5 bucks USD sounds fair, maybe 10 if it’s smooth as butter. I want it to be virtually identical to the current one, only it works properly. My only request really.

4

I don’t intend to modify the LLAPI, only the HLAPI. The LLAPI is closed source anyway.

Thanks for your feedback.

5

I’d definitely be interested in paying for that. Especially if I can see the stress test results, which would reassure me that this would be a good and dependable option for my projects

PS: if you do manage to successfully communicate with the rare unicorns working on UNET, can you please try to drag them back here in the forums and make them read/comment on this thread?: [Official] Multiplayer Improvements - Unity Engine - Unity Discussions

6

Good to hear.

That reminds me, I also have a lot of SyncListStruct examples (including hooks) that would probably be interesting for a lot of people too.

I am sure they do read the forums every now and then.

1 Like
7

Paying for it wouldnt be an issue, although if it was free but based on for example donations/patreon/etc then more people could adapt it to their projects.

8

Patreon is a good idea too. Will add this option to the first post.

9

I’m most interest in premium support or complex examples as those provided by Unity are oversimplied for me and don’t cover many typical use-cases. While I am a programmer, programming network stuff is still a bit of magic for me and I would gladly pay to learn some more of this magic :wink:
More features are secondary for me, at least for now.

P.S.
NetworkTransform with Rigidbody synchronization works good enough for me (as it does movement interpolation) so I don’t quite understand why is this issue mentioned so often.

10

There is no question about the current UNET flaws and the urgent need for further improvements. So any kind of initiative is more than welcome.

I have one concern though. If you go that route with custom HLAPI, in the end, we have both native UNET HLAPI and HLAPI_fixed. That means we have 2 different HLAPIs which are developed independently by different people. This has some potential for confusion and I guess also for problems. For example, what happens if official UNET implements significant updates to the original HLAPI but I am now using HLAPI_fixed and it is not updated as well? Also, support could become an issue.

Maybe this is a good idea still. But before going this way, I would strongly recommend to first get in direct contact with the UNET devs and try to establish some kind of official collaboration. So that you can directly work together with the UNET team to get your improvements in the official branch. Maybe even something like freelance UNET improvement task force. Then, we would have both a faster improvement progress and official support and maintenance. And above all, a single stable and feature-rich HLAPI that everyone can use, with a single documentation and community. If this way does not work out, okay, then you could still take the custom route.

1 Like
11

NetworkTransform is laggy for most people when trying it over the network.

Valid concerns.

If enough people end up being interested in this project, then I will contact Unity first of course. For legal reasons, etc.

I definitely don’t want to reinvent the wheel. Phase 1-3 are very important and can be developed without messing with the HLAPI core (NetworkManager etc.) at all. Component based development allows us to replace NetworkTransform, NetworkProximityChecker, etc. easily. Allowing us to replace and create our own components seems to be one goal of UNET anyway.

Phase 4 would be more difficult, if we decide to replace more critical components like NetworkManager. Don’t get me wrong, I really don’t want to do that. This would be a nightmare to deal with. Keeping it up to date with the latest official HLAPI code would be hard. Just like anyone else here, I am really only interested in launching my own online game. If UNET would have the same quality like other Unity components, then we wouldn’t have this discussion in the first place. Sooner or later, many of us will launch their games though. If critical bugs in core components are found, then they will have to be fixed. Let’s hope we don’t get to that point though.

12

We are currently developing MMORPG for our client and the lack of update in Unity network is really becoming our main concern. It would be nice if you can get the collaboration from UNET developers. I fully support your plan and I am willing to pay for your effort.

13

Just to be clear on legal matters: Anyone can freely modify, use, re-distribute (for free or for a fee) or do anything they want with the high level API source we published on bitbucket (as explained in the LICENSE file in the repo). Nothing to worry about there.

You can work on the project, and do fixes/modifications/improvements, and it’s up to you if you want to make them public and available for us to integrate if that is suitable or to keep them private (or publish on asset store with a price tag). It should be easy to switch out components (like NetworkTransform) and exchange with modified or customised versions. Of course if the core is changed too much it will be harder to integrate patches from us but that’s up to you.

We’ll have an update soon on our immediate roadmap so you can see what changes are incoming in future releases.

7 Likes
14

To answer your question I would be willing to pay.

Do to personal issues i have been away from the Unity scene. I recently started up again with the idea of using UNET. I had no idea it was in such a bad state with no signs of improvement. Although i think it is great you are willing to take on this challenge. It is unfortunate that Unity has let it come to this.

15

Thanks for the info.

By the way @larus , it looks like you are trying to create your own GetComponentsInChildren function in NetworkProximityChecker:

        // called hiding and showing objects on the host
        public override void OnSetLocalVisibility(bool vis)
        {
            SetVis(gameObject, vis);
        }

        static void SetVis(GameObject go, bool vis)
        {
            foreach (var r in go.GetComponents<Renderer>())
            {
                r.enabled = vis;
            }
            for (int i = 0; i < go.transform.childCount; i++)
            {
                var t = go.transform.GetChild(i);
                SetVis(t.gameObject, vis);
            }
        }

Even though it already exists and can be used like this:

        // called hiding and showing objects on the host
        public override void OnSetLocalVisibility(bool vis)
        {
            foreach (var r in GetComponentsInChildren<Renderer>())
                r.enabled = vis;
        }
16

Update: HLAPI Pro V1.0 released for Unity 2017.1.

After reading @aabramychev 's post about how no one created a better HLAPI , I figured I should finally do it.
Please read the top post for all the details. V1.0 already has the fix for the ReadString out of Range bug that happens randomly in every single UNET project.

Please reply if you tested it, if you like it, if you have questions or suggestions. Please tell me what you want to see in the future. Source code access and license info will come soon.

Let’s fix UNET!

10 Likes
17

Thanks for your efforts! I’m looking forward to test it.

One suggestion: I would appreciate to have more transparency and information on bandwidth consumptions when using particular HLAPI methods. I know that this is more a matter of documentation, but maybe you decide to add some additional documentation as well (ofc only where it is needed).

1 Like
18

Which methods in particular? Do you mean ‘how many bytes a Rpc uses’ or do you mean ‘how many bytes a SyncVar uses per second’ etc.?

19

I think both. It would be helpful to have clear information right from the start, e.g. about header bandwidth consumptions or for magic stuff that is going on under the hood. Especially for the relevant methods such as SyncVars, Commands, RPCs, SyncLists, etc. I have once started a thread about this here. I think such information should be part of the official UNET docs but it’s not there yet. So, it might be a beneficial option for additional docs.

20

Great work. A fix for the readstring bug is huge on its own. Thanks for your work.

1 Like