KAIJU PROTOCOL DEV BLOG: BUILDING DESTRUCTIBLE CITIES

I've spent the last two months trying to make a city collapse convincingly, and I've learned more about lying to the player than about physics. When I started Kaiju Protocol, I assumed destruction would be the fun part. The reward for solving every other engineering problem first. Instead, it has been the single biggest technical wall I have hit, and the answer turned out to be doing less, not more.

So this is a dev blog. No marketing copy. Just notes from a solo dev on why city destruction is harder than it looks, what approaches I considered, what I am actually building, and where I am still stuck. If you are working on something similar, maybe it saves you a week.

The problem statement

Kaiju Protocol is a game about being a giant monster wrecking a city. That is the core verb. If the destruction does not feel good, nothing else in the game matters. You can have the best monster animations, the most clever progression system, the smartest AI for fleeing civilians, and none of it lands if the buildings collapse like cardboard or refuse to break in interesting ways.

The reference points are obvious. Rampage. War of the Monsters. Gigabash. The older Godzilla games on PS2 and PS4. And looming over all of it, Teardown, which set a new bar in 2020 and made every developer who works in this space look at their own work and feel slightly worse about it.

I am one person with a Unity license and my own time. I am not going to out-engineer Tuxedo Labs. So the question becomes, what can I actually build that gets close to the feeling, and where do I have to accept compromises?

Why Teardown is the wrong target

Let me get this out of the way. Teardown is incredible. It is also a five year project from a team with deep voxel rendering and physics expertise. Dennis Gustafsson built the engine from scratch in C++, with custom path tracing and a destruction model that simulates structural integrity at the voxel level. Every tiny cube knows what it is connected to. Remove enough connections and gravity does the rest.

That is not a thing I can build. It is also not a thing I should try to build, because Teardown's voxel approach has tradeoffs that would actively hurt my game.

The first problem is scale. Teardown's maps are small by design. A heist map is maybe a few city blocks. A kaiju game needs a whole city. The voxel resolution that makes Teardown feel tactile would balloon to numbers my engine cannot handle if I scaled it to a few square kilometers of urban environment.

The second problem is art style. Teardown commits hard to its voxel look. Kaiju Protocol is stylized low poly with smooth surfaces and clean silhouettes. Voxels would clash with the visual language. The monster would look like one thing, the city would look like another, and the seams would be everywhere.

The third problem is gameplay focus. In Teardown, destruction is a tool. The game asks you to be precise. In a kaiju game, destruction is the goal. You want to feel powerful, not surgical. You want to swing a tail and have a city block come down, not stand there watching individual voxels crumble while your monster does careful pottery breaking ASMR. The wrong destruction model would make the game feel slow.

So Teardown is not the model. What is?

The chunk-based approach

What I have settled on, after a couple of false starts, is a chunked prefab system. Every building in the city is built from prefabs. Every prefab has multiple destruction states. Every prefab is divided into chunks that can be removed independently.

Here is how it works in practice. A skyscraper is not one model. It is a stack of floor prefabs, each one composed of wall sections, support columns, interior debris, and a roof piece. When the player smashes a building, the system does not simulate the structure failing. It identifies which chunks were hit, swaps them for damaged variants, spawns rigid body debris pieces that match the broken section, and triggers a structural check on the floors above.

The structural check is the interesting bit. Each floor has a list of supporting chunks. When a supporting chunk is destroyed, the floor's support count drops. When the support count crosses a threshold, the entire floor is flagged as unstable. Unstable floors collapse onto the floor below them after a short delay, which can cascade into a chain reaction down the whole building.

This is not real physics. There is no actual structural simulation. I am not solving stress equations. I am running a glorified counter on each floor and triggering a collapse animation when the counter hits zero. But the result, when it works, is that buildings collapse in ways that respond to where you hit them. Punch out the corner of the third floor and the whole corner of the building above it caves in. Knock out the central columns and the building pancakes down on itself.

The animations are partly procedural and partly canned. The initial collapse uses cached animation curves with some random offset per chunk so it does not look identical every time. Once the floor pieces have fallen far enough, they convert to actual rigid bodies for the final settling. The final pile of debris is real geometry that the player can interact with, even if the falling phase was a cheat.

The performance budget

Here is where solo dev reality kicks in hard. I do not have a graphics programmer. I do not have an engine team. I have whatever Unity gives me out of the box, plus the Burst compiler, plus some hand-rolled object pooling. That has to be enough.

My target is 60 FPS on a midrange GPU, something like a 3060. That gives me a frame budget of about 16 milliseconds. Of those 16 milliseconds, I am giving the destruction system 4 milliseconds in worst case scenarios, which means a multi-building collapse during heavy combat. That is not a lot.

The implications cascade through every design decision. I cannot have thousands of debris pieces with full physics. I cannot run real physics on more than a few dozen rigid bodies at a time. I cannot afford fancy fracturing on the fly. Every shortcut I take is in service of staying inside that budget while still selling the illusion.

Object pooling does most of the heavy lifting. Every debris chunk comes from a pool of pre-allocated objects. There is a strict cap on how many active debris pieces can exist at once. When the cap is hit, the oldest pieces despawn first, hidden by dust particle effects so the player does not see them vanish.

LOD is brutal. Buildings past a certain distance switch to lower detail prefabs with no chunk subdivisions. They get intact, half destroyed, and rubble states, and that is it. If you smash a building from across the map, you get a less satisfying collapse, but you also get the framerate. The math says players will not notice from that distance, and so far the math has been right.

The physics layer is segmented. Active debris and the player's monster live on a high update rate layer. Background scenery sits on a lower update layer. Far buildings are not simulated at all, just visually intact, and get promoted to full simulation a frame or two before entering view distance.

Fake destruction and visual cheats

The honest truth is that most of what makes destruction feel good is not the physics. It is the dust, the debris flecks, the camera shake, the sound, the slow motion micro pause when something big breaks. I have spent more time on these than on the actual destruction logic, and they have a much bigger impact on how the game feels.

Dust is the biggest cheat. Whenever a chunk is destroyed, a particle system spawns a billowing dust cloud at the impact point. The cloud is opaque enough to hide a multitude of sins. It hides the moment the chunk model swaps to its damaged variant. It hides debris pieces snapping into place from the pool. It hides the abrupt despawn of pooled objects. The dust cloud is not just an effect. It is the curtain I hide the magic trick behind.

Camera shake is the second cheat. A solid full body shake when a building collapses sells the impact better than any physics sim could. The shake intensity scales with the size of what was destroyed and the distance from the camera. A small collapse is a soft rumble. A skyscraper coming down is a teeth rattler. The player does not see this as a system, they just feel that big things feel big.

The audio mix does almost as much work as the visuals. Low frequency rumble for the structural failure. Mid range crashes for impact moments. High frequency glass and metal for the secondary debris. A bass drop on the final settling. None of this is novel, but missing any of it makes destruction feel weightless and cheap.

Slow motion is used sparingly. When a building starts to topple, I drop the time scale to 0.6 for about half a second, then ramp back up. It draws the eye and gives the player a moment to register that they did this. Used on every destruction it would be exhausting. Used on the big ones it makes them feel earned.

Where the trade-offs hurt

I want to be honest about what this approach gives up. There are real losses here, and pretending otherwise would be the exact kind of marketing speak I said I would not do.

You cannot precision tunnel through a building. If you punch a hole in a wall, the hole is a chunk sized hole. You cannot make a smaller hole. You cannot poke a kaiju finger through the brickwork. The granularity is whatever the chunk size is, which in my current build is roughly two meters by two meters by one floor tall. That is fine for kaiju play. It would be terrible for a heist game.

You cannot have persistent destruction at the level of individual debris pieces. Once a building has collapsed, the rubble pile is essentially decoration. You can walk on it. You can shove some pieces. You cannot dig through it to find a buried car. The pile is an aesthetic, not a system.

Buildings collapse in a finite number of ways. Hit the same building the same way twice and you will get the same collapse. There is some randomization on the secondary debris, but the macro shape repeats. In a kaiju game where you are usually destroying each building once, this is invisible. In a replayable sandbox, it would feel cheap fast.

Chain reactions are limited. Building A collapsing onto Building B does not actually transmit force into Building B's structural calculation. I fake it with trigger volumes around buildings that, when struck by enough debris mass, deal damage to the neighbor as if the player had hit it. It works most of the time. Sometimes it triggers when it should not, and a building collapses for no visible reason. I have a debug overlay just for diagnosing these phantom collapses.

What I am still figuring out

The biggest open problem is interior destruction. Most of the time the player is outside, smashing buildings from the street. But sometimes you want to peer through a hole in a wall, see scared office workers running around inside, and then collapse the floor on top of them. That requires interior geometry that exists, can be revealed by external destruction, and can itself be destroyed.

Right now my buildings have no interiors. They are facades with collapse states. When you break a wall, you see the wall behind it, also a facade. The illusion holds at distance but breaks if you get close. I am prototyping a system where buildings have a few interior shells that get instantiated only when nearby destruction reveals them, but the bookkeeping is annoying and the performance cost is real.

The other open problem is variety. I have, at the moment, eight building archetypes. Office tower, residential block, low industrial, gas station, parking structure, retail strip, school, and church. Each archetype has three to five visual variants that share the same destruction logic. That sounds like a lot until you walk around the city and notice the same parking structure three blocks in a row. I need either more archetypes or a way to procedurally vary the existing ones at runtime, and I have not figured out which is the better use of my time.

There is also the question of what destruction means for player progression. Right now destruction is its own reward, the way it is in city destruction games like City Smash. But Kaiju Protocol has missions and objectives. The destruction has to feed those systems without becoming homework. That is a design problem more than an engineering one, and I will probably write a separate post once I have solved it.

Notes for other solo devs

If you are building anything in this space, the thing I would tell past me is that you almost certainly do not need real physics. You need the perception of physics. The player is not running structural calculations in their head. They are reading silhouettes, particles, sound, and screen shake. If the cues are right, the underlying system can be a glorified state machine and nobody will know.

The second thing is that scope is the real enemy. Every time I have been tempted to add a new system to the destruction pipeline, I have lost a week and gained almost no perceived improvement. The wins have come from polishing what was already there. Better dust, better sound, better camera response. Boring craftsmanship work that matters more than flashy systems work.

The third thing is to ship something playable fast. I had a paper prototype of this whole pipeline running in two weeks, with crude programmer art and placeholder sounds. It was ugly and it played badly, but it told me what was working. If I had spent two months building the system before testing it, I would have built the wrong thing and not known.

I will write more as the game progresses. There is a lot more to say about the AI for fleeing crowds, the kaiju controller, and the grim economics of one person studios trying to ship something ambitious. For now, I am going to go put more dust into more particle systems, because that is the work actually moving the needle.