I’ve tried my hand at this design before and the real difficulty I’ve always run into is enforcing a particular order that components should be in the container class. The method I’ve employed before is to have each component maintain it’s own list of dependencies which are checked when the component is added to an object or component collection. The problem inherent with this is that it’s very easy to create cyclic dependencies, especially later on in the project when you have potentially thousands of components.

There’s no easy solution, but the traditional approach simply doesn’t cut the mustard these days in my opinion, and something new like the composite design is definitely an improvement.

When creating components, or functionality for an existing component, consider if it can be split into sub components that might be useful in another composite object. All the things you mention could be components.

While reading your article though, a question kept popping up in my head which I don’t seem to be able to shake off.

Take a light or a camera for instance. Beyond the very essence of their nature, i.e. as objects that illuminate or capture the scene, either of them may have or have not a Position, Render, Physics or Script component and so on, so they clearly must have their place in such a system, either as entities or as components, so my question is how do you go about incorporating these objects into such a system? Are lights and cameras components too? So a scriptable camera consists of two components, the CameraComponent and the ScriptComponent? What about a particle emitter? Or a physical joint?

Generally speaking, what’s the rule of thumb for recognizing components?

Thanks in advance.