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 :)
