I understand why people want the feature and I agree it’s amazing but the reason lots of games don’t is it requires the serialization of basically everything in the game and that can be a nightmare if you’re making lots of big changes to the game throughout development. You have you go back and rework your save code every time you change anything.

And while it can be done with most major engines with plugins, it you’re creating your own structures/object types etc, you need to extend that plugin to support them (and update that code every time you make changes to the structures).

Games that have a daily tick e.g. Stardew only need to store a set of initialisation values that are used to begin the day since no other changes would be made to state yet (since the player hasn’t made any that day). Or checkpoints where you serialise player state, quest state, etc, with enemy location etc ignored and respawned as default the next time you play.

Think of it this way. If an enemy spawns in a default location, that doesn’t need to be serialised if you load a game from a checkpoint. But if you can save anywhere? Well then you need to know the enemies, their positions, their vectors, their AI state (alerted etc), their velocity, their position in the animation timeline, and potentially so so much more.

And what about multiplayer? That’s additional players and their state and surroundings etc that need to be serialised and reserialised at load successfully.

It’s a lot easier if you don’t have to serialise the state of a huge number of things for saving and maintaining that saving code every time you make changes. It’s not impossible, and if you build with the feature in mind, it can be made manageable to maintain.

But if that feature isn’t essential to your game, and you’ve an acceptable alternative, it frees you up to work on other features instead.

It’s a balancing act. And for a solo developer like that of Stardew, I can completely forgive them for not wanting to implement it.