Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
Interfaces are not composition either, so it is not clear what you are asking. –  user744 Sep 1 '11 at 18:08
I just want to mention that since you are working with C# you would have a hard time if you chose to use inheritance since C# doesn't support true multiple inheritance. Using the multiple interface method is fine until you get into the 4-5 interface range and have to cut/paste 25+ lines of code between every class that shares the same implementation. There are some work-a-rounds but they are just as ugly since the language doesn't provide direct support. –  NtscCobalt Oct 29 '11 at 22:12

2 Answers 2

up vote 17 down vote accepted

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.

share|improve this answer
Thanks for the advice mate :) Nice to know I wasn't hearing voices! –  Peter Short Aug 31 '11 at 18:09
+1 for "big-ass wormhole gun. Surprise surprise!" –  Amplify91 Aug 31 '11 at 18:15
+1 Thanks for the article, I've been meaning to do this in my game for quite some time –  John McDonald Aug 31 '11 at 19:15
Should be noted that due to the high inter-reliance of game entities that inheritance often complicates things and makes maintainability and extension a cumbersome task. Component systems tackle this problem nicely and the other additional benifit is what is listed in the answer above ;) –  James Aug 31 '11 at 20:08
Surprises are fun, but surprises that mean you die without warning, like a low level ship that can OHKO you, are just frustrating ;) Of course this may not be what you meant in your answer. Also, there is much more to a game than just game design. –  Jonathan Connell Sep 1 '11 at 11:52

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: http://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

share|improve this answer
-1, components are a form of composition. –  user744 Sep 1 '11 at 18:09
well, a form of but not the same since they provide different features. (So I don't understand your comment and -1) –  idefix Sep 2 '11 at 8:45
When you say "composition vs components" it is not clear what you are comparing since components are composition. Do you mean dynamic components vs. static components? Either of those versus composition of types related neither familialy nor structurally? What is "component-based overhead"? In static component systems (and many dynamic ones) the overhead is nearly zero. –  user744 Sep 2 '11 at 17:06
Hm, interesting points. Do you mind a little more detailed discussion? If not I would like to send you my mail address on another platform. –  idefix Sep 20 '11 at 5:53

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.