# What is an appropriate level of granularity for component-based architecture?

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.

• Similar question: gamedev.stackexchange.com/questions/4914/… – Den Jul 9 '11 at 12:02
• Are you going to use your own physics engine or integrate an existing one? – Den Jul 9 '11 at 12:07
• @Den: I'm writing some physics code, but it's not an engine by any means. Just mundane 2D kinematics. – Jon Purdy Jul 9 '11 at 22:54

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.

• Sounds fair. My system has very little centralisation: if an Entity has a Position and some components that make that Position participate in physics, then the Entity is de facto physical. I think what I may do is just add some components for logical grouping, and keep all the fundamental components to a single responsibility. So adding, say, a Movable to an Entity would have the same effect as adding a Position, Velocity, and Acceleration. – Jon Purdy Jul 8 '11 at 15:41

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.

• I'm not a new developer. If I have components based on concepts rather than behaviour (i.e., top-down versus bottom-up), won't my architecture be more brittle, and more elaborate? I can implement any behaviour I want from small components, but I can't always get the desired behaviour from precombined ones. Not to mention that I can't predict everything I'll want to achieve even in the context of one game. – Jon Purdy Jul 8 '11 at 19:21
• The drawback to bottom-up is that communications between components becomes a problem, and people tend to start way too micro on the scale of what they're modeling. I was mainly trying to steer away from the super-micro "xyz is a component" "rotation is a component" "rgb is a component" level for someone inexperienced. – Patrick Hughes Jul 8 '11 at 19:50
• Fair enough. I just wanted to make sure I understood you correctly. With the slot system I have, it's simple and efficient for components to communicate, so I really don't see any drawbacks to the "super-micro" scale. I don't intend to refactor this into a standalone engine, but if I do, then I can always introduce abstractions such as the component groups I mention in my comment on The Communist Duck's answer. – Jon Purdy Jul 8 '11 at 20:02

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).

• The problem with combining components with a lot of interaction is that sometimes the other part isn't needed. – The Communist Duck Jul 9 '11 at 11:44

I realize this is an old question but maybe someone will find this answer useful.

I believe that Systems will better help you to understand how to construct Components. Systems exist in architectures where components don't contain their own logic, aside from simple getter/setters and helper functions. Systems operate on Entities which satisfy the Component requirements. This is why it is best to separate component data as much as it makes sense for that data to be processed without the other data.

For example, you might have a MovementSystem which updates its Entities' Position based on their Velocity. This could be for simple entities in the game. But, for the Player and Enemies, you might want movement that has Acceleration which is processed in AcceleratedMovementSystem. But for Obstacles you might want Friction. The Terrain might also have friction, but it won't have a velocity component. But what about Gravity? Just add it Player, Enemy, and Obstacle, and create a GravitySystem to process it.

The bottom line is that the more decoupled your Components are, the more extensible the Entities will be when using Systems.