Live data from Hacker News

Correlated randomness in Slay the Spire 2

tck.mn

1–10 of 92 posts

Re: Correlated randomness in Slay the Spire 2

#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, right?

Re: Correlated randomness in Slay the Spire 2

#3
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.

Re: Correlated randomness in Slay the Spire 2

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

For things like daily runs / seeded runs part of the fun is getting the same card rewards.

Re: Correlated randomness in Slay the Spire 2

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

You could observe future random numbers by taking combat actions, and then reset to the start of the fight and play a line which consumes fewer random numbers in order to manipulate your card rewards. Maybe you could generate the card reward at the start of the fight, but what if they play a card which impacts the card reward, e.g. by creating an extra card reward.

Re: Correlated randomness in Slay the Spire 2

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

Because they appear to have a curious way of doing their saves. From the article:

>The way Slay the Spire allows you to save and resume runs is by storing the total number of times each RNG has been called, and then calling each RNG that many times (throwing away the result) whenever a save file is loaded.

Depending on what the game is like (I know nothing about it), that could make sense, even if it is inelegant.

Re: Correlated randomness in Slay the Spire 2

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

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.

Re: Correlated randomness in Slay the Spire 2

#8
I've always thought that random number generators are one of the best examples of Hyrum's law ("all observable behaviours are part of your API"): once you release a random number generators that either uses a default seed or allows you to seed it, you can't ever change it, it's a huge breach of backwards compatibility. Imagine if you did a Minecraft style game that relied on the behaviour of some PRNG, and then you changed the implementation? The entire game will break. That's why GNU libc still uses a terrible LCG for rand() despite the fact that much better generators exist: they can't ever fix it, because srand() exists and people rely on it.

On the other hand, it's STUPENDOUSLY useful to have "default" random functionality in your core library, for the "just give me a random number" or "shuffle this array, I don't care how" users, who don't really care about the details. But if you do that: always seed it with some external entropy (current time or /dev/random or whatever), don't even allow users to seed it. That means you can improve it in the future, because users already can't ever rely on the sequence. If the users do want to rely on the sequence, they should have to specify the exact engine they want.

TL;DR: System.Random in C# should not ever have been seedable, big mistake.

Re: Correlated randomness in Slay the Spire 2

#9
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 don't think it's deliberate RNG manipulation they worry about. It's a single player (or coop) game after all.

However, one of their design goals is that people playing on the same seed should have roughly the same game, it should feel "fair". Some things you probably want to be fairly random, for instance your card choices can depend on what cards you chose before. But it's also important that people choosing the exact same cards (and taking the same path, maybe?) should be offered the same options.

In STS1, the order of relics was fixed from the start as I recall. So if you skipped a shop, you'd get exactly the same relics in the next shop as you would have in the one you skipped. Good for seed fairness, but a little odd.

Re: Correlated randomness in Slay the Spire 2

#10
post #8

I've always thought that random number generators are one of the best examples of Hyrum's law ("all observable behaviours are part of your API"): once you release a random number generators that either uses a default seed or allows you to seed it, you can't ever change it, it's a huge breach of backwards compatibility. Imagine if you did a Minecraft style game that relied on the behaviour of some PRNG, and then you c…

That split is exactly what .NET 6 did. The parameterless Random switched to xoshiro256*, but new Random(seed) stays pinned to the old Numerical Recipes subtractive generator so historical seeds still reproduce, and that legacy generator is the affine one whose first output is linear in abs(seed), which is the whole root cause of this bug.
Post reply on HN