Search Unity

Through our connected games initiatives, we’re revamping how we can make networked games easier, more performant, and multiplayer-ready by default. To make these important changes, we need to start anew. That means existing multiplayer features will be gradually deprecated, with more performant, scalable, and secure technologies taking their place. But don’t worry – games with impacted features will have plenty of time to react.

Over the past few years we’ve offered Unity creators a set of multiplayer tools and services commonly referred to as “UNet.” UNet consists of two major components: Core networking (High Level API/HLAPI and Low Level API/LLAPI) and enabling services (Relay Server and Matchmaker). These features work together to enable peer-to-peer (P2P) multiplayer games.

UNet has been a tremendous learning experience for all of us, and we’ve seen our community ship some incredible multiplayer games.

The journey of these games hasn’t been without challenges, however, and we’ve heard your feedback: Unity game developers need more than what the current version of UNet can offer. Notably, you want more-scalable and transparent core networking and fully supported server-authoritative games that enable the security, stability, and consistent performance required for all levels of success. The future at Unity holds great promise for large-scale projects that are networked-by-default with the Entity Component System (ECS).

To achieve these goals, a complete rethinking of our real-time multiplayer technology was required. Here’s our plan.

UNet transition overview

UNet powers many active games today, and we take this responsibility very seriously. As a result, we are ensuring the following long-term support for developers who depend on our existing technology:

  1. The HLAPI and LLAPI will no longer ship 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.
  2. Relay Server and Legacy Matchmaker Services: Continued operation for at least three years following 2018.4 (LTS) ship date, with a clear transition plan provided before this date.

While UNet features are being deprecated, next-generation networking features will be made available soon, including:

  1. Game Server Hosting services, which replace the P2P-enabling Relay Server.
  2. New networking code, which replaces existing UNet HLAPI/LLAPIs. Early versions will be ECS compatible.
  3. A new Matchmaker service that works seamlessly with Game Server Hosting.

For more on what we’re working on, check out our blog post on connected games.

Stay in touch

  • Keep track of what we’re working on by visiting unity3d.com/connectedgames.
  • Have feedback? Please share it in the sticky threads of the Connected Games forum.
  • Interested in alpha testing some of the new technologies? Contact us here.
  • Keep watching the blog.  We’ll share more about what we’re working on soon.

104 评论

订阅评论

评论被关闭。

  1. Here’s an idea. Dont use Unity. Make your own game engine and you have all the freedom in the world no beholding to anybody

  2. Will i be able to host my game with my own hardware?

  3. 啥时候公布啊,这都秋天了,我等的花儿都谢了。。。

  4. Octavio Centeno

    八月 30, 2018 4:58 上午

    I’m currently working on a game. I will implement multiplayer. Should I wait to new Unet 2.0 or work with Unet 1.0?

    1. Use something which you have more control over Steamworks, lidgren, LiteNetLib anything but not Unity

      1. Use the simplest UDP networking. Even if the library only has unreliable and reliable UDP you can easily add sequenced unreliable.

  5. I wanted to start making a game in November that would have multiplayer. Should I not be starting it then if it’s going to take around a year to make if the networking is going to be completely replaced?

  6. Please make it possible for the normal integration of UNET HLAPI and Steam p2p

  7. What about local multiplayer
    Via mobile hotspot or over wifi
    With no internet connection
    Will it be supported?

  8. It must be hard developing Unity — I’m sure you all have stuff up your sleeves with this one, and I’m looking forward to the new system! Goodluck to all the developers on the team :)

    Also, I haven’t been able to dive into networked multiplayer games with Unity consistently, so I see a bunch of Network-related stuff in the docs. My biggest request is — when this new system comes out, would you be able to make it easy to see exactly what classes are “old” and/or deprecated, and which ones are the new ones we should be using?

    Anyway, stay strong, you’re doing an awesome job! ^_^

  9. I’m currently developing a game with synchronous PVP in 2017 LTS using LLAPI. I don’t need HLAPI since it’s way too bloated and I have implemented a similar but much simpler solution. I’m going to run Unity servers in headless mode on AWS infrastructure. Will it be possible for me to upgrade to a newer transport layer painlessly at some point?

    1. “It will be similar, like having similar network events (data event, connect/disconnect, etc). It will have a different serializer but you could keep using NetworkReader/Writer since this is pretty easy to swap out at the transport level.”

  10. Why you creating another great networking from scratch?) Why not cooperate with https://github.com/RevenantX/LiteNetLib ?)

  11. Why is everyone so whiny!

    I’ve put a few weeks implementing networking with the transport layer and I’m sad to see that this came out of no where, I mean we are on 2018.3 and 2018.4 is the last version you can use the transport layer..

    It would be nice if we can get some more information about where things are going.

    Keep at it UNITY!

  12. Christopher Burns

    八月 12, 2018 12:21 上午

    I hate to be that guy, but holy crap did you all ever screw this up. It’s not rocket science to make a low level UDP lib with reliable ordered support, and then commit to its maintenance. What a circus sideshow! Not that its rocket science to swap out your crappy UDP lib for something different, but that is not work that needed to pushed on me.

    1. You know — I so have to agree with you here!
      It amazes me and I sit back and spend hours wondering what the hell the devs at Unity are thinking… Usually while trying to track down the latest bug that Unity has created to keep me from being able to publish a viable game. So, yeah – With ya 100% on this one!

  13. Will the new network API feature some convenience systems such as lag compensation? It was one of the main issues I’ve had working with unet, re-inventing the “wheel” when it comes to providing a smooth and responsive network experience.

  14. Hello connected games team
    I am currently planning my university degree project for the university of applied science in darmstadt, germany. We want to create and publish a multiplayer game that should be finished in January 2019. Should I stick to the current UNET solution an then rework my code when the new multiplayer system is finished, should I start with the new system and risk working with a beta version, or should I look into other solutions like Photon ?
    Thanks in advance !

  15. I saw this coming since HLAPI Lead developer quit and Unity Technologies bought Multiplay for $25.2 million. They host various game servers including Titanfall 2, Killing Floor 2, Rocket league, Rust, and soon going to host PUBG servers.
    This time they’re making something really worth your time.

  16. Don’t forget about voice chat.

    1. +1 Voice chat is a deal breaker

  17. I see you want to replace Relay and Matchmaking with Server Hosting. I already tried to play around with Master Server Framework and Master Server Kit. Is it something similar?
    Is it necessary to use your hosting, or we can host server anywhere we want (VDS provider or even my home PC)?

  18. I am glad you are finally decided to ditch UNet away. However, I am afraid you may repeat the same mistake.

    I want to give you an advise: You don’t need to develop everything new from scratch. You already tried with UNET, it was a failure.

    You already had a great network tool. Old network system, also knows as Raknet. It was great, with some flaws, but super easy to use and great potential.

    Also there is an asset in Asset Store, called TNet, which is very similar to Raknet, but much more advanced and have some revolutionary features which does not exist anywhere else.

    You are already familiar with the author of TNet, it is the same man who developed NGUI and who worked with you in Unity in order to create UGUI, which was a revolution on UI.

    DO IT AGAIN! Hire author of TNet again and integrate TNet natively into the Unity! Bring another revolution into Unity.

    Please do not develop anything from scratch, unless you are 1000000% sure that it is will be better than TNet.
    Please at least check out TNet from Asset Store and learn its revolutionary “receive save load functionality for free” feature. Be sure that your solution will not be worse just better.
    Otherwise, just integrate it and improve a bit if you wish. You will save a lot of resources and everyone will be super happy.

    Thanks.

  19. LOL why would anyone use this? Unity clearly is clueless about networking. Very happy with Steamworks .net.

    1. Steamworks.net is not a complete networking solution. It is just steam modules you can implement like scoreboard and matchmaking. You still need so.ething to sync player states

      1. LOL no Steamworks has low level library and also lobby including chat

        1. Can you suggest any steam multiplayer games using steam networking api ?

  20. (From the other blog post, as this one seems more up to date)…
    Bear in mind, I am trying to figure out (with a limited data set) what the new unity networking package will be like. When I wrote this on the other blog, I had in mind the fact that I have my own servers, and I intend on having something that will work on said servers. I would like for it to be Unity based, as I prefer Unity to Unreal. (Though, the current job market seems to be all Unreal development, if the head hunters are to be believed.)

    So, when replying or heck, just reading this, keep in mind the above, and the fact that having already paid for servers and not really wanting to make a lan party style game (though, props to others who do want to) I’m really not looking forward to an over priced CCU model again. Rather, I’d like to just host it myself and be done with it (and not get charged based on concurrent users).

    What I would love to see — Something that will allow us to make AAA grade games with a variety of multiplayer features. I say it this way, because not all of us are wanting to make facebook casual games. Some of us, like Myself, **Really** want to make a higher scale of game. Like a real Server-Authoritive MMO or MOBA or TB/RT-SG. (And, Atavism is not viable here, as if their demo server is any indication, it’s not fit for the job. 4 frames a second on a high-end gaming pc, because I went out of “town”… yeah, no.)

    From what I have seen with the current room-based matchmaking games, they’re “great!” if all you want to do is recreate Quake from 20 yrs ago. If you want something more… complex, has built in team matchmaking – like the ability to be a “party” and join a match as a party, and stay “together” as a party, you have to completely write the logic yourself, AND NOT USE UNET… meaning that the current UNet fails miserably — especially pay-to-host matchmaking. If you want a server that you can run (locally or on a service) so that you can have your program work, the matchmaking services that come with UNet completely fails. It’s like it was created for lan parties, and oh, yeah, the internet is just an interesting way to make your lan party bigger.

    And, it appears that the ecs-model is (also) just going to be an over glorified lan party. That said, (and strongly thinking that I am really not interested in paying for only the ability to write quake or doom — hence not using my crappy CCU’s that equate out to 2 simultaneous games) I look forward to the change. I would stress, however, that giving us optimized networking APIs that allow us to intuitively create servers, be it locally hosted/cloud/co-lo’d, would be a great thing.

    What would suck, however, is being charged for yet another crappy CCU-based system asking us to accept only BaaS as the premium standard (meaning, you’re limited to crappy facebook games, casual android games — hint, the market is oversaturated as it is with both of these — or, Quake from 20 years ago, all the while paying a monthly fee for this schlock).

    Having produced my share of Casual games, and games on Facebook, I’ve seen quite a LOT of services offered that lack any real value. At least with UNet, you can do a mixture of Socket IO and HLAPI and make a server (there’s a really good asset on the Asset Store, called Master Server Kit, to do this). I honestly, would love to see something like Master Server Kit integrated into the Networking offered by Unity. And, I’d love to see a headless windows build so that I don’t have to have a linux server if I don’t want one. (I realize that linux hosting is cheaper, but not all of us are fans of the os. Don’t laugh, I am sure they are out there.)

    Just off-the-head thoughts at reading how the past 6 months of my life have just suddenly been “deprecated” with UNet being on it’s way out, and how it would have been better spent creating a custom tcp/ip based server and just serializing the heck out of the data sent.

  21. Tobias Löffler

    八月 6, 2018 7:11 上午

    As an 3D Artist, i don’t have much to do with all of this magic-alchemy stuff (that’s how i call it) but i would love to tell you a couple of words from my colleague, who is the coder in our team: “Please, whatever you do, don’t forget the documentation and don’t make things more complicated than they should be.” He likes Unity more than UE4’s solutions but he eats three keyboards a week ranting why things don’t work as expected even if the code is correct and kinda hates it that some API (?!) lacks of documentation and features, including that he’s looking for functions that are easy in Java, but hell of work in C#. I am not sure what exactly it is, but i guess like Robert Cummings said in another comment, he just wants some clean, powerful API (probably well documentated). Thanks for the open ears, we’re looking forward using this new features on our current openworld game-pitch.

  22. Robert Cummings

    八月 5, 2018 1:39 上午

    I’m hoping that there will be extremely clear and non fancy direct examples on how to get things up and running. I’d like to see things like dropping into games in progress and host migration. I don’t really want obfuscated syncvar nonsense either. Just a clean, powerful API. I just want to make my game and have Unity take care of business in a way that has a curve of costs: it’s free for me to start, but as I get more successful, so do you.

    I don’t want mixed messaging. I need Unity staff to be very clear about what is the right and wrong way to do things. Don’t forget, experts will ignore you. There is no downside to being authoritative to your audience.

    1. +1 for this!

  23. Next time you guys should announce a deprecation/replacement AS SOON AS you remove the prior system. Since you removed the old Networking in 2018.2 (a couple weeks ago) I’ve been busy replacing it with the mess that is UNET. I’m happy to hear you are replacing it, but you could have let us know sooner. What a waste of time.

  24. It’s great to hear something concrete about Unity and its internal networking solutions. Many people have mentioned it already but I’d like to add my voice about something quite important for smaller groups or hobbyist developers: the hosting costs / CCU / etc. Currently with UNET you can do a variety of things such as utilize NAT punchthrough to reduce or outright avoid CCU fees, or you could refactor some of the network code using the kindly provided open-source HLAPI and direct UNET to use Steam’s relay/matchmaking or even net messaging, assuming you’re targeting that platform.

    The major alternative to UNET that is Photon has potential to end up as overly-expensive for some people and that doesn’t seem likely to change. Valve is currently working on and releasing an entire networking back-end that isn’t tied explicit to their service, but it is neither complete yet nor is there a C# port of it (https://github.com/ValveSoftware/GameNetworkingSockets). Because of this, one of the things I would love to see most is support for connecting in about any way the developer would like to, as the current UNET provides. Simple access to the scripts handling connectivity would likely fulfill most desires for this (for example, all connectivity as overrides/partials/etc, and built such that everything will run fine if they’re fed the correct connection information when they’re reached). Other gaps left open by UNET include things like middleman APIs to integrate with Steam (which can be filled with things such as Steamworks.NET or Facepunch’s Steamworks API), and it would be great if that would be addressed as well at some point in the production process.

  25. Whoops meant to say who are not networking specialists

  26. Hello Larus, I am super excited to learn more about the new networking layer and server archetypes. Is the end goal templates (FPS/RTS/MMO) of a high level api that people who are networking specialists will be able to select from when making a game? As a hobbyist one of the biggest road blocks for me is getting multiplayer right. When will Unity give us more detail on this?

    1. Lárus Ólafsson

      八月 5, 2018 3:29 下午

      There will be more news on the new feature in the coming weeks, however, this will be less like a drop-in system like the current high level API where everything is ready made and more like a collection of tools tuned to work well with a certain game type. It will probably have a steeper learning curve because of that but there will be focus on making good docs and examples so it’s as easy as possible to get to grips with.

      1. Peter Källviks

        九月 4, 2018 7:57 上午

        It has been a couple of weeks now since you stated that there will be more information coming in a few weeks. When will we get more info? …I guess there are quite a few people waiting due to ongoing projects.

  27. It’s great that you are focusing on authoritative servers. It was great that in uNet unlike some other solutions you always had the option to host your servers in an authoritative manner if you wanted. In fact I always did that.
    I’ve used uNet to release 3 games and am grateful of the work Alexey and others did on it. Please after 2018.4 release the code generation parts of uNet so if unity does not continue the work long enough, people still can do continue using it. I know that it might mean exposing some more editor events to run a step for CIL modification after script compilation and … but probably should have been done in the first place. Just consider it if it is not a huge problem to do it.

    Many thanks for the great uNet and I hope you do it even better for the next system. Some painful parts of uNet

    – the fact that the message for authority of the object is sent after the spawn message so in OnStartClient you could not know if you have authority or not
    – the fact that you could not send any additional data while spawning objects and did not have access to syncvar data before OnStartClient
    – Not having the ability to send additional data to the server with connect
    – Not having a list of Player and Player id classes on the server was a problem since always you have to code it and you’ll need it and many games need a common structure
    – not being able to send an RPC only to a set of clients (like all except owner), I know code generation was an issue if you wanted it to be seamless.

    1. Lárus Ólafsson

      八月 4, 2018 3:36 下午

      The code generation part (unet weaver) is already released (see https://bitbucket.org/Unity-Technologies/networking/src/07fd9d678e96de1ab215076f5e6fdb1bef7aaac8/Weaver/?at=2018.1 ). And we’re looking into making this even easier, moving all code from the unity engine so it’s 100% open source and you could for example change how the code generation step is invoked.

      The list you made also make a lot of sense.

  28. Oussama Bouanani

    八月 4, 2018 11:33 上午

    Great work, really looking forward to this but I do have one question/request, is there any plans to support determinisim in multiplayer?

    1. Lárus Ólafsson

      八月 4, 2018 3:24 下午

      Determinism is very important in the ECS world, and something multiplayer will focus on as well.

  29. I’m using the transport layer for a game that will launch in a month, so I have a couple of questions Unity.

    Brandi House’s comment “For example, the LLAPI should have a lot of similarities to the new transport, and the migration should not be too challenging.” made me wonder what will change, will it still depend on NetworkEvents?

    Will it still be viable to use NetworkReader/Writer, or are you shipping api specific to the new transport?

    1. Lárus Ólafsson

      八月 4, 2018 3:22 下午

      It will be similar, like having similar network events (data event, connect/disconnect, etc). It will have a different serializer but you could keep using NetworkReader/Writer since this is pretty easy to swap out at the transport level.

  30. Salah Mikolovic

    八月 4, 2018 12:39 上午

    Will the new networking system have P2P support? I find it handy to have P2P support for LAN parties. Another question; will there be improved physics over the network? Two networked rigidbodies colliding seem to be laggy even on LAN.

    1. My understanding is that the networking transport will be agnostic to network topology, so it should be feasible to use in a P2P model. However, we do not have immediate plans to work on a new Relay (less relevant in LAN scenarios that you note), as we are focused on dedicated server support.

      1. Will it be possible to host the server on your own machine? Or we will be able to use only unity service for that?

  31. I think that many developers prefer use other networking services because the high price of the Unet service.

    1. Reducing costs for developers and offering fair pricing is important to us in these future offerings. Do you have any more specific feedback about the prior UNet pricing model?

  32. So, do we have to remake whatever socket abstraction classes we have created based on the current LLAPI?

    1. Lárus Ólafsson

      八月 4, 2018 3:41 下午

      Yes, but this will likely be straightforward to do since the APIs will be similar.

      1. Hello, my VPS costs me less than 4$ per month, i have to manage it, install firwalls, launch games etc.. myself, but i dont have ccu limits message limits, bandwith limit and stuffs.
        Don’t know if it is realistic, but is it possible to have something close to that ?

  33. Awesome news! I would love to see Unity to step up on networks. If someone asked me, and to my colleagues what the most lacking feature in Unity is, it’s always the lack of usable network libraries. I come from PC online gaming development and I can’t get more excited to hear that Unity is determined(seemingly) to make this happen, this time.

    I suppose it is still at the design stage and I would like to mention few things so that it heads toward to the right direction. I guess I’m bit worried because Unity solutions are usually bit odd and they are known to make half-finished products and throw them away. uNET anyone?? ^^

    We are onto make high-performance network libary for dedicated server environment, right? Well then, I would like to ask you to take a look how Unreal networking frameworks solves the problem. Let me say it simple. Please copy the high-level concept(not the implementation, I believe Unity can do better job implementing it with ECS) first and add more layer on top of it, and do not come up with some different concepts to confuse everyone or to dodge the headon comparisons with Unreal.

    I know coming up with good network library is a daunting task and Unreal has had a very good solution for years and they ante up with the recent update even further. In that regards, I think your choice to tackle FPS fist is really a good choice. I don’t know if there is any other type of games that pushes the limit of network more than FPS games, given the number of players are the same.

    I say this because after waiting after a few months to years, it doesn’t end up like uNET. Good network library needs to deal with, dedicate, client-hosted, authoritative, proxies(autonomous, simulated), replications with priority, frequency, filtering, and of course reliable, unreliable RPCs and so on.

    Honestly, I don’t know if there can be better solution than what already Unreal solved already. I would say it again, copy the high-level concept but go about implementing much better with ECS. One thing that Unreal lacks is multicore networking. With ECS, I think many of the underlying systems can run in parallel giving much higher throughput than Unreal. And of course, deterministic physic/network is huge plus.

    Many would probably say, not everyon one is making FPS game but my answer is once we have a good solution for FPS game, the same concept can apply to many different types game equally well. Turn-based game just won’t need sophisticated filtering setup, MOBA would be very similar to FPS but has much less tick-rate and bandwith, and MMORPG will need an extra filtering layer, perhaps a hierarchical filters but it’s not difficult to implment. Yes MMOPRG also needs be persistent but that has nothing to do with Networking.

    So, please design with the right goal from the beginning. If you can make it similar to Unreal APIs but C# can help make the syntax much cleaner, I know that many of the Unreal developers will flock into Unity, like myself. ^^ I and many of my colleagues always talk about lack of Networking solution that keeps them to use Unity. If Unity had a real(Unreal) network library, I and my colleagues willing to become the best advocate and help to shape it to be the best. So, please push the FPS implementation to the limit and don’t leave it behind unless it’s not the best.

    Thank you very much for the awesomeness.

  34. Are we gonna be able to activate the Relay Server and Legacy Matchmaker Services during the 3 year transition, because we are almost done with our game (a couple of months or so) and i don’t want to start over the networking right before release.

    1. We don’t have plans to block new releases; we understand that some games will be too close to launch to change plans now.

  35. Hello, so what will happen to our codes written with UNet? Can they be used with the new update or do we have to revise our codes all over?

    1. Atomic, it clearly states that uNet will depreciate. Depending on how long you can wait, you either have to go with uNet or the unknown network library. While I’m at it would like to mention few more things before it gets too late. I would love to see Unity to step up on networks. If someone asked me, and to my colleagues what the most lacking feature in Unity is, it’s always the lack of usable network libraries. I come from PC online gaming development and I can’t get more excited to hear that Unity is determined(seemingly) to make this happen, this time.

      I suppose it is still at the design stage and I would like to mention few things so that it heads toward to the right direction. I guess I’m bit worried because Unity solutions are usually bit odd and they are known to make half-finished products and throw them away. uNET anyone?? ^^

      We are onto make high-performance network libary for dedicated server environment, right? Well then, I would like to ask you to take a look how Unreal networking frameworks solves the problem. Let me say it simple. Please copy the high-level concept(not the implementation, I believe Unity can do better job implementing it with ECS) first and add more layer on top of it, and do not come up with some different concepts to confuse everyone or to dodge the headon comparisons with Unreal.

      I know coming up with good network library is a daunting task and Unreal has had a very good solution for years and they ante up with the recent update even further. In that regards, I think your choice to tackle FPS fist is really a good choice. I don’t know if there is any other type of games that pushes the limit of network more than FPS games, given the number of players are the same.

      I say this because after waiting after a few months to years, it doesn’t end up like uNET. Good network library needs to deal with, dedicate, client-hosted, authoritative, proxies(autonomous, simulated), replications with priority, frequency, filtering, and of course reliable, unreliable RPCs and so on.

      Honestly, I don’t know if there can be better solution than what already Unreal solved already. I would say it again, copy the high-level concept but go about implementing much better with ECS. One thing that Unreal lacks is multicore networking. With ECS, I think many of the underlying systems can run in parallel giving much higher throughput than Unreal. And of course, deterministic physic/network is huge plus.

      Many would probably say, not everyon one is making FPS game but my answer is once we have a good solution for FPS game, the same concept can apply to many different types game equally well. Turn-based game just won’t need sophisticated filtering setup, MOBA would be very similar to FPS but has much less tick-rate and bandwith, and MMORPG will need an extra filtering layer, perhaps a hierarchical filters but it’s not difficult to implment. Yes MMOPRG also needs be persistent but that has nothing to do with Networking.

      So, please design with the right goal from the beginning. If you can make it similar to Unreal APIs but C# can help make the syntax much cleaner, I know that many of the Unreal developers will flock into Unity, like myself. ^^ I and many of my colleagues always talk about lack of Networking solution that keeps them to use Unity. If Unity had a real(Unreal) network library, I and my colleagues willing to become the best advocate and help to shape it to be the best. So, please push the FPS implementation to the limit and don’t leave it behind unless it’s not the best.

      Thank you very much for the awesomeness.

    2. It depends on what parts of UNet you are using and your stage of development. For example, the LLAPI should have a lot of similarities to the new transport, and the migration should not be too challenging. Also, if you are within 6 months of launching the game, you may want to keep things as-is and rely on the 2018.4 LTS version for your game launch.

  36. If HLAPI/LLAPI aren’t included with Unity beyond 2018.4, will subsequent versions of Unity be devoid of networking support until the new system is released (hopefully in the first half of 2019)? I have a lot of multiplayer infrastructure written with the LLAPI, and it sounds like I’ll be stuck on Unity 2018.4 until the new system is available. That’s fine if the new system is actually released in early 2019, but it’s easy to imagine a scenario where it doesn’t come out until 2020 and I can’t upgrade to a new version of Unity for a year because nothing past 2018.4 has UNet or its replacement.

    1. As the diagram indicates, it’s our goal to have “experimental”/”preview” versions of the tech available by the end of the year, so if there is a gap, we hope it will not be for long.

  37. I can’t say I fully understand how this new stuff relates to the ECS. First there’s “networked-by-default with the Entity Component System (ECS)” – ie this new networking system is mostly ECS based? But then “Early versions will be ECS compatible” – ie the point is just that you can also use it from ECS code? Also I assume if early versions are ECS compatible then later versions are as well? Is the point basically that *even* early versions are ECS compatible?

    1. Robert Cummings

      八月 3, 2018 2:05 下午

      I believe they refer to the fact that ECS has all the data up front that you would be accessing and it’s deterministic. Therefore it is already in the format ideal for being networked with perfect prediction. This does not imply that the networking layer itself is ECS (although may be at some point – I don’t think it’s relevant).

    2. You have the right idea – the goal is that the new networking layers are designed with ECS in mind from the start, with an eye on the future when ideally all aspects of the game (including networking) are ECS. We’ll have more details soon!

  38. Patrick Scheper

    八月 3, 2018 11:57 上午

    I’ve been waiting for this blog post for quite some time! Thanks a lot! It sounds pretty promising and I’m glad Unity is being responsible with the long-term support.

    Enjoy the weekend!

    1. Just want to say thanks for this; the team is also excited about what’s next, and responses like this really brighten our day. :)

  39. Question, if I use just UnityWebRequest do I need to use WWW instead. Will UnityWebRequest deprecate?
    I’m using it just for post and get, nothing else.

    1. Lárus Ólafsson

      八月 3, 2018 2:12 下午

      This is unrelated to UnityWebRequest stuff, you can keep using that as before.

      1. Good thank you

  40. Ha, we’re in the middle of implementing the old UNET stuff and wrapping our heads around it. Woo, fun.

  41. Eric Batlle Clavero

    八月 3, 2018 9:49 上午

    Will the new Unet work better with unity physics? you know all the problem discret physics are affecting games nowadays :(

    1. Lárus Ólafsson

      八月 3, 2018 2:11 下午

      Yes it’s something which will be looked into, possibly just showing an example how to use a custom deterministic physics layer, since this is hard to do with the current physics engine.

  42. Since the connected games initiative now it seems Unity is focusing on Multiplayer now. This is a great News.

  43. Bryan Livingston

    八月 3, 2018 2:42 上午

    So I’m on 5.6 still. Planning on upgrading someday, but if the compiler injection stuff goes away and would we not be able to use the open source version of the HLAPI, would that be a big incentive for me to never upgrade?

    1. Lárus Ólafsson

      八月 3, 2018 2:07 下午

      I’m not sure I fully got the question, but it’s expected you’ll be able to keep using the HLAPI open source feature in the future with the new transport (or any transport you want).

  44. It would be awesome to launch multiple game instances like unreal 4, compiling the game just to correct an not operator on a IF statement takes ages, even if just compile the game code is possible, sometimes some asset modification is needed.

    1. +1 on this. Building the game every time something changes is a huge time sink.

      1. Thanks for the feedback; it’s noted for future versions of our build pipeline that are in planning stages today.

  45. I’m pretty early in to a hobby project at home, currently using my own networking solution (built on top of the LLAPI), but I plan on switching to this as soon as it’s available. Do you know when the first preview/beta build will become available? I’m hesitant to go too deep in writing my networking code in light of this news.
    Cheers

    1. Lárus Ólafsson

      八月 3, 2018 2:04 下午

      We’re aiming at october for the first preview. Switching from the unet transport to the new transport will likely be pretty easy (from an API standpoint), although it won’t be as fully featured of course (only aiming at supporting basic unreliable/reliable support at first).

  46. With what sounds like a ground-up rewrite and with new ECS support, will there be any focus on providing functionality akin to, say, how the Source engine lets you run separate client/server instances with *separate* running simulations from within a single application without having to deploy a separate server build for testing?
    In my experience a setup like this has been absolutely immeasurably helpful for debugging and iterating on networked games without the pain of deploying and re-deploying server builds over and over, and it would be nice to see Unity offer something like that out-of-the-box.

    1. Lárus Ólafsson

      八月 3, 2018 1:35 上午

      Yes, exactly :) This kind of workflow could be possible in the ECS world, we’ll be looking into making this kind of iteration work.

  47. Jérémy CROMBEZ

    八月 2, 2018 10:58 下午

    Will the new network layer provide a simple way to do NAT punchthrough or is it not dedicated server oriented enough ?

    1. NAT punchthrough is generally not required in a dedicated server model, so this isn’t currently a high priority.

  48. “The HLAPI and LLAPI will no longer ship 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.”

    As if these have received any attention, critical or otherwise, in the last 3+ years.

    Seriously…deprecate them now, don’t bother spending a minute on them. If someone needs to finish a project with UNet they could switch to HLAPI CE, the replacement Unity turned down. You should’ve paid the guy for stepping up on your behalf, IMHO.
    https://github.com/vis2k/HLAPI-Community-Edition

    For your roadmap, please consider the following:

    1) Do NOT require we host our servers or services anywhere specific. If we want to rent a server from namecheap or whoever that should not be interfered with in any way. If we’re fully self-hosting, no CCU nonsense.

    2) Please do give us a Build Manager where we can set up MULTIPLE build profiles in a single project and for each one define the scenes and assets that go into each, and each may target any platform, some the same platform, e.g. 2 distinct profiles for desktop, 1 for WebGL, 2 more for headless, etc.

    3) Make sure ANY client platform can connect to the server: desktops, mobiles, WebGL, TV’s, whatever. In a HLAPI we shouldn’t have to concern ourselves with the underlying topology, whether it’s web sockets or whatever. We should just be able to define a FQDN / IP and protocols we need (reliable, unreliable, ordered, TCP Secured, etc.) at the HLAPI inspectors and it should all just work as long as the server is reachable.

    4) Implement console and headless builds for Windows. Console would use stdin, stdout, stderr like any normal .Net console app (which means we can capture it from a process host) and a headless would include a simple windows service wrapper that would run normally (console mode) if launched from Explorer (Environment.UserInteractive == true) or as a service when launched by the Windows Service Controller.

    1. Lots of good feedback – thanks!

      1) We are collaborating with Google Cloud closely as we announced at Berlin, and it’s our goal to provide the best ease-of-use balanced with flexibility through our joint integrations. However, our new networking is designed to be agnostic, so you’ll always be able to use your own server solution; it just may not benefit from the dedicated attention to workflows.
      2) Feedback noted for the build pipeline team; there are many conversations about this ongoing right now, so the feedback is timely.
      3) This sounds like a great ideal to strive for long-term, and I sure hope we get there. In the short-term at least, there won’t be one single “HLAPI” since different game types need significantly different higher-level networking models; instead, we’ll be building out networking “archetypes” that work best for different types of games. For example, the FPS sample demoed at Unite Berlin showcases forward prediction, lag compensation, etc typically required similar types of games.
      4) Feedback noted for the desktop team. It’s also worth calling out that we are focusing a attention especially on the headless Linux runtime for servers to reduce hosting costs, and optimizations to all headless runtimes are in-progress today.

      1. Feedback noted for the desktop team. It’s also worth calling out that we are focusing a attention especially on the headless Linux “runtime for servers to reduce hosting costs, and optimizations to all headless runtimes are in-progress today.”

        If there’s anyone on your staff suggesting “few if any will host on windows servers” they should be demoted to non-decision-making status. The cost difference is nominal and is upside down when you factor in the pain of working in an environment that is completely unknown and unfamiliar. Working smarter not harder means we’d rather host on the same platform we developed and tested on than spend ridiculous time and treasure learning Linux at deployment time. A dual-mode console / service wrapper is trivial to generate.

        1. For cloud-based games hosting, we’ve learned from some very experienced game developers that Win licenses can equate to a major proportion of hosting costs. Here’s an example break-down from one of the lead Titanfall 2 developers: https://youtu.be/p72GaGq-B_0?t=25m49s
          Many devs (including some in this thread) consider costs of hosted games to be very high priority, so we can’t ignore a significant chance for cost savings.

          However, the point is taken that for local iteration, it may be easier and faster to use Win, and it is our goal that swapping between platforms for local vs cloud-hosted scenarios should be simple and provide equivalent functionality.

      2. “For cloud-based games hosting, we’ve learned from some very experienced game developers that Win licenses can equate to a major proportion of hosting costs. Here’s an example break-down from one of the lead Titanfall 2 developers: https://youtu.be/p72GaGq-B_0?t=25m49s
        Many devs (including some in this thread) consider costs of hosted games to be very high priority, so we can’t ignore a significant chance for cost savings.”

        You’ve missed the point of the video segment. He’s getting raped on cloud licenses, yes, but he also makes the point, along with his graphic, that in a bare metal scenario it’s a non-issue. I’m sure all of your customers would like to be published by Electronic Arts, but objectively, that’s just not going to be many of us. Many of us are going to rent one server for the whole deal, and a cheap one at that. The price difference is about $20 more for Win Server 2016 over Ubuntu / Centos and they’re still at or under $100/mo. Worth every penny versus the headaches of different / unfamiliar platform. That’s simply not enough money to quibble over.

        I’m not saying to ignore Linux, I’m saying Windows deserves parity, expecially when it’s just so darned easy to do.

        (Also, could someone please make this comment box taller or stretchable? 2.5 lines tall is a bit silly.)

      3. Here another fan of multiplayer trying to get a prototype (FPS like) with a dedicated authoritative server, client prediction (and all this stuff) with a custom kinematic controller (deterministic) and all this stuff..

        I think you are going the right way, hope to see some tutorials soon :)

  49. For someone who wants to start on the multiplayer turn based game “today” what should they be using?

    1. A turn-based game is latency-tolerant, so you have many good options. A couple things to consider:
      – How do you pass gamestate back and forth quickly? This usually depends on a fast / real-time database. In the GCP world, you could consider Google Cloud Spanner (for x-platform applications) or Google Cloud Firestore (for mobile/web only).
      – How do you prevent hacking/cheating? Typically, some form of simple serverless cloud functions are the ideal such that code that is most-likely to be hacked (think: dice roll or card draw) is run on-demand in the cloud without a full dedicated server. Some options in GCP today are App Engine, Cloud Functions, or (recently-announced) Knative.
      We’re working with Google to bring this functionality more-easily to Unity developers, and these tools are a solid starting point today.

  50. Great news, looking forward to the stuff!

    For those who are worried about their current UNET projects, please visit our HLAPI Community Edition: https://forum.unity.com/threads/unet-hlapi-community-edition.425437/ forum thread and use/contribute :)

  51. Richard Kopelow

    八月 2, 2018 7:30 下午

    UNet was clunky when I wanted to do “normal” network things like simply sending data from server to client but I was a huge fan of the Command/RPC workflow. With a little forethought and a few attributes it let you write a game as if it was local but all the code ran where it was supposed to. I hope some of these idea come over to the new system.

    1. Great feedback – these are all things we are considering in the new designs as well.

  52. I am very happy that the network service has regained importance.
    But using google server means that China has high latency and can’t even connect? I am looking forward to a service that is not restricted by the region.

    1. This is really great feedback, and we are investigating many paths to be able to support the Chinese gaming markets in the future. For example, Multiplay’s current Enterprise orchestration tech is “multi-cloud” capable, so in future iterations we may be able to integrate/leverage this capability to unblock regions where GCP is not ideal for server hosting.

  53. The graphic shows all 3 new multiplayer features available starting in 2018 — I assume is this just as early-alphas / “preview” releases?

    What’s the planned 1.0-stable release window for the new networking code, specifically? (Even a super vague answer is good, like: last-half of 2019?)

    1. That’s correct; the initial release of the new tech stack will be “preview” / “experimental” of some form, and each component will remain that way until we have confidence that real games can successfully launch using it, based on feedback from developers in the community. This inherently means we can’t promise exactly when that will happen, but we hope to get there as soon as possible – our goal currently is in the first half of 2019.

  54. Oh my… Barely got a grasp on UNet and managed to run headless unity servers with master-server framework and here are the news. I liked UNet for its flexibility. Hope its good architecture won’t be forgotten.

    1. Hi dnnkeeper! Some of the key people behind UNet are here informing the new architectures, and flexibility continues to be front-of-mind for all of our new technology. We’ll share more details soon!

  55. About time, lets have it!

  56. I’m glad something is being done about UNet and I’m really looking forward to the new stuff you will bring us! But I do have one concern: You’re all about connected games and game server hosting, but will the new networking system still support direct P2P? To me, it’s an important part about keeping your game alive. As a hobbyst, I can’t afford to maintain servers and would have to rely on players hosting their own servers, which, IMO, also builds a community, espescially if you make a game that supports modding and plugins. Not every game wants to have “get players, drop them into a server and play”. Some want to allow the users to customize and make a server their own. Not just some game server on a Google server somewhere.

    1. Thanks Hertzole, and great questions.
      One of the things we learned from UNet developers was that most games struggle to succeed with a P2P model due to inconsistent connection/latency, hackable clients, and inherent scale limitations. Even cooperative games with less chance of cheating struggle with other aspects. This is why it’s our highest priority to ensure Dedicated Servers are a viable option as soon as possible, including doing our best to bring down the costs of hosting (i.e. with as little overhead as possible in the server runtime).
      We aren’t ruling out a future P2P system (or equivalent) for latency-tolerant games, but it isn’t our immediate focus.

    2. Lárus Ólafsson

      八月 2, 2018 6:54 下午

      To be clear, you can host the game servers themselves anyway you like (not only on a google server somewhere), do it yourself or allow your players to do it , that’s fine.