Some unrelated points:

* Casting is usually a sign of a mismatch between your code design and your inheritance hierarchy

* Are you sure a player "is-a" tile?

One alternative implementation is that a tile has a pointer to any player that happen's to occupy it, or nullptr if there is no such player. Alternative implementations might decouple the player from the tile by just storing the tile index that the player is "on" (assuming your game has a tile based map that the player moves across).

The need to cast to a subclass type arises all the time in well-designed architectures. Please stop it with the scaremongering about downcasting being a symptom of bad design. It's not. If you want to eliminate it everywhere, then your code is going to turn to shit because you'll be jumping through all kinds of unnecessary hoops like adding lots of virtual functions to do simple things.

As a basic example, consider a GUI system in which there is a class hierarchy of widgets. Suppose there is a resource format of some kind that stores all the widgets for a dialog box, and suppose that when it's loaded, the widgets of the appropriate subclasses (TextWidget, ButtonWidget, MenuWidget, etc.) are created and stored in a tree representing the layout of the dialog. Now some code is going to load that resource and want to access particular widgets as their specific subclass types, e.g., to change the content of a TextWidget to the user's name or enable/disable a ButtonWidget depending on some condition. However, the function that locates those particular widgets (perhaps by name or some kind of ID number) after the dialog is loaded will always return a pointer to the Widget base class. Knowing what the widget's actual subclass type must be, your program will then use static_cast to change a Widget * into a pointer to a TextWidget *, ButtonWidget *, etc., so it can call the functions specific to those subclasses. There's nothing wrong with this.