Inheritance vs Composition

Question

I make my money in C# Generally in that language I like to decouple everything to the high heavens using interfaces. This has served me well in enterprise code but in writing games in C# I find myself tending towards inheritance due to being able to define some default behaviors for base classes. I feel dirty doing this though, like I'm disobeying some architecture god who once said "favor composition over inheritance". I know its not black and white but I also feel like i could use interfaces with a bit more work and achieve roughly the same thing.

What do other people do? Is inheritance the right approach for games or should I refactor in some interfaces?

Answer 1

Inheritance in games is actually one of the worst things you can do -- in particular in regards to entities. Read this for why. Composition over inheritance takes you a long way with games. As for other areas of your engine, it doesn't really matter. Say for example you are making a call to some sort of external network service, then you can inherit one generic type Service to eg. HTTPService and SocketService -- very much as in the enterprise apps you're used to.

Unless your game is really simple, you will want to use an component-based entity (CBE) architecture. The general idea is that with entities, the reason they are so commonly composed rather than inherited is because you cannot know until runtime what capabilities a given entity will have. For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition. The plus side in this scenario is that you can also have fully customisable enemies, built in the same way, rather than enemies that are always exactly the same every time you see that enemy type. So with CBEs, you might see a Martian Freighter and think, "Ah it only has tiny lasers, I'll take it down", and usually that would be true but when you get in range suddenly you realise it has a big-ass wormhole gun. Surprise surprise!

Componentisation is removing implicit coupling of logic, and that is GOOD.

Answer 2

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: https://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.

---

For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too