Entity Component System in unreal

Development Programming & Scripting
1

I watched some tutorial videos epic made about component design architecture and it also linked to some great articles about different component design patterns as well as the Entity Component System structure.

If I understand correctly, it seems that ECS is very possible with blueprint and in a simple way - the confusion is just that some terminology is conflicting.

What we call a actor component in unreal wouldn’t need to be used. Instead, “components” would just be structs.

Systems can just be an actor class or some logic that lives on something like the game mode class.

Since systems could not easily find actors that implement a struct, that problem is simple enough to get around - just add an associated tag with each struct, or otherwise you might have an actor who uses a struct component report itself to the system upon being spawned.

I suppose this is not a 100% true ECS because something like an actor does have some inbuilt logic - it’s more than just an ID - but I think practically speaking, you might get the same benefits of modular, flexible code to use a system like this for certain situations.

It seems most appropriate for “classic games” where you are likely to make wild, imaginative changes to the game rules just for the sake of fun over the course of your development, so setting up a system that allows you to easily swap functionality between classes is going to benefit that.

But this system does seem like a lot more setup and requires more mental energy per decision that you make involving the system, because you have to filter everything through a lens of maximum flexibility, so in some cases - like a game where the rules are known before production and they won’t change - then I think there must be no benefit to using a framework like this.

Well, just wanted to share some thoughts after digging into this a bit. I see a lot of people tout ECS like the second coming of christ, but I haven’t found much talk about it beyond theoretics.

This was a helpful video and it also has some links to some great, practical examples:
Component Design Choices - Breaking Down the Components of Gameplay (epicgames.com)

3 Likes
2

Disclaimer: I have not programmed in ECS, but have looked it up to know what all the fuss is/was about.

ECS is used to make AI, physics, graphics etc. into their own components so when the respective aspects of the game are updating the data is optimized for the CPU cache.

If you are programming in blueprints, you are not optimizing for CPU cache. The decoupling of data and behaviour does not happen for the sake of decoupling data and behaviour, it happens for a reason - to maximize performance by organizing the data in a specific way.

While ECS is better for the CPU cache and thus gives better performance, most games don’t need it. The bottlenecks are elsewhere.

Even the traditional UE5 C++ does not do ECS-style programming. UE5 has an experimental MassEntity feature that is.

6 Likes
3

Gotcha.

In my case, my only concern is making project easier to manage - I won’t be getting anywhere near realm of low-level optimization concerns like that.

It seems like there may be some cases where a pseudo-ECS style structure could help me, but I am not entirely convinced that the time spent creating the system would pay-back versus a more direct, less abstract approach.

But I think I know enough now that I may be able answer that question through some testing.

4

ECS has become quite an overloaded term over the past few decades, just like most things in programming. Pure ECS is just a variant of data-oriented design, which is one of the oldest design strategies that has recectly come back into style. The focus and strength comes from how things are a laid out in memory, which keeps it strictly in the realm of programming. There really isn’t a high level design benefit to ECS; it’s actually much more difficult to reason about things unless you are an experienced programmer. So either the editor / engine will hide most of the details to the designer, or the designer will have to understand low-level systems concepts.

Regarding pure ECS, you cannot achieve anything close to this in Blueprint because you have no control over allocations and memory layout. Secondly, the underlying C++ in Unreal is a hybrid ECS that has few (if any) of the data-oriented approaches that the pure ECS approach takes. Thus any attempts to mirror the new wave ECS will just be designs that go against the idiomatic approaches in the engine and will generate a great deal more friction than if you were to embrace its current paradigms.

There is a general design principle required by ECS that is useful in Unreal’s hybrid ECS model: bind data to logic that operates only on that data. Or, put another way, keep components as small as possible with one clearly defined responsibility. But this isn’t a design principle unique to ECS, as you’ll find similar ideas in any programming paradigm. This strategy tends to generate more flexibility and cohesion to high level design, and it also can sometimes incidentally help performance due to making things inherently more cache friendly. It won’t be nearly as cache friendly as the true data-oriented approach, but it is usually helpful to minimize the amount of irrelevant data whenever you are bringing a component in to perform logic (e.g., instead of having health management in the Pawn class which is huge, move it to separate component that only manages and operates on health values). Always profile if you are making design decisions specifically for performance; assumptions are particularly dangerous here. Regardless, smaller components with tightly focused responsibilities will also increase design flexibility, as you can then substitute/swap them more easily without requiring drastic reworks. Beyond this general principle, I don’t see ECS being a particularly helpful design strategy for anyone not deeply interested in the low-level memory strategies it provides.

7 Likes
5

awesome thanks for the insights.

Yeah I came up with a way to integrate my pseudo-version of ECS into my project, but it leaves me unsure if the extra time to design so much abstraction is really going to be of benefit, seeing as my primary goals are just to reduce coupling and make code that has consistent design logic so that it’s easy for me to manage as a solo-developer.

It does seem like having some separation of data from logic and encapsulating behaviors into components is going to help my organization in general. And it also looks like much of the project could follow this pattern, thereby giving me the consistency, which should help reduce strain on my brain when swapping gears from one part of project to another.

6

This is an interesting topic.
I think some games absolutely would benefit from an ECS type system, while others might even mandate it.
As an example, a Total War game or other RTS type game where thousands of units are performing logic each frame. This absolutely requires tons of optimizations to perform efficiently. Or even a game where a huge number of projectiles are on screen at a time, or other data heavy games.
If you are making a game such as this, you probably won’t be using blueprints, at least for those intensive operations. In fact you probably don’t even want them to be C++ UObjects either so you can keep overhead even lower.