Phaser 3 Arcade Physics Tutorial: When You Need It (and When You Don't)

Phaser 3 Arcade Physics Tutorial: When You Need It (and When You Don’t)

Honesty note: my game (Merge Fish 2048) uses no physics engine — merges are tweens, drag is pointer math, collisions are board-logic. I wrote this tutorial to answer the question I had as a beginner: does my game even need arcade physics? Here’s the honest answer, what physics gives you, and when to skip it entirely.

TL;DR

1. Arcade physics = simple AABB collisions + velocity + gravity for sprites. It’s the lightweight physics layer in Phaser 3 — great for platformers, breakout, falling objects, and clicker-game projectiles.
2. Many casual games never need it. Match-3, merge (2048-style), card games, puzzles, and most turn-based games resolve movement and “collisions” with board logic and tweens. Adding physics to these is pure per-frame overhead (frame cost breakdown).
3. If you need it, it’s ~10 lines to enable: physics: { default: 'arcade', arcade: { gravity: { y: 300 } } } in config, this.physics.add.existing(sprite), sprite.body.setVelocity(...), and this.physics.add.collider(a, b).
4. The decision framework: does your game need objects to fall, bounce, or collide with each other in continuous space? Yes → arcade physics. No → use tweens + your own logic, and save the frames.

What arcade physics actually does

Phaser’s arcade physics gives sprites:

• A body (AABB by default) with position, velocity, acceleration.
• Gravity — world gravity you configure (gravity: { y: 300 } means +300 px/s² downward).
• Collision and overlap detection — collider(a, b) (physical push-apart) vs overlap(a, b) (just detect).
• Bounds — setCollideWorldBounds(true) keeps objects in the world.

It’s intentionally simple: no rotation physics, no joints, no complex shapes (AABB only). That simplicity is the point — it’s cheap enough for HTML5.

When you need it (the yes cases)

• Platformers — jumping, gravity, landing on platforms: collider(player, platforms).
• Breakout / Pong / ball games — bouncing: body.setVelocity(), setBounce().
• Falling/stacking objects — gravity + colliders.
• Projectiles hitting targets — overlap(bullets, enemies) then deal damage.
• Any game where objects move freely and interact continuously in space.

Minimal working setup

// config
physics: {
  default: 'arcade',
  arcade: { gravity: { y: 300 }, debug: false }
}

// in a scene
this.player = this.physics.add.sprite(x, y, 'player');
this.player.setCollideWorldBounds(true);
this.player.body.setVelocityX(200);

this.crates = this.physics.add.group();
this.physics.add.collider(this.player, this.crates);

Ten lines, and you have a playable physics world.

When you don’t need it (the honest majority for casual games)

My merge game is the poster child: 2048-style grid, drag-to-merge, score pops, particles. Everything “collision-like” is:

• Grid logic — is the target cell occupied? That’s array math, not physics.
• Merge animation — tween the old tile into the new one (tween guide).
• Drag — pointer down/move/up events with coordinates.
• Particles — pooled sprites with manual motion (60fps guide).

Zero physics bodies, zero collider calls, and the game runs smoothly on mid-range phones. The same applies to match-3, card games, puzzles, turn-based games, and most menu-driven games. If your game is grid-based or turn-based, you almost certainly don’t need arcade physics.

The decision framework

Ask in order:

1. Do objects move continuously in space? (not on a grid, not in discrete steps) — no → skip physics.
2. Do they need gravity? — no → skip physics.
3. Do they need to physically push each other apart? (not just “detect and react with logic”) — no → skip physics.
4. If all three are yes → use arcade physics. Otherwise, tweens + your own logic is faster to write, easier to debug, and lighter on frames.

When in doubt, build the prototype without physics first. Adding it later to the objects that need it is straightforward; removing it from a game that never needed it is a refactor.

Pitfalls

1. Physics for grid games — every body is per-frame cost; a 2048 board with 16 physics bodies is pure waste.
2. Forgetting debug: false — physics debug rendering is a real frame cost; turn it off for production.
3. Huge bodies — AABB uses sprite size; oversized sprites (big PNGs) make collision feel wrong and cost GPU (asset pipeline bakes correct sizes).
4. Colliders with dynamic groups — adding/removing colliders per spawn is a common frame-cost leak; reuse groups.
5. Physics for polish effects — if you only want juice (pops, shards), pooled tweens/particles beat physics bodies.

Bottom line

Arcade physics is a precise tool for continuous-space movement games — platformers, ball games, projectiles. For the large family of casual web games (grid, merge, card, puzzle, turn-based), it’s overhead you don’t need: board logic + tweens resolve everything with fewer frames and fewer bugs. My 2048-merge game ships physics-free on purpose, and the 60fps budget stays intact (how frames get spent). Choose physics by your game’s motion model, not by what engines demo.