I've spent the past few weeks on-and-off building a new framework for myself. Having done this a couple of times now, I figured I would impart some unsolicited advice.
Before you embark on what can be a long and arduous journey, consider if you really have to build a framework. There are plenty of great ones out there. I've had positive experiences with openFrameworks, GLFW and SDL. They may do exactly what you need.
But they may not. A few good reasons for writing your own framework are:
Taking control of your technology/destiny. At the end of the day, the core experience of your videogame depends on the underlying technology. It's important to get it right.
You need more under-the-hood control than existing frameworks expose.
Responding to new technology. While Windows and Mac are fairly stable, iOS (and mobile in general) is evolving and fast-moving. Understanding how everything works allows you to implement these technologies quickly.
Existing frameworks do not fit your mental model.
Even if you decide to roll your own framework, I'd recommend trying existing solutions first. At the very least you'll pick up some design tips. At best, you may find they do exactly what you need.
This sounds counterintuitive, but there's underlying code that might be worth taking. How much is a personal preference. I've been all over trying low- and high-level frameworks. The journey helped me figure out what I wanted done for me, and what I wanted to do myself. Identify the areas you really care about and focus on those. "Outsource" the rest.
Efficient rendering stack. Most frameworks focus on either giving you low-level access, or high-level (but inefficient) APIs. I wrote a high-level API that is efficient if you understand the implementation. To me, it feels like the best of both worlds. But this is the kind of (potentially) esoteric API that general-use frameworks shy away from.
Reusable game code. The essentials, like entities moving around a world with collision and basic pathfinding. I also collect (mostly math related) odds and ends. Look through your older projects for helper code. Pick out the functions that are useful and reusable.
Helper libraries for loading textures and fonts. For the former I used libpng. For the latter I'm working on a tool to bake a texture offline.
Speaking of which: tools! The best thing I did was write new_project, which generates a new project based on a template. Writing tools to make the idea-to-prototype transition easier is well worth the effort.
A more robust iOS experience. Most frameworks treat iOS as a peer to the desktop OSes, but it's very unique. I may not achieve full compatibility between iOS and Windows/Mac, but iOS projects will take advantage of UIKit, gestures, multitasking, and whatever else Apple introduces in the future.
As above, I focused on providing a great experience on a limited number of platforms: just Windows, Mac and iOS.
These are all personal preferences I've figured out over the years. You'll figure out what your focus is too.
As you go along, your framework will evolve. You want to ensure that your older projects continue to work as your framework blazes ahead. My approach is to version the framework (using a simple folder structure), and allow each project to select a version to build against. This allows me to "go forth and break things", without worrying about older projects.
Building a framework is a learning experience. With every iteration I've done a better job. Keep working with a framework until you feel you've outgrown it, and then do it all over again.
But don't make it a frequent thing. I've only done this four times over the past nine or so years. And don't forget that old code can still be good. Most of Zucchini is based on Chickpea's source code.
Finally, remember: do this because you need to. Don't get caught up in the trap of making the "ultimate" framework. Build a framework to make better workflows for yourself, and of course, to make incredible videogames.