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

Game Prototyping & Systems

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.