Build fast, polished 2D browser games using Phaser 3’s scene-based architecture and physics systems.

Games are not static UIs—they are dynamic systems where entities interact, state evolves, and player input drives everything.

Before building, ask:

Core principles:

❌ Global state soup: Storing game state on or module globals
Why bad: scene transitions become fragile; debugging becomes chaotic
Better: scene data, registries, or a dedicated state manager

❌ Loading in

create()

: Loading assets in instead of
Why bad: assets may not be ready when referenced
Better: load in ; use a Boot scene for all assets

❌ Frame-dependent logic: Using frame count instead of
Why bad: game speed varies with frame rate
Better: scale by for consistent movement/timers

❌ Physics overkill: Using Matter for simple platformer collisions
Why bad: unnecessary complexity + perf cost
Better: Arcade covers most 2D collision needs

❌ Monolithic scenes: One giant scene with all game logic
Why bad: hard to extend; UI/menus/pause become hacks
Better: separate gameplay vs UI overlay vs menus

❌ Magic numbers everywhere: Hardcoded tuning values scattered in code
Why bad: balancing becomes painful; changes cause regressions
Better: config objects/constants and centralized tuning

❌ No pooling for spammy objects: Creating/destroying bullets/particles constantly Why bad: GC spikes → stutters Better: object pooling with groups + /

❌ Assuming spritesheet frame dimensions: Using guessed frame sizes without verifying source asset Why bad: wrong dimensions cause silent frame corruption; off-by-pixels compounds into broken visuals Better: open asset file, measure frames, calculate with spacing/margin, verify math adds up

❌ Ignoring spritesheet spacing: Not specifying for gapped spritesheets Why bad: frames shift progressively; later frames read wrong pixel regions Better: check source asset for gaps between frames; use in loader config

❌ Hardcoding nine-slice colors: Using single background color for all UI panel variants Why bad: transparent frame edges reveal wrong color for different asset color schemes Better: per-asset background color config; sample from center frame (frame 4)

❌ Nine-slice with padded frames: Treating the full frame as the slice region when the art is centered/padded inside each tile Why bad: edge tiles contribute interior fill, showing up as opaque “side bars” inside the panel Better: trim tiles to their effective content bounds (alpha bbox) and composite/cache a texture; add ~1px overlap + disable smoothing to avoid seams

❌ Scaling discontinuous UI art: Scaling a cropped banner/ribbon row that contains internal transparent gaps Why bad: the transparent gutters scale too, making the UI look “broken” or segmented Better: slice into left/center/right (or similar), stretch only the center, and stitch into a cached texture at the target size

Outputs should vary based on:

Avoid converging on:

Phaser gives powerful primitives—scenes, sprites, physics, input—but architecture is your responsibility.

Think in systems: define the scenes, define the entities, define their interactions—then implement.