@Unity: Hello, is there anybody out there? :P

Quick question! Will the upcoming NAT punchthrough work with WebGL?

 

Is it possible disable LogIng for UNET?

 

Thanks dev, I already figured out, that Debug is going in One frame. And I already change my log level. Everything works like a charm.


My respawn method works great now.

 

It's all good now, No errors, it was only a Warnings that took a lot of CPU usage

 

YOU EXIST!!! Thanks for the update Honestly, docs and a working, in-house, minimal demo (read: The opposite of "Tanks!"), including a REAL lobby -- that's where 1/2 the issues lie -- with standard callback examples -- would satisfy "the beginning" of redeeming UNET: Because there's no sufficient docs/demos, not even the community can help each other.

Unfortunately I agree with this guy. One of the biggest woes of UNET are broken promises. I remember Host Migration "going to be fixed soon" (quoted almost a year ago).

Awesome!

That's wonderful, but if there's no docs or support (although kudos for the recent attention), there's still a long way to go.

Although this rocks, back to the "KISS" essentials: docs, minimal in-house demo, working host migration would be even better (as amazing as that feature is).

I have one simple question for you that I've been asking since June of last year: HOW do you properly disconnect using HLAPI in the lobby?

The core files that needed updating (mostly having to do with lobby) were not in 5.5 -- but I can't speak for 5.6 (although these aren't 1.5 years apart, I saw a # a while back that I'm too lazy to go back and find). For example, this was the only example we had to go by to figure out UNET:

https://www.diffchecker.com/diff

5.4 vs 5.6

Anyway, stick around Glad to see some transparency and progress.

 

This is the latest in a handful of threads I've seen just BASHING either Unity or specifically the UNET team, whatever that means to people. I assume most of you have worked in software and understand the realities of shipping a product, good or bad. Networking is complicated. I see a lot of complaints that stem, ultimately, from them not understanding networking or UNET. A few of those complaints do at least try to unload the blame on the supposedly bad documentation, but this isn't even really fair IMO. The information has been there for years, as has the source, as have a lot of resources on this forum that have figured most of these things out and get tired of answering the same questions about authority or whatever it is, only to have some angry customer jump in and say how stupid it is that UNET even has player authority. Well, ok. I think Unity's biggest mistake was giving customers something as complicated as networking and telling them it will be easy (or bug free.)
Full disclosure, I haven't shipped a game, UNET or otherwise, so I'm always waiting to see what new frustrations await. But from what I can see, the very few legitimate complaints or bugs in UNET are hammered SO HARD by a really angry minority, that it overall gives the impression that UNET is fundamentally flawed and Unity are a bunch of jerks. UNET is what it is. If it doesn't work for you, move on or change the code yourself. Unity are not a bunch of jerks any more than any other bunch of computer people are. That's my opinion, formed from trying to use Unity for about 3 years and schlepping software while getting blamed for other people's problems and mistakes for about 18.

 

You're probably confusing things here. "Tanks!" is a multiplayer demo made by Unity, obviously using UNET as the network provider. I have no information that this is going to change any time soon. "Tanks Multiplayer" is an asset made solely by us, supporting both UNET and Photon. We've explained why we have added Photon support to it, and why we would not use UNET for production in its current state in that blog post. Although the guys over at Exit Games used Unity's Tanks! images in their blog post (I've only seen this now), these are two different assets. I'll contact them to correct this.

 

Interesting thread. I have been working with UNET 10 hours a day for almost two years now, working on uMMORPG, uMOBA, VOXL. Here are my thoughts on UNET after all this time:

The LLAPI works. And if it doesn't, you can contact alex abramychev, he will fix the bug and probably thank you for it.

The HLAPI would be the perfect solution with SyncVars, Commands, Rpcs. I used it in all my projects, and there is a reason for it. It makes development 10x faster and the code 10x shorter. There is absolutely no doubt that this is the right concept for Unity networking. Once you understand it, it makes perfect sense.

The problem is that no one cares about the HLAPI. Here is some simple proof: I reported the highest rated HLAPI bug an enternity ago when @seanr still worked here. A critical bug that hasn't been fixed for over a year, with the usual excuses. This is just one bug, there are countless of others. Or what about NetworkTransform?

We see very clearly that no one here cares about HLAPI bugs and that every promise is an empty promise. The question is, why? Let's think about the possible reasons:

• The HLAPI developer(s) simply aren't skilled enough to deal with it. From what we have seen in the presentations, this is likely not the case. All of them worked on major networking projects before coming to Unity.
  
• The HLAPI developer(s) could be part of the 80% group of programmers. They do the work to get paid, and go home worrying about other stuff. Life is difficult, this is understandable and definitely not the programmers fault. It would be Unity's fault for hiring the wrong person. But then this is Unity, the #1 game engine in the world. Why would they hire someone who isn't driven to push out the best networking solution?
  
• Focusing on the wrong features. They mentioned working on steam integration, nat punchthrough and other weird features, essentially building a skycraper on top of a broken fundament. This is a common beginners mistake and it takes only so many community complaints until the fundament is thrown out and replaced with a better one. As far as we know, neither of the UNET developers is a complete beginner. We can assume that they are aware of the problem. We can assume that they would be skilled enough to come up with a new, more simple and more solid HLAPI. Yet they don't, so it might not be their decision to make, indicating a higher up problem.
• Unity focuses on the multiplayer services. Unity is a big business. They need money to continue their work. Telling the UNET guys to focus all their efforts on the multiplayer services makes perfect sense from a business perspective. New customers don't know about the state of the HLAPI, so they would likely be happy to pay. If given the option between making thousands a month with a S***ty HLAPI and lots of services vs. the option to make 0 a month with a great HLAPI and no services, it's the perfect explanation for the UNET situation here. It's sad, but let's be honest, who wouldn't do the same?

I think it's safe to say that every sane person here would rather have the UNET devs spend 100% of their energy on the LLAPI and HLAPI, making it absolutely bulletproof and simple while letting the community come up with nat punchthrough, steam integrations, hosting services and so on. It makes sense to care about monetization instead, but at what cost? UNET is about to fail big time, especially with the new Gamesparks partnership on the asset store.

This whole situation sounds like a typical case of letting managers make programming decisions. Correct me if I am wrong, but I just can't see any other reason to make any sense. There is just no way that a 4+ people team of networking professionals isn't capable of developing a good HLAPI, when one guy is capable of developing a good LLAPI.

Seriously Unity. Pick the most skilled developer from the UNET team, double his pay, lock his office door and make him rewrite the HLAPI while spending 30 minutes every day on this forum. This is not AI, not rocket science, not physics, not self driving cars. All it takes is a good architecture. Every single problem can be debugged, every packet can be traced. There is no reason why the HLAPI has to suck if someone would care about it. There is no excuse.

 

Agreed. I've been a part of the developer world for a long time and unfortunately this is a recurring theme that I've had to witness a few times.

Let's hope they get this sorted out...
Maybe someone from the Unity team can comment on this? (or send a PM )

 

Thanks for the clarity, great work guys.

 

For me this is not the case. For me the most important features are the low level connection robustness, NAT punchthrough, and steam support. What good is the HLAPI if I can't connect to other players in the 1st place? As long as I can connect to other players, and send data using MessageBase, then I am happy. I do not need any HLAPI. Just speaking for myself.

I believe HLAPI pre-packed things (like NetworkTransform) will never work for the majority of players because every game is going to have vastly different controls/physics. So (in my opinion) there isn't much point to Unity spending time on this.

 

Agreed that having a world-class LLAPI should be the #1 priority. And the 5.6 network transport + NAT punchthrough in Unity 2017 seem to be bringing us exactly that.

I dislike the overly-simplistic code architecture that the HLAPI imposes, even though I understand why it is like that (for accessibility). I prefer recreating something that is similar to UE4's Gameplay Framework, with servers and clients being separate objects instead of having an omnipotent NetworkManager, online and offline being seamless, and with a networked "Actor + ActorComponents" system that replaces NetworkIdentities and NetworkBehaviours. And with all the known bugs, I think it's just safer to make my own system in order to have complete control/knowledge over it.

Also big thanks to @Erik-Juhl for explaining the situation and clarifying everything. I think people will be much less inclined to complain if they know that the HLAPI is waiting for a lead engineer before work can really resume. Sure it's not an ideal situation, but at least now we know what's going on

 

My vote is 100% for this, even if I am a bit biased. @Zullar I see where you're coming from but the community can solve these problems. The community can't expand on or solve fundamental issues with the HLAPI / LLAPI. And damnit I really wanted to write that steam integration plugin..even if I never have time..

 

i agree with @Zullar .... unet should just simply work out of the box without dependence on 3rd party, closed source plugins.

i mean really...could you imagine if the rest of the unity engine were dependent on spending $50 for a 3rd party graphics plugin just to draw something on the screen? or another $55 just to play audio? controller input is another $25. nobody would use it. this is why a lot of people don't use unet.

unity is successful because you don't have to worry about boilerplate issues like rendering images, playing sound, and managing input. as far as unet is concerned, being able to connect players to each other in an efficient manner should be considered a boilerplate, high priority issue. (the relay servers don't count...they're bad)

 

Here is their new blog post on unet
https://blogs.unity3d.com/2017/03/17/update-on-unity-multiplayer-current-and-future/

 

Thanks for the clarification @Erik-Juhl, this brings more transparency to the table. I guess many of us in the forum suspected some kind of gap after Sean left.

The current improvements on the LLAPI are a great thing! I also think that a stable and bullet-proof LLAPI is very important as it is the UNET core at bare bones. Still, I really hope you get back to 100% fuel on the HLAPI part as well soon, because I think it is important too. It's the thing that might get many non-expert people into networking in the first place. Also, a nice and optimized HLAPI is able to shorten the code and make a programmers life much more easy. So, I believe it is 100% worth the efforts to invest further work here to improve it and just make it as good as possible.

Also, I like to say that I really appreciate the current features which are to come. I agree that the community can achieve amazing things. Still, we all know that there is always a certain risk when relying on third party assets. For example, loss of compatibility and support at some time. For some assets, this risk might be very low though, because there are amazingly dedicated community devs out there. Ideally, I like the idea of possible collaborations between the official UNET team and 3rd party asset developers in order to achieve best-possible solutions at a faster speed, and then get them officially integrated into the whole UNET framework. Maybe, this can be an option somehow? At the end of the day, I would like to see UNET include all the features I need to ship a stable multiplayer game. Just my 2 cents though.

 

I still don't really get what people are griping about or why they're trying to tell Unity how to allocate their resources. Bulletproof LLAPI? It worked before, they've improved it, let's move on. "Improve" or "fix" or "whatever" the HLAPI? Pfft. First you have to get everyone to agree on what they want it to do. The users on this forum don't want an HLAPI, they want a P2PAPI or a client-server API, but whatever it is, they seem to want it all spelled out for them and anything that doesn't work as expected is a bug, poor design, docs, whatever. Let's be real. The services are what don't work, and even that is really a matter of mismatched expectations more than something the doesn't "work." So don't use them. Maybe educate yourself about what the APIs do (and can do) before posting a bunch of stuff claiming that Unet doesn't work, will never work, isn't supported...

Pfft.

 

Hi, you must be new here. Many of us were promised docs, demos, and improvements. However, there has not been. The only demo has been an outsourced production-ready (opposite of minimalist like all their other demos) demo that doesn't even use the advertised features.

Host migration was (is?) still advertised as a feature, although confirmed by a dev broken almost a year ago. "Fixed soon!" Nope.

Support tickets were unanswered, for even the most basic questions.

Community can't even help each other because there's no proper docs and no one even knows the standard.

SyncVars randomly don't work.

Lobby features simply don't exist -- they just "left it" 1/2 working. The devs still didn't even answer how to properly disconnect - something people have been asking for the standard for 6 months+ now. I asked it again above, but the answer was skipped.

That said, @Erik-Juhl -- simple question: What is the standard of how to properly disconnect from a game/lobby?

^ People are upset because they don't even know simple standards and no one will answer when asked, just like this question above.

These devs above answering? It's the first devs that even answered a real mplayer question about UNET for the past year (not even exaggerating). No staff even roams here. Look when I posted OP and how long it took to get their attention!

Why are we mad? Broken promises beyond comprehension, no docs, no demos, and overall NOTHING compared to the usual standard of Unity. These feature sets shouldn't even be advertised at all - and it should be called alpha.

Many of us aren't just making games for hobbies -- we are spending time and effort relying on Unity to pay rent. We took a chance out there to use this new technology that they SUPER HYPED UP and pretended they are all over it. I follow Unity's usual standards and assumed their word was true. It was not. I'm sure I'm not the only one upset for these very reasons.

I'm with Photon now and I'm never going back. However, I still talk about UNET because I was really getting into it and hoped that it worked. I still hope it works. I also still hope that they communicate better publicly (that blog was a good start) that this is a VERY EARLY, nearly unusable alpha. We wasted months on UNET and my entire purpose of this thread (originally posted when I still used UNET) is for hopes they keep their promises so other indie devs don't suffer like we have.

 

Repeating something doesn't make it correct.

Since this gets brought up constantly, great place to start. Thank you. Host migration is only broken using the relay service, I believe.

I see the same closed tickets linked to, over and over. Let me translate. "Works as designed" means you are not using the code correctly.

While that's only your opinion, it's also pretty provably false. This forum is littered with messages with random users helping each other. That's why I'm usually on here, rather than to abuse people over something I don't understand. The docs cover everything I've needed to know, and when I didn't understand something, I was able to get help with it here, usually just from searching for an already answered question. The "expert" forums like SO are also full of UNET knowledge. Furthermore, the code is open source, so the standard could not be more known.

Too vague to bother answering, but I assume that like the rest of this stuff, you just don't know how to use it, don't like how it works, or would rather pay for another solution from somewhere else. Go for it.

Lobby is not even a part of UNET and has been updated many times. It's example code. If you can't make it work, why are you trying to use it?

Impossible-to-satisfy customers bring that out in people.

Just lol.

 

To do something other than nay-say:

I think UNET is great. Some parts of it stalled, and that's sad, but I'm not angry because I didn't pay for it. Which brings me to the next part, the harder part. I think UNET is great, but I don't like or want the services Unity provides. That's a bummer for them because the services are why they are doing this in the first place. Luckily for me though, that's the majority of what is "broken" or hard to use in UNET.

When I started using Unity, UGUI was just about to hit and UNET was close behind. I was, and still am, a frustrated install developer, not a game programmer. That said, all it took was a whole lot of hard work and frustration (and a broken keyboard) to understand the various types of game networking and what UNET was well enough to know how to pick and choose the functionality I needed (from working examples in the asset store!) and come up with working demos that just need a back-end service. Since my project includes a charity deployment with privacy/security concerns, I MUST self-host, so I'm a little stalled on that. If I wanted to use the cloud or do internet matches, I'd be all set.

As for p2p, yep, seems like it's pretty hard to use UNET out of the box the way people want to, but its important to note that only parts of it are broken, and that doesn't mean the LLAPI or HLAPI are broken. The services are broken and/or not useful. Fortunately, there are already good alternatives, so I don't know why Unity would really give a rats ass about fixing their "me too" implementation.

 

It's 2017. You are using LAN only in your game...?

Funny you say that. I was told worked as designed for host migration last year. They finally admit it in in June that they were able to reproduce it and it was confirmed broken for non-LAN (which is 99% of games that attempt multiplayer in the past 10 years). Other tickets I waited for months of no answer, following up every 2 weeks. One of the QA eventually said, literally this: "I can't force a developer to answer this question" in regards to how to properly disconnect from UNET. This was 2 months later.

It's not that I'm not getting worked as intended (with the exception of host migration, which they changed their answer to later) -- there is simply no answer because no one even knows UNET standards -- there are no standards, yet (docs come 1st - minimalist demo reinforces).

The standard of early 2015 without using HLAPI at all, sure. What questions are you asking? You must have a ninja account because you sure didn't ask here.

SyncVars don't work? This is always the top of the forum -- they inconsistently don't work -- random, a dev's worst nightmare. Even Tanks Multiplayer mentioned this.

It's been asked repeatedly by more than just myself. Here, do a search - for forums alone, not even Unity Answers. Find an answer. It won't happen.

I've provided facts - you have only provided trolls.

 

Angusmf stop trolling. There is nothing wrong with coming to the forums to discuss bugs and broken features in hopes that things will be fixed.

I am not upset about UNET as long as the dev's making progress are communicating future plans. I think it will be great in the end.

Regarding SyncVar not working... they do not. But it's not random. Here's the reasons.
1: SyncVars can become desynced between server and client. This occurs due another client connecting calling OnSerialize while the value has been changed on the server, but before NetworkSendInterval has expired. This clears dirty bits leaving existing clients with de-synced values. The new client will get the correct value. The SyncVar will remain de-synced indefinitely until it is changed again (or something forces the script to serialize).
2: SyncVars hooks can fail. This occurs on scene changes. Briefly during scene changes NetworkIdentity.observers are removed, and then re-added when the client loads. Any SyncVar changes are not sent to the unobserved client during this period of scene transition (10+ frames depending on load time). When the client loads the new scene the object is re-spawned erroneously. This forces OnSerialize (with initialState == true) to be pushed to the client that just loaded. This correctly sets the SyncVar to the latest value, but hooks are not called (due to initialState == true)
3: Hooks are inconsistent. For SyncVar hooks are called before value change, and for SyncList hooks are called after value change.
4: Callback information is insufficient. For example on SyncList remove callback it tells you the index that was removed... but you have no idea *what* was removed (because it is no longer in the list).
5: Setting a SyncVar to the same value causes dirty bits to flag and chews up network bandwidth.
6: SyncVars are limited to 32/script (design issue... not a bug)
7: SyncVars cannot be set by clients (design issue... not a bug)

That specific enough for you?

 

Woah. Hold up. This thread is the definition of trolling. I'm trying to provide a less biased voice (and a little support for the devs who honestly don't need this crap. It's not helpful.) I said UNET is great, and I think that these threads, with exaggerations, inflammatory language, and misconceptions, hurt the chances a lot of people have of finding that out. I also said, "I still don't really get what people are griping about or why they're trying to tell Unity how to allocate their resources." dylanh7244 was kind enough to tell me in private message why he cares enough about these issues to go to these lengths. I'm kind enough not to repeat them, but let's say I stand by my assertion that there's a need for a more unbiased voice.

What I see below that are 7 "issues" you seem to know how to work around or are just things you think should work differently. I feel your pain, but this is outrageous behavior from adults, in my own personal opinion.

My private message to dylanh was to reach out and explain myself, to prevent some flame war here. I really am not trying to troll. I'm trying to say you guys are doing a disservice to the community you purport to be helping.

 

Your argument for knowing what all users want is what exactly?
First, you might want to look into this thread. It is a good example of nice collaboration between UNET developers and the community, and it provides a sound overview of what different people want and need. Of course final choices always remain at the unity team. I cannot imagine that anyone here would ever question this. But we can always point to features we consider beneficial, and to bugs which are currently remaining, in order to help to make UNET better for everone. People here are just doing this.

Just try to not be polemic or derogatory yourself.

 

@moco2k Thanks for the advice I suppose, and sorry to be polemic, but I think you are missing my point as well. I don't know what all users want, but neither do those two guys, and neither do you. The important part of HLAPI is that it's high level, but "high level" depends a lot on what you're trying to implement. Letting unity know what you need is one thing. But conflating your personal problems getting a project to work with some kind of (imaginary) intentional conspiracy by unity to keep us in the dark or make us suffer is ridiculous and not helpful. And dare I say it, it pisses me off sometimes. These two guys think they "won" something by constantly complaining about the same exaggerated issues and lack of response. They post troll threads like this and then hijack legit troubleshooting conversations with links to them. The claim that unity doesn't respond and that they would not be working on anything if it wasn't for all the noise is just wrong. They've obviously been working and I've seen numerous responses to their gripes, just nothing they liked.

I got no problem with you, bud, but if you think I'm the one causing trouble here, think again.

---edit---
The situation as I see it:
1. HLAPI is semi-authoritative and for a variety of reasons, some people will never be happy about that.
2. That said, it's almost the only restriction on what you can do with it aside from the bugs and limitations that we've all been made so aware of now, though many are misunderstood.
3. Possible omission from the docs I haven't read from cover to cover: An easy-to-understand yet exhaustive explanation of point 1 and what that means for the subset of games and networking types you can implement with it.
4. The forum is a useful place for finding tips for dealing with 1, 2, and 3 but has a lot of noise, as all forums do, that confuse the issue for folks without the context of already understanding 1, 2, and 3.

I've mentioned above I'm a software dev IRL, and what we do when confronted with an unruly 3rd party lib (all day, every day) is:
a) Work around it or find another lib, or
b) Tell our boss it's impossible to do what they want because of the 3rd party.

Just saying.

 

I want to make games and i want the easiest tools for this, including networking. So i would like a working HLAPI with a working transform/animation/properties sync and ideally i shouldn't even need to know what the LLAPI is.

@Erik-Juhl I'm very sorry that you and the rest of the UNet team have to take the blame for the UNet issues because obviously Unity doesn't have enough manpower/resources assigned to UNet. Like in any other business this
a) stays like this and the client is not satisfied and finds another solution after too much dissatisfaction - or
b) Management assigns more resources.

I'm curious to see who releases first: UNet or Photon Thunder ( https://www.photonengine.com/en/Thunder).

 

Thanks for clarifying. That's what we wanted, the cold hard truth

 

Glad I read this epic thread day one into UNET. Moral of the story don't use UNET if I want an easy life. Or is it safe to use now?

 

OMG, please don't start this again.

UNET works as well as anything else out there for unity, if not better. Source is available and time will tell if they take pull requests seriously. I've submitted two fixes recently. I highly recommend it over any other currently available solution unless your game's networking requirements closely fits the profile of another known-working example using that solution--with source available. The actual moral of the story is, if you want an easy life don't do multiplayer programming. Ever. It takes a lot of reading and experimenting.

 

Not only is this hilarious and not-so-true, but it sounds totally biased -- likely due to his UNET asset store item

 

its an open source product that you can find on github and its not his product. no money involved

 

@dylanh7244

Could you please show at least a professional level of respect to the unet dev team and other developers? Your posts are unnecessarily hypobolic and condescending.

 

Hilarious indeed. Accusations of bias from this guy? He told me privately the reason he was harassing the dev team publicly was that he had clients and "partners" he had promised UNET-based product to but was unable to make it work. All that spam was so he could make excuses.

 

Their dev team rocks, it's just poor upper mgmt decision making -- they don't give the epic dev duo enough resources and call it an enterprise product that they're charging for. I've never insulted the devs -- my words target UNET itself, in it's current, unmoving state. For what the the devs have accomplished for UNET with only 2 people is miraculous, however again -- UNET itself (not the devs, but more so the upper mgmt decisions to market more than implement), thanks to a lack of resources, is simply not there yet -- and it won't be without proper resource allocations.

It took this thread bumping for 6 months just to get some form of transparency -- shouldn't even have to do this. However, it's at least in the right direction, taking time or not.

As for respect to other developers -- they have it - except for Angus, who has been nothing but a troll this entire thread (scroll up even on this page, you'll see. I'm not the only one calling him a troll).

Or a troll translation of the same thing as above stating it's sad that things like this has to be bumped in order to get attention to fix bugs, get proper docs or keep promises like host migration. I could care less if it's UNET -- like most people, we just need the job done -- I care more about time lost than anything. Clients and partners? I wish, lol. If we had clients and partners to promise these things to, I wouldn't suggest a product that was in beta, at the time I started using it.

I've just been making a single game, self-published. Troll on bro.

 

Thunder seems to be stuck so I switched to Photon Bolt after they added relay server support and matchmaking. I think Bolt is great (I'm not using it for any authoritative networking) and can highly recommend it.

 

Seems promising. What about closed console networks where we know IP (like steamworks?)

I also need host migration and drop in. These are modern staples

Thanks.

 

You didn't. You literally did not need to. You accomplished nothing of consequence. My life, as someone who uses UNET almost every day, has not changed in any way as a result of your posts. At least Zullar took the time to figure out exactly what his problems with the API were and can state them coherently.

Must be true then. Except for the parts about me being a unity dev or trying to pimp an asset for money. I actual AM trying to help. I reply to people's questions with thoughtful, and hopefully helpful answers. I've sent two HLAPI fixes to Unity for the only stuff that hasn't worked for me so far. What you are doing is...well, I would have called it trolling, but since I'm a troll, what do I know?

Sorry, I misquoted you from memory and didn't simply cut and paste your words since I'm not trying to open myself up to a lawsuit from someone who thinks behaving like a child is the way to get something. The term you used was "business friends" which I foolishly and generously assumed meant someone wanted to work with you. If you recall, that was the point where you were explaining why you were so mad about a product you don't even use.

 

Your work is appreciated as well as your passion, but people aren't paying you, and are paying Unity. That's the problem here. You might vanish tomorrow.

 

And so might anyone at Unity, like Sean R did. Unity did a reasonably smart thing and made the HLAPI open source so anyone who wants to or needs to, can work on it. (It really blows my mind that there have been fewer than 20 pull requests submitted on something that supposedly has such glaring faults. Please contribute, especially if you've already tracked down your problem!! https://bitbucket.org/Unity-Technologies/networking) I'm not sure that paying someone excuses any of this. What did it really accomplish except maybe to embarrass some people? I still see no evidence of a conspiracy to hide the status of UNET or reason why they would. I had all the information I needed and still do. IMO, the only reason they had to respond to this was because forum users were stating things that were essentially untrue based on their misunderstanding or simple frustration.

Now that I've actually worked on the HLAPI and a similar project (in my sig) a little bit, I understand how they might have trouble devoting resources to such a moving target. It sounds like there are legitimate problems with peer-2-peer and Lobby, two things I don't use. P2P may not represent enough paid dev licenses for them to care, if you want the cynical guess. The Lobby issues are easier to understand without that sort of negativity. It's very difficult to make a Lobby API that's general enough to be usable for all the various types of games people will want. Master Server Framework has the same issue. The difference there is that the user base now fixes their own issues and contributes new, useful modules.

I think people really misunderstand what the "High Level" in HLAPI means. That's code that's fairly specific to a use case. If your use case is different, you may have to work around, fix, or extend the API.

 

I think it's fair to say that Unity has been an approachable product for people who don't have much technical know-how and the networking product offered is falling below standard in how it's understood.

Fact is, networking is a non trivial subject and currently Photon basically obliterates Unet in functionality, performance, ease of use, all of them if comparing to the HLAPI which I don't really think exists in a usable form at present (where usable is defined as commercial production quality, like Photon).

You could say HLAPI misunderstood but you'd be wrong. Unity is targeted classically, at people who don't have much tech know-how. It's only with Unity 5 are we seeing things opening up, things being lower level.

Currently HLAPI is not good enough, not even close. It might be surprising to see that the moderators aren't fanboys but there you go, that's how I see it. I want to see a big effort behind making a new HLAPI and what is there is more of a placeholder at the moment - that you've done well with, but that's you. That's the minority.

The majority of Unity users are *not* very technical and it's not something that will change, so I think the HLAPI needs to get oriented because it speaks volumes when I see peers evaluate both and go with Photon practically every time...

My problem is I really, really want to use UNet but I'm not seeing bullet points or anything telling me I should pick it over Photon at present.

What is the real problem with HLAPI?

 

I'm unfamiliar with pull requests. Is that like you suggest a change to their code and submit it?

 

Yes sir. With Git and Mercurial, you can put your changes in a new branch and then submit that to the repository you forked from as a pull request. I believe the manual process is a bit different for GitHub vs Bitbucket vs whatever, but usually whatever tools you use with your local repo have some automation built in for that purpose. I really like SourceTree.

Oh, the other cool thing about pull requests is that they are public, so if you have a fix, even if Unity doesn't merge it, I can go grab it and build that lib myself. There are a few really interesting PRs out there already.

 

Is there one?

Your points are well taken but they feel like your opinion vs. mine in something that's somewhat subjective. Photon doesn't interest me because of the additional costs and the fact that I can't host my own servers (it's been a long time since I looked at it, but it seemed very focused on P2P.) For what it does, it is probably superior, definitely more mature. It just doesn't do what I need, whereas the HLAPI is, ironically, more low level, extendable, and has no additional costs unless you use Unity services, which I don't. I've tried to express that I think UNET is the best thing available, not perfect, but that is obviously "biased" by the fact that Photon doesn't work for me. I'm not discouraging anyone from using it if it works for them, which is the point of my caveat way above about replicating well-known use cases from example source code. In those cases, definitely use whatever gets your game out the door fastest with the most maintainability.

 

Is the UNET team actively implementing pull requests that people submit?

 

It would be hard to call it active no matter what since there have been so few PRs, so I don't know. The bitbucket page says they will mostly be looking for bug fixes. Without active community participation they probably haven't put much thought into it.
I went to a fair amount of trouble to document what I did and even submitted bug reports. So far one report at least has been looked at, reproduced and sent to the dev team, so hopefully they'll pick up my fix also. I will report back honestly on what my experience is with it.

 

Host Migration and NAT Punchthrough, two big requirements for producing a game, cannot be fixed with HLAPI.