Single or multiple inheritance for game world objects

Question

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?

Answer 1

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.

Answer 2

You might also want to consider a component based approach for your game. I can point you to these two articles on the subject:

• Component Based Engine Design (archived from Randy Gaul's Game Programming Blog)
• various entries on entity component systems on Cowboy Programming

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