The naive solution to create a "save anywhere" feature would be to simply take a snapshot of the whole game memory, dump it to a file and restore it later. When a game requires very little RAM, then that can actually be a viable strategy. Modern emulators for 90s consoles use this strategy successfully to implement quicksave and quickload which works in any game at any time, including games which never even had a savegame feature. But those consoles had RAM measured in kilobytes, which is trivial to handle on modern hardware.
Modern games, on the other hand, often use several GB of RAM. And don't forget all the data they are storing in the GPU RAM. So dumping the whole memory would result in savegames of the same size, which would mean really long saving and loading times. So when you want to do this well, then you need to differentiate between:
- Static data which can be loaded from the game files. Textures, models, audio files, (non-changing) level geometry etc. While this needs to be loaded from files anyway, there is no reason to store it redundantly in the savegame files.
- Transient data which does not need to be saved because losing it does not really matter. Like particle systems or other purely cosmetic features. Or lookup data structures which only exist for optimization purposes and can easily be restored.
- Data which actually matters for gameplay. Positions of entities, their velocities, hit points, AI state, animation state, inventories and so on.
Identifying which pieces of data fall into which category is not trivial. Which is why so many games have weird bugs which are triggered by saving and loading in specific situations.
For that reason it's a good idea to implement savegames relatively early in the development, consider with every new feature what data of that feature needs to be persisted in the savegames, implement the persistence together with each feature and only consider the feature "done" when it saves and loads correctly.
Yes, this is as much work as it sounds like. Which is why more and more games nowadays say "screw this, we only do fixed savepoints in situations where there is not much going on". This greatly minimizes the amount of data which needs to be persisted and restored and the number of edge-cases to consider which could lead to savegame-related bugs.
Implementing savegames retroactively can be a real pain. Even if you have access to the sourcecode. Creating a working savegame system as a mod for a game you did not make can be next to impossible.
