Entity Component Architecture

[ilariel via Digitalmars-d]

On Wednesday, 24 August 2016 at 17:57:33 UTC, vladdeSV wrote:
> Hi,
>
> I have created a project, which is an Entity Component System 
> (ECS)-like structural setup for projects. It is to be used as 
> building blocks for (most likely) games.
>
> I call it 'Entity Component Architecture' (ECA).
>
> The difference from ECS to ECA is fundamentally different. ECS 
> consists of three parts: the Entity, Component and it's System. 
> ECS uses systems to handle the entity's logic based upon the 
> data in the entity's components.
>
> ECA however, only has two pieces, namely Entity and Component. 
> In ECA, the logic of the entity is calculated in the components 
> themselves, which also usually contains data.
>
> For me personally, this approach felt more reasonable to use. 
> The entities' logic is directly handled in the components, and 
> not in systems (which might be scattered around in code (Can 
> very well vary from dev to dev)).
>
> Now, the main reason why I write here is because: I wrote ECA 
> for a school project, and I am going to write about this type 
> of project structure. Since I do not have much experience with 
> ECS or bigger scale game development, what do you people think 
> of this new approach?
>
> I am searching for feedback. What do you think it's pros and 
> cons are? Preformance, memory usage, scaleability, etc?
>
> :)
>
> ---
>
> My ECA project can be found at https://github.com/vladdeSV/eca-d
> The README.md contains snippets of typical code usage, and the 
> docs contain examples (specifically 'source/package.d')

I'm sorry if this sounds rude. For a small scale project where 
you don't get performance problems there is nothing wrong this 
approach if it fits your purpose. Ask, profile, fix bottlenecks 
and optimize.

The approach itself is not new, but instead a failed one which 
ECS in general avoid due to inefficiency caused by virtual 
function calls and bad cache locality.

Your "ECA" approach itself is "flawed". It is merely another term 
for OOP in this case. You have entities which have components 
which are polymorphic objects implementing virtual functions. You 
are basically throwing away the good parts of ECS.

One of the strengths of ECS is that you compute in tight loops 
with as little indirection/branching based on existence of 
components. In your example usage you query for existence of a 
position component so that you can move an entity in your 
movement component if said component exists. In an ECS this would 
be solved by requiring Velocity/Movement-System to require entity 
to have a position and a velocity component after all something 
without a position cannot move.

I recommend you to read the pages at 
http://entity-systems-wiki.t-machine.org/ and also 10/10 for 
effort.