phaser-core

Phaser 4 Core

Set up the foundation of a Phaser game: the Game config, the Scene lifecycle, asset loading, cameras, and passing data between scenes. Targets Phaser 4.2 for new projects; keep an existing Phaser 3.90 project on its pinned major unless the user explicitly asks for a migration.

When to use

• Use when starting a Phaser game, wiring the Phaser.Game config, structuring Scenes, loading assets in preload, or fixing scene transitions and shared state.
• Use when the project has phaser in package.json or import Phaser from 'phaser', and code uses preload()/create()/update().

When not to use: movement, velocity, colliders, gravity, or overlap → use phaser-arcade-physics. Complex rigid-body simulation uses Matter physics (a separate concern). For cross-engine save/load patterns use save-systems.

Core workflow

1. Detect the installed major first. Read package.json and the lockfile. Use Phaser 4.2 for new work; do not silently rewrite a Phaser 3 project as Phaser 4.
2. Create the game from a config. new Phaser.Game(config) with type: Phaser.AUTO (WebGL with Canvas fallback), a width/height, and a scene array. The first scene (and any with active: true) starts automatically.
3. Model each screen as a Scene. Subclass Phaser.Scene, pass a unique key to super, and implement the lifecycle: init(data) → preload() → create(data) → update(time, delta).
4. Load assets in preload, use them in create. Queued assets are not available until create. The loader is per-scene; the cache it fills is global.
5. Reset per-run state in init(), not the constructor. A scene instance is reused across restarts, so constructor-set fields keep stale values.
6. Move between screens with this.scene.start/launch/switch/sleep/wake. Share data through this.registry (global) or a sibling scene's event emitter.
7. Run and observe. Serve the page, open it, and confirm assets load (watch the Network tab and console) and scenes switch as expected before assuming success.