Why don't they just pass the time into the RNG in order to randomize it instead of using fixed seeds?
Correlated randomness in Slay the Spire 2
21–30 of 92 posts
Re: Correlated randomness in Slay the Spire 2
#22Why don't they just pass the time into the RNG in order to randomize it instead of using fixed seeds?
Being able to share and replay seeds is a big part of the StS community.
Re: Correlated randomness in Slay the Spire 2
#23Earlier quoted context omitted.
The game stores and allows you to see the RNG seed that controls the run's events and layout. The developers want players to be able to share seeds that produce interesting runs. That requirement is what made this problem difficult for the devs to solve.
This shouldn't actually be difficult to solve though. The issue is that knowing the offset of seeds helps predict outputs. Instead of calling RNG(seed+hash(string)) 10x, make one RNG(seed) and call that 10 times to get random seeds for your 10 rngs. Now you have perfect determinism and no correlation.
My first solution was RNG(hash(seed.toString() + string)), which would get rid of the correlation while still being deterministic based on the seed.
It's also more robust than calling RNG 10 times since if you use the same algorithm to seed as for the RNG proper then you will get the same sequences in each instance, just offset.
Re: Correlated randomness in Slay the Spire 2
#24Why don't they just pass the time into the RNG in order to randomize it instead of using fixed seeds?
People often want to share their seeds so that players can play the same game they did. If there was an interesting series of results for example, which gave you a good set of cards.
Minecraft does this too with world generation for example.
Re: Correlated randomness in Slay the Spire 2
#25This is also the cause of the thing in Minecraft where you find surface clay, move X blocks over, and dig straight down into diamonds.
Re: Correlated randomness in Slay the Spire 2
#26I feel vindicated. I knew this game was bullshit and it couldn't possibly have been a skill issue.
Re: Correlated randomness in Slay the Spire 2
#27> Implementing a PRNG within the codebase instead of calling the C# standard library has an additional advantage: seeds are guaranteed to be the same on all platforms. In Spire 1, seeds on the desktop version of the game were different from seeds on the mobile version of the game, because the standard library implementation of PRNG differed between platforms. It is also worth mentioning that the standard library implementation might change over time, which would break all past seeds.
This is the correct conclusion - game developers should consider gameplay-relevant random generators part of their gameplay code rather than platform code.
Re: Correlated randomness in Slay the Spire 2
#28> the game used several distinct pseudorandom number generators, to prevent e.g. randomness within a combat from influencing future card rewards. Why is this important? Feels like fixing what seems to be a non-issue lead to a bunch of real issues. With a good RNG it should not be possible to predict future numbers based on past numbers so players cannot manipulate card rewards in their favour based on combat actions,…
For a singular seed, they wanted the resulting run to be stable in the sense that small deviations in decision making does not result in a vastly different result (as far as random events are concerned) Imagine the game of two players having the same state X. While combat, one player would trigger a random action, the other doesn't. After the combat, both should still get the same randomized reward options. This woul…
This is exactly it.
This way, you can see how e.g. players of different skill level navigate the "same" run (same seed), without everything diverging completely on the very first (meaninglessly small) combat choice.
Re: Correlated randomness in Slay the Spire 2
#29> Implementing a PRNG within the codebase instead of calling the C# standard library has an additional advantage: seeds are guaranteed to be the same on all platforms. In Spire 1, seeds on the desktop version of the game were different from seeds on the mobile version of the game, because the standard library implementation of PRNG differed between platforms. It is also worth mentioning that the standard library impl…
More than just that, procgen as a whole requires an entirely different level of vigilance to avoid nondeterminism creeping in if the game requires it to be reproducible. None of the inputs to the procgen algorithm can be allowed to even so much as brush up against code you aren't actively exerting complete control over, and care is required to avoid inadvertently encountering any platform specific hardware quirks.
Re: Correlated randomness in Slay the Spire 2
#30> Implementing a PRNG within the codebase instead of calling the C# standard library has an additional advantage: seeds are guaranteed to be the same on all platforms. In Spire 1, seeds on the desktop version of the game were different from seeds on the mobile version of the game, because the standard library implementation of PRNG differed between platforms. It is also worth mentioning that the standard library impl…
> It is also worth mentioning that the standard library implementation might change over time, which would break all past seeds.
If the stdLib changes and you need to use the same, then you're unfortunately going to be suck with porting the previous version into your own library. It's pretty forward thinking from the devs here, I would love to see my boss' face if I told him we need time to port some of the stdLib incase they update it in the future.
I had to check for my own curiosity, but it looks like the Random class has not been updated in 12 or so years. At least in the inital subset of framework to core.
https://github.com/microsoft/referencesource/commits/main/ms...