Networking: feedback and questions

Hi, it seems that there is no update on https://github.com/Unity-Technologies/multiplayer after its first commit. Can you provide some development status or roadmap about that?

 

So i went into Services>Multiplayer then it took me to this(Attached) screen which shows UNet Deprecated. Can some one point me to a good video tutorial or text tutorial for new Multiplayer System. And does it have a name for which I should search online. I want to start a MMO from scratch using New Multiplayer System.

 

@timjohansson There is no hard secrets here how to do it, your graphics teams are doing an excellent job at it, For instance the post processing stack is on github and done properly, or what about the scriptable render pipelines? Check how they are developing in the open, that seems to work great..
Why is it so hard for you guys at unity to make networking of the same quality? too small teams? no finances?
Networking is a integral part of game development, almost all of the most successfull games right now are about networking, and you guys just keep failing and failing.
Your competition is overtaking you left and right, providing great network libraries for their customers, and games are being created on those platforms, you are facing tough competition and still cannot get your act together, HLAPI broken and deprecated, LLAPI broken and abandoned, New library developed again behind closed doors without even the most basic features.

What's going on guys? seriously?

 

I don't think they communicate with each other among themselves within Unity. Unity needs to get their acts together quickly, otherwise, they are going to make the same mistake again. It's been very disappointing so far. There is no update since the initial dump and we have no idea where they are going. Words alone will not be enough anymore. Unity will have to earn the trust the hard way.

 

Yeah, since 3 months ago nothing was committed to the public... not even a written documentation providing more info as well...

 

So much this. There's posts on this subforum about Photon and UNET, and just lots of exciting blog posts about the networking, but what appears to be a real dearth of useful information.

 

Since we have an information vacuum, let's speculate for entertainment while we wait.

Here's mine: Management wanted flashy announcement for conferences and overlooked the fact that the code was wasn't even close to production ready; workers are keeping their heads down because 'management is never wrong'. So now, after the flash/buzz around the conferences we have quiet time.

 

Yeah, It's going through that endless circle, i.e., we will have to wait for the next Unite event for another marketing campaign making empty promises.

 

But why does unity have to re-invent the wheel all the time, a good networking transport is ready and available already to the community, it consists of 5000 lines of C code plus a C# wrapper, works cross platform and is proven technology used in countless games. It supports everything you want from a network transport and is performing great. (much better than unet ever did);
https://github.com/nxrighthere/ENet-CSharp

Check also the benchmark results here:
https://github.com/nxrighthere/BenchmarkNet/wiki/Benchmark-Results

So if good transports exist, why roll new ones, especially the one you build here:
https://github.com/Unity-Technologies/multiplayer

Which is pretty much a terrible implementation with way too much code to do something so simple.
Your not helping your customers at all here unity!

Now about the higher level stuff that's where your customers DO need help, it's that stuff that would really help to be working in the unity ecosystem....

Your customers are forced to run to solutions like Photon, Smartfox, SpartialOS, which are very expensive, costing per connected client, forcing you to use their cloud, or self hosting with giant licensing costs. the costs of that is way higher than the unity pro licenses per seat, have you thought about that? your scaring your customers away really, because they want to make simple games but are pushed to greedy companies. and decide to move to other engines which have stuff like that build-in.

You guys bought multiplay.co.uk for 20 million. why haven't you invested i don't know, 10% of that and hired some top networking programmers and rolled a great networking solution for your clients, directly integrated with the unity ecosystem, that does not force you to use google cloud by the way.

I can go on and on, but unity has disappointed us with the networking solution, and keeps doing it, again and again.
All the blabla on these blogs and topics on this forum haven't gotten us anywhere near a good solution,

The FPS example was a fiasco too, it was one big project and mess, not having any real networking solution people could use..

For me, it does not matter I rolled my own higher level networking part, but I would assume not everybody is in that position.

Clock is ticking unity, the future is networking. don't disappoint your customers.

 

Enet may be great, but I would be careful with those benchmarks. They don't take into account UDP/IP header so sending 3 packages is counted the same as sending 1 batched package. Heck they don't even touch a network card (clients and servers are in the same machine)

 

What are you smoking?

And never will be, because NIC shouldn't be a bottleneck when you measure performance. I already said this to you once.

 

the bandwidth only takes into account payload. You are not adding UPD/IP header size, resends or acks.

you can tell it to me 100 times and I will still not agree with it. But this is OT

 

No I'll just drop you into ignore list.

 

Ownership and licensing probably makes it a non-starter; the MIT license is pretty benign, but it isn't the same as owning the code outright. No doubt there are other issues as well, but that's likely the top one.

As for the package, it does look pretty slick, but more painful than necessary to implement that cross-platform capability.

 

There is not a single problem, Unity utilizes 3rd-party modules under the hood with a way less liberal licenses. Competitors such as Godot don't have any problems with it. Riot Games is using ENet in League of Legends for about a decade.

And here you are dead wrong as well. Pure C is one of the most portable languages in the digital world. ENet can be compiled without a single problem for any platform including mobiles. Slight changes and improvements are required for consoles. ENet can even work in the browser using Emscripten which compiles LLVM bitcode to JavaScript.

 

The bandwidth is calculated with an external application on the IP level, that includes headers too, it is explained here:
https://github.com/nxrighthere/BenchmarkNet/issues/10
and here:
https://forum.unity.com/threads/ben...miniudp-hazel-photon-and-others.512507/page-6

 

You have every right to be proud of your work, but that doesn't mean its right for every application. In response to your statements.

First: Contracting for use of third party software allows the language of the contract to be negotiated to ensure that it is compatible with Unity's agreements with its users. Open source licenses are fantastic, but they can produce challenges because there is no way to adjust the language to meet the specific needs of the user. Godot is already under the MIT license so its a good fit. A developer using software with an open source license is also fine because they can decide for themselves if their use is compatible with the license.

Second: Pure C is indeed highly portable, but the only binaries available for download are x64 binaries, so someone who wants to casually use the product for iPhone or Android has to download and configure CMake, NDK, and XCode. Not an overwhelming obstacle, and not your problem, but there are easier alternatives for casual users.

 

Ahhh, ok, I did not see that in the code so I misunderstood. I stand corrected on the header size thing then.

 

Browsers do not allow direct access to sockets at all, even in webassembly. The only suitable protocols available are websocket (TCP) and webrtc(UDP) AFAIK.

Has anyone ever gotten enet to work on browsers?

 

Which statements? I didn't say a single word that Unity should integrate ENet into the engine, and more than that I don't want this to happen because Unity doesn't deserve ENet to be a part of the engine's ecosystem, this is my personal opinion.

You don't know anything about MIT it's already clear to us, let's move on.

This is a low-level networking library with a mature protocol encapsulated into UDP (it can work with any other protocol and with a custom sockets if required). ENet is designed for network programmers, not casual users.

 

LOL, have a nice day!

 

enet is based on udp, it is possible to attach it via webrtc thingy, as you mentioned, also checkout https://github.com/mnaamani/enet-emscripten

 

That is your answer?
Come on now)

 

https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/

 

I checked the git and it still hasn't been updated for 3 months. Well, I guess that it should be expected from Unity Network Team...

 

Hi, just popping in to announce that while there's a little lag, please moderate yourselves to be less argumentative about each other and focus on improving Unity's communication here.

There is little wonder Unity would not respond when users are squabbling. I know of staff who no longer post because of PMs, because of demands. Lets ask nicely and be patient.

Last I heard, Unity are simply waiting for a bit of tech in place before moving to public repo.

 

I understand you are a moderator and don't know anything of what is actually happening at unity, but that is the point, were not being told what their up to.

We the clients are sitting here, with an engine with no working networking layer, and unity is dead silent.
No communication, that is so important, what bit of tech? what are they working on?

Why no public repo?

Also why is the code they put up so bad? thousands of lines of code for a ping pong example is unbelievable, they really expect people to use their library?

I hate to be that person, but Unity, wake up, look at your competition. They are making huge steps with network layers...

 

As they stated - it will not WORK on your external version of Unity. You need a source code change inside Unity first. Unity are working on it.

 

Thanks for taking the time to communicate. I can see that you are a bit frustrated, but so are we. Making this information simple to find would be easier on everyone. The same questions keep getting asked because the publicly available answers are spread in multiple locations, and not where one would expect them. Prominently advertised info on the website like https://unity.com/solutions/real-time-multiplayer,
https://support.unity3d.com/hc/en-us/articles/360001252086-UNet-Deprecation-FAQ,
https://blogs.unity3d.com/2018/08/02/evolving-multiplayer-games-beyond-unet/, and
https://blogs.unity3d.com/2018/09/12/multiplayer-connected-games-first-steps-forward/ do not provide a discussion of the delay, so people are confused and come here looking for answers. Even when they find this thread it is confusing because the originating post indicates that it will be kept up to date, but it hasn't been updated since November:

As to the "As they Stated" bit, I'm assuming you are referring to the post below. I'm sure it makes sense to an insider, but to those of us on the outside, it is not clear what the phrase "our CI which only works on the internal repo right now" even means.

Edit: added to reference web pages

 

We just posted an update in the UNet deprecation thread that may be of interest to people following this thread. Most relevant to this group is the new published list of active projects:

• Active Projects list for Networking - the networking team has published their current priorities to the public git repo project view as a "plan of intent" - it's their goal to keep this up-to-date with each of the projects we are currently working on. We've been seeing solid progress internally, and we're hopeful that some of the work-in-progress items listed in Github will be in the hands of the community soon.

Note - sticky post also updated to include this link.

 

Thank you for the update!

Has there been any additional consideration for a separate unity forum space for the new mutiplayer stack? Or a more search-friendly name branding of the system? I believe a central place for info on this would be helpful now, to keep users informed and patient. (Many of us *do* understand that these things take time, and just want to keep updated as it goes along)

In the future, a separate forum space would also be a great place to find learning resources that don't conflict with 3rd party solutions and legacy systems that are heavily discussed in 'Connected Games'.

And as for name branding, searching for "unity multiplayer" is going to be wacky once people start making tutorials for this new system.

 

It is very depressing...to be honest.
It sounds like you bought yourself a couple of years time. As long as there is something while developing, it's ok, like mentality.

Let say you have something stable in the year 2020, it will take at least a year or two before people start supporting it. History shows that Unity tech is very unstable and it breaks without notice and we learned the hardway that it's not a very good idea to get on board soon. Network is by nature very complicated and very easy to break and it will take even longer if done by Unity.

I had high hope that Unity will do something different this time but past few months of your attitude showed that nothing has changed. It's all about lip-service.

I looked at the GitHub list. It's too high level and it means nothing.

Yeah, that's what network system does. So what are you saying?

The question is, how will you do it? What kind of optimization scheme you will use like UE's Replication Graph...
Do you have any ideas what and how you want to solve? That's kind of thing I wanted to see.

Yeah, as you said, you have a few years to think about it and good luck!

 

That's great you have a plan what you want to work on or what you are working on, but work in the open, public github guys!
It's the only way to move this project forward, get feedback early and listen to your customers.

Right now this project is dead in the water already, what is on github right now is terrible, but we can't comment on it properly because we don't know if you are making it better, fixing it, and what you are implementing now.

Once again, guys, there are no secrets here, great lower level libraries have been written, and work well, take lessons from it, take lessons from your concurrence, they are making a great network framework right now and you can learn from them.

Get us in there with you, lets make this a great network library together. not like this.

 

Just to repost what I have said on the deprecation thread. Our opinion should count as we developed one of the first successful Android multiplayer games on Unity.

I call for a senior member of Untys technical staff to own this. Ideally Joachim or someone directly reporting to him.

This situation has gone on for many years now and repeating the past mistakes will result in a mass exodus which no one here wants.

We need to be sure that the CTO is aware of this issue and that progress will be monitored and timely dates set.

Vincenzos comments should be supported- Networking is no longer a nice to have, it's a critical core part of gaming today. Unity will win or lose key customers based on this.

Let me make this patently clear- as a pro Unity dev house. If Unity's networking support fails again and UE4's Android and VR support improves we will be forced to switch.

I have had a public conversation with Tim Sweeney on twitter about improving Android support (see anjin_games twitter handle).

Ultimately we need a viable platform for Android/VR that supports networking properly. Whoever delivers this will win the community.

Unity must provide a new working solution by early 2020 (at the latest) and needs to bet the company on it.

We love you Unity but you can't fail on this one anymore.

 

The reason for that is that no 3rd party solution will ever be fully integrated with the ECS, Burst and Job system. So by using ENET, we'd be missing out on many of the gains that the Data-Oriented-Tech-Stack would bring.

It's the same reason why Unity will have to make an ECS physics engine at some point too

-

Another thing that's important to remember is platform support. Enet is not guaranteed to continue to evolve and support PS5/etc..... It's unclear from Enet's website if they even support current-gen consoles and mobiles. All they say is "ENet works on Windows and any other Unix or Unix-like platform providing a BSD sockets interface"

 

Including the Unity's low-level layer, because network transport is by definition a coarse-grained system which performs long-running continuous I/O while the whole data-oriented tech stack is about fine-grained parallelism.

ENet abstractions are okay for this and can be improved to make packets work on top of large contiguous page-aligned vectored memory blocks if you want a good memory layout. It takes about a day to write the code in plain C, and this is done in my other performance-oriented projects.

That said, my opinion around Unity's networking future and ENet is opposite. It's not about technical problems it's all about the business and investments.

 

Wow, April 7th and still no movement!

 

Hello !
New Networking has formalized protocol desscription document? I need connect this with dotnetty or other console application.

 

https://forum.unity.com/threads/networking-feedback-and-questions.555070/#post-3916921

 

@BHouse Hi, Any ETA about packet fragmentation and reliability? (same functionality as LLAPI)

Edit:
Also, current sample uses Entities 0.0.12-p.19! Latest Entities completly removed [Inject] and has lots of breaking changes, so I think the sample shoud be fixed for it. (even if it doesn't have any new function)

 

When will we see anything structured from Unity, like tutorials, asynchronous etc.?

 

https://github.com/Unity-Technologies/multiplayer
There is new update for Unity Transport!

It seems that new Pipelines API provides abstraction layer for packet processing. But document is minimal yet.

 

Still would like to have built in TCP socket support vs having to roll our own in the new system :\

 

Now that there's reliable-sequenced support in the new transport (for UDP), would you still need TCP? Seems to me like it's the same thing

 

To access say a 3rd party WebSocket API that is reliant on a TCP connection I do. I have no control over the server, only the client. The requirement is a TCP connection.

 

Just use generic TcpClient.
Unity networking is about communication between your game instances

 

Well I am currently using C# sockets; however, is is naive to think that Unity is exclusively for games. To that end it would also be silly for Unity to exclusive work on tools for solely gaming.
The new networking system is more Data Oriented than the current implemntations.

 

point is not about "game" but about "your"
I rephrase: Unity networking is about communication between your game or app instances made with Unity.