Archived

This topic is now archived and is closed to further replies.

no one

engine and ai object classes...

Recommended Posts

no one    133
Hello hmm, I deleted what I originally had because it was starting to look like a book. lol. Ill try and get out my questions as quicly as possible. If what I say is unclear, just tell me so. Ok, heres my ''issue''. Im taking the normal oop approach at my object system, but with a small twist, each class may and probably will have a interface class associated with it for lua. Anyway, Im just not sure what I should make engine specific and what should be part of the AI system. Heres what im thinking of doing now... CEntity and interface classes, extended class- CMesh, CStaticMesh, CLight, etc. Sub classes, CVehicle : public CStaticMesh, CTerrain : public CStaticMesh, CPawn : public CMesh, etc... Those classes would be engine specific. Ok, now to turn that stuff into a game, I would make classes in the AI engine which extend the engine classes. Example: CHoverBike : public CVehicle Understand? With this approach, I can''t really see any problems, other then maybe this... *example only* CEntity ent = new CHoverBike(); Im not sure if that would work correctly. Other then that, I can''t think of any problems. Ok, so to sum this up. Is my design plan good or bad? *note: I have already thought about memory issues and such, that is one reason why there will be interface classes. Thanks alot and sorry for the long post. Its not as long though as the original one! Feel free to criticize or whatever.

Share this post


Link to post
Share on other sites
oliii    2196
that''s pretty much the approach used when coding in C++ on top of an engine. In fact, you can use virtual interfaces to your engine components, where the interfaces are all abstract, like you probably do. It is a common practise really.

CVehicle provides a common shared interface to all vehicles, so it makes sense to have an HoverBike as a vehicle. For A.I. you could have a CHuman base class in the engine, and derive a CFootSoldier, CSniper, CPilot, ect... However, with this method, you sometimes cannot avoid multiple inheritance, which can cause problems.

The Centity* pEnt = new CHoverbike(); works, but limits access to the HoverBike object to a CEntity interface. You probably also need a way to differenciate various game objects, like having a class ID parameter stored, and cast pEnt to CHoverBike object safely. Another way to do it is use something like this...


class CActor: public CEntity
{
virtual void Drive(CVehicle* pxVehicle)=0;
};

class CNPC: public CActor
{
virtual void Drive(CVehicle* pxVehicle)
{
pxVehicle->UpdateDriverInputs(this);
}
};

class CPlayer: public CActor
{
virtual void Drive(CVehicle* pxVehicle)
{
pxVehicle->UpdateDriverInputs(this);
}
};

class CLandVehicle: public CVehicle
{
virtual void UpdateDriverInputs(CActor* pxActor) =0;
virtual void UpdateDriverInputs(CPlayer* pxPlayer) =0;
virtual void UpdateDriverInputs(CNPC* pxNPC) =0;
virtual void UpdateDriverInputs(CCruiseControl* pxCruiseControl) =0;

};


class CHoverBike: public CLandVehicle
{
virtual void UpdateDriverInputs(CActor* pxActor) { pxActor->Drive(this); }
virtual void UpdateDriverInputs(CPlayer* pxPlayer) { ... }
virtual void UpdateDriverInputs(CNPC* pxNPC) { ... }
virtual void UpdateDriverInputs(CCruiseControl* pxCruiseControl) { ... }
};

class CTank: public CLandVehicle
{
virtual void UpdateDriverInputs(CActor* pxActor) { pxActor->Drive(this); }
virtual void UpdateDriverInputs(CPlayer* pxPlayer) { ... }
virtual void UpdateDriverInputs(CNPC* pxNPC) { ... }
virtual void UpdateDriverInputs(CCruiseControl* pxCruiseControl) { ... }
};



Also, I think you should call your engine classes differently from your game classes, like

CEngine_Entity....
CEngine_Vehicle.....
CGame_LandVehicle....
CGame_Tank....

it makes it easier to see what''s from the engine and what''s not. Then you can possibly migrate some stuff from your game into the engine, if you think it''s appropriate enough.

Share this post


Link to post
Share on other sites
jonnii    122
with oop programming two rules that will always pretty much help are:

always code to an interface, not an implementation

and

composition over inheritance

Share this post


Link to post
Share on other sites
no one    133
Yea, I quess I have been forgetting why we use oop languages
in the first place. *slaps him self in face, starts to tear up* lol.

Share this post


Link to post
Share on other sites