Entity Component Architecture

[Chris Wright via Digitalmars-d]

On Fri, 26 Aug 2016 19:30:43 +0000, vladdeSV wrote:

> On Wednesday, 24 August 2016 at 22:26:00 UTC, Chris Wright wrote:
>> It's like thirty lines of code and does almost nothing that I need.
> I've never done anything similar to this. I do not know what others
> might need.
> 
>> Why no `getOrAdd`?
> Entity has getComponent and addComponent which do different things.

Null safety is awesome.

>> Why no ID?
> I simply found no use of them in the small test I did.

The absence makes serialization a lot harder.

>> Why is there nothing to help me find all components of a given type?
> An Entity must only have one (1) of a component type. I have not found a
> use of having two of the same components.

I want to broadcast a message to all players. Your library doesn't help 
me do that.

>> Where's the reference back from Component to Entity?
> In my implementation, via the `void update(Entity e)` method. Update is
> the only part of a component which interacts with the Entity.

I've found it useful quite often. My procedural generation code tends to 
store references to rooms and such directly so as not to incur a lookup 
cost as often. (The cost being having to write the code more than 
computation time.) Then sometimes I need to look at other components, 
which means I need the attached Entity.

Also, for serialization, if Entity is an opaque ID, that makes it easy to 
serialize references between entities.

>> How do I get all components on an entity that implement a given
>> interface?
> Never thought of this. That could come in handy, but I, personally, do
> not see any use of it.

The `update()` method on Component is you hard-coding that for one 
specific member function.

>> I really don't think the problem your library is addressing is both
>> complex enough and standardized enough to reasonably turn it into a
>> library.
> I think you see this as ECS, which it is not.

Which seems to be something you invented that's loosely inspired by ECS. 
Your version has less implementation complexity than ECS, though, which 
means it's less valuable as a library. For instance, in ECS, you tend to 
store components separate from entities (because an entity is just an 
ID), so an ECS library would provide efficient querying capabilities for 
components, both by ID and by type. This is probably simple but might 
have some quirks that would recommend using an existing implementation.