Can Someone Please Explain the State of Unity's Networking To Me Like I'm 10?

I guess I just don't get it. UNET was deprecated and we had.... nothing.

Now we have some foggy network/server relationship they are cooking with Google Cloud, Multiplay (which is a black box), WebRTC, com.unity.transport, MLAPI, DOTS Netcode and apparently a different ECS FPS network code. I haven't written anything multiplayer in Unity in a while and Unity isn't being stellar about saying what to use when. Can someone tell me -

Do these all work on the same stack - just at different levels of abstraction, or are they really different technologies that I should research independently?

We've been hearing about DOTS/ECS Netcode for YEARS now and it still isn't even production ready?

 

Unet was deprecated. Unity announced a replacement was in development. The scope of the replacement was scaled back to only the DOTS/ECS use case, and Unity bought MLAPI as the officially supported Monobehavior style networking.

Unity is actively working on modifications to MLAPI, but it was already working before the acquisition, and have already released an official package (though marked Experimental). You can use MLAPI right now. The DOTS/ECS networking is going slowly. Since DOTS/ECS itself is going slowly, I doubt that is unrelated to its networking going slowly.

The Google Cloud integrated server solution is only slightly related. It is just a hosting solution, probably with some Unity integration bells and whistles related to monitoring and spinning up and shutting down instances as needed. Given the pricing of Google Cloud, it is unlikely to be an attractive hosting solution if it ever releases. But this doesn't have much to do with Unity's official networking API's.

There's also several 3rd party networking API's. Many with good reputations. Some with different network architectures, which offer more options.

 

Thank you, that is some good info. One would wonder if maybe they've been too focused on the IPO and social issues and not enough on users' needs and the technology. DOTS + ECS netcode should probably become critical path. There has been a lot of "Experimental" or "Preview" packages that I would consider essential framework components which should have been sorted out by now. Wouldn't it concern them to hemorrhage so much multiplayer business to UE4/Epic? I'm not even sure I want to learn 2 "official" network stacks myself, not to mention all the 3rd party offerings in the Unity ecosystem. I guess we will see in April, I found this today -

.

Thanks again @Joe-Censored for your reply.

 

Unity is getting pulled in quite a lot of different directions, by different groups with different needs. DOTS/ECS is important for certain types of games into the future, so I'd agree with you that it is a critical path. One problem with that is DOTS/ECS is pretty much irrelevant on platforms and types of games Unity currently dominates. Specifically mobile games and small indie games, where MonoBehaviour makes more sense. You don't want to lose sight of the needs of such a large portion of the user base in an effort to increase Unity's reach.

But networking is one area of the engine that Unity doesn't need to provide at all. Yeah it is handy when Unity provides their own solution, but it isn't something Unity must provide. Anyone can implement their own networking using the socket class built into C#, or use a 3rd party library. There is no need for engine integration like we have in the rendering or physics areas of the engine for example.

 

Keep in mind that MLAPI is going through major rewrites because, really, it was barely usable and terribly inefficient. Use at your own risk.

Networking is far, far more than just a library to pass messages around, and the idea that, in 2021, an engine should not provide native (and robust) support is mind boggling.

It's like saying Unity doesn't need to implement a render pipeline because anyone can write their own SRP.

 

Every game requires rendering, the vast majority of games don't need real time networking. So I don't think that's a very good analogy.

 

No matter. Good networking is nearly as complex as good rendering, and to make it worse there are far less resources for learning about it out there. Yeah, you'll find some decade old articles about the concepts of server reconciliation, client-side prediction, lockstep networking and such, but actually doing that right goes through a lot of gory details which you'll only have to deal with when actually doing it, and everyone ends up reinventing the wheel.

Things like having to make builds or fuss around with symbolic links to trick Unity into allowing you to open multiple instances of the same project in order to test multiplayer, all the way to having to engineer complex build pipelines in order to build dedicated servers without unnecessary assets like shaders, textures and sounds, plus having to worry about either writing your own infrastructure (like RPCs, replications, etc) or making sure the 3rd party asset you decided to use actually does those things well and in a performant way (most actually don't), all make it multiplayer games take 10x more work on Unity compared to Unreal.

I actually recommend people who wish to make multiplayer games to not use Unity if they can. Heck, if you want to prototype an online game you're better off doing it in Roblox.

 

Not sure what you are talking about, I agree with @KokkuHub on this one. We currently use Unreal for our multiplayer game because it is basically built in and really fast. To do server authoritative multiplayer in Unity, you would have to have Unity do the physics calculations server side and replicate those results to clients. Transmitting that much data coupled with client prediction would almost certainly require a first party networking solution tightly integrated with the simulation stack which is why I was excited about DOTS. One alternative would be to do lockstep, but that is a no no on mobile. I have been waiting to try an RTS in Unity, but without deterministic physics, I'm not sure how to pull it off with different devices trying to simulate physics on different clients / architectures.