Search Unity

Current state of DOTS

Discussion in 'Entity Component System' started by Kandy_Man, Aug 30, 2019.

  1. Kandy_Man

    Kandy_Man

    Joined:
    Mar 8, 2014
    Posts:
    67
    Hi guys, been out the loop for quite a while, just wondering what the current state of DOTS is and how close it is to being production ready. I vaguely recall Burst came out of preview a while ago, just wondering about the rest of it.

    I think 2019.1 beta was the last time I had a chance to mess around in Unity and I liked how we got templates in the create menu now like we would with mono behaviour scripts for components and systems, was a big help in getting up and running.
     
  2. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    982
    Far from production ready but that doesn't stop people from using it in a game in production (that includes us).
     
    MNNoxMortem likes this.
  3. supron

    supron

    Joined:
    Aug 24, 2013
    Posts:
    67
    Some parts of DOTS are production-ready, some are not. The job system and burst are in good shape and stable (not perfectly stable but on Unity Engine core stability level). There are still issues with older processors and we had some troubles with mobile devices (compile-time errors). However, we use it in our production code for a few months and we are very happy with the results.

    ECS, on the other hand, is not ready yet (in my opinion). It's still hard to write and debug the code effectively. If you are aiming for AAA performance, you will have troubles with detecting bottlenecks. When codebase grows, you will find it hard to detect why one job is waiting for another (profiler can show you CPU underutilization but not what causes it). EntityCommandBuffer allocates garbage and cannot be used with burst. EntityQuery is not as performant as it should be. Unity.Collections don't implement useful containers and features (like NativeHashSet or parallel writers with memory grow). If you want to implement the most performant solutions (IJobChunk), then you are forced to write a lot of boilerplate code. Lack of ECS components for very basic types (like animation or camera). Editing scene and connecting two worlds (MonoBehaviour and ECS) is another story.

    I know all of these issues will be resolved sooner or later. Every package update brings new features. Once you get used to ECS limits and principles, you will find that your code is easier to maintain and refactor. Performance is outstanding compared to MonoBehaviour (or plain C#). Unit testing is easy and straightforward. However, writing the same system in ECS requires way more effort than MonoBehavoir. In my opinion, prototyping in ECS is a bad idea. I still write a proof of concept in plain C# and then write ECS version.
     
  4. Singtaa

    Singtaa

    Joined:
    Dec 14, 2010
    Posts:
    492
    @supron is pretty spot on. That middle paragraph really hits home.

    Detecting performance issue and just debugging in general is harder in ECS. And I believe the best way to solve it is through really good visual tooling.

    The biggest thing I'm hoping out of Unite 2019 is burstable ECB.
     
  5. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    962
    Low level simulation with jobs is production ready I'd say. Everything above that, graphics and all that is still in preview.