Inconsistent Entity Hierarchy

[nightm4re94]

Have a look at this excerpt of our entity hierarchy:

├Entity (implements IEntity)
|  ├CollisionEntity (implements ICollisionEntity)
|  |  ├...
|  |  ├CombatEntity (implements ICombatEntity)
|  |  |  ├Creature (implements IMobileEntity)
|  |  |  ├Prop
|  |  ├MobileEntity (implements IMobileEntity)
...

MobileEntity and Creature both implement IMobileEntity and as there is currently no use for MobileEntites that are not CombatEntities, we have some redundancy going on. Do we actually need the MobileEntity implementation? Sure, one might come up with scenarios where you want something to move but not take part in combat, but in that case there are ways to exclude CombatEntities from combat anyway.
I think we could ditch MobileEntities entirely for the sake of simplicity and not confusing developers too much.

[steffen-wilke]

That's just the downside of an inheritance-based Entity hierarchy compared to a component-based architecture. I think however our interfaces kind of define the "components" an entity can provide.

Ultimately this comes down to: potentially some runtime memory wasted vs. some duplicated code. I don't think either downside is really significant. But I would agree with the argument of trying to make the structure as simple as possible, i.e. ditching the MobileEntity implementation and just providing Prop and Creature is a much cleaner concept.