Today I've been working through what will and won't be part of the "Framework".
That is, what values and settings and functions should be "Framework", which should be "Engine" and which should be "The Game".
-=-=-

For those not keeping track, the "Engine" is what I count as the bottom-most C++'y layer of my code, which takes commands and passes them to target-specific functions. For example, if I type Debug("Error Message"); then the Engine is the part of my .cpp code that decides what the best method to output that debug message would be. Whether to the command line in Windows, or to XCode's output console when running on an iPhing.
Similarly loading images and deciding how to draw them, is again handled by the "Engine".

The Framework sits on top of that, and handles things like Load/Saving of scoreboards and settings, managing where in the menu system we are, as well as dealing with switching to Fullscreen and other basic menu'y things that I won't have to re-write each and every week.

I've just spent the past hour or so working on the Load/Save functions.
As you can imagine, not having a complete framework, nor any idea what kinds of games will be popping up during the next era of AGameAWeek, the Load/Save functions have to be as generic and easy to tweak as they can be.
I was intending to have a global (for all games using the framework) "Settings.ini" file that the player could tweak for things like Fullscreen resolution and whatnot, but the fact that I'm not sure what future additions might be added to the engine, makes that incredibly difficult to manage.
Imagine that on Game #8, I decide to add an ini value for Invert Controller, but Games 1->7 don't support that setting. It'd mean that each time you load Game #8, after having played Games 1->7, it'd have lost that setting, since the earlier games don't know to save that setting back out again.

Instead, then, I've settled for a single .sav file, crammed full of numbers! It's not tweakable, but it should at least be able to keep your settings through all future games, since the engine simply loads and saves the array of numbers, whether it knows what they mean or not!

As well as that is a Save_###.sav file, which will hold that specific game's scoreboards and other per-game settings that need to be saved.

By doing it this way, with two distinct files, I'm hoping to future proof any further games, so that players can bundle the games together, should they want to store them all in a single directory, but also that (for example) changing the music volume on one game will change it on the others, too. Same for control settings and things like that.
It *should* work out that way, as long as I remember to keep track of what all those values are used for, and don't mistakenly start overwriting values!

I can't really test that the load/save functions are fully working, until I have a proper test game that stresses things. But for now it is at least outputting a couple of .sav files, and they look fairly functional.
Settings.sav is a simple 100-Integer, 400 bytes, whilst Save_550_Test_Game.sav is 81Kb in size, holding another 100 "local" setting values, alongside what is hopefully enough data for hundreds of Scoreboards or unlocks, or other such stuff. (I have a knack for improvising when it comes to arrays of values!)

Now I just need to add checksums and things to ensure the values are locked tightly, as well as double-checking that the values can be loaded back again.