Chapter 4: Animation, pixel art, and sprites

Animations usually aren't built from just one technique, but are made up of a combination of patterns that can be assembled in different ways. So rather than just showing you isolated code examples, we'll take a different approach in this chapter. We'll build four small projects to teach the fundamental animation techniques you'll use frequently in web games.

1. Bouncing ball. Velocity, acceleration, and basic collisions.
2. Bouncing DVD logo. Separating simulation from animation.
3. Animated grid-based movement. Animated vs logical positions, lerp, springs, easing functions.
4. Sprite animation. Animations with images, plus some ways to upscale pixel art.

A bouncing ball

if (ball.y > bottomY) {
  ball.vy *= -1; // flip velocity
}

if (ball.y > bottomY) {
  // move ball to collision boundary
  ball.y = bottomY;
  // then flip velocity
  ball.vy *= -1;
}

const overshoot = ball.y - bottomY;
ball.y = bottomY - overshoot;

ball.y = 2 * bottomY - ball.y;

const ball = {
  x: 100,
  y: 50,
  r: 16, // radius
};

Bouncing DVD logo

What we built in the bouncing ball example is a simulation. Each frame reads the previous frame's state, then uses that to compute where it's going next. You could easily use those same techniques to build the bouncing DVD logo animation [YouTube] but in this section we're going to do something totally different.

You can probably already picture what the state would look like for an animation like this. Maybe:

const logo = { x, y, dx, dy, numberOfBounces };

But what if I told you that the only state you need for that animation is this:

const state = { time }; // elapsed seconds since animation start

All of the other properties--the location, movement direction, and number of bounces--can be derived from time.

There's an analogy to this concept that you sometimes see in other coding problems: using an iterative solution vs a direct formula or "closed-form solution".

function countDaysBetweenDates(start: Date, end: Date) {
  let days = 0;
  let currentDay = new Date(start);
  while (currentDay < end) {
    currentDay.setDate(currentDay.getDate() + 1);
    days++;
  }
  return days;
}

You could count the number of days between two dates one-by-one, like the above code. But we know we're just looking at two timestamps, and we know the duration of a day, so we have all the information we need to do this without the loop:

function countDaysBetweenDates(start: Date, end: Date) {
  const ONE_DAY_MS = 24 * 60 * 60 * 1000;
  const days = Math.floor((end.getTime() - start.getTime()) / ONE_DAY_MS);
  return days;
}

Besides the fact that it feels elegant to use formulas to do in O(1) time what previously was done in O(N), there's a lot more to this "iterative vs closed-form" or "simulation vs animation" mental model than microoptimizations. If you can derive the current state without having to look back to the previous state, it becomes possible to massively parallelize these computations and run them on the GPU, which is how games are able to animate things like the movement of foliage so efficiently. But even if you're not planning to have millions of blades of grass in your browser game or use shaders or do any GPU optimization, if you can avoid storing state for every blinking light or rotating coin or idle breathing animation, you'll be doing future you a favor by reducing the complexity of your game code.

Let's look at a real example.

const speed = 80; // px/s
const width = 300;
const x = (time * speed) % width;

const speed = 80; // px/s
const canvasWidth = 300;
const logoWidth = 100;
const width = canvasWidth - logoWidth;
const x = (time * speed) % width;

const speed = 80; // px/s
const canvasWidth = 300;
const logoWidth = 100;
const width = canvasWidth - logoWidth;
const x = (time * speed) % width;
const invertedX = width - x;

const speed = 80; // px/s
const canvasWidth = 300;
const logoWidth = 100;
const width = canvasWidth - logoWidth;
const x = (time * speed) % width;
const invertedX = width - x;
const displayX =
  x < width / 2
    ? x 
    : invertedX;

const speed = 80; // px/s
const canvasWidth = 300;
const logoWidth = 100;
const width = canvasWidth - logoWidth;
const x = (time * speed) % (width * 2);
const invertedX = width * 2 - x;
const displayX =
  x < width // double the half-width
    ? x 
    : invertedX;

xBounces = floor((time * speed) / (canvas.w - logo.w));
yBounces = floor((time * speed) / (canvas.h - logo.h));
bounces = xBounces + yBounces;
color = colors[bounces % colors.length];

const logo = {
  x: 40,
  y: 40,
  w: 96,
  h: 42,
  dx: 80, // horizontal velocity (px/s)
  dy: 55, // vertical velocity (px/s)
  bounces: 0, // we'll count # of walls hit
};

Just remember, relying on state is not bad! And actually, our "stateless" animation still relies on some state: time is state, too. Sometimes it's just more pragmatic to build a simple stateful solution than it is to use a clever formula. So our aim is not to eliminate statefulness everywhere we can. Instead, identify where it is practical to derive it rather than simulate it, and apply these techniques there. Because the fewer states your game can be in at any given time, the fewer branches you have to go down when debugging or reasoning about your code. And if that sounds appealing to you, there are a few more examples where we derive positions and other typically-stateful properties using only the current time in the section on sine waves in Chapter 5 →.

Animated grid-based movement

In grid-based games you want your logical game state to be in discrete, integer steps. So if the player is at x=1 y=2 and moves right, then they snap to x=2 y=2 on the next update. There are no in-between states, so your game rules will never have to deal with a player at x=1.333 y=2.5.

While snapping to a grid is great for game logic, it's rarely how you want to display movement to players. In this section we'll show how to decouple the logical grid position from the visual position.

Lerp

Lerp is a strange portmanteau for "Linear Interpolation", which blends between two numbers a and b. How far between? Some amount t--a value between 0 and 1.

function lerp(a: number, b: number, t: number) {
  return a + (b - a) * t;
}

// lerp(0, 1, 0.3) => 0.3
// lerp(0, 100, 0.3) => 30
// lerp(50, 100, 0.5) => 75
// lerp(123, 456, 0.789) => 385.737

When the t value updates over time, you get an animation.

const t = (time % 2) / 2;
const x = lerp(startX, endX, t);

And the same blend factor t can update several properties at once.

const t = (time % 2) / 2;

const x = lerp(startX, endX, t);
const opacity = lerp(0, 1, t);
const size = lerp(0, 40, t);
const rotation = lerp(-0.45, 0.45, t);

Easing functions

You mostly see unaccelerated motion in machinery. An automated factory is chock-full of linear tweens—robotic arms, conveyor belts, assembly lines. It is extremely difficult for humans to move in a linear fashion. Breakdancers who do “robot”-style moves have achieved their linearity with much practice. In this sense, you could say Michael Jackson is the master of the linear tween.
- Robert Penner on the Aesthetics of Linear Motion

The L in "lerp" stands for "linear". But in games and in life, movement tends not to be linear. So if you apply an easing function to the t parameter in your lerp, it will still take the same amount of time to get from a to b, but you can shape the acceleration and deceleration as you move between those fixed points for more natural-looking motion.

const eased = easeOut(t);
const x = lerp(startX, endX, eased);

function easeOut(t: number) {
  return 1 - (1 - t) ** 2;
}

There are a bunch of other easing curves, with examples and TypeScript functions you can copy at easings.net.

Fixed tweens vs follow behaviors

The lerp we've used so far is a fixed tween, measuring progress between a known start and end point. What do you do when you have a target that can move again before the previous move has finished?

Follows, unlike tweens, do not need to know the original starting position in order to smoothly close the gap between the current value and the latest target each frame.

Exponential smoothing

Exponential smoothing is a follow technique that brings a value asymptotically close to a target point, but never actually reaches it. No matter how fast you make the speed factor here, blue will always win.

The formula looks like this. You may notice something funny in it:

t = 1 - Math.exp(-speed * dt);
x = lerp(x, targetX, t);

That's right, follows can still use lerp! We just need to reframe the thinking a bit: let a in the lerp(a, b, t) function be the current position rather than the original starting position.

x = lerp(x, targetX, t);
avoid doing this

x = targetX + (x - targetX) * Math.exp(-speed * dt);

Springs

Springs are a physics-based follow function with configurable stiffness (how much the target pulls the value towards it) and damping (how much resistance the velocity faces). Like exponential follows, springs can also follow a moving target. But unlike the exponential follow, springs also carry a velocity value and can overshoot the target.

function stepSpring(
  value: number,
  velocity: number,
  target: number,
  stiffness: number,
  damping: number,
  dt: number,
) {
  const acceleration = -stiffness * (value - target) - damping * velocity;
  velocity += acceleration * dt;
  value += velocity * dt;
  return { value, velocity };
}

For more on springs, see Josh Comeau's A Friendly Introduction to Spring Physics and Glenn Fieldler's Spring Physics.

Mini animated grid movement project

The goal in this section will be to code a grid movement system with an exponential follow. An integer row and col grid position will always be available in the game state, but an animated visual position will also be available for drawing.

const gridSize = 40;
const playerSize = 28;

const state = {
  col: 0,
  row: 0,
};

Sprites

People have been producing the illusion of motion through still images for hundreds of years. Analog mechanical animation media, like film, flip books, and zoëtropes all rely on the fact that if you flip through still frames fast enough, viewers will perceive motion.

Sprite animations, such as this one, also rely on that principle.

A sprite (sometimes called a texture atlas or sprite sheet) is simply a single image with other images in it. Here, for example, we have a sprite sheet with all of the frames of our planet animation in it.

You can play through the animation by cropping to a frame, then adjusting the crop window on an interval.

Sprite sheets are used for much more than animation--they're often used for background tiles and textures as well since you can easily pack dozens of textures into a single file. The exact same techniques for indexing into a small window within a larger image can be used both for sprite animations and for static uses of sprites.

Sprite sheets are especially useful in web games because they can significantly reduce the number of roundtrips your browser needs to make to fetch your game's assets.

Let's start with how to draw a single frame in a sprite. We'll need to use the 9-argument form of drawImage (see Chapter 2 →). The code below pulls from the source rectangle (our "crop window") within the image, then draws it to the destination rectangle on the canvas.

function drawSprite({ index, destX, destY }: { index: number; destX: number; destY: number }) {
  const frameWidth = 50;
  const frameHeight = 50;
  const frameX = index * frameWidth;
  const frameY = 0;
  ctx.drawImage(
    sprite,
    // source rectangle
    frameX,
    frameY,
    frameWidth,
    frameHeight,
    // destination rectangle
    destX,
    destY,
    frameWidth,
    frameHeight,
  );
}

drawSprite({ index: 5, destX: 0, destY: 0 });

function drawSprite({
  index,
  destX,
  destY,
  scale,
}: {
  index: number;
  destX: number;
  destY: number;
  scale: number;
}) {
  const frameWidth = 50;
  const frameHeight = 50;
  const frameX = index * frameWidth;
  const frameY = 0;
  ctx.imageSmoothingEnabled = false;
  ctx.drawImage(
    sprite,
    frameX,
    frameY,
    frameWidth,
    frameHeight,
    destX,
    destY,
    frameWidth * scale,
    frameHeight * scale,
  );
}

drawSprite({ index: 5, destX: 0, destY: 0, scale: 4 });

To turn that into an animation, increment the index on an interval in the update cycle of your game loop.

const state = {
  frameTime: 0,
  index: 0,
};

function update(dt: number) {
  const totalFrames = 40;
  const frameDuration = 0.1;
  state.frameTime += dt;
  if (state.frameTime >= frameDuration) {
    state.index = (state.index + 1) % totalFrames;
    state.frameTime -= frameDuration;
  }
}

function drawSpriteTile(row: number, col: number, destX: number, destY: number) {
  const frameWidth = 32;
  const frameHeight = 32;

  ctx.drawImage(
    // your image asset (usually an HTMLImageElement)
    sprite,

    // the source rectangle (x, y, w, h)
    col * frameWidth, // startX
    row * frameHeight, // startY
    frameWidth, // source width
    frameHeight, // source height

    // the destination rectangle (x, y, w, h)
    destX,
    destY,
    frameWidth,
    frameHeight,
  );
}

If you want to create your own sprite sheets, Aseprite and Tilesetter are good (paid) options.

Performance improvements for upscaled pixel art

Scaling images every frame is rather expensive. We can instead pre-scale them in an OffscreenCanvas, which is just like a <canvas> element except that it can't interact with the DOM, so you'll only use it to compute bitmaps and then directly transfer those onto your main canvas.

const scale = 4;
const frameWidth = 50;
const frameHeight = 50;
const totalFrames = 40;

// create an offscreen canvas with the exact scaled dimensions for our sprite
const scaled = new OffscreenCanvas(
  totalFrames * frameWidth * scale, // canvas width
  frameHeight * scale, // canvas height
);

// pre-scale the entire sprite sheet one time up front
function prescale() {
  const scaledCtx = scaled.getContext("2d")!;
  scaledCtx.imageSmoothingEnabled = false;
  scaledCtx.drawImage(sprite, 0, 0, scaled.width, scaled.height);
}

// only run the one-time scaling once the sprite is fully downloaded
if (sprite.complete) prescale();
else sprite.onload = prescale;

function drawSprite(index: number, destX: number, destY: number) {
  ctx.drawImage(
    scaled,
    index * frameWidth * scale, // previously `index * frameWidth`
    0,
    frameWidth * scale, // previously just `frameWidth`
    frameHeight * scale, // previously just `frameHeight`
    destX,
    destY,
    frameWidth * scale,
    frameHeight * scale,
  );
}

OffscreenCanvases can even be used in Web Workers, allowing you to run expensive computations in a separate thread.

See also

• An In-Depth look at Lerp, Smoothstep, and Shaping Functions [YouTube] — SimonDev on linear interpolation
• Puzzle Game Movement Systems [YouTube] — Jonathan Blow and Sean Barret discussion
• The 12 Principles of Animation [Wikipedia] — Disney's foundational animation rules (also on YouTube by AlanBeckerTutorials)

Tools

• Aseprite — animated sprite editor and pixel art tool
• easings.net — interactive easing curve reference
• Paint of Persia — like tracing paper for pixel art, with animation support
• Tilesetter — can export a png + json file with coordinates for sprite sheets