Entity Component Architecture

vladdeSV via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 26 05:40:20 PDT 2016


On Wednesday, 24 August 2016 at 21:09:36 UTC, ilariel wrote:
> I'm sorry if this sounds rude.
No problem.

> 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.
If we don't compare it to ECS, could there be any improvements to 
this structure?

> 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.
When I was designing I intended multiple features being able to 
happen , in the same update call, depending on what compnents 
exist. Ex. if poisoned compnent existe, movement will be slowed. 
I do not fully understand how ECS work, but does the entities 
require systems for all different component combinations?

> I recommend you to read the pages at 
> http://entity-systems-wiki.t-machine.org/ and also 10/10 for 
> effort.
Will do! Thank you for your reply :)


More information about the Digitalmars-d mailing list