with the key exception of adding a select clause for each class you need the game to update in the tGame Run method
This shouldn't go in tGame. Run() should call GameObjectUpdate() which would have a Select clause for dispatching to the correct GameObject (sub)class's update function. If it has to do with GameObjects, it should be in the GameObject class!
so you would simply add a new a new tGameObject, and then in its Create() method, i would assign the sub class name... "PLAYER2"
Atrocious. You're going to have serious coupling between Player and Player2/PlayerAux. Either they will both share a lot of the same code, or they'll both call the same function (in which case it was pointless to make them two separate (sub)classes.)
Harmful architecture like this is precisely what you're going to run into when you try to create a framework that is too generic. You just don't see it yet...
as i see it you've got the game engine tied to closely to the type of game you are making... in your design, how would i make a game with no map...
In your design, how would I make a game with no player?
and if you think it already has failed, copy and paste the code, and see how easy it is to create an object...
You won't be able to see if your framework fails until it gets used in a complex project.