ok let me build a foundation real quick.. in my "game" I have an Entity Class .. wich for me means that it has physical properties thus recieves physics calculations... a few classes that inherit from Entity are Item and Actor.. ..Item being any thing useable ..(weapon, potion, moveable wall,..etc) ..Actor being characters in the game.. thus actors will require inteligence ie a brain if you will... I am thinking of making another base class called mmm. "Brain" .. i know the rule "is a" / "has a"... while an Actor may not be a "Brain" hear me out. The brain will contain goals, urges, purpose .. etc I then will make the Actor inherit Entity and Brain... Since all my objects are from Entity They are owned by EntityEarth .. EntityEarth holds a list of Entites..the "EntityList" and a list of Brains "BrainList" ... Actor being in both of them The "mainList" is processed by the PhysicsMaster.. wich does collisions and physics" I am going to create an AIMaster that will recieve the "BrainList".. it will process the "brains" is this making since? the actuall order of processing will be USERINPUT AI PHYSICS RENDER I never really see anything good written about multiple inheritance.. So is there something that i dont understand .. it seems like a good idea here ACTOR = ENTITY + BRAIN..? are there any issues that i may incounter?? also for userInput.. I dont really wnat it to be in the main loop as if( this keydown ) {do this ..} else {dont do this} I think i would rather my controlled units respond to the key presses.. anyone know any good resources for that... or perhaps a better idea? thanks for the time.. ;P

.. yeah, i am using direct input.. I guess i am interested in input listeners... and having my controlled units listen to the keyboard and respond on their own .. instead of me having to tell them to move

if(keyDown(DIK_W))
{
unit[23].moveFoward();
}

ill figure it out..
thanks though

oh how did the post confuse you?
I just really wondered about the "risks" of multiple inheritance..

Hi MTclip,

I think multiple inheritence is a bit of a no-no, I used it once and got slapped on the wrists for it :-) But would like to know more on the subject...

Sounds to me like a Brain requires an Entity. So derive Brain from Entity... Then you'll only need one list, of entities, and you can cast these to brains when needed. Although you'll need to handle if an entity doesn't have a brain, what I would do is have a virtual bool HasBrain() function which returns false in the Entity and is overriden in Brain to return true.

When handling the brains you can then just go





Richard.

hey.. those were the responses i was looking for

Quote:
bangz: Sounds to me like a Brain requires an Entity. So derive Brain from Entity

yeah i thought of that but.. a "brain / intelegence" is that it does not have physiscal properties.. so i did not want to do that.. but if for some reason i have probs with the muliple inheritance this is my back up plan

Quote:
dbzprogrammer: everything in the brain class begin with a 'b' or a 'B'. Same with entity...

thanks for that.. I am planning on using the multiple inheritance..

Quote:
bobason456: Just a thought about your AI. If an object has a brain then moving forward might translate in the desire to walk forward in the brain, rather then directly moving the object how about.

object.brain.I_Want_To_Move_To_Location(vector);

With a number of vectors then AI could then make a weighted decision about where or how to get to those locations, or in what order to move to them.

I like that idea.. the way my characters move(walk / run) is is purely physics.. It will apply a linearforce based on the movement strength.. and they will not actually move until physics procesisng time.. this allows for multiple influences per character..


thanks..

I would put a pointer to a brain into the actor class and a bool telling you whether the actor has a brain or not? Then you wouldn´t the same actor being in two different lists, but could only put its brain inside the brain list, and the actor itself into the entity list. If the brain needs to know to which actor it belongs (which I´d assume) you could put a pointer to the actor inside the brain, too.
To me that resembles my view of this better than your approach, since an actor has a brain, but he isn´t one... if you get what I mean :) and you get around having the same object in two lists doing different things, which I personally wouldn´t like too much.

Otherwise I like that design.

I like matches81's idea, you can get rid of the bool by setting the brain pointer to NULL initially (in constructor for the actor class) and you'll know if you've got a brain because this pointer will have a non-NULL value.



Richard.

Quote:
I would put a pointer to a brain into the actor class and a bool telling you whether the actor has a brain or not? Then you wouldn´t the same actor being in two different lists, but could only put its brain inside the brain list, and the actor itself into the entity list. If the brain needs to know to which actor it belongs (which I´d assume) you could put a pointer to the actor inside the brain, too.

yeah.. that is also something that had crossed my "brain" ..hehe..
it follows the OOP rules better .. "is a / has a"... but then i have the cyclic thing going on.. The more I think about it more, I actually do like that idea much better... is cyclic ok .. or is it considered something to be avoided..

thanks again