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

81–90 of 92 posts

Re: Correlated randomness in Slay the Spire 2

#81

Post by doctorpangloss »

account42 wrote: post #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 impl…

i wonder how the StS developer could get this far without "ownership" of the behavior that this blog author called "linearity." in these kinds of games you simulate bajillions of random games and check metrics after every player action, including whether or not you observe sufficient randomness in shuffles and stuff, as a matter of debugging something this complicated.

Re: Correlated randomness in Slay the Spire 2

#82

Post by SAI_Peregrinus »

gpm wrote: post #43
Lalabadie wrote: post #40

Earlier quoted context omitted.

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.

CSPRNGs are absolutely seedable deterministic functions that will result in entirety reprodible runs. The only difference is that if you don't know the seed it is computationally difficult to predict the next value given the previous ones. But that's not something any game dev is ever going to want to do (or waste time trying to do)

In contrast, OS CSPRNG APIs usually only provide access to a CSPRNG that the OS seeds on its own, in some way not fully controllable by the user. E.g. using fast key erasure & hashing in data from a hardware entropy pool.

Re: Correlated randomness in Slay the Spire 2

#83

Post by lucb1e »

kami23 wrote: post #58

I haven't had time to read the whole article, but I really appreciate the cross section of the world that reads HackerNews and plays STS2. STS1 and STS2 are my favorite games and to see this pop up here brought a big smile on my face. Thanks for sharing.

Another cross-section is space enthusiasts. I really have to rewire my brain every time someone says sts-n and doesn't mean a mission number of https://en.wikipedia.org/wiki/Space_Transportation_System

Re: Correlated randomness in Slay the Spire 2

#84

Post by joshschreuder »

cevn wrote: post #45

I wonder if this can explain something happening to me. If I select "random" at character select, I had a run of 30 or 40 where I never received the Silent. Defect seem to come up more often than it should, and Ironclad less often.

Were they at different ascensions? I believe up until the most recent beta patch random with an ascension selected would only pick from classes which had that ascension unlocked which might explain it?

Latest beta patch introduced > Implemented preferred Ascension for random character option

Re: Correlated randomness in Slay the Spire 2

#85

Post by chriskw »

Random thing I ran into while trying to seed search for a challenge run, but since the seed is passed through a 32-bit hash function it means there's effectively only 4 billion seeds (as opposed to the first game, which had 64 bit seeds). This is great if you wanna do something like prove/disprove whether there are unwinnable seeds since its trivial to brute force all of them, but it does mean the potential for fun "high roll" seeded runs is much lower, which is a shame since the new game has so much more variance than the original.

This was the challenge run I ended up with (Ascension 10 win without taking any cards) https://youtu.be/PbP284CZrZ4?is=iL1E7gIzj_kgx0MS

Re: Correlated randomness in Slay the Spire 2

#86

Post by chriskw »

bilekas wrote: post #30
account42 wrote: post #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 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 in…

Breaking old seeds is probably not too big a deal since the game is currently in early access, and the biweekly patches mean that seeds are already pretty inconsistent. For example, adding new cards/relics/combats to the pool throws off the generation for all cards/relics/combats anyway

Re: Correlated randomness in Slay the Spire 2

#87

Post by Terr_ »

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?

Think of chaos theory, or at least the pop-science version of it. You brush aside a butterfly today, and the fated hurricane doesn't happen next week.

However if insect-wingbeats and weather-systems used two independent PRNGs, you could safely walk in the garden without changing the meteorological future.

Re: Correlated randomness in Slay the Spire 2

#88

Post by beasthacker »

kami23 wrote: post #58

I haven't had time to read the whole article, but I really appreciate the cross section of the world that reads HackerNews and plays STS2. STS1 and STS2 are my favorite games and to see this pop up here brought a big smile on my face. Thanks for sharing.

You may like a game my younger brother developed. Same genre as slay the spire.

He and one other guy coded this together for a few years. Really good reviews on Steam.

https://store.steampowered.com/app/3057670/Pluto/

Re: Correlated randomness in Slay the Spire 2

#89

Post by kowbell »

beasthacker wrote: post #88
kami23 wrote: post #58

I haven't had time to read the whole article, but I really appreciate the cross section of the world that reads HackerNews and plays STS2. STS1 and STS2 are my favorite games and to see this pop up here brought a big smile on my face. Thanks for sharing.

You may like a game my younger brother developed. Same genre as slay the spire. He and one other guy coded this together for a few years. Really good reviews on Steam. https://store.steampowered.com/app/3057670/Pluto/

Love the art style, definitely gonna try the demo later! (But boy howdy the "About This Game" section needs a human being's touch.)

Re: Correlated randomness in Slay the Spire 2

#90

Post by purple-leafy »

OskarS wrote: 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…

Yes this is a key insight, and fortunately something I realised very early on in my JavaScript game engine which had a custom PRNG - but effectively for part of my game engine (stateful replays) every time I change my codebase and release/publish I effectively have to freeze that version of my engine - and route players to that engine version silently.

It’s not elegant but I don’t see any better way to do it to maintain backwards and forwards compatibility.

My plan is to control engine versions via a manifest.json or similar that points to applicable engine versions as a compatibility layer

Post reply on HN