See also: Dependency Inversion Principle
As described in that link, many game engines will provide and implement abstract interfaces. You program against the abstract interface. If you need something that does something, you search based on the abstract interface.
For an example, one major game I worked on, the concrete GameObject class derived from the IGameObject interface. You would not search for a GameObject, you would search for an IGameObject.
Doors and bridges and other portals implemented IHasPortal. It would be a very bad idea to try to search for a concrete instance because there were many classes of things that implemented IHasPortal. There were bi-directional doors and one-way gates and assorted kinds of bridges, drawbridges that could be opened and closed, and downloaded content meant new classes could be added that you would never know about. But if you always searched for objects implementing IHasPortal, you would get anything and everything.
We had quite a lot of them in the code base. IDetonatable, IStoreFront, INotCloneable, and so on.
Use a dynamic_cast and if it returns NULL, it doesn't implement the type. Be a tiny bit wary of using dynamic_cast. On many systems it is very nearly zero-cost, on other systems it has quite a high cost, plus it also depends on if you are searching up the inheritance tree or down it. If you are on one of those systems where dynamic_cast has a high cost, there are tricks you can use with type_id instead. GCC implements dynamic_cast so casting to the base class is optimized to basically the cost of a single pointer indirection, and since the interfaces are base classes, it is practically free.
When you are properly using inheritance you very rarely need to cast that way. The entire point of deriving from a base class is that code that uses it should never know what class is involved.