I'd try a composition-based approach at compile time rather than trying to build an über generic runtime framework. The problem with the direction you're going in is that it's primarily data based and you lose the nice sematic benefits of OOP. Now, if your particular implementation won't win anything from polymorphism then the road you're on might be the right one. However, from your description, I'd say there's a lot to be gained from a reified domain model.
Here's what I'd do:
1. Build a concrete, reified model for your first game.
2. After the game works, refactor any common classes and other functionality "up the tree".
3. Move the generic base classes into their own module.
And, finally, if you really want super composition:
4. Break reusable subclasses off into their own modules so you can quickly recompose them into new projects. For example: You might break off an TDarkKnight subclass into its own module so you could reuse it in the future for another game.
Hope this helps.
Here's what I'd do:
1. Build a concrete, reified model for your first game.
2. After the game works, refactor any common classes and other functionality "up the tree".
3. Move the generic base classes into their own module.
And, finally, if you really want super composition:
4. Break reusable subclasses off into their own modules so you can quickly recompose them into new projects. For example: You might break off an TDarkKnight subclass into its own module so you could reuse it in the future for another game.
Hope this helps.