Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Having read a lot recently on Component Based systems (for games), i find it hard to go back to my earlier state of mind.

If static object hierarchies fail to model "objects with a dynamic set of properties" then:

  1. Why are they even used for in the first place? (in game dev and software engineering in general).
  2. Is there any other option other than going Component Based to realize a more dynamic and flexible object model ?
share|improve this question
Component-based architecture is really just an application of preferring composition over inheritance in the general case, which there are a ton of articles supporting. – Tetrad Aug 13 '12 at 16:55
  • Not everything has a dynamic set of properties. In fact, much of software engineering is about trying to pin down a precise and static specification of something.
  • Static hierarchies are easier to reason about because they're broadly fixed in the code. Components can lead to an explosion of possible permutations - great if you need that flexibility, but difficult for someone to understand later.
  • Components are not always a simple way to think about something. Often you're more interested in the whole than the parts, and the parts only become clear later. It's very hard to start out with a component based system for this reason.
  • Nobody knows the best way of doing components yet. You can see this from the mountains of questions here asking about how to implement some aspect or other. The more traditional approaches are fairly unambiguous and straightforward by comparison.
  • Components are really just another way of structuring code to do the same things that have always been done. If you wanted to be able to swap out some similar parts, you always had polymorphism for that. Design patterns like State and Strategy were facilitating components long ago. So you don't need to throw out all the old ways of working to enjoy most of the benefits.
  • The choice was never between 'static object hierarchies' and 'component based systems' - people were writing software and games before inheritance was commonly used. You can approach shared functionality in many other ways, perhaps just by setting a flag that tells the system whether to call a certain function or not. Ultimately they're all just different routes to the same goal - different objects have different bits of data that require different functions to be called on them, and how you arrange that information has always been down to a combination of personal choice and the features of the language you use.
share|improve this answer
I'd +1 this answer to infinity, it's really great. – jcora Aug 13 '12 at 14:18
@Kylotan nice answer. The choice i was referring to was regarding game object models, and how to represent different game objects. Static hierarchies do not allow to break down a set of properties and mix&match them to create an objects with varying kinds of properties. – spaceOwl Aug 13 '12 at 14:24
I know they don't - and for the majority of computer games ever made, that didn't matter. – Kylotan Aug 13 '12 at 16:01
I disagree with most of these points. The bass of most of them are that components are hard. Having worked with hundreds of kids who are just learning programming, I can say that they are not hard; they only seem hard if you've been miseducated for years about how to use inheritance in the first place (e.g. Using it for real-world/ "logical" is-a relationships instead of as a tool for facilitating polymorphism). – Sean Middleditch Aug 13 '12 at 16:25
Well, I learned programming years before I even heard about object orientation, and I still think component-based systems are relatively difficult to get working well, and very difficult to design. Maybe literature will make it easier in the future but right now people are struggling, and that is borne out in the perpetual questions you see here, on, on Reddit, etc. – Kylotan Aug 13 '12 at 21:27

Well, definitely.

You don't have to go to extremes, like adam, who suggests that you should make your games more like databases and use declarative programming.

You could combine the approaches, for example, not having an entity manager but specific lists for various types of objects. Component based design is really useful when you end up with a monolithic class that defies the single responsibility principle.

Generally, in simpler games, or games where performance is needed, you might not want to use entity systems (but the performance greatly depends on the implementation).

As for why inheritance is used in game development, well, it was already there and natively supported, everyone else is using it, and it's simply intuitive. And seriously, if you plan ahead and use at least some component based design elements, you'll be fine with a classic implementation of a game.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.