Guidelines for determining what should be a component?

Question

Background:

So I'm developing my first 2d C++ fighting game (for learning purposes) and I have a setup where I have 'components' which are really just data holders with maybe some simple utility functions such as GetComp(), AddToComp(), etc. All components get passed to component systems which are just functions which act on certain components (e.g. MovementSystem(PositionComp pos, VelocityComp vel), etc.) which are split up into their respective domains (Graphics, Animation, Physics, etc.). All components are held by 'Fighter' class which acts as the component holder that keeps everything together.

Issue:

The problem I'm having is I'm not sure how I decide what exactly should be made into a component vs what shouldn't. For example, for my animations I have a system which essentially takes a 'spriteComponent' and a 'animationClip' obj like so SetAnimation(spriteComponent sprite, animationClip anim). As it stands, my animationClip class is not considered a component and is not currently attached within my Fighter class, though I guess I could implement it that way. How do I decide what classes/types should be made into components? How is this typically handled in other ECS like systems?

Answer 1

I have always somewhat preferred to think of a component as a container of values that influences a specific behavior in a data-driven way.

So when we talk about animation, we're designing a system that is meant to allow some external source to request that the system play and optionally blend various animations. That would mean that we need some component that allows those values to be driven

1. Flag that controls whether animations are enabled.
   This could optionally be influenced by whether or not the component exists; however, the same entity might be rendered for different purposes and being able to toggle this may be useful for cases where animations aren't important.
2. Default animation to be played.
3. List of available animations that can be played.
4. Define animation blending overrides.

From here its simply a matter of the system taking these values from the component and implementing the desired behavior.

When it comes to the next behavior, you follow the same process.

The one aspect I will mention is that i have found it useful in the past when systems deal with multiple components to manage some internal system data structure that relates the multiple components together somehow that is memory efficient for that system.

This may mean cloning values from the components to this internal data structure when some update event fires and then simply iterating that internal data structure on the system's update rather than trying to do multiple look-ups for all the various components.