Good to knows about LLAPI?

Eyo!
So I've written my project using the HLAPI. But it's been decided to be ported to LLAPI (We were concidering using Lidgren aswell, but Unet was the final option).
I've spent about 8 hours so far porting the game. And it's actually a fairly flawless process. (I imagined it to be a pain). I am having the server and client in entierly different Unity projects now. (Before I had All in one and we used HLAPI).

Just curious, is there any tips you lads got that you wish you would have known when starting to use the LLAPI? Best practices etc?

Thank's, TwoTen

 

why/what are you porting it to the LLAPI? like what problems are trying to solve?

 

HLAPI is messy, obfuscating and sometimes misleading, and in most cases hard to maintain. And nearly impossible to debug. Not to mention "usefull" classes like NetworkManager. I'll bet it's some of these.

 

I know what many of you think, you dislike the HLAPI. However, this was not the reason. For us, the HLAPI was a fairly flawless experiance. Easy to maintain. Easy to write server code etc.

But the main reason was future proofing and control.

 

i guess i don't understand haha. so you're still using the LLAPI, but not the HLAPI?

the LLAPI is the weak point of unet, imo. no source code access is a deal breaker.

 

Uhhh, WHAT?

Unet is open source:
https://bitbucket.org/Unity-Technol...1dbc3d08eaadfc07c24dcf75866e7a1bfa/?at=2017.1

Also, there's plenty of decompilers. Rider has a built-in one.

P.s. I use both, and LLAPI gives much better control over what's going on. Plus being supported by the devs which are fixing it's bugs, where's HLAPI is long way forgotten in the Unity department.

 

Let me clarify. The project is using HLAPI, but we're moving it to LLAPI. And im looking for just general tips when using it

 

the open source bitbucket repo is the HLAPI. the LLAPI (NetworkTransport, etc) is closed source and baked into unity - you don't have a ton of control over your fate there. so i'll reiterate my point - the LLAPI (being closed source) is the weak point here.

am i fundamentally misunderstanding something?

 

HUH?
In your first post, you said LLAPI is better and the biggest reason is that HLAPI is closed source.
Now you're saying that the LLAPI is closed source and you don't have alot of control?

The only thing that is in that Bitbucket project is HLAPI as far as I understand it. According to their readme:

The Unity Networking extension DLL is the open source component of the Unity Multiplayer Networking system. In this DLL we have the whole networking system except the NetworkTransport related APIs and classes. This is all the high level classes and components which make up the user friendly system of creating multiplayer games. This document details how you can compile your own version of the Networking extension DLL and use that in your games and applications.

EDIT: Just realised I've missread your original post. My apologies. But why is it a weakpoint to not have sourcecode access to the LLAPI?

And AFAIK the HLAPI is just built ontop of the LLAPI.

 

hey i'm sorry to derail your thread here, but i think you guys are misunderstanding what i'm saying. i never said the LLAPI was better (i said twice that it was closed source in fact)! I never said the HLAPI was closed source either.

in any case, i'll restate it more clearly: unet is (at least) two parts - the LLAPI, and the HLAPI (there's more if you want to talk about the relay server, etc).

the HLAPI is open source on bitbucket (i personally like this part with all its warts. if anything janky is going on here,we can fix it ourselves). the LLAPI is baked into unity and is closed source. i'm not a big fan of the LLAPI because black boxes really suck to program against. even if the dev team is actively fixing bugs in their API, you're still kind of at the mercy of Unity Incorporated to fix your show-stopping bugs.

out of the box, the HLAPI relies on the LLAPI for establishing connections & transmitting data, but it's not too difficult to sever that tie and just have the HLAPI talking with whatever low level communication layer you choose (steam p2p, enet, whatever).

along those lines, what @TwoTen is talking about doesn't make any sense to me. Why would you throw out the open source stuff (HLAPI) and build your whole project around the blackbox LLAPI?

 

Thank you for clarifying. Your statement makes total sense to me now. I would also like to apoligize to you, I missread your original post. I thought you stated that the HLAPI is closed source.

What you're saying does make alot of sense. And the reason to why we made the decision is this:
* We want our Server and Client to be two separate Unity Projects. Not related in ANY way. On clients, inventory and stuff is represented with gameobjects etc. On server, it's just data structures.
* We wanted more control and we didn't want to be limited by the design choices that had been made by the Unity team regarding HLAPI (LLAPI doesn't really have any significant design choices. Just another network library tbh).
The main design choice that got us away from HLAPI is the fact that we had to have authority to send commands etc. That made us have to spawn in all the weapons during runtime as network objects and give the client authority over them. A mess (We could make a root script aswell that handled the commands), but also that would kindoff be a mess.

Anywans: My point of this post was to get some tips / I was I had known when i started type tips. Maybe good practices you guys found on Serialization etc.

Hope you understand where I'm coming from
Thanks, TwoTen

 

alright, thanks for clarifying!

from personal experience, i can say that working on two separate codebases kind of sucks (i.e. your server & client unity projects). it can be problematic to make sure each piece is working in sync. especially if you're working with another programmer and dividing the labor amongst each codebase. the more you can overlap, the better off you will be.

 

Why is that? And what do you mean with "it can be problematic to make sure each piece is working in sync". Can you elaborate on that?

 

Heh "sync" was a poor word choice for a networking forum.

I meant more in terms of development/logistics - you now have two programs that have to compile. If you add a feature, you now have to add it in two places instead of one, and you have to make sure it works in both places.

Also, you lose any compile-time bug catching. Like if you're in one codebase and you screw up an rpc parameter, your code just won't compile. In two codebases, this kind of thing is harder to catch because you'll probably only discover it through testing.

Also, two code bases to debug.

 

Also the part I said about dividing up the labor. It can just be a little tricky in my experience. If the two programmers aren't totally clear on the data being passed around, it can lead to lost time trying to figure out why things aren't working. & if one person's work is dependent on the other person's work, it becomes harder to schedule when people should work on features in their respective codebases.

It's just harder all around, is what I'm saying.

 

Well, we just have two Unity Projects open. And we implement a feature on the Server, and then replicate to Client. Works flawlessly for us. The main reason we did this was to keep the server lightweight to later have significantly lower costs on running the servers.
The Server project right now basically uses no UntiyEngine things. Just Vector3's n stuff. This is so, when the Server dll releases. We can easily convert this to a Console Application and have it super light.

 

Okay :v