Appropriate level of granularity for component-based architecture

Question

I'm working on a game with a component-based architecture. An Entity owns a set of Component instances, each of which has a set of Slot instances with which to store, send, and receive values. Factory functions such as Player produce entities with the required components and slot connections.

I'm trying to determine the best level of granularity for components. For example, right now Position, Velocity, and Acceleration are all separate components, connected in series. Velocity and Acceleration could easily be rewritten into a uniform Delta component, or Position, Velocity, and Acceleration could be combined alongside such components as Friction and Gravity into a monolithic Physics component.

Should a component have the smallest responsibility possible (at the cost of lots of interconnectivity) or should related components be combined into monolithic ones (at the cost of flexibility)? I'm leaning toward the former, but I could use a second opinion.

Answer 1

There's a line between complete granularity, leading to no code wastage or blob-like state (which is why component architectures are favoured), and usability.

Obviously things may have a Position, but they're not necessarily dynamic (so why have Velocity and Acceleration?). However, something with a Velocity is going to be a moving object, so it makes sense to also have Acceleration grouped.

Are you going to have a case where v and a are going to be needed, but you don't want a physics simulation for them? Similarly, is there going to be a point in Gravity if they're not physics objects?

tl;dr Group what makes sense.

Answer 2

To avoid micromanaging each and every variable I'd suggest by starting heavy, choose divisions around responsibility and refactor when the situation presents itself logically. You can start the first designs on paper. At some point these gross divisions of responsibility will become the building blocks of your entities.

So for a rushed example you have Game. Game splits into Environment + State. Environment splits into StaticWorld + MovingStuff. State splits into AIControlled + PlayerControlled. The gross idea of Damage splits into TakesDamage + GivesDamage.

And so on.

Much like the common advice to "Build games, not engines!" for new practitioners I recommend "Build Games, not elaborate component systems!" because only with personal experience with a running game will you know whether an elaborate component system is called for in future works.

Answer 3

My guess would be to combine components who will have lots of interaction. In your case, i'd keep the position in a single component, and have the velocity & acceleration kept together in a physics component.

But it depends a lot on what your game features are (unless you're building a framework with no specific game in mind).