Update log
Full Painted Kingdoms: Tower Defense & Firefighting update
The complete published notes, normalized for clean reading and source attribution.
Extracted changes
- Events
- Maps
- Workshop
- UI and audio
- Gameplay
- Performance
We get this question a lot: why build the whole game around fire? Honestly, we needed something that would mess with the player's plans. Enemies alone weren't enough , you learn their patterns and eventually you're just optimizing a build order. Fire doesn't care about your build order. It shows up, it spreads, and you have to deal with it now. Making that actually work at 60fps on a world made of paper was a different problem entirely
The Problem: Tower Defense Needs an Edge
Early on, we knew we wanted to make a tower defense game that didn't feel like every other tower defense game. Enemies are predictable. You learn their patterns, optimize your build, and eventually the challenge flattens out. We needed something unpredictable and relentless; something that forced you to react, not just plan.
Fire solved that problem, and then created about twelve new ones: how do you simulate fire spreading across an entire map in real-time without destroying performance?
Stock fire particle systems couldn't handle it. Unity's terrain tools weren't built for dynamic, spreading burn states. And we needed the fire to look as good as it felt organic and unsettling
The Solution: Two Systems Working Together
System 1: The Fire Grid (Gameplay Interactions)
The fire simulation runs on a coarse grid, think of it like a chessboard overlay on the world. Each cell tracks three things: heat, fuel remaining, and temperature. This is just gameplay data. It tells us where fire should be positioned.
This grid is the interface with fire for most of the gameplay systems:
Buildings heat up and ignite based on nearby cells
Burnt ground speeds up fire spread (chain reaction mechanic)
Water from towers or the player's hose directly affects cell temperature
Enemies react to fire zones (they heal in flames, move faster on burnt ground)
The trick: Only cells that change get recalculated each frame. If a section of the map isn't heating up or cooling down, the system ignores it. This keeps performance stable even when half the map is on fire.
System 2: The Fire Particle System
The grid tells us where the fire is. Particles tell us how it moves. Fire particles represent the active front the leading edge of the blaze. They're not simulating every flame; they're simulating the shape of the fire as it spreads.
Here's where it gets interesting:
Particles start out from predefined patterns (circles expanding from buildings, lines advancing like a wildfire front, arcs curving around obstacles)
If the front gets too stretched out, particles split to fill gaps; this keeps the fire front cohesive
Particles heat both the grid and buildings directly
Some examples:
A building on fire spawns a circular fire pattern that expands outward
Enemy fire attacks can create targeted fire lines that target specific buildings or even follow the player
Wave-based fire events can spawn custom shapes (fronts, curves, clusters)
The result: Fire feels alive. It doesn't just tick boxes on a grid, it moves like it's looking for something to burn
From Prototype to Product
Everything in gaming requires iteration. The first fire prototype was a basic shader that turned paper brown when it "burnt." It looked okay, but it didn't feel threatening.
Then we added the particle system. Suddenly, fire had direction. You could see it coming. You could predict where it would go next, but only if you were paying attention.
The last thing we added was lighting. Fire particles generate light
Source
