No announcement yet.

Feature suggestion: Complete Entity-Component-System for UE4

  • Filter
  • Time
  • Show
Clear All
new posts

    Feature suggestion: Complete Entity-Component-System for UE4

    Hi everyone,

    like my title already says, I'd love to have a fully implemented ECS in UE4.
    I know a lot of things are already (at least somewhat) done that way, however there are still things that aren't possible to handle in components (e.g. (and especially) input is handled/forwarded by the "PlayerController" framework-class and not available in components and networking is directly implemented in "Actor") and thus it seems somehow unfinished and you still have to do the split between using UE4's inheritance-based (framework) concept and component-based programming. Another thing is that the components are also kinda in a state where I'm not sure what I should think of them... Why do I need to have a static mesh component in order to be affected by physics (of course I could leave the mesh empty, but isn't that the point to use components: To not "hide" stuff you don't need by ignoring it, but rather by really not-having it). I know I am quite bitchy here, but a component based-workflow would have several benefits.
    One of them is obviously the gain in flexibility; simply sticking objects together via components at runtime or using Blueprints as prefabs, while still being able to add/remove components later on (or at runtime) is great. Plus the option to inherit Blueprints (yeah I know, inheritance here... but I wouldn't call inheriting a blueprint, with no actual behaviour in it, inheritance in a C++/Java/C#/etc. sense, but rather using a factory method from an entity whose factory method is already defined, and only extending it a bit) to create dynamic entity-hierachies instead of static class-hierachies.
    Another one would be transparency. It'd give (UE4) beginners (and also experienced designers, exploring new areas) a huge advantage. They don't have to dig their way through thousands of lines of C++ code to find the line they're interested in. They'd simply think: I'm interested in networking, let's look at the (maybe) "NetworkingComponent". Together with some interfaces this would also make it a lot easier for people to alter already existing components/behaviour.

    To be clear, I don't want to abolish inheritance from UE4, though I'm not really a fan of it anymore. However everyone should be able to use what fit's him best and since this is already perfectly implemented (and used by many professionals), I don't see any reason to remove it. However, a clean starting point for people who are more familiar with an ECS and would like to use it only (yes, without ever having to use one of UE4's derived classes) would be really, really awesome.
    I definitely don't want to start an engine war, but an ECS as Unity3D uses it would already be a good step in the right direction. For instance they have a "MeshComponent" for selecting a mesh, a "MeshRenderer" for rendering it, a "ColliderComponent" for collision and a "RigidbodyComponent" for physics, etc... . In UE4 if you have e.g. a "StaticMeshComponent" it already contains a transform and physics... I works but (as already mentioned above) it mixes up things that shouldn't be mixed up... Of course some components are dependent on each other, but an explicit mentioned dependency (Unity has a "RequiresComponent" attribute), working with Tags or a clever event system would leave a component's logic, that doesn't belong in another, in it's own realm.

    I'm really curious if Epic already considered to implement an clean ECS. If yes, in what manner. If not, maybe why.

    Thanks already for taking your time reading my suggestion and best regards,


    PS: Error spotting welcome . It's a quite complex theme so I might misspelled the one ore another word...
    I wan't an even more powerful/pure ECS than in Unity3D
    I want an ECS like Uniy3D's
    Some more possibilities in components would be cool
    I'm okay with components as they're now
    Inheritance always works for me so I'll never use components
    I don't care
    Last edited by benjamin.rickels; 03-16-2015, 05:27 PM.

    Hey Benjamin.Rickels,

    Thank you for your suggestion on how to improve UE4. I have submitted a feature request to our Developers. If for any reason you need to reference this entry, please reference: UE-11915. And as always, if you have any questions regarding the Editor, feel free to submit a question to our AnswerHub.

    Twitter @UnrealSamantha
    Mobile Development Troubleshooting Guide | Package and Deployment Troubleshooting | How do I report a bug?
    Call me to a thread by posting this: [MENTION]Samantha Sutton[/MENTION]


      Thank you very much for submitting my suggestion to the developer team !
      It's really cool to see that you really try to help everyone with their ideas, keep up the awesome community work !


        That is quite a big post and I wanted to try and break it down into a couple of different points!

        - Handling input in a component is something we are talking about, there are some sticky issues to figure out (e.g. order in which input is consumed)
        - I know other engines do it differently, but over the years we have found that having one 'static mesh component' that can handle physics sim, collision and rendering is more efficient and easier for gameplay code to deal with. Also because our components support an attachment hierarchy (like a scene graph), it's not clear what that would look like if we separated concerns. You can write 'movement components' though for custom movement logic, and we already have a few of them.
        - Each component can support its own replication (networking) of properties
        - The only component that currently cannot be added to any Actor is the CharacterMovementComponent, though we would like to continue to refactor that code to make that more possible.

        You _should_ be able to create functionality now just by putting components together, but sometimes the Actor-based class is the right place to write logic, so it can sit 'above' the components, with knowledge of all of them.
        Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
        Twitter: @EpicJamesG


          Hey JamesG,

          thank you very much for your feedback.
          • Great to hear that handlin input in components is alreay in discussion !
          • Yes, in terms of runtime efficency I have to totally agree with you. My concern was more about maintainability and overseeability, because I still think a single component for a narrow field of tasks is easier to understand than a component with two totally different purposes. I think this is also very dependent on which workflow someone has; and since you're also using the same engine you publish, I don't have any doubt that the decision to handle components as you do currently is bad, for if it was, you probably would have implemented them in a different way. However I thought giving people, used to another workflow, an equally easy way to implement it, would at least be worh a suggestion for the developers... I know, having two systems doing effectively the same thing is somewhat redundant, but since actually not much new logic would be involved if you decided to expand UE4's components, I don't think it would be too much of a problem for a developer team like Epic's.
          • Yes I noticed that as well, and since implementing networking is a kinda different subject than actually building gameplay-logic, I have to admint that this wasn't the best example someone, trying to explain some advantages of ECSs, could give. Especially for components themselves (having components managing behaviour of components would even be to complicated for me ). Still I think networking on an Actor is not as clean as it could be, but this is really complaining on a high level, and as mentioned in the sentence before, more or less a matter of opinion.
          • Cool to hear that generalizing some of UE4's former framework-unique components is already an internal aim

          So as far as I can tell, some of the things mentioned by me are already under internal disussion.. Big thumps up for that
          And again, please note that my suggestions are only in addition to already present features... Because this would make UE4 the ultimate choice for all kinds of developers, whether they like classical inheritance, "newer" (or at least popularity gaining) ECSs or a mixture of them.



            Dear all,

            Thank you very much for opening this discussion about the EnitySystem paradigm and UE4.

            Obviously the Entity-System is gaining popularity so I was interested in it and we can understand why this paradigm is quite interesting.

            In fact, when you replace inheritance by composition then you ll have more flexibility in dealing with dynamics of your game; you lose also consistancy and control during compilation and so you can do a lot of conceptual bugs...

            The most interesting concept I personnaly found in the EntitySystem pattern is the concept of "System". In fact the dynamics of the system is calculated globally knowing all the entities that have the required aspects (the required components) This global perspective is hardly found when you perform per entity update of you component. For instance, a collision system needs to know where are other entities.
            It is curious that the concept of "system" is not present in UE4 and only components have been identified.

            For comparaison, I realy like the LibGDX implementation of the entity system (named Ashley I think) They have a nice exemple showing how to build a basic game with 8 systems and some components the link is here:
            The component are realy bags of data with no inheritance and the logic is on the systems.
            So the added value is not on the components but in the systems ! I love the way they manage the pause/resume; just turn on/off systems and you're done and also the rendering system

            In UE4 the concept of System can be implemented using an Actor; However we need an easy way to find/query all entities (actors) that match a specification of an aspect (actors with a set of components/exclusion of components and so on) If this is possible then one can easily come with an interesting implementation of the EntitySystem pattern in UE4.



              To bump it up, there is an implementation of wrapper-version of ECS in UE4 based on EnTT framework (C++ ECS): Spaceships Boid Simulation, with a related forum thread.