: Just for shits and giggles, this is my API in its current state
I think the best approach is not only something that is abstract enough, but extensible
. It has to be easy to customize objects to work in various circumstances. For example, it has to be easy for the framework to be extended to deal with new data structures. Or, in my case (NES), my aim is to make it easy to extend my ROM class by implementing a specific mapper so you don't have to wrestle with pointers.
As far as feasibility, I know that I already have something that I could easily use over and over again to make my life much easier. Would others use it? Probably not, but I could at least post it as some very useful example code others can learn from. If you really want to make it cross platform, that brings us back to extensibility. In your tiles example, rather than programming support for every kind of tile, make it easy to program support for additional types of tiles. The design would need to be very carefully considered, but very doable. If one took this approach, then community would be an important aspect of it. Only one person needs to write code to handle SNES tiles. He can then share it with the community, and everyone can plug it into the framework. With that kind of approach, there is real potential for an incredibly expansive and highly flexible framework.
Even if it was the most awesome framework in the world that could handle 99,99% of all games, barely anyone would use it. The problem is: romhackers love to redesign the wheel. You have to hit most of them over the head with a wrench to get them to use other people's libraries/code. I don't know why this is either...
Hmm... I'm that way, I guess. Especially when it comes to rom hacking, I like to roll my own code instead of using someone else's code. Maybe it's like stroking my ego, proving to myself that I've mastered the material at every level. Or maybe I just want to know my program inside and out the same way I want to know the ROM I'm hacking inside and out.