Soon after my run of the GBC version of the game was published, I had my eye on the C64 version and after the fun I had with the GBC version, I was hoping I could recreate it here. That ended up being far from the case.

The main difference between the two games is the flood fill. In the GBC version, it is instant, save for a few lag frames the more moves you make, whereas the C64 version visibly fills each square in individually which can take a long time. My method for the GBC run was just running a bunch of random moves until it found a solution, which worked and took tens of thousands of rerecords to complete (the listed amount isn't even close to what it actually is lol). This worked because I could run it at 5x speed and got through a failed solution every couple of seconds so it ended up being very efficient. This C64 version is the opposite. I can't quickly go through a series of moves due to its extremely slow flooding and I seem to be unable to run the game more than its original speed so I needed to come up with a new method of finding the optimal solutions.

My first idea was to use the GBC game since I had already found an effective method of quickly finding solutions. But how can I possibly recreate one game inside another? Since I found the RAM addresses for all the pixels on the board, it was only a trivial task of just manipulating them all to be whatever colours I wanted them to be to match the C64 levels with a script. Implementing my brute force script was a little harder but wasn't impossible in the slightest. So here I had a perfect solution to finding optimal solutions for this game...

At least it was for the first couple of levels.

While GBC has only 6 colours, C64 can go up to 9, which is a bit of a problem since it's not like I can directly change the actual code of the game... or can I?

I mentioned in my GBC submission notes that the game is open source, and it had virtually no use to me. Now it did and I was genuinely considering modifying the game to include these 3 extra colours. And it was a fairly easy task too, no need to learn any C at all. The issue I did run into that is easily fixable was the inability to compile the new ROM due to my idiot brain not being able to work out instructions. I think eventually I'll have to come back to this method to see if it works but in the meantime I came up with a different method.

Instead of simply editing the source code, how about I recreate a stripped down version of it in python? After much trial and error I finally got ChatGPT to spit out a working version of a flooder game that is fully playable... sort of. It seems to work 99% of the time when I play casually but I quixkly threw together code that could automate random inputs and it quickly broke after a couple of failed game loops. I'm not sure what's going on, but my goal for now is to find a way to incorporate a brute force method into my version's code as I hope this can avoid it and maybe result in maximum efficiency.

I'm not close to done yet, but it's a long-running project I'm really enjoying (at least when it goes right) so I hope one day to be able to show off a finalised product.

I have quite a habit of leaving TAS's longer than 5 or so minutes in limbo far longer than I'd like, only coming back to TAS another 10-60 seconds every month or so. So instead of actually trying to finish them, here's a list of games I really want to TAS and have some WIP file somewhere.