How We Solved the Worst Minigame in Zelda's History

Excellent video. I'm impressed the author went to recreate the run frame by frame, and then used those findings to analyze what was happening. Never expected this video to turn into a full on reverse engineering explanation. As a side note, this kind of speed run has become more popular in the recent years for a combination of reasons: - First, it's difficult to improve on the regular world records since they're so optimized (just have a look at Quake Done Quick and its sequels). - Second, the emulators available to the speed running community have evolved. They now include better ways to track what's happening in memory. - Third, the games themselves are understood better (as recently exemplified by the Super Mario 64 full reverse engineering). So it's creating a whole new genre of runs that simply isn't about execution anymore. If you're interested in the topic, you might like the Super Mario World speed run that uses a similar technique ( [LINK] ), or the recent work on removing randomness from Wind Waker runs ( [VIDEO] ).

The sheer depth of knowledge and analytical ability pannenkoek has is honestly quite amazing. I've become quite spoiled watching their SM64 videos, it's been incredibly hard to find something of similar rigor and production value for other games. The closest I've found so far has been a video on how a group of speed runners were able to conquer RNG for a puzzle in Wind waker[0]. [0]: [VIDEO]

If you're developing a game, there's a fairly big issue in that many things may be requesting values from, and thus incrementing, the PRNG, and many of them could be indirectly controlled by the user (where they are, where they're looking, etc. [VIDEO] is a fun video about reverse-engineering Zelda to predict the randomness in a minigame) As far as the approach, I agree in that I don't understand why 'no code changes' is that important, especially in the context of Python which has a general attitude of consent towards monkeypatching code. Maybe one of the randomness sources was hashing all the source files? :P

Good point. That approach was in fact used for "Sploosh Kaboom", a RNG minigame in the Windwaker: [VIDEO]

That's true. I did think about mentioning this possibility, but decided not to. Another good example of predicting RNG, after a large amount of gameplay, for a non-turn-based game: [VIDEO] I think in certain Pokemon games, people figured out how to predict and manipulate random encounters based on an animation in the load screen.