Armory: Entity component system

[luboslenco]

Investigate leveling up the current trait system to ECS.

[troyedwardsjr]

I would be interested in helping with this. Pure Entity Component Systems are great, and even Unity is planning on implementing one soon as an isolated part of their engine (https://www.youtube.com/watch?v=EWVU6cFdmr0). It seems to be the current trend as many in the industry are waking up to the massive benefits of this architecture in games.

If anyone is not aware of them, or need to be convinced this is worthwhile, some of the benefits are:

• Composition over Inheritance (Massive flexibility without having to predict the future).
• Decoupling data from logic.
• Massive performance gains in non-naive implementations.
• Contiguous memory usage, CPU "streaming" or look-ahead optimizations, fewer cache misses.
• Easier to parallelize both component systems and per-entity updates.
• Hardware architecture optimizations, ie data is compressed in memory, is decompressed to specific core's local memory for processing, then recompressed and written back to "slow" memory.
• Easier/faster to (de)serialize data, ideally, you can write the entire data directly into a contiguous block of memory.
• Decoupled, serializable data is great for networking and world synchronization in games (http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/).
• Database/tool export may be easier (ie header of structs or class stubs is easier to generate than modifying class headers with additional logic in them).
• No function call overhead in component system's update loop.

Proper, performant, pure ECS is difficult to implement.

It would be nice to write Haxe CPP externs / WebAssembly bindings through Emscripten for JS (similar to haxebullet) to the library entt (https://github.com/skypjack/entt), which is currently the fastest open source ECS library available in C++ (https://github.com/skypjack/entt#performance), and has proven to be battle tested as it is used in the new C++ version of Minecraft, a multi-billion dollar game. However, due to its metaprogramming / template nature it would be very difficult to write bindings / externs for it as it stands.

I would recommend instead, we would use something like the Haxe library ECX,
as it has comparable performance to the C++ libraries, is already cross-platform and has great performance across all targets (https://eliasku.github.io/ecx2_versus.html) using Typed Arrays (https://github.com/eliasku/hotmem).

Let me know if you have any thoughts.

[HeadClot]

Hey - I too would like to echo my support for this feature. I wont be able to help out with programming but
I should be able to help out with testing and reporting bugs.

[William-Godwin]

And here is one of the coolest libraries for ECS! I use it myself ^ _ ^

https://github.com/skypjack/entt

[zicklag]

Just a warning about ECX I, just heard from the maintainer that:

currently I have no plans to support ecx/hotmem/hxmake libraries in my spare time, as these libraries are experimental/educational projects.

Just something to keep in mind, not that we might not want to use it still and maintain it with Armory if it is the best library out there.

[PDeveloper]

Hmmm, I could try finalizing where I left Eskimo. Benchmarks were good + using Haxe4 it would be even more viable with its heavy macro use for clean API, but fast performance.

[masterneme]

+1 for EnTT

[porky11]

I'm not a fan of many inbuilt systems.
It seems preferable, when it's possible to import your own ECS somehow. Not sure, if this is possible now.

[Filtiarn00]

If you do this It will give me no reason to stay with Unity. I love Unity's new Entity Component System over Monobehavours. It makes much more sense. I happy to be a tester and report bugs.

[andrewolaughlin]

@troyedwardsjr What do you think about this new development with EnTT? Does it change anything in regards to what you wrote months ago?

https://github.com/skypjack/entt/wiki/Push-EnTT-across-boundaries

[longpinkytoes]

i need ECS for my main game project :)

[skypjack]

@andrewolaughlin actually, I'm currently moving it forward to a model where you don't have anymore to _name_ your types.
It's on the branch experimental and I'm actively working on this part to make everything run across boundaries flawlessly. :+1:

[dpomier]

I think ecso could be a nice candidate too. It is still experimental at this point but presents some advantages, such as strong code-analyses capabilities and it is super simple to use. I will try to build an Armory project with it when I have time. It would theoretically be possible to also plug external implementations as "backend" to offer different runtime, this is something I would like to explore in the future :)