Is HLAPI dead?

@aabramychev

When I look at the repository for HLAPI, there have not been any significant commit since 2015. Clearly the code has been abandoned.

There are many pull requests submitted to address several issues. Not a single f*** has been given.

Don't get me wrong I am happy that it is open source and at least people can pick up the slack on their own, but it is rather cumbersome having to replace HLAPI libraries in unity for every install.

Is unity working on a replacement for HLAPI? Have you guys considered hiring someone to work on it? Is there anything at all in the road map that would give us hope that the situation might improve?

 

And it's the best way. Every game need specific behaviour.

 

Unity is frequently promoting its goal to make game development easier for everyone. I think this is true for UNET as well (or should be, at least). So, there are enough arguments that a nice, stable HLAPI is a good thing to have. It just takes away the need for people to roll their own, saves time to spend on other things, makes it easier for non-experts, etc. And not every game is so specific that it needs to re-invent the wheel in terms of network solutions. Still, it does not prevent anyone from creating their own HLAPI if needed.

I think the community is able to do awesome things. However, as soon as we are talking about support, stability and compatibility with upcoming unity releases, there can be a difference between community assets and native, officially supported solutions, right?

So, this makes me wonder if it is the best decision to not offer a native, stable HLAPI solution that is officially supported. IMHO, it would be better to have both a native, generic HLAPI (open source) AND community derivatives. Or it would also be possible to have an official HLAPI which still is actively supported/driven by the community. I think the UNET HLAPI staff would just need to improve on collaboration and communication with the community and a good share of the work would be done by the community easily. For example, why not ask vis2k about a possible collaboration? There already is UNET HLAPI Pro. Why not choose an approach that is both community-driven and officially supported (native) at the same time? I think this might work pretty well.

Anyways, more information on the future plans would be appreciated. Especially as it regards the HLAPI, I don't remember much more information updates besides those 2 posts for example: #1 #2

 

@aabramychev @larus
I volunteer.

Why
Been working with HLAPI every day for the last 3 years while working on uMMORPG, uMOBA, VOXL etc.
Reported the highest rated UNET bug and fixed it myself in HLAPI Pro - as well as many other bugs like the closely related Editor restart IndexOutOfRangeException bug.
I know the source pretty well by now.
I am not going anywhere. I want to make my own MMORPG with UNET and I won't stop until it's done.

HLAPI Goals
After all these years I still believe that HLAPI's "server & client in one" architecture is genius, this is the coolest thing I have ever seen when it comes to multiplayer games because for the first time, indie developers actually have realistic chance to finish their projects.

My vision for HLAPI is to keep all the components and architecture to not break anyone's projects (unless absolutely necessary). We shouldn't make 'HLAPI 2' or any big changes - it should stay the way it is. We should fix all the bugs and then maybe (only maybe) make the internal code a lot more simple. 30k lines of code are a lot to handle, 15k or 10k lines of code would be a lot more valuable for everyone.

When it comes to features, I think the most important ones to add would be SyncVars and SyncLists that only sync to one client, similar to how the TargetRpc only sends the Rpc to one client. This is highly important for inventories, equipment, quest lists and so on - there is no reason why other players need to see them too, this costs so much bandwidth. NetworkTransform should be perfect too.

HLAPI should stay 100% free for everyone. If I can keep up that Patreon page then that would be enough. If not, I'd still do it because I desperately need this for my MMO.

Suggestions

• As suggested before, all the NetworkTransport classes and functions should be usable from within the Unity Editor - there should be no more internal classes. I am really hoping this will happen @aabramychev .
• Afterwards we should be able to just drop HLAPI into our projects. Perhaps over the Asset Store too - so it's as simple as possible for everyone.
• Don't take this personally, but I think it's best if the community decides which changes go into HLAPI. The Readstring Bug that I reported is still marked as "by design" - whoever made that decision should stay away from future HLAPI decisions imho.
  
• If there are new 'high level networking' components planned for the Multiplay acquisition then please let us know in advance. If HLAPI will be replaced anyway then there's no point in continuing to work on it.

If anyone else has an opinion on this, please reply..

 

Sure, the server and client model in one can be a good idea but here it's implemented in messy fashion, with other networking libraries doing a better job of it. It's not a new idea. I would vote that HLAPI just become open source and not part of Unity in any shape or form (perhaps a community driven package manager thing is the best it could hope to be).

Instead I would focus all engineering (which is probably what is happening) to LLAPI. So long as LLAPI is golden, it doesn't matter. So long as the death of HLAPI is officially announced, then people can start bringing out their own HLAPIs on asset store etc.

Currently, asset store devs won't invest big because they don't know Unity's next move.

 

@vis2k have done a great job with his HLAPI pro. My problems gone after installing his solutions. Look at these numbers, it is the most active thread on the Multiplayer Networking section. For sure HLAPI should be driven by community or maybe even worth it to hire him.

 

Yeah HLAPI's status should not be in limbo. Because it is, devs won't touch it and only enthusiasts will try. If it comes out of limbo and answers are given then time investments can be applied appropriately.

 

@aabramychev @larus

I think it is fine if it is community driven if we can keep HLAPI with our code.

Currently you have to replace the binaries inside unity, which makes it hard to make reproducible builds.

By far the best supported fork is vis2k's HLAPI pro. But it is being held back with backwards compatibility.

Can you explain how this will become a community project? In the future, how will I use a community fork in my project?

 

@aabramychev Let it be community driven, put @vis2k to on top of that, he is doing an awesome job even witthout an attachment.

After that please come clean with https://multiplay.com/2017/11/28/un...-hosting-division-multiplay-game-digital-plc/ this and future of HLAPI.

And make HLAPI Downloadable from Asset Store so everyone can apply their own solution and publish with their product.

Thanks a lot and please please do something about HLAPI.

 

You can do a HLAPI without replacing any dll.

The only things not accessible is this :

Code (CSharp):

1. #if UNITY_EDITOR
2.                         /* UnityEditor.NetworkDetailStats.IncrementStat(
3.                          UnityEditor.NetworkDetailStats.NetworkDirection.Incoming,
4.                          MsgType.LLAPIMsg, "msg", 1);*/
5. #endif

 

Last time I tried it there were some 'internal' NetworkTransport functions that weren't usable. Been a few months though. Which Unity version did you try that with?

 

2017.x . I'm working on it, and asked you about reusing your HLAPI_PRO code (not answered :'( :'( i'm sad :'( :'( )

https://github.com/Driiade/Unet_HLAPI_Ext/tree/master/Unet_HLAPI_Ext_Experimental .

 

As a patron to Vis2k HLAPI Pro https://www.patreon.com/HLAPI_PRO its been invaluable to my project and has absolutely become a must have!

-J

 

All I know is that when I inserted Vis's HLAPI-Pro code all the network layer errors I was having (and there were a few) went away. I fully support Vis and or the community in whatever way gettign the opportunity to continune to improve this. It is absolutely needed to make a robust transport layer.
Just my 2 cents.

 

this needs to be kept going it is an important part of many game projects.

 

So basically if I want networking then my choices are:

• Require external libraries
• Require paid 3rd party tools/assets
• Roll my own HLAPI / dig into LLAPI abyss.

None of those choices are particularly appealing and none of them are supported by Unity directly meaning zero support from a system Unity is pretty much expected to have built-in. These choices might be okay if you're just making a small game and expect to turn it around in a year and not really update it much after that but this is a problematic structure we're expected to adopt that creates a lot of problems for the Asset Store / Template ecosystem and the community in general.

If HLAPI is going to [basically] drop as a feature then that is really disappointing and IMO makes the work spent on UNet practically obsolete. There's almost zero incentive to support this move, like all this good backend work was done and then when it's time to make it good for users it was kind of just given up and ignored.

Bad networking was a stigma prior to UNet, and it looks like that isn't going to change unless the HLAPI gets actually finished and properly supported. I really don't see any reason to support UNet today. Other solutions are more reliable and better supported so UNet has to either step up and compete or live with the label of being completely useless. There isn't much middle ground to stand on here.

 

@aabramychev @larus

Replacing unity's dll's is more than just inconvenient. It makes it impossible to use hlapi pro in unity cloud build. You would get back at least this customer if this was possible.

The manager that has the power to address this is clearly asleep at the wheel. Please point them to this thread. Get the ball rolling.

 

I use Vis2k HLAPI Pro implementation and it has fixed numerous issues and should be looked at by Unity Tech.
Without HLAPI Pro my game wouldn't be as good as it is currently.

 

@aabramychev Vis2k's HLAPI Pro is the best I have seen. What ever Vis2k says, goes in my book.

 

I just want to be clear about how critical HLAPI(Pro) is to Unity. It is a foundational part of many multipler projects being worked on by many different groups. We need this as a community and if we can't have an integrated HLAPI it potentially means alot of people will have to question the commercial viability of their application.

Unity you need this. Let's get someone at the table and move it forward please.

 

When do you expect to have that final decision?

 

Not in a panic, but I am certainly concerned, as I have over a year's work into an HLAPI project currently.

As already mentioned, if we could drop the HLAPI source into our project, like really any other asset, instead of having to replace Unity DLL's, that would make it far easier to maintain. If you did that then you'd be able to see HLAPI versions posted to the asset store. I could imagine @vis2k posting HLAPI Pro for example, and able to charge a reasonable price to cover his continued work and improvements.

 

I am in the same boat. Would really like continued support for the HLAPI in some form, be it community or Unity. Vis2k's work is a step in the right direction, but replacing dll's in the engine is not feasible for some projects for a number of different reasons.

 

Exactly. I haven't tried HLAPI Pro specifically because of the DLL change, and not wanting it to cause issues with other projects I don't intend to move to HLAPI Pro. (not that there would be issues, but I don't even want to go down that rabbit hole)

 

Thank you for your answers @aabramychev.

Who would know? who can make that decision? What are they waiting for to make the decision?

 

There are also those of us who use the halfway house of NetworkServerSimple + NetworkClient classes for dedicated server projects. So far it's proving to be pretty good, especially if the few bugs that showed up in the networking benchmarks can be fixed.

 

I really don't know how we can agree on a HLAPI when everybody want different behaviour about it.

For me what is trully important :

-Not disabling gameObject with networkIdentity on it when server disconnect (not the case in HLAPI)
-Server can be build from different project and NetworkBehaviour can still work (not the case in HLAPI)
-NeworkBehaviour just send a byte (255 value) to be identified (not the case in HLAPI)
-Network change scene can handle async loading (not the case in HLAPI)
-Not to worry about client ready or not (not the case in HLAPI).
-Can play locally like connected (not the case in HLAPI)

Server or only hosted solution ? (NetworkTransport can handle both, not the case of HLAPI).

It's cool, but for the moment I don't agree with most of the choice made in HLAPI, and I don't think i'm alone.

 

Personally i like the simplicity of using UNET and cannot understand why the bugs identified by vis2k havent been eliminated. My side project currently uses pure UNET, but i dont have any issues to switch to HLAPI Pro, if this takes away unreliable behaviour. I also dont get why you want to turn HLAPI into a community project; i think its a great starter for network beginners, and the pros can roll their own optimized solution anyway.

 

No, we can't. There is currently no way to use HLAPI Pro or any other HLAPI fork in unity cloud build.
This statement would be true if we could add HLAPI as an asset in our project that you could download from the asset store. This is precisely what many of us are asking for, and it sounds like it would be fairly easy to do judging from vis2k's comments.

 

Hi, I'll have to ask you to stop harassing staff at this point. He's said twice he can't answer. Read how you're coming across. Likely they have to wait for a review and examine all the facts.

 

2018 and we continue with no out-of-the-box Multiplayer solution. What need Unity? people? money? feedback?

 

Unity needs time to discuss it among themselves, a lot of it is peer reviewed. If you are in a rush, Photon is ready.

 

I am not in rush but some people perhaps yes and this people spent too much time waiting for a Unity out-of-the-box solution this people love Unity like me and we want a real profesional multiplayer solution by Unity.

So if Unity need more time.... this cause:

1- Panic.
2- Abandonment of projects.
3- Paid for 3rd party tools/assets / re invent the wheel.
4- Uncertainty about - what use? Photon? But if i wait for Unity? lost time? etc.



P.D: I am currently developing a MMORPG with more of 40k lines of codes (is not too much but it's time spended) and if some day i finish the game i want to do this with a Unity a Multiplayer solution.

 

I'm in a similar boat as you, but I wouldn't panic just yet. Even in the worst case, Unity is not abandoning networking. UNET's LLAPI appears to be here to stay, and is fairly solid. Even if the HLAPI becomes a community project, I expect that may actually benefit it since it can't get any worse than the current next to no updates it has right now.

I'm working on an MMO like you, on top of the HLAPI (a lot of it is UNET Messages and NetworkServerSimple, but in the game world I'm using the higher level features) with a considerable amount of effort invested. I restarted the project from scratch a little over a year ago when I threw away most of my code that was closely coupled with the then abandoned uLink networking API, so I will be quite frustrated if I have to change API's yet again.

The HLAPI's use of Commands, RPC's, and SyncVars that mix your networking code with the rest of your code is really nice to work with, but will become a nightmare if I need to change to another API that doesn't have those features. So I am concerned about what happens here.

 

HLAPI is a right way for unity networking.
But Why does not Update??????????????????????????????????????????????????????????????
It is a good networking system.

 

I'm pretty worried about this.

I've switched from Forge to UNet because I needed a professional and well supported multiplayer library and Forge's new opensource community driven aproach wasn't as fast as my project needs (VR project). I was between Photon and UNet, and I decided to choose UNet because I thought Unity will always be behind it, and I don't know if photon will shutdown or change their systems in the future (they did something like that recently).

I lost months of work to acquire that stability porting to UNet. The doc were the worst part, it's even wrong in many cases, but now, I know how UNet works (beyond the lies of the documentation).

I don't want to port all the netcode to photon, but without official support (by my own experience) I don't see the future here and I would have to move again to another multiplayer solution(photon probably).

In my opinion what I expect as customer and UNet user:

• A professional team behind UNet to expand the basic and advanced features:
  • Host migration
  • NAT Punchthrough
  • Voice chat / voice service
• A documentation for UNet as accurate as the rest of the engine(I don't need it now, but I would save TONS of hours).
• 4 kilobytes limit and 30 msg/s limit on relay? I don't think everyone is developing mobile games with UNet. I understand we have to optimize but every game has its own needs.
• A dedicated server service/cloud whathever to mitigate the problems of relay servers or NAT Punchthrough.

There's a lot of professional netcode guys, hire them and solve this issues, I don't see the problem.

BTW, there are things I don't like from photon, for example, the dependency even if you want to host your own headless servers. But I'll take a decision soon because it's better to change today than tomorrow in my experience.

 

Photon is nice but for instance in my scenario, going with a client-server setup (self hosted) it would cost $175 monthly just to use the code.

I wish uLink wasn't dead, but since it is, Unet is one of the few integrated solutions and imo making it community driven will be very good

 

Seems so. And this is disaster for Unity and everyone who working with Unity.

Basically current situation with network solutions in Unity is super catastrophically bad.

People just no longer have a possibility to easily develop a multiplayer game. Earlier, when old Unity network (Raknet) was live, people was able to create a multiplayer game from scratch in 1 hour. It was ultra super easy to use with great tutorials and manual.

But what we have now?

1. UNET which brings a suffering for everyone who will try to use it.
2. Photon which is good not for for any case, mostly it is only for MOBA style games with match making and some similar simple games.
3. Forge Network with a lot of outdated documentation and questionable stability.
4. TNet with even worse documentation and strange restrictions.
5. DarkRift which does not inspire confidence at all.

So what we have?
Nothing, basically.

Earlier I said that "multiplayer for your game is not a complex task, with Unity it is super easy"
But this is no longer a true. Development of multiplayer games in Unity currently in very very very very very bad condition.

aabramychev
I hope you will bring this information deeper into the company, because any new features developed by Unity Technologies have no any sense while developers does not have access to good and reliable network solution. It is much more important that support of AR or new baked GI light.

You want a situation when Unity will be suitable only for single player games? Unlikely.

 

I'm curious as to why you feel this way? Are you referring to the LLAPI or the HLAPI? I've personally found working with the HLAPI relatively straight forward and functional. There are some minor annoyances but they can typically be worked around.

 

HLAPI

It have a lot of problems which was discussed countless times here on the forum.

In short:
1. Terrible documentation
2. Bugs with incorrect errors in the console which can be cleared and you will have no idea why your game is not working
3. Overall UNET forces you to develop the game using only very specific architecture (very weird, unnatural and inconvenient architecture) and you can't develop the game as you want. UNET just will not allow you. Mostly it is caused by auto disabled GameObjects before the server started and super weird error "Can't invoke a function without player authority" in many simple cases, so in order to fix it, you need to turn your nice and clean game architecture into a monster.

Probably later I will prepare a big post about what wrong with HLAPI.
Seems like people forgot what is truly good manual and comfort of development, like is was in old Unity network, which is now became a history.

 

Aside from bugs I wish HLAPI was more modular and did not depend on post compile to function.

 

LLAPI is supposed to be the part that works in all cases. HLAPI was just meant as an example on top of it - you should probably look into LLAPI if HLAPI doesn't fit your game's architecture. For example, that disabled GameObjects part would be really difficult to disable in HLAPI, probably not worth it.

 

Yes, I remember these thread where people discussed that HLAPI it is just an example of what can be built using LLAPI. However, as someone noticed, people prefer to develop a game, instead of develop a network engine. This is why people use Unity.
But I understand you, you are experienced network developer who working with Unet a lot, and LLAPI is simple to use for you. I just prefer something more high level.

 

To be completely honest, this architecture (server authority, client just sends inputs) is a complete must for any multiplayer game that doesn't want to end up in PUBG, GTA Online and you name it place. You are still going to have them, but they at least won't be invincible, teleporting around and such.

 

I'm sure unity are watching carefully what's happened when an engine-feature-level component became an unsupported (or community supported if you prefer) example of using low level functionality.

After all, the scriptable render pipelines are a similar concept...

 

any updates on this?

 

I have written an alternative to the HLAPI called the MLAPI. You might want to check it out. Porting things from HLAPI to MLAPI should be fairly straight forward. The project is activley maintainted, issues and PR's are looked into.

https://github.com/TwoTenPvP/MLAPI

I think the project will benefit many of you.