A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'UNet' started by BHouse, Aug 2, 2018.
Why not stick with 2017.4 LTS?
Yeah, I'll likely do exactly that for the time being. I wouldn't mind making use of the scriptable render pipeline at some point, but that can wait.
Nevertheless, I'll still have to evaluate my options networking library wise.
Will the new networking engine be hot reload friendly, like the way RakNet is, as opposed to Unet?
Doubt it as they said its being made in C#
I had to use Unet for one of our company tech demo, and even with the awesome work made by vis2k I have to admit that we had a hard time getting a stable network experience (we ended up modifying Unet). I need to start a new project based on the tech demo and don't want to use Unet again. I need to plan our project. Will the new network solution be released in a few weeks, or is it something planned for the end of the year? As we are already using headless servers with docker and kubernetes, I'm really looking forward the new network system and don't really want to move to Pun
I don't believe a timeline for the new networking solution has been given beyond a blog post graphic.
The Unity roadmap doesn't list it for 2018.3, and unless they are changing from what they did with 2017.4 then I'd be surprised to see it shoved into the 2018.4 LTS build (which should really just be a patch release for 2018.3 with no new features). So, around 2019.1 is where I would put my money.
@aabramychev But seriously why killing LLAPI? I do agree HLAPI is over engineered but LLAPI is mostly fine. Just strip the extra fat from LLAPI, make it blazingly fast and leave it as is And I seriously doubt it's possible to create highly efficient low level networking library in pure C#... Or you'd rather recommend sticking with ENet instead of LLAPI?
I have been dealing with silently dropped messages with LLAPI for the past few months , even though I am using the reliable channel. It regularly stops working altogether after a few days of server uptime. In addition, it uses ungodly amounts of memory even compared to pure C# alternatives.
That's interesting to know, thanks! What would you recommend using instead? I was going to use LLAPI for headless Unity servers and since those servers would be setup just for a game session they won't live long(maybe 15 minutes max), so maybe those issues wouldn't affect me...
I think it depends on your game. My game is an MMORPG, latency is not critical, so I am switching to a minimalist TCP based transport just released called Telepathy.
For a fast paced FPS, most people prefer UDP based transports. Enet seems to blow everything else out of the water in the benchmarks. I have not tried any other transport, so I can't really give recommendations.
Else, you can just hang in there and wait for unity to release their new transport announced here.
Hopefully you don't have to deal with these problems in your game.
@pachash, as you asked me, my personal opinion below:
There are two big reason to do this: (1) LLAPI as it is implemented in core, looks like black box, which cause to the problem described for example by @goldbug. When @nxrighthere provided hist test, he received the same problem with memory occupation, but after configuration was changed these problems have gone.. But for these changes we did some work to understand what he is really configured and how, with c# implementation it will be much more clean. (2) Do not pay for features which you will never use, this remove a lot of if() from the code and do code much cleaner. (2.5) support will be much more easy, For example, You won't imagine how many problem related crc error we did resolve, user changed one parameter in configuration and complains that client cannot connect to server. After some discussion we did download his game, compile his server and client, and did find that values are different. In these time we didn't fix bug, we didn't answer to other questions we did not develop new features... With new implementation such kind of problem should gone too.
Except these things, the new layer should be available in open source, so you will be able do additional debugging just in the code, for example to understand why and is it really reliable messages silently dropped (BTW, yes there was a problem, when reliable message can be dropped, but it should be fix now with last patches of 2018 and 2017.3... )
Interface? Nothing new from Send() and Receive() so far not invented, and as far your game based on these two functions you should be able to migrate from one library to another.
@aabramychev What I don't understand is why there will be an additional layer for reliable messages as a package?
The reliable messages were _already_ optional based on configuration of the channel So you could have channels with
QosType.Reliable and have other channels with e.g. QosType.Unreliable What is the advantage of splitting it into extra packages?
To me it seems just to add unnecessary complexity. Probably everyone will need some form of reliable message.
See, there are different reliability types. For example consider the reliability implemented in unet, each reliable messages has a id, and each receiving packet has last received id and bitset of acks (actual algorithm is more difficult but it is ok for illustration). If sender doesn't receive ack for some message in the period == rtt + someDelta; it will resend message. Works fine, but for FPS this approach is still slow and you need to other sort of reliability based on snapshots. Means, on the first update client will send his input K1, in the second frame it will be K1, K2, in the next K1, K2, K3, then K1K2K3K4 till he will receive acknowledge for K3 for example and on the next frame it will sen K4K5... You can see that the communication is still reliable but approach is totally different. Imagine that you have first algorithm has been already implemented, but actually you are using only last one. But for any receiving message you still will need to check if(theMessage is Reliable)... the question here - why? With new system (in theory) you will be able to tune your communication protocol and use only that code which you really need.
Hope, it helps
Thank you for taking time to explain, that makes total sense. So the issue is that there are different approaches of implementing reliable messages depending on the situation, so packages could offer different implementations depending on the scenario.
On another note, will the new networking engine rely on a weaver again like in UNET? It would be *kind* of nice to be able to use the incremental compiler with the new networking, as opposed to right now its either UNET and no inc compiler, or use another library.
I'd imagine that you wouldn't need to weave anything if its all C# and not baked into the engine.
How about performance and memory efficiency? UdpClient in .NET Framework allocates unnecessary internal classes (ex: EndPoint and so on) in every sending/receiving packets.
I concern whether pure C# implementation suffers garbage collection and other performance issues.
@Kichang-Kim, I dont know
I have a question about the legacy unet. With the old peer to peer system I have been making a game that we only have to pay for the web host and use mysql to run it.
Will this new system have peer to peer or do we now have to pay for the service? One of the bet parts of the old system was the peer top peer aspect.
Will this makes those games that are looking to keep cost to web hosting now incur costs per user or data used?
Two very important things that should not get overlooked.
1. Console Integration.
2. Voice Chat.
I feel Voice Chat is something we do ourselves, and not Unity. Unity lays down the framework for it would be nice, but the thing is, what libraries do we use for Voice Chat? That's something Unity doesn't need to tell us what to use, even if they have something we can use it for.
So yeah, the new networking API wouldn't be feasible to have voice chat support, but it would be nice to know some pointers.
I feel like voice chat is something Unity should for me. Why would I want more work?
I feel like voice chat should be done for us. While my general POv is in line with asperatology, I think voice chat is different. Two main reasons:
1. Fairly difficult for beginners
2. Microphone APIs are quite limited.
Also, evidently, if anyone wants a different voice package there is absolutely nothing in the world to stop them trying.
Unity probably wants people to have more reasons to use their network, not less. Built in voice which also works on console would be a very strong reason to use it.
Unity should approach feature design with the following two guidelines.
Provide Default Option.
Be Open and Extensible. (Note: Open in this context doesn't mean open source)
Unet did a decent job of providing a default option. It allowed those who aren't strong network programmers to create networked games. I applaud the Unet creators for that.
Where Unet fell short is in the openness and extensibility of the software design. Had the designers followed SOLID principles (hello dependency inversion) I'd be willing to bet Unet would have been much more successful. The Unet designers had a very specific vision for how a multiplayer framework should work and built a very concrete and rigid codebase to match that vision. There was good intention to support 'extensibility' through the having separate HLAPI and LLAPI, however, the code base of each was still rigid and lacked extensiblility. As times changed and the needs for connected games evolved this meant Unet didn't have the ability to adapt. Anyone who needs to extend Unet, such as for unique platform needs as an example, have to involve ugly hacks or make big compromises just to make things work.
So it seems Unity is finally getting serious about their investment in connected games. Connected games involve voice chat (and console integration). So I believe whatever their solution is they should provide default options and also make their software open and extensible for those who want to quickly adapt to changes (hello consoles).
The UNet features will not be removed until 2019.1, so the existing tutorials should still be relevant until that time. We are working on new tutorial content that we hope to roll out by that date for the new transport.
The FPS Sample is on-track to release a first version publicly in the next couple of months, and it's built in a way that has an ECS-style structure, but also leverages the existing monobehaviours (i.e. a good example of how devs may want to build a game during the transition period to ECS).
A bit of a tangent, but this thread has mentioned several times the "transition period to ECS". This implies that MonoBehaviours are planned to be removed at some point instead of supporting both MonoBehaviours and ECS over the long term. Can you comment on that? I've only seen ECS discussed as an alternative elsewhere, not as the eventual only built in option.
There are no plans to depreciate monobehaviour and the classic way of working. Transition here means developers porting their project.
Next a couple of months before we see what the FPS template will look like? Hmm.. Berlin United said the FPS Template will come this Summer. Technically, the summer is over in about a week. Well, there is even very little information available about the network library itself and the further delaying makes me concerned a lot. I develop PC online games for the high-end and I think a good network library in Unity is the weakest link in terms of systems and I hope you guys will really take this seriously this time.
Even if you try, I don't think you will get this right at the first time and you need to state your goal clearly as you cannot satisfy everyone's need and be open about it. If you don't have anything to share at this moment, (almost at the end of the summer), it's either you don't have a really good idea how to solve the problem or there isn't much to share.
From what I watched and read from the Berlin United, I take it that Unity seemed to realize how important the network games are and you decided to tackle the FPS games first.
It's quite late but better late than never. On the positive side, I think it's really a good start you chose FPS game, as network performance requirement for FPS game is the highest. It has to have 30+ tickrate, but some games (CSGO) can go up to 128+ tickrate for the competitive environment and nowadays, there are many games that have up to 100+ players playing at the same time.
If I were to make FPS that with about 10s of players, any library will work with reasonable performance. But in order to make, for example, a game like PUBG or similar, you will need a sophisticated filtering system to send the data that are only relevant, prioritize what's more important, how frequently to sync, whether to send it reliably or not, collect only the data that are changed from the last send, make deltas, compress and send it.
You might say, what about other types of games? Well, the turn-based game will not need the sophisticated filtering system but it can benefit to send the optimized data to save packets. And on the other extreme side, for MMORPG games, everything applies the same but you will need a zone manager that sits on top of the filtering system but that's not that hard to make. Yes, it needs be persistent but then it has nothing to do with the network itself. So keep on pushing before half-finishing it and move to the next template. Other templates can be based off of the FPS template, in my view.
I know it's not an easy problem to solve and that's why I'm really concerned that you start with the right goals and approaches. I'm sorry to bring this up but Unreal Engine is known to have a good network solution for years but they recently upgraded their network library to a whole new level in order to optimize for their popular game called Fortnite. I don't mean to dis Unity in any means but I really hope Unity to succeed. Unreal have their own weakness and I think it's mostly due to the lack of C#(or any other good scripting language that can be better than C# but I don't think there is.)
Instead of inventing the new wheel, I really wish you study how Unreal network system works. I've worked with Unreal network for years, and I think it's probably the best system out there and it will very difficult to top it. Just copy the high-level concept and optimize with ECS and we can perhaps make it even faster network engine.
I think it's a good opportunity to take the leadership. With good network library, there will be tons of online game developers who will support Unity, me and my colleagues at least. ^^ Unity is much fun to work and the level of graphics quality is getting much better and you can squeeze out the most performance using ECS. ECS has given us whole new opportunities and please take full advantage of it.
As an example, what I mentioned above can run in parallel with one frame offseted, like double buffering in graphics. With double buffering, there will be a bit of extra latency but network inheritently is latent anyway. But there is a way to reduce the latency with many processes running in parallel. With many processes running in parallel, the throughput can be much higher so we have room to send packets in 1/100 second instead of every 1/30 second. What changed within the same time period are the same, therefore you are not increasing the total amount of data(except for headers) but the latency will actually be decresed. What you are end of having is that very efficient and very responsive network system without increasing packet size. I hope it makes sense.
Perhaps you have better idea than Epic. I would like to see what you have in your mind and please start sharing be open about it.
I would be more than happy to share my experiences. ^^
As UNet replacement will be done in collaboration with Google, I wondered if Google Firebase https://firebase.google.com/ will play a role in this rework: Especially because there is already a Unity SDK: https://firebase.google.com/docs/unity/setup
About features, I believe those of Firebase are a good starting list
It would be interesting to know if the new API will be similar to firebase as it would permit to begin develop.
Also, about pricing will it be similar to Firebase: https://firebase.google.com/pricing/ ?
Thanks, I am impatient to get my hands on this.
So UNET is being phased out, but there's no alternative yet? So it's not really possible to start developing a multi-player game right now?
There is a community version that's free to use for everyone, and open source.
Can you tell us when this will happen?
As I understood it the hosting services are , not the netcode itself.
I'm a little late to the news on this unfortunately. Was hoping to finish up development in the next 6 months. Current using the HLAPI and a Asset Store / Custom package for dedicated server and cloud hosting.
The project is not overly complicated but it would be nice to get a jump on this as early as possible and just see whats involved and if its worth switching. Looks like they're might be some benefits to switching the hosting solution if it can auto scale easier than what I currently have, and hopefully gain a real skill based matchmaking service of some sort.
Any price information is useful as well. As right now the custom solution for dedicated servers is far cheaper than UNET's peer to peer solution.
Is there any ETA regarding when this might be available for early testing / integration? I filled out the contact us information located here but would like to get involved as soon as possible.
They mentioned that you can estimate pricing right now based on Google's existing cloud services pricing. As far as Google's pricing goes, they are generally in line with AWS and Azure from what I can tell, and significantly more expensive than alternative VPS or dedicated hardware rentals if you need more than their lowest tier products.
This gives me an idea at least.
I've looked at Amazon and their GameLift SDK previously and unfortunately they looked like they were going to be significantly more than Digital Ocean after all was said and done. Although having SDK support, better scaling, and a skill based matchmaker are possibly worth it.
Do we know if the API and "Services/hosting" integration are going to be available simultaneously? Or is the networking API going to be released first with the hosting / services integration coming at a later date?
I'm really looking forward to this. I hope that you also provide some sound examples/tutorials/documentation on how to migrate from current UNET (incl. both HLAPI and LLAPI) to the new networking layer. It does not need to be a step-by-step migration guide, but at least a guide that shows how to transpose the concepts and solutions. For example, what am I doing with all of my SyncVars, SyncLists, etc.? IMHO these are nice and useful things. Do I need to start completely new with my game architecture and code base? Currently, I'm afraid that many of the good features of current UNET get lost along the way and that there just might be holes afterwards. I hope that you will prove me wrong on this though.
Moreover, I'm not fully convinced yet that all these new plans are fully inline with what most people really want. Chances are that I am wrong here as well but I don't know. For example, personally I do not care too much about ECS right now. Instead, I do care about the very basics to finish a stable multiplayer game using network features such as support for both dedicated servers and player-hosted servers, both internet and LAN, optional and fair matchmaking & relay solutions, NAT punch through, options for both reliable and unreliable channels, optimized and easy to use data synchronization concepts, etc.
Its been noted by a few with the notes on LAN, I want to echo that. As an indie when I consider multiplayer I can never go dedicated server *only* as the game must have a fallback that is not dependent on maintenance costs such as hosted servers. This solution needs to be as simple as possible for the gamers to get working ideally a direct connection such as a simple P2P where in the host is the server as this requires the least set up on the users part and has the fewest moving parts in terms of processes on the machines.
In an ideal world creating a game that supports multiple options, in the game with no additional set up on the users part is what we want. e.g. LAN, Direct Connection or Server based multiplayer. and it is in that order in terms of priority e.g. LAN or otherwise no internet required thats 1st priority in many cases, Direct Conneciton or otherwise not dependent on any maintained service that is 1st or 2nd priority (1st if same as LAN 2nd if using something like a routing service like Steam does), having dedicated servers that is always a nice to have for us not a priority and *can not* be the 'only' option.
Hello @BHouse and thanks for keeping us updated.
Any news about free tier ? Google Compute Engine offers a free f1-micro Linux instance, which is more than enough for development and closed alpha testing.
I wonder if we will have something like that, otherwise why not just use bare-bones Google Compute Engine ?
This is what makes me even-more concerned. Why was an enterprise, premium feature short staffed? Why was there 0 support for UNET (no email support, no docs, not even forum mods)? Why were UNET docs not even given the most modest priority? What else is short staffed? Why do we keep hearing that Unity x and y features are all short-staffed when they make enough money to build Rome in a single day.
How many total developers does Unity have? hire some more staff with those monthly subs, guys ;p sort of like RAM -- unused budget is a useless budget.
Anyway, I guess I'm just disappointed that they let this drag so far before doing anything about it, and hoping it doesn't reveal a pattern.
Hi, what is the substitute for Network.time? I would also highly appreciate any shred of documentation for the new networking system.
Please see Unity's blog on this https://blogs.unity3d.com/2018/09/12/multiplayer-connected-games-first-steps-forward/
I thought we went over this, Unity doesnt make documentation until 3 generations of unity are complete.
Jokes aside, having an early documentation (even if its preview) would be nice, to soften the transition when a release is available.
I see in the 2018.3 beta the UNET componenets are marked as depricated yet you dont have any thing in place yet to replace it. Are you planing on releasing the replacement for UNET in 2018.3 or do you intend to have a gap where Unity has no inbult networking solution?
I assume you may comeback with 'its depricated but still there and should work till 2019.1' ... I get that but I wouldn't have expected you to depricate the prior before releasing the succesor or did I just overlook something somewhere?
i wait from unity 5.x.x a valid multiplayer system, so team say wait for UNET in 2017. This is a worst case and unique. unet is obsolete already in the 2018 version? i want make client/server application, less difficult for servers than massive multiplayer and i can't. i have not a valid base that a valid basis that ensures operation over time. Pheraps external package will be useful but what? it don't exists, all is really confuse. if team not solve this i think that unity3d is not really useful like they intend.
Deprecation warnings are for folks who would have missed this information otherwise. Since they plan to remove UNET by 2019.1, the deprecation warnings HAVE to go in 2018.3. Even if the removal wasn't until further into 2019, the warning should still be added as soon as possible so you can plan ahead. Many people will not be moving forward with whatever new networking solution Unity has, even if we had a preview now. Those folks need as much lead time as possible to find replacements for their functionality.
UNET, for good and bad, seems to have been a learning experience for Unity. The bad is that people's expectations were definitely abused. The good side is that while the entire engine is moving into a new generation (ECS/Jobs,) they're starting fresh with networking as well. The new team seems to be working to gather the expertise and information to identify and serve the actual use cases that have been difficult/impossible for Unity users on the majority of the spectrum from indie to enterprise.
I was pretty let down by UNET and the HLAPI. MLAPI is/was promising but late to the game, and there literally was no other alternative that wasn't...worse. So I had to dig deep into it to make it work for me. It was my own learning experience. Whatever Unity comes up with next, I know I can make that work too, and expect it to be a more thoughtful and useful product that improves accessibility. They're talking a lot about solutions for deployment and scaling that I expect are intended to address the "we can't have dedicated servers!" folks among others. I'm really looking forward to this!
We have the same problem. Try the UNET Community Edition, aka Mirror (see my signature).
And has 300+ bug fixes.
My experience with networking with Unity since 2013 says unfortunately to both avoid 3rd party solutions as well as Unity official solutions. The 3rd party solutions come and go, as soon as you are making progress with your game they stop supporting it (I put a lot of work into using uLink until that disappeared), and surprisingly the same has been happening with the official Unity networking solutions. They are moving on to their 3rd networking API now in as many years.
Photon looks like it has staying power, so may be an exception. The fact that @vis2k has popular Asset Store products now intended to sit on top of the free Mirror project implies Mirror is likely sticking around for a while as well.
Other than those 2, I think your best bet is to use the C# Socket class and roll your own higher level networking solution. The Socket class is not going away any time soon, if ever, and you're then not dependent on another actor to maintain your networking system. This is the route I recently went.
I just think it is premature to expect Unity to produce a networking solution that they commit to for the long haul. Maybe I'm just a bit jaded moving from uLink to Unet and becoming a bit of a fanboy, only to watch it become abandoned so quickly and for the last couple years no official comment on that abandonment - especially with more details and more excitement coming out regarding the development and launch of Unet at the time than there seems to be now for this new planned solution.
I just haven't seen any reason to believe that this new networking solution won't be effectively abandoned in another year. And the fact that the majority of official information regarding the new networking has been in relation to paid services, such as their Google partnership, rather than on the actual networking implementation, tells me their priorities might not even be in the right place.