2D Physics Engine: Everything You Need to Know

A 2D physics engine is the software layer that makes objects in a flat-plane game move, fall, collide, and bounce as if they had real mass and momentum. Every time a character lands on a platform, a crate tumbles off a ledge, or a ball ricochets off a wall, the engine has applied forces, integrated them into motion, and resolved the resulting collisions — all on the X and Y axes.

If you remember one thing, make it this: Box2D is the de facto standard, and the single most common reason a 2D game's physics "feels wrong" is wrong world scale — feeding pixels into a solver that expects meters. Everything else in this guide is detail around those two facts.

The global market for game engines is growing fast — Grand View Research puts it at about USD 3.07 billion in 2024, rising to USD 8.35 billion by 2030 at an 18.4% CAGR — and 2D is where most indie and mobile projects live, because a flat plane is cheaper to simulate and runs on weaker hardware. This guide covers what a 2D physics engine actually does, how collision detection works, how the main engines compare, and the setup mistakes to avoid.

What a 2D physics engine does#

A physics engine calculates the forces in a simulation so that objects behave according to the laws of physics, then converts those forces into motion. In 2D, everything happens on a flat plane — no depth, no perspective, no volumetric mass. That removes a whole axis of computation, which is why 2D physics is faster and cheaper to run than 3D, and why it dominates mobile.

Each simulation step runs the same pipeline:

1. Apply forces. Gravity, springs, player input, and joints push on bodies.
2. Compute acceleration. Newton's second law, F = ma, turns force into acceleration.
3. Integrate velocity. Acceleration updates each body's velocity over the time step.
4. Update position. Velocity moves the body, then collisions are detected and resolved.

A 2D engine handles three things: dynamics (forces, acceleration, torque), kinematics (motion and position), and collisions (detecting and resolving contact). One thing the standard engines do not handle is deformation — they simulate rigid bodies, which cannot bend or break. Cloth, rope, soft bodies, and fluids are out of scope for most of them. If you need fluid simulation, you reach for an extension: Google's LiquidFun added particle-based fluids and soft bodies on top of Box2D.

The core components#

Every major 2D engine — whether off-the-shelf or custom — is built from the same parts.

The physics world is the container that holds global settings: gravity (with separate X and Y components), a gravity scale per body, and the time step the simulation runs on.

Rigid bodies are what actually move. Every body is one of three types:

Body type	Affected by gravity?	How it moves	Use it for
Dynamic	Yes	Forces, impulses, velocity	Anything that should react to physics — players, crates, balls
Static	No	It doesn't — you place it once	Ground, walls, permanent platforms
Kinematic	No	You move it manually via velocity	Moving platforms, rotating hazards

Material properties define how a body behaves on contact. Density sets its mass (in 2D, mass divided by area). Friction resists sliding along a surface — near zero for ice, near one for sand. Restitution (or bounciness) is how much energy a body keeps after an impact — zero for a dead weight, 0.8 and above for a rubber ball.

Joints and constraints connect bodies into systems: revolute joints for hinges and wheels, prismatic joints for sliding along an axis, distance joints to hold two bodies a set length apart. They are what let you build ragdolls, rope bridges, and machinery.

How collision detection works#

Collision detection is the most expensive part of a physics simulation. If you have N objects, there are N(N−1)/2 possible pairs — 100 objects means roughly 5,000 checks, every step. No engine tests them all. Instead it uses a two-phase approach.

Broadphase is a fast, approximate pass that throws out pairs which cannot possibly be colliding. The standard tool is the axis-aligned bounding box (AABB) — a cheap rectangle around each object. If two AABBs do not overlap, the objects cannot be touching, so the pair is discarded immediately. What survives is a short list of pairs that might collide.

Narrowphase runs the exact, expensive geometry test only on that short list. It computes real contact points, the collision normal, and how deeply the shapes overlap — the penetration depth the solver needs to push them apart.

Collision resolution then separates the objects. The standard method is impulse-based: the engine applies an instantaneous change in velocity (an impulse) proportional to each body's inverse mass. This is why a bowling ball barely slows when it hits a ping-pong ball, while the ping-pong ball flies off — the lighter body absorbs most of the impulse.

One more concept matters for fast-moving objects: continuous collision detection (CCD). Without it, a bullet moving faster than its own length in a single frame can tunnel clean through a thin wall — the engine never sees the overlap because it happened between steps. CCD sweeps the object's motion across the step to catch these misses. Box2D supports it; Chipmunk2D does not.

The leading 2D physics engines compared#

Most developers never choose a physics engine directly — they use whatever their game engine bundles. But if you are picking a library, or evaluating what you are already running on, here is how the main options compare.

Engine	Language	Where it shines	CCD	License
Box2D	C/C++	The standard; Unity and GDevelop run on it	Yes	MIT
Chipmunk2D	C	Lightweight, portable native games	No	MIT
Matter.js	JavaScript	Browser games, easy API	No	MIT
Planck.js	JavaScript	Web games needing Box2D-level physics	Yes	MIT
Rapier	Rust / WASM	Modern 2D + 3D, deterministic multiplayer	Yes	Apache-2.0 / MIT

Box2D, created by Erin Catto and released in 2007, is the engine under Unity's 2D mode and GDevelop's Physics behavior. It is fast, stable, well-documented, and limits itself to 2D rigid bodies — no soft bodies or fluids out of the box. Godot is the notable exception: its default 2D physics is its own engine, Godot Physics 2D, and Box2D (or Rapier) is available only as a third-party add-on. Chipmunk2D is a lighter C library; its main limitation is the lack of CCD, which matters for shooters and pinball but not for slower games.

For the web, Matter.js is the friendliest to pick up, while Planck.js — a JavaScript port of Box2D — is the choice when you need Box2D's feature set and performance in a browser. Rapier, written in Rust with WebAssembly bindings, handles both 2D and 3D, runs in the browser, and offers a deterministic mode that makes it attractive for multiplayer games where physics state must stay in sync.

Setting up a 2D physics simulation#

A working simulation follows four steps. Get the first one right and most problems disappear.

1. Set the world scale first. Decide how many pixels equal one meter before touching any value. Box2D works best with moving objects between roughly 0.1 and 10 meters. If your player sprite is 64 pixels tall and represents a person, use 64 px = 1 m. This single decision prevents the floaty, sluggish feel that dooms most beginner physics.
2. Assign body types correctly. If it reacts to physics, it is dynamic. If it is permanent scenery, it is static. If you move it yourself but it should still push other bodies (a moving platform), it is kinematic. Mixing these up is the source of most "my platform is glitching" bugs.
3. Start from sane defaults. Density around 1.0 (water), friction 0.3–0.5 for ordinary surfaces, restitution 0.0–0.2 for most objects and 0.8+ for bouncy ones. Tune by feel from there.
4. Run physics on a fixed timestep. Physics must step at a consistent rate — Unity's default is 50 steps per second — independent of your frame rate. Tie it to the frame loop and your game behaves differently on a 60 Hz screen than a 144 Hz one.

For a deeper look at the iteration loop — how to tune mass, friction, and gravity and see the result the instant you change it — see our guide to the real-time physics editor. If you are newer to the underlying ideas, the game design basics guide covers how physics fits into the wider loop of prototyping and playtesting.

Common mistakes#

Most broken 2D simulations come from the same handful of errors.

Mistake	What happens	Fix
Using pixels as units	Objects are enormous in physics terms; gravity barely moves them; everything feels slow and floaty	Convert pixels to meters and keep moving objects around 0.1–10 m
Moving a static body	Jitter, teleporting, or bodies that refuse to collide properly	Use a kinematic body for anything you move manually
Creating joints every frame	Hundreds of joints in seconds, memory spikes, crashes	Create joints once, at scene start
Ignoring damping	Objects spin and slide forever, as if in a vacuum	Add small linear and angular damping (around 0.01–0.1)
Tying physics to the frame rate	Behavior changes between devices and frame rates	Keep physics on the fixed timestep

The world-scale mistake deserves the most emphasis, because no amount of tweaking individual bodies fixes it — the solver's internal math is built for meters. Get the scale right at the start and the rest of tuning becomes straightforward.

Beyond games#

Physics engines reach well past entertainment. In robotics and AI research, simulators train manipulation and locomotion policies in virtual sandboxes before anything touches real hardware — MuJoCo, open-sourced by Google DeepMind, has become a standard for reinforcement learning. In engineering, tools like Project Chrono run multi-physics simulations to test mechanical designs before expensive real-world prototyping. For these uses, determinism — reproducing the exact same outcome from the same inputs — matters more than raw speed, and the engines chosen for safety-critical work differ from the ones chosen for games.

Where Egmatic fits#

A 2D physics engine is powerful, but tuning it is still a loop: change a value, rebuild, watch, repeat. Egmatic builds 2D physics into the editor itself, so you can adjust a collider, raise gravity, or change friction and watch the simulation respond immediately — no rebuild step, no round trip through a build pipeline. That turns the feel-driven tuning physics demands into something closer to live editing. Combined with visual scripting and scene editing in the same tool, it keeps the whole 2D workflow — design, logic, physics — in one fast loop.

Conclusion#

A 2D physics engine simulates rigid bodies on a flat plane: it applies forces, integrates them into motion, and detects and resolves collisions through a broadphase-then-narrowphase pipeline. Box2D is the standard, and Unity and GDevelop already run on it; Godot ships its own engine. The engine you use matters less than two decisions: getting the world scale right, so the solver works in the meters it expects, and keeping physics on a fixed timestep, so it behaves consistently. Get those two things right, and the rest of physics — body types, materials, joints, collisions — falls into place.

---

Sources#

1. Box2D is a free, open-source 2D rigid-body physics engine created by Erin Catto, released under the MIT license — Box2D.org and Wikipedia: Box2D
2. Box2D is tuned for meters and works best with moving shapes between roughly 0.1 and 10 meters; do not use pixels as units — Box2D FAQ
3. Unity's 2D physics runs on Box2D; Unity 6.3 introduced low-level 2D physics based on Box2D v3 — Unity Discussions: Low-level 2D Physics in Unity 6.3 and Unity 2D Physics (Box2D): importance of scale
4. Godot's default 2D physics is its own engine (Godot Physics 2D / PhysicsServer2D); Box2D is available only as a third-party add-on — Godot issue #10592: Box2D physics engine implementation and godot-box2d add-on
5. Rapier is an open-source 2D and 3D physics engine written in Rust with WebAssembly bindings and a deterministic mode — Rapier.rs and @dimforge/rapier2d-deterministic on npm
6. Chipmunk2D is a lightweight 2D rigid-body physics library written in C under the MIT license — Chipmunk2D
7. The global game engines market was valued at about USD 3,072.6 million in 2024 and is projected to reach USD 8,345.2 million by 2030, growing at an 18.4% CAGR — Grand View Research: Game Engines Market
8. Continuous collision detection (CCD) prevents fast-moving objects from tunneling through thin surfaces; Box2D supports it — Box2D on GitHub
9. Unity runs physics on a fixed timestep (default 0.02 s, i.e. 50 Hz), independent of frame rate — Unity Manual: Time and Fixed Timestep
10. MuJoCo is an open-source physics simulator widely used for robotics and reinforcement learning — MuJoCo