UNET transition - advice needed

Unity Engine
,
1

My team and I have been building a peer to peer game. Originally we used unet - though it was fairly difficult to get set up as I am a noob at networking. Now that we’ve been developing a while and improving/refactoring our code base, we are running into latency and syncing issues.

Seeing that unet will be deprecated and removed by 2021 - we would like to utilize a small library to keep our tiny game moving as we scale.

We have looked at mirror and photon as potential alternatives. Does anyone have any advice for we noobs? Much appreciated.

2

I hear good things about Mirror

1 Like
3

Glad to hear you’re making progress in networking!

Correct, Unity’s HLAPI will be dead by then. And I must clarify that this is old UNET, not related to the new networking stack Unity Tech is working on.

It really depends on your game. If you are not wanting server authoritative (ie. you tell the server to do things and the server then does things, sending you back the results) networking which Mirror excels at, then Photon is probably the way to go.

Photon does have a peer to peer-based solution, so you’ll have to implement things to avoid data tampering etc. However, it does have a 20 CCU limit for the free tier before you have to pay a monthly subscription fee, while Mirror does not really have such limit - all it needs is a $5 per month VPS (virtual private server) and it’ll run fine. Heck, I run a few in-house test VPSes on the Vultr $5 plan and Mirror runs cosy on them.

Mirror has also the benefit of a UNET Converter that does a solid job at converting old UNET projects into the Mirror equivalents, and if you’d like more info on Mirror, drop by the discord - we’re a friendly bunch.

At the end of the day, other network solutions like Forge Networking Remastered and DarkRift Networking exist too. However, I have not used them enough, but I acknowledge their existance. My honest advice? Just do your homework before committing to a networking solution.

2 Likes
4

I would recommend

:stuck_out_tongue:

2 Likes
5

I suggest looking at MLAPI (my own) and continue to look if Photon fits your needs. Photon is good for what it is, but if you need something similar to UNET I suggest my own MLAPI.

As for Mirror, I suggest you be careful. The Mirror project seems to be ran on pride rather than creating a good product. Mirror is just a fork of UNET, and since the project was forked, little evolution has occured. That’s not to say it’s not changed. It has changed. Things have been removed, others added. But no real project evolution or major features have been introduced in years.

The project authors want to appeal to a uninformed audience by stating “MMO Scale”. This is only backed up by nonsense benchmarks with no real value. I have asked for real benchmarks that shows the raw speed, but the requests have been ignored. (Source: Mirror forum thread, also their Readme contains links to benchmarks).

I submitted a bug report over 2 months ago containing a servere security flaw that allows you to bypass authentication in Mirror. The author closed the bug report saying it was fixed when it was not. (It has since been reopened, but not fixed yet). This shows that security is on low priority. MLAPI for example takes this very seriously, we offer built in encryption. (Source: Potential ghost clients: Client side connection initiation · Issue #721 · MirrorNetworking/Mirror · GitHub)

For a long time, the Mirror licence discredited their contributors. It stated that Vis2k, the author of Mirror owned all copyright which he did not. I pointed it out in a GitHub issue, it was closed with a comment stating that someone told them to do so. This is super dishonest and just not right. It has since been fixed, but still shows that great lengths go to not fix simple things. (Source: Fix licence typo · Issue #952 · MirrorNetworking/Mirror · GitHub)

The project developers prefer to give you answers rather than features. They explain away things because of lacking competence or otherwise. As an example, Host migration (in fairness, a fairly complicated feature to implement) was included in UNET. It was stripped from Mirror like a year back. The reason stated in the commit message was that it was not stable. Instead of fixing it, it was removed. When people later asks the developers why it was removed, it was stated “it relied on third party Unity services”. This is incorrect, A clueless answer with no correction after being pointed out. (I can provide source if needed)

Its further reflected in issues like this: SSL for websockets · Issue #947 · MirrorNetworking/Mirror · GitHub
SSL is pretty much a must, and they dont want to do it right now, so they close the issue. Instead of fixing it, sweep it under the rug. Simpler hey. Make it look good, dont make it actually be any good. This occurs for most features, requests and redesigns. Someone proposes, closed with “not right now” type of message.

Simple things like that shows that the operation of the open source project is sketchy. It’s ran by pride rather than a strong development. Instead of creating good features, and a fast library. They rather post bogus benchmarks that are impossible to get any useful data from instead of adding the features and making it faster. Mirror is thus not something I would use for production for the given reasons.

You can look at a nice feature chart found here: https://mlapi.network/features/ (anyone can modify this chart, it’s fair)

1 Like
6

@TwoTen I added some needed explanation for the benchmarks here:
Mirror - Open Source Networking for Unity page-27#post-4758365
If you have other suggestions for benchmarks, let’s hear them.

License issue should be fixed now. Thanks for pointing it out.

You are right: we don’t want to add some features, especially if they will end up introducing complexity and not enough value. Host migration is 1) not needed for our projects, and 2) very difficult to do correctly. The added complexity would raise the probability of bugs, so we are unlikely to ever add it to Mirror. Host migration was indeed included in HLAPI, but it never worked correctly.

That said, it is not like we are holding the code hostage. All the code is released under the MIT license. We would welcome people to fork it and add these kind of features themselves if they want to. I see very little value in including a half baked rarely used very buggy feature with Mirror. It is a lot easier to fork and add a feature to Mirror than HLAPI, and we have taken several steps to facilitate this.

About the security flaw defect you opened, I acknowledge it could be better and it was a mistake to close it. That said I would not call it severe. There is no known way to exploit it. None of the built in messages are vulnerable to it. Don’t get me wrong, it should still be tightened up, because someone out there might write a vulnerable message handler without realizing it.

No project is 100% perfect, and there might be different point of views. But we must be doing something right, since we have hundreds of members in discord, and steady growth in github stars. Clearly we are making a lot of people happy.

Anyway, thanks for the feedback. You work hard on MLAPI and you must be proud of the features you have.

1 Like
7

Yes I understand, no project is perfect. I am not telling you to change anything, or stating you are holding the code hostage. You can do what you like, all I am saying is the given reasons would make me not use it for production, especially when there are alternatives out there.

And yes, of course people get happy when you fork UNET, that doesnt make it the best choice for others projects.

I would argue other libs are a better choice than Mirror, but i’m of course not saying Mirror is useless.

Always pick the best option, and one of the most important things IMO is what coburn said, do your homework.

1 Like