Every game development tutorial starts the same way: colored rectangles sliding across a gray canvas. That is fine for l

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

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