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.

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.

Multiple inheritance

In C++, you generally want to avoid multiple inheritance. It can really add complexity to your code. Especially when you include two objects that have the same base class.

Alternative to multiple inheritance

In Java, you can use interfaces in most of the cases were you may need multiple inheritance. But as you know, C++ doesn't really have interfaces. Well, at least not as an official feature. In C++, you can create a class that contains only pure virtual functions to create an "interface".

While this is still technically multiple inheritance, it still avoids a lot of the problems that can be introduced by normal 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). 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.

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.