This C64 version of Flooder is a level-based example of the game concept of filling a grid of coloured pixels with just a single colour, starting from the top-left pixel. Unlike the Gameboy version which I previously made a TAS of, the level system provides 6 opportunities to show off finding the optimal solutions to boards increasing in difficulty as a new colour is added each time. This TAS aims to beat all 6 easy mode levels in as few moves as possible
Game objectives
- Emulator used: Bizhawk 2.9
- Uses easiest difficulty
- Aims for fastest completion
Comments
Pretty much immediately after completing the GB version of the game I set out to find another TASable version because I wanted to have the fun of solving another game again. So I landed on this C64 one and for the best part of 2 years, it's mostly spent its time dormant in my workbench, only touching it every few months because this game wasn't at all the enjoyable experience I was expecting it to be.
With the slower flooding speeds I had to find a different method of brute forcing my way to solutions, and so my process for finding the fastest solutions for each level looked like this:
- Generate a random set of inputs to influence the layout of the board (that's one benefit compared to the GB version)
- Take a look at the result
- If it looks good, run the board layout in a external solving program, else roll again
With all the boards I ended up generating, I came to the conclusion that the fewest number of solves needed for a level would be 5 greater than the level number. I did do some manual board manipulation myself when anything promising but not quite there yet came up and I still couldn't get this down any further. Also with the way the game calculates how to flood, it would lead some solutions of the same length to vary by a few seconds in length and so this TAS ended up becoming more of a fewest moves TAS than fastest completion (though that is still a goal) so maybe the goal name should end up being changed. I think the only other thing worth pointing out is the ending and making it end as soon as possible. Inputs can be queued but the maximum number that could be queued never felt consistent. At the end, I managed to queue up 11 inputs, though there did have to be a one frame space between the second and third inputs otherwise inputs 3 onwards wouldn't get processed for some odd reason.
nymx: Woah! Another recent addition to our C64 TASers! Claiming for judging.
nymx: I have confirmed that the movie syncs.
nymx: I remember when you did the Gameboy version of this game. You impressed me with the results. With the C64, I can certainly understand your frustrations with how it wasn't as fun as you had hoped. The core is very slow, so brute forcing it would be a nightmare. I like how you approached it with a different method, which I am always doing when I TAS a C64 game. In comparing this with your other work, I see that it is well done. I might believe more could be found, but it certainly isn't noticeable. Also, what an amazing set of buffered inputs at the end!
Accepting to standard.
despoa: Processing...