The idea of Crane Tower was simple: a crane drops blocks, the player builds a house, and finally an earthquake tests whether the building holds. The game was supposed to reward careful building. In the first tests, the opposite happened.

The problem: even a perfect house collapsed

The game uses the open-source Matter.js physics engine. When we stacked blocks exactly on top of each other, a tall tower would sooner or later start slowly “creeping” and fall over — without any earthquake. Physics engines solve contacts between bodies in small time steps and iteratively, and small calculation errors add up. In a tall stack they are enough to bring the whole building down.

From the player’s point of view this was unfair: careful building did not help, and the earthquake result felt random.

Measuring, not guessing

We built a simulation separate from the game that builds hundreds of houses with different accuracy and runs an earthquake on each. That let us compare settings with numbers instead of gut feeling. We tried more solver iterations, friction, letting bodies “sleep” and other tweaks. None of them fixed the problem on its own.

The solution: blocks lock in place

The final solution is familiar from classic tower games: when a block lands and comes to rest, it locks in place. During construction the tower cannot fall by itself. Only when the earthquake starts do all blocks return to full physics — and that is when sloppy building is revealed.

We also split every physics step into three smaller ones. A shorter time step makes the stack much more stable, and a perfectly built house no longer collapses for no reason.

Tuning the earthquake

The earthquake does not move the ground; instead an alternating force acts on every block — in physics terms, an inertial force in the ground’s frame of reference. Its strength and frequency were tuned with simulations so that the result depends on building quality. In our simulations, a carefully built house kept about 97% of its blocks standing on average, a reasonably built one about 85% and a crooked one about 65%.

What we learned

  • Fairness is design. The player must feel that the result depends on them.
  • Measure before you tweak. The simulation found the problem and the right values faster than random playtesting.
  • Borrow good solutions. The locking block in tower games exists for a reason.

The same principle applies to all our games: we test them so that players do not have to find the bugs for us.