Submission #8226: Cephla's GBC Flooder in 00:05.44

Flooder is a 2022 GBC homebrew puzzle game with the goal being to flood the given area with one single colour. At the start of a new game, the screen is crowded with a random mess of 6 different colours (purple, blue, green, yellow, red and pink). By switching the main colour to that of an adjacent pixel, that adjacent pixel will join the flood and change colour with the it. This TAS manages to beat the entire game in barely 2 seconds, skipping all the thinking players must use.

Flooder is probably the game I've been wanting to TAS seriously for a long while now, I just didn't know how to approach it. My original TAS done 10 months ago was made by hand and clocked in at 332 frames, making this a 7 frame improvement (which to me feels huge). That original TAS only had 76 rerecords which deterred me quite a bit from submitting (I know there's been recent discussion about hiding rerecord counts but that really represented my efforts) so I let it sit in my userfiles for another day. About a month ago, it suddenly occurred to me that botting has always been an option, I just didn't know how to do it but I ended up learning the very basics, culminating in this mess of a script.

This game in general was quite interesting to work with, especially after I decided to do a tiny bit of research. It turns out this game is open source which I initially thought would be really helpful but it just turned out to be interesting and I didn't actually gather anything particularly useful from it.

As for the version of the game, the anniversary edition was released not to long after I started working on this again. The game itself hasn't changed all too much, only animations and music have been added but that seems about it. I continued using the original version because it would provide a faster TAS and I'd actually be able to compare this to my original TAS.

You can get the game here: https://obalfour.itch.io/flooder

Very little human input was put into this final version. All I did was do the beginning move and the final 7 or so moves to make it optimal, the main bulk of the game was done using this script.

The way this works, is it will simply select a colour at random, check it's made a move that actually does something and then move on. Looking at it in more detail, you'll notice that there's an entire section dedicated to the second move; the first move is made by me as there is almost always a definitive starting colour and cutting out having the script choose a first colour cuts out a lot more failures. This section wasn't actually used in this TAS because any colour is valid on the second go which brings me onto my next point which is the board of choice. The game can be started 4 frames earlier (the game can be started every 4 frames) however, the board generated on that frame isn't nearly as nice as the one used in this TAS. I spent a good chunk of time running the script on this board but it didn't generate any solutions in the time I gave it. It came close once or twice but it was clearly not nearly as fast as the one used in the final TAS.

But now to actually explain the stuff that happens after the first go. To start with, a save is created and the game chooses a colour but doesn't select it just yet. It counts the amount of pixels with the same colour as the colour that is going to be selected ($1F2C). The colour is selected and another save is made. Another random colour is selected but this doesn't matter because now the amount of pixels of the previously selected colour needs to be recounted. If the amount has decreased, a valid colour has been played and the game can continue. If it remains the same, the go needs to be retaken until it decreases. This is how the success rate is increased by only selecting colours that make a difference.

Other RAM addresses used include the amount of moves left ($1FFD), if this reaches 0, the game will be replayed but this also means all solutions must be played in 24 moves or just get the 1 in 5 chance of selecting the last colour, and if the game has been won ($1992). The original goal was to get the game to pause after it was changed to 1 which indicated a win but this didn't end up working in the end but it doesn't really matter so I didn't bother fixing it. The colours of all 196 pixels are stored individually between $1F35 and $1FF8 with purple being 0 and pink being 5. This applies for all other things that are one of the 6 colours.

For sure. There are so many possible solutions that I wouldn't have come across, this one was just the first 32x and it was a mid-32x so I was happy taking it. It's difficult to estimate just how low a TAS of this game can be taken, I highly highly doubt sub-300 is possible, 31x looks unlikely too but you never know.

nymx: Claiming for judging.

nymx: This is exquisite work! When I saw the thumbnail, I had to check this out....especially since I love puzzle games. After taking this submission on, I got really excited when I discovered that BOTing was involved. Needless to say, I wasn't able to find anything that could improve this run. As for execution, I see that your approach was right on! Great job! I can't wait to see more of this type of work from you.

Accepting to "Standard" for publication.

despoa: Processing...

feos: Fixed cycle count.