Chapter 6: Cameras and viewports

Screen space and world space

So far whenever we've called a function like fillRect(x, y, width, height), those x/y coordinates have been in screen space, where x starts at 0 from the left and y starts at 0 from the top of the canvas.

Working directly in screen-space coordinates means that depending on your canvas size, more or less of the game world will be visible at any moment. This creates issues with fairness and consistency, and can be totally game-breaking. Imagine not being able to see half your board because you're on a small screen!

for (let row = 0; row < 8; row++) {
  for (let col = 0; col < 8; col++) {
    const size = 40; // every tile is 40px x 40px
    const x = col * size; // and every coordinate needs to know this size
    const y = row * size;
    ctx.fillStyle = (row + col) % 2 === 0 ? "white" : "black";
    ctx.fillRect(x, y, size, size);
  }
}

To make our chess game work consistently on all canvas sizes, we'll make a couple of changes:

1. Define an 8x8 grid for our world space.
2. Scale the canvas so that the grid fills either the full vertical or horizontal space available, whichever threshold is met first.

How? Like this:

function inChessWorldSpace(
  ctx: CanvasRenderingContext2D,
  bounds: DOMRect, // canvas' boundingClientRect
  draw: () => void,
) {
  const size = Math.min(bounds.width, bounds.height); // the board is square, so constrain it by the shorter side of the canvas
  const scale = size / 8; // we'll scale up by this factor since it's an 8x8 board
  ctx.save();
  ctx.scale(scale, scale);
  draw(); // anything in this callback is now scaled to "chessboard units"
  ctx.restore();
}

inChessWorldSpace(ctx, canvas.getBoundingClientRect(), () => {
  // in here, x=4 y=2 means "file 4, rank 2" in chessboard world space.
  // we're no longer thinking in pixels!
  for (let row = 0; row < 8; row++) {
    for (let col = 0; col < 8; col++) {
      ctx.fillStyle = (row + col) % 2 === 0 ? "white" : "black";
      ctx.fillRect(col, row, 1, 1);
    }
  }
});

Now we have two coordinate systems to draw into, and it's trivial to swap between them. Anything outside the inChessWorldSpace callback is in screen space and anything inside of the callback is in world space, a new coordinate system we've created specifically for our game to make it easy to lay things out.

Let's also center the board and add some margins.

function inChessWorldSpace(
  ctx: CanvasRenderingContext2D,
  width: number,
  height: number,
  draw: () => void,
) {
  const margin = 16;
  const size = Math.min(width, height) - margin * 2;
  const scale = size / 8;
  ctx.save();
  ctx.translate((width - size) / 2, (height - size) / 2);
  ctx.scale(scale, scale);
  draw();
  ctx.restore();
}

A square 8 x 8 world is an extremely simple example, so let's apply this concept to another game, this time using a more standard 16:9 aspect ratio. We'll build pong within a 64 x 36 unit game world, giving our paddles and ball a width of 1, but that choice of world size is totally arbitrary and we could have just as easily used 1920 x 1080 or any other 16:9 area.

function letterbox(
  container: { width: number; height: number },
  world: { width: number; height: number },
  margin = 0,
) {
  const scale = Math.min(
    (container.width - margin * 2) / world.width,
    (container.height - margin * 2) / world.height,
  );
  return {
    scale,
    xOffset: (container.width - world.width * scale) / 2,
    yOffset: (container.height - world.height * scale) / 2,
  };
}

function inWorldSpace(
  ctx: CanvasRenderingContext2D,
  gameArea: { width: number; height: number },
  canvasRect: { width: number; height: number },
  cb: () => void,
) {
  const margin = 16;
  const { scale, xOffset, yOffset } = letterbox(canvasRect, gameArea, margin);
  ctx.save();
  ctx.translate(xOffset, yOffset);
  ctx.scale(scale, scale);
  cb();
  ctx.restore();
}

All our game logic and draw code can now operate within a 64 x 36 world space, no matter what size the canvas element actually is.

const bounds = canvas.getBoundingClientRect();
const gameArea = { width: 64, height: 36 };
const state = {
  ball: { x: 20, y: 14 },
  leftPaddle: { y: 10 },
  rightPaddle: { y: 20 },
};

function draw() {
  ctx.clearRect(0, 0, bounds.width, bounds.height);
  inWorldSpace(ctx, gameArea, bounds, () => {
    ctx.fillStyle = "#13131e";
    ctx.fillRect(0, 0, gameArea.width, gameArea.height);
    const paddleOffset = 4;
    const paddleWidth = 1;
    drawPaddle(ctx, {
      x: paddleOffset,
      y: state.leftPaddle.y,
    });
    drawPaddle(ctx, {
      x: gameArea.width - paddleOffset - paddleWidth,
      y: state.rightPaddle.y,
    });
    drawBall(ctx, state.ball);
  });
}

function inWorldSpace(
  ctx: CanvasRenderingContext2D,
  gameArea: { width: number; height: number },
  canvasRect: { width: number; height: number },
  shake: { x: number; y: number },
  cb: () => void,
) {
  const margin = 16;
  const { scale, xOffset, yOffset } = letterbox(canvasRect, gameArea, margin);
  ctx.save();
  ctx.translate(xOffset, yOffset);
  ctx.scale(scale, scale);
  ctx.translate(shake.x, shake.y);
  cb();
  ctx.restore();
}

In-game cameras

Pong and chess both display the entire game world on screen at once, but what do we do when the game world is much larger than the portion we want to display? For that, we need an in-game camera.

To start we'll create a state object for our camera.

const state = {
  camera: {
    x: 0,
    y: 0,
    zoom: 1,
  },
};

Then to use it...

function inCamera(
  ctx: CanvasRenderingContext2D,
  bounds: { width: number; height: number },
  camera: { x: number; y: number; zoom: number },
  draw: () => void,
) {
  ctx.save();
  // start at the center
  ctx.translate(bounds.width / 2, bounds.height / 2);
  // scale to the camera's zoom level
  ctx.scale(camera.zoom, camera.zoom);
  // translate to the camera's position
  ctx.translate(-camera.x, -camera.y);
  draw();
  ctx.restore();
}

function draw() {
  inWorldSpace(ctx, gameArea, bounds, () => {
    inCamera(ctx, gameArea, state.camera, () => {
      drawTrack(ctx);
      drawCar(ctx, state.car);
    });
    drawHud(ctx, state.car.speed);
  });
}

Now we have two primitives to work with. inWorldSpace puts everything into game world units allowing us to draw in world space. inCamera then pans and zooms within our world space keeping our view within the camera. And anything drawn outside of those two functions will remain in screen space.

Right now there is a potential issue with our camera for some games. You can currently see more or less of the game world at different aspect ratios. (Try resizing the previous demo!) If you want to prevent players from seeing anything outside of the 16:9 letterboxed camera, using .clip() makes that possible.

function inCamera(
  ctx: CanvasRenderingContext2D,
  bounds: { width: number; height: number },
  camera: { x: number; y: number; zoom: number },
  draw: () => void,
) {
  ctx.save();

  ctx.beginPath();
  ctx.rect(0, 0, bounds.width, bounds.height);
  ctx.clip();

  ctx.translate(bounds.width / 2, bounds.height / 2);
  ctx.scale(camera.zoom, camera.zoom);
  ctx.translate(-camera.x, -camera.y);
  draw();
  ctx.restore();
}

Screen, world, and camera

The main takeaway I'd like to leave you with is that the camera is really just a set of transforms. First, we can make our lives easier by setting our game units to something that makes sense for our specific game world (world space). And then we can pan and zoom around that world with basic transforms in our camera. Everything outside of these callbacks will continue to be in screen space, which is made up of the DPI-scaled pixels within our <canvas>.

There are many ways to take this from here. A few ideas to get you thinking...

1. Instead of always snapping the camera right to the player, try using an exponential follow (see Chapter 4) so that the camera lags slightly behind the player's position.
2. Offset the camera's x and y whenever there's an impact in your game to add screen shake.
3. Don't render things that are a certain distance outside of the camera.
4. Add rotations to the set of transforms done in-camera.
5. Think about how you'd convert a mouse event's x/y (window-space) coordinates into world-space or in-camera coordinates so you can let players click/hover/drag in-game items. (We'll answer this in the next chapter →.)

And just to recap, our final car/racetrack code now looks something like this:

function draw() {
  // 1. in screen space (raw canvas pixels)
  ctx.clearRect(0, 0, bounds.width, bounds.height);

  inWorldSpace(ctx, gameArea, bounds, () => {
    inCamera(ctx, gameArea, state.camera, () => {
      // 2. the camera-viewed world
      drawTrack(ctx);
      drawCar(ctx, state.car);
    });

    // 3. in world-space units w/ letterboxing, but floating outside of the camera
    drawHud(ctx, state.car.speed);
  });

  // 4. back in screen space (usually FPS/debug ui)
  if (import.meta.env.DEV) {
    drawDebugOverlay(ctx, state);
  }
}

Up next

Our camera demo had the player moving around inside of the game world using key presses. We'll cover how to react to these inputs in Chapter 7 → where we wire browser events into the game loop.