Submission Text Full Submission Page
In this game, the goal is to trigger the longest chain reaction. Once you click on a cell, you can no longer click on any of them before they all stop moving. The chain reaction and the soothing sfx make it a relaxing game. You can play the game is various places, for instance here.

Comments

For my last submission, I spent roughly a week instrumenting and patching libTAS in order to bruteforce 1.3 million possibilities in 5500 grids. But we're mid-2026. AI is now sufficiently advanced to be able to fully reimplement the game in C with a few prompting (or, to be fair: a LOT of prompting and frustration about how stupid it is despite its capabilities), along with a complete bruteforcer.
Thanks to this, I was able to bruteforce over a billion grids in less than 24 hours. While the last bruteforce barely found a solution hitting the 4000 cap, I found many solutions over 5000, and a best solution of 5800. In order to find the best grid, I used the strategy of making a few attempts on each grids, then performing a full search for the grid when one of them is below a certain threshold (2000 or 3000, I did some tweaking during the bruteforce). I ran several bruteforcers in parallel tweaking these parameters (from one doing an extensive search on all grids to one aggressively cycling through grids).
The resulting solution is an elegant grid with almost no unreachable cell which finishes visually pretty well sorted.
The bruteforcer code is on Github, along with documentation regarding the RNG used by Ruffle.

Potential screenshots:

Potential optimizations

There should be roughly 2 billions possible grids (2^31) due to the way the seed is constructed. While I used a time-efficient strategy to cycle through grids to quickly find the most promising ones, an extensive search of the whole address space should be doable in reasonable time (several days/weeks of computation). I doubt, however, that the best result would be significantly higher than the current solution.

Emulation



TASVideoAgent
They/Them
Moderator
Location: 127.0.0.1
Joined: 8/3/2004
Posts: 17972
Location: 127.0.0.1
Player (156)
🇺🇸 United States
Joined: 5/5/2025
Posts: 265
Location: 🇺🇸 United States
Nice improvement, yes vote!!
GJTASer2018
He/Him
Location: Stafford, NY
Joined: 1/24/2018
Posts: 416
Location: Stafford, NY
Note that as Samsara pointed out in judging the previous submission for this game, limiting your actions to a single click is the only viable way to do a proper TAS for this game. Also, infinite loops are not mathematically possible, so the game can only run for a finite length of time in these circumstances and only a finite number of rotations for score can be achieved.
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
Editor, Experienced player (599)
Joined: 2/11/2018
Posts: 286
Rather than translating Rust to C, you could use the original implementation of Flash's RNG in the brute forcer
CoolKirby
He/Him
Editor, Experienced player (708)
Joined: 11/8/2010
Posts: 4270
Couldn't sync using the right libTAS and swf. Can you verify which Ruffle was used? Ruffle 2026-05 14 through 16 all give the "hash mismatch" error as they don't match the one logged in the input file (which is also different from the one listed in the submission text.) Another thing to check, did you use the linux_x86-64 Ruffle?
Editor, Active player (259)
Joined: 7/10/2022
Posts: 44
Yes, this is the ruffle-nightly-bin debug AUR package 2026.5.15-1, x86_64 Not sure what more to test, I'll try on another machine Edit: It indeed doesn't sync with the same version on another computer. The AUR package does give the correct hash. The problem may come from the libTAS version then, I'll make more tests tomorrow Edit2: this is not a version issue. The problem is due to the click not landing on the right cell. I'll try hardcoding window size to avoid this
Editor, Active player (259)
Joined: 7/10/2022
Posts: 44
@CoolKirby: I fixed click coordinates in this file: https://tasvideos.org/UserFiles/Info/639239802862303458 Ruffle may use different window size on smaller screen, please use --width 267 if click on wrong cell happens. I'm not sure about the hash difference. I'm using the AUR package's nightly-2026-05-15 (commit 90c15221ce3f6da6d4ac3ef13001451a42246af4) which is pulling this exact release. Do you at least see the same starting grid than the one in the youtube encode?
CoolKirby
He/Him
Editor, Experienced player (708)
Joined: 11/8/2010
Posts: 4270
zapkt wrote:
@CoolKirby: I fixed click coordinates in this file: https://tasvideos.org/UserFiles/Info/639239802862303458 Ruffle may use different window size on smaller screen, please use --width 267 if click on wrong cell happens. I'm not sure about the hash difference. I'm using the AUR package's nightly-2026-05-15 (commit 90c15221ce3f6da6d4ac3ef13001451a42246af4) which is pulling this exact release. Do you at least see the same starting grid than the one in the youtube encode?
That window size must've been the problem, because the new file syncs fine on libTAS 1.4.8 and the Github 2026_05_15 you linked, which was among those I'd tried before. The click in the old file must've been in the wrong spot on my 1366x768 screen, good to know about that --width option for future verifications. I couldn't figure out the AUR site. I tried several of the links and searching the commit string and version number. Do you have a direct link? Otherwise the Github one syncs fine, so it should be okay. I'll mark it sync verified once the file's replaced.

1788444614