Is there any option other than Component Based for game architecture?

Question

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 ?

Answer 1

• 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.

Answer 2

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.