Every game development tutorial starts the same way: colored rectangles sliding across a gray canvas. That is fine for learning syntax, but it teaches you nothing about how a game engine actually breathes. I wanted out of the rectangle business. I wanted to build something that felt like a real game—a top-down dungeon crawler with movement, combat, a HUD, and sound.

I committed to Phaser v4 and gave myself one hard rule. Zero external assets. No image files, no audio clips, and no build tools like Webpack or Vite. The entire project had to live inside a single HTML file written with plain JavaScript. That constraint was not about minimalism for its own sake. It was about removing every excuse and every black box. When you cannot download a sprite pack to cover up a gap in your knowledge, you are forced to learn how the engine manages textures, animations, audio, and state under the hood.

Disegnare il mondo tramite codice

In un normale progetto Phaser, chiami this.load.image() all'interno di una funzione di preload e indichi al motore un file PNG. Senza quell'opzione, ti rivolgi all'oggetto Graphics. Lo istanzi, disegni forme primitive — rettangoli per le piastrelle del pavimento, tratti più spessi per le pareti, magari un cerchio per il token del giocatore — e poi chiami generateTexture. Quel metodo cattura il buffer grafico e lo registra nel texture manager di Phaser sotto una chiave a tua scelta.

Da quel momento in poi, il motore tratta quel bitmap generato esattamente come un file immagine caricato. Puoi assegnarlo a tilemap, dividerlo in sprite o colorarlo. Per il dungeon crawler, questo significava che potevo generare proceduralmente una griglia del pavimento, applicare segmenti di muro e iterare sulla tavolozza dei colori senza mai lasciare l'editor di codice. La lezione pratica è che una texture è solo un blocco di dati bitmap memorizzati in memoria. A Phaser non importa se è arrivata tramite una richiesta HTTP o una chiamata Graphics scritta a mano.

Questo approccio ti costringe anche a riflettere deliberatamente sull'ordine di disegno e sul batching. Quando ogni muro e ogni piastrella del pavimento proviene dalla stessa famiglia di texture generate, inizi a prestare attenzione a come Phaser raggruppa le chiamate di rendering. Noti la differenza tra un livello di tilemap statico e una spritemap di oggetti individuali perché stai decidendo manualmente quale meriti di esistere come istanza di texture.

Animare senza spritesheet

I quadrati statici diventano noiosi rapidamente, ma il sistema di animazione di Phaser si aspetta uno spritesheet — solitamente un singolo PNG con i frame disposti in una griglia. Ho replicato quella striscia utilizzando un elemento HTML canvas offscreen. Per ogni frame di un'animazione, ho svuotato il canvas e disegnato una nuova posa: un semplice fendente di spada, un ciclo di camminata in due passi o un leggero movimento di attesa di un nemico. Una volta completata la striscia, l'ho registrata in Phaser come spritesheet, definendo la larghezza e l'altezza dei frame in modo che il motore sapesse dove finiva una posa e dove iniziava la successiva.

Fare questo manualmente rivela esattamente cosa sia un'animazione sotto la superficie: un insieme di confini di frame su una texture condivisa. Il componente di animazione di Phaser richiede un frame di inizio, un frame di fine e un frame rate. Poi fa avanzare un puntatore attraverso quei ritagli rettangolari a ogni tick dell'orologio di gioco. Smetti di pensare agli spritesheet come asset magici prodotti dagli artisti e inizi a vederli come matematica delle coordinate. Questa prospettiva è inestimabile in seguito, quando dovrai ritagliare arte reale o fare il debugging del motivo per cui un'animazione riproduce i frame fuori ordine.

Suono dal nulla

I file audio erano banditi, quindi ho usato direttamente la Web Audio API. Poche righe di JavaScript possono creare un nodo oscillatore, impostarlo su un'onda quadra o sinusoidale, farlo passare attraverso un nodo gain e programmare un breve impulso sonoro. Ho scritto dei piccoli helper per gli eventi comuni: un bip a bassa frequenza per i passi, un trillo crescente per il recupero del bottino e un tono aspro a onda quadra per quando si subiscono danni.

Questi suoni sintetizzati sono dei placeholder per design, ma forniscono immediatamente un feedback meccanico al gioco. Puoi percepire se il timing è corretto prima di impegnarti nella registrazione o nella ricerca di audio reali. Il vero vantaggio risiede nell'architettura. Poiché hai racchiuso l'attivazione del suono in una semplice funzione, sostituire il bip sintetizzato con un buffer audio caricato in seguito richiede il cambio di una singola riga. Il resto del gioco — l'evento di collisione, il flash della UI, l'incremento del punteggio — rimane invariato. Prototipi la sensazione prima, poi aumenti la fedeltà.

Gestire mondi multipli

A real game needs more than one screen, so I split the project into separate Phaser scenes: Menu, Game, UI, and Pause. The UI scene runs in parallel with the Game scene, launched simultaneously so the health bar and score counter live in their own sandbox while the dungeon crawls below. They communicate strictly through events. When the player takes damage, the Game scene emits a change. The UI scene listens and updates its text objects. The Game scene does not import the UI, call its methods, or even check if it exists. It simply sends data into the void. That decoupling means you can yank the HUD out for testing, or replace it entirely, without touching the core game loop.

For pausing, I used a stacked Pause scene that sits on top of the Game scene. Crucially, calling scene.pause() on the Game scene actually freezes the physics world and halts timers. The Game scene stops updating, but the Pause scene remains awake to render a menu and wait for an unpause signal. If you have only ever managed pause states with a boolean flag inside one giant update loop, this feels like discovering a light switch. The engine gives you a real pause lifecycle rather than forcing you to pepper your code with if (isPaused) return guards.

Hard Lessons from Real Bugs

Working this close to the metal exposed two habits I needed to change.

First, I tried to use a method in Phaser v4 that looked public but was not part of the documented API. It changed between versions and broke my build. I refactored to use getChildren(), which is a stable, documented public method, and the instability vanished. The lesson is blunt: if a method is not in the official documentation, do not build your game on it. Internal APIs are internal for a reason. Stick to the public surface area and your project will survive engine updates.

Second, I learned never to trust events for everything. Event callbacks work perfectly well for low-stakes interactions like picking up a coin or opening a chest. But for critical state transitions—especially Game Over—I added a redundant check inside the main update loop. Events can misfire if a listener is removed, a scene pauses at an awkward microsecond, or a race condition sneaks in between emission and handling. By checking the player’s health directly in the update loop and forcing the game-over state if it hits zero, I ensured the game could never get stuck in a limbo state if an event failed to fire. The events still handle the secondary effects—screen shake, sound cues, score submission—but the authoritative logic lives where the game clock lives.

Why You Should Try This

If you are learning game development, impose this exact constraint on your next project: no external assets, one HTML file. It sounds restrictive, but it removes every excuse. You do not need to configure a bundler, wrestle with CORS errors on local audio files, or spend an afternoon curating free asset packs. You write code, you refresh the browser, and you see results.

More importantly, you will understand why the engine behaves the way it does. You will know how a texture enters the GPU because you called generateTexture. You will know how animation frames are indexed because you registered the boundaries by hand. You will know how audio reaches the speakers because you wired the oscillator. That knowledge transfers directly to larger projects that do use external assets, because the underlying mechanics never change—the engine