This is how the Unreal Engine was architected and it makes it really easy to create new composite objects.
In contrast, when we did the first version of the MyMiniLife/FarmVille engine in flash, in the name of the speed, we made the mistake of not architecting the game object model in this way. We had to go through a painful refactor process 6-months after FarmVille's launch to fix-up the object model because we were duplicating behavior across objects that were really close to being the same...but not at the same time.
Couple other benefits of using this approach:
1/ You can let game designers dynamically create new objects without programmer intervention. Just let them mixup new components as they see fit through an editor.
2/ If you build a visual editor/CMS for your objects, you can do some pretty nifty stuff with custom editors/renderers for components. For example, the UnrealEditor at one point had a custom color picker for the ColorComponent that made it much easier to work with colors than entering R,G,B manually.
3/ If you build in serialization to your components at a low level, you can do things like have lazy deserialization of your components so that they are only instantiated/initialized once you access the component. This may not seem like a big deal at first but when you are working with tens of thousands of objects across millions of users, deserialization time ends up being significant.
It needs to be mentioned that components are not how UnrealEngine was architected, rather Unreal was designed as a monolithic single inheritance tree, and components were very recently just shoehorned into the system. Unreal still carries a lot of complexities from it's inheretiance even though some of the more basic systems have been converted into component systems.
The Component system is also at the core of the Unity3D game engine : everything in the scene is just a basic game object which just has a parent and a position ; and each specific behaviour (be it mesh rendering, collision handling, also all custom user scripts) is then added via components.
This is how the Unreal Engine was architected and it makes it really easy to create new composite objects.
In contrast, when we did the first version of the MyMiniLife/FarmVille engine in flash, in the name of the speed, we made the mistake of not architecting the game object model in this way. We had to go through a painful refactor process 6-months after FarmVille's launch to fix-up the object model because we were duplicating behavior across objects that were really close to being the same...but not at the same time.
Couple other benefits of using this approach:
1/ You can let game designers dynamically create new objects without programmer intervention. Just let them mixup new components as they see fit through an editor.
2/ If you build a visual editor/CMS for your objects, you can do some pretty nifty stuff with custom editors/renderers for components. For example, the UnrealEditor at one point had a custom color picker for the ColorComponent that made it much easier to work with colors than entering R,G,B manually.
3/ If you build in serialization to your components at a low level, you can do things like have lazy deserialization of your components so that they are only instantiated/initialized once you access the component. This may not seem like a big deal at first but when you are working with tens of thousands of objects across millions of users, deserialization time ends up being significant.