Official UNet Deprecation Thread

[Edit: removing old sticky threads as our new SA team begins to manage this forum]

*Update 2/14/19*
We've been following user feedback, and took some time to discuss internally; we want to share a few updates:

1. LLAPI guaranteed in 2019 LTS build - due to demand for more time to transition and give the new transport more time to mature, we've decided to guarantee that the LLAPI will remain in the engine in the 2019 LTS build at the end of this year, and therefore will be supported with critical fixes in that build until Spring 2022. This is a 1-year extension from the original plan, and we will soon update the original blog post to reflect this change.
2. Plan of Intent for Networking - the networking team has published their current priorities and focus areas to the public git repo - it's their goal to keep this up-to-date with each of the projects we're currently working on. We've been seeing solid progress internally, and we're hopeful that some of the work-in-progress items listed in Github will be in the hands of the community soon.
3. DOTS-compatible - the new networking stack will work with ECS, Job System (for multi-threading), and Burst Compiler to reach the best possible performance and scale. AND, it does not require you to use DOTS for everything, most of your game can still be written in classic unity if you prefer that.
4. HLAPI support LLAPI and new transport - HLAPI will be released soon as a full-source package, and will be supported according to 2018LTS terms, so critical fixes will be provided until Spring 2021. This has not changed from the original plan. For clarity, The HLAPI will support LLAPI and the new transport (once it reaches a sufficient feature set) throughout this transition period. We feel confident that before 2021, the new networking stack will be a much more performant solution than the HLAPI, and we strongly recommend developers move over by this date.

*Original Post*
Through our connected games initiatives, we’re committed to making multiplayer game development easier, more transparent, and multiplayer-ready by default. To reach these goals, we need to start anew. This means “UNet” features will be gradually deprecated. Here’s what’s impacted, as well as our support timelines.

• The HLAPI and LLAPI will no longer be included with Unity after 2018.4 (LTS): Critical fixes will be provided for two years following the 2018.4 (LTS) ship date, consistent with Unity’s Long-Term Support policy.
  
  
• The Relay Server and Matchmaker service will operate for at least three years after the 2018.4 (LTS) ship date, with a clear transition plan provided before this date.

To learn more about why we are deprecating UNet, and the timelines, see Evolving Multiplayer Games Beyond UNet.

Many great games depend on this technology, and we know these changes may have a significant impact on your games; our teams will be actively monitoring this thread for deprecation-related concerns and discussion. Please post here to ensure we monitor and respond to feedback efficiently.

 

Given the status on my teams UNET development status, question is:

1) When will we be able to replace UNET fully? ...should we stop the current UNET implementation?
2) Pricing, can you please give some indications?

 

1) It really depends on how soon you plan to launch your game. Our guidance for now is that if your game plans to launch in the next 6 months, and you've already done a good bit of integration with UNet, it's ok to go ahead with your current plans. If it's beyond that timeframe, the new tech stack may be the right option, and it's worth investigating how you may update your game to have server-authoritative code.

2) We recently announced our alliance with Google Cloud, and dedicated servers in our stack will generally be hosted with them. The pricing model behind these VM's is publicly available (it's a consumption-model), and it's our goal to offer fair pricing to our developers (details aren't fully defined, so I can't share more yet). Your best bet today is to estimate costs using GCP's calculators and the profile of your server code (i.e. using a "headless" and preferably Linux runtime to reduce costs). In the meantime, we'll continue to focus on reducing the overhead of the headless server runtime to reduce the costs of servers, and the Multiplay-based orchestration tech will ensure servers are only running and consuming resources when your players need them.

 

I hate being dramatic about things on internet forums, but Unity really needs to release more details about the UNET replacement along with this deprecation notice.

Namely: What is the release window for the stable, ship-worthy, 1.0 replacement? The blog mentions "next-generation networking features will be made available soon" -- with no indication of what development state the features will be in. Also, the term "soon" is so vague it implies things are too far out to even estimate to a quarterly window.

However, the earlier the deprecation notice the better, so maybe that's what Unity decided on despite the lack of details?

EDIT: BHouse, you were kind enough to reply with more details on the blog post, so quoting them here for others:

This makes sense. I'm glad there's a planned feedback period, even if it means a few versions of Unity 2019 will effectively ship without an officially supported Unity multiplayer solution -- IMO, that's better than wasting resources on the deprecated UNET in 2019.

 

It's in the blog post.

 

Will the New Networking Layer source code be made available like the current networking layer is? Even if it's only made available for reference purposes, it would still be valuable. I've had to consult the source code many times to understand exactly how the networking system works.

 

After reading the initial blog post, and the projected timeframes for deprecation and the new implementation, I still get a feeling that their will be a doughnut hole between the old unet and the maturity of the new multiplayer. I really hope I'm wrong.

Cheers!

 

That's the plan! The new networking layer will be provided as a package with full source for debugging purposes.

 

Hi Brandi,

• New networking layer will be like current LLAPI but C#?
• New networking layer will be unreliable and no reliable?
  
• New networking layer will work with MonoBehaviour and ECS, not only ECS?
  
• What about Websockets? Right now Unity disabled those features in C#
  
• What about the planned HLAPI community takeover? We kinda started already
• Will old LLAPI be open sourced so we can fix bugs?
  
• Why did old UNET fail?
• Why is Alexey not working on new LLAPI?
  
• What happened to the rest of the UNET team?
• Will same team work on UNET - if yes, why will it be different this time?
• Will there be real world tests this time?

Thanks

 

I've always wanted to make weird, niche indie games that have multiplayer, but I've always been put off by everyone's complaints about HLAPI. I'm excited about the new stuff but I hope you don't forget about the little people who can't justify paying much per month.

 

Probably so, that's generally how things work when introducing a new feature. It doesn't always land at 100%. Especially considering it's integrated with ECS which is far from ready.

But, it looks like it will be available for at least limited use within the year so that should let us get in and hack at it and provide feedback pretty quick.

 

That's... a lot of questions. I changed your bullets to numbers to make this easier.

1. That's a pretty fair description. We'll share more specific details about the new transport layer soon.
2. The baseline will be unreliable with reliability layers optional.
3. Correct - it's intended to work for both to support the transition period.
4. Good question - we are still investigating options for this.
5. We are working on converting HLAPI to a package, and beyond that, it's still available for the community to use where it's helpful.
6. Here's a quick summary of challenges. The LLAPI was not going to be easy to convert to ECS-compatibility, so we started fresh; it also wasn't easy to decouple from the engine, so providing full source wasn't an option. The HLAPI in many ways was overly-general, so we are focused now on "game archetype" higher level networking code that is tailored to unique needs of different types of games (for example, the FPS we demoed at Unite Berlin). The P2P model (i.e. Relay and MM service) have inherent struggles with inconsistent connection/latency, hackable clients, and scale limits, so we want to make dedicated servers a viable option for Unity developers as an alternative.
7. He's certainly been involved, and he can speak for himself on this one.
8. Some of the key people from UNet are still here and on this team building and informing the future tech;
9. See 8 and 6 for some of the key things we learned.
10. Under the new header of Connected games, we are building out a cross-discipline set of teams that range from services (like MM), to networking/gamecode, to server runtime, to server orchestration (i.e. the Multiplay team that just joined Unity). This is a major priority for Unity, and it involves many teams working closely together.
11. We have a lot of conversations ongoing about how we build and staff a dedicated support team this time, including options for paid / guaranteed responses as well as more timely attention to issues raised on the forums. This team will have escalation paths to each of the teams I described in #10 when they can't resolve the issues directly.
12. I may not understand this fully. We do have an internal team focused on creating "real" sample games with networking code that share full source. We are using these games to test and validate our tech before public availability. Beyond that, we'll generally be dependent on adopters of "experimental"/"preview" versions to provide feedback before a full release.

 

Nice

 

I remember that at some point it was mentioned that steamworks p2p support was planned for unet. Looks like that will never happen
Is steam support for p2p games planned for the new networking layer? Thanks for the info!

 

Honestly this news is really upsetting for me. The fact that you're announcing the deprecation of UNet so close to the date of its death while providing no way for developers to start planning their migration immediately is extremely disheartening.

 

What do you mean? they said they would provide fixes for 2 years after 2018.4, how much more lead time do you need?

If I were you, I would take a serious look at HLAPI CE, we have fixed a lot of issues there.

 

I'm very interested in developing LAN games, which is a niche area that is getting less and less attention in the era of cloud-connected games.

I'm in the middle of a big project that I'll need to support long-term, so I need a networking solution that (1) allows LAN connections without any internet connectivity and (2) benefits from general Unity upgrades beyond 2018.

Will the new Unity networking solution support LANs, or ought I switch to a third-party solution?

 

Yes, critical fixes until 2021, and the Relay is live until at least 2022 (by which time we will either provide a clear transition path for live games or extend the service). Hopefully plenty of time for devs to make the right choices for their games.

 

I'm building a game using UNet and the multiplayer services provided. I plan on continuing support for multiple years to come and can't justify working in a system that will lose service in 3 years, 2018.4 keeping UNet or not. Until the UNet replacement is released to developers, this project is put on hold. Then I will have to rewrite the game to utilize the new system. I don't mind having to rewrite the game's networking code but I'd prefer the downtime to be absolutely minimal and without a date on the new networking system, I don't know when I can continue working on this project. There are probably higher profile developers than I that this is pulling the rug out from under.

 

I love LAN games, so please do keep making them! From the networking side, I don't know of a reason why the base transport API's wouldn't be viable. For the rest of the stack, it's pretty focused on enabling "dedicated server".

For local workflow purposes, we are certainly considering how LAN scenarios will work with our new tech, though most of those still assume that a "dedicated server" is also running in the LAN (i.e. sharing one of the client machines or on a separate box). For a LAN-only game, this may be more cumbersome than is necessary, and alternate paths may be preferable for the near future while we are still focused on enabling dedicated server games.

 

@BHouse I look forward to see what you guys make. LLAPI has some serious issues with memory consumption and dropped packages. It is refreshing to see you guys refocusing on networking.

will the new transport layer be open source or the source will be provided just as a reference?

 

Could such a "dedicated server" be deployed similar to Unet's "host server," in that the server code is contained within one of the game clients (rather than a separate application)? This is especially helpful for certain deployment scenarios (quick start, mobile LAN games, etc.).

 

Thanks goldbug! The plan is that the source is largely a reference in the package. My understanding of packages (a fairly recent construct at Unity) is that if you modify the source, it may become impossible to upgrade to future versions of the package, so while it may be possible, it likely won't be recommended.

 

Good question - I think we are too early in the planning to answer this with any certainty; the default is certainly a separate runtime, so for now, assume separate until we get further down the path.

 

This is a HUGE bummer. Something like a network transport should really be open source. Please take this into concideration.

 

We are very much aware of this use-case, and it's why we use the phrasing "at least" 3 years for the Relay service. We have confidence that by 2022, there should be a clear transition path in place for live games to get to a new tech stack. And if not, we will very likely extend the service. It's certainly not our goal to harm games that depend on this tech.

In your case, if you planned to ship in the next 6 months, then continuing as is may be your best bet. Beyond that, then we recommend starting the investigation of swapping to a dedicated server model for your game.

 

The new transport layer may not directly interface with the P2P steamworks api's, but the devs on the team say it should not be a painful transition to swap between them.

 

Ok, I'll rephrase a little:

Will the license allow forks?
What kind of license do you have in mind?

 

It was so cool to provide this !
Not like Photon, using a tiers server, but just your clients !
We absolutly need this, if not it will be a big change compare to the (old) Unet

 

I just wanted to stop in and say that I hate this. It seems really weird to me to just scrap UNet and start building again from the ground up. Why not fix / improve UNet? What is the major unfixable issue that is forcing the entire thing to be abandoned? What are you going to do differently this time that is going to justify so much rework?

I guess I'm just one of those weird people who actually kind of likes UNet. I definitely encountered my fair share of problems or missing features that would have been real nice to have, but I never wanted UNet dead, I just wanted it fixed and improved!

Also, I sure as hell hope corporate is throwing some money at this. UNet never seemed to have the funds or staffing that it actually needed, and unless something has drastically changed I would not have faith in the same size team of, I think at one point it was only three people, completely redoing everything from the ground up. It's just not realistic no matter how good the devs are.

 

You may want to give HLAPI CE a shot. We have fixed a ton of bugs, simplified the code quite a bit, and we are adding new features like "sync to owner". Find us in discord if you want help or if you want to contribute.

 

It's totally understandable to be frustrated, and if it helps, this was a decision that we considered in-depth over a quite a long period (hence why so many questions remained unanswered in the community for so long). I mentioned this in a prior response, but some of the key challenges that we couldn't easily resolve for UNet were as follows:

• The LLAPI was not going to be easy to convert to ECS-compatibility, and as Alexey mentioned, it also wasn't easy to decouple from the engine, so it would always struggle as a "black box" without full source. In the long-term plan of Unity, this was always going to need a complete replacement.
• The HLAPI is in many ways overly-general, and it can struggle to work ideally for all types of games. We are focused now on "game archetype" higher level networking code that is tailored to the unique needs of different types of games (for example, the FPS we demoed at Unite Berlin). That said, the HLAPI will remain open to the community, and people may find it useful even alongside the new transport.
• The P2P model (i.e. Relay and MM service) has inherent struggles with inconsistent connection/latency, hackable clients, and scale limits, so we want to focus on making dedicated servers a viable option for Unity developers as an alternative.

And I can confirm that this a major effort at Unity. We were very excited to welcome Multiplay to Unity (they already host game servers for a breadth of games - like Gang Beasts to Titanfall 2), and even more recently, we announced our close alliance with Google Cloud. We are now in the midst of staffing up several cross-discipline teams, so we can eventually provide great tools and services across the spectrum of connected games.

 

I really don't understand why the HLAPI was overly-general ?
What was the limitation about this approache ?

 

OK well count me in since I'm on alpha, in the ecs (unity) slack and ready to add MP to my game.

 

Sounds interesting and I'm looking forward to how this develops and grows.

Until it's ready, and mid 2019 gives plenty of leeway, the developers of HLAPI CE have a solution that many might find useful too.

 

Good clarification - perhaps it is better described as not designed with modularity and flexibility at its core, so the more features we added, games frequently paid a performance cost whether or not they used the new features. As we rebuild from the ground-up, modularity is a key tenant of the design: i.e. add and use only what you need for your game.

 

Yes but i looked on it and based my own hlapi on yours and didn t see so much limitation.

If by Hlapi you mean, like me, message handling and rpc/command and gameobject identification. The rest was just features added on these functionnalities.

But yes I am curious to see something new. Just a bit nervous about my long work on my Hlapi xD.

 

Couple quick Qs:

Someone asked above about LAN and there was an answer, but I want to be sure: will this allow for clients to act as a server (host/listen server)? This is pretty important, especially if you don't have a dedicated server geographically nearby.

Second, are there plans to actually build any games with this before releasing? Loads of features were missing from UNet that made it pretty clear no real high-level, performance intensive multiplayer games were made with it before release. A first person or third person shooter would be ideal, since they tend to be among the most complex multiplayer games on the market (from a networking point of view).

Really excited for this, networking really is the largest gap in Unity's toolbox at the moment.

 

Personally I think this is great. Watching UNET languish over the last few years has been painful. I'm glad to see you guys have fully embraced connected gaming and jumped in with both feet. Sign me up for the alpha.

 

What happened to the Unity acquisition of MultiPlay?

I presume we'll still have classes like NetworkClient and NetworkServerSimple as core classes to work from?

 

Question, if I use just UnityWebRequest do I need to use WWW instead. Will UnityWebRequest deprecate with UNet?
I’m using it just for post and get, nothing else (I'm not making a multiplayer game, I'm just using get and post for API call to dropbox and others cloud services).

 

How soon until we can test the new networking? I've built my own hlapi specifically designed for dedicated server rpgs, hopefully it'll be fairly simple to move from uNet to the new one.

 

Will that mean available for experimental feature testing? ...if so, when? I think we are many people that need to start the coding exercise already now. Myself will delay my, already coded but not fully tested, project for this.

 

Thank you for the explanation.
While you are there check the Post... sometimes I have to use WWW because Post in UnityWebRequest receive errors.