# Single or multiple inheritance for game world objects

So I am currently laying out on paper the system I want to code for a game in C++.

Now currently I am debating whether to have e.g. a class object_door that inherits from another class object_interactive, which inturn inherits from the base class object

OR

have a class object_door that inherits from both the class object and another base class interactive.

Is there any advantage to either way of doing inheritance? Or is there maybe a commonplace convention for this?

• If interactive NEEDS to inherit from the base game object, then make it. If it doesn't, then make door inherit from both. This is a question of whether or not interactive is a base game object( it probably should be ). – Ben Apr 17 '14 at 18:29
• You shouldn't use inheritance where it doesn't solve a code duplication problem in software design. It may lead you to uneasy situations where conceptually an object is x and y and you want to inherit both. This could make the construction and handling of objects far more complicated. You should consider an entity component system unless you see a clear advantage in the current inheritance scheme you are using. In general you should think of inheritance as a tool to remove code duplication and group classes with very different attributes and behaviors under one roof, use it sparingly. – AturSams Apr 18 '14 at 12:37

Update: I have learned quite a bit about game programming since I wrote this. I think it would be relevant to mention Robert Nystrom's Game Programming Patterns book, which contains a lot of information on ways of structuring your game code.

## Multiple inheritance

In C++, you want to be careful with multiple inheritance. It can really add complexity to your code. Especially when you include two objects that have the same base class. This is known as the diamond problem. There are, however, cases were multiple inheritance has it's uses, as seen below.

### How to properly use multiple inheritance

In Java, there is a built-in interface type. This is the type of situation were an interface could be used. But as you know, C++ doesn't really have a built-in interface type. You instead create a class that contains only pure virtual functions to create an interface. This class shouldn't cause any diamond inheritance issues, however, so avoid letting this class inherit from other classes if it isn't logical to do so.

While this is still technically multiple inheritance, it still avoids a lot of the problems that can be introduced by normal multiple inheritance (like the diamond problem).

Again, multiple inheritance has it's uses, but can add complexity. I recommend that you read this SO page on multiple inheritance.

## Designing your game

Many times, you can think of how such hierarchies would by organized in real life. In this case, multiple inheritance may be the way to go (remember, this is only how I would design it if it was my game). Here is my reasoning: Not all doors are directly interactive (think of garage doors). Think. Later on, you may want doors that aren't interactive.

Doors are really just a concept that can be thought of in this way:

• All doors can be in an "open", or a "closed" state.
• All doors have some way of opening or closing them (except in the case of one-way doors). This may be direct, or indirect (as in a electrical signal).

This doesn't mean that you need to have an abstract door base class, but you should consider that you may want a Minecraft-like iron door (which can only be controlled by redstone). In this case, the only difference between wooden and iron doors is that iron doors have a different onBlockRightClicked method. So there isn't really a reason to have a single door base class (really, how many doors do you need?).

So if you don't need a door base class, what should you do? My recommendation is that you consider moving your object_interactive code to your base game_object class. This is because you may have a lot of items in your game that are interactive. I do not know exactly how you are doing things, but I would assume that you would have to cast every object into an object_interactive after checking that it is an object_interactive every time that you want to use them as an interactive object.

In the end, it really comes down to how your game is structured. It is really hard to tell you what to do unless we were actually on a team with you discussing this in person.

You might also wan't to consider a component based approach for your game. I can point you to these two articles on the subject: 1 - 2

If you search for "component based game architecture" or "entity component system" you should be able to find a lot more on the subject.

• From my experience, I would recommend this too. It may be worth expanding on this answer with some of the advantages components offer over inheritance. Informally, I've found that systems that use composition over inheritance retain their flexibility better as the project becomes more involved, and the work required to add new functionality goes down as new features can often be made by re-using a combination of existing components. It's also very friendly to data-driven approaches, where designers can modify behaviour or even create new enemy & item types without needing to touch the code. – DMGregory Apr 17 '14 at 20:07
• Though I agree that entity systems are the preferred route for game development. It takes some time to get used to the paradigm and if you're not used to entity systems (like I was) you'll encounter some unexpected problems that you would've planned for in a normal hierarchical approach if you're already really accustomed to that. That doesn't mean you should be afraid to learn something new, just prepare yourself that it will take months before such a new paradigm will really make sense and you really understand the strengths and weaknesses of the method. – Roy T. Apr 17 '14 at 21:02