Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Design considerations for hybrid ECS as a precursor to pure ECS

Discussion in 'Entity Component System' started by one_one, Jan 4, 2019.

  1. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    After dipping my toes into the highly intriguing but still somewhat daunting waters of ECS I decided to go for the compromise of hybrid ECS. It's still a fairly early stage in the project (but it hopefully will have a long lifespan) - so I'd like to avoid blocking myself off to the possibility of using pure ECS + jobs + burst (without major rewrites) due to design/architecture decisions. I suppose my question boils down to:
    Are there some essential 'gotchas' or design considerations when creating a hybrid ECS that, at some point, should/could be ported to pure ECS?

    I understand that this could be partially impossible to answer because pure ECS is still shaping up and it's hard to predict which limitations will stay or go. However, compared to the fairly strict requirements to make the data layout job- and burstifiable along with pure ECS, there's a lot more freedom in hybrid ECS. This of course also means that there are a lot more ways to shoot myself in the foot regarding 'portability' to pure ECS, jobification and being burst compilable.
    I realize that this sounds a little lazy and egocentric - but as a generalist indie dev it's just too time-consuming to pick up all the scattered resources on ECS that are currently available. However, I feel like a lot of reading up and research is required before being able to make even just basic design decisions here. The way I understand it, hybrid ECS is meant as a way to skirt current limitations of ECS (mostly the still missing integrations with other built-in features, but also the fairly strict limitations due to supporting only blittable types [no strings, char or guid...].) It also appears to be a nice way to bridge pure ECS with existing classic gameplay code.
    In addition, though, it seems to be meant as a way to allow for a smoother transition to pure ECS - and this is where I feel ECS amateurs like me can mess up pretty badly. E.g.:
    • Basically any use of dictionaries and/or resizable collections in components seems to be problematic at least (due to memory layout in pure ECS)
    • Relying on non-blittable data types (e. g. we have a ScriptableObject-based database for static data that uses GUIDs as keys)
    • And of course not-so-sneaky stuff like hierarchical/tree-like data structures that might still somehow end up in your code (and work in hybrid ECS mostly fine)
    There may be workarounds at times, but I have a feeling that in many cases such 'mistakes' require major rewrites to be able to take advantage of pure ECS, jobs and Burst. Am I overthinking this and should just 'shoot for it'? Is it expected that code should be, from the ground up, designed with jobs + Burst in mind, not just 'half-heartedly'? And if not, is it maybe still too early to give some general advice on how to 'pure-ECS-proof' a hybrid approach?
     
  2. thelebaron

    thelebaron

    Joined:
    Jun 2, 2013
    Posts:
    851
    I can only speak for myself but I'm just trying to keep my systems and logic as self contained as possible, and using pure ecs where it fits(for now its really just projectiles and ai detection, as this is mainly reliant on raycasts and math) and hybrid for the rest, but hopefully with each system being self contained it shouldn't be a big deal to upgrade them in the future. Theres no announced timeline for pure ecs equivalents, so I don't think you should lose sleep trying to architect it trying to predict what doesn't exist.
     
  3. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,555
    Note that the game does not have to be "just hybrid/pure ECS". You "use" hybrid ECS. (Unlike "my game is LWRP" / "my game is HDRP" / "My game is for landscape orientation" etc. all of those are mutually exclusive and you must switch from one another) Hybrid ECS is just a collections of add-on methods. You can use them along with pure ECS, which should be majority of the code. In my opinion Pure ECS should be called just "ECS", and then there are hybrid ECS extension methods for use with it.

    What I would call "Hybrid" for real is the game that do not create/instantiate Entities at all (with EntityManager call) but only use GameObjectEntity as the core, so each entity is tangible and you can click + see it in the hierarchy and you sync position with ECS. If you have some other entities working in background and then finally use that data for some GOE in the scene, your game is pretty much almost pure.

    My game for example is about 60% pure ECS, 20% hybrid ECS and 20% mono. Should I say my game is "Hybrid"? This is why I don't like the term "for pure/hybrid" because it hide the actual architecture... By the way if having just 1% of hybrid considers your game a hybrid approach, then the official pure ECS example is also hybrid since it uses a material from the scene, requiring hybrid component to get into the ECS system. You could get things from Addressables Address System / Resource.Load to be 100% pure, but the point is there might be no performance difference of hybrid and pure game from just the wording.

    What I am saying is that you can use pure as much as possible and use hybrid when you feel the friction of implementing something in pure. This would 99% make your game labeled as "hybrid" but you should not care, because you may have pure ECS as majority of the code and that what's matter. If you already have a large part in pure, migration would not be so costly especially you use something like chunk iteration which had been stated that the API is solidified and not likely to go away.
     
    Last edited: Jan 5, 2019
  4. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    Great point @5argon - it's not so much about pure vs hybrid ECS, but rather how much each pure ECS, hybrid ECS and classic a project is made up from.

    The suggestion of going with pure by default and only going for hybrid when it's too much of a hassle is great. I have a feeling that my 'distribution' would be more heavily leaning towards hybrid, maybe if only because I'm not well versed enough in 'pure' API to engineer some clever workarounds. So my concern was/still is that I might be building these hybrid parts in a way that makes porting to 'pure' later on a major PITA - which would sort of defeat the point of me picking up ECS at this stage. I suppose there's only one way to find out, though.
     
  5. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    If you not confident wit ECS start with jobs. This will allow you structure and learn principles of Data Oriented Design. Which later in future, should help move into EC if needed.
     
  6. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    To be honest, this is more about architecture (mostly data layout and modularity) than performance gains for me at this point. Sure, for performance critical code I will figure out some way to make it work with jobs and burst, but for large sections of the game, game logic is very unlikely to become a bottleneck.
     
  7. Singtaa

    Singtaa

    Joined:
    Dec 14, 2010
    Posts:
    492
    Yup, that's how I see it as well. Another thing to consider is (editor) tooling in ECS (right now there's none). Some form of editor tooling is coming this year, but I think, for the foreseeable future, if you want to keep the project designer- and artist-friendly, you will have a lot of non-ECS-related tooling code in there.

    Architecture-wise, ECS is really good for networked games. But to get to "performance by default", I think Unity will need to nail down the right API and proper tooling in order to fill in the gaps.