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.
