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

ECS Solution for Artists

Discussion in 'Entity Component System' started by protopop, Oct 12, 2018.

  1. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    I have a suggestion for using the scene tab with ECS.

    Let us add entities, and maybe components and systems, to the scene view.

    I mean, isn’t an entity really just a gameobject with all the extras like transforms removed?

    I already use gameobjects with data only c# attached. I always wished I could just delete the transform but keep the object visually in the scene view, because I’m an artist and work well with this kind of visual. It would allow for ecs but not break the established paradigm many artists prefer. And it would use the easy for OO designers method of dragging reference to other scripts.

    Instead of create new gameobject, it would be create new entity. And if you wanted to replicate the gameobject behaviour, you could just add a transform to it. Like a very a la carte gameobject creator.

    Optionally, Components and systems could also have a visual representation in the scene view. And if they are singletons they could be restricted to one instance per scene, for visualization purposes.
     
    laurentlavigne likes this.
  2. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    ECS on preview, all user friendly editor tools will be in future afaik.
     
    MadeFromPolygons and protopop like this.
  3. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    I think it’s good for artists to start chiming in now. Many articles and posts about ECS don’t make much mention of how it will affect visual designers. We’re being exposed to the discussion without feeling like a part of it. And if there is zero discussion about visual tools while ECS is being implemented, that kind of infers that ECS’s data oriented design paradigm is inherently not visual friendly.
     
  4. Ouch, the worst thing ever is the non-visual stuff going in the scene view.
    They don't belong there.

    If you remove the transform, where would you put them in 3D space?
    Dump to the origo? Then why bother? It's just visual pollution of the scene.

    Non-visual entities should have an editor for them, like SOs have, but they should not be part of the scene.
    Visual entities can be and should be in the scene and can be handled like the GOs.

    I seriously down-vote and/or dislike any tutorials which starts with 'create an empty game object, then zero it out then attach the BlablaManager script to it'. It's insanely wrong.

    Not to mention that Entities are nothing have in common with GameObjects. Entities are not containers, they don't contain components. They are just indexes in component lists.


    ---

    Aside from that, I don't think it would be a good idea to start to develop visual tools on the top of the ECS. It's not the time yet. The underlying API is still changing a lot, they would have to rewrite considerable portions of the UI/Systems every time they shift something in the API. It does not worth it. Patience my friends.
     
    Last edited by a moderator: Oct 12, 2018
  5. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    567
    Unity doesn't provide any other way to visualize the manager that has a logic which related to the runtime. Your only way is to inherit from MonoBehaviour, create an empty game object, and attach the component to it. Don't hate the player hate the game.
     
    MegamaDev and noio like this.
  6. There is no need to visualize a non-visual component. You have other ways to do that.
    For example ScriptableObject just made for the very problem.

    I don't hate the game if it's logically coherent.
     
    MadeFromPolygons, FROS7 and dadude123 like this.
  7. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    567
    This is not an excuse for a customer who bought a product and expects quick access to parameters of the component at the first touch. Especially if you are creating stuff for people (newcomers/designers/non-programmers), you have to provide visualization.

    If I want to quickly switch an IP address or port in a network manager, without digging into the code and recompiling it, the visualization makes sense. If I want to quickly replace prefab in a pooling manager, the visualization makes sense as well. It speeds up workflow in many cases. Instead of opening an IDE and start writing, I prefer quick access to the component where I can make a few clicks right in the editor.

    The functionality of the ScriptableObject is limited compared to the traditional way, unfortunately.
     
    protopop and futurlab_peterh like this.
  8. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I think the ECS pattern is an ideal fit for node-based scripting in future. I would say it's the best pattern actually. Only hope Unity will go in this direction.
     
    MadeFromPolygons and chiapet1021 like this.
  9. Well, I disagree. It's just super-lazy design in my opinion and I will continue to judge it. And I know, many otherwise great asset does this, unfortunately. I wish they didn't.

    I'm pretty sure they will. Will see how performant they can make it. I have my doubts.
     
  10. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Re: performance I would expect it to be identical to hand-rolled ECS, perhaps faster for most people as it would be easier to design out anti-patterns.

    Unlike trying to generate code from nodes, ECS is a node already. Your systems are the nodes. The mapping is 1:1
     
  11. Well if they choose to compile the node-woods into actual code and they can utilize all the pipeline they are building today, probably it will be a great feat.
    I have doubts because of the nature of the node-based systems: it's easy to make mistakes and entangle everything. But will see. I'm really and honestly curious if they can pull off a working and performant node-based system after all.

    And in theory, components are the data nodes, the entities are the pointers to the data nodes, the systems are the relationship (command-flow) between nodes. Roughly. Or something like that.
     
  12. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yeah you're right. From my experiments with ECS I noticed that I was generating a lot of small systems and I could apply these small systems to any kind of data I wanted, so long as the data was compatible. I just kept adding more and more systems, basically until I had a library. Felt a lot like how a node based scripting system could work - because at some point you'll have enough systems to do practically anything - like most graphs.
     
    Lurking-Ninja likes this.
  13. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    I've seen Unity team people make this argument also and it doesn't make sense to me. You need a high level way to reason about the relationship that is separate from implementation. And entities containing components is the best we have I would argue. Every other ECS system on the planet pretty much uses that paradigm to reason about at a higher level. Go to the wikipedia article on ECS or go read pretty much any information online about ECS generally, and they all have the concept of entities as containers. Every ECS system I've worked with over the last decade has that concept.

    Which isn't to say there is not a better way to describe the relationships. But if you don't like it provide a better alternative, don't just try to force low level implementation into high level reasoning.

    If you want ECS to be easily understandable by everyone working with game data, you need the equivalent of what you see in relational databases. Has one/has many/belongs to type relationships. That is the base that you design UI's around and how you talk about ECS to non developers. It's necessary even if all cases don't fit perfectly.

    Like it's very common almost everywhere to take relational data and flatten it for performance reasons. But we still reason about the data in relational terms because flattening is purely a lower level implementation for performance. To me how Unity ECS stores data is a similar paradigm. I think of entities having components, even though I know implementation structures it a bit differently. Because at a high level it's just easier to reason about and I can explain it to laymen in simple terms.
     
  14. Yes, we will need to find another term for the 'thing which looks like a game object in the ECS world'. But it should not be 'Entity', because it's easy to mix up after a short period of time. You always have to describe if you're talking about the thing in the editor or the thing in the code. Those are separate things so let's name it differently. But I will to leave it to Unity as you can see above, I am also guilty in this.
     
  15. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    I thought of that. In my scene i have a gameobject (essentially a folder) that i use to group gameobjects with just data on them. It's convenient from a visual design perspective because i can easily see what i have going on in the same tab as the actual game objects. And i can easily drag references to them to other scripts.

    But what i dont need is the transforms and the rest of the gameobject cruft in those situations.

    I think the new component is similar, correct? its just data? So they could just be some kind of Null object that can hold the script. No transform, no need to place it, so it wouldnt actually be in the scene. But you would have instant access to it using the same, familiar scene object paradigm.And im not crazy about the new scene view icons, but they could be used here to denote when a sceneobject (we could call them scene objects now) are components, systems or entities.

    We COULD have a separate tab that holds these things too, but for me its more intuitive to have everything in the same tab. Maybe a new tab that could hold all these types of scene objects together.

    Probably the best is to just let people choose. If you want to use the scene tab as a visual collection for everything you can. Or you could leave your components in the project directory for people who dont need to visualize classes so much.
     
    Dr_SuiuS and Lurking-Ninja like this.
  16. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    Aren't GameObjects really just entities with some systems and components inherently attached? Thats what i gathered from what ive read.

    Like gameobjects, dont we attach components to entities?

    I think im talking about something closer to the hybrid model etc rather than the pure ECS stuff, because from what i see, pure ECS without a visual organizer would be very difficult, if not near impossible, for people whose minds do not think that way, who are more visually minded.

    I know that ECS is in the early stages. But i would just like artists to be able to make suggestions and talk about something that will eventually have to be addressed for us. I don;t think there is any harm in that. and I don;t expect unity to have a visual designer from the get go.
     
    futurlab_peterh likes this.
  17. Ok, I think I solved it. You aren't talking about the scene. You're talking about the hierarchy.
    I may be okay to put manager stuff in the hierarchy without polluting the scene. It's not ideal, but I can live with it if needed. (I really would prefer a separate section for those stuff)

    Okay, about Monobehaviour and ECS:
    Monobehavior:
    - we have game objects (contains monobehavior components)
    - we have components (contains data, business logic and other code)
    ECS:
    - component (contains data)
    - entity (pointer to a component in the collection of the same type of components -> this is like you have a lot of enemy with enemy component on it, strip out the enemy data from all the enemy GOs and put it in an array, it's like that, the entity will tell you which dataset you're pointing to)
    - systems (do the business logic and other data-transformations, essentially it's The Code)

    When they implement the editor features to handle ECS, they probably will name this new type of game objects (which will reference an entity, and a bunch of different kind of components), hopefully they won't call it Entity. :)
    But probably it will look like something like the GOs today.

    Question is, how you define 'entities'. If the ordinary meaning in life, yes, but then a lot of things are entities. Entity in ECS is a very well defined indexer in the component collections. I wouldn't use this terminology in any other way. And with the systems, it's the other way around. Systems get the collection of components which has the same indexer (entity). Which means Entity alone does not indicate anything other than a number.

    Bad enough that we use the same terminology for the components in the Monobehaviour way and in the ECS. Those are different components. ECS components only contain data. Monobehaviour components contain data and usually the code which process that data and even more logic.

    I understand the urge to do it, but believe me, it would be very bad to start to build anything on the top of the ECS. When they start to build the visual stuff, extending the editor and other systems, sure. But that won't happen any time soon, because the low level code is still changing.
    (I wish I was wrong, please, Unity prove me wrong! :) )
     
    Last edited by a moderator: Oct 12, 2018
    protopop and hippocoder like this.
  18. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    You're not wrong - this thread is around 2 years too soon IMO :)
    (or a year to get more friendly but...)
     
    Lurking-Ninja likes this.
  19. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Absolutely thats the plan and work is under way. Just to be clear, right now it's a code only API with a little bit of support via GameObjectEntity & ComponentDataWrapper. But clearly thats not an acceptable solution.

    It's just that all of that code we have to write it and this takes time, we are building ECS step by step and completely openly, so we released it with obvious things like artist tooling missing. That doesn't mean we forgot about or don't care, it just means we haven't gotten to it in what we released as a preview.
     
  20. slim_trunks

    slim_trunks

    Joined:
    Dec 31, 2017
    Posts:
    41
    This is a really interesting thought. The less distracted the code is (by OOP patterns) the more it is suitable for a graph based system. I tried other visual scripting solutions and was never convinced by them but Shader Graph recently taught me to never underestimate the power of such systems.

    If ECS can make node based scripting editors practical than I'm all for Unity trying to integrate one. Maybe this would boost productivity in the initial stages of development like we haven't seen it yet.

    Also this reminds me of much of this post:
    http://bitsquid.blogspot.com/2010/09/visual-scripting-data-oriented-way.html?m=1
     
    Lurking-Ninja likes this.
  21. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    Yes, and I should be clearer there.

    I’m talking about the hierarchy tab, not the scene view.

    So we could manage these new ECS items in the hierarchy.

    It would make it easy to use things like ECS components even now . I could create a new HeirachyObject or SceneObject or whatever we want to call it that represents a data component, and then it would be visualized and easier for me to use.

    I think ECS is tryouts my to achieve something good, even in OO thinking the trend is to atomize everything into smallest components and then remix it into something new, like DNA does. I think there ar many ways to acrualize ECS and some are code based and some could even look identical to how we work with the hierarchy tab today, which would make it easy to use its concepts. As long as we don’t force ecs thinking on people (because it’s not an ideal process for every situation and some minds do not work that way) and wrap it up in a variety of options (visual, pure code, whatever works best for you) then we won’t lose beginners and artists to something that does not look yet very user friendly or inclusive to people who are not pro coders, or think in a data oriented way.
     
  22. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    There’s no rush, and I just want to mention, since it was mentioned above, I mean the Heirachy tab, not the actual scene view. So we could add visualization of the ecs parts in the heirachy tab, but I think this is what you mean too,right?

    I disagree with people who say this post is too soon. I don’t think it is ever too soon to talk about important issues that will affect many expletive eventually. It’s too soon to ask for artist tools now for something that is very much in development, but to be clear that is not what I am doing. I am simply opening a discussion about it, and I think it is timely because there has already been so much interesting and illuminating things said just in this thread after one day.

    I would like to see artists represented more in discussions about ECS, because we use Unity too and if the push is a move towards an ECS paradigm then it’s something we need to pay attention to and understand. Thanks in big part to the usability of Unity, I am lucky enough to make a living now as an indie game designer, so changes to Unity are not just of tangential interest to me, it has an effect on my ability to make my living off of it.
     
  23. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,557
    Thank you so much.

    So, an ECS COMPONENT -
    • that is always a script right?
    • It’s always a c# cs file?
    • it always only contains data?
    • It’s never anythIngelse but this?
    It’s important to know this because as you mention the naming can make things a bit confusing. I will call it a DataScript in my head for now:)

    So we could technically write an ecs component today in even earlier versions of Unity, by just making a c# script that only contains data (something I already do). It just won’t have access to the burst compiler and other things that make it more performance in he new ecs framework in new versions of unity.
     
  24. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    The goal we have is that in terms of how you use Unity as an artist, level designer (Creating game objects / adding components / placing prefabs / working with scenes) ECS doesn't really change everything.

    You simply get significantly faster systems so you can throw significantly more data at Unity without worrying about performance. Both in terms of runtime scale and editing scale.
    Prefabs, Scenes, selectable entities, inspectors, components etc map 1 to 1 from game object -> entity.

    There is definitely improvements we want to put on top, like hierarchical scenes etc. But you can think of those as feature additions on top of what we have now.

    That is also partially why we haven't focused so much on that yet, because the intention is to not change so much in that area. By not changing much I mean rewriting a large amount of the tooling but essentially keeping the same workflows. Different code, same UX.
     
  25. DominikD

    DominikD

    Joined:
    Jul 14, 2013
    Posts:
    2
    Here's my mental model of old vs. new.

    Unity used to have what I'd call "Entity/Component system". There were Entities which acted as containers for Components. Components were isolated pieces of data and associated logic. Problem with this approach comes mostly from the fact that logic typically deals with more than one type of data so it's hard to find the right place - correct Component - for the logic (e.g. position change is caused by something and this something is typically data in some other Component; do you put position update logic in Position Component that needs access to, say, Gravity Component, or do you put this code in Gravity that needs access to Positions?).

    The new way is what I'd call "Entity-Component-System system". This reflects the fact that you have three concepts to deal with. Entities are unique identifiers. They indicate absolutely nothing by themselves. Components are simply bags of data. They do nothing other than hold some values. Systems operate on Components using Entities (Entities are access-points to Components). Systems become responsible for a single operation. So "update position based on velocity" System would basically do "for each Entity that has both PositionComponent and VelocityComponent, do blah". How you achieve this depends on implementation (and implementation depends on your particular needs) but it's possible, pretty elegant and performs very well across all types of hardware.
     
    futurlab_peterh and protopop like this.