[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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
That’s a pretty fair description. We’ll share more specific details about the new transport layer soon.
The baseline will be unreliable with reliability layers optional.
Correct - it’s intended to work for both to support the transition period.
Good question - we are still investigating options for this.
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.
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.
He’s certainly been involved, and he can speak for himself on this one.
Some of the key people from UNet are still here and on this team building and informing the future tech;
See 8 and 6 for some of the key things we learned.
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.
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.
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.
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.
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.
I changed your bullets to numbers to make this easier.