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.

 

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.

 

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

 

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.

 

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

 

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.

 

Stop crying guys. Some explanation (imho for sure). The biggest disadvantages of old implantation was it's "black boxing". It cause couple of problems:
1. Customer doesn't have any idea what's going on inside
2. Bug fix take a time
3. Every new feature implemented cause another if() in the code and affects performance.

pure c# implementation should solve all of these problem. As, (again afaik) new implementation should be fully open source (1) and fully modular (2), the last thing mean that you won't pay for feature which you won't use. If you create FPS for example, you will probably don't need any reliable transport as you will send state + delta updates...

Another big advantage is you will be able create package on top of package, so, other words, you will be able to be part of implementation.

And for sure you will be able to debug the code. Huge relief for us and you.

Make sense?

 

The new transport will be open source, as in you can grab it, drop it in your project, and customize/edit whatever parts you want to (fork it), it will be modular. You'd need to merge any upstream changes on the package after that manually. Not sure about the license but I expect it's the Unity Companion License like ECS is using. And see @aabramychev reply above.

 

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.

 

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.

 

So regarding the Hosting question. The short answer is yes. And the bit longer answer would be that if you have special needs you can always modify the package in the way you want to accomodate your specific needs.

 

We are working on the integration of all services, including Multiplay one networking solution. Might you have seen the Sample Game in last Unite Berlin keynote? Operation dashboard was MultiPlay part of the product.

Current solution will allow you to use similar to those classes.

 

UnityWebRequest will keep working as well, will be moved to a package in future.

 

We will post a little bit more detailed roadmap in the next coming weeks