ਹਰ ਗੇਮ ਡਿਵੈਲਪਮੈਂਟ ਟਿਊਟੋਰਿਅਲ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਗ੍ਰੇ ਕੈਨਵਸ 'ਤੇ ਰੰਗੀਨ ਆਇਤਾਂ (rectangles) ਦਾ ਸਰਕਾਉਟ। ਇਹ ਸਿੰਟੈਕਸ (syntax) ਸਿੱਖਣ ਲਈ ਠੀਕ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਸਿਖਾਉਂਦਾ ਕਿ ਇੱਕ ਗੇਮ ਇੰਜਣ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਮੈਂ ਇਸ ਆਇਤਾਂ ਵਾਲੇ ਕੰਮ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣਾ ਚਾਹੁੰਦਾ ਸੀ। ਮੈਂ ਕੁਝ ਅਜਿਹਾ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਜੋ ਇੱਕ ਅਸਲੀ ਗੇਮ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ—ਮੂਵਮੈਂਟ, ਕੰਬੈਟ (combat), ਇੱਕ HUD, ਅਤੇ ਸਾਊਂਡ ਦੇ ਨਾਲ ਇੱਕ ਟੌਪ-ਡਾਊਨ ਡੰਜਨ ਕਰਲਰ (top-down dungeon crawler)।
ਮੈਂ Phaser v4 ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਸਖ਼ਤ ਨਿਯਮ ਦਿੱਤਾ। ਜ਼ੀਰੋ ਬਾਹਰੀ ਐਸੇਟਸ (external assets)। ਕੋਈ ਇਮੇਜ ਫਾਈਲਾਂ ਨਹੀਂ, ਕੋਈ ਆਡੀਓ ਕਲਿੱਪ ਨਹੀਂ, ਅਤੇ Webpack ਜਾਂ Vite ਵਰਗੇ ਕੋਈ ਬਿਲਡ ਟੂਲ ਨਹੀਂ। ਪੂਰਾ ਪ੍ਰੋਜੈਕਟ ਸਿਰਫ਼ ਪਲੇਨ JavaScript ਨਾਲ ਲਿਖੀ ਇੱਕ ਸਿੰਗਲ HTML ਫਾਈਲ ਦੇ ਅੰਦਰ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਉਹ ਸੀਮਾ ਸਿਰਫ਼ ਮਿਨੀਮਲਿਜ਼ਮ (minimalism) ਲਈ ਨਹੀਂ ਸੀ। ਇਹ ਹਰ ਬਹਾਨੇ ਅਤੇ ਹਰ 'ਬਲੈਕ ਬਾਕਸ' ਨੂੰ ਹਟਾਉਣ ਬਾਰੇ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਗਿਆਨ ਦੀ ਕਮੀ ਨੂੰ ਛੁਪਾਉਣ ਲਈ ਕੋਈ ਸਪ੍ਰਾਈਟ ਪੈਕ (sprite pack) ਡਾਊਨਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਸਿੱਖਣ ਲਈ ਮਜਬੂਰ ਹੋ ਜਾਂਦੇ ਹੋ ਕਿ ਇੰਜਣ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਟੈਕਸਚਰ (textures), ਐਨੀਮੇਸ਼ਨਾਂ, ਆਡੀਓ ਅਤੇ ਸਟੇਟ (state) ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ।
ਕੋਡ ਤੋਂ ਦੁਨੀਆ ਬਣਾਉਣਾ
ਇੱਕ ਆਮ Phaser ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ preload ਫੰਕਸ਼ਨ ਦੇ ਅੰਦਰ this.load.image() ਕਾਲ ਕਰਦੇ ਹੋ ਅਤੇ ਇੰਜਣ ਨੂੰ ਇੱਕ PNG ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹੋ। ਉਸ ਵਿਕਲਪ ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ Graphics ਆਬਜੈਕਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਇੰਸਟੈਂਸ਼ੀਏਟ (instantiate) ਕਰਦੇ ਹੋ, ਮੁੱਢਲੇ ਆਕਾਰ (primitive shapes) ਬਣਾਉਂਦੇ ਹੋ—ਫਰਸ਼ ਦੀਆਂ ਟਾਈਲਾਂ ਲਈ ਆਇਤਾਂ, ਕੰਧਾਂ ਲਈ ਮੋਟੀਆਂ ਲਾਈਨਾਂ, ਸ਼ਾਇਦ ਖਿਡਾਰੀ ਦੇ ਟੋਕਨ ਲਈ ਇੱਕ ਚੱਕਰ—ਅਤੇ ਫਿਰ generateTexture ਕਾਲ ਕਰਦੇ ਹੋ। ਉਹ ਮੈਥਡ ਗ੍ਰਾਫਿਕਸ ਬਫਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਚੁਣੇ ਗਏ ਕੀ (key) ਦੇ ਅਧੀਨ Phaser ਦੇ ਟੈਕਸਚਰ ਮੈਨੇਜਰ ਵਿੱਚ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ।
ਉਸ ਪਲ ਤੋਂ, ਇੰਜਣ ਉਸ ਤਿਆਰ ਕੀਤੇ ਬਿਟਮੈਪ (bitmap) ਨਾਲ ਬਿਲਕੁਲ ਇੱਕ ਲੋਡ ਕੀਤੀ ਇਮੇਜ ਫਾਈਲ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ tilemaps ਨੂੰ ਅਸਾਈਨ ਕਰ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ sprites ਵਿੱਚ ਕੱਟ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਸਦਾ ਰੰਗ ਬਦਲ ਸਕਦੇ ਹੋ। ਡੰਜਨ ਕਰਲਰ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਮੈਂ ਆਪਣੇ ਕੋਡ ਐਡੀਟਰ ਨੂੰ ਛੱਡੇ ਬਿਨਾਂ ਹੀ ਇੱਕ ਫਰਸ਼ ਦਾ ਗਰਿੱਡ (floor grid) ਪ੍ਰੋਸੀਜੁਰਲੀ (procedurally) ਤਿਆਰ ਕਰ ਸਕਦਾ ਸੀ, ਕੰਧਾਂ ਦੇ ਹਿੱਸੇ ਲਗਾ ਸਕਦਾ ਸੀ, ਅਤੇ ਰੰਗਾਂ ਦੇ ਪੈਲੇਟ (color palette) ਵਿੱਚ ਬਦਲਾਅ ਕਰ ਸਕਦਾ ਸੀ। ਵਿਹਾਰਕ ਸਬਕ ਇਹ ਹੈ ਕਿ ਇੱਕ ਟੈਕਸਚਰ ਸਿਰਫ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਿਆ ਬਿਟਮੈਪ ਡੇਟਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ। Phaser ਨੂੰ ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਇਹ HTTP ਰਿਕਵੈਸਟ ਰਾਹੀਂ ਆਇਆ ਹੈ ਜਾਂ ਹੱਥ ਨਾਲ ਲਿਖੇ Graphics ਕਾਲ ਰਾਹੀਂ।
ਇਹ ਪਹੁੰਚ ਤੁਹਾਨੂੰ ਡਰਾਅ ਆਰਡਰ (draw order) ਅਤੇ ਬੈਚਿੰਗ (batching) ਬਾਰੇ ਵੀ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਕੰਧ ਅਤੇ ਫਰਸ਼ ਦੀ ਟਾਈਲ ਤਿਆਰ ਕੀਤੇ ਟੈਕਸਚਰਾਂ ਦੇ ਇੱਕੋ ਪਰਿਵਾਰ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਗੱਲ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਕਿ Phaser ਰੈਂਡਰ ਕਾਲਾਂ (render calls) ਨੂੰ ਕਿਵੇਂ ਗਰੁੱਪ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਸਟੈਟਿਕ tilemap ਲੇਅਰ ਅਤੇ ਵੱਖ-ਵੱਖ ਆਬਜੈਕਟਾਂ ਦੇ spritemap ਵਿਚਕਾਰ ਅੰਤਰ ਦੇਖਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਖੁਦ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਕਿਸ ਨੂੰ ਟੈਕਸਚਰ ਇੰਸਟੈਂਸ ਵਜੋਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Spritesheets ਤੋਂ ਬਿਨਾਂ ਐਨੀਮੇਸ਼ਨ ਕਰਨਾ
ਸਟੈਟਿਕ ਵਰਗ (squares) ਜਲਦੀ ਬੋਰਿੰਗ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਰ Phaser ਦਾ ਐਨੀਮੇਸ਼ਨ ਸਿਸਟਮ ਇੱਕ spritesheet ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ—ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਿੰਗਲ PNG ਜਿਸ ਵਿੱਚ ਫਰੇਮ ਇੱਕ ਗਰਿੱਡ ਵਿੱਚ ਸੈੱਟ ਹੁੰਦੇ ਹਨ। ਮੈਂ ਇੱਕ offscreen HTML canvas ਐਲੀਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸ ਸਟ੍ਰਿਪ ਦੀ ਨਕਲ ਕੀਤੀ। ਐਨੀਮੇਸ਼ਨ ਦੇ ਹਰ ਫਰੇਮ ਲਈ, ਮੈਂ ਕੈਨਵਸ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਅਤੇ ਇੱਕ ਨਵਾਂ ਪੋਜ਼ (pose) ਬਣਾਇਆ: ਇੱਕ ਸਧਾਰਨ ਤਲਵਾਰ ਦੀ ਸਵਿੰਗ, ਦੋ-ਕਦਮਾਂ ਵਾਲਾ ਚੱਲਣ ਦਾ ਚੱਕਰ, ਜਾਂ ਇੱਕ ਦੁਸ਼ਮਣ ਦਾ ਆਈਡਲ ਬੌਬ (idle bob)। ਇੱਕ ਵਾਰ ਸਟ੍ਰਿਪ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਇਸਨੂੰ Phaser ਵਿੱਚ ਇੱਕ spritesheet ਵਜੋਂ ਰਜਿਸਟਰ ਕੀਤਾ, ਫਰੇਮ ਦੀ ਚੌੜਾਈ ਅਤੇ ਉਚਾਈ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਤਾਂ ਜੋ ਇੰਜਣ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਇੱਕ ਪੋਜ਼ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਗਲਾ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।
ਇਸ ਨੂੰ ਮੈਨੂਅਲੀ ਕਰਨ ਨਾਲ ਇਹ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਐਨੀਮੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ: ਇੱਕ ਸਾਂਝੇ ਟੈਕਸਚਰ 'ਤੇ ਫਰੇਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ। Phaser ਦਾ ਐਨੀਮੇਸ਼ਨ ਕੰਪੋਨੈਂਟ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਫਰੇਮ, ਇੱਕ ਅੰਤਿਮ ਫਰੇਮ, ਅਤੇ ਇੱਕ ਫਰੇਮ ਰੇਟ ਮੰਗਦਾ ਹੈ। ਫਿਰ ਇਹ ਗੇਮ ਕਲਾਕ ਦੇ ਹਰ ਟਿਕ (tick) 'ਤੇ ਉਹਨਾਂ ਆਇਤਾਕਾਰ ਟੁਕੜਿਆਂ ਰਾਹੀਂ ਇੱਕ ਪੁਆਇੰਟਰ ਨੂੰ ਅੱਗੇ ਵਧਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ spritesheets ਨੂੰ ਕਲਾਕਾਰਾਂ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਜਾਦੂਈ ਐਸੇਟਸ ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਮੈਥ (coordinate math) ਵਜੋਂ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ। ਇਹ ਨਜ਼ਰੀਆ ਬਾਅਦ ਵਿੱਚ ਬਹੁਤ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਸਲੀ ਆਰਟ ਨੂੰ ਕੱਟ ਰਹੇ ਹੁੰਦੇ ਹੋ ਜਾਂ ਇਸ ਗੱਲ ਦੀ ਡੀਬੱਗਿੰਗ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਐਨੀਮੇਸ਼ਨ
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