2D Game Physics: Rigid Bodies, Colliders, and Triggers
2D game physics rests on three building blocks you place in every scene: rigid bodies, the objects that carry simulated mass and motion; colliders, the shapes that detect contact between them; and triggers, the colliders that sense overlap without blocking anything. A dynamic body falls and gets pushed around; a static body is the immovable ground it lands on; a kinematic body is the moving platform neither of them shoves aside. Collisions fire callbacks the moment contact begins, stays, or ends, and collision layers decide which pairs interact at all. This guide explains what each primitive does, how they combine into player movement, pickups, and hazards, how Unity and Godot name the same ideas differently, and the mistakes that make 2D physics feel broken.
2D game physics rests on three building blocks you use in every scene: rigid bodies, the objects that carry simulated mass and motion; colliders, the shapes that detect contact; and triggers, the colliders that sense overlap without blocking anything. A platformer character is a rigid body with a collider. The floor beneath it is another. The coin the character collects is a trigger — it registers the overlap and disappears, but never blocks the player's path. Everything else in 2D physics — gravity, friction, restitution, joints, callbacks — hangs off these three primitives and the way you combine them.
This is the building-blocks guide. For how the engine under them works — the simulation pipeline, broadphase and narrowphase, the world-scale problem — see 2D physics engine: everything you need to know. For choosing which engine to run on, the 2D physics engines comparison ranks the options. Here we zoom in on the three things you actually place in a scene and wire together.
Rigid bodies: the objects that move
A rigid body is a physics object — something the simulation treats as having mass, position, velocity, and rotation, all governed by forces and collisions instead of by your direct placement. The word rigid matters: these bodies do not bend or break. They are single solid chunks, which is why a crate tumbles as a unit and a plank does not sag.
Every rigid body is one of three types, and which one you pick decides how it behaves.
| Body type | Gravity | Reacts to collisions | How it moves | Use it for |
|---|---|---|---|---|
| Dynamic | Yes | Yes | Forces, impulses, and velocity push it | The player, crates, balls — anything that should react |
| Static | No | No (others collide with it) | It does not — placed once, never moved | Ground, walls, permanent platforms |
| Kinematic | No | No | You move it via velocity | Moving platforms, rotating blades, doors |
Two rules carry most of this. A dynamic body is fully simulated — gravity pulls it, collisions shove it, and it shoves back. A static body is the immovable scenery other things bounce off. A kinematic body is the in-between: you drive it with code, so it has no gravity and cannot be knocked off course, but a dynamic body landing on it still rides along. That is exactly what a moving platform needs.
Colliders: the shapes that make contact
A collider is the invisible shape that defines where a body is solid. It is separate from the sprite you draw, and it should be: visual art and collision geometry serve different purposes. A round coin can have a square collider; a spiky character can have a simple capsule collider so it does not snag on every edge.
Colliders come in basic shapes for a reason. A box, circle, or capsule is cheap for the engine to test and stable under rotation. A polygon matches the art more closely but costs more and can behave unpredictably when it is concave. The practical advice is to use the simplest shape that reads correctly — a circle for a ball, a box for a crate, a capsule for a humanoid — and reach for polygons only where precision matters.
Each collider can carry a physics material that defines what happens on contact. Friction resists sliding, so a high-friction floor lets the player walk up a gentle slope and a near-zero one turns it into ice. Restitution is bounciness — how much energy a body keeps after impact — near zero for a dead-weight crate, above 0.8 for a rubber ball. These two numbers do most of the work of making surfaces feel different.
Triggers: colliders that sense instead of block
A trigger is a collider with one property flipped: it detects overlap but produces no physical response. Two bodies whose contact involves a trigger pass right through each other — nothing blocks, nothing bounces — but the engine still fires an event the moment they overlap. Some engines call this a sensor.
This is the mechanism behind every non-solid interaction in a game. A coin is a trigger the player walks through; the overlap fires, the coin is collected, and the player never slows down. An enemy's aggro radius is a trigger that switches the enemy to chase mode when the player enters it. A checkpoint, a level-exit zone, a damage area left by an explosion — all triggers. The pattern is the same: sense the contact, run the logic, skip the physics response.
Colliders versus triggers: the one distinction that matters
New developers lose hours to confusing these two, because they look identical in an editor — both are shapes attached to a body. The difference is entirely in what they do on contact.
| Collider | Trigger | |
|---|---|---|
| Blocks movement | Yes | No |
| Produces a physical response (push, bounce) | Yes | No |
| Fires an event on overlap | Yes | Yes |
| Typical use | Floor, walls, the player, crates | Pickups, detection zones, checkpoints, hazards |
The failure modes are mirror images. Make the player a pure trigger and it falls through the floor. Make a coin a solid collider and the player bounces off it instead of collecting it. When a physics interaction feels wrong, the first question to ask is whether each shape involved is set to be solid or to sense.
Wiring the blocks together: events and layers
Placing the bodies is half the job; the other half is responding when they meet. Two mechanisms connect the primitives to your game logic.
Collision callbacks fire at three moments for each contact pair: on enter, when the overlap begins; on stay, every physics step the overlap continues; and on exit, when it ends. Solid collisions and triggers each have their own set. This is how you write code that reacts the instant contact happens rather than polling for it every frame.
Collision layers and masks decide which bodies are even allowed to interact, so the engine skips pairs you do not care about. A layer names a group — player, enemies, projectiles, scenery. A mask lists which other groups a body collides with or senses. Put the player on a Player layer that collides with Scenery but ignores other players, and let enemy-detection triggers sense only the Player layer. Layers are both a correctness tool (the player's bullets do not hit the player) and a performance tool (the engine never tests the pairs you filtered out).
The physics step, briefly
All of this runs on a fixed timestep: the simulation advances in constant slices of time — 50 steps a second is a common default — independent of how fast the screen redraws. Keeping the step constant is what makes a jump arc identical on a 60 Hz phone and a 144 Hz monitor. One fast-moving object can break that stability by tunneling: stepping from one side of a thin wall to the other between checks, so the engine never sees the overlap. Continuous collision detection fixes it by sweeping the body's motion across the step instead of sampling a point. The physics engine guide covers the pipeline in depth; the point here is that the step is the heartbeat your bodies, colliders, and triggers all move to.
How the engines name the same ideas
The three primitives are universal, but every engine calls them something different. The same concept that is a checkbox in one tool is a separate node in another.
| Concept | Unity (2D) | Godot |
|---|---|---|
| Dynamic body | Rigidbody2D (Body Type: Dynamic) | RigidBody2D |
| Static body | Rigidbody2D (Body Type: Static) | StaticBody2D |
| Kinematic body | Rigidbody2D (Body Type: Kinematic) | AnimatableBody2D |
| Player you move yourself | Rigidbody2D, or a custom controller | CharacterBody2D |
| Collision shape | Collider2D (Box / Circle / Polygon) | CollisionShape2D + a Shape2D resource |
| Trigger | Collider2D with "Is Trigger" checked | Area2D |
| Solid-collision event | OnCollisionEnter2D (and Stay / Exit) | body_entered / body_exited signals |
| Trigger event | OnTriggerEnter2D (and Stay / Exit) | area_entered / body_entered on Area2D |
One nuance worth knowing: in Godot, a CharacterBody2D is a kinematic-style body you move yourself with move_and_slide, not a body the solver pushes around. Unity has the same idea — many platformers do not put the player under full dynamic simulation at all, but move it manually and use colliders only to resolve the resulting contact. Both approaches are legitimate; the trade-off is between physics-driven realism and tight, predictable control.
Common mistakes
| Mistake | What goes wrong | What to do instead |
|---|---|---|
| Making the player a trigger | It falls through the floor and every wall | Give the player a solid collider; reserve triggers for sensing |
| Moving a static body directly | Jitter, teleporting, missed collisions | Use a kinematic body for anything you move by code |
| Collider copied from the sprite | Snagging on edges, imprecise contact | Use a simple shape (box / circle / capsule) sized for the gameplay |
| Reading physics in the frame update | Missed or duplicated contacts | Handle contact in the physics step (FixedUpdate / _physics_process) |
| No CCD on fast projectiles | Tunneling through thin walls | Enable continuous collision detection on fast bodies |
| Everything on one collision layer | Objects collide that should not | Split bodies into layers and set masks deliberately |
For the wider set of setup errors — world scale, joints created every frame, physics tied to frame rate — the common physics mistakes guide goes deeper, and the physics bug-fixing guide covers what to do when it is already broken.
How Egmatic fits
Working with these primitives is fundamentally a tuning loop: drop a collider, run the scene, watch whether the crate slides or the coin registers, adjust, repeat. Anything that adds a step between changing a value and seeing the result — a build, a re-import, a context switch — slows the tuning itself.
Egmatic is built around that loop. Its 2D scene editor lets you place a rigid body, shape a collider, and flip a shape into a trigger, then run the scene and feel the contact immediately. Because physics, scene composition, and the game logic that responds to collision callbacks live in one tool with live preview, the round trip from "the coin didn't register" to "the trigger fires and the coin disappears" is seconds, not a build cycle. For the broader case for a fast preview loop, the real-time physics editor guide makes it directly.
Conclusion
Three primitives carry 2D game physics. Rigid bodies are the objects that move, split into dynamic, static, and kinematic by how they should respond to the world. Colliders are the solid shapes that make them contact and block each other, tuned by friction and restitution. Triggers are the sensing shapes that detect overlap without blocking, powering every pickup, detection zone, and checkpoint. Wire them with collision callbacks for logic and collision layers for filtering, keep them on a fixed timestep with CCD for anything fast, and you have the full vocabulary of 2D physics interaction. The names change between engines, but the ideas — body, collider, trigger — do not.
Sources
- The three rigid-body types (dynamic, static, kinematic) and how they differ in gravity response and collision reaction — Box2D manual: Bodies, Unity Manual: Rigidbody 2D body types
- A trigger (sensor) is a fixture that detects overlap but generates no collision response — Box2D manual: Sensors
- Collision and trigger callbacks (enter / stay / exit) for 2D contact — Unity Manual: Collider2D events (OnCollisionEnter2D, OnTriggerEnter2D)
- Godot 2D physics nodes: RigidBody2D, StaticBody2D, AnimatableBody2D, CharacterBody2D, CollisionShape2D, and Area2D as the trigger/sensor node — Godot documentation: Physics in 2D
- Godot's body_entered / body_exited / area_entered signals for detecting contact and overlap — Godot documentation: Using Area2D
- Physics should run on a fixed timestep independent of frame rate — Unity Manual: Time and fixed timestep, Glenn Fiedler, Fix Your Timestep!
- Continuous collision detection prevents fast-moving objects from tunneling through thin surfaces — Box2D on GitHub
- Collision layers and masks for filtering which bodies interact — Unity Manual: Layer-based collision detection, Godot documentation: Collision layers and masks