tl;dr Hide and Seek RNG on Emulators is fucked, you should start with any other minigame if you're not looking to explicitly exploit this glitch.
So, some days ago, I did a couple runs of this game on the MelonDS emulator. At one point, I realized Hide and Seek RNG was always consistent - George was always in the same position. This didn't happen on my 3DS, so it's clearly an emulator issue.
Checking the MelonDS issue tracker, I find that enabling JIT sometimes fucks up RNG. I decide to disable JIT and behold! Different Hide and Seek RNG. Except it's different from what I get with JIT enabled, but also perfectly consistent as long as JIT is disabled (every run with JIT disabled has the same RNG in that minigame).
At this point I'm fully convinced it might be MelonDS. Confronting myself with other runners, who say the problem is not there for them on DeSmuME, I decide to run the latest DeSmuME. It should be noted that I'm on GNU/Linux, which means my DeSmuME version is actually the latest version from GitHub and not the out-of-date "latest" stable version that's available on Windows.
It looks like I finally have different RNG, except now it's consistent among all DeSmuME runs. Thinking this might actually be a problem with whatever the emulators are using for RNG on my PC, I boot up my brother's PC, running Linux Mint, and try out both DeSmuME and MelonDS - the RNG is perfectly identical to the RNG on my PC.
At this point this can only mean that, apparently, there's an RNG glitch on all DS emulators on Linux, which would be completely absurd. I even try MelonDS Android and... RNG is perfectly consistent there too.
So I try building MelonDS from a branch that has improved timing emulation and... RNG is still consistent but differently. This confirms that this is a problem with CPU timing emulation, and apparently only exists on the Linux kernel.
And I'm fully convinced this is a Linux issue until someone approaches me and informs me that on the actual latest version of DeSmuME, on Windows 11 (and not the "latest" stable version of DeSmuME) not only is RNG consistent, but it's also identical to what at the time was the Any% WR.
The only way I can explain this is if an emulator being TOO accurate somehow fucks up the RNG, probably because it's badly programmed and only the DS' poor performance made it work as intended on actual hardware. Which would explain why DeSmuME only shows this problem on recent versions and not on the 2015 one.
As for the solution? There's currently none if you intend to start with HnS, but the problem "solves" itself if you start with any other minigame - HnS is the only one which relies on this broken RNG.
It turns out the RNG for Hide and Seek can be exploited on hardware (on a 3DS at least). It requires fully restarting the game (in the case of 3DS, quitting to the 3DS home screen and launching the game again) and it puts George in the same places every time.
As an extension: if you start and quit hide and seek before the timer starts, then start the minigame again, it will 're-seed' the RNG in such a way that George is hiding in different places but it is still 100% predictable where he's hiding. This can be done multiple times and the result is always predictable.
I haven't tested this on an original Nintendo DS but have no reason to believe the manip wouldn't work if you turned the console off and on between attempts to completely reset the game.
Oh! So basically the only difference between emu and console is the HnS RNG seeds? That's... actually great to know, and I guess it means exploiting the RNG on emu is allowed?
Sure why not.
As far as I'm concerned, it's possible on original hardware so should be allowed as a way to make HnS more consistent by exploiting the game's broken RNG.
