I am new to game development. Coming across the ECS (entity-component system) pattern I generally quite liked the idea. I have implemented the current version of my engine using the OOP style approach. In other words, Components are objects that have both state and behaviour and methods that can be polymorphic. My entity manager also means that when a SpriteRenderComponent
has been added to an entity, entity.GetComponent<RenderComponent>()
will return a reference to the SpriteRenderComponent. Of course, the problem with this is that components have to communicate with each other. E.g. the draw method will access the TransformComponent
's transform data.
Now I have dug a bit deeper and found that most sources recommend the pure ECS approach where the entities are an id or a list of components, components are just structs with public data and the systems are where all the magic happens ie where all the functions are. Of course, components don't depend on each other and the same is ideally true for systems as well.
So now when I want to draw a sprite I create a SpriteRenderSystem
which knows how to draw a sprite. The problem is that drawing concerns all kinds of drawable things e.g. to sort them depending on a zOrder and layer. This is what lead me to the idea of nodes as objects that are local to the system. So now the SpriteRenderSystem
would add a 'SpriteRenderNode' to the RenderManager
. The SpriteRenderNode
could inherit from an abstract RenderNode
and implement the virtual draw method. The SpriteComponent
would only hold the data specific to the sprite such as colour. The vertex array and all the other stuff that is purely related to rendering is kept encapsulated in the derived RenderNodes
.
Problem #1
In order to be drawn by the RenderManager
, the SpriteRenderNode
would need to know and therefore store its transform data. The only way to keep this data up to date would be to copy the entity's transform component's transform data to the SpriteRenderNode
every frame. I am not so much concerned about performance here but about the practice of duplicating the data in the systems. It feels like this is a violation of general good programming practices though I can't see any immediate reasons why it may prove harmful.
Problem #2
Taking the data out of the components.
From what I understand, the data should live in the components. However, taking the above-presented idea a step further, there may be cases where storing data in components isn't necessary at all. Such an example may be an animation system which may simply store and update animation nodes for each entity and then change their components such as texture, position... The problem with this is that it would take away the ability to save the game by simply serialising all the components.
As you see I am quite confused about how a good pure ECS should look like. Any help would be much appreciated.