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.

Drawing the World from Code

In a normal Phaser project, you call this.load.image() inside a preload function and point the engine toward a PNG file. Without that option, you turn to the Graphics object. You instantiate it, draw primitive shapes—rectangles for floor tiles, thicker strokes for walls, maybe a circle for a player token—and then call generateTexture. That method captures the graphics buffer and registers it with Phaser’s texture manager under a key you choose.

From that moment on, the engine treats that generated bitmap exactly like a loaded image file. You can assign it to tilemaps, slice it into sprites, or tint it. For the dungeon crawler, this meant I could procedurally generate a floor grid, stamp down wall segments, and iterate on the color palette without ever leaving my code editor. The practical lesson is that a texture is just a chunk of bitmap data sitting in memory. Phaser does not care whether it arrived via HTTP request or a hand-coded Graphics call.

This approach also makes you think deliberately about draw order and batching. When every wall and floor tile comes from the same family of generated textures, you start paying attention to how Phaser groups render calls. You notice the difference between a static tilemap layer and a spritemap of individual objects because you are manually deciding which deserves to exist as a texture instance.

Animating Without Spritesheets

Static squares grow stale quickly, but Phaser’s animation system expects a spritesheet—usually a single PNG with frames laid out in a grid. I replicated that strip using an offscreen HTML canvas element. For each frame of an animation, I cleared the canvas and drew a new pose: a simple sword swing, a two-step walk cycle, or an enemy idle bob. Once the strip was complete, I registered it with Phaser as a spritesheet, defining the frame width and height so the engine knew where one pose ended and the next began.

Doing this manually reveals exactly what an animation is under the surface: a set of frame boundaries on a shared texture. Phaser’s animation component asks for a start frame, an end frame, and a frame rate. It then advances a pointer through those rectangular slices on each tick of the game clock. You stop thinking of spritesheets as magical assets produced by artists and start seeing them as coordinate math. That perspective is invaluable later when you are slicing real art or debugging why an animation plays frames out of order.

Sound from Nothing

Audio files were banned, so I used the Web Audio API directly. A few lines of JavaScript can create an oscillator node, set it to a square or sine wave, pipe it through a gain node, and schedule a short burst of sound. I wrote tiny helpers for common events: a low-frequency beep for footsteps, a rising chirp for picking up loot, and a harsh square-wave tone for taking damage.

These synthesized sounds are placeholders by design, but they give the game mechanical feedback immediately. You can feel whether the timing is right before you commit to recording or sourcing real audio. The real payoff comes in the architecture. Because you wrapped the sound trigger in a simple function, swapping the synthesized beep for a loaded sound buffer later takes a single line change. The rest of the game—the collision event, the UI flash, the score increment—stays untouched. You prototype the feel first, then upgrade the fidelity.

Managing Multiple Worlds

Un vrai jeu nécessite plus d'un écran, j'ai donc divisé le projet en scènes Phaser distinctes : Menu, Game, UI et Pause. La scène UI s'exécute en parallèle de la scène Game, lancée simultanément afin que la barre de vie et le compteur de score vivent dans leur propre sandbox pendant que l'exploration du donjon se déroule en dessous. Elles communiquent strictement via des événements. Lorsque le joueur subit des dégâts, la scène Game émet un changement. La scène UI écoute et met à jour ses objets textuels. La scène Game n'importe pas l'UI, n'appelle pas ses méthodes et ne vérifie même pas si elle existe. Elle se contente d'envoyer des données dans le vide. Ce découplage signifie que vous pouvez extraire l'HUD pour des tests, ou le remplacer entièrement, sans toucher à la boucle de jeu principale.

Pour la mise en pause, j'ai utilisé une scène Pause superposée qui se place au-dessus de la scène Game. Point crucial : appeler scene.pause() sur la scène Game gèle réellement le monde physique et interrompt les minuteurs. La scène Game cesse de se mettre à jour, mais la scène Pause reste active pour afficher un menu et attendre un signal de reprise. Si vous n'avez jusqu'ici géré les états de pause qu'avec un flag booléen à l'intérieur d'une seule et immense boucle de mise à jour, cela donne l'impression de découvrir un interrupteur. Le moteur vous offre un véritable cycle de vie de pause plutôt que de vous forcer à parsemer votre code de gardes if (isPaused) return.

Leçons difficiles tirées de bugs réels

Travailler aussi près du matériel a révélé deux habitudes que je devais changer.

Premièrement, j'ai essayé d'utiliser une méthode dans Phaser v4 qui semblait publique mais qui ne faisait pas partie de l'API documentée. Elle a changé entre les versions et a cassé mon build. J'ai refactorisé pour utiliser getChildren(), qui est une méthode publique stable et documentée, et l'instabilité a disparu. La leçon est brutale : si une méthode ne figure pas dans la documentation officielle, ne construisez pas votre jeu dessus. Les API internes sont internes pour une raison. Tenez-vous-en à la surface publique et votre projet survivra aux mises à jour du moteur.

Deuxièmement, j'ai appris à ne jamais tout confier aux événements. Les rappels d'événements fonctionnent parfaitement pour des interactions sans grand enjeu, comme ramasser une pièce ou ouvrir un coffre. Mais pour les transitions d'état critiques — en particulier le Game Over — j'ai ajouté une vérification redondante à l'intérieur de la boucle de mise à jour principale. Les événements peuvent échouer si un écouteur est supprimé, si une scène se met en pause à une microseconde inopportune, ou si une condition de concurrence s'immisce entre l'émission et le traitement. En vérifiant directement la santé du joueur dans la boucle de mise à jour et en forçant l'état de fin de partie si elle atteint zéro, je me suis assuré que le jeu ne puisse jamais rester bloqué dans un état de transition si un événement ne se déclenchait pas. Les événements gèrent toujours les effets secondaires — tremblement d'écran, indices sonores, soumission du score — mais la logique faisant autorité réside là où réside l'horloge du jeu.

Pourquoi vous devriez essayer cela

Si vous apprenez le développement de jeux, imposez-vous exactement cette contrainte pour votre prochain projet : aucun asset externe, un seul fichier HTML. Cela semble restrictif, mais cela élimine toute excuse. Vous n'avez pas besoin de configurer un bundler, de lutter contre des erreurs CORS sur des fichiers audio locaux, ou de passer une après-midi à sélectionner des packs d'assets gratuits. Vous écrivez du code, vous rafraîchissez le navigateur, et vous voyez les résultats.

Plus important encore, vous comprendrez pourquoi le moteur se comporte ainsi. Vous saurez comment une texture entre dans le GPU parce que vous avez appelé generateTexture. Vous saurez comment les images d'animation sont indexées parce que vous avez enregistré les limites manuellement. Vous saurez comment l'audio atteint les haut-parleurs parce que vous avez câblé l'oscillateur. Ces connaissances se transfèrent directement vers des projets plus vastes qui utilisent des assets externes, car les mécanismes sous-jacents ne changent jamais — le moteur