   Game programming Common Problems
  i would like to check if this idea has problems...question is:how do games create all these meshes and collide with each one with a different way?...e.g.when the player hits a door it opens(his health doesn't get affected),when he hits an enemy while that enemy is attacking..his health changesim thinking of making that:std::vector<D3DXMESH9> Enviroment(0);std::vector<D3DXMESH9> Enemies(0);and create a bounding shpere 3 or 4 times as large as the players original bounding sphere and if any of those meshes in any array of the two is in that bounding sphere....i put in the test we talked about later(a test for each subset) and if i collide with an enviroment...if its a door and closed..open it...if its opened....close it,if its an enemy and idle....do stealth attack...if its attacking..and im not evading...health goes down...   
  Well, I'd use polymorphism along with dynamic_cast<> to achieve this. If, for example, you derive a class 'Actor' and a class 'Door' from a base class 'Object' you can easily find if you should lose health or not:Object* current, target;std::vector<Object*> gameObjects;std::vector<Object*>::iterator iter, temp_iter;std::vector<Object*>::const_iterator end = gameObjects.end();for(iter = gameObjects.begin(); iter < end; iter++){    current = dynamic_cast<Actor*>(*iter);    if(current != NULL){   for(temp_iter = iter+1; temp_iter < end; temp_iter++){  target = dynamic_cast<Actor*>(*temp_iter);  if(target != NULL){ if(current->IsEnemy(target) && target->IsAttacking())current->LoseHP(target->AttackPower());  }  else{ target = dynamic_cast<Door*>(*temp_iter); if(target != NULL){target->Open(); }  }   }    }}Please note that I am not an expert in design and that it might be a very ugly design but I think it could work.   ;Quote:Original post by White ScorpionWell, I'd use polymorphism along with dynamic_cast<> to achieve this. If, for example, you derive a class 'Actor' and a class 'Door' from a base class 'Object' you can easily find if you should lose health or not:*** Source Snippet Removed ***Please note that I am not an expert in design and that it might be a very ugly design but I think it could work.i don't understand that partstd::vector<object*>::iteratorshould'nt it be std::vector<object*> iterator   ;  You're probably better off checking for attack collisions when you update the enemy thats attacking. Say they are swinging a sword, you can check that area against the bounding regions of nearby players and then notify relevant parties of hits. Trying to add checking for weapon hits to your collision detection routine sounds like it would be a bit messy.   ;  I agree with Bezben. My solution was way too much overhead.For your question on vectors: no this line's not wrong. 'iterator' is a typedef common to all STL containers that is accessible through the '::' operator; therefore, it's a type and not a variable name.   ;  you can create three vectors/dynamic arrays one for the eneimes ,one for the player ,one for the enviroment then loop throught the first to test for collison with the second and the third then do the same for the next two arrays and to speed things up calculate the radius of the bounding box then test for any models only inside that radius and if you dont want to use polymorphism or inhertince you can put a field for special value in the model class to identify which is a door , weapon , bonus etc..   ;Quote:Original post by White ScorpionWell, I'd use polymorphism along with dynamic_cast<> to achieve this. If, for example, you derive a class 'Actor' and a class 'Door' from a base class 'Object' you can easily find if you should lose health or not:*** Source Snippet Removed ***Please note that I am not an expert in design and that it might be a very ugly design but I think it could work.My post is somewhat offtopic - I apologize to the original poster.@White Scorpion: I have a couple of remarks on your codeas you notice, it is rather poor design. Using dynamic_cast<> to test the type of a variable as you did is a typical break of the open-closed principle, which states that a software should be opened to extension, yet closed to modification. In your example, you can't extend the code without modifying it. As a consequence, such kind of code is a good candidate for maintenance nightmare [smile]. There are other alternatives that will work better (double dispatch and the closely related  visitor pattern).Since you are using a vector, you can use the [] operator - instead of iterators. It will make the code easier to read.if you really want to use iterators: post-incrementing operator works, but it should be avoided when unneeded. Post-incrementation copies the variable, increment it and then returns the copy. Pre-incrementation increments the variable then returns the incremented value. Using pre-inc, you will avoid a temporary copy, and since you never use the return value of the (post/pre)-increment operator, you don't care if it is a post or a pre-increment.Regards,   