Official UNet Deprecation Thread

snip

snip

This is really the most important point. The only part going away is the Transport/LLAPI. The HLAPI is open source, though it will be useless without the LLAPI. There are many transports out there that can replace it either in your code or in a higher-layer abstraction like the HLAPI. This should serve anyone managing to ship networked games in MonoBehaviour projects for as long as people care to build and maintain them.

I would highly (and specifically) recommend https://github.com/MidLevel/MLAPI to anyone going that route. It's actively maintained as of today and a genuine improvement over the HLAPI. The maintainers actually understand what they're doing regarding both networking and writing clean Unity code.

 

@BHouse
I'm trying to upgrade a project that uses LLAPI to Unity 2018.3 and it gives a ton of warnings about deprecated classes such as NetworkConnection, NetworkReader, NetworkWriter. Is the new network API already available in 2018.3 or am I stuck with these warnings until 2019.1 comes out. This is very annoying and for some compiler setups like treat-warnings-as-errors this means it can't be compiled at all. (Speaking of which, it seems that enabling -warnaserror in 2018.3 produces errors about fields marked with [SerializeField] not being assigned, even though they don't show up as warnings without this option. But that's another issue.)
The bottom line is you shouldn't give deprecation warnings unless there's a viable alternative to deprecated classes and methods.
Also, does this mean that there won't be an overlap in Unity versions when both old and new APIs are available?

EDIT: Seems I was wrong about "fields not being assigned" warnings. They do show up without -warnaserror after all. Guess it's just due to migrating to Roslyn and is going to be fixed soon.

 

2018.3 does not include the new networking API. They have not announced the specific Unity release where the new networking API will be available. They have announced that Unet will be stripped out of 2019.1, which is why you're being warned about the deprecated API. Otherwise Unet will be removed with zero deprecation warnings from the editor when 2019.1 drops.

 

That is annoying, but also it's the point of both deprecation warnings and the treat-warnings-as-errors option. Together, they can save your butt when working in a big code-base with automation. Better to be annoyed than have your networking API disappear out from under you unexpectedly, right?

 

Awesome, this is indeed a good step in improving the developer happiness

 

imma save you some blood, sweat, tears, and time, and kindly offer this advice: forget about unity networking. Forget about unet, HLAPI, LLAPI, forget about it all, and forget about whatever they say they are working on as a replacement. Take a big deep breath, and let it all go.

If you are already working at the packet level, serializing bytes etc, ditch LLAPI and use something else that is established, maintained, has support channels available, and has actually been tested to work. There are options available.

This information has helped me out:

• https://forum.unity.com/threads/ben...dgren-miniudp-hazel-photon-and-others.512507/
• https://github.com/nxrighthere/BenchmarkNet/wiki/Benchmark-Results

I am currently in the process of porting my project from LLAPI / transport layer to ENET, due to the incompetence (and now obsolescence) of unet.

For serialization, i recommend ZeroFormatter:
https://github.com/neuecc/ZeroFormatter

 

I also switched our engine to ENET, it is working great and stable. it solved a bunch of weird bugs we were having.

 

I experienced a similar issue with LLAPI as soon as I upgraded to 2018.3 beta last thursday or friday. My LLAPI code completely stopped working, had all these weird bugs going on. I was debugging it all weekend trying to figure out what was wrong. When my client was connecting, my server was receiving double connect events, one of which was coming from the port the server was listening on, which is behavior i have never seen before, and doesnt make any sense. The client side was not receiving any data events whatsoever, even after writing code to mitigate the buggy connect events that were coming in. I still have no idea, I'm fairly certain something is bugged with LLAPI in the 2018.3 beta. The code had been working in previous editor versions.

Today i replaced LLAPI with ENet in a matter of a couple hours, everything is working great again. It actually took a lot less code, things are much cleaner now.

 

I've recently posted a reply here it might be interesting for guys who work with ENet. This system is utilizing it for low-level communications over UDP, and all the stuff that related to ENet is performed independently of a game loop. The inter-thread messaging system delivers data across the threads. This system is stable, safe, and almost GC-free.

 

@nxrighthere Do you have plans to release parts of that work? Right now I hooked enet into the fixed update loop, it works fine but perhaps it is not so scalable.

 

I'm going to release this system somewhere as soon as I finish working on a fast AoI logic and smart data compression based on world space bounds, a distance between visible entities in the scope, and other stuff. It's only the two things that still at the work-in-progress stage.

 

We naturally have our own data packing, and compression algoritms, to smartly add all data together and send it off in one package, I guess it will be harder to hook that into your work?

 

Nah, it's very modular and flexible. We have a core, buffers, serialization, cryptography, transport, some modules like UPnP/PMP port forwarding and so on. You can remove anything you want just in seconds, and use raw byte arrays instead of the built-in serialization. The core module will take care of concurrency and scaling, you only need to feed it with any data that will be sent across the network or to a particular peer just like with the ENet, but at a bit higher level.

 

I moved all my UNET projects to Mirror! (https://assetstore.unity.com/packages/tools/network/mirror-129321) Easy migration, works actually and has great support on Github, Discord and Unity forum. Can totally recommend it!

 

@Red_Dragon69 Carefull with that, it's based on a TCP transport layer, depending on your game it could bring huge delay problems.

 

You can use any layer that you want, TCP is just the default.

 

In the GCP suite of services, Firebase is their mobile-specific suite, and it's powered by some excellent GCP services and infrastructure. Given Unity's goal to support a breadth of platforms, you can expect our new join solutions to work for a broader range of platforms.

 

We actually ran some benchmarks with the f1-micro with the fps sample game, and it's unfortunately not sufficient and likely won't be for most games. No other news on pricing yet; still working out options here.

 

As others mention here, these warnings are just to ensure people are all aware that this is coming down the pipe.
The new transport will be a package, which means it is not in 2018.3 directly. But it will be available as a preview very soon in its initial bare-bones form. We will continue to ship updates and new features frequently; packages mean we can update as quickly as possible without being tied to releases every 4 months.

The hope is that most critical features of the LLAPI will be available before 2019.1 hits; however, if this is not the case, we very likely will delay the removal of LLAPI until it is.

 

I see there was some announcements yesterday regarding the new networking architecture?

https://blogs.unity3d.com/2018/10/24/introducing-the-fps-sample/
https://unity.com/solutions/real-time-multiplayer/network-transport-layer

For those of us who want to get a jump on this asap, is the best place to start by downloading the sample project or git repository?

 

Thanks a lot for info @BHouse . I'd like to ask another question.
Will we be able to launch multiple game server instances per VM ?

 

I'm getting warnings that say the following:
'NetworkIdentity' is obsolete: 'The high level API classes are deprecated and will be removed in the future.'
What I found distressing is that this is the only time in well over a decade of programming that I can remember seeing a deprecation warning without telling you what to replace it with. So the question is: what do I replace it with?

My Master Audio Multiplayer plugin needs nothing other than the NetworkIdentity from UNET to do what it needs to do (find the same game object on other clients). How will the next system handle this?

Should I not worry until beta Unity 2019 comes out at which point it won't compile and customers will start complaining?

 

I've been complaining about this too - it's quite unprecedented in my experience to deprecate a feature when there is barely anything to replace it yet.

Right now you have no upgrade route at all. Judging by the FPS sample Unity seem to want everyone to build their networking on top of their new low level transport system so there won't be a standard UNet identity object you can hook in to. If you're lucky, later they'll release something in a package that vaguely resembles this system, and you will be able to have your plugin use that package, if (and only if) your customers are also using that package for their game.

 

@BHouse What is the plan regarding HLAPI? currently it is all deprecated with no replacement,

Do you expect indie developers to interact directly with the new low level networking API?
Are you going to provide a new high level API for networking?
As I understand it, HLAPI will be turned into a package but at some point support will end, so what then?
Do you expect third party libraries like MLAPI and Mirror to fulfill this role?

 

https://unity3d.com/unity/beta/2018.3

The docs are not helpful as of yet:
https://docs.unity3d.com/2018.3/Doc...etworking.NetworkManager-activeTransport.html

 

@jerotas You can try to replace UNET components with the Mirror (https://assetstore.unity.com/packages/tools/network/mirror-129321) equivalent. All components from UNET should be replaced with their corresponding component from Mirror. As this is very similar to UNET it should not be a problem. Please refer to https://github.com/vis2k/Mirror/blob/mirror/migration.md

 

So what I don't understand is about the timeline.
WHEN exactly are we getting the replacement tools for the HLAPI?
Will it happen before deprecation of the current toolset, or will we need to deal with a window of time where Unity will have no in-house networking support at all?

 

Folks seem to be confused (...ok, hyperventilating might be more accurate) about this topic. I'd suggest an example guide on how to use HLAPI with literally ANY other transport than UnityEngine.Networking since the HLAPI has been updated to support it. Explain what requirements there are for that transport, etc.

 

I'm an indie looking to make a fairly complicated online game, and I'm really struggling to see what the right tools are to use for it. Do I use UNet? Do I invest stupid money in Photon? Do I WAIT for this new system?

I'm just one guy, and I have bills to pay. I can't wait indefinitely for this new networking system, but I'm being told not to use UNet because it's going to be phased out. As far as I'm concerned, Unity3D currently has zero networking capability.

I NEED a release date.

 

There's a free version of Photon. Why do you need to pay for it?

 

Hi, just started learning UNET, and found out now about the depreciation.
I had previously been using Unitys Legacy Networking, and have a few successfully released games.

My questions are:

1. Should i continue learning UNET and have a joyful 2 years before it goes?
2. I know photons popular, but can i use my own servers with them?
3. Is this new Unity networking in a usable state, with tutorials and docs, to implement and release games on, or even update my current ones to?
4. What should i learn and use now/instead?
   
5. Is 'connected games' the name of the new networking, or a generic term being used?
6. Is this just regards to the hosting/joining, or the client server RPC code too?

 

I have spent the weekend retrofitting my small multiplayer game to support the new multiplayer package. I think its looking great. It is really interesting to take a modular approach and that it already supports the new job system.

One thing I am not happy with however is that you've already deprecated UNET without providing a stable and feature complete alternative. Deprecating it to tell people that it will be removed in the future is not a good idea unless theres already a viable replacement available, because you are actively (every time I recompile the project, which is hundreds of times per day) telling me that there is a problem in my code base without giving me a solution for how to fix it. This is bad game design

One thing I am especially missing from the new API is the an easy way to broadcast over UDP so that clients can easily find the server that has been set up on LAN.

 

Wow that's good news! I honestly thought it was quite expensive with their servers and whatnot. I'm going to give them a trial run now ^^

This goes to show though, that for idiots like myself, all these options are just confusing, not helping. I'd love a "works for all" type thing, and I think that's what Unity are aiming for in all fairness to them.

 

Understandable. There are so many networking options it can be quite confusing. I'm not sure exactly what the differences are between the paid and free Photon versions aside from some credit but it's worth checking out.

 

There's also several other free networking API's, the free Mirror project port of the Unet HLAPI, and the Socket class.

 

That's a fantastic suggestion for me! I'm comfortable with the UNet HLAPI so it's great to see a community driven one. Having looked into Photon a small bit and seen the CCU charges and still yet to find a code sample I can trust, I feel other 3rd party networking tools are, in general, going to be more complication for me to learn than my game would warrant.

To quote from the Mirror asset store page.. "Mirror is optimized for ease of use and probability of success" That's just so what I'm looking for. Thanks again!

 

Wow, I'm glad I saw this now. I have far too many projects running on UNET that I now have to start preparing to redo... and more than a few in-flight projects. Fortunately, most of them I can deviate and move to Photon. Others I'll probably just shutoff when the time comes. And other projects of mine with clients, well, I suppose that'll be for them to figure out. But it does make me wonder about the future state of Unity Ads, AR Foundation, built in Vuforia and all the other less used features... and it certainly creates a strong argument about the risks of trusting Unity's built in frameworks. I suppose that settles my AdMob vs Unity Ads debate I was having today.

I'll definitely check out Mirror, thanks to those that shared it. For what its worth, I'm not likely to invest time into some C# git repo they want us to pick apart (assuming I read that correctly) - it sounds counterproductive to using an all-inclusive middle-ware game engine. And if I went down that path, I'd have to start reconsidering Forge, etc etc.

Personally, I do get that changes need to happen, and planning to cut off services for a handful of clients is a worthwhile thing to the Unity folks. It isn't the first time they've done something like this and I am thankful that we have more notice than usual. Even if they don't have actual answers yet.

 

I asked a question here: https://answers.unity.com/questions/1570289/simple-game-networking-solution.html which might have better been asked on this forum. In summary, i want to learn about networking but i am not sure which tech to get started with. For a very simple Bomber man game that the players can self-host, what would be the recommendation? Mirror? Or will that be easy to do with the new system and i should hang tight? Six months is not really too long to wait as this is more about learning than producing a commercial product.

 

Sorry for hijacking the thread, but since no one else seems to reply: don't panic.

Unity will make UNET a package, so you can still use it for a while.
If they do remove it, you can still keep using whatever Unity version you use right now to release your game.
If you encounter bugs or want those changes that we did in Mirror, you can still switch between UNET and Mirror relatively easily. (We keep Mirror compatible with UNET, except for the parts where it really does make 100% sense to change things)

As for long term support: Paul and I both need it for our projects, we don't have a choice

 

Appreciate the reply! Sounds like I cannot go horribly wrong with UNET.
The only other question is whether the new Unity solution is worth using in my scenario of being a complete beginner to networking and wanting something that does not required any paid hosting for a simple networked game.

 

I wouldn't necessarily jump to that conclusion. They've told us flat out if you plan to use unet, to expect their servers to stop working in a few years. And that for now they have no replacement outside of a self hosted sample project they themselves don't recommend using. There is a reason they are announcing discontinuation before having a solution, another project manager may very well decide to abandon multiplayer entirely in 6 months (it wouldn't be the first time they did something like that) and hey that's OK. We just have to plan accordingly.

I'd wager unet to be a moderate risk to use at this time and future unet as a potential fantasy project.

Given your intent, I feel you'll get more out photons free server (mirror you may need to run your own matchmaking server eventually too). Photon still depends on their userbase and exist beyond just being used by unity. Comparatively, unet isn't a core business service for Unity and they can treat it as disposable when it's inconvenient. A company like photon is much less likely to do so.

But if you don't mind redoing work down the road and learning a framework that's being discontinued, by all means pursue it, I really liked it as a framework. I wouldn't invest time in future unet projects at this time though unless you're really bored - I doubt it will be even moderately usable and stable for another year or two. They only recently stabilized unet which took a great many years.

 

Not an answer that makes me feel i have a clear and easy choice to make but a useful answer none the less! Thanks!

 

You don't need the Unity Multiplayer services at all for UNET. You can host it anywhere you like, but it seems like Unity didn't make this very clear from the beginning.

 

Good point - I had originally said that in my reply ... but it must not have survived the edit . If someone feels like hosting their own matchmaking servers etc, has access to do so, and is confident about the future stability of UNET - it is certainly an option .

 

can someone point me in the right direction as a networking beginner and the whole disaster of UNET, if i want to use MLAPI for dedicated servers what do i have to learn and where? what about ENET which is not unity integrated how do i make characters/components/collision talk to server and replicate to other clients?
Im completely lost as beginner, im no good with C++, so im stuck with unity C# but i really want to get into networking the games/prototypes i made need to be online and i have no clue where to go next, everyone seems experienced already and found their own solution, me on the other hand.... totally lost.

 

There are 2 types of networking frameworks: low level and high level

Low level libraries allow you to send messages between a client and a server. Typically they are referred to as "transports". There are several libraries you can chose from. some examples:
* LLAPI it comes with unity, It has been deprecated and will be removed from Unity.
* ENET C++ based transport
* DarkRift
* Telepathy
* LiteLibNet
* Photon
* Steam

While you can use these libraries directly, most people prefer to use high level libraries that make life easier. The high level libraries can be used with any transport. The high level libraries deal with sending messages between gameobjects/components instead. They also deal with synchronizing data in gameobjects. Your options are:
* HLAPI it comes with unity, it has been deprecated and will be removed from Unity. It has lots of bugs.
* Mirror it is a community fork of HLAPI. It is meant to be simple and robust. Easiest for current HLAPI users.
* MLAPI is another framework that focuses on features and performance.
* Photon somewhere in the middle, not as easy, but well tested.

If you are starting a new game, I would recommend you take a look at either Mirror or MLAPI. You can use any transport and even change it later without changing your application.

 

I think it would be fair if Unity clearly communicated in the docs and in UNET tutorial (https://unity3d.com/learn/tutorials/s/multiplayer-networking) that UNET is being phased out and does not have a future. Nobody should invest their time in learning UNET anymore.

Frankly, it was quite unpleasant to find out (somewhere in the forums) that the HLAPI was "just a demo" made by some guy (who had left Unity years ago) after investing a lot of time and effort on learning and utilizing UNET.