Yes, I actually use a hashing system in Minesweeper.
I wrote it purposely to test the plausibility of such a system.
I’ve tested it, and if you overwrite any part of the data block it uses, including the hash and the data length,
it recognises that its data has been corrupted, and informs the user that ‘no save slot was found’.
Thanks to the data length it’s also backwards and forwards compatible if you increase the save size in later releases,
because the game calculates the hash correctly and then (for an older game) doesn’t touch the newer data.
As long as you never change the meaning of any part of the data, it will stay compatible.
It’s a pretty cool system.
Some of the implementing code isn’t compliant with the C++ standard though,
so I need to fix that.
I know a very good way to fix it though.
If you make it the user’s job to hand the function a buffer then the user can pass in the screen buffer instead of allocating a new one on the stack,
which gives the function an instant 1024 bytes to work with,
which is the size of EEPROM itself.
(I really wish I’d thought of that when I first created it.)
I started designing something like this once I think,
but my notes will be buried under a pile of paper somewhere.
We could build one, but it would be a lot of effort.