if your making in any game make system is hell I redoing my game, I'm in hell but you have to do what you need to do :(
The problem with save systems really isn't finding a place where you can save your game state, it's putting your game data into a form that *can* be saved (i.e. serialization & deserialization). And even then, the problem is not so much the low-level serialization itself (most game engines have support for JSON, BSON or something similar) but determining what parts of your state need to be saved and what parts don't, reinflating the saved data into a functional game state, making sure that savegames from previous versions can still be loaded, and testing the whole thing, because forgetting to save something that needs saving can result in profoundly weird bugs that are extremely hard to track down.
It's sometimes a difficult decision, what to save a what not. In my last game I actually implemented two different types of save: One save that only saves the map (so that the player can try the same map again from the start) and one save that saves the map and the player's progress and the player position.
Since there might be the risk of exploits - before the player does something risky he'd rather save the game and reload it if things didn't go well - I think it is acceptable if the player doesn't get back to the exact game state where he was when saving but at a point shortly before. This way the exploit isn't for free.
The good thing about saving systems: If done well (modular) parts can be reused for any game you make in the future.
The difficult thing about save systems is that they affect all other parts of your game architecture. If you don't design with saving in mind from the start, you are going to run into a dead end.
For example, coroutines are good tool for structuring game logic that runs over extended periods of time, like scripted scenes for example. If you haven't used them before, coroutines are basically functions that can be suspended and resumed later. I like coroutines. The problem is that in most programming languages that support coroutines, there is no way to save the state of a coroutine. So if you've got a coroutine running and you save the game and quit, there is no way to resume the coroutine when the game is loaded. If the coroutine was doing something important, this breaks the game.
For my previous project, I had to write my own scripting language in order to get coroutines whose state can be saved and restored. It was fun to program and definitely worth it, but it was also a lot more work than simply integrating an off-the-shelf scripting language. And in this case I knew ahead of time that I would need my own scripting language to get what I wanted. I didn't have to rewrite anything because I knew the issues I would face ahead of time.
If I had the game using Python coroutines for scripting, for example, I would have had to dump all of that work and start over when it came time to write the save system. And that would have been hell.