In the case of the game that spawned GameSaver, as I recall, the issue is not speed but size: I intend to have largish levels, with a fair few objects, each of which may have a fair bit of data within it. Given some of the complexity, I’ve ended up deciding that my “save games” are essentially snapshots of the levels, along with a few other pieces of data, bundled into multifiles.
I imagine that a more efficient mechanism could be devised – some means of saving and restoring only the changes to a level’s contents, but that doesn’t seem to me to be worth the extra work and testing that I suspect would be involved in getting such a system working.
Your API looks good to me, based on a quick look through. I’ll confess that I prefer not touching the file objects myself – one of the things that I like about GameSaver is that it handles pretty much everything bar some complexity in specifying data to be saved and in restoring some things. I also far prefer specifying which objects are included, rather than which are excluded. These are, however, likely just personal preference.
Overall I honestly don’t see much to choose between the two versions, although, perhaps just through familiarity, I’m inclined to prefer my own approach; I also prefer having somewhat-readable files, I think.
As to safety, it does look to me – especially given wezu’s example – that it’s easier to get malicious code via Pickle; given Python’s features I doubt that such dangers are likely to be excluded entirely, but it does look as though it may be a little more difficult – far from impossible, admittedly – for it to be done via GameSaver.
A minor update: I’ve added a small convenience class that wraps simple data (lists, tuples, dicts, etc.). The new version should be available from the same link as the previous, in the first post.
Nice work, @Thaumaturge !
A question: does it works well with Bullet physics? For instance, imagine you saving a game with a ball falling into floor. If you save only the ball’s position but not the forces (gravity) applied to it, when you reload the game the ball will start its fall with force zero instead of last force applied and thus its velocity will less than the paste velocity (before game be saved). I 'm looking for a game loading/saving code that take this in account.
1 Like
Thank you very much! 
As long as Bullet lets you set the appropriate forces, then I don’t see why it shouldn’t work: you could save the forces as Vec3s, and then set them on loading. (A few simple custom conversion methods would likely be called for in order to handle Vec3s–that’s what I generally do–but those are straightforward, I believe.)
All that said…
To start with, please note that the link in the first post isn’t working any more.
Now, I might replace that with a GitHub repository… but it’s been brought to my attention that GameSaver in its current form has a security issue. I do have plans to attend to this, but haven’t yet done so. As a result, I haven’t yet made the module once again available.
My apologies if this is troublesome! :/
I’ve just released a new version of GameSaver!
Perhaps the most salient change in this version is that is should–I hope–no longer hold the security vulnerability that was present in previous versions! In short, GameSaver no longer employs “exec” or “eval” in saving or loading! 
For a little more detail, see the first post! (Which I’ve updated.)
Furthemore, the module is now available via GitHub; the link is in the first post, but let me include it here too, for the sake of convenience: