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