6.4 Animated Sprites and Camera

Step 1 — Recall what the method does: sprite.addAni(name, sheetUrl, frameCount) loads a horizontal frame strip from an image file and registers it on the sprite as a named animation, ready to be played or switched to later with changeAni. (The first addAni call on a sprite also auto-activates that animation.)

Step 2 — First argument, name: A string label you choose, such as 'idle' or 'walk'. This is the handle the animation is registered under — it's what you'll pass to changeAni later, so it's how you refer to the animation from then on.

Step 3 — Second argument, sheetUrl: The URL (or file path) of the sprite sheet image — the single image file containing all the animation frames arranged in a horizontal row.

Step 4 — Third argument, frameCount: How many frames the strip contains. The engine needs this number to know how to slice the image into individual frames.

Answer: addAni registers a named animation on a sprite from a horizontal sprite-sheet image: name is the label you'll use to switch to it, sheetUrl is the location of the frame-strip image, and frameCount is how many frames that strip contains.

Step 1 — Define a sprite sheet: A sprite sheet is a single image file containing multiple frames of an animation arranged in a horizontal row, instead of one separate image file per frame.

Step 2 — Explain how frame boundaries are found: The engine doesn't detect frame edges from the picture content — you tell it how many frames the strip holds, via the frameCount argument of addAni. The engine then divides the image's total width by that count and cuts the strip into that many equal horizontal slices, one per animation frame.

Answer: A sprite sheet is one image containing several animation frames laid out in a row; the engine knows where frames begin and end because you supply the frame count, and it slices the strip into equal-width pieces accordingly.

Step 1 — What changeAni does: sprite.changeAni(name) switches the sprite to a previously registered animation — for example, player.changeAni('walk') makes the sprite start playing the 'walk' animation that an earlier addAni call registered.

Step 2 — What happens with an unregistered name: Nothing at all — it's a silent no-op. No error is thrown and no warning is printed, which is why a typo like changeAni('idel') when you registered 'idle' quietly does nothing. That's also why you must register an animation before trying to switch to it.

Answer: changeAni switches the sprite to a registered animation by name; if the name was never registered, the call does nothing silently — no error, no change.

Step 1 — What frameDelay controls: ani.frameDelay is the number of game frames each animation frame is held on screen before advancing to the next one — it's the speed dial for sprite-sheet animation.

Step 2 — The default value: The default is 4, so each animation frame displays for 4 game frames. At 60 fps that means \( 60 \div 4 = 15 \) animation frames per second.

Step 3 — Setting it to 1: Each animation frame would display for exactly one game frame before advancing — the fastest playback possible, with no holding at all. The animation runs at full game speed (60 animation frames per second), which is 4× faster than the default and will usually look like a rapid blur.

Answer: frameDelay is how many game frames each animation frame is shown for; the default is 4, and setting it to 1 plays the animation at maximum speed — one animation frame per game frame.

Step 1 — Register both animations first: Registration has to happen before any changeAni can find them (an unregistered name is a silent no-op), so the two addAni calls come first:

player.addAni('walk', 'player-walk.png', 6);
player.addAni('jump', 'player-jump.png', 4);

Step 2 — Test whether the player is grounded: The same player.colliding(ground) test from §6.3's jump logic tells you whether the player is on the ground or in the air each frame.

Step 3 — Switch based on the test:

▶ Press Run to see the output…

The first addAni auto-activates 'walk', which is conveniently the correct animation for a player standing on the ground at the start.

Answer: The code above — register 'walk' and 'jump' with addAni, then each frame call changeAni('walk') when player.colliding(ground) is true and changeAni('jump') otherwise.

Step 1 — Identify the special behavior: The first addAni call on a sprite auto-activates the animation it registers — the sprite immediately starts displaying that animation with no changeAni call needed.

Step 2 — Explain why it matters: This guarantees a sprite has a visible animation the moment its first sheet is loaded, instead of sitting with nothing active. It also means the auto-activation only happens once: every later addAni call merely registers, and you must call changeAni explicitly to switch to those.

Answer: The first addAni call is special because it auto-activates the animation it registers — the sprite starts playing it automatically, so you never need a changeAni for the first animation.

Step 1 — Convert the time budget to game frames: At 60 frames per second, one second is 60 game frames total — that's the whole time budget the cycle has to fit in.

Step 2 — Divide the budget among the 8 animation frames: Each of the 8 animation frames must occupy an equal share of those 60 game frames:

Step 3 — Set frameDelay:

player.ani.frameDelay = 7.5;

If you'd rather keep whole numbers, 7 completes the cycle in \( 8 \times 7 = 56 \) frames (just under a second) and 8 completes it in \( 8 \times 8 = 64 \) frames (just over) — both read as "about 1 second."

Answer: frameDelay = 7.5 (60 game frames ÷ 8 frames = 7.5); integer alternatives are 7 or 8 for a cycle of roughly one second.

Step 1 — What they represent: camera.x and camera.y are the world coordinates at the center of the visible canvas. The camera is the viewport into the game world — the window through which you see the level.

Step 2 — What changing them does: Changing them scrolls everything drawn inside draw(), as if the world were sliding underneath a fixed window rather than the window moving over a fixed world. For example, increasing camera.x moves the view to the right, so on-screen sprites appear to slide to the left.

Answer: They are the world coordinates at the center of the visible canvas; changing them scrolls the entire scene in draw(), panning the viewport around a world larger than the canvas.

Step 1 — Recall the soft-follow pattern: Each frame, the camera moves a fraction of the gap between itself and its target — the gap (player.x - camera.x) scaled by the catch-up factor and added back onto the camera's position, so it eases toward the player instead of jumping to it.

Step 2 — Apply a factor of 0.2 to both axes:

camera.x += (player.x - camera.x) * 0.2;
camera.y += (player.y - camera.y) * 0.2;

Each frame the camera closes 20% of the remaining distance, catching up quickly but smoothly.

Answer: The two lines above — one easing camera.x toward player.x, the other easing camera.y toward player.y, both with a catch-up factor of 0.2.

Step 1 — Consider what snapping does: camera.x = player.x copies the player's position to the camera exactly, every frame. Every twitch in the player's motion — sudden starts and stops, landing from a jump, tiny physics jitter — is passed straight through to the camera with zero smoothing.

Step 2 — Compare with a soft follow: A soft follow only closes a fraction of the gap each frame, so quick jitters get averaged out and the camera glides with a sense of weight and inertia. Both approaches keep the player on screen, but snapping makes the whole world jerk in lockstep with the player's velocity changes, which feels rigid and harsh, while easing feels smooth and polished.

Answer: Snapping transmits every abrupt change in the player's motion directly to the camera, so the whole world jolts with each stop, start, and landing; the soft follow's catch-up factor smooths those changes out, making the same on-screen result feel far more natural.

Step 1 — Recall the rule: Moving the camera scrolls everything drawn inside draw() — the score text included — so placement relative to the camera update determines whether the text scrolls or stays put.

Step 2 — Answer the ordering question: Draw it before the camera update. Draw commands issued before the camera's position changes that frame are placed at fixed canvas coordinates, so the text stays pinned to the corner no matter where the camera ends up looking that frame.

Step 3 — See what goes wrong the other way: If the score is drawn after the camera update, it's placed relative to the camera's new position, so it drifts and scrolls along with the world instead of staying put.

Answer: Before — because the camera update affects everything drawn after it in that frame, drawing the HUD first keeps it fixed to the screen while the world scrolls.

Step 1 — Recall what friction is: friction is a physical property of a sprite's surface — it describes how much contact with that sprite resists sliding. It's about the material's behavior, not the sprite's size.

Step 2 — Compare what changed and what didn't: Widening the ground from 400 to 900 pixels changed its geometry — how much of the world it covers — but not its surface behavior. Wherever along the 900 pixels the player stands, the player-to-ground contact uses the same friction value, so walking, stopping, and skidding feel identical to §6.3.

Answer: Friction is a per-surface property, not a per-pixel one — the width only extends how far the surface reaches, so the same ground.friction value applies to every point along it and the movement feel is unchanged.

Step 1 — Find the center and amplitude of the pulse: Math.sin oscillates smoothly between \(-1\) and \(1\), so the line has the shape baseline + amplitude * Math.sin(...). The middle of the range 14–20 is \( (14 + 20) \div 2 = 17 \), and the half-width of the range is \( (20 - 14) \div 2 = 3 \).

Step 2 — Write the line:

sprite.diameter = 17 + 3 * Math.sin(frameCount / 20);

The divisor 20 sets the pace of the pulse — larger values pulse more slowly, smaller values faster.

Step 3 — Check the extremes: When Math.sin(...) equals 1, the diameter is \( 17 + 3 = 20 \); when it equals -1, it's \( 17 - 3 = 14 \); when it equals 0, the sprite sits at its 17-pixel midpoint. That's a smooth pulse across exactly the requested range.

Answer: sprite.diameter = 17 + 3 * Math.sin(frameCount / 20); — baseline 17, amplitude 3, so the diameter sweeps smoothly between 14 and 20 pixels.

Step 1 — State the decision rule: Whether the string contains a dot. A string with a dot in it (like 'player.png') is treated as a URL to an image file; a string with no dot (like '🏃') is treated as an emoji, drawn centered on the sprite with the sprite's height used as the font size.

Step 2 — State the effect on .ani: Setting .image clears any active animation — .image and .ani are mutually exclusive on a given sprite, and assigning either one wipes out the other.

Answer: A dot in the string means "treat it as an image URL," and no dot means "treat it as an emoji"; setting .image afterward clears the sprite's .ani, since the two are mutually exclusive.

Step 1 — Recall what .image changes: .image is purely cosmetic — it only changes how a sprite is drawn, replacing the default colored shape with an image or emoji. It does not touch the sprite's position, size, velocity, or collider.

Step 2 — Recall what overlaps depends on: player.overlaps(coins, ...) is decided by the sprites' colliders and positions — the coins are still 24-pixel-diameter circles and the player is still a 40×40 sprite, whether they draw as emoji or as plain shapes.

Step 3 — Put the two together: Since neither sprite's physics changed, overlap detection fires at exactly the same moments and with exactly the same callback behavior as before; only the pixels on screen are different.

Answer: .image changes appearance only, while overlap detection runs on colliders and positions — which are untouched — so collecting coins behaves identically with or without the emoji.