For creators of HLAPI: Big list of things which MUST be done

Unity Engine
1

Let’s be clear. Currently UNET HLAPI is a mess.
Yes, I read that HLAPI it is just an “example of what can be achieved using LLAPI”
Yes, I read that you are thinking to make it open source.

But there is a problem.
First. In most cases, open source = abandoned and low quality. Forget about it.
Second, about LLAPI.
Let’s open your website
https://unity3d.com/unity/features/multiplayer

What we see?
“Unity Multiplayer is the simplest way to create multiplayer games for Unity. It’s fast to implement and highly customizable.”

So, your goal was to create the simple but flexible network solution for everyone, right?
Good goal.
But you have failed.

HLAPI is not easy and not flexible at all.
LLAPI maybe a flexible but it is super complex. Only a super experienced software engineer will be able to create a good network architecture which will be suitable for real projects.

It is not a definition of “simple” network solution.
Besides that. Working on LLAPI is a waste of time.

Why? Look:
What is Unity? Why people using Unity? Because Unity is a high-level solution. People no longer need to develop own game engines. People may create games, not a game engine. And it is great.
But even though Unity is high-level solution - it is super flexible. We can do anything using Unity!
That means that high-level != low flexibility.

Once good high-level solution will be done, it is no longer necessary to work on own solution using low level tools.

The same with network.

If LLAPI is required - it means that your goal with HLAPI has failed!
If HLAPI will be good enough, there will be 0 reasons to work with LLAPI.

For example, previous network system (Raknet) was great, it was high-level, super flexible and we can make almost anything with this tool. But you dropped it.
Raknet is much much much more flexible than HLAPI.

So currently people forced to develop own network system using LLAPI, which is super hard.
Every developer should reinvent the wheel over and over and over again. Everyone should develop the same wheel.
Only because you didn’t managed to make HLAPI right.

People will not be able to use LLAPI in correct way.
People will not develop HLAPI instead of you.

It is your goal to develop HLAPI and provide the best solution for your customer.

You want to use power of community? Great. We will send you ideas, suggestions, bug reports and also, we can work on manuals and tutorials.

But YOU must develop the HLAPI. Not a community.

You receiving a lot of money from customers (since Unity on subscription plan) and it is your job to develop such super complex and important thing like network solution.

=============================================================================

So, actually a list of things which must be done:

1.
GameObject with NetworkIdentity disabled while no connection established. Fix it. There is no any reason for that. Who came up to this idea? No other network solutions are not requires that.

2.
NetworkIdentity component have bad performance. Explanation:
Create 5000 of cubes with NetworkIdentity component attached. Open a profile. You will see 1-2 ms of updates due all of these NetworkIdentity, even if they do nothing.
This completely ruins a possibility to create a complex sandbox games with a lot of dynamic objects.
In previous network system, NetworkView component didn’t had such problem.

3.
Add an option to disable “auto remove game objects when owner is disconnected”.
Maybe it is possible somehow, for example:

But super complex and looks like a kludge.
For example in TNet it can be done using just a single bool argument in instantiation call.
Take a look:

4.
Do not block a possibility to send RPC from objects without authority! Like it was possible in previous network system.
Yes, I read you think that such code is “cleaner”, “more secured” and “easier to debug”. Completely disagree.
Even if you want to teach developers how to develop an architecture - write an article about it! Do not force us to develop thing using only your way! Maybe someone want to use another approach? It is our choice!

5.
Add a possibility to spawn object with additional parameters. Currently we have only NetworkServer.Spawn (), that’s all. If we want to set any additional variables we should use [SyncVar], which is garbage because (look item 2) and not designed for this task anyway. We need to update this variable only once! During instantiation, but SyncVar designed for variables which changes often.

Also we can create additional RPC functions in order to set additional parameters, but such functions is not buffered and also entire code became much more bulky (like spaghetti code, despite the fact that you are trying to assure us that UNET have “cleaner” code).
It should be done using the same approach like in old NetworkSystem using custom spawn function:

The code is super clean and easy to use, and also very flexible. It even managed to spawn a prefab with many NetworkView component inside using this approach by sending array of NetworkViewID which was allocated by several calling of .Allocate (). Super easy and super flexible! Return it back!

Also you can use another very elegant approach like it is done in TNet using special RCC functions. Take a look:

6.
Add a byte counter like it was in previous network system. It is easy. Just add it! When I was beginner, this information allowed me to learn a lot about efficiency of various approaches in network architectures.
3443763--272564--2018-03-29 15_35_55.png

7.
Add a possibility to manually allocate NetworkViewID and assign it to NetworkIdentity component like it was possible in previous network system. It is super important feature if we need to spawn complex prefabs with NetworkIdentity on child. Yes, I know that NetworkIdentity on child is a bad thing, but it is still possible! And sometimes it is necessary. Just add this functionality. It was available before and worked great.

8.
Add an analogue of RPCMode.Others from previous network system. Sometimes it is required. It was available earlier and was very handy. Return it back.

0.
Do not mark old Unity network as deprecated while UNET HLAPI is such a mess and not fixed! Raknet is much easier to use than UNET, but new customers of Unity even not aware about this “lost technology”.

There is a lot more flaws, for example very complex procedure of server initialization. But at least it could be acceptable.
However, a list above is completely unacceptable! All these features worked in previous network system. UNET is a pure degradation.

The only thing that I like in UNET: It is very easy to invoke RPC functions. That’s all. Everything else is pure disappointment.

Maybe I am rude in this post. But it is only because I am love Unity and for 3 years I saw like Unity dropped great network solution, replaced it with something unusable and you didn’t even realized a mistake.
As result, currently there is no good and reliable network solution for Unity!
This is something which should be fixed ASAP! You should spend most of your resources on this task!
But I don’t even see something about network in nearest roadmap : (

Hope you will read this, realize flaws and starts to develop HLAPI to the usable state.
If you will need any additional information about my suggestions and why it is necessary - I will be glad to help.

2

FYI, HLAPI is already open source and has been forever. Unity know’s that they have failed their original goal. There are many posts alike. HLAPI was abandoned before it became good enough for use. But I think there are good alternatives.
There are two forks that I know of of the HLAPI.
HLAPI Pro and HLAPI ext.
There are also other ones that aren’t forks like MLAPI (developed by me).

At this point we have to wait and see, Unity is aware of many of the issues. There are good alternatives like the ones mentioned above.

As for going on the LLAPI, I think that’s wrong. If the LLAPI gets developed like it currently is I like it. We have a company supporting it unlike other solutions like Lidgren etc. Also, Websockets is built into the LLAPI which is great for Unity games. We built our first title on the LLAPI. You don’t need an out of the box Hight level network solution, even tho in many cases optimal. Building on the transport can be fine, or even the HLAPI’s low level components.

But I don’t see the HLAPI (even if it was really good) replacing the LLAPI. They compliment each other. Sometimes you want nice abstraction and high level functioanlity and sometimes you don’t need it.

3

And decided to give up instead of develop HLAPI 2.0? What a shame.

Thanks. I tried HLAPI Pro but it mostly fixes small bugs, it does not change approach to development. Any items from my list is not fixed in HLAPI Pro.

I will check another two solutions. Thanks.

No, we need it. This is ideology of Unity. People want to develop a game. Not an engine. We need full scale high-level network solution out of box. We already had it 3 years ago. Old Unity network (AKA Raknet). The now solution should be at least as good as Raknet. Not the worse.

Maybe it is not too hard to develop very small and simple game using LLAPI, but arhictecture of such game will be very limited and it will be impossible to implement something bigger.

If you want to develop something big using LLAPI, you should basically re-develop HLAPI from scratch. All infrastructure, managers, core systems, RPC attributes, reflection etc etc. Super complex task even for experts who worked a lot with high level network solutions.

4

I guess you’re right. But the fact is that the developer of the HLAPI stopped working for Unity. Thus, the community versions such as the forks or alternatives like my MLAPI exist. MLAPI for example has MANY more features than the HLAPI, built in lag compensation etc. But also offers the SyncVars etc.

I personally don’t agree that you need something high level in all cases. But it is nice for many purposes.

5

Most of your list could be addressed if Unity would just assign a developer to support the HLAPI. I don’t know why they don’t want to do that. Overall I think the HLAPI is pretty good and ease of use is one of its best attributes. I agree with most of your suggestions.

  1. My suggestion in another thread was to just create a separate UnsafeCommand that could be called on objects you don’t have authority over, but otherwise work just like a Command. I’d think that would be a rather trivial addition and solve a good number of headaches of people just starting with the HLAPI.

I actually really like the HLAPI. I went with it on my big project I’m working on because I previously used uLink until I discovered they walked away from it but couldn’t be bothered to tell anyone. So I went with the HLAPI because I figured the built in solution had the lowest chance of getting dropped by the developers… oops. Really the HLAPI just has some fairly minor design issues, missing functionality, and some annoying bugs, but nothing I haven’t been able to work around.

My personal list of gripes just comes down to 2 issues though:

  • NetworkTransform is complete garbage (had to write my own, but shouldn’t have had to)

  • On instantiated/spawned gameobjects it is possible that Update() can be called on a NetworkBehaviour prior to Awake() and Start(). Meaning I can’t depend on any references set there to actually be there during the first Update() call. It took me several days to figure out where my somewhat rare and random nullreference errors were coming from. Now any reference I set in Awake or Start I check if null immediately before I try to use it in Update or any method called by Update. Super annoying.

1 Like
6

Yeah, same thought =\

I am also want to like HLAPI. But I can’t.
For me, items 2, 5 and 7 is crucial. Especially 2. I have thousand of objects in my sandbox game, but NetworkIdentity component eats a performance and there is no way to workaround it because NetworkIdentity it is a core component of HLAPI.

I am tried to write my own “high level network system” using LLAPI, but I only managed to recreate RPC using brute “SendMessage (“FuncName”)” approach. I need a deep understanding of approaches of optimizations which was used in HLAPI in order to create the same system.

What a shame that we need to recreate HLAPI using LLAPI only in order to fix 10% of problems of HLAPI, while the rest 90% of HLAPI have acceptable quality.

Even if someone from Unity team will create a detailed tutorial about “How to develop your own HLAPI suing LLAPI” it would be super helpful and enough to consider UNET as success.

7

You made my day bro :')

https://discussions.unity.com/t/685487 have most of features you need.

Actually no tutorial because I don’t have time but you have a test scene.

For the moment my “networkTransform” doesn’t have many issue, just a strange extrapolation behaviour, I will fix it. But it’s a very difficult task to make movement perfectly in sync.

I will check to add a “spawn with parameters” function for next updates (for the moment there is only the sync of gameobject in scene or create for new player, no spawn function).

SyncVar are already sync at the Start() of a NetworkingBehaviour, no strange behaviour like Awake/Start/Update in wrong order and syncVar not sync at Start.

You don’t have the “isReady” variable which was a lot confusing and the only purpose of it was just to solve scenes change problem. You have now a safe scene change whatever you do with your scenes.

Take a look, ask me for feature, show me error/bug and possible improvment :slight_smile:

It lack a lot of feature, but hey, I’m just starting =)

8

I mean, don’t wanna be funny. But the MLAPI CLEARLY has the better and more features :wink:

Serious note tho, both HLAPI ext and HLAPI pro seems like decent options if you really want the HLAPI back.

1 Like