Game designers are hired on finished, playable work. This mid-level course takes you from design ideas to prototypes that run, and from prototypes to a published game and a portfolio.

In four modules you write the core of a 2D game in plain JavaScript and HTML canvas (drawing, an update/draw loop with delta time, keyboard input), then the mechanics most games rely on (AABB collision, gravity and jumping, and game flow as a finite state machine). You compare Unity, Godot and Unreal, build your first scene in Godot, and tune difficulty from playtest data with a seeded random number generator. Finally you scope a 48-hour game jam entry, publish a browser build on itch.io, and present your work as design breakdowns.

Every lesson has a reading with worked examples, free videos, a quiz and an in-browser coding exercise or a hands-on task with free tools. You should have finished Game Design Fundamentals and JavaScript Essentials first.

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.

The Game Loop in Code

## Why this matters

Almost every mechanic is a collision question in disguise. Did the bullet hit the enemy? Is the player standing on a platform? Did the mouse click a button? Is the coin inside the pickup radius? You need an answer that is correct, fast enough to run hundreds of times per frame, and simple enough to debug at 2 a.m. during a jam. For 2D prototypes the answer is usually the **axis-aligned bounding box**, or AABB.

## What an AABB is

An AABB is a rectangle whose sides line up with the x and y axes (it is never rotated). Store it the same way you draw it:

```javascript
const player = { x: 10, y: 20, w: 16, h: 24 };   // x, y = top-left corner
```

Its edges are:

- left = `x`, right = `x + w`
- top = `y`, bottom = `y + h`

Even when the art is a circle or a character with flowing hair, a box that roughly fits is usually good enough. Many games make the **hitbox** slightly smaller than the sprite so near-misses feel fair to the player.

## The overlap test

Two boxes overlap when they overlap on **both** axes at once. Thinking about the opposite is easier: they are apart if one is completely to the left, right, above or below the other. Flip that and you get the classic test:

```javascript
function aabbOverlap(a, b) {
  return a.x < b.x + b.w &&   // a's left is left of b's right
         a.x + a.w > b.x &&   // a's right is right of b's left
         a.y < b.y + b.h &&   // a's top is above b's bottom
         a.y + a.h > b.y;     // a's bottom is below b's top
}
```

Worked example. `a = {x: 0, y: 0, w: 10, h: 10}` and `b = {x: 5, y: 5, w: 10, h: 10}`:

- 0 < 15, 10 > 5, 0 < 15, 10 > 5: all true, so they overlap (a 5×5 square is shared).

Move `b` to `x: 10`. Now `a.x + a.w > b.x` is `10 > 10`, which is false. The boxes **touch** along an edge but do not overlap. Using strict `<` and `>` means touching is not a hit, which is what you want for a player standing exactly on top of a floor: they rest on it without "colliding into" it every frame. Whichever rule you pick, pick it deliberately and use it everywhere.

## Point in rectangle

Clicks, cursor hover and small projectiles are points. A point is inside a box if it lies within both ranges:

```javascript
function pointInRect(px, py, r) {
  return px >= r.x && px < r.x + r.w &&
         py >= r.y && py < r.y + r.h;
}
```

Here the left/top edge counts as inside and the right/bottom edge does not. That "half-open" convention means a point on the shared border of two touching tiles belongs to exactly one of them, never both or neither.

## Checking many objects

A simple loop is fine for prototypes:

```javascript
function findHits(player, others) {
  const hits = [];
  others.forEach((o, i) => {
    if (aabbOverlap(player, o)) hits.push(i);
  });
  return hits;
}
```

Returning indices (or the objects) and letting the caller decide what to do keeps the collision code **pure**: it answers a question and changes nothing. The game then decides that touching a coin adds score, touching spikes costs a life, and so on. Mixing detection with response makes bugs hard to find.

With a few hundred objects, checking every pair is still cheap. When you have thousands, games use a **broad phase** such as a uniform grid: only test objects in the same or neighbouring cells. Do not build that until profiling says you need it.

## Tunnelling

Collision is checked at discrete moments. A fast bullet moving 40 pixels per frame can be on one side of a 10-pixel wall in one frame and on the other side in the next, never overlapping it. Fixes, roughly from simplest:

- cap the speed or make thin walls thicker,
- split the movement into smaller sub-steps,
- use a **swept** test or a ray cast along the path.

This is also why the previous lesson capped delta time.

## Beyond boxes

- **Circles:** two circles overlap when the distance between centres is less than the sum of radii. Compare squared distances to avoid `Math.sqrt`.
- **Rotated shapes:** use the Separating Axis Theorem (SAT), covered in the Nybbit video. Engines like Godot do this for you.

## Common mistakes

- **Using `<=`** in one place and `<` in another, so touching counts as a hit sometimes.
- **Treating x, y as the centre** in one function and the corner in another.
- **Forgetting width/height** and comparing only `x` values.
- **Changing state inside the detection function**, which makes the order of checks matter.
- **Hitboxes equal to sprite bounds**, which makes near-misses feel unfair.

## Quick recap

- An AABB is `{x, y, w, h}` with sides along the axes.
- Boxes overlap when they overlap on both axes; strict comparisons mean touching is not a hit.
- Points use a half-open range so shared borders belong to one box.
- Keep detection pure; let the game decide the response.
- Watch out for tunnelling with fast objects.

## Try it

Open the Do tab to write `aabbOverlap`, `pointInRect` and `findHits` as pure functions.

Detect overlaps between axis-aligned boxes and points, and find every object a player touches.

Collision detection

Simple AABB Collision Explained [Colliders: Part 1]

AABB vs SAT - 2D Collision Detection

## Why this matters

Jumping is the signature verb of a whole genre, and "game feel" lives in a handful of numbers: how hard gravity pulls, how fast the jump starts, what happens when the player lets go of the button. You do not need a physics engine to get a great jump. You need three ideas (velocity, acceleration, ground contact) and the discipline to tune them as design values, not magic numbers.

## Position, velocity, acceleration

Each frame:

1. **acceleration** changes **velocity**,
2. **velocity** changes **position**.

Gravity is a constant downward acceleration. With `y` growing downwards on a canvas, gravity is **positive**:

```javascript
const GRAVITY = 1800;   // pixels per second per second

function applyPhysics(dt) {
  player.vy += GRAVITY * dt;    // velocity changes by acceleration
  player.y  += player.vy * dt;  // position changes by velocity
}
```

Updating velocity first and then position with the new velocity is called **semi-implicit Euler** integration. It is simple and stable enough for most games. Because both lines multiply by `dt`, the jump is roughly the same height at 30 fps and 144 fps (here about 90 px vs 98 px; a fixed timestep makes it identical on every machine).

## Landing on the ground

Without a floor the player falls forever. The simplest floor is a single line:

```javascript
const GROUND_Y = 180;

if (player.y + player.h >= GROUND_Y) {
  player.y = GROUND_Y - player.h;   // snap on top of the ground
  player.vy = 0;                    // stop falling
  player.onGround = true;
} else {
  player.onGround = false;
}
```

Two things matter. **Snap** the player to the surface so they never sink in. **Zero the velocity**, or gravity keeps building speed while they stand still and the next step off a ledge becomes a sudden plunge. For platforms, apply the same idea with the AABB test from the last lesson: if the player is falling (`vy > 0`) and overlaps a platform, put them on top of it.

## The jump

A jump is an instant upward velocity, applied only when standing:

```javascript
const JUMP_SPEED = 600;

function jump() {
  if (!player.onGround) return;   // no infinite air jumps
  player.vy = -JUMP_SPEED;        // negative = up on a canvas
  player.onGround = false;
}
```

Gravity then slows the rise, stops it at the peak and pulls the player back down. Physics gives you the shape for free: the peak height is `JUMP_SPEED² / (2 × GRAVITY)`. With 600 and 1800 that is 100 pixels, and the time to the peak is `600 / 1800 = 0.33` seconds. Designers often work backwards: choose the height and time to peak you want, then solve for gravity and jump speed. The GDC talk "Building a Better Jump" walks through this method.

## Variable jump height

In many platformers, tapping jump gives a hop and holding it gives a full jump. A simple way to get that: when the player **releases** the button while still rising fast, cut the upward speed.

```javascript
const JUMP_CUT = 0.5;

function releaseJump() {
  const minRise = -JUMP_SPEED * JUMP_CUT;
  if (player.vy < minRise) player.vy = minRise;   // still rising fast: slow down
}
```

If the player is already falling or rising slowly, nothing changes, so a late release does not cause a strange mid-air stop.

## Feel tricks worth knowing

- **Coyote time:** allow a jump for about 0.1 s after walking off a ledge. Players perceive this as fair, not as cheating.
- **Jump buffering:** remember a jump press made just before landing and perform it on landing.
- **Higher gravity when falling:** many games multiply gravity by 1.5 to 2 on the way down for a snappier arc.
- **Terminal velocity:** cap `vy` so long falls stay readable.

Each of these is a few lines once the basic state (`vy`, `onGround`) exists. Add them one at a time and playtest each.

## Treat numbers as design data

Put tuning values in one place, name them, and show them on screen or in a debug panel while you play:

```javascript
const TUNING = { GRAVITY: 1800, JUMP_SPEED: 600, JUMP_CUT: 0.5, MAX_FALL: 900 };
```

A designer who can change jump height in five seconds will try twenty variations; one who must hunt through code will try two.

## Common mistakes

- **Gravity with the wrong sign.** On a canvas, down is positive.
- **Not resetting `vy` on landing**, so speed keeps building while standing.
- **Jumping without checking `onGround`**, which gives infinite jumps.
- **Forgetting `dt`** in either line, which makes the jump depend on frame rate.
- **Setting `onGround` only to true**, never back to false when walking off a ledge.

## Quick recap

- Acceleration changes velocity; velocity changes position, both times `dt`.
- Snap to the ground, zero `vy`, track `onGround`.
- Jump = set `vy` to a negative speed, only from the ground.
- Releasing early cuts upward speed for variable height.
- Name your tuning values and tweak them while playing.

## Try it

Open the Do tab to implement `applyPhysics`, `jump` and `releaseJump` for a canvas platformer.

Add gravity, ground contact, jumping and variable jump height to a canvas platformer.

Simple physics

Math for Game Programmers: Building a Better Jump

5 tips for better platformer controls

## Why this matters

A prototype quickly grows more than one "mode": a title screen, the game itself, a pause screen, a game-over screen with a restart button. Without structure this becomes a nest of flags (`isPaused`, `isDead`, `hasStarted`, `showMenu`) that can contradict each other. Players then find the bug where pressing pause on the game-over screen revives them. A **finite state machine** (FSM) removes that whole class of bugs by making the modes explicit.

## The idea

A finite state machine has:

- a fixed set of **states** (exactly one is current),
- a set of **events** (things that happen: a key press, a hit, a timer),
- **transitions**: rules saying "in state S, event E moves you to state T".

Anything not listed is ignored. For a typical arcade game:

| from | event | to | side effect |
|---|---|---|---|
| menu | START | playing | score = 0, lives = 3 |
| playing | PAUSE | paused | |
| paused | RESUME | playing | |
| playing | HIT | playing or gameover | lives - 1; gameover at 0 |
| playing | SCORE | playing | score + points |
| gameover | RESTART | menu | |

The table *is* the design. Write it before any code, and show it to teammates: holes ("what does Escape do on the game-over screen?") become obvious.

## A pure transition function

The cleanest implementation is a function that takes the current game and an event and returns the **next** game, without changing the input:

```javascript
function createGame() {
  return { state: "menu", score: 0, lives: 3 };
}

function transition(game, event) {
  switch (game.state) {
    case "menu":
      if (event.type === "START") return { state: "playing", score: 0, lives: 3 };
      return game;
    case "playing":
      if (event.type === "PAUSE") return { ...game, state: "paused" };
      if (event.type === "SCORE") return { ...game, score: game.score + event.points };
      if (event.type === "HIT") {
        const lives = game.lives - 1;
        return { ...game, lives, state: lives <= 0 ? "gameover" : "playing" };
      }
      return game;
    // paused and gameover follow the same pattern
    default:
      return game;
  }
}
```

Events are objects (`{ type: "SCORE", points: 10 }`) so they can carry data. The spread `{ ...game, ... }` copies the old fields and overrides a few, so the original is untouched.

Why bother with purity?

- **Testing:** `transition(createGame(), { type: "START" })` is a one-line test with no canvas, timer or keyboard.
- **Replays and debugging:** a list of events plus the starting state reproduces any bug exactly.
- **Undo, rewind, networking:** keeping old states is free when nothing mutates them.

## Ignoring invalid events

Notice the `return game;` lines. A `HIT` in the menu, a `PAUSE` on the game-over screen, a `SCORE` while paused: all ignored. This is the main safety property of an FSM. Instead of asking "which flags must I check here?", each state lists what it accepts and everything else is a no-op.

## Wiring it to the loop

The game loop asks the state what to do:

```javascript
let game = createGame();

function update(dt) {
  if (game.state === "playing") updateWorld(dt);   // physics only while playing
}

function draw() {
  drawWorld();
  if (game.state === "menu") drawTitle();
  if (game.state === "paused") drawOverlay("Paused");
  if (game.state === "gameover") drawOverlay(`Game over: ${game.score}`);
}

window.addEventListener("keydown", (e) => {
  if (e.key === "Enter") game = transition(game, { type: game.state === "gameover" ? "RESTART" : "START" });
  if (e.key === "Escape") game = transition(game, { type: game.state === "paused" ? "RESUME" : "PAUSE" });
});
```

Input handlers translate keys into events; the transition function decides what those events mean right now.

## When states get bigger

- **Enter/exit actions:** run code once when entering a state (play a jingle on game over).
- **Hierarchical states:** "playing" can contain sub-states like "alive", "respawning", "level-complete".
- **Per-entity FSMs:** enemies use the same pattern: idle, patrol, chase, attack. The NesHacker video shows how classic games used state machines for almost everything.
- **Behaviour trees** replace FSMs for complex AI, but an FSM is the right first tool for game flow.

## Common mistakes

- **Boolean soup:** several flags that can be true at once instead of one `state` value.
- **Mutating the input** in a function meant to be pure, so tests pass or fail depending on order.
- **Forgetting to reset** score and lives on START, so a new run keeps the old score.
- **Handling events everywhere:** pause logic scattered across input, physics and UI code.
- **Using `<` instead of `<=`** for lives, so the player gets an extra life at zero.

## Quick recap

- One `state` value, a fixed list of events, and a transition table.
- A pure `transition(game, event)` returns a new game and ignores invalid events.
- The loop updates and draws based on the current state.
- Write the table first; it is the design.

## Try it

Open the Do tab to implement `createGame` and a pure `transition` function for menu, playing, paused and game over.

Model menu, play, pause and game-over as a finite state machine with a pure transition function.

Game states

An introduction to finite state machines and the state pattern for game development

How NES Games Use State Machines For Everything

Detect AABB collisions, add gravity and jumping, and structure game flow as a state machine.

Mechanics

## Why this matters

Hand-written canvas code is perfect for testing one mechanic in an afternoon. Once a prototype needs animation tools, a tile map editor, audio mixing, physics with many bodies, or builds for consoles and phones, an **engine** saves weeks. Choosing one is a real design decision: it affects what your team can build, how fast you can iterate, what it costs, and which jobs your portfolio points towards. The good news is that the core skills (loops, state, collisions, tuning) transfer between all of them.

## What an engine gives you

- An **editor** for placing objects, building levels and tweaking values while the game runs.
- **Rendering**, **physics**, **audio**, **input** and **animation** systems.
- A **scripting language** for your game logic.
- **Export** to Windows, macOS, Linux, the web, mobile and (with licences) consoles.
- An **asset pipeline**: importing images, models and sounds.

## The big three for indie and studio work

| | Godot | Unity | Unreal Engine |
|---|---|---|---|
| Licence | Free and open source (MIT), no fees or royalties | Proprietary; free tier with revenue limits, paid plans above | Source-available; free to use, royalty on revenue above a threshold for games |
| Languages | GDScript (Python-like), C#, C++ via GDExtension | C# | C++ and Blueprints (visual scripting) |
| Strengths | Small download, fast to open, great for 2D, readable scene/node system | Huge ecosystem and asset store, strong mobile and 2D/3D, very common in industry job ads | High-end 3D graphics, large worlds, used by many AAA studios |
| Watch out for | Smaller asset ecosystem; console export goes through third parties | Licence terms have changed over the years; check the current ones | Heavy downloads and hardware needs; C++ learning curve |

Licensing and pricing change, so always read the official terms before committing a commercial project: godotengine.org/license, unity.com/products/compare-plans and unrealengine.com/eula. Checked on 2026-10-23. In 2023 Unity announced a per-install "runtime fee", faced strong backlash and cancelled it in 2024; the lesson for designers is to read the terms yourself, not to assume they stay the same.

Other tools worth knowing: **GameMaker** (2D, very popular with indies), **Defold** (light 2D and mobile), **Phaser** (JavaScript, browser games), **Bevy** (Rust), **PICO-8** (tiny fantasy console, superb for practice), and **Twine** (interactive fiction, no code required). For pure design exploration, a paper prototype or a spreadsheet still beats any engine.

## How to choose

Ask questions in this order:

1. **What is the prototype trying to learn?** A card-game economy might need only a spreadsheet. A movement feel test needs a real-time loop.
2. **2D or 3D, and how ambitious visually?** For 2D, Godot, GameMaker and Unity are all excellent. For photoreal 3D, Unreal leads.
3. **Target platforms.** Web builds are easiest from Godot, Unity and Phaser. Console work needs a licensed developer account and usually a studio.
4. **Team skills.** A team of C# developers will be productive in Unity or Godot with C#; artists who want visual scripting may prefer Unreal Blueprints.
5. **Licence and cost.** Open source and royalty-free removes a risk for small teams.
6. **Career goals.** Look at job ads for the studios you want to work at. Many mid-size studios list Unity; AAA studios often list Unreal; indie and education roles increasingly list Godot.

## A worked decision

A two-person team wants to make a 2D pixel-art roguelike for a 48-hour jam, playable in the browser, with one programmer who knows Python. **Godot** fits: GDScript reads like Python, 2D tools are strong, web export works, and there are no licence questions. If the same team were building a 3D shooter with realistic lighting for a publisher pitch, **Unreal** would be the stronger choice. A studio porting its mobile line-up would likely stay with **Unity** because its code, tools and staff already use it.

## Engine-agnostic habits

Whatever you choose:

- Keep tuning values in one place (resources, data files, scriptable objects).
- Separate game rules from presentation, as you did with `update` and `draw`.
- Use version control (Git, with large-file support for big assets) from day one.
- Prototype the riskiest question first, not the menu screen.

## Common mistakes

- **Engine-hopping** instead of finishing anything. Pick one for a project and ship.
- **Choosing by graphics demos** when your game is 2D and small.
- **Ignoring licence terms** until a game earns money.
- **Learning the engine instead of designing.** Use the engine to answer design questions.

## Quick recap

- Engines provide editor, rendering, physics, audio, scripting and export.
- Godot: free, open source, great 2D, GDScript. Unity: C#, huge ecosystem, common in jobs. Unreal: C++/Blueprints, top-end 3D.
- Decide by the question you are testing, 2D/3D, platforms, team skills, licence and career goals.
- Always check the current official licence terms.

## Try it

This lesson is quiz only. Next, you will build your first scene in Godot.

Compare Unity, Godot and Unreal on licensing, languages, platforms and fit, and pick a tool for a given project.

Choosing an engine

choosing a game engine is easy, actually

Godot in 100 Seconds

Download the standard Godot 4 build from godotengine.org/download, open it, and in the Project Manager create a new project in an empty folder (Compatibility or Forward+ renderer both work).

Create a new scene with a Node2D root named Main and save it as main.tscn. Set it as the main scene (Project > Project Settings > Application > Run > Main Scene, or accept the prompt the first time you press F5).

Add a StaticBody2D named Floor with a CollisionShape2D (new RectangleShape2D, about 600 by 40) and a ColorRect or Sprite2D so you can see it. Place it near the bottom of the view.

Add a CharacterBody2D named Player above the floor, with a Sprite2D (drag the default icon.svg into its Texture) and a CollisionShape2D sized to fit the sprite. Check that no yellow warning icons remain in the Scene tree.

Attach a script to Player and paste the script from the reading (gravity, jump on ui_accept, Input.get_axis for left and right, move_and_slide). Press F5 and confirm you can walk, fall and jump.

Turn SPEED, JUMP_SPEED and GRAVITY into @export variables, select Player and change them in the Inspector. Try at least three combinations and note which feels best.

Open Project > Project Settings > Input Map, add a jump action bound to Space, W and a gamepad button, and change the script to use "jump" instead of "ui_accept". Run again to confirm it works.

Save the project and, if you use Git, commit it (Godot projects are plain text and diff well; add the .godot/ folder to .gitignore).

## Why this matters

Your canvas prototypes taught you the moving parts of a game: a loop, state, input, collision and gravity. An engine packages those parts so you can spend your time on design. Godot is a good first engine for a designer: it is free and open source, the download is small, it runs on modest laptops, and its language, GDScript, reads like Python. In this lesson you will map what you already know onto Godot's concepts and build a playable scene.

## Getting Godot

Download the **standard** build of Godot 4 from **godotengine.org/download** (the ".NET" build is only needed for C#). On Windows and Linux it is a single executable you can run without installing; on macOS it is an app bundle. Steam and itch.io also distribute it. Use the latest stable 4.x release. Checked on 2026-10-23.

## Nodes and scenes

Everything in Godot is a **node**: a sprite, a camera, a sound, a collision shape, a timer. Nodes form a **tree**. A saved tree is a **scene** (`.tscn` file). A scene can be a whole level, or a single reusable thing like a player or a coin, and scenes can be placed inside other scenes (called instancing). This replaces most of the hand-rolled structure you wrote in JavaScript.

A typical 2D player scene:

```text
Player (CharacterBody2D)      <- moves and collides; holds the script
├── Sprite2D                  <- the picture
└── CollisionShape2D          <- the hitbox (a RectangleShape2D or CapsuleShape2D)
```

A floor:

```text
Floor (StaticBody2D)          <- does not move, but others collide with it
├── Sprite2D (or ColorRect)
└── CollisionShape2D
```

Mapping to what you know:

| your canvas code | Godot |
|---|---|
| `player = { x, y, w, h }` | a `CharacterBody2D` with `position` and a `CollisionShape2D` |
| `update(dt)` | `_physics_process(delta)` (called at a fixed 60 Hz by default) |
| `draw()` | automatic: nodes draw themselves |
| `keys.ArrowLeft` | `Input.is_action_pressed("ui_left")` or `Input.get_axis(...)` |
| AABB + landing code | `move_and_slide()` and `is_on_floor()` |

## Your first script

Select the Player node and click the **Attach Script** button. Godot creates a file starting with `extends CharacterBody2D`. Replace its contents with:

```gdscript
extends CharacterBody2D

const SPEED := 220.0
const JUMP_SPEED := 450.0
const GRAVITY := 1200.0

func _physics_process(delta: float) -> void:
	if not is_on_floor():
		velocity.y += GRAVITY * delta

	if Input.is_action_just_pressed("ui_accept") and is_on_floor():
		velocity.y = -JUMP_SPEED

	var direction := Input.get_axis("ui_left", "ui_right")
	velocity.x = direction * SPEED

	move_and_slide()
```

Read it next to your JavaScript from module 2. `velocity` is a built-in `Vector2` on `CharacterBody2D`. Gravity is added only in the air. `ui_accept` is a built-in input action (Enter and Space by default). `Input.get_axis` returns -1, 0 or 1 from two actions, so opposite keys cancel exactly as yours did. `move_and_slide()` moves the body by `velocity`, handles collisions with the floor, and updates `is_on_floor()`. GDScript uses **tabs** for indentation, like Python uses indentation for blocks.

## Input actions

Hard-coding keys is the mistake you avoided in the input lesson. Godot builds that idea in: **Project > Project Settings > Input Map** lets you define actions such as `jump` and bind several keys and gamepad buttons to each. Your code then asks for `"jump"`, and players or designers can remap without code changes.

## Running and iterating

- **F5** runs the main scene (Godot asks you to choose one the first time). **F6** runs the scene you are editing.
- Change `SPEED` while the game runs and save: many changes apply live. Even better, mark tuning values with `@export var speed := 220.0` and they appear in the **Inspector**, where a designer can tweak them without opening the script.
- Use `print()` for quick debugging; output appears in the bottom panel.

## Common mistakes

- **Forgetting the CollisionShape2D** (Godot shows a yellow warning triangle on the node). Without it, the player falls through the floor.
- **Moving a CharacterBody2D by setting `position`** instead of using `velocity` and `move_and_slide()`, which skips collision.
- **Mixing tabs and spaces** in GDScript.
- **Writing physics in `_process`** instead of `_physics_process`.
- **Not setting a main scene**, so F5 asks every time.

## Quick recap

- Godot organises everything as nodes in trees saved as scenes.
- `CharacterBody2D` + `CollisionShape2D` + `Sprite2D` is a typical player.
- `_physics_process(delta)` is your update; `move_and_slide()` does movement and collision.
- Use the Input Map and `@export` variables to keep controls and tuning editable.

## Try it

Open the Do tab and build the scene step by step. It takes about 30 minutes with the editor open.

Install Godot, build a 2D scene from nodes, and attach a GDScript that moves a character with gravity and input.

First scene in Godot

Godot 4 Crash Course #1 - The Basics

Godot 4 Crash Course #2 - Coding in Godot

## Why this matters

"It feels too hard" is useful feedback, but it does not tell you **which** level, **how much** too hard, or whether your change helped. Studios combine playtest observation with simple numbers: how many players finished each level, how many attempts it took, where they quit. You do not need a data team to do this. A list of session records, a few small functions and a clear target turn vague opinions into decisions you can check.

## What to record

Decide the question first, then log the minimum that answers it. For difficulty, a per-attempt record is enough:

```javascript
const sessions = [
  { player: "p1", level: 1, completed: true,  deaths: 1, seconds: 42 },
  { player: "p1", level: 2, completed: false, deaths: 6, seconds: 180 },
  { player: "p2", level: 1, completed: true,  deaths: 0, seconds: 35 },
  { player: "p2", level: 2, completed: true,  deaths: 3, seconds: 150 },
];
```

In a jam game, these records can come from a notes sheet you fill in while watching, a `console.log` you copy out, or a simple download button. Respect privacy: record play, not personal data, and tell testers what you collect.

## From records to rates

The **completion rate** of a level is completed attempts divided by all attempts:

```javascript
function completionRates(sessions) {
  const totals = {};
  for (const s of sessions) {
    totals[s.level] ??= { done: 0, all: 0 };
    totals[s.level].all += 1;
    if (s.completed) totals[s.level].done += 1;
  }
  const rates = {};
  for (const level in totals) rates[level] = totals[level].done / totals[level].all;
  return rates;
}
// { 1: 1, 2: 0.5 }
```

Look at other numbers too: **average deaths**, **median time** (one stuck player can inflate an average), and **drop-off** (players who never attempted the next level). A level with a fine completion rate but ten deaths per clear may still be frustrating.

## Set a target, then adjust

Numbers need a goal. A designer might decide: "early levels should be completed by about 80% of attempts; the final boss by about 50%." With a target, you can turn a difficulty parameter (enemy speed, spawn interval, timer length) up or down by a small step:

```javascript
function adjustDifficulty(value, rate, target, step, min, max) {
  if (rate < target) value -= step;   // too hard: make it easier
  else if (rate > target) value += step;   // too easy: make it harder
  return Math.max(min, Math.min(max, value));
}
```

Small steps and clamped ranges matter. Large jumps overshoot ("now it is trivial"), and an unclamped value can drift into nonsense like negative enemy speed. Change **one** parameter at a time between playtests, or you will not know which change caused the result.

## Seeded randomness for fair comparisons

Random spawns make two playtests hard to compare: maybe level 2 just rolled more enemies this time. A **seeded** random number generator produces the same sequence every time from the same seed, so you can replay identical conditions and simulate many runs:

```javascript
function makeRng(seed) {           // mulberry32: small, fast, good enough for games
  let a = seed >>> 0;
  return function () {
    a = (a + 0x6D2B79F5) >>> 0;
    let t = a;
    t = Math.imul(t ^ (t >>> 15), t | 1);
    t ^= t + Math.imul(t ^ (t >>> 7), t | 61);
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

const rng = makeRng(42);
rng(); // always the same first value for seed 42
```

`Math.random()` cannot be seeded, so games that need replays, daily challenges or procedural levels ship their own generator. Many roguelikes let players share a seed to play the same map.

## Simulating before playtesting

With a seeded RNG you can run a crude **simulation**: if a level kills a player with probability `p` per encounter and has `n` encounters, how many of 1,000 simulated runs survive? Simulations are cheap and catch obvious problems, but they model your assumptions, not real people. Use them to choose what to test, then confirm with humans.

## Data is not the whole story

The Extra Credits video makes the point that balance is about meaningful choices, not equal numbers. Data tells you **where** players struggle; watching them tells you **why**. A 40% completion rate might mean the level is too hard, or that the exit is hard to find, or that a control is confusing. Pair every chart with observations.

## Common mistakes

- **Averages hiding outliers**: use medians or look at the distribution.
- **Tiny samples**: five testers is enough to spot big problems, not to tune by 2%.
- **Changing several things at once**, so results cannot be attributed.
- **No target**, so every number looks "about right".
- **Optimising the metric**, not the experience (a level everyone completes because it is boring).

## Quick recap

- Log just enough per attempt: level, completed, deaths, time.
- Completion rate = completed / attempts; also check deaths, medians and drop-off.
- Set targets; adjust one parameter by small, clamped steps.
- Seeded RNGs make runs repeatable and simulations possible.
- Combine numbers with observation.

## Try it

Open the Do tab to write `completionRates`, `hardestLevel`, `adjustDifficulty` and a seeded `simulateRuns`.

Summarise playtest sessions into completion rates, find the problem level, and adjust a difficulty value towards a target.

Tuning with data

Balancing for Skill - The Link from Optimal Power to Strategy - Extra Credits

How Games (Secretly) Adjust Difficulty

Compare Unity, Godot and Unreal, build a first scene in Godot, and tune difficulty from playtest data.

Engines and Tools

Pick a theme: use the current or upcoming theme from a jam listed on itch.io/jams, or choose a past Ludum Dare theme.

Brainstorm at least 10 one-sentence ideas in 15 minutes without judging them.

For your top three, ask: could the core mechanic be playable with plain boxes in four hours? Choose the idea that passes most clearly.

Write the core-mechanic sentence at the top of the page.

List every feature you can think of and sort them into Must, Should and Could. Make sure the Must list includes a goal, a fail state and a restart.

Draw an hour-by-hour plan for 48 hours, including sleep, a fun check by hour 10, a feature freeze at least six hours before the end, and time to build, upload and test the uploaded build.

Mark which code from this course (loop, input, collision, physics, state machine) you would reuse, and which engine or tool you would use.

Show the plan to a friend or classmate and ask them to point to the feature they think is riskiest. Cut or simplify it.

## Why this matters

A game jam is an event where people make a game in a fixed, short time, usually around a theme announced at the start. Ludum Dare (48-hour solo and 72-hour team formats), Global Game Jam (a weekend, often at local sites) and the hundreds of online jams listed on itch.io are the best-known. For an aspiring designer, jams are the fastest way to build a portfolio of **finished** games, practise scoping, and meet collaborators. Many studios read jam entries when hiring, because a small finished game shows more than a large unfinished one.

## The real skill is scope

Almost every failed jam game fails the same way: too big. The idea is fine; the plan assumes everything will work first time. Experienced jammers design for about a **third** of the time they have, because the rest disappears into bugs, art, sound, menus, building and uploading.

Start from one sentence:

> "You are a lighthouse keeper who rotates the beam to guide boats past rocks."

That sentence is the **core mechanic**. If a feature does not make that mechanic more interesting, it waits.

## A 48-hour plan

| hours | goal |
|---|---|
| 0–2 | Read the theme, brainstorm 10 ideas, pick one by "can I prototype the core in 4 hours?" |
| 2–8 | Core mechanic playable with boxes and no art. Playtest it yourself. |
| 8–10 | Decide: is it fun? If not, change the idea now, not on Sunday. |
| 10–24 | Goal, fail state, restart (the state machine from module 2), a few levels or a scaling difficulty. Sleep. |
| 24–36 | Art pass, sound effects, juice (screen shake, particles), title and game-over screens. |
| 36–42 | **Feature freeze.** Fix bugs, tune with friends, write instructions on the start screen. |
| 42–48 | Build, upload, test the uploaded build, write the page. Submit early. |

Sleep is in the plan on purpose. Tired developers write bugs that cost more time than they save.

## Must, should, could

Write every feature on a list and sort it:

- **Must:** without it there is no game (move, the core mechanic, lose, restart).
- **Should:** makes it much better (three levels, sound, a score).
- **Could:** nice if time allows (leaderboard, story intro, extra enemy type).

Build all the musts before any should. When you fall behind (you will), cut from the bottom. A story intro is never worth a broken core loop.

## Worked example: cutting a plan

Theme: "Deeper and deeper". First idea: a submarine game with an upgrade shop, five biomes, a boss and a crafting system. Applying the rules:

- Core sentence: "Steer a falling submarine between hazards as it speeds up."
- Must: steering, hazards, speed increasing with depth, collision, depth score, restart.
- Should: two hazard types, sound, a high score in memory.
- Could: one upgrade between runs, a second biome palette.
- Cut entirely: crafting, boss, shop with many items.

The cut version reuses the AABB collision, game loop and state machine you already wrote and is realistic for one person in 48 hours.

## Working in a team

- Agree on the engine and version **before** the jam starts.
- Use version control from the first hour; decide who owns which files or scenes to avoid merge conflicts.
- Artists and musicians need specifications early: sizes, palette, file formats, how many animations.
- Hold a five-minute check-in every few hours: what is done, what is blocked, what is being cut.

## Rules and etiquette

Each jam has rules about what you may use (pre-made assets, existing code, AI-generated content) and when the theme may be used. Read them on the official page before you start; they differ between events. Credit every asset you did not make, with its licence. Rate and comment on other entries: jam communities run on feedback, and playing others' games is one of the best ways to learn.

## Common mistakes

- **Starting with menus and art** instead of the core mechanic.
- **No fail state or restart**, so testers play once and stop.
- **Testing only in the editor** and discovering the web build is broken at hour 47.
- **Adding features after the freeze**.
- **Skipping sleep and food.**

## Quick recap

- Pick an idea whose core can be playable in about four hours.
- Plan for a third of the time; freeze features well before the end.
- Sort features into must, should and could, and cut from the bottom.
- Build and upload early, and test the uploaded version.
- Read the jam rules and credit every asset.

## Try it

Open the Do tab to scope your own 48-hour jam game on paper.

Scope a 48-hour jam game around one core mechanic, plan the hours, and cut features before they cut you.

Game jams

Ludum Dare Tips: Planning

How to Scope Your Games Better | For Game Jams and Small-Term Projects

Pick the prototype and make sure it has a title screen or on-screen text explaining the controls and how to restart.

Make a browser build: for a canvas game, put index.html and assets in one folder; for Godot 4, install export templates and export a Web preset to index.html in an empty folder.

Test it locally with a small web server (for example python -m http.server in the build folder) and fix anything that breaks.

Zip the contents of the build folder so index.html is at the top level of the zip.

Create a free itch.io account, then Dashboard > Create new project. Set Kind of project to HTML, upload the zip, tick 'This file will be played in the browser', and set the viewport to your game's size.

Add a short description, controls, at least three screenshots, a cover image and credits for any assets you did not make. Set Visibility to Restricted (or Draft) for now.

Open the page in a private browser window, play it, and check focus, input, fullscreen and restart. Ask one other person to play it on their computer.

Fix what they found, upload the new zip, and decide whether to make the page Public. If you do not want to keep it, set it back to Draft or delete the project from your dashboard.

## Why this matters

A game nobody can play does not count in a portfolio. Publishing turns a project folder into a link you can put on a CV, share with a playtester or submit to a jam. **itch.io** is the standard home for jam games, prototypes and indie releases: creating an account and a page is free, browser games play instantly without downloads, and you can choose to charge, accept donations or give games away. It is also where most online jams are hosted, so you will use it constantly.

## Browser builds first

A game that runs in the browser removes every barrier: no download, no "Windows protected your PC" warning, no wrong operating system. For short prototypes it is the best default.

- **Plain HTML/canvas games** (like this course's module 1 and 2 prototypes): put `index.html` and any assets in a folder, then zip the **contents** of the folder, so `index.html` sits at the top level of the zip.
- **Godot 4**: install export templates (**Editor > Manage Export Templates**, then download), add a **Web** preset in **Project > Export**, and export to `index.html` in an empty folder. Zip that folder's contents. If the page shows an error about `SharedArrayBuffer` or cross-origin isolation, either export with **Thread Support** turned off in the Web preset, or tick the **SharedArrayBuffer support** option in itch.io's embed settings.
- **Unity**: use the **Web** (WebGL) build target, then zip the build folder's contents.

Always test locally first. Browsers block many games opened straight from the file system, so run a local server (for example `python -m http.server` in the build folder, then open `http://localhost:8000`).

## Creating the page

On itch.io: **Dashboard > Create new project**. The important fields:

| field | what to put |
|---|---|
| Title and project URL | the game's name; the URL becomes `yourname.itch.io/game-name` |
| Short description | one line that says what the player does |
| Classification | Games |
| Kind of project | **HTML** for browser builds (Downloadable for desktop builds) |
| Pricing | No payments, or "pay what you want" with a minimum of 0 |
| Uploads | your zip, with **This file will be played in the browser** ticked |
| Embed options | viewport size matching your canvas or Godot window, fullscreen button, mobile-friendly if it is |
| Visibility | **Draft** while you set up; **Restricted** to share privately; **Public** when ready |

## A page that gets played

Visitors decide in seconds. A good page has:

- a **cover image** (the dashboard shows the recommended size) that shows gameplay, not just a logo,
- **three to five screenshots** or a short GIF of real play,
- **controls** written clearly near the top ("Arrow keys to move, Space to jump, R to restart"),
- a short description: the hook, the goal, how long a run takes,
- **credits** for every asset, font and sound you did not make, with licences,
- accurate **tags** (genre, input method, "short", "jam") so people can find it.

## Test the published build

Before you share the link:

1. Open the page in a private browser window (to see it as a stranger does).
2. Click to play, then check input works: canvas games may need a click to receive keyboard focus, so say "click the game to start" if needed.
3. Try fullscreen, and a second browser.
4. If your game uses `localStorage` for saves, check it still works when embedded (itch.io serves games from a separate domain inside an iframe).
5. Ask one person on a different computer to play it.

## Updating and devlogs

Uploading a new zip replaces the build; players get the new version the next time the page loads. itch.io's **devlog** feature lets you post update notes, which keeps followers informed and shows employers how you iterate. For jams, check the rules: many allow bug-fix uploads after the deadline but not new content.

## Selling and legal basics

If you charge money, itch.io handles payments and takes a share you choose (the default "open revenue sharing" lets you pick). You will be asked for tax information before payouts. Details change, so read itch.io's official documentation (itch.io/docs/creators) before you sell. Checked on 2026-10-23. Never upload assets you do not have the rights to publish.

## Common mistakes

- **Zipping the folder instead of its contents**, so itch.io cannot find `index.html`.
- **Wrong viewport size**, which crops the game or adds scroll bars.
- **No controls on the page.**
- **Publishing public before testing** the uploaded build.
- **Missing credits** for third-party assets.

## Quick recap

- Browser builds are the easiest for players; zip the build so `index.html` is at the top.
- Create the project as HTML, tick "played in the browser", set the viewport.
- Use Draft or Restricted until you have tested it as a stranger.
- Show gameplay, controls and credits on the page.

## Try it

Open the Do tab to publish one of your prototypes as a restricted itch.io page.

Export a browser build, upload it to itch.io with a clear store page, and test it before making it public.

Publishing on itch.io

How To Publish A Game On ITCH.IO

Uploading Your Game to Itch.io Tutorial 2025

Choose the project with the clearest design story: a problem you noticed, a change you made and a result.

Write the header: title, one-line pitch, your role, team size, time frame, tools and a working play link (for example your itch.io page).

State the design goal in one or two sentences.

Describe two or three key decisions. For each, write the reason and at least one alternative you rejected.

Add evidence: playtest notes, completion rates or deaths per level, a before/after GIF or screenshot, or your tuning values.

Finish with the result and an honest reflection: what worked, what did not, what you would try next.

Cut it to one page. Replace long paragraphs with headings, bullet points and one or two images.

Ask someone outside games to read it in two minutes and tell you what you designed and why. Revise anything they could not answer.

## Why this matters

Game designer roles are competitive, and most studios hire designers on evidence: what have you made, and how do you think? A degree in game design or computer science is common, but it is not a licence and it is rarely enough on its own. A portfolio of shipped prototypes and jam games, presented as **design breakdowns**, is what gets you an interview. This lesson turns the work from this course into that evidence.

## What reviewers look for

Hiring managers often spend only a few minutes on a portfolio. In that time they want to see:

- **Finished, playable work.** Links that open and games that run.
- **Your specific contribution.** On a team project, what did *you* design?
- **Process, not just results.** The problem, the options you considered, what you tested and what you changed.
- **Fit for the role.** A level designer shows levels and blockouts; a systems designer shows economies, spreadsheets and tuning; a technical designer shows scripts and tools.
- **Communication.** Clear writing and diagrams, because designers explain ideas all day.

## The design breakdown

A breakdown is a short case study, one page per project. A structure that works:

1. **Header:** title, one-line pitch, your role, team size, time frame, tools, a link to play.
2. **The goal:** what you were trying to achieve ("make a jump that feels responsive for new players").
3. **Key decisions:** two or three decisions, each with the reasoning and the alternatives you rejected.
4. **Evidence:** playtest notes, a chart of completion rates, before/after GIFs, a tuning table.
5. **Result and reflection:** what worked, what did not, what you would do next.

Worked example, written from this course's work:

> **Ledge Runner** (solo, 48-hour jam, HTML canvas). Goal: a platformer that new players can finish in five minutes. In the first playtest only 2 of 6 testers cleared level 2. Watching them showed they misjudged jumps, not that the level was long. I added coyote time (0.1 s) and variable jump height, and reduced the gap on the second jump. Completion rose to 5 of 6 in the next session. I chose not to add a double jump because it would have made the level's main challenge trivial. Next time I would add a visible landing shadow.

It is short, specific, honest about the numbers, and shows judgement. That is the tone to aim for.

## Formats

- A simple **website** (a free static host, or a well-organised itch.io profile) with one page per project.
- A **PDF** version for applications that ask for one.
- **Short videos or GIFs** for anything that needs motion to understand; keep them under a minute.
- **Design documents** (a one-page GDD from the Game Design Fundamentals course) as supporting material, not the headline.

Put your best two or three projects first. Three strong, well-explained projects beat ten thin ones.

## Your CV and the rest

- A one-page CV that leads with projects and skills (engines, scripting, tools like spreadsheets and level editors).
- A short, specific cover note per application that names the studio's games and why your work fits.
- Respect non-disclosure agreements: never show unreleased work from a job or a client without permission.
- Keep links working. A broken link is the fastest way to lose a reviewer.

## Entry routes

Common paths into design include QA testing, junior or associate designer roles, level design, technical design (scripting), and moving across from programming or art. Game jams, modding communities and open-source game projects all count as real experience. Industry bodies such as the IGDA (igda.org) publish career resources and run local chapters. Checked on 2026-10-23.

## Common mistakes

- **Showing only screenshots**, with no explanation of your decisions.
- **Vague roles** on team projects ("worked on the game").
- **Unfinished projects first.**
- **Walls of text.** Use headings, short paragraphs and images.
- **Claiming credit** for work others did. Studios check, and the industry is small.

## Quick recap

- Studios hire designers on evidence: finished work plus clear reasoning.
- Write one-page breakdowns: goal, decisions, evidence, result, reflection.
- Lead with your best two or three projects and make every link work.
- State your role precisely and credit others.
- Jams, mods and QA roles are real entry routes.

## Try it

Open the Do tab to write a design breakdown for one of your prototypes.

Present your prototypes as design breakdowns that show the problem, your decisions, the evidence and the result.

Designer portfolio

Get Hired: Portfolio Design - How to Build a Portfolio - Extra Credits Game Design

Game Design Portfolio

Scope a game jam entry, publish a browser build on itch.io, and present your work as a design portfolio.

Game Prototyping & Systems

About this course

Course content

The Game Loop in Code

Mechanics

Engines and Tools

Shipping a Game

Where this course leads

Careers that use it