Search Unity

C# Job System, ECS, ScriptBehaviours and UNET HLAPI: What's going to happen?

Discussion in 'UNet' started by PhilSA, Sep 8, 2017.

Thread Status:
Not open for further replies.
  1. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926


    I'm sure by now most people have seen this excellent talk about the future of scripting in Unity. It's looking really, really nice. "ScriptBehaviours" will be replacing Monobehaviours, and a new built-in ECS system will allow you to write highly-performant/highly-organized multithreaded data-oriented code. This is all fantastic news. However, I just thought about something: what's going to happen to the HLAPI with all this?

    Surely the HLAPI will not be compatible with any of this(?) It would require a completely different structure where Syncing & RPCs are the responsibility of ComponentSystems; not of the components themselves. Even if you forget about jobifying the HLAPI, it would still require immense changes due to the ECS. Will people who want networking in their game be confined to sticking to the old, outdated, and inefficient monobehaviours system? Will people have to do some Mono.Cecil magic themselves if they want to integrate their own RPCs and SyncVars with the ECS/ScriptBehaviours/Jobs/etc.... using the LLAPI? Is this why no one has been working on the HLAPI for over a year? Because you need to wait for ECS & ScriptBehaviour first?

    I just want to make something very clear: this isn't at all a complaint about the fact that you are introducing changes to the engine that will deprecate previous functionality. In fact, it's the complete opposite. These changes sound amazing and it's always good to move forward like this. I am merely just curious about where this will take networking in Unity. To me, this sounds like an ideal opportunity to just get rid of the HLAPI entirely and build a new, better, simpler, less bloated system. This sounds like a case where trying to convert the old HLAPI to this new system would actually take more time in the long run than starting from scratch (and wouldn't give as good of a result).

    _____

    PS: I would actually be completely willing to make my own HLAPI in the new ECS with the LLAPI + Cecil, but I won't be able to really start working until we get access to the ECS. Is there any chance we'll get an early version soon? Joachim seems to suggest it's pretty much ready for an experimental prototype release right now in his talk
     
    Last edited: Sep 8, 2017
  2. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    I bet there's hope - @vis2k
    Otherwise whole Unet will be deader than dead.
     
  3. mischa2k

    mischa2k

    Joined:
    Sep 4, 2015
    Posts:
    4,347
    LLAPI already has multithreading, that's worth a lot.
    As for HLAPI Pro - would have to see the new ScriptBehaviour+Jobs first.

    I am really looking forward to the Navigation path calculations running as jobs, that would be huge. For HLAPI though, not sure if there are that many calculations that can be outsourced as jobs.
     
    xVergilx likes this.
  4. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    While we're here, I'd like to ask something to everyone. Would you guys agree that the ideal HLAPI system would mostly just be:
    • Simple GameServer/GameClient classes whose sole purpose is establishing connections and having network callbacks
    • Some sort of system that has methods for networked entity/prefab spawning
    • A good workflow for syncvars and rpc
    Basically just the bare minimum for supporting sync and rpcs, because these are the only real pain points I've encountered while trying to implement my own system with the LLAPI. We can and should be handling all the rest (scene management, player management, net transforms/animators, etc...) ourselves depending on our specific projects. Worst case scenario is that the community will take care of making a package that handles all these things for beginners, which would actually be a great thing
     
    Last edited: Sep 8, 2017
  5. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    I do agree on most of it. Although, now I prefer using LLAPI instead. Messages are too flexable to be ignored. And Cmd's\Rpc's are often not that great of a solution.
     
  6. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    I think it depends on what kind of game you are making. I wouldn't use RPCs at all for a turn-based game like Hearthstone, but for more "realtime action" games where tons of things must be in sync continuously, it seems to me like it would be a pain to work without RPCs
     
  7. a-t-hellboy

    a-t-hellboy

    Joined:
    Dec 6, 2013
    Posts:
    180
    Hey guys,
    I read all the post in this topic.
    Now I want to know if you guys think which I can use HLAPI (UNet) and ECS (Also C# Job system and burst compiler) altogether ? If it's not possible what about LLAPI ? Is it possible ?
    It is off-topic but I want to know your opinion about using IOC like Zenject and UNet altogether ? (Of course with classic approach I mean MonoBehaviours)
     
  8. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    HLAPI is being deprecated, so I guess there won't be any support for ECS.
    LLAPI - not sure. Probably they'll add support for it, since a new solution developed for networking is probably will be based on LLAPI. Unless, rewritten completely.

    Zenject in most project is not even worth it. Depends on the project size.
    (Everything smaller than GTA5 scale goes towards not worth it)

    I'd rather stick to classic setup, or use Unity's ECS instead.
     
  9. a-t-hellboy

    a-t-hellboy

    Joined:
    Dec 6, 2013
    Posts:
    180
    Oh, I see. So do you know anything which with that can use ECS in multiplayer game ?

    Oh, why it's not worth ? So what is your suggestion for loose coupling ?
     
  10. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I locked this to discourage people posting against outdated information.
     
    Joe-Censored and xVergilx like this.
Thread Status:
Not open for further replies.