I'm not really sure what the OP is actually asking for, so I'll tap away and if anything makes sense, take note, and if it doesn't apply you can ignore it.
You can make a game which can repeat a deterministic path each time[1]. Much as per DF world history and geology generation, start it off with a seed for a pseudo-random number generator. Could be as simple as a hashing algorithm taking the last result (or seed, if there was none) and outputting a new result.
At each decision time, the PRNG rolls out a new number. Identical every time. Of course, the player could 'trick' it if they got a handle on how it works, so that instead of something like entering a cave, trying to hit monster (fails) and trying to hit monster again (wins), and losing some HP in the process, they could re-run the situation and this time search for treasure (fails), enter a cave, try to hit monster (wins), with no loss of HP.
The most trivial way of avoiding this is to make each action query the PRNG, or otherwise manipulate it, or poke it, with an 'encounter number', thus disrupting the predictability. A game's designer could even exploit this fact to ensure that a particular path through a segment (over which they must control the entry point of the PRNG, perhaps by re-seeding it) has an idealised route that works well in a particular manner (not easily discoverable even by decompiling) by poking in values that support said path. Of course, if that particular entry-point does not have a limitation on how the PRNG is initially configured, it'll only work when the lead-up is as the designer intended (and tested for).
For an actual varied plotline, even with the same intention, let go of the control of the PRNG. Indeed, most inbuilt randomising functions will self-initialise with something like current setting of the clock or (if there's not something like that available) the time passed since the program started which (if the player has to "Press Enter to Start" prior to the PRNG first being called/initialised) has a distinct degree of variance.
And if, despite all the above, the whole point is that essentially have a "Roll a D20 to see how much defence you have for an attack, but roll a 20 and you survive anything, even a nuclear bomb" situation, then the answer is not to have super-save rolls in the first place. Or reduce the likelihood down to the odds you're actually expect for the nuclear bomb not to explode. (In dragon terms, it might have tripped up just as it was about to lunge at you or something.)
Does that help? Not sure.
[1] When I was first introduced to a higher-level programming language, the first practical graphics program was a "fly this space-ship through a random cave system". The cave ceiling and floor undulations were dictated to by a rnd() call of whatever kind that language had, and yet cave 1 always looked the same, cave 2 always looked the same, cave 3 also... etc, etc, etc. Then I realised that the "srand()" equivalent function was obviously being seeded exactly the same every time. Among many 'improvements' I made (along with changing the characteristics of the space-ship so it was thrust upwards and thrust downwards, rather than go upwards and downwards, meaning it was now a second order (and, later, for fun, third order) derivative motion on the y-axis) was making it seed more randomly. But whereas the original version was a level playing field (the level 6 cave might be the one that always arises with a very tricky pinch, which together with an asymptotic narrowing of each successive cave meant it was a reasonably easy manner to know that getting further meant you were better at it), it was now quite possible for the first cave to have a bad pinch to ruin the player's day right from the start, and no guarantee that someone else got co-operatively easy caves from shear randomness (albeit that they still narrowed down, to the limit of the space-ship's actual height where perfect play was needed even on a forgiving cave).