Thank you :)

Thanks for playing :) It was very hard to get this game running smoothly so sorry about that.

 I'm very happy it even runs in the browser :D

Thank you. I'll try my best to explain it.

The easy but very laggy way to do pixel manipulation in Godot is usually by iterating through every pixel in two nested for loops and then reading or setting its new color value with get_pixel() or set_pixel(). These built-in functions are extremely slow because they run on a single CPU thread, processing each pixel sequentially.

This consumes a lot of CPU cycles and takes a significant amount of time.

In my game, which runs at a resolution of just 480×270, that's already 129600 iterations per frame. This is a heavy load and takes too long to compute. For example, here's a laggy check to see if a pixel has been completely burnt by fire. Calling this in _process()  takes a lot of compute. 

func check_for_burnt_out_pixels(current_image: Image, last_frame_image: Image, burnt_mask_image: Image) -> Image:     
    for y: int in range(current_image.get_height()):         
        for x: int in range(current_image.get_width()):             
            var last_pixel: Color = last_frame_image.get_pixel(x, y)             
            var curr_pixel: Color = current_image.get_pixel(x, y)             
            var already_emitted: bool = burnt_mask_image.get_pixel(x, y).r > 0.1              
            var just_burnt_out: bool = (last_pixel.g > 0.0 and curr_pixel.g < 1.0 and curr_pixel.g > 0.998047 and curr_pixel.a > 0.0)             
            if just_burnt_out and not already_emitted:                 
                burnt_mask_image.set_pixel(x, y, Color(1.0, 0.0, 0.0))      
    return burnt_mask_image

And these kinds of checks also need to be done to determine if a pixel is wet, burning, repairable, or producing smoke. Running this at 60 FPS on a CPU with current hardware is practically impossible. Using threads makes it a bit better but still not ideal.

The alternative is to leverage the power of the GPU through shaders.

The GPU can run thousands of threads in parallel, each handling a single pixel (fragment). In a shader (like a fragment shader), each pixel is processed independently. This means that if you’re rendering a 480×270 texture, the GPU can compute 129,600 pixels with ease in a fraction of the time a CPU would. 

In Godot, these are called canvas shaders, which you apply to materials via ShaderMaterial. Godot uses a shading language based on GLSL. shaders are not written in GDScript.

I accidentally left my debug tools in. You can set something on fire and then press Q to see the debug.

I do almost all heavy pixel manipulation in shaders, leaving only a minimal amount in GDScript when there’s no alternative. Shaders are essentially a one-way street: you can feed them variables at runtime, but you can’t read their internal variables back. Only the computed results can be written back into textures. This adds complexity and a few headaches, but the performance gain is worth the trade-off.

I have shaders that handle the calculations for fire, water, fuel, repair, avoidance areas, and smoke, along with their rule-based interactions and propagation. These are written into and fed by several texture masks representing fire, fuel, and water as RGBA values.

For example, burnable pixels must still have some green channel value to be considered ignitable. The green value gradually decreases to 0 as the fire consumes the pixel, and repairing restores the green channel back to 1. Water uses the blue channel, which slowly decreases when it touches fire (eventually evaporating). Fire uses the red channel.

In the end, I get a texture where each RGBA channel shows how much fire, fuel, and water each pixel holds. I then pass this into another shader that combines the final RGBA values with the pixel art, applying visual rules depending on how much fire, fuel, or water a pixel has. Pixels with low green and red values appear darker; those with both green and red show varying fire intensities; and pixels with blue appear wet.

With this method, I achieve around 120 FPS on desktop, and even in browsers performance stays acceptable at around 30–50 FPS.

There’s more to it, but this is already a super long explanation. Hope this helps!

Thank you for the kind words :) I agree that some aspects like the balance and the whole smoke absorption need some rework ^^ I’m actually thinking about completely removing the Roomba and reduce the smoke. maybe turning it into a left-village vs right-village autobattler, 

maybe even with a catapult shooting burning boulders that the player can control.

Its still a prototype but i think i want to build on it :D

Thank you man :) Normally I mute the music while developing because it gets repetitive to listen to it through the whole dev cycle,

but this time I just let it play and loved it so much :D 

Also I think the tactic you described is the best one too. I posted a cheese strat image a bit further down in another comment if you want to check it out.

Thank you :D

Thank you so much, glad you had fun! I’m happy to hear it fit the vibe while you were setting everything on fire :D

Glad you had fun :D currently every 4 sec a firefighter is spawned until all fires are gone and then they return to base and the number resets. It was not easy to balance fire vs water. The fire grows exponentially so it starts very slow and overwhelms very quickly, but the firefighters grow lineary. slower spreading fire didnt look that cool in my opinion so i opted for more firetrucks because they simply couldnt handle the firestorm :D

Thank you for playing :) For easy mode I would say the best strategy to speedrun is: set 2 roads on fire, let the firefighters work on that and then light a tree area and just cover it with the roomba to absorb all the smoke directly.
like that :D 

Thank you :D

Haha yes. Thanks so much. I think I made a good score in your game. it was fun too :D

Thanks for the kind words :D Thats really cool that you liked the vibe. I was way in over my head with doing everything in shaders and there was once again too little time to make other parts like the music crossfading work well sadly. But i gave it my best and I really wanted both song to be in the game because i liked them so much :D
same with the endcredits (of course real men test in production /s). at least the main menu credits are valid :D

Thank you :) The whole smoke mechanic is a bit wacky sorry about that. when you touch a smoke pixel with the side of the roomba its not counted as consumed but still despawns i think. its some buggy behaviour that makes wiping the screen with the roomba a worse strategy than just hovering directly over a burning area.

The bar at the bottom right grows either left or right, with the middle being neutral. Shooting uses up some energy, and hovering over burning areas to absorb smoke gives you energy back.

When the bar goes full red you lose, and when it goes full blue you win. That’s all :D

Thanks for playing.

I tried to make the fire spread organically using cellular automata logic. Then I spawned some Sprite2D flames on top of it and added a GPUParticles2D node for sparks and embers. I think it turned out really pretty :D

Thank you for playing :)

Thanks for playing! :D

Haha, yeah, that number in the top left is just the framerate. I accidentally left my debug info in the game, and the fps was part of it.

Since I mentioned debug, there’s a secret debug screen you can open by pressing Q. It shows some of the shader computations under the hood as rough visualized textures (it cant be disabled until the scene reloads).