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
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.
No comments:
Post a Comment