Discuss: Entity-Component-System framework

[JackSkylark]

I've made a quick gist detailing some interfaces for creating an entity component system. Let's use this as a starting point for determining if this approach is right for the game engine.

https://gist.github.com/JackSkylark/5284a969697fd24127cce35c68a082d1

[souldzin]

I read the wiki for this pattern and I really like it! It seems close to MVC and Decorator pattern but it is completely applicable to the game engine domain. It also seems pretty modular and flexible.

On the downside, it sounds like there are some performance hits, but maybe using rx and concurrency we can resolve those.

Here's something we'll have to decide on:

So systems operate on a subset of entities based on some selection criteria (namely what components are registered with the entity). How should a system specify what type of components it's looking for?

• entities.where(x -> x.components.any(c -> c instanceof HealthComponent))
• entities.where(x -> x.components.any(c -> c.type() == 'health'))

not really a huge fan of either one... I'm thinking we need some intermediate class, but not sure...

What do you think?

[JackSkylark]

Take a look at this gist. https://gist.github.com/JackSkylark/b36653712d33495643df79fb8ed02278

The idea would be that all systems would have a property like this. aspects: Aspect.all([TransformComponent, MeshComponent])

There would be a intermediary that would wrap all systems that get registered by the game manager in something like a EntityQueryer.

The game manager would have a lookup dictionary of <ComponentId, Array<EntityId>> that gets passed into the EntityQueryer. Then the entity queryer calls the systems update method with the entities that it can modify & the game loops delta time.