Official UNet Deprecation Thread

Sounds exciting! Eager to test the new stuff!

 

The new transport layer is written on top of .NET sockets?

 

Fantastic, really excited to dig in to this as soon as it's out

 

Will we be able to run our own servers, or use direct connections for example Playstation network? I ask because while I really want to support Unity I don't think I can afford to do so at launch.

 

Brilliant, count me in.

 

This is interesting news. I'm one of the weird people who has been happy with the HLAPI. In the last few months I've been running into trouble with the LLAPI though, and it has been very difficult and time consuming to troubleshoot. Creating a new transport that is open source will definitely help with this.

 

Me too. Just chiming in, because I'm excited for the direction that Unity is taking. All I ever read on the Networking forum is to not use UNET. It was embarrassing, and I've turned to alternative options because of this, and never even gave UNET a chance. I don't have much of a stake in multiplayer at the moment, but I have high hopes for the new networking system.

I do have a slightly uninformed question though. If the open source Transport Layer is written in C#, won't that go against performance? I really don't know what will be going on in that layer, and/or if it would make sense to introduce a C++ interface, but that just sounds like even more overhead.

 

For example, I can't scale up my RTS game with HLAPI.

1. Will the new replacement for UNET have better documentations and more samples to put in the documentations? We have various forum threads in the past where we kept hitting walls with UNET and how we can't figure out how to effectively use our UNET codes. (Instead of giving out only 1 sample code, can we see at least 3 sample codes, all used in various ways?)
2. What is the new replacement called? "Multiplay"? Or something I missed?
3. So, I may not be understanding correctly. Will there be a high-level version and a low-level version of the multiplayer package? Or it's just "one" version for all, be it performance, or for reliability?

 

Good questions!

1. We've already demoed the FPS sample game at Unite Berlin, and we are working on plans to provide more samples in the future of varying game types with differing networking requirements. In addition, we are focusing early on documentation, Learn resources, and support to ensure more developers can find sufficient materials to keep their development unblocked. It may not all be ready on day-one, but it will remain a high priority indefinitely.
2. Naming is... always fun, and our marketing team is still sorting it out. The backend of the new hosted game servers will be powered by Multiplay tech, but that may not be the final name.
3. Actually, potentially many packages - for example, there may be one package for the base unreliable transport, one optional "Reliable" package, another optional "Sequenced Reliable" package, etc (caveat - not final names). The goal is that packages enable our new networking to be highly modular, so developers can integrate only the features they need for their game.

 

Okkkkkk, that black boldfaced text worries me a bit. But the blue boldfaced text helps alleviate the concern I had.

I thought it's going to be a "one-for-all" package, so the documentation would be "all-in" in one location.

But if it's many packages, I worry that documentations and changes per packages will fragment the pace of documentations and may shake up sufficient materials for incorrect features. And also, it would bring a bit of confusion to developers who are trying out, mainly because they don't have a keen idea on which package is better suited for them than the other.

When I say "confusion", I refer to developers planning out networking in their games in the long-term. What happens if they have package A, but later down the road, they have to go for package B due to various reasons. Would they be required to relearn package B even when they know full well what package A has?

The C# code gets converted to C++ interfaces. Basically, C# is the frontend, and during building, C# is translated into the backend C++. I think it's the IL2CPP (here), where the C++ codes are compiled based on the supported platforms and their architectures. It's less about performance, and more about trying to communicate with various hardware differences any given platform can offer.

 

Hi,

1) Will this be somehow bound to the unity/multiplay services? Or can we also host our own servers on our own machines at the same time?
2.) The multiplayer by default sounds much like "performance by default" from the ECS system. Which makes me wonder if you guys might have ECS as the primary design goal and MonoBehaviours as only a secondary objective. So, when you mentioned that MonoBehaviours will also be supported, is that just "supported" as in "we give you Send(byte[]) and you'll have to do the rest on your own", or is that actual support in terms of a HighLevel API as there was previously? With a weaver, syncvars, rpcs, ...
3.) Is there a "game archetype" planned for RPG/MMO games as well? Or is the FPS-type you are working on complicated enough that it covers the aspects of RPG games as well (synchronizing position+health is covered by the FPS type. But lag compensation for things like spellcasting start/end, lots of numbers changing because of buffs/debuffs, ... might require a different setup).
4.) Will there be support for multiple parallel "reliable sequenced" channels? If so, how much overhead (bytes added to the message I mean) per message can we expect in this transport type?

 

How do you know that's what's happening in the new networking system?
Did they say that anywhere? Or is that just guessing?

I'm a bit concerned about that, because what about games that can't use IL2CPP?
Like games that have to load code at runtime like game mods, interface plugins, ...

 

Guessing. I did say "I think", because that is my impression. But, it's best to wait for an official response.

 

Youguys should be telling us the preview release date asap. Our team is currently working on multiplayer, and we are planning to switch to the new api, because of features like dedicated server on the cloud and etc. We are planing to start all over, and we don't want to waste time waiting for the release.

 

Hi @BHouse, will the new networking package written in ECS way?

 

Will this new implementation have emphasis on multiplayer debugging? In particular it would be extremely useful to have in-editor support for multiple game instances. It has been an extreme pain over the years having to build an executable just to test network features.

 

This sucks... it's not just that bug (that I tried to send you), I also have lot's of code written with WWW class...

 

1. Unity+Multiplay server hosting will not be required. The networking, server runtime, and likely many other aspects of connected games should be viable options even if you provide your own servers and orchestration. However, we will be focusing on simple/integrated workflows that leverage the full tech stack, including the hosting/orchestration.
2. Unity is moving towards a (long-term) ECS future, since we believe it's the best path to unblocking creators who want to make games at large scale with fast performance; Networking is an important part of this future. The core transport we are working on today is agnostic, and the FPS sample will leverage a mix of the old and new technologies available today. However, the highest levels of the future networking stack will be focused on deep integration with ECS.
3. When we talk about networking samples and "archetypes", we are thinking about unique needs from a networking stack. For example, a typical multiplayer RPG from a networking perspective may look similar to a traditional FPS. MMO's in the traditional large-world form may differ since one core challenge is dealing with larger numbers of networked characters and objects. Once we begin to see some of the gains from integration with ECS, a large-scale sample / archetype will certainly be a high priority.
4. This kind of detail is too early to say; we'll be sharing much more information soon.

 

Is there some way to hijack the code weaver stuff Unet does so that we can use Unet basically forever?

I think code weaver is the only real complication stopping me from just namespacing my own version of the HLAPI that doesn't rely on engine-baked systems

PS pretty disappointed by this news but not surprised at all

 

I assume that it's correct that any projects relying on UNET will not be able to upgrade to any versions of Unity past 2018.4 LTS. Is that correct? In other words, unless we port to the new networking stack, we will need to stay on 2018.4 LTS, right? For example, an existing project using UNET, that upgraded to Unity 2019.1 would not work I assume.

It is always a bummer to get "stuck" on an old version so I'm hoping that there might be a chance my assumptions are wrong. (Changing from one networking system to another will be a time-consuming and costly endevour that'll only happen if our clients fund significant other updates to their applications at the same time -- hence the idea of being "stuck".)

 

Is there any information on the general code architecture of the new system?

E.g. is it still based around adding components to sync different aspects of your gameobject (NetworkTransform, NetworkAnimator, etc) and using Command/ClientRpc to communicate between server and client.. or is the architecture totally different?

Would I potentially be able to adapt an existing project over to the new networking system once it is released?

 

Would it be possible to host the server anywhere I want (custom VDS provider or even my home PC)?

 

Previously it's always been said that the GameObject/MonoBehaviour and ECS system will live together and there is no plans for deprecating the old system at all, this seems to indicate that there are some plans around this at least? Especially if the ECS is getting higher level networking features which won't exist in the GO/MB system.

 

Check out HLAPI Community Edition, we did several improvements to the weaver already.

 

Hi @BHouse, I hope Unity will offer free tier for development instead of like trying 30 days only.

 

Surprising news, I didn't think UNET was that bad (although it had its quirks, specially regarding player management. For example, there was no support to get a list of connected players from a client), but if you feel like it needs replaced, I guess it's ok.

Some worries (not really questions) about the new networking system, I hope you have them in mind:

1. You say you're ditching P2P over server-authoritative in the new system, but wasn't UNET server authoritative? Sure, we made P2P games but they just relied on the server relaying messages to the other players. You may say it brings a number of problems to the table, such as cheating (tbh, we wish our game had a level of success where this could become a problem), scalability (which only would apply to games with many players in a same game, which is not common) and network quality (which I agree could be a problem), but it does have its advantages.
   
   
2. I really think focusing on dedicated-server multiplayer is a bad idea for an engine like Unity. Maybe I'm very wrong, but I'd say less than 10% of multiplayer projects in Unity work with dedicated servers, and most will use host/listen servers on the fly. It's faster (to develop), it's easier, and it's cheaper.
   
   
3. We've used UNET on 2 successful games so far, both using Listen server/P2P mode. The only issues we had were related with NAT traversal, and the overly unreliable Unity relay servers. We've recently changed the transport layer to use Steam P2P networking, and it's almost flawless now, so I sincerely hope we can use a similar approach on the new system.
   
   
4. If you're working on a new matchmaking system, please have in mind the modern matchmaking systems (read: parties, player levels...), as well as in the engine itself (in other words: A way to get the list of players, if they're in a party, some metadata about them,etc), and it should be compatible with consoles as well.
   
   
5. Since you want to go with the dedicated server way, I guess the system should feature a way to manage some player data (for example, level, ranked ELO, unlocked inventory...) in the matchmaking server, so we don't have to rely on separate external services (such as Playfab). I know this one is probably asking too much and it's not directly tied to the networking layer, but without this you'll be just giving an incomplete tool, and people in need of dedicated servers will need this kind of services anyway.

 

I learned network coding with my last project, and I have to say that HLAPI was just a nightmare. LLAPI was a bit more straightforward and I got it working, but the whole multiplayer aspect took me 6 months, and wondering the whole time if I was going to have to start with a whole new networking engine. It finally came together in the last few days before release. Everything else in Unity is like a dream come true, but the networking is not up to par.

I'm very glad to hear things are moving forward, but please keep in mind that people are coming in hoping they can learn this, so documentation has to be spot on, especially for cryptic error messages. For example, how am I sending on the 'wrong channel' when I'm only using one channel... Can't look that up currently.

 

I consider it a very brave and progressive move for a company to stand up and say "ok we made something that works, but it's not good enough for you. So we're doing better." - in so many words.

So to do that, costs Unity a truck load of cash. Frankly, Unity didn't need to. They probably aren't going to make this cash back for a long time. But this company actually really wants to be the best.

So count me out of any complaining because that's the price of progress. Sometimes stuff just plain sucks and it's nobody's fault because nobody's perfect. So Unity has my 100% support for this new networking.

All I ask is for complete transparency so we can spot issues early, not too late.

 

It's imperative that Unity needs to be transparent about its development as many will depends on it. Unity is not shy asking for requests/feedbacks but has been very low-key on following up.

Unity has a sign up page for the the early participants. I signed up but when you will let us know? I would like to be of a help and I appreciate or the opportunity.

 

For those who care, due to the UNET deprecation. We have open sourced our standalone relay that you can continue to use for games that use UNET (be that the transport, or the HLAPI)
https://github.com/MidLevel/MLAPI.Relay

 

This is feedback many of us gave to Unity. Unity made it "friendly" so they thought but really it was just confusing. We asked for a straight forward API with no guesswork involved. We got non stop guesswork and obfuscation.

The thing to learn here is that networking is complicated but that's OK - just keep it straightforward and show clean simple snippets with fantastic documentation and lovely little examples for everything. Don't need experimental theoretical APIs. Stick to Gaffer's advice.

So TLDR for my initial pre-feedback:

• No Syncvars
• No HLAPI
• Document everything - it's better than HLAPI to do this
• Examples for everything - again better than HLAPI

In fact it's probably better hiring a decent network programmer to sit on the networking forum and just answer questions 6+ hours a day, since the developers will eventually end up being too busy I think. This IMHO will create much needed structure and learning since networking is so individual to the game.

Kind of makes me wonder when kids with minimal experience get so much futher with Photon and even Unity Raknet than they ever did with UNet.

 

I just want 1 active Unity-employed community manager. Active as in, having a dedicated job 8 hours/weekday managing the forums.

Of course this is unrealistic, but that is what I like about.

 

1. Will the new network layer still provide a API library similar to LLAPI ?
2. How about the simulation server ?

 

A new start might be a good opportunity to improve on many aspects and all of these new plans sound promising and exciting for sure. At the same time, I have sort of mixed feelings that all/many(?) of the current concepts are thrown away in the end. I'm with UNET since it's beginning in 2015 and I really appreciate most of the HLAPI concepts such a SyncVars, Commands and RPCs. Besides the flaws, IMHO such things make networking simple and accessible even for non-experts and I really hope this idea still remains as a design goal.

 

There are already full time CMs for the purpose of forum support and passing on information. Let's not derail but what I suggested wasn't a CM but a developer intimate with networking hired for ongoing network specific support. It was not a realistic suggestion

 

As a developer, beginning on networking, what is the best course to take now?

 

@BHouse -- are we likely to see a tutorial that is updated for the parts of UNET that were removed in 2018.2 soon? I just started a project that will be my first foray into multiplayer, and I'm worried my timing wasn't the best (much like, it seems, @ristophonics). I feel like it'd be in my best interest to start up with the new tech for longevity's sake.

 

I think it is great that Unity guys are telling us the plan ahead of time. As game devs we can make informed decisions on what to do. Our options are:

1. Use existing UNET.
2. Switch to a UNET fork such as HLAPI CE
3. Switch to other solutions such as Photon
4. Wait for the new network library

All options have pros and cons, there is no right or wrong answer, pick the one that works best for you.

 

UNET was deprecated the moment it was released - it just wasn't communicated. At all...

I'm glad you guys are doing something about it, be it deprecating or improving. Anything is better than it was as long as there's communication and something happening. I can't believe you guys had only two developers on such an enterprise feature with no docs/support, leaving all your clients using UNET in the dark, abandoned in the dirt for two years without even answering core questions how to use it, dancing between it's mock existence and false hope.

Two developers and 0 support? That's how many we have for our indie game that took two years to make. Respectfully, where is the budget going? How could anyone guess that two would ever be enough for what could be one of the most complex features in Unity? And why no support at all for such a feature with only 8 pages of deprecated docs?

Heck, it originally advertised reconnection, too, but that wasn't even added. Our type of game, for example, requires reconnection. If we had known it was a false promise, we wouldn't have even tried UNET.

I truly hope Unity takes from this and concentrates on stability over simply adding it to the list of features then moving on, no matter its state. UNET is an example of this. In your next iteration, please continue caring for your features instead of abandoning them. If abandoned, please mention it way earlier.

Our team wasted months of development time on that module, where there was no form of communication that it was abandoned until years later. I spent months following up how to get a single question answered that wasn't in the docs, as simple as "How do I properly disconnect a player?" and after the 8th follow-up, the QA literally responded, "I can't force the developer to answer that question". That's the moment we quit UNET and saw where it's going.

And this was a featured that you guys were charging money for, actually calling it stable.

Love you guys, but come on, mates.... stability > features. Always. This is both an indie and enterprise philosophy-- and even beyond that: a standard. Please fix existing bugs before moving on. I can still name countless bugs that have been here since 4.x -- just simple things that should have been fixed long ago, but for some reason, still remain.

This post (and all the bug fixes I see in Unity 2018) gives me hope. Please keep the communication + stability high <3

 

@i42-Xblade
I wholeheartedly agree.

Me and my team have learned a similar lesson, which is the reason why we are in the process of creating our own networking library.
I thought/hoped that maybe the new system the Unity guys have planned would solve our need for a networking solution, but there have been two things that made us decide against waiting for Unity.

First:
Seeing how other features get treated (UI, ...) and how UNET was handled in the past we have little trust that the future will be radically different. As they saying goes "if we don't remember history we are doomed to repeat it". No point in learning the same lesson twice...

Secondly:
The responses in this thread by BHouse are extremely concerning (for us at least). Our game is well underway and thus builds strongly on top of MonoBehaviours (obviously, since ECS wasn't even announced when we started). There have been more than enough "hints" that the focus will be pretty much only on "networking specifically for ECS", with the bare minimum being done to make some sort of upgrade path available to games using the old UNET code (if even that!)

Don't get me wrong, a new beginning is totally fine and understandable. Hell, maybe I'd even make the same decision in their shoes, who knows! But pretty much everything here tells me that the new networking solution will not be what we actually need (read: we=my team, not we=everyone on this forum).


The new low-level API however could be interesting to at least take a look at when/if it comes out.

 

I have to agree here. Deprecating UNET and building something new is fine, but there's a lot of uncertainty at the moment between the old GameObject/MonoBehaviour system and the new ECS system. Now the ECS is very early in development and if you're building a game right now the old system is the way to go. But since we're talking about timelines that in the blog post is showing at least a 4 year time span, it would be very good to get more information about how the new networking system is going to relate both to GO/MB and ECS systems.

• Is the new networking mostly going to be focused on the ECS? If it is how does this relates to the current lack of features (i.e. integration with the rest of the engine) that the ECS suffers from?
• What features will be available to the GO/MB system? Will it have feature parity with the ECS networking? Will it just be a low level/transport API? etc.

There's a ton of question-marks here, the connected games initiative is great, but it feels like we need more information. Because right now the state is:

• UNET is officially dead/deprecated
• There's no information about what features will be in the new networking system (other than that there's going to be a C# based transport API)
• There's no information about how the networking system will relate to GO/MB vs. ECS

This leads to a lot of uncertainty and worry in the community.

 

I think they were pretty short staffed in this area before, to be fair. But being fair means Unity has a chance to get networking right now and the way that happens is transparency. Not partial, but full transparency. This is how you get trust back and support.

 

That's great. Do you have free matchmaking service?

 

Salutations Unity Team,

Can we/I get a copy of the shooter game example that was shown in the Unite Berlin keynote that uses the new system? That way we could look at something even if it is very preliminary? If not could we know a timeframe for when some example would be available?

Thank you for keeping us informed.

Edit: It would be ideal if any example materials showed how to use the system with the traditional gameobject/monobehaviour design as ECS is still so new and is taking some time to get used to.

 

I have not written a matchmaker. It can range from being super easy to being really difficult depending on the features you want. If you want game ranking with something like Glicko for competietive games, you will need more architecture behind the system. The relay is designed to take the IPAddress and not an arbitrary GUID which makes it usable with ANY matchmaker. Since this topic is about UNET's deprecation, please send me a PM or continue the convo on another thread like the MLAPI.Relay forum thread for example. The Unity relay for example would be super easy to replace since it has limited functionality. Pretty much just a list of matches.

 

Hello unity technologies. I have a question. Have you guys already started working on it before you guys announced it? Or did you guys just start making the new networking right when you announced old unet was being deprecated a few days ago?

 

I've been developing my game for quite some time and I'm still using the old RakNet-based networking.

At the time RakNet was announced as being deprecated I looked into moving over to the then new UNET system, but it didn't seem ready for prime time, so I decided to wait for it to mature a bit more. Honestly I haven't looked at UNET for a little while, so maybe it would now fit the bill, but given that it's just been deprecated too it doesn't seem to make much sense to go that route. I guess it's just as well I waited!

The trouble is, RakNet has now finally been removed as of 2018.2, which leaves me in total limbo. I was hoping that UNET would be a mature and complete replacement by the time RakNet was removed, so it's really frustrating that we're in this situation.

Anyway, now that I've got that off my chest, here's hoping that the new networking initiative has more success. In the meantime, particularly given the uncertainty around it, I think I'll have to go on the hunt for a suitable 3rd party solution.