Multiple inheritance

[Laurens]

Hi,

 

I am currently facing a problem to which I see no other way out then multiple inheritance. I have never actually used it before but keep hearing from people you should probably stay far far away. The problem I have is this:

 

I have class called Actor. This class is the base class for all other objects that have some sort of physical representation. It simply contains a TEntity. The class Tower inherits from Actor. The tower is an object that can establish a link with other towers over which it transfers energy.

 

On a basic level this network of towers is a graph. I could implement a graph with a Graph class (the network), an Edge class (the links) and a Vertex class (the individual towers). I would then have the Tower inherit from the Vertex, but the tower already inherits from Actor.

 

Is this situation a valid use for multiple inheritance or is it not, and more important, why? Would you perhaps solve this differently?

 

Hope I made myself clear

 

Thanks!

[Canardia]

There's 2 types of multiple inheritance: parallel and sequential.

In most cases sequential inheritance should be the right thing to do, since that's how nature works too.

 

In your case, sequential inheritance will work fine, since Actor should inherit from Vertex, so Tower needs only to inherit from Actor. Or then the design of your Vertex class is wrong, which causes your dilemma. The Vertex class should only contain a 3D coordinate, and maybe some other general vertex related abilities.

[Rick]

hmm, could you just have the Tower class hold a list of Towers that are linked instead of having the graph, edge, vertex classes?

[Laurens]

Hi,

 

There's 2 types of multiple inheritance: parallel and sequential.

In most cases sequential inheritance should be the right thing to do, since that's how nature works too.

 

In your case, sequential inheritance will work fine, since Actor should inherit from Vertex, so Tower needs only to inherit from Actor. Or then the design of your Vertex class is wrong, which causes your dilemma. The Vertex class should only contain a 3D coordinate, and maybe some other general vertex related abilities.

 

That would work but I prefer not to because not all actors are part of the graph. Towers are part of the graph, but a Planet is not. I can't think of any real ill side effects of having Actor inherit from Vertex but I feel it wouldn't be proper design.

 

hmm, could you just have the Tower class hold a list of Towers that are linked instead of having the graph, edge, vertex classes?

 

That would also work, except I need the links between the towers to also have a visual representation which is why I also derived the Link class from Actor. It would also need it to inherit from Edge but this is essentially the same problem as with Towers.

 

Anyway, still pondering this over

 

Thanks!

[Laurens]

I finally decided to go with Rick's solution. The end-result works pretty nicely but I am a bit disappointed about the fact I don't have any reusable graph components for a future project now. Oh well

 

Thanks!

 

EDIT: I realized MVC would be the ultimate solution here though. I would have a TowerView that would inherit from Actor and a Tower that would inherit from Vertex. To far in to make such a big change now though and I feel my understanding of MVC is not quite strong enough.

[Rick]

This is the reason I'm making this component based system. Like you pointed out above: "To far in to make such a big change now though", this is often the case with hierarchy systems. It can take a good deal of work to rework a hierarchy.

 

With the component design I have you would create components that describe the behavior of your towers via a class. This would expose events, functions, & attributes. Then the communication between each other would be by linking events to functions between game objects.

 

So in your case you would create in an editor x tower game objects. Then assign your tower component class to them. Now those game objects have events and methods. Let's say in the Update() method of your tower component, it's looking for a distance between it and another game object (let's say the "player"). When the distance is < x that tower fires off an event called OnFoundPlayer. Let's also say your tower behavior has a function called ShootAt() with an attribute of what to shoot at. In the editor you would link all your towers OnFoundPlayer event to each other towers ShootAt method. You would then set each towers shoot at attribute to the "player" game object.

 

Now when 1 tower see's the player it's telling all the other towers that registered to that towers event, and the other towers can act accordingly.

 

This is just an example, I don't really know how your towers are working, but this is the main idea behind my component design.

[Laurens]

That would indeed be much easier. I am currently working on this project mostly as a learning experience and may rework it at some point anyway if it helps me lay a good founding for building on in future games. I have been following your thread on component based design with much interest and will certainly look into it if I ever decide to rework it.

[Rick]

What type of functionality are your towers doing? Just want to make sure that the component method is able to handle all sorts of requirements. So if you wouldn't mind the idea behind your towers and the interaction they have that might help me validate that my design will work in various needs.

[Laurens]

It's a basic tower defense game where the towers shoot at enemies in range, and link up with other towers nearby to increase the damage they do (similar to the prism towers in Red Alert 2 if you know what I mean).

 

So the example you presented would be perfectly fitting.

[Rick]

I assume these towers are created dynamically by the player?

[Laurens]

Correct.