   Design Question
  I'm sure this is discussed frequently, but now its my turn lol.  I'm making a game, and wondering how to design my gameobjects so that they interact with a collision, rendering, and update/AI systems.  I could have the gameobject use multiple inheritance so i have an interface for each system to use, but I recall hearing that using multiple inheritance is a bad design decision.  Perhaps its an unavoidable evil in this case.  Should I use a static struct to contain info for each gameobject derivation and send that to the systems?  There are many ways to go about this, but I just want to get a better design sense.  What are your recommendations?   
  Please read my response here: http://www.gamedev.net/community/forums/ViewReply.asp?id=3471235There should at most be very very shallow inheritance.   ;  Makes sense.  I think I was trying to make things hard on myself by having data (such as the transform info) local to the gameObject, rather than have multiple instances of the same data among the different system interfaces.  I need to learn not to try so hard to optimize sometimes lol.   ;  'Component-based Design' is a pretty popular concept around here. I chose instead to go a different route. A basic Actor class which is used for most moving, animated creatures is defined like this:class ActorView {public:virtual void TakeDamage( Vector3f location, int damage ) = 0;};class ActorView3D : public ActorView {public:ActorView3D( Actor & _actor ) : actor( _actor ) {// initialize mesh}void TakeDamage( Vector3f location, int damage ) {// create blood particles}// notice this is not virtualvoid Render( ) const {// just using opengl as an exampleglTranslatef( actor.position.x, actor.position.y, actor.position.z );mesh.Render( );}private:Actor & actor;};class SoundActorView : public ActorView {public:void TakeDamage( Vector3f location, int damage ) {// create grunt sound effect}// notice this is not virtualvoid PlaySounds( ) const {// whatever library you're using}};class ActorController {public:virtual Vector3f GetDesiredMoveDirection( ) const = 0;virtual Vector3f GetDesiredLookDirection( ) const = 0;};class KeyboardActorController : public ActorController {public:Vector3f GetDesiredMoveDirection( ) const {if( keyboard.IsKeyDown( 'w' ) ) {return Vector3f( 0.0f, 0.0f, 1.0f );}// etc ...}// etc..};class AIActorController : public ActorController {public:Vector3f GetDesiredMoveDirection( ) const {if( aistate == "walking" ) {return aistate.destination( ) - actor.position( );}// etc..}// etc...};class Actor {public:// Getters and setters for everything belowvoid TakeDamage( Vector3f location, int damage ) {health -= damage;foreach( view in views ) {// notify views of eventview->TakeDamage( location, damage );}}private:float health;AxisAlignedBoundingBox box;Vector3f position, velocity;Vector3f rightvec, upvec, forwardvec;ActorController * controller;std::map< std::string, ActorView * > views;};Then in the game class..class Game {public:void Timestep( float elapsed ) {foreach( actor in actors ) {UpdateActor( actor );}}private:void UpdateActor( Actor & actor ) {actor.velocity += actor.GetController.GetDesiredMoveDirection( );if( environment.CheckCollision( actor.position, actor.forward ) ) {// move to collision point, do collision response} else {actor.position += actor.direction;}// other stuff}std::list< Actor > actors;Environment environment;};class GameView3D {public:GameView3D( Game & _game ) : game( _game ) { }void Render( ) const {game.GetEnvironment( ).GetView< EnvironmentView3D >( ).Render( );foreach( actor in game.GetActors( ) ) {if( actor.GetView< ActorView3D >( ) ) {actor.GetView< ActorView3D >( ).Render( );}}}private:Game & game;};Basically that's how it works.[Edited by - MilfredCubicleX on June 17, 2009 3:25:51 PM];Quote:Original post by MilfredCubicleX'Component-based Design' is a pretty popular concept around here. I chose instead to go a different route.*** Source Snippet Removed ***That is very similar to a component-based approach: your Actors are the Entities, and your Views are the Components. 'Component-based' covers all manner of evils [wink]   ;Quote:Original post by swiftcoderQuote:Original post by MilfredCubicleX'Component-based Design' is a pretty popular concept around here. I chose instead to go a different route.*** Source Snippet Removed ***That is very similar to a component-based approach: your Actors are the Entities, and your Views are the Components. 'Component-based' covers all manner of evils [wink]Fair enough. However, Actors aren't the only type of entity in the game, there are other types for static objects, weapons, etc. And most importantly, Actors (Entities) do not update themselves. I guess I was mostly referring to the 'pure' component-based design linked to by bzroom.;Quote:Original post by MilfredCubicleXAnd most importantly, Actors (Entities) do not update themselves. I guess I was mostly referring to the 'pure' component-based design linked to by bzroom.I would consider Entities updating themselves to be a fairly 'impure' approach to component architectures [smile]In my engine, Entities have absolutely no logic - they purely exist to contain state, with all behaviour provided by the attached Components.   