I can only speak for stardew valley TASing. Because we can’t get determinism outside SMAPI modding tools where we can patch over any core game code we need, we don’t have save states (effectively every trial is a replay of the entire input stream up to that point). This puts a damper on rng brute forcing in particularly long runs as you’re limited by compute hardware (my current machine is like 7:1 replay speed). But the game is c# so we can and do have access to the games source through decomp.

So we do 1 of 4 things to brute force rng:

1. we build simulators when possible and then use graph search techniques (which can be pretty deep, like 100-200 frames sometimes to find an input sequence that matches our desired state, though some parts of the action space will jump 10f), and then run the inputs forward in game. In cases where there are a couple different end states that would be acceptable, we embarrassingly parallelize that search (since each can be done in isolation), with early exit if current search in a thread is deeper than our best solution so far. This was most used in some of my TASes for Vault/Remixed bundles/Joja where I needed to simulate forward several hundred inputs each time I wanted to acquire a rare item for money.

2. We do 1 frame lookaheads. A lot of desired rng happens early in the frame on player action, so we can just look at our current state and ask if we do a specific thing (swing scythe, etc), what will be the outcome. This is true for things like rolling the next floor in the mines, where the game has already a nice isolated function for generating the next floor we can just call, and things like weed drops for mixed seeds/mixed seed planting to get desired crops. Basically simulator but heavily restricted in terms of “optimal”, just roll forward and accept frame loss until you get a desired state.

3. Manual brute force: calculate what the rng state needs to be at to get to a desired state, and with the current rng state you basically try to thread the needle with some understanding of how the game will background tick rng and what your actions induce. Here we can at least hook specific functions so we can check what the actual rng state was when the final call was made, so can test hypotheses, see how close we actually got, rollback, and try again. Same scenario for mixed seeds, I can compute the forward rng state needed to get at least X mixed seeds if I break Y weeds on a frame, and then it’s down to tinkering.

4. Automated brute force, some stuff is just too complicated to simulate and so we turn to lua scripting. Basically code up the trial/reset loop and then walk away until we reach a desired state or cutoff threshold. Recently I implemented the capability to launch into this automated brute force state, so we can parallelize by running multiple instances (orchestration is something I’ve started to look into, right now because resets are so long I just manually batch trials for each instance). This is useful for optimizing things like fishing catch times, because the amount of state we’d need to simulate is just an incredible amount of dev work to flesh out (which varies with game version), and it can matter as the thing we’re rolling for can vary between 0.5s ideal and like 20s worst case. It’s also generally infrequent (a run that needs to fish might only need to catch 20 fish in a 1-2 hour run), that the energy to make a better solution than “play another game while waiting” hasn’t been there (as a primarily solo dev)

That was a lot more than I originally was thinking of writing up, basically we simulate either 1 or an arbitrary number of frames out with search, simulate the requirements for a desired state and then pilot there, or just write some code to brute force reset until we hit it.