As I was falling asleep last night, I had an idea for a setting. I'm not sure it would actually work for a game, but it hits some ideas I think people here are likely to be familiar with, so I'm going to write it down just for fun.
It's basically a village with a save/load option. There's this machine (is it fixed or mobile? Who controls access to it? The mayor? The village elder? A cult?) that has an option to freeze a point in time, and then can later revert to that point in time. Like save states in video game emulation. In thinking of it, though, I was trying to picture it from the perspective of what's actually going on inside the game/emulated system. When an old state is loaded, the current state ceases to exist entirely. In general (more about this related to filesystem work from my job later,) it doesn't seem like actors within the system could pass back information, either. I'm imagining some kind of a frontier or post-apocalyptic or otherwise disconnected settlement, faced with lots of potential troubles and catastrophe. I think that would be kind of needed to induce enough desperation for someone to decide to destroy their entire existence for the possibility that a different version of them could do better. Maybe nothing could induce that sort of desperation, but I'm picturing something like a child being killed in an accident, and a parent resetting reality, hoping the random number generator goes better this time, and willing to erase their existence on the chance that some version of the child might live.
It also makes me think about whether there's some indication the machine has been used. Does a light turn on when the state is reverted, so everyone knows that something bad happened(/will happen in the future)? Does that just cause them to make worse decisions out of paranoia and get all Greek tragedy-y? Most of this crystallized in the morning, but just now I thought instead of a light, how about a numerical indicator? Everyone in the town would know that they've all failed to stop some catastrophe five times already, and things would probably just get worse and more desperate. Logically (to me, of course) it would reset when you saved a new state, but maybe you can't do that immediately, so you can't just save-scum every decision? How often do you save? Daily? Hourly? If you only get one save, how far back do you want to plan to be able to go to avert a crisis? If you find out some catastrophe is coming, maybe you need more than an hour to prepare, but will a day or a week help if you don't know what's coming? When I say that, it feels like the indicator becomes important to making this a useful thing, rather than just an existential/random chance we'll do it better/save the kid from the RNG thing. Like on time loop episodes of star trek, when they realize they're in a time loop, but they still don't know how to break out. I guess the incremental display is probably just a riff on Data's card dealing.
The information passing bit reminded me of a thing we were doing at work with LVM. We wanted to snapshot the filesystem on a machine, run some tests that could do arbitrary things to the system, and then restore the snapshot so the machine would be clean. I ran into a couple of issues:
1. The snapshot is taken on a machine without a snapshot, so when you restore the snapshot, there isn't a snapshot there, because you took the snapshot before you took the snapshot. This seems like something that should be solvable, but the way I was doing it, I got tripped up on that.
2. Passing information back when you restore the machine is (nigh) impossible without external help of some sort. Restoring the snapshot undoes everything you've done since taking the snapshot, including the snapshot itself. I think maybe if we had a separate boot partition, we could hide something there, but we didn't.
All of this may well be solvable when you're not trying to restore an LVM snapshot to/from your mounted and running root filesystem, but that's what we were trying to do.