Please Add ECS to UE4

General Feedback & Requests
23

Oh I didn’t see all these latest comments in this topic ^^

Anyway, +1 for ECS; it’s a good thing IF used in the right place for the right reasons. i.e (not replacing Actor-Components).

I don’t think “re-writing” the whole engine would be necessary. Epic could build ECS from the ground up as a “pure” self-contained environment then build an additional “hybrid” system linking ECS to Actor-Component environment… Where and how to use it would be up to the game developer.

Major problems I see with this tho is that “ECS” cannot contain object and entities aren’t objects either. So that means no support for UFunction, no UProperty, no UStructs, no “code reflection” features, no Blueprint support, no nothing lol

24

No. It’\s Entity Component pattern, not Entity Component System pattern.

The System part of the ECS is the defining part. It’s the system that implements all the logic.

In UE4 Actors and Components implement logic and because of that it have nothing to do with ECS.

Either way, ECS in UE4 is not gonna happen. It’s to big paradigm shift for entire engine.

25

Now let’s sit here and wait for an Epic engine developer to show up in this thread with a “-hold my beer!” line, if ever :stuck_out_tongue:

26

I’m sure someone’s on it, right after figuring out how to enable wiki editing again.

27

I thought they were meant to get it right this time… sad

https://forum.unity.com/threads/huge-spikes-on-the-profiler-caused-by-endframetransformsystem.555301/

What they’re doing is very cool, but how to trust code you can’t see?

28

By not using it you can trust it to never be an issue for you.

29

And today I discovered that there’s a free open source system already mature and much better than Unity’s ECS :V

30

And it’s available in a bunch of different languages too, including C++.

31

Unity’s megacity running on mobile is pretty impressive: Megacity | Unity
would love UE4 to add this sort of feature out of the box as well…

32

Is it not possible to implement your own ECS system on top of Unreal and limit Unreal’s responsibilities to things like rendering and IO? Does anyone have experience using Unreal in this way? Would love to hear how that has gone.

33

for ecs there is too much refractor. but instead realy need pure component based entity system at gameplay level.
remove the inheritance, make the Actor just as a container of components, spit the code in to component, let the component do the work.

34

There is no way (== very hard) to do this for rendering, but it’s completely possible to implement the gameplay logic with ECS pattern. I’m doing this in my project and thinking to make a plugin for Marketplace… THough can’t promise anything at this stage :slight_smile:

35

Current state of the GameFramework module makes that a redundant effort.

In the end you’re just moving the problem somewhere else because all the objects inside a UWorld level are stored in Heap memory, doesn’t make any sense to develop ECS in heap memory :slight_smile:

The way to make it work correctly is creating Instanced Skeletal Mesh component (which doesn’t exist in engine) and then modify engine source to re-implement the whole GameFramework system in ECS pattern to run on stack memory, no UObject, no UStruct, no net replication (custom network model)…

Good luck with that ^^

It’s same reason why Unity are rebuilding their engine, moving things to stack memory and CPU caches.

36

Wait, why would heap memory be a problem?

37

Because the real deal is not about the way ECS is used, the thing is about packing the data together.
And dynamic memory allocations make super difficult for you to pack your objects together (cache efficiency), if you can’t avoid cache misses there’s no reason to ditch objects for the sake of ECS pattern.
It’s all about avoiding to leave CPU cache to read data (L1, L2, L3) having to search dynamic memory…

lol There’s a reason why Intel is sponsoring Unity’s ECS efforts haha :stuck_out_tongue:

38

Hey Bruno, Unity’s ECS does not work on stack memory. By definition, stack allocations are not supposed to live beyond execution stack. Unity’s ECS chunk data is allocated on the heap, except it’s not the C# managed heap. The whole think with Unity ECS is that they gave up trying to shoehorn “vanilla” C# into working for high performance gameplay code and wrote a system on top of unmanaged memory and value types as a nuclear option. You can get 80% of the way there in C++ by using struct-of-arrays where needed.

Data-oriented programming has been used in games since forever, but usually only for specific systems. Particle systems are the classic example. Writing high level gameplay code directly in a data-oriented paradigm, however, is not common at all and this is the problem with Unity ECS right now. Their forum is full of people banging their heads trying to reinvent the wheel in ECS, like inventory systems, state machines, triggers, etc.

In my experience, the “pure” ECS approach is a fool’s errand. It’s no different than trying to go “pure OOP” for a game-engine design and end up doing stupid things like a particle system where each particle is an instance of a class with a virtual Update() method. Different solutions for different problems. For example, Blizzard’s Overwatch is known to be built on top of their own ECS implementation, but high-level logic like character weapons and skills are actually done using something called StateScript which uses, guess what, separate heap-allocated objects with overrideable functionality. Because actual gameplay logic in 99% of the games cannot avoid having a ton of “if-this-then-that”, with a good dose of “if-this-then-wait-X-then-that-WaitSomeMore-than-that-too”, which is ridiculously hard to do in pure ECS.

39

Did you watch their Unite talks?
​​​​​It’s all about caching plain data structures.
It’s all about avoiding cache misses, very simple.

UObject classes just weren’t made for this.
Also you seem to forget what L3 cache does.

40

Yes, I did. But that doesn’t have anything to do with stack/heap memory. Those both are just memory, stack and heap are software concepts, the stack doesn’t have any sort of better caching or anything like that, it’s just memory set aside for function local variables. Yes, you can’t do this level of cache efficiency with UObjects(*), but you can with UStructs and arrays.

(*) You kinda can if you set up a custom memory allocator for a specific class.

41

Okay then!
Make an ECS using the “new” keyword and pointers.

See if that works for you to avoid random memory locations allocated to your objects and show us how you’re going to align together all the objects you have created, making one chunk be stacked right next to address of chunk CPU is using and the one to be used next… So then cache won’t miss and RAM won’t have to be read again when dereferencing the pointer to the object.

*Hint: Unreal does that already with an internal UObject pool.

  • Hint: We still need Actor Pooling Systems, why is that?!? Hmm…

After that let’s create one million entities then add and remove components in a loop, let’s benchmark that and see how many times a cache miss happens and how much slower it is because of each RAM access.

Good luck :smiley:

42

Just wanted to add a few pointers. Im sure you probably saw my ECS experiments with unreal engine http://victor.madtriangles.com/code%…cs-battle.html .

On the topic of ECS frameworks/libraries, the unity ECS is a unique type of model, in the way it works by storing entities with the same set of components into contiguous blocks. I implemented my own version of the same concept here. GitHub - vblanco20-1/decs: High performance Entity/Component/System library. . Its performance characteristics are absurd even in its prototype “barely works” stage. Its really not that hard to create a ECS framework, which is why you see so many of them, but all performant ECS dont guarantee pointer stability, so trying to allocate an uobject like that would be impossible.

The best ECS library you can find in internet is EnTT (GitHub - skypjack/entt: Gaming meets modern C++ - a fast and reliable entity component system (ECS) and much more), which uses a different model than unity ECS, but its very solid and nice to use. This is the one i have used in my experiments. It has different performance characteristics than unity ecs, but its really fast anyway.

Ive been doing a lot of different ECS experiments around, trying different ways to interface it with unreal engine. Ive actually shipped a game that used ECS (through entt) in a real project, a music game. It worked because i was loading the music charts from json files manually, and the Blueprints for the notes were display-only.

The issue with doing such things is the same as if you just ignore the game framework and code the game code in your own architecture. You completely lose access to blueprints, and you also lose access to assets and editor in general. Multiplayer is out of the question.

Even IF you do something like that, you will likely get bottlenecked by having to interface through the game framework to do things into unreal, unless you want to modify the engine itself. For one of the prototypes i had, i added hooks into the StaticMeshComponent so i could update the ComponentToWorld matrix and update the render proxy without going through the entire UpdateComponent flow.

One of the biggest roadblocks for such a thing is that to get UPROPERTY() support, you need to use UStructs or UObjects, but they have their limitations. UStructs cant be uproperty-d by pointer, and need to be stored by value in a component or actor, and uobjects have to be allocated through unreal engine internal systems, which means you cant use any custom memory management or pooling for them.

Im still doing different prototypes with different approach for this stuff, to see if there is a way that could work smoothly. The best i was able to make is to make ECS components have a UActorComponent wrapper, and use a special type of actor called a " ECS Template actor". The idea is that you would create a blueprint with this Actor, give it some of the wrapper components, and then you can apply a template actor into any scene-component to create a paired ECS entity with those components. Its a shame EditInline is as buggy as it is, as the template actor would work better as data asset or similar.

This is one of my most advanced prototypes:

In here, All of the objects are pure ECS, using the template-actor model i described. It has its own transformation/scenegraph system so it can interface well with parenting to/from unreal actors and back](ECS Tower defense prototype 1 - YouTube). The renderer is hybrid. Some of the objects are pure-ecs, and rendered with some global instanced mesh system, and some objects are just an actor that is getting transformed by the ecs logic.