Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correlated randomness in Slay the Spire 2

tck.mn

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Correlated randomness in Slay the Spire 2

#71

Post by nimih »

Lalabadie wrote: post #40
jszymborski wrote: post #33

> The phenomenon of "correlated RNG" (or "CRNG") This is a pretty funny abbreviation since CRNG is sometimes "cryptographic random number generator", which would not be susceptible to this correlation. Albeit I think CSRNG is more common.

The criteria for calling a RNG "cryptographically secure" are incompatible with the game design goals here. The game needs a RNG that's stable when seeded, for reproducible runs. I look for the same kind of qualities when doing generative art. In comparison, a CSPRNG should be safe from oracle attacks, which is essentially the opposite goal.

Can you describe what you mean by "oracle attack" here? CSPRNG APIs (at least the ones I've used) usually expose ways to set a specific seed and serialize the RNG state. In fact, arguably the simplest possible CSPRNG, where you just run a (suitably strong) block cipher in counter mode, would seem to meet the requirements for game dev in a straightforward manner.

Re: Correlated randomness in Slay the Spire 2

#72

Post by passivegains »

jcalx wrote: post #54

Combining this article and discovery of an unwinnable seed in the original Slay the Spire [0] — I've always pondered the existence of some kind of "RNG hell", where a game uses the time as its random seed and, due to some quirk of the hashing function and the game mechanics, the game is rendered completely unwinnable for (say) four days straight. (Sometimes it feels like I'm in it!) [0] https://oohbleh.github.io/losi…

Putting this into my rotation of excuses. "It wasn't my fault! They were hacking, also my fingers were slippery and the deterministic behavior of psuedorandom number generators guaranteed we would lose anyway."

Re: Correlated randomness in Slay the Spire 2

#74

Post by nimih »

yccs27 wrote: post #3
xdertz wrote: post #2

> 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,…

I guess it's mainly a limit to savescumming.

It's in fact the opposite: an intentional design choice to make save scumming (edit: and by extension, sharing specific rng seeds) more effective for people who like doing it. They made a similar design choice with how save/restore works, in that it resets the current encounter, which allows players a limited ability to undo/backtrack if they make a mistake.

Re: Correlated randomness in Slay the Spire 2

#76

Post by dtech »

maxbond wrote: post #38
fc417fc802 wrote: post #29

Earlier quoted context omitted.

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.

What's burned me before is iterating over hash maps. B-tree maps (or hash maps that are guaranteed to iterate in insertion order, or any fixed order) are your friend.

I'm so happy most modern language stdlibs decided having a guaranteed order for maps and other collections is a good idea.

Although I can definitely respect Go's decision to always iterate over maps in a random order.

Re: Correlated randomness in Slay the Spire 2

#77

Post by ASalazarMX »

sltkr wrote: post #51

The post suggests replacing the linear congruential generator (LCG) with a permuted congruential generator (PCG). The latter has more random-looking output. Another solution is to switch to a cryptographic hash function. For example, using sha256(seed || event type || counter) only requires storing seeds and counters in the save game. This has several benefits: - You can find efficient implementations on all platform…

Sincerely blows my mind to see someone recommend cryptography to generate pseudorandom numbers. It speaks volumes of how fast computers are now, and how used we are to waste that power.

Slay the Spyre is a rogue deck builder, the PRNG of Windows Freecell (3.11) would be good enough for it.

Edit: From https://github.com/joshuamkite/freecell

> Microsoft FreeCell RNG Algorithm: Uses seeded random number generator (seed = (seed * 214013 + 2531011) & 0x7FFFFFFF) for reproducible deals (games numbered 1-1,000,000)

Re: Correlated randomness in Slay the Spire 2

#79

Post by ufo »

antitoi wrote: post #63

I don't understand the motivation for using multiple RNGs in the first place. If the game had one global, seed-able source of randomness, would this problem just disappear?

They want two players with the same seed to have a similar gameplay experience in terms of challenges encountered.

For this reason they want to isolate the RNG that procedurally generates maps, card rewards, shop contents, from other RNG streams such as the RNG used by random enemy attacks in battles, random event outcomes, etc.

One example of the wonky things that are possible when there is a single RNG stream is speedrunners manipulate the RNG state. For example, in Super Mario 64 they can jump in place to produce dust clouds that advance the RNG state until it is in a favorable position.

https://www.youtube.com/watch?v=MiuLeTE2MeQ&t=476

Re: Correlated randomness in Slay the Spire 2

#80

Post by ufo »

zemo wrote: post #53
xdertz wrote: post #2

> 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,…

> 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, right? I think you're overlooking the distinction between seeded and unseeded runs. An unseeded run is a run in which the player enters the game not knowing what the seed of the RNG is and not being able to pick it (this is the default mode). A…

One important kind of seeded run are the daily challenges, where everyone gets the same seed once a day (like Wordle)
Post reply on HN