   Alternatives to My Design
  I have a base game engine that I've been using and modifying for a while now, but I want to redesign it a bit to make it even simpler to create a new game from it.The design I'm envisioning would work something like this (and yes, I know there are flaws and that's why I came here :-) )Here's the basic idea. The main Engine class would contain a list of Entity objects which would be the base class for anything in the game world. Each entity would be updated in the main loop and would have access to the other entities in the world. This seems like a good plan to me because all the entities in the world know where to find each other because there is only one collection. But, that brings me to the problem of not knowing exactly what type of entity it is.The way I've handled this in the past is by down-casting and checking for what derived type the object is (for example, if the entity is an enemy, inflict damage on the player, if it's a power up, enhance the player etc.) I've read that this is slow, especially if it's done in a loop. But, it's not just a matter of knowing the type, I also need to be able to access any new properties/methods it may have.I guess the goal of this whole design is to keep the game-specific code from touching the main loop. The Engine class would handle the loop and the entities would take care of themselves and each other.So, does anyone have a solution similar to this, but better? Or is this just a silly idea in the first place?Thanks!   
  One way could be to keep object interactions as generic as possible, i.e. define some virtual functions in the base class and have each object know as little as possible about the other entities directly.The engine would thus detect collision of two objects and both objects would be notified that they are colliding.This way, if the two objects collide, some generic function for this could be triggered on each of the two objects (or events are provided to the objects).Then each of the objects decides what has to be done accordingly.If a player collides with an item the item could request to be picked up while the player object does nothing. But it could also be the other way around withe player object taking care of picking it up. Either way, I think at some point this would involve a cast because the player needs to know which item is about to be picked up.However other interactions will work without downcasting this way, e.g. when the player object collides with an enemy unit: Both objects receive notification that they collide and based on virtual functions (like getDamageValue or similar) each object will decide what is going to happen.I am sure though that there are other solutions also, and I have been wondering about this particualr problem also. Other suggestions, anybody?   ;  I would recommend using separate containers for separate entity types. However, you might consider using more general entity types, i.e. instead of separate player and enemy types create an actor type and stick them in one container, static objects in another container, etc. Despite the fact that the idea of having an abstract base class for all entity types in the game is quite popular on gamedev, through my own experience I have found it to be a mess later on.   ;Quote:Original post by UphoreumThe way I've handled this in the past is by down-casting and checking for what derived type the object is... I've read that this is slow, especially if it's done in a loop. But, it's not just a matter of knowing the type, I also need to be able to access any new properties/methods it may have.On Visual Studio it involves a strcmp for some reason (something to do with comparing types across assembly boundaries).Lots of games use an enum for type.  But it isn't very elegeant, and really breaks the whole idea of a base class, since it has to know (and enumerate) the different derived classes.So one good compromise is to add a hash for the class type into the base class.  Deriving classes would fill in the hash value with its class type (hashing the class name makes the most sense probably).  There might be some way to move that hashing into the base class, I don't remember how robust the C++ real time reflection capabilities are.So when the class is created you have that extra overhead of hashing, but after that you can check for class types using a single integer compare.  There's a (remote) possibility of hash conflicts, but you should be able to check for that in a unit test.The downside here is that you're really only checking for equality between an instance of a base class and the different derived classes, which is a run time operation.  I can't think of a clean way to do the (compile time) cast you probably need to do at some point.Really this is the sort of thing C++ is terrible at.  C# has excellent run time reflection capabilities by comparison.   ;Quote:Really this is the sort of thing CPP is terrible at. C# has excellent run time reflection capabilities by comparison.Actually I am using C# for this part of the engine.Also, is using a hash much faster than just having a GetClass method that returns a string that I can compare? And in both cases I would need to downcast in order to actually access the new methods right?   ;  Just a tid bit of advice.Make an entity container, instantiate one of these in your engine, the engine should have no idea how to process or store entities, only that they need to be processed and stored.Also, there's nothing wrong with a GetClass method, just as long as it doesnt return a string.. It should return a unique id, likely an integer, that is specific to the class type.struct BaseObject{ virtual int GetType() = 0; virtual ~BaseObject();};struct ConcreteType : public BaseObject{  virtual int GetType() { return StaticGetType(); }  int StaticGetType()   {static int type = -1;if (type == -1) type = GenerateUniqueID();return type;  }};//simple usevoid FooAMonster(BaseObject *obj){  if (obj->GetType() == DragonMonster::StaticGetType())  {DragonMonster *mons = static_cast<DragonMonster*>(obj);mons->Foo();  }}That can be conviently implemented with macros.(I assume no responsibility for the use of my crappy code.)   ;  Thanks, this is basically what I'm talking about.Is downcasting like this something that is done a lot, or is it something that real professional wouldn't touch?   ;  Some days you just gotta lower your standards a bit :PIn all seriousness i think this kind of stuff is fine. Hell, even just using dynamic_cast is probably fine. There will be lots of other opportunities for optmization rather than this one.   ;  I must say I haven't used this a lot and neither recently, but some time ago we had this problem in a project, and I believe it was fixed by using typeid(). I didn't work a lot with it as somebody else in the team did most of this part, but I did work a bit on the code after this was implemented, and the result was more then fine, the game compiles and runs on both Windows and Linux and checking types works fine (it was for example used to count the number of enemies in the array of all world objects).   ;  I would argue that your enemies should be of the same c++ type as your non enemies. Just a generic actor object. The actor should have a GameFlags attribute, which could be used to indicate if this particular actor was an enemy.int CountEnemies(){  int enemies = 0;  std::vector<Entity*>::iterator it;  for (it = ents.begin(); ents.end(); ++it)    if (it->GameFlags & ENEMY_GAME_FLAG) ++enemies;  return enemies;}