Creating a re-usable FrameworkThe main concept in creating a framework you can use for multiple projects is to distinguish between game specific code(most likely in the form of gameplay related behaviors/systems) and generic systems that have nothing to do with the actual form game itself takes.
As you can see, our framework contains all the code we would use regardless of the type of game we are making. It has handles basic functionality like rendering API calls, entity management, random utilities like random number generators, and anything else any type of game may need. All this functionality is compiled as a DLL or static library (I tend to prefer static libraries myself as they help avoid DLL hell). Once your game links against the library, the game then can access all our frameworks functionality as needed and implement any game specific classes/systems to as required. So, while your framework might contain an abstract interface class for entities (let's call it IEntity), the game itself would create any game specific classes (let's say a RaceCar for a race game, and ShooterGuy for an FPS) that simply inherit from IEntity. The framework's management system will handle those objects just fine(it already knows about IEntity and works within that interface) and your game gets to use a reliable system that you're familiar with without having to write more than a handful of lines of code. So while you'll still have to write the system the first time, once you've paid that cost it's done. No matter how many games you create, you can re-use that existing code greatly speeding up your development all because you took a few moments to organize your systems properly.
Now the only caveat with a re-usable framework, especially if you are working on multiple projects at once, is that you be very careful you don't put (or remove) anything that another game may be using(or could cause instability). Remember, this framework is linked to by... well, all the projects you link it to. Imagine you have 3 guys at a buffet. Guy A and B love potatoes and keep going to fill up their plate with them. Guy C just doesn't feel like potatoes so he removes them. Guy A and B are going to be pissed. So, leave the potatoes, even if you don't need them right this minute.
Setting Up/Statically Linking against your Framework (Quick Tutorial)
If you've never created a static library before, here's a quick tutorial. It's very easy but I figure it's better to be thorough than make assumptions. Quick note, I'm using Visual Studio 2010 Pro Edition, but this setup hasn't change since... well, a long time (I seem to remember 6.0 still working like this) so it should be fine for 2005 through 2012 and onwards. As always, see your IDE documentation, the MSDN, or Google if you have any questions for your specific version.
- Create a new Solution / Project. Name it whatever you want. I'll use Framework just to be consistent with what I've written on this post.
- Right click on your Project in the Solution Explorer and select "Properties".
- You're going to want to set the "Configuration" drop down to "All Configurations" instead of just "Active (...)".
- Set your "Configuration Type" to "Static Library" and hit Ok! Build and you should now have "(yourProjectName).lib" in the respective Debug/Release directory.
- Create a new Solution / Project for your game.
- Open the Properties for your game and add the directory your framework library was outputted to your list of library directories. You also want to point the linker to where you are keeping you're header files for your framework.
- Link to your library and start coding away!
P.S. The image at the top of this blog is from Game Dev Story, check it out on iOS/Android if you haven't already.