Showcase Mirror - Open Source Networking for Unity

(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:

Code (CSharp):

1. public class Player : NetworkBehaviour
2. {
3.     // synced automatically
4.     [SyncVar] public int health = 100;
5.    
6.     // lists, dictionaries, sets too
7.     SyncList<Item> inventory = new SyncList<Item>();
8.    
9.     // server/client-only code
10.     [Server] void LevelUp() {}
11.     [Client] void Animate() {}
12.    
13.     void Update()
14.     {
15.         // isServer/isClient for runtime checks
16.         if (isServer) Heal();
17.         if (isClient) Move();
18.     }
19.    
20.     // zero overhead remote calls
21.     [Command]   void CmdUseItem(int slot) {} // client to server
22.     [Rpc]       void RpcRespawn() {}         // server to all clients
23.     [TargetRpc] void Hello() {}              // server to one client
24. }

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

Low Level Transports

• (default) KCP: reliable UDP
  
• (built in) Telepathy: TCP
• (built in) UNET LLAPI: UDP
• (built in) Ninja.Websockets: Websockets
• Libuv: TCP powered by Node.js' native C networking
• LiteNetLib UDP
• Ignorance: ENET UDP
• FizzySteam: SteamNetwork

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

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!

 

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

 

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.

 

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

Thanks for your feedback.

 

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?: http://forum.unity3d.com/threads/official-multiplayer-improvements.390823/

 

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.

 

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.

 

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

 

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
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.

 

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.

 

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.

 

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.

 

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.

 

Thanks for the info.

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

Code (CSharp):

1.         // called hiding and showing objects on the host
2.         public override void OnSetLocalVisibility(bool vis)
3.         {
4.             SetVis(gameObject, vis);
5.         }
6.  
7.         static void SetVis(GameObject go, bool vis)
8.         {
9.             foreach (var r in go.GetComponents<Renderer>())
10.             {
11.                 r.enabled = vis;
12.             }
13.             for (int i = 0; i < go.transform.childCount; i++)
14.             {
15.                 var t = go.transform.GetChild(i);
16.                 SetVis(t.gameObject, vis);
17.             }
18.         }

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

Code (CSharp):

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

 

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!

 

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).

 

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.?

 

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.

 

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

 

I see. I will look into the code and see if I can find anything.

 

Good luck and have fun

 

Thanks for your work! (just posting here for checking it later at home)

 

Download will be available again soon, looking into a potential issue first

Wasn't much work yet, but thanks.

Please keep me all posted on wether or not it works in your project and remember to rebuild all clients/servers first.

 

I know that post is old. But no he isn't reinventing GetComponentsInChildren. GetComponentsInChildren goes down the whole hierachry. He just checks the direct children of this object.

 

And then calls SetVis again on each child. Recursion is used there.

 

Oh, did not spot that! My apologies.

 

Are you planning to add support for the Unet LLAPI timestamp feature? Don't think that's in the HLAPI

 

Update: new version uploaded, download link is in the first post.

• ProximityChecker GetComponentsInChildren replacement
• NetworkManager.Awake HLAPI-Pro welcome message for easy check
• Temporarily removed my ReadString out of range fix while I am researching another occurence at one of my customer's projects

Maybe later. I am more interested in bugfixes and code improvements first.

 

Hey, could you implement some authorization system on HLAPI, with a some byte[] array for example client.Connect(ip, port, data); an the server won't connect the player to the server if the credentials are wrong, thanks.

 

Update: next version was uploaded.

• [2017-08-01] OnSerialize/OnDeserialize safely
  • Problem: the reader/writer is passed through all components. If one messes up, all other components will get strange errors like ReadString/ReadByte out of range
  • Solution: data length is included for each component, buffer copies are passed to each component so that it's impossible to touch any other component's serialization data.
• [2017-08-01] OnSerialize/OnDeserialize detailed error logging
  • Problem: errors in OnSerialize/OnDeserialize are never shown. If we are lucky, we see ReadString/ReadByte out of range errors, but sometimes just corrupt data.
  • Solution: errors are caught properly before calling OnSerialize/OnDeserialize and log messages give detailed info about the object's name, component's type, sceneId, expected data size, and known causes.

Here is a screenshot of the detailed error logging:

There will be no more randomness in OnSerialize/OnDeserialize errors. They will be easy to debug.

Coming soon

You should do that in your custom NetworkManager, just send the account info along when connecting. I do that in uMMORPG too.

 

Progress: repository link added to the first post.

 

This is a great idea! If we could fix up the NetworkTransform so people don't have to write their own and get rid of massive per frame memory allocs in the NetworkAnimator then I'd be a happy camper.

 

Maybe it's a good idea to work with Unity and get these accepted as PRs (Minus the SyncVar limit increase, that can be kept out).

Unfortunately it seems Unity hasn't merged any PRs for the HLAPI, they should really think about it.

I also don't think you should change NetworkTransform, just have a NetworkTranformInterpolated.

 

Wow, this is HUGE. How did I missed this earlier?

I hope this would became a part of actual HLAPI library. Not that I wouldn't pay for it, just to keep my sanity.

If you'd fix that sceneId bug, that would be really, really goood.

 

Good morning everyone. Glad to see so much positive feedback here. Next wave of improvements coming soon.

That would be nice yes.

Will see about that yes

SceneId bug is my highest priority. I have a fix that works, except when you build the game with a scene file that you never opened before. Need to figure out how to set and save a sceneid in a scene that isn't open first.

 

Update: added a new Experimental version to the first post:

• [2017-08-02] assetId uses a prefab's m_localIdentifierInFile instead of a complicated NetworkHash128 workaround
  • Problem: Networkhash128 was used to uniquely identify a prefab based on it's path. This is unnecessarily complicated and uses 128 bytes of data and wasn't resistant to renaming.
    
  • Solution: Unity's built in m_localIdentifierInFile is a persistent unique id for prefabs, so we might as well use it. It fits into a long value, so we save 64 bytes each time we send it over the network.

This bothered me for a long time.

Now that the asset id is a simple struct wrapped around an 'ulong', NetworkAssetId, NetworkSceneId and NetworkInstanceId are just simple wrappers around built in types. Might be possible to make them even simpler too.

 

Seems really promising. Looking forward to the updates!

 

Thanks. Playing around with NetworkTransform right now..

 

Progress: turns out that NetworkTransform is a giant mess, 2144 lines of code for all the relevant components. It even has package handling hooks in the NetworkServer code.

That's way beyond fixing, so I decided to rewrite NetworkTransform from scratch.

Position interpolation is already ultra smooth, here is a uMMORPG test: https://gyazo.com/0519736c3794fa64f5c3dbf2f0287ae1

 

That link is one of the most pathetic things I have ever read. I'm sure aabramychev and the rest of the networking team are just doing their best, but Unity Technologies has a valuation of over one BILLION dollars and has over 1500 employees. The fact that they thought it was okay to leave something as important as networking to be written by the community almost makes me want to give up on Unity altogether. It blows my mind how many games released today are multiplayer and yet a company as massive as this treats their networking solution like a second class citizen. Now we rely on a single unpaid member of the community to fix something that a company with plenty of cash and staff to throw around should be working on.

Anyway, thanks for your effort vis2k! It's very generous of you to do Unity's work for them and release it for free. I will always be a big supporter of anyone who decides to create an open source project to help the community. Best of luck!

 

Thanks. I guess it's like he said, HLAPI was just an example on how to use LLAPI. The LLAPI is UNET. And that works impressively well and is far from easy to do.

HLAPI is just one way to do a high level architecture, there's value in not being tied to any. I think this architecture with SyncVars/Commands/Rpcs is really good though, it just needs some cleaning up.

 

Alex is the LLAPI guy. And how do you know they have 1500+ employees? I am not saying you are wrong. Just wondering about your sources? Only one I can find is Wikipedia. But there is no source on that number. So it could be made up.

 

You're right about Alex, I'll edit my post.

Actually the valuation is even higher than I had seen previously. This is the most recent interview I could find (May 2017). About halfway through the Q and A John Riccitiello says:

"We’re hiring 10 or 15 people a week, so yeah, that number changes. But every company like ours has some attrition. We’re at a low attrition number. We’ll probably finish the year with 1,500 to 1,600. We’re not hiring like we were two years ago, building up the company to do all the stuff we’re able to do now. But we’re still growing. Revenue is growing even faster."​

The article is actually pretty interesting if you want a sense of Unity as a company and where they are heading.

Fair enough, I mostly felt like ranting a little bit. Although I maintain there is no reason why Unity couldn't create a fully-featured, non-example, robust high level architecture for the most popular use cases, or at least they could improve the old one. It would be a huge feature win for the engine.

I don't want to derail your thread though so I'll leave it at that.
Can't wait to see your work progress!

 

How frequently are you sending position updates and via what QoS?

 

if i could chime in about the HLAPI and a possible direction of this library - what I would really like out of the HLAPI is more dependency-injection-esque patterns. for example, the HLAPI already has ways for you to supply your own NetworkConnection class to use instead of the built in one. more stuff like this would be very helpful.

the thing about the HLAPI that really sucks is that if you don't like one part of it, you have to change the source code, generate DLLs, and shove them into your unity application folder. this is tedious to maintain, especially if you have multiple HLAPI unity projects on your computer. ideally, it should be a cinch to inject changes into the HLAPI at the project level and not the system level so that all your different projects can play nicely with each other. it would also make upgrading unity versions a lot less painful

 

It uses the DefaultUnreliable channel like the original one. There's another issue with default channels that I want to work on too. So right now the code always assumes that DefaultUnreliable is channel 0 in your NetworkManager. But if you reorder them it might wind up using Reliable, StateUpdate or whatever other channel there is in the first slot. Unless I am missing something. Will have to do more research there soon.

Frequency can be selected by the user via 'Send Interval' in seconds. So a smaller send interval means more updates. The video uses 0.1s. I just tested 0.5s and that works just as well.


The original NetworkTransform sets the position in OnDeserialize immeditately without any interpolation, so any interval should look smoother than before.

Would be best if we can put the Scripts in the editor directly. Right now this is not possible because parts of NetworkTransport are internal. I mentioned this to Alex.

 

I suggest using the Unreliable Ordered. Otherwise this might happend:
We get an update. And move them there.
We then get an older update. So we move them back!?
We then get an even newer update. So we move them really far ahead

 

True. My current interpolation method keeps a history with timestamp anyway, so packets arriving out of order won't be a problem.

 

Keep going vis. You're doing well. Everyday we move closer to multiple scenes with a fixed HLAPI. I'm glad I could bring the Readbyte but to your attention and am happy that you have it working. Cannot wait until scenes are done, everyone is extremely pleased with what you have done so far.