Appropriate level of granularity for component-based architecture

Posted by Jon Purdy on Game Development See other posts from Game Development or by Jon Purdy
Published on 2011-07-08T03:18:49Z Indexed on 2011/11/17 2:06 UTC
Read the original article Hit count: 136

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.

© Game Development or respective owner

Related posts about architecture

Related posts about programming