Save-proof randomness

[Kinsman]

Did you know that if you save and then load a Ren'Py game, the random generator changes internally, and you'd get different numbers than you would if you didn't save and load? This will happen even if you use renpy.random.seed() to guarantee a certain sequence.

If you don't want that to happen; for instance, if you want to keep the player from savescumming an RPG scene or minigame - then use the code below.

It changes how renpy.random behaves slightly. Your Ren'Py game will continually save the internal state of the random engine as a game variable, so that it can survive a save/load cycle.

Edit: Made an update to include the seed() function.

Code: Select all

# options.rpy is a good place for this code
init python:

    _oldrandom = renpy.random.random
    _oldseed = renpy.random.seed
   
    renpy.random.seed(0)
    _globalrandstate = renpy.random.getstate()
    
    def _newrandom():
        global _globalrandstate
       
        renpy.random.setstate(_globalrandstate)
        rv = _oldrandom()
        _globalrandstate = renpy.random.getstate()
       
        return rv
        
    def _newseed(value):
        global _globalrandstate
            
        renpy.random.setstate(_globalrandstate)
        _oldseed(value)
        _globalrandstate = renpy.random.getstate()
   
    renpy.random.random = _newrandom
    renpy.random.seed = _newseed

[xela]

I couldn't get your code to work. Calling renpy.random.random() still generated new random every time I've loaded the game.

This will prevent save/load exploits that were based on random generation while still generating new sequence and therefor new gaming experience on every gamestart:

Code: Select all

label start:
    $ _seed = renpy.random.random()
    $ renpy.random.seed(_seed)

label after_load:
    $ renpy.random.seed(_seed)  

Not entirely sure that this is a cookbook material.

[Kinsman]

I couldn't get your code to work. Calling renpy.random.random() still generated new random every time I've loaded the game.

Well, making sure you've set the seed is always important if you want predictable and repeatable random numbers.

This example script should help give you an idea of what the code is for.

Code: Select all

# The game starts here.
label start:

    "Let's test randomness."

    # Example seed
    $renpy.random.seed(0)
    
    # Ten random rolls
    $i = 1
    while i <= 10:
        $die6 = renpy.random.randint(1,6)
        "Roll #[i] was [die6]."
        $i += 1

    return

If you run this code a few times, you should get a sense of what numbers it's going to generate. But if you interrupt the run halfway through, either with a save/load cycle or using Shift+R, you'll end up with different numbers, since the state of the random generator changes with a new load.

If you then install the code above, and try it again, you'll find that the numbers remain the same when you do a save/load halfway through.

But yes, if you didn't include the seed() statement in the script, you're always going to get random numbers with each new run, since Ren'Py will use your computer's clock as a seed number when the game starts.

This will prevent save/load exploits that were based on random generation while still generating new sequence and therefor new gaming experience on every gamestart:

Code: Select all

label start:
    $ _seed = renpy.random.random()
    $ renpy.random.seed(_seed)

label after_load:
    $ renpy.random.seed(_seed)  

That code's got a problem, though - when you reload the game, the first rolls right afterwards are always going to be the same throughout the game's run, since you've gone back to the beginning of the seed's sequence.

Not entirely sure that this is a cookbook material.

I'll need to add some lines so that the seed function is protected in the same way as the random function. That way, a user doesn't have to remember to set the seed themselves.

[xela]

My bad and you're right, I should have caught that...

I wanted to implement something like this in my game. Trouble is that your code or two or three variations of it that I've tried, kill after_load label (I really need that as well).

Even if after_load label looks like this:

Code: Select all

label after_load:
    $ pass

game will only load to the beginning of start label. I have no clue why

Maybe I'll figure it out when I have more time to tinker with this. Or just use lists of pregenerated randoms and pop from them like I've originally planned.

In any case, well done

[Kinsman]

Make sure you put a 'return' at the end of your after_load code, so that Ren'Py knows to go back to where you saved from.

[KimiYoriBaka]

if you want to keep the player from savescumming an RPG scene or minigame

while I can understand using this type of code if you want to set up a different course for your story each play-through or something, the reasons you mentioned are actually really bad. I would advise against that type of design, as it will often give the player the feeling as if the game is pre-set against them. remember that the times when a player needs to reload are generally when they're losing, and if the same thing happens again after they reload that means the numbers they thought were supposed to be random suddenly are giving far more bad results.

[Kinsman]

That's fair enough. When I made this code, I had some very specific reasons for it (that actually is related to story-based randomness) but I shrugged when it came to writing more general reasons why anyone would want it.

I figure anyone who's going to use this code will be someone specifically looking for it.

[xela]

Make sure you put a 'return' at the end of your after_load code, so that Ren'Py knows to go back to where you saved from.

Thanks you, works purrrfect now

I narrowed it down to this (since I'll be using after_load anyway):

Code: Select all

init python:

    _oldrandom = renpy.random.random
   
    def _newrandom():
        global _state
        
        rv = _oldrandom()
        _state = renpy.random.getstate()
        
        return rv
       
    renpy.random.random = _newrandom
    
label after_load:
    $ renpy.random.setstate(_state)
    return

label start:
    $ renpy.random.seed(_oldrandom())

actually really bad

It actually isn't. In Civ5, you are simply given a choice at game start, if you wrap the whole thing in a function with an "if" in-front of it: player has a choice. In Civ5 many consider enabling random seed a form of cheating (similar to summoning nuclear bot to stoneage). There is no general rule here, it's a preference of developer and player if given the choice...