Build playable prototypes in code and in Godot: game loops, input, collision, physics, state machines, data-driven tuning, jams and publishing.

Game Prototyping & Systems

## Why this matters

A prototype answers a design question: is this jump fun, is this enemy readable, does this loop hold attention for five minutes? The fastest way to answer it is often a single HTML file that runs in any browser. The `<canvas>` element gives you a blank bitmap you can draw on with JavaScript, with no engine, install or build step. Many jam games and pitch prototypes start exactly like this, and the habits you build here (state in plain objects, drawing as a function of that state) carry straight into Godot, Unity or any engine.

## The canvas and its context

A canvas is an element with a fixed drawing size, set with the `width` and `height` attributes (not CSS, which only stretches the bitmap):

```html
<canvas id="game" width="320" height="200"></canvas>
```

To draw, ask the canvas for a **2D rendering context**. Every drawing call goes through it:

```javascript
const canvas = document.getElementById("game");
const ctx = canvas.getContext("2d");

ctx.fillStyle = "#1e293b";              // background colour
ctx.fillRect(0, 0, canvas.width, canvas.height);

ctx.fillStyle = "#f59e0b";              // the "sprite"
ctx.fillRect(40, 80, 24, 24);           // x, y, width, height
```

The coordinate system starts at the **top-left** corner. `x` grows to the right and `y` grows **downwards**, which surprises people used to maths graphs. A rectangle at `(40, 80)` has its top-left corner 40 pixels from the left edge and 80 from the top.

Useful calls to know:

| call | what it does |
|---|---|
| `fillRect(x, y, w, h)` | solid rectangle |
| `clearRect(x, y, w, h)` | erase to transparent |
| `beginPath()`, `arc(x, y, r, 0, Math.PI * 2)`, `fill()` | a circle |
| `drawImage(img, x, y)` | draw a loaded image (a real sprite) |
| `fillText("Score: 3", x, y)` | text, styled with `ctx.font` |

## State first, pixels second

The canvas has no memory of "objects". Once you draw a rectangle it is just coloured pixels. To move something you **change its data** and **draw everything again**. Keep the game's state in a plain object:

```javascript
const player = { x: 40, y: 80, w: 24, h: 24, color: "#f59e0b" };

function drawFrame() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);  // wipe the last frame
  ctx.fillStyle = player.color;
  ctx.fillRect(player.x, player.y, player.w, player.h);
}

function movePlayer(dx, dy) {
  player.x += dx;
  player.y += dy;
}

movePlayer(10, 0);
drawFrame();   // the square appears 10px further right
```

This split is the most important idea in the module. `movePlayer` changes **state**; `drawFrame` turns state into **pixels**. Your game logic never reads pixels back, so you can test it without looking at the screen, and you can swap a coloured square for real art later without touching the rules.

## Keeping things on screen

Players find edges fast. Without a guard, the square slides off and never comes back. **Clamping** keeps a value inside a range:

```javascript
function clamp(value, min, max) {
  return Math.max(min, Math.min(max, value));
}

function movePlayer(dx, dy) {
  player.x = clamp(player.x + dx, 0, canvas.width - player.w);
  player.y = clamp(player.y + dy, 0, canvas.height - player.h);
}
```

Note the upper bound: `canvas.width - player.w`, because `x` is the **left** edge. If you clamp to `canvas.width`, the sprite can sit entirely off the right side.

## Exposing state for debugging

During prototyping, put your state where you can poke it from DevTools:

```javascript
window.game = { player, movePlayer, drawFrame };
```

Now you can type `game.movePlayer(50, 0); game.drawFrame()` in the console, or set `game.player.color = "red"` to test readability. The Do activity uses this same object to check your work.

## Sharp pixels and sizing

If you scale the canvas with CSS (say `width: 100%`), the browser stretches the bitmap and pixel art goes blurry. For a crisp retro look keep the bitmap small and add `image-rendering: pixelated;` to the canvas's CSS. For non-pixel art, set the `width`/`height` attributes to the size you actually display.

## Common mistakes

- **Forgetting `clearRect`.** Each frame draws on top of the last, leaving a smear trail.
- **Setting size with CSS only.** The default bitmap is 300×150, stretched to your CSS size.
- **Thinking y goes up.** Moving "up" means `dy` is negative.
- **Drawing before setting `fillStyle`.** The colour applies to calls made *after* you set it.
- **Storing positions in the DOM or reading pixels to find objects.** Keep a state object; draw from it.

## Quick recap

- `<canvas width height>` plus `getContext("2d")` gives you a drawing surface.
- The origin is top-left; `y` grows downwards.
- Keep the game in a state object; `drawFrame` clears and redraws from it.
- Clamp positions with the sprite's size in mind.
- Exposing `window.game` makes prototypes easy to debug and test.

## Try it

Open the Do tab. You will finish `movePlayer` (with clamping) and `drawFrame` for a small canvas prototype.

Draw a sprite on an HTML canvas, move it by changing its state, and keep it inside the play area.

Drawing with canvas

Drawing On HTML5 Canvas for Complete Beginners

## Why this matters

Every real-time game runs the same heartbeat dozens of times per second: read input, **update** the world, **draw** it. That heartbeat is the game loop. Get it wrong and your game runs twice as fast on a 120 Hz monitor, stutters when a laptop is busy, or teleports objects through walls after the player switches tabs. Get it right once and every prototype you build afterwards feels consistent.

## requestAnimationFrame

In the browser, `requestAnimationFrame(callback)` asks the browser to call your function just before the next screen repaint. It passes a high-resolution **timestamp** in milliseconds. To keep looping, the callback requests the next frame itself:

```javascript
function loop(timestamp) {
  tick(timestamp);                 // do one frame of work
  requestAnimationFrame(loop);     // schedule the next one
}
requestAnimationFrame(loop);
```

Why not `setInterval(tick, 16)`? `requestAnimationFrame` lines up with the display's refresh, pauses in background tabs (saving battery), and gives you an accurate timestamp. `setInterval` drifts and keeps running when nobody is watching.

## The problem: frame rate varies

A naive update moves a fixed amount per frame:

```javascript
ball.x += 2;   // 2 pixels per frame
```

At 60 frames per second that is 120 pixels per second. On a 144 Hz monitor it is 288. On a struggling laptop running at 30 fps it is 60. The same game now has three different speeds, which wrecks balance and makes difficulty impossible to tune.

## The fix: delta time

Measure how much time passed since the last frame, called **delta time** or `dt`, and express speeds **per second**:

```javascript
let lastTime = null;

function tick(timestamp) {
  if (lastTime === null) lastTime = timestamp;   // first frame: dt = 0
  let dt = (timestamp - lastTime) / 1000;         // ms -> seconds
  lastTime = timestamp;

  update(dt);
  draw();
}

function update(dt) {
  ball.x += ball.vx * dt;   // vx is in pixels per SECOND
}
```

With `vx = 120`, the ball moves 120 pixels every second whether that second contains 30, 60 or 144 frames. A quick self-test: two updates of `0.25` seconds must leave the ball exactly where one update of `0.5` seconds does.

## Clamp dt after a pause

When the player switches tabs, the browser stops calling your loop. When they come back, the first `dt` might be 30 seconds. Multiply a velocity by 30 and your ball leaves the level, passing through every wall on the way. The standard defence is a **cap**:

```javascript
const MAX_DT = 0.1;   // never simulate more than 100 ms in one step
dt = Math.min(dt, MAX_DT);
```

The game appears to "pause" during the gap instead of jumping forward. Many engines also use a **fixed timestep** (always step physics by exactly 1/60 s, running several steps if needed) for repeatable physics. For prototypes, variable `dt` with a cap is usually enough; the Clear Code video explains both.

## Worked example: a bouncing ball

```javascript
const ball = { x: 20, y: 90, size: 20, vx: 120 };

function update(dt) {
  ball.x += ball.vx * dt;
  if (ball.x + ball.size > canvas.width) {     // hit the right wall
    ball.x = canvas.width - ball.size;
    ball.vx = -Math.abs(ball.vx);
  } else if (ball.x < 0) {                     // hit the left wall
    ball.x = 0;
    ball.vx = Math.abs(ball.vx);
  }
}
```

Two details make this robust. First, the ball is pushed back inside the wall, so it can never get "stuck" flipping direction every frame. Second, `Math.abs` sets the direction explicitly instead of blindly negating, which is safe even if the ball is somehow already moving away.

## Keep update and draw separate

`update(dt)` changes numbers. `draw()` reads numbers and paints. Do not move things inside `draw`, and do not draw inside `update`. This separation means you can:

- run `update` many times without drawing (to fast-forward or test),
- pause by skipping `update` while still drawing a pause screen,
- test the rules by calling `update(0.5)` directly and checking the state.

The last point is exactly how professional teams write automated tests for game logic, and how the Do activity checks your work: it calls your functions with chosen values instead of waiting for real frames.

## Common mistakes

- **Speeds per frame instead of per second.** Anything that moves should be multiplied by `dt`.
- **Forgetting to divide by 1000.** Timestamps are milliseconds; speeds per second need seconds.
- **No dt cap.** A tab switch becomes a teleport.
- **Calling `requestAnimationFrame(loop)` from several places**, which starts several loops and doubles the speed.
- **Starting with `lastTime = 0`.** The first `dt` is then the whole time since page load.

## Quick recap

- The loop is read input, update, draw, repeated with `requestAnimationFrame`.
- Delta time = seconds since the last frame; multiply velocities by it.
- Cap `dt` (for example at 0.1 s) to survive pauses.
- Keep `update` and `draw` separate so logic is testable.

## Try it

Open the Do tab to write `update(dt)` and `tick(timestamp)` for a bouncing ball, including the delta-time cap.

Write an update/draw loop with requestAnimationFrame and delta time so movement is the same at any frame rate.

The game loop

requestAnimationFrame() - Beau teaches JavaScript

Understanding framerate independence and deltatime

## Why this matters

Controls are where players first touch your design. If the character keeps walking after a key is released, if pressing left and right together does something odd, or if the arrow keys scroll the page, the prototype feels broken no matter how good the idea is. Good input code is small, but it follows a few rules that are worth learning once.

## Events versus state

The browser reports keys as **events**: `keydown` when a key goes down (and repeatedly while it is held, after a delay), `keyup` when it is released. A game, though, asks a different question every frame: **is the key held right now?**

The standard bridge is a `keys` object that events update and the game loop reads:

```javascript
const keys = {};

window.addEventListener("keydown", (e) => {
  keys[e.key] = true;
});

window.addEventListener("keyup", (e) => {
  keys[e.key] = false;
});
```

Then movement happens in `update(dt)`, once per frame, from the current state:

```javascript
function update(dt) {
  let dir = 0;
  if (keys.ArrowLeft || keys.a) dir -= 1;
  if (keys.ArrowRight || keys.d) dir += 1;
  player.x += dir * player.speed * dt;
}
```

Why not move the player inside the `keydown` handler? Because key repeat is controlled by the operating system: there is a pause before repeats start, and the repeat rate varies by machine and user settings. Movement driven by events stutters and runs at different speeds for different players. Movement driven by state is smooth and uses your delta time.

## Opposite keys cancel

Using a `dir` value that adds `-1` and `+1` gives a sensible answer when both are held: `0`, standing still. Some games prefer "last key pressed wins", which you can build by recording the order of presses, but cancelling is a fine default and is predictable.

## key versus code

`e.key` is the character the key produces ("a", "A", "ArrowLeft"). `e.code` is the physical key position ("KeyA", "ArrowLeft"). For WASD movement, `e.code` is better: on a French AZERTY keyboard the key in the W position produces "z", but its `code` is still "KeyW". Also note `e.key` changes with Shift ("a" vs "A"); lowercase it if you use it for letters. For arrow keys both are the same.

## Stop the page scrolling

Arrow keys and Space scroll the page by default, which yanks your game out of view. Call `preventDefault()` for the keys your game uses:

```javascript
const GAME_KEYS = ["ArrowLeft", "ArrowRight", "ArrowUp", "ArrowDown", " "];

window.addEventListener("keydown", (e) => {
  if (GAME_KEYS.includes(e.key)) e.preventDefault();
  keys[e.key] = true;
});
```

Only block the keys you need; blocking everything breaks shortcuts and accessibility tools.

## Stuck keys and blur

If a player holds Right and then clicks another window (or alt-tabs), your page never receives the `keyup`. When they come back, the character runs forever. Fix it by clearing the state when the window loses focus:

```javascript
window.addEventListener("blur", () => {
  for (const k in keys) keys[k] = false;
});
```

## Actions versus held keys

Some inputs are **actions** that should happen once per press: jump, fire, open a menu. Holding the key should not fire every frame. One approach is to record "pressed this frame" on `keydown` when `e.repeat` is false, and clear it at the end of each update. You will use this for jumping in the physics lesson.

## Remapping and accessibility

Designers should treat controls as data, not as letters scattered through the code:

```javascript
const bindings = { left: ["ArrowLeft", "a"], right: ["ArrowRight", "d"] };
const isDown = (action) => bindings[action].some((k) => keys[k]);
```

A table like this makes remapping a settings feature instead of a rewrite, and remappable controls are one of the most requested accessibility options in games. The Game Accessibility Guidelines (gameaccessibilityguidelines.com) list it as a basic recommendation.

## Common mistakes

- **Moving inside `keydown`.** Speed then depends on OS key repeat.
- **No `blur` handler.** Keys stick after alt-tab.
- **Listening on the canvas without focus.** Canvas elements do not receive key events unless focusable (`tabindex="0"`) and focused; listening on `window` avoids the problem in prototypes.
- **Checking `e.key === "a"` while Shift is held** (it is "A").
- **Calling `preventDefault` on every key**, which blocks browser shortcuts.

## Quick recap

- Events (`keydown`/`keyup`) update a `keys` state object.
- `update(dt)` reads that state every frame and moves with delta time.
- Opposite directions cancel; clear keys on `blur`.
- `preventDefault` only for game keys; prefer `e.code` for WASD layouts.
- Treat bindings as data so they can be remapped.

## Try it

Open the Do tab to wire up `keydown`, `keyup` and `blur` handlers and drive the player from key state.

Track keyboard state with keydown and keyup, move a player from that state each frame, and avoid stuck keys.

Input handling

keyup and keydown events - Basic JavaScript Fast (68) | event.key, event.code

Keyboard Input Manager - HTML5 Game Development

Draw on an HTML canvas, run an update/draw loop with delta time, and respond to keyboard input.