After reading a lot about entity-component based engines, I feel like there is no real definition for this kind of engine. Reading this question, and the linked articles, made me think a lot. I do not feel that comfortable using the system concept, so I'll write something else that is inspired by this pattern. I'd like to know if it is a good way to organize game code, and what improvements can be made.
Regarding a more strict implementation of the entity-component based engine, is my solution viable? Do I risk getting stuck, at any point, due to the lack of flexibility of this implementation, or anything else?
My engine, as for entity-component patterns, has entities and components, but no systems, since the game logic is handled by components. I also think the main difference is the fact that my engine will use inheritance and object-orientated programming concepts, in general. I don't try to minimize them.
- Entity: an entity is an abstract class. It holds a position, width, height, scale and a list of linked components. Every frame, the entity will be updated (i.e. all the components linked to this entity will be updated), and rendered, if a render component is specified.
- Component: like for entity, a component is an abstract class that must be extended to create new components. The behavior of an entity is created through the components collection. Components are updated when the owning entity is updated, or for only one specific component (render component), rendered.