Boreal Games

First point

 

I gravitate towards keeping components as pure data and having systems provide implicit, automatic logic.  Among other things, it makes inter-component dependencies much easier, as a system (and thus a task) requiring more than one component type will ignore entities that are inappropriate.

 

To use your example of a Movement component, you propose lumping position, velocity, and collision detecting together.  The problem with this is that it enforces rules that don't need to exist, such as "every entity with a position is movable" and "every movable entity is collidable".  You should split it up into three separate components with three separate domains of data:

• Position
• Velocity
• Collision (shape)

The systems that you should use are:

• Movement (adds velocity to position)
• Collision (checks between collision shapes at positions)

As you can see, entities don't need to be movable or collidable to exist spatially, simply give them a Position component.  This is useful for purely aesthetic static objects.  Entities also don't need to be collidable to move, and don't need to move to be collidable.  The latter is useful for static platforms and obstacles, while the former can be used for dynamic background props.

 

The key thing is that dependencies are automatically resolved if you have a system to detect when a system's desired component group is formed or unformed, registering and removing that entity from that system.

 

Second point

 

Components should all derive from a simple base class that holds the entity that component is part of.  I'd avoid any deeper inheritance than that.  You can use inheritance when designing your entities; for example, a robot chicken derives from a chicken class and adds a Robotic component (a bit contrived, but you get the idea).

 

Third point

 

The change in executable size will be negligible or even beneficial if you move entity definitions into data.  In terms of runtime performance, entity-component-systems are easy to parallelize because, generally, each system operates on each entity independently.

I've seen a lot of games with a minimalistic UI pause when the user puts down, say, 3 fingers at the same time instead of one.