Official UNet Deprecation Thread

How would this affect LAN only implementations?

I'm tasked with creating a LAN networking backend for future projects, which is set to be complete in approximately 6 months. Most of the backend is complete, running through UNET, however the idea is that future software utilizes this backend, so I imagine it would need to be converted to the new system.

However, it would be an absolute dealbreaker if this were not able to be run in a closed-off network. I understand the long term benefits of switching from P2P, but I need to know if this is a recommendation or a requirement.

Thanks!

 

Sorry if this has been mentioned previously, but there is a fundamental question that concerns me, will we be able to host our own dedicated servers?

 

Ok I'm incredibly confused and more than a little frustrated. I tried to start working on a simple test setup for the multiplayer system I want to use in my game. As we all know multiplayer games can be very complicated so I wanted to keep it super simple. Rather than try to integrate the oddly specific HLAPI functions for part of the game and end up still having to manually handle other parts, I decided it would be easier to control everything myself. So I start looking for the simplest way to establish a connection and send reliable messages. That's all I want, nothing excessive, just messages back and forth.

I scan down the page until I see "Send and receive network messages". Bingo! That text isn't a link (sigh) so I go searching for which part of the manual explains how to do that. Ok, I find "Actions and Communication > Network Messages". Sounds hopeful. I start reading that page, and.... ugh, wtf. Why do I have to extend a class just to send a message? Why is this not just a function I can call? I don't understand. Maybe if I keep reading... nope, it just gets more complicated. Well that's stupid. So I wonder if maybe I'm in the wrong place. I keep looking and find "Using the Transport Layer API > NetworkReader and NetworkWriter serializers". I'm less hopeful this time but start reading anyway. Ok, this sounds like what I want. I can create a NetworkWriter, feed it some variables, it serialises them and I send the message. Hey, maybe we're getting somewhere now. It still seems unnecessarily awkward but that's ok, I can wrap it in a function to simplify it. I notice that the example code uses the NetworkServerSimple class, so I go find it (manually, because it's not linked...) in the script reference. And.... wut.

At this point I'm stuck. Both NetworkServer and NetworkServerSimple show as Obsolete (wtf? what does that even mean? Is it the same as deprecated? And WHY IS IT OBSOLETE, if the manual says to use it???), and neither of the references actually seems to explain how to use the class. NetworkServerSimple doesn't show ANYTHING. No methods, variables, nothing.

What am I supposed to do here? The documentation seems to be conflicting and there's a severe lack of information for beginners. Can someone clear this up for me?

 

Thanks for the clarification, this brings my next question, will there be a fee associated with hosting our own server? like the nonsense Photon does?

 

All of the networking classes in the documentation are deprecated. As of this writing there is no replacement from Unity. I wish unity would put a big warning in their tutorials and documentation about this, because I see other people have the same confusion.

Your options are:
1) Stick with UNET, it will be turned into a package soon and will be supported for a couple years (last I heard). Having tons of Obsolete warnings is no fun though.
2) Switch to Mirror, it is a community fork of HLAPI. It is very similar to HLAPI so the transition is quite simple, and it has a large growing discord community behind it.
3) Switch to other options such as MLAPI, Photon, etc... This might take a bit more work, but those seem to be solid alternatives as well.

About send a message, this is how you normally send a message from the client to the server in both HLAPI and Mirror:

Code (CSharp):

1.  
2. class Player:  NetworkBehaviour
3. {
4.      [Command]
5.      public void CmdMove(int x, int y)
6.      {
7.          // this gets executed in the server,  the client just
8.          // sent us a message to move this player to position x,y
9.      }
10.  
11.      public void Update()
12.      {
13.          //  this gets executed in the client
14.          if (GotInput() )
15.          {
16.               // this is the magic,  this gets turned into
17.               // a very compact message and sent
18.               // across the network to the server
19.               // it does not wait for the server
20.               CmdMove(newx,  newy);
21.          }
22.      }
23. }
24.  

Use [ClientRpc] instead for sending messages from the server to the clients.

Follow the KISS principle whenever possible.

 

Ok thanks, so Unity is actually being as dumb as it seemed. Right. Not very helpful, Unity, making an already-difficult topic even harder...

I think I'll look at Mirror. I've stared at your example for a little while and I think I am starting to understand how HLAPI is intended to be used. The Unity documentation does a very poor job of explaining this. I'm at work right now so I can't test whether I have indeed understood how HLAPI/Mirror works but I think I'm starting to get it.

So let's see if I have my head around this yet. Imagine I have a timer object in my game world. The timer has a plus and a minus button, a screen to show the current time and a screen toggle button. The timer always counts up every second, but can be changed by any player by clicking the +/- buttons. The screen (the in-world UI) can be turned on and off by clicking the screen toggle button. This is the pseudo-code script I would attach to the timer gameobject:

Code (CSharp):

1.  
2. class Timer : NetworkBehaviour
3. {
4.     [SyncVar]
5.     int currentTime;
6.  
7.     GameObject inworldUIObject;
8.  
9.     void Awake()
10.     {
11.         inworldUIObject = gameObject.transform.GetChild(0).gameobject;
12.     }
13.  
14.     void Start()
15.     {
16.         setInterval(function() {    //this is JS syntax, idk how to do this in C# yet - it just runs the function every 1000ms
17.             currentTime++;
18.         }, 1000);
19.     }
20.  
21.     void Update()
22.     {
23.         if(playererHasClickedPlusButton)
24.         {
25.             clickPlusButton();
26.         }
27.         if(playererHasClickedMinusButton)
28.         {
29.             clickMinusButton();
30.         }
31.         if(playererHasClickedScreenToggleButton)
32.         {
33.             clickScreenToggleButton();
34.         }
35.         //update in-world UI to show currentTime
36.     }
37.  
38.     [Command]
39.     void clickPlusButton()
40.     {
41.         currentTime++;
42.     }
43.  
44.     [Command]
45.     void clickMinusButton()
46.     {
47.         currentTime--;
48.     }
49.  
50.     [Command]
51.     void clickScreenToggleButton()
52.     {
53.         Renderer renderer = GameObject.GetComponent<Renderer>();
54.         if(renderer.enabled)
55.         {
56.             renderer.enabled = false;
57.         } else {
58.             renderer.enabled = true;
59.         }
60.     }
61. }
62.  

Some questions I still have:

- If I run this as a dedicated server, the in-world UI for the timer gameobject would be updated unnecessarily (since we don't need to be updating the rendering on a dedicated server). How would I avoid that?
- Imagine I have two players and a dedicated server (or three players, one being a server, doesn't matter). If one of the players is a long way away from the timer (or any networked object) and I want the server to tell only that client to despawn that object, how would I do that? And then how would I respawn it when the server determines that the player has come back within range of the object?
- Would the state of the renderer component be synced when the screen toggle button is clicked? If not, how would I do that?

I'm also a big fan of KISS. I actually almost said that in my last post but decided it wasn't relevant. The problem is that I foolishly assumed Unity wouldn't add a heap of unnecessary, fairly niche "features" to the HLAPI; things like NetworkLobbyManager, NetworkManagerHUD and even NetworkServerSimple. The only thing that did was add extra confusion (which parts do I need and why do I need them?) and cause me to believe HLAPI was the exact opposite of simple. I now realise those classes are intended for convenience and aren't necessary. I read through the notable changes of Mirror from HLAPI and was quite relieved to see a lot of things being removed and NetworkServer made static, which simplifies things a lot.

But of course I'm still very confused by how to actually use NetworkManager, NetworkServer and NetworkClient. For instance, the documentation for NetworkServer.AddPlayerForConnection has some example code that includes this line:

Code (CSharp):

1. NetworkServer.RegisterHandler(MsgType.AddPlayer, OnAddPlayerMessage);

There's two reasons this is confusing. First, why don't I see RegisterHandler in NetworkServer's documentation? Second, what is MsgType, how do I use it and why is its documentation blank?? I'm really struggling here.

 

@Clonkex your code is getting close to what you need. But this becoming offtopic. If I explained it here I would take over the thread. I suggest you join us in Mirror discord and ask for help, there are a lot of people there ready to help.

 

@goldbug Fair enough. I since found quill18creates' series of tutorial videos. I've gone through the first one and even though it was super basic he's explaining things extremely clearly and I believe after I've gone through the rest I'll have a solid understand of UNet. Fingers crossed. After that I'll jump in on the Mirror discord if I still need help. Thanks

 

How many server app instances we can host on a single VM while using official Unity's server hosting services ?

 

Hello Jack. This actually means that we will have this option while using Unity's Multiplay infrastructure ?
This is great. Looking forward to switch when it's ready for production.

 

Why not just rent a dedicated server (you can get cheapo ones from Vultr/Linode for less than a fiver for a month) and manage your own resources like CPU usage, RAM and Disk rather than let Unity Tech host it for you?

Have you considered what would happen to your game server instances if Unity's server stack randomly derps, suffers data loss and extended downtime? Unless UT is promising a 99.99% instance uptime guarantee I'm gonna say it's a little sketchy.

Rather than UT host your game, it's not that hard to just build a Linux headless executable and make a script that bootstraps everything and gets the game ready for action. If I can do it within an day, I'm sure you can do it too.

 

The Alpha of the new transport layer at https://github.com/Unity-Technologies/multiplayer hasn't been updated since October 25th). Are you mostly done with it?

 

If I was to take a guess, they've probably closed-sourced the Transport Layer like old Unity LLAPI was and broken their OSS transport layer promise.

Pardon my sarcasm.

 

My netcode knowledge is weak at the moment so I could easily be missing something, but the Transport layer code and the FPS sample network code look like independent efforts. This makes me wonder if they are have decided which path to take.

 

Thanks for the clarification! This explains why there was raw sockets code in the FPS example.

 

I'm sending you a PM that I think will help you out with this since it's off topic. Anyone else, feel free to PM me if you need better examples than the awful documentation.

 

Not waiting for Unity to build and deprecate another networking framework, so we've moved to C# ENet. It's crisp and clean and wins across the board on the network library benchmarks.

 

Hi!
Im not reading and looking for the answer to question I will ask in a second everywhere, so please don't hate me if that was already answered.

So - based on graph of old and new networking timeline support, I can assume that "New Unity Multiplayer Features" should already be there. I done some searching, and what I found is that all we have for a moment are 2 features which are in alpha, and you need to sign up for them. Assuming that its right, when can we expect to see "New Unity Multiplayer Features" aka. Unet 2.0 be released in at least beta form, where you could already learn new Unet by documentation and some Unity Tutorials? Are there any ETA's?

Im currently really stuck at choosing Multiplayer Solution. I find Forge a bit hard to start with, and based on forum posts Photon to be a bit hard to make it work with ~20+ players. I can assume that Unity "Unet 2.0" is aiming to be even "better" then 2 solutions I mentioned so answer for this question is quite important for me.

Thanks for reading,
Have a good day!

 

I'm also stuck in this tunnel. I feel like giving up now because I don't know what networking solution to use while I have one hell of an idea to create in Unity3D. I just don't know what I'm doing - multiplayer gamedev is my life

 

People keep asking the same question every day here, maybe this helps:

• The community fork of HLAPI is called Mirror. Try Mirror if you don't want to move away from UNET architecture.
• Try MLAPI if you want a different architecture / if UNET was too high level for your needs (hence 'Mid Level API')

 

If you guys are looking for an alternative to the new system... maybe I can mention what we came up with as well.
We've completely dropped UNET and developed our own networking library/system for our game.

Major features:
- It's somewhat similar to UNET in that it provides automatic syncing of fields/properties.
- It's a complete custom high-level (HLAPI) and low-level (LLAPI) networking system. It uses LiteNetLib as transport, but that can be swapped out very easily for anything else (maybe tcp, or your own thing, or even unity's new upcoming LLAPI)
- Supports completely "split" objects, explained in more detail below.
- Better performance (much less cpu impact, no allocations).
- Does not modify assemblies, generates source-code instead (partial classes and managers).
- Supports RPCs (in both directions, so in UNET terms [Rpc] and [ClientRpc]), and also supports returning results.
- Supports singleton/static objects! For stuff that is not bound to an object, like "static class LoginApi { ... }"
- Server autoritative architecture by default, but flexible to allow clients to modify things as well. It's also possible to have peer to peer alongside a classical server (think about it: having movement and spellcasting stuff checked and replicated by the server; while having less important stuff like emotes based on peer to peer to save traffic)


Regarding the mentioned "split" objects:
With UNET we were forced to have one class that is used on both server and client.
Obviously that required a lot of if(isServer), if(isClient), if(isHost), ....
That naturally always leads to somewhat confusing code which alone is already bad.
But it is also a security issue: people are able to easily see how certain calculations are done on the server (using that information to find exploits or cheat).

With our system you can easily define an object, and have the network system generate a server and client version for it! (example of the generated server-base, just inherit from it and literally everything is done automatically)
The server file then has a property for each field which does the change-tracking, and on the client a network manager is generated that receives the updates from the server and sets the fields/properties (optionally also calling change callbacks)....

Of course, it's also possible to have classical "unified" objects (which, when used, makes the system conceptually very similar to UNET)


All in all it's an even more comfortable experience to use than UNET was while at the same time having more features.
At first we were hesitant to build our own system but the work totally paid off.


Currently we're toying with the idea of maybe making it public, but there are no concrete plans yet.
It all depends on if people are interested.
Depending on the reactions to this post, I'll write a more in-depth overview of what it does and it works in a separate thread.

 

Hey thanks for the reply! I look forward to the new UNet later on though. I'm now learning Forge step by step.
I have one question in mind, maybe sounds dumb but will there be an option to convert old UNet code to UNet 2?
Let's say I have an old project an import it in the newer Unity3D, get it?

 

Alright thanks. "however" I'm just getting started with Forge as a replacement for now. Excited to see when UNet 2 is going live!

 

Hello!
Will there be Unet 2 in Unity 2019.1?
Thanks!

 

No.
And there won't be anything like unet again (most likely, or if there will be, then it will take years).
They're developing a new low-level network thing, based on ECS.

 

When is it going to be released?

 

Unity.... you have said that the new networking engine would be available end of 2018.... your site still says this... what is the real date now?????

 

They already release it. It was a low level udp network.
You can see FPS sample already using it and build somewhat mid-high level network on top of it.

You should wait till the end of Jan or Feb to hear about new High Level Api network that will replace Unet

Be patient. Networking is an extreme hard topic. Would be another year until Unet-2 can be stable

 

This seems like the right decision. Scrapping UNET and starting over seems like a good move.

I've switched from UNET to Steam and found it to work well. The Steam API is LL and you just send byte arrays... but that's all you really need!

 

Please confirm your facts. Where did you hear that there's a new HLAPI coming out from Unity Tech? There has been no announcements, as far to my knowledge, of a new HLAPI. You might be thinking how the high-level calls talk to the LLAPI, but from my understanding you have to write that yourself - there is nothing out the box like old UNET had (NetworkManager, NetworkBehaviour, etc).

 

I read it from another post. They say just wait till 2019 Q1. I figure they mean by the end of Jan or Feb. Any later date would just look bad for Unity Team if they did not update anything

 

Mind linking me to that post?

 

From this post and some other posts from @jackt_unity.
Hum my bad. No HLAPI gonna come out. I guess new library only work with new Hybrid Entity or Pure ECS as Unity is heading this way. As why the delay with new library, I can only guess they have trouble make it simple for people to use.

 

Just to be clear, is the HLAPI gone from 2018.3, or still merely deprecated?

The blog post here says "The HLAPI and LLAPI will no longer ship with Unity after 2018.4"
But the manual here says "Removed in version 2018.3.0", i.e. 2 minor versions sooner than we were told to expect.

 

I am just starting a from-the-scratch multi-player prototype which is to be finished within 4 months. Later, it will continue into production. Please suggest what framework, libraries how-to guides to use for the same. I am currently on Unity 2018.3. Should I just proceed with network manager, and other components based multi-player implementation?
Please suggest.
Thanks!

 

I think the bigger problem was even having LLAPI and HLAPI as a concept. It should just be one API and examples on how to use it to achieve a goal, so there's only one set of docs to do, one set of support, and one set of knowledge growing on forums / stack overflow / etc... networking is complicated but Unity's prior handling of it made it a lot worse.

Would also appreciate having UNet removed from the manual once it's a package, it's absurdly confusing for a beginner.

 

I think it makes sense to have them as separate concepts, especially because you can swap out either one of them and keep the other.

Heck, once Unity's new transport gets in shape, I would expect Mirror to work with it too!

 

Being gone from 2018.3 is 2 minor versions before "after 2018.4". If you say something is gone after 2018.4, the implication is that it exists in 2018.3 and 2018.4, but not after that.

So you're confirming that you actually removed the current networking solution ahead of schedule, despite no similar replacement being ready? And that all we have to work with is the alpha low level API that is barely more than a wrapper around a bare socket? That's pretty poor treatment of paying customers.

If you want to hear feature requests, how about you replace the high level API too? Give us some actual functionality. Over 600 lines of code to implement a trivial Ping sample is embarrassing for you and annoying for us.

Yes, they did a great job of fixing up much of the abandoned code, but it's not a drop-in replacement if one is using unreliable transport. There appears to be another 3rd party library to tack on to fix that (https://github.com/SoftwareGuy/Ignorance), which may or may not replicate everything needed from the LLAPI, but who knows? It's implemented in terms of yet another library (https://github.com/nxrighthere/ENet-CSharp). So if I do all that and something doesn't work, that's 3 separate places I need to look to find out why. All this because Unity hasn't taken its responsibilities seriously regarding providing a usable networking API.