On libGDX ashley ecs framework, we are required to split large object into Components. I want to see what is the edge of SpriteComponent (Sprite is still a large object) to TextureComponent, SizeComponent, PositionComponent, OriginComponent, RotationComponent, ScaleComponent (or TransformComponent & SizeComponent).
TextureComponent - @field: TextureRegion region
SizeComponent - @field: float width, float height
TransformComponent - @field: Vector2 position, Vector2 origin, Vector2 scale, float rotation
entity.add(texture);
entity.add(size);
entity.add(transform);
V.S
SpriteComponent - @field: Sprite sprite
entity.add(sprite);
or the combination of both
entity.add(texture);
entity.add(size);
entity.add(transform);
entity.add(sprite);
SpriteSystem - overrides the size and transform components
RenderingSystem - uses the texture, size, transform components to draw object
Question do you required to use SpriteComponent if the Texture ,Transform & Size Component is already added as Entity Components?
I'm not sure on my SpriteSystem if that is the proper behavior.
The way I see it, the goal of an entity component system such as Ashley is to have systems handle all the components of the entities of your game. Suppose you split your SpriteComponent into TextureComponent, SizeComponent and TransformComponent, will you implement a TextureSystem or a SizeSystem? Those systems will iterate over all entities, and if they have the specific component, perform some logic, each frame. Maybe your specific game will change the size or the texture of most of the entities on a frame by frame basis, but to me, it is unlikely, and your performance will suffer from this design. The examples shown in Ashley and other ECS give pretty good examples of what a component is likely to be: inputs, position, velocity, rendering... and for the moment maybe the good thing to do is to stick to it.