Search Unity

  1. Unity 2019.4 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  3. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

API usability

Discussion in 'Data Oriented Technology Stack' started by Adam-Mechtley, Sep 4, 2018.

  1. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    1,995
  2. thebanjomatic

    thebanjomatic

    Joined:
    Nov 13, 2016
    Posts:
    31
  3. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    3,583
    Check out the SystemBase code: upload_2020-5-13_20-37-39.png
     
  4. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,452
    Any API that includes Interfaces like this:

    From line 45 of the Boids example here: https://github.com/Unity-Technologi...s/Assets/Advanced/Boids/Scripts/BoidSystem.cs

    Is not Keeping It Simple Stupid!

    What elements of the DOTS API have you found that are becoming way too complex/longwinded to be useful?

    Also the lack of warnings, feedback and good documentation (linked to by the warnings) when working with in built DOTS systems.

    Forum thread on the joys of trying to work with DOTS systems https://forum.unity.com/posts/5861107/
     
    Last edited: May 19, 2020
    Cynicat and galaskap like this.
  5. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,452
    What happens when the solution domain (DOTS) becomes more complex than the problem domain (GAMES)?

    Could we end up with a situation where games become simpler as developers spend more time and energy working though the complexity of game development with DOTS than they do on the games development?

    What if DOTS just opens the door to massive unit count games but shallower games e.g. Bullet Hell and Boids Wars style games?
     
  6. Micz84

    Micz84

    Joined:
    Jul 21, 2012
    Posts:
    290
    Why simpler? You can make a complex game in DOTS, it is harder because most of us are trained in OOP and it takes time to learn new things and get rid of old habits. Games like city builders, economics simulators can only benefit from DOTS, and I would not call games like Capitalism II a shallow game.
     
    florianhanke likes this.
  7. colin_young

    colin_young

    Joined:
    Jun 1, 2017
    Posts:
    122
    I disagree that DOTS makes things more complicated. I've adopted it not because I need the performance, but because I find it far, far easier to reason about my code with DOTS than with GameObjects. It does require a different mindset if you are used to the GameObject style. Personally, I've never liked it, possibly because I'm coming from a long history of business/website/database software background with a heavy dose of dependency injection, but I can see why it could be difficult to make the adjustment.

    Right now, a lot of the complexity comes from the rapid pace of change and lack of really good documentation (the documentation of the specifics is quite good, the bigger-picture is what I find lacking). I expect that will change as the dust settles.
     
    shmafoozius likes this.
  8. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    285
    Honestly, once we have better core editing workflows ECS and some API improvements it will be much simpler to work with ECS than the old paradigm ever was.

    Unity's default paradigm was originally: GameObjects for scene structure->MonoBehaviours for user data and logic->SendMessage for decoupling and exposing events. While this paradigm is very simple and powerful it also is hella expensive. Sendmessage is based on reflection and is extremely expensive for large codebases, gameobjects have tons of overhead, Monobehavior added quite a bit of extra memory/overhead to your own logic and data. So we'd have to use other approaches, tight coupling via GetComponent with interfaces to expose events, handling large datasets ourselves, ungodly multithreading, etc.. Games ended up having to take on lots of tech-debt to implement their systems efficiently.

    Enter ECS: Entities for structure -> Components for user data -> Systems for user logic -> and components/dynamicBuffers act as your events/decoupling as well. The kicker is, all these scale well performance wise. You can have thousands of systems that recognize different cases and respond, you can expose tons of events via components/dynamicBuffers, these also have a variety of advantages as decoupling tools in terms of the ability to filter/modify them in multiple stages (eg: having a fire resistance system that iterates over all your damage events and reduces it by your fire resistance). These allow huge amounts of code decoupling and allow lots and lots of gamerules to exist without stepping on eachother or making eachother more complex.

    HOWEVER: Unity's ECS still has a long way to go on their API, there are numerous problems with how their API works that make it more complex to work with, systembase was a big step in the right direction but it has several places where it makes code more complex than needed. They also haven't exposed enough via dynamicbuffers and such, especially in the physics packages(eg: trigger/collision events are still hellish to get and interpret).
     
    laurentlavigne and GliderGuy like this.
  9. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,452
    Isn't one of the issue of DOTS scheduling systems. Take your example fire resistance system, how would you ensure it runs before any damage is dealt and only run once per new fire damage entity with resistance?

    I believe the default pattern is to use an empty tag component that can then be consumed how would this work for flammable items that have a fire resistant coating e.g. players driving a vehicle on fire?

    Is this a bad example and should fire resistance be some additional data held by flammable entities?
     
  10. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    285
    There's an attribute for making your systems run before other systems: [UpdateBefore(typeof(SystemToUpdateBefore))] where you can define that something should run before a certain other system. The system only runs once in the frame so we know it won't get applied multiple times. You don't need any kind of tag component or something to make it handle that.

    For something like an actual "being on fire" effect, not just a damage type, you'd probably add a component that says that that entity is "On fire". A good trick for this would be having one component called Flammable which stores all the information about how that entity burns and another component called Burning (or some other better name) that stores the information about how the entity is currently on fire. eg: how hot the fire is, a reference to the particle effect entity, etc..
     
  11. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,860
    Can you give some examples of what's fine, what's too complicated and what it should be?
    That'll help check temperature, see if the river of molten gold has cool down enough to dip toes.
     
  12. KwahuNashoba

    KwahuNashoba

    Joined:
    Mar 30, 2015
    Posts:
    76
    I would say that you are gonna burn your self that even Freddy Krueger himself would envy your skin only by the looks of it :)
    I'm currently working on my game in spare time and came sort of late to the DOTS party so I needed to stay alone at the bar, drinking hard liquor, until I got drunk enough to join the party. Why I'm telling this is that there is a lot written and spoken material about the DOTS out in the wild, also with the lack of proper documentation, so it's very easy to find more then you need solutions for one single thing which can introduce lots of confusion until you grasp what's the current state of the things. This is due to the rapid development of whole DOTS ecosystem so the whole approaches of doing things get deprecated repeatedly.
     
    laurentlavigne likes this.
  13. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,860
    :D:D:D
     
  14. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    247
    GetBuffer on SystemBase would help a lot!
     
    GliderGuy and Cynicat like this.
  15. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    247
    Adding components of another entity with its values is a must-have. And it must be on EntityManager and EntityCommandBuffer. Something like

    Code (CSharp):
    1. EntityManager.CopyComponents(eSource, eTarget);
    2.  
    3. ecb.CopyComponents(eSource, eTarget);
    4.  
    5. cecb.CopyComponents(entityInQueryIndex, eSource, eTarget);
    This may be extremely helpful for networking and some prefabs manipulations where we need to make some existing entity matching a prefab.
     
    GliderGuy likes this.
unityunity