It is so rare that it is I making posts . But I've been wondering about this for a long time, and I've never quite found the kind of solution I am looking for. Note the code below:

Now the game engine can treat all game objects on this level, and it does all collision detection on this level. The problem is the actions that an object must take.

Let's consider a Bullet hitting a Tank. The Bullet wants to dissapear from the game and die (in my game engines, this means it will set a flag so that it returns true from its next update call), and the Tank wants to get hurt.

This can be done from either side, but the question is where do I put and how do I call Tank's specific code for getting hurt or Bullet's specific code for dying, since the Tank might do different things depending on which way it hits.

There's several methods of doing this. What I've done so far is be lucky enough to have only several categories of objects that matter, like bullets, tanks, and unhurtable objects (terrain things), which makes a "getType" method easy to use an RTTI type solution.

With this getType method I can then use conditionals in the doCollision method. There are several techniques. I could have the Bullet detect the type of thing it hits, and if it is a Tank, cast the Entity& to a Tank& can call "damageTank( myDamage )" from the Bullet. You likewise do it from the Tank side and detect that the colliding Entity is a Bullet, cast it, and do a "life -= bullet.getDamage();"

The question I have is there a better method of doing this than using RTTI? How do you handle this in your games?

Heh that's cool. I've been using a very similar system with Entity in all of my games since I started with Allegro 3 in 1998. I have had other methods from time to time like load and save for save game files, and input to do input. I don't have a virtual input method anymore because I've found better ways to do input, by using Controller objects. The problem with an input method is that the logic to do input is in the specific class. With a Controller object, it changes the structure so I can control any object (not just players) much more easily, so I can have a KeyboardController and a JoystickController and an AIController and a NetworkController etc...

But I guess the RTTI-type method is the best way to do it. Not much else one can do since somewhere logically you must determine what you hit. I need to start experimenting with dynamic_cast and such. I haven't learned the real RTTI well enough until after I started my last games.

23, can you answer my question about the subclassing with C++ RTTI? Typically what I have is like a Tank class and then a subclass of Tank for each specific tank usually with the only difference of the draw method and maybe initialization for different stats of tanks, but I want to treat the objects as Tank objects and not HighTechHumanTank or whatever.

It didn't answer my question but the friendly people in #C++ on EFNet were helpful. My question was (given your hierarchy) was if you had a CGameBase* that pointed to a CGoblin, if I could try to cast it to a CEnemy* and treat it like a CEnemy w/o knowing that it's really a subclass of CEnemy.

Here is the class heirarchy I use though that I might create for a game with sailing ships:

Entity
|-MovingEntity
| |-Ship
|   |-SpecificShip
|-StillEntity
  |-BigRock

The Entity/MovingEntity/StillEntity are the base I use. An Entity has a rectangle, and a MovingEntity adds to that a vector. The MovingEntity's update will move the rectangle throughout the game world, hence my updates are chained -- SpecificShip::update will call Ship's update which calls MovingEntity's update.

edit: ya I forgot to tell you what the answer was. If you use dynamic_cast it works if the thing you are casting to is that thing or a subclass:

dynamic_cast<CEnemy*>( obj ) works for CEnemy or CGoblin or the others.

If you use typeid, then it's only an exact match:

if ( typeid( obj ) == typeid( CEnemy ) ) works only if obj is a CEnemy and not a CGoblin.