Physics Puzzle Game Development

Phase	Decision	Typical value or rule	Planning use
Choose the engine	Solver type	Box2D uses sequential impulses, which are mathematically equivalent to PGS	Pick an engine whose solver you can reason about before you build any levels.
Simulation setup	Timestep	About 1/60 second (about 16.7 ms) for a 60fps simulation	Fix the step early so every level is tuned against the same value.
Tuning: overlap	Overlap correction	Split bias velocity with a large bias factor reduced overlap 80% per step in the cited example; with merged velocity a large factor can overshoot	Correct overlap gently and test stacks, because aggressive correction can add energy.
Tuning: bounce	Restitution	Clip to 0 as a minimum, never negative; tune per situation	Treat bounce as a per-material setting you test, not one global number.

Figures come from a physics tutorial on integration and timesteps and a Bullet forum discussion of sequential impulse solvers and Box2D.

How to make a physics puzzle game comes down to three early decisions: choose a physics engine, simulate on a constant timestep, and design levels that stay fair when the simulation varies slightly.

Physics puzzles raise problems that general level design does not, so this guide stays on the simulation. For the wider production picture, see our indie puzzle game development hub.

Before prototyping: choose the engine

For a puzzle set in a flat plane, choose a rigid-body engine built on a sequential impulse solver, then commit to it before you design levels. Switching engines later changes how stacks settle and how objects bounce, so every finished level would need retesting.

Box2D and sequential impulses

Box2D is the reference point for flat rigid-body puzzles. A forum discussion of the solver describes it as using sequential impulses, which are mathematically equivalent to PGS. The same thread says the approach is very similar to an iterative LCP solver but easier to understand and implement. That ease matters for puzzle developers, because when a structure collapses unexpectedly you need to be able to reason about why.

Rigidbody2D and engine components

If you build in Unity, Rigidbody2D is the component that gives an object rigid-body behaviour, and colliders define its shape. The decisions in the rest of this guide apply whichever engine you use. A tutorial on integration also notes that most common physics engines avoid Verlet integration for rigid bodies, because it is not feasible to use directly with contact constraints. Rigid-body puzzles are therefore served by engines designed around contacts, not by cloth-style simulation code.

Browser alternatives

If you target the web, a JavaScript physics library is a realistic route. One public example on the GitHub physics-game topic is a physics-based casual puzzle game inspired by Angry Birds, built with Phaser 3 and Matter.js. For a wider comparison of full game engines, see our guide to the best game engine for puzzle games.

Prototype: one rule and a first construction level

A construction puzzle works best when the first prototype tests a single rule and nothing else. One puzzle design overview puts it plainly: a good puzzle game has one clear rule and explores it level by level.

1. Pick the rule. Choose one physical idea, such as balancing, bridging or launching, and name it in a sentence.
2. Build the smallest scene. Use a ground collider, a handful of rigid bodies and one goal condition.
3. Make the goal readable. The player should see why a structure holds or fails, so keep part shapes simple.
4. Play it repeatedly. Set up the same attempt again and again and watch whether the outcome changes.

Existing physics puzzle projects to study

Public projects show how others scope this genre. The GitHub physics-game topic lists 97 public repositories. One example there is a Rube Goldberg puzzle game drawn in crayon, with 100 levels and seven crayons that each have their own physics. That is a useful model of one idea, differing material behaviour, carrying a whole game.

Simulation setup: fixed timestep and repeatable runs

A fixed timestep is the foundation of consistency in a physics puzzle. The physics step should advance by the same amount every time, whatever the rendering frame rate does. A physics tutorial gives a typical step of 1/60 second for a 60fps simulation, which is about 16.7 ms.

A constant step does not guarantee identical results on every device, so treat it as necessary rather than sufficient. Check results on your target hardware, as described in the testing section below.

Integration order

The same tutorial recommends semi-implicit Euler, also called symplectic Euler, which updates velocity first and then position. It describes explicit Euler as less stable and more prone to numerical drift. Drift is a problem for a puzzle because a structure that should rest quietly may creep or jitter. Prefer an engine that already integrates in the stable order.

What resets each step

In the solver discussion, the bias velocity and impulse are initialized to zero each time step, with no warm starting. Each step therefore solves its contacts without carrying impulses over from the previous one. A tall stack is the place to watch for this, since small differences in how contacts resolve can decide whether it stands.

Tuning: overlap correction and bounce

Overlap correction and restitution are the two settings most likely to make a level feel unfair. Both can be tuned, and both can be pushed too far.

• Bias velocity. In the solver discussion, each body has a bias velocity used only for correcting overlap. Splitting it from the normal velocity, with a large bias factor, reduced overlap 80% per step. With merged velocity, a large bias factor is not recommended because the correction can overshoot.
• Extra energy. The same thread warns that penetration depth recovery can introduce extra energy or velocity. If blocks pop or shudder when a heavy piece lands on them, suspect overlap correction before blaming your level.
• Restitution floor. Clip restitution to 0 and never make it negative.
• Restitution per situation. The value applied has to be tuned for different situations, so give each material its own tested bounce.

Level design when physics are unpredictable

Design each level around outcomes players can reason about, not around one exact solution. Small differences in contact resolution are normal in a physics simulation, so a level that only works for one precise placement will feel broken.

• Keep one rule. The design overview advises that new levels come from combining what the player already knows, not from piling on new rules. For physics puzzles this also limits how many interacting behaviours you must tune.
• Reward margins. Make goals broad enough that a slightly different placement still succeeds. Reserve tight tolerances for later levels, after players understand the material behaviour.
• Test several solutions. Play each level in more than one way and confirm that every sensible approach reaches the same verdict.
• Keep materials stable. Because restitution needs tuning per situation, change a material’s bounce deliberately and retest every level that uses it.

Players learn physical rules best by experimenting, so pair early levels with a puzzle game tutorial design that demonstrates the rule without lengthy text.

Release testing on real devices

Test on the devices your players will use, because a puzzle that behaves in the editor can still differ on a phone. Run the same checks on each device you target.

1. Record a known solution. Save the placements for a level you have already solved.
2. Replay it repeatedly. Run the identical attempt many times on one device and note any difference in the result.
3. Repeat on other hardware. Compare outcomes between a desktop and at least one phone.
4. Check the edges. Pay most attention to tall stacks, heavy-on-light contacts and bouncing parts, where overlap correction and restitution matter most.
5. Adjust the level first. If a result varies, widen the goal margin before changing global physics settings, since those settings affect every other level.

Frequently asked questions

What is a construction puzzle?

A construction puzzle asks the player to assemble parts into a structure or machine, then lets the physics engine decide whether it works. The Rube Goldberg style is one familiar form of the idea.

Is Verlet integration a good choice for a rigid-body puzzle?

Usually not. A physics tutorial notes that Verlet simulation requires a constant timestep, and that most common engines avoid it because it is not feasible to use directly with contact constraints and rigid bodies.

What gravity value should I start with?

The same tutorial applies -9.81 m/s² to every object’s velocity each step in its example. Choose your gravity once and keep it fixed, so every level is built against the same rule.

Why do so many engines use sequential impulses?

A Bullet forum thread describes the algorithm as very similar to iterative LCP but easier to understand and implement. Bullet itself implements a 3D version with restitution support.