Saving/loading turned out to be negligible, possibly because I used a binary format instead of JSON.

The slowest part right now is actually generating the minimap level thumbnails, it only does this once and it doesn't cause any lag, in the future if I can be bothered I'll use a script to generate these as image files.

Most games have multiple save slots, I guess it's useful so multiple people can play on the same computer, but is it really that important?

It's not very immersive, and it's the very first thing you see when you start up the game.

I'd rather be immediately transported to the game world with some sort of animation.

I should post more screenshots of the game since it's been a very long time since I last did so.

A true puzzle game shouldn't have to worry about save versioning issues because I don't expect to be updating the levels.

Thus I am not going to bother manually assigning a unique ID to every unit and just use an incrementing ID.

For the sake of testing during development if the total number of units changes then I'll wipe the save file.

I think I'll autosave whenever the player changes areas.

I should be able to do this asynchronously and even let the player continue moving while the file is being written, it should be very fast because there isn't much data to save.

In the case where a player repeatedly switches areas possibly causing file lock issues I will just ignore the later saves because it doesn't matter anyway.

I have to be sure the player is never able to change areas after "getting stuck" to avoid softlocks, this may constrain level design slightly but I'm willing to make that sacrifice.

If I don't serialize and save the entire undo stack then the player can potentially softlock themselves.

I think I need to clear the undo stack in a new level or something rather than having the game be technically open world, but it's unelegant and makes one of the intended mechanics troublesome.