Multiple inheritance?

That sounds like a design flaw. Could you explain why you think a sprite should have access to the AI module? A sprite should be informed to draw at a position with an orientation not querying the AI for state.
I also do not understand where you think multiple inheritance comes into play here.

Composition is a much better way to design, try to google component based game design.

Quote:

Original post by Haladria Composition is a much better way to design, try to google component based game design.

I would have a problem with composition here as well for the same reason as listed above. Why should a sprite know about AI? if you need to change a sprite based on the state of the AI then that is for a higher level to decide and implement.

Well you might have noticed my question mark after my subject. Im not sure if it had anything to do with inheritance... Hence the question mark 0_0.

All i want to know is what would be the best way to go about doing what i wanto do..

Just like i call:

g_pSprite->Draw();

I wanto to be able to call:
g_pSprite->Roam() or g_pSprite->Avoid()..

I hope that clears up the confusion. Im sure there are better ways of implementing this.. If so, what are they.

Quote:

Original post by magic_man Quote: Original post by Haladria Composition is a much better way to design, try to google component based game design. I would have a problem with composition here as well for the same reason as listed above. Why should a sprite know about AI? if you need to change a sprite based on the state of the AI then that is for a higher level to decide and implement.

Yes, but a composition could be like the following

GameObject
- holds (private) instance of AI component
- holds (private) instance of Sprite component
- ...

OK I will not dwell on this but you are using Hungarian notation and are referencing a global, this could be better designed.
I have asked a couple of times for you to say why you think the sprite should be able to access the ai module but to no avail.

What is your definition of a sprite? It seems that you have your responsibilities messed up. My definition would be something like a sprite is:
an image or a portion of an image.
what does it do:
it gets drawn to screen.

Lets image you have an _object_ class, it "has a" sprite instance and "has a" ai instance.
object::update(float delta)
{
ai->update(this,delta);
sprite->render(renderer,position());
}

Here the sprite needs no interaction with the ai, as the ai updates the _object_(or requests a change) by making decisions on whether is should wander,avoid, follow etc. The _object_ then passes the location to render the sprite to the sprite instance.

magic_man has it completely right (imo). This smells of bad design, you should never have a circle dependency. Sprite has nothing to do with AI what-so-ever and has no need to know about AI at all. Its a dumb object if I've ever seen one. It should hold a smart pointer to its image, its position and maybe orientation. The renderer should draw it, the AI might update it (via physics).

Also the fact your using globals is another indicator of a bad design. Answer the asked questions and we can likely start steering you in a better direction (and no, singletons are not a better direction).

magic_man is right. your design is unfortunately poor as said. Sprite has nothing to do with AI

your design should be similar to this

class Sprite{	//Handles creating/loading/saving the image of the sprite	//as well as moving it/stopping it/hiding it};class AI_TANK{	Sprite* _p_Sprite;	//AI functionspublic:	void dodge();	void chase();	void fire_missles();	//and so on};

Ideally, IMHO, your design would look something a little more like this:

class Sprite{    Image img;};class AI{    Intent foo;};class GameObject{    Sprite sprite;    AI ai;    //and other stuff};

There is this small issue of communication between AI, GameObject, and Sprite. I'm still working on that one.