Dev Diary - Burning Down the House: Fire as Gameplay

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 based on how dense they are in an area, so as the fire grows, that whole section of the map starts glowing. It actually makes it harder to keep track of what's happening, shadows move around, the battlefield looks different than it did ten seconds ago. We didn't plan for that but it ended up being one of the best parts. You catch yourself watching the fire instead of playing

We cluster light sources dynamically. If 20 particles are close together, we spawn one bright light instead of 20 dim ones. It looks better and runs faster. Little optimizations like that add up.

Why This Matters to You

Here's what this system enables in actual gameplay:

Control It Early, or Lose Control Entirely

Fire spreads through chain reactions. One burning building can create a new fire wavefront around it. This can ignite other buildings, and burns the ground. Even if you extinguish the fire, that burnt ground speeds up the next fire. If you don't extinguish threats early, they compound very fast.

Meaningful Trade-Offs

• Do you defend your economy buildings or your Paint Wells?

• Do you paint terrain to slow fire or build more water collectors?

• Do you risk to let a section burn to trigger special bonuses? For example, some buildings generate more resources when surrounded by burnt ground.

The Tools We Use

For anyone curious about the tech stack:

• Unity Jobs System for grid and particle calculations (parallel processing keeps frame rates stable)

• Compute shaders for visual texture generation (the burnt paper effect, edge smoothing, noise)

• Custom visual particle pooling (thousands of fire particles = one memory-efficient system)

• Dynamic light clustering (performance trick that makes fire glow without tanking FPS)

The fire grid updates at ~20ms intervals. Visual updates happen every frame, but only for dirty cells. The particle system runs independently at the same interval and syncs with the grid for gameplay effects.

What's Next

We're still tuning fire behaviour for different biomes. In desert regions, sunlight and shadow will affect spread rates (fire moves faster in direct sun). In mountainous areas, slope and wind will create unpredictable patterns.

If you want to see fire in action, stay tuned for our next demo.

Wishlist Painted Kingdoms if this kind of systems-driven design sounds interesting and comment if you want to know of other systems.

Thanks for reading. Don't let your Painted Kingdoms burn.