Designer portfolio — Game Prototyping & Systems

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

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:

Header: title, one-line pitch, your role, team size, time frame, tools, a link to play.
The goal: what you were trying to achieve ("make a jump that feels responsive for new players").
Key decisions: two or three decisions, each with the reasoning and the alternatives you rejected.
Evidence: playtest notes, a chart of completion rates, before/after GIFs, a tuning table.
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.