Hey, thanks for playing!
We've utilized threads lightly in past jams to help us work through more complex functions that were choking up the main thread, but they were definitely relied on too heavily for this entry. The amount of WorkerThreadPool tasks and thread functions seemed to hurt the quality of the web build, which definitely made this an important learning experience.
Threads did a lot of heavy lifting for the simulations on the map. We used one that ran a custom flowmap for navigation that encouraged the enemies to avoid burning regions on the map. We also had a separate thread do the procedural generation at the start of the game, since the tile operations were quite heavy and really held up the scene tree when loading in. Finally we had a big WorkerThreadPool group task that decodes the map data and generates a texture for the shader to draw the map. That also got us around using the built in TileMap entirely. Since images aren't thread-safe we instead wrote the decoded color to a PackedByteArray and then converted that to an Image at synchronization. The fire simulation runs surprisingly well on the main thread, so that was left as was. The best way to maintain performance was to use GpuParticles2D and write to a pointmap to communicate where the fire would emit from, letting us offload a huge chunk of the work to the GPU. So everything you see there when a big fire is going is one singular particles node!
Seems like using threads on web builds are best suited when deployed sparingly though, and where the performance gain really counts. In the future we'll certainly be more careful with how we utilize concurrency!