Analyse why games work, build and playtest paper prototypes, balance systems and levels, and communicate a design with a one-page GDD and a pitch.

Game Design Fundamentals

Write the title, a one-sentence high concept and the target platform and audience at the top.

List the design pillars: two or three short phrases describing the experience every decision must support.

Draw or describe the core loop in one line of verbs with arrows.

List the main mechanics with one line each, and the controls or inputs if it is a digital game.

Describe the scope: number of levels or areas, play time, and what is explicitly out of scope.

Add a small sketch or diagram (a map, a screen layout or the loop) taking no more than a quarter of the page.

List the top three risks or open questions you would test first.

Give the page to someone and ask them to explain your game back to you. Fix anything they got wrong.

## Why it matters

Once more than one person works on a game, the design has to live somewhere other than the designer's head. A **game design document (GDD)** is that shared reference: what the game is, what it is not, and how its pieces fit. Programmers, artists, producers and testers all use it to make decisions without asking the designer every five minutes.

## From bible to one page

Older studios wrote huge GDDs, sometimes hundreds of pages. They were slow to write, rarely read and quickly out of date. Many teams now prefer:

- A **one-page design** or one-sheet for the whole game, popularised in talks by designer Stone Librande.
- **Short living docs** per feature (a page on the inventory, a page on combat), kept in a wiki and updated as the game changes.
- **Diagrams over paragraphs**: maps, flowcharts and annotated mock-ups.

The one-page constraint forces clarity. If you cannot fit the core of your game on a page, you probably do not know what it is yet.

## What goes on a one-page GDD

| Section | Purpose | Example |
|---|---|---|
| **Title + high concept** | the game in one sentence | "A cosy puzzle game where you fold paper maps to connect villages." |
| **Platform and audience** | who and where | mobile and PC, ages 10+, casual puzzle players |
| **Design pillars** | 2-3 experience goals every feature must serve | "tactile folding", "calm discovery", "no fail states" |
| **Core loop** | the repeated cycle | study map -> fold -> connect -> unlock village -> new map |
| **Mechanics** | the main rules, one line each | folds snap to creases; each village needs one path |
| **Controls** | inputs for digital games | drag to fold, tap to undo |
| **Scope** | size and limits | 40 puzzles, 3 hours, no multiplayer |
| **Visual** | a map, loop diagram or screen mock | a small sketch |
| **Risks** | what to test first | "Is folding readable on small screens?" |

## Design pillars: the decision filter

**Pillars** are the most useful part of a GDD for day-to-day decisions. When someone proposes a feature, the team asks: "Does this support our pillars?" If the pillars are "calm discovery" and "no fail states", a countdown timer is an easy no, however cool it looks.

Good pillars are short, specific and different from each other. "Fun" and "good graphics" are not pillars; "every fold should feel physical" is.

## Worked example: scoping down

First draft of scope for the folding game: "100 puzzles, story mode, level editor, online sharing, 5 art styles."

For a first release by a small team, that is far too much. Revised scope:

- **In:** 40 puzzles in 4 themed sets, undo, hint system.
- **Out (for now):** level editor, online sharing, extra art styles.

Writing an explicit **out of scope** list is just as important as the in list: it stops scope creep and records decisions so they are not re-argued every week.

## Keeping it alive

A GDD is only useful if it matches the game. Practical habits:

- Date the document and note what changed.
- Link from the one-pager to feature docs rather than growing it.
- Review it after each playtest round: does it still describe the game?
- Make it easy to find (a pinned wiki page, a shared folder).

## Common mistakes

- **Writing a novel.** Long lore and backstory belong in a separate narrative doc.
- **Vague pillars.** "Fun", "epic" and "polished" do not help anyone decide anything.
- **No out-of-scope list.** Every idea stays "maybe" forever.
- **Writing it once and never updating it.** An outdated GDD is worse than none, because people trust it.
- **Text where a diagram would do.** A loop or map sketch is faster to read than three paragraphs.

## Quick recap

- A GDD is the team's shared reference for what the game is and is not.
- Modern teams favour a one-page overview plus short feature docs.
- Include high concept, audience, pillars, core loop, mechanics, scope (in and out), a visual and risks.
- Pillars are a decision filter; keep the document current.

## Try it

Open the Do tab and write a one-page GDD for your game.


Write a one-page game design document that a small team could build from.

Game design documents

How to write a Game Design Document

One-Page Designs

## Why it matters

"Game designer" is one of the most wanted job titles in games and one of the hardest to get as a first job. Understanding how studios are organised, what each role does and how people actually get hired helps you plan a realistic route and build the right portfolio, instead of waiting for a dream job posting.

## Who makes a game

Team size ranges from one person to more than a thousand, but the same disciplines appear everywhere:

| Discipline | What they do | Example titles |
|---|---|---|
| **Design** | rules, systems, levels, balance, narrative, user experience | game designer, systems designer, level designer, narrative designer, UX designer |
| **Programming** | engine, gameplay, tools, networking, AI | gameplay programmer, tools engineer, engine programmer |
| **Art** | concept, characters, environments, animation, VFX, UI art | concept artist, 3D artist, animator, technical artist |
| **Audio** | music, sound effects, voice | sound designer, composer |
| **Production** | schedules, scope, coordination | producer, project manager |
| **QA** | finding and reporting bugs, test plans | QA tester, QA analyst |
| **Other** | community, marketing, user research, live operations, data analysis | community manager, user researcher, live-ops designer |

Design itself has specialisms. In a large studio you might be a **combat designer** or **economy designer**; in a small studio one designer covers everything.

## Studio types

- **AAA studios:** large budgets and teams, specialised roles, long projects (often several years).
- **Indie studios:** small teams (1-30), broad roles, many shipped smaller games, more risk.
- **Mobile and live-service:** ongoing updates, data-driven design, monetisation and economy roles.
- **Work-for-hire and outsourcing:** build parts of other companies' games (art, ports, QA).
- **Serious and educational games:** games for training, health or schools; overlaps with instructional design.

## What a junior designer actually does

Early-career design work is less "invent the game" and more:

- implementing content in an editor or scripting language (placing enemies, wiring quests)
- tuning values in spreadsheets
- writing specs for a feature someone else designed at a high level
- running and analysing playtests
- fixing design bugs reported by QA

Being reliable at these tasks is how designers earn ownership of bigger features.

## Entry routes

There is no licence for game design. Studios hire on evidence that you can design and ship. Common routes:

1. **Portfolio of small finished games.** Jam games (48-72 hour game jams such as Global Game Jam or itch.io jams), mods and small releases on itch.io show you can finish things. Two or three polished small games beat one unfinished epic.
2. **Degrees.** Game design, computer science, or related programmes give structure, team projects and industry contacts. Many designers have one; it is common but not strictly required.
3. **Adjacent roles.** QA, community, level scripting or programming roles are frequent stepping stones into design.
4. **Modding and level creation** in games with editors.
5. **Indie or self-published projects**, sometimes with a small team.

A strong design portfolio shows **your process**, not just screenshots: the problem, prototypes, playtest findings, what you changed and why, and the result.

## Realities to plan for

- Competition for design roles is high; the industry has had waves of layoffs, so many experienced people are also job hunting.
- Crunch (long overtime) still happens at some studios; ask about it in interviews and look for reviews.
- Many designers build skills in scripting (for example C# in Unity, Blueprints in Unreal, GDScript in Godot) because technical designers are in demand.
- Networking matters: jams, local meetups, Discord communities and conferences lead to many jobs.

## Common mistakes

- **Only applying for "game designer" titles.** Look at QA, level scripter, technical designer and indie roles too.
- **A portfolio of ideas instead of games.** Studios want playable evidence.
- **Unfinished projects.** Finishing is a skill; show it.
- **Ignoring other disciplines.** Designers who can talk to programmers and artists in their terms are easier to hire.

## Quick recap

- Games are made by design, programming, art, audio, production, QA and support roles.
- Studios range from AAA to indie, mobile, outsourcing and serious games.
- Junior designers implement, tune, document and test before owning big features.
- Entry is through a portfolio of small finished games, often with a degree or an adjacent role.


Map the main studio roles, how teams are structured, and realistic entry routes into game design.

The games industry

How to Get a Job as a Game Designer

Write a hook: one sentence that makes the game sound different, for example 'X meets Y, but Z'.

Write who it is for and why they will want it (the audience and the feeling it gives them).

Describe the core loop in one or two sentences using verbs.

Add a reason to believe: your prototype, a playtest finding, or a GIF or sketch that shows the game.

State the scope and the ask: team size, time, platform, and what you want from the listener (feedback, a teammate, funding).

Rehearse with a timer until the pitch fits in two minutes without rushing.

Deliver it and ask the listener to repeat the game back in one sentence. Note what they remembered and what they missed.

## Why it matters

Designers pitch all the time: to teammates in a meeting, to a lead when proposing a feature, to a publisher or funding body, to a game jam team at 9 pm on Friday. A clear pitch gets an idea a fair hearing; a rambling one gets it forgotten, however good the idea. Pitching is also a test of your design: if you cannot explain the game in two minutes, it may not be clear yet.

## The core idea: what the listener needs

Every listener is silently asking four questions:

1. **What is it?** (the hook and genre)
2. **Who is it for?** (audience and platform)
3. **Why will it work?** (core loop, unique angle, evidence)
4. **What do you need from me?** (the ask)

A good short pitch answers all four, in roughly that order.

## A two-minute structure

| Time | Part | Example (folding puzzle game) |
|---|---|---|
| 0:00-0:15 | **Hook** | "Fold Lands is a calm puzzle game where you fold paper maps to bring villages together." |
| 0:15-0:35 | **Audience and feeling** | "It's for players who love relaxing puzzle games and the feel of craft; every fold should feel physical." |
| 0:35-1:05 | **Core loop** | "You study a map, fold it along creases to line up roads, connect every village and unlock the next region." |
| 1:05-1:30 | **Reason to believe** | "Our paper prototype tested with eight players; all finished the first set and asked for more. Here's a 10-second clip." |
| 1:30-1:50 | **Scope** | "Two people, nine months, PC and Switch, 40 puzzles." |
| 1:50-2:00 | **Ask** | "We're looking for an artist to join the team." |

## Hooks and comparisons

A common hook format is **"X meets Y"** or **"X, but Y"**: "a farming game, but your farm is on a whale's back". Comparisons are useful because they borrow the listener's knowledge, but they also set expectations, so pick comparisons that are honest and widely known. Then add what makes yours **different**; a pitch that is only "like X" invites the question "why not just play X?".

## Show, do not just tell

Evidence persuades more than adjectives:

- a short gameplay clip or animated GIF
- a photo of the paper prototype in use
- one playtest result ("seven of eight players replayed the first level")
- a single striking piece of concept art

Avoid claims you cannot support, such as "it will be the next big hit".

## Pitching to different audiences

- **Teammates:** focus on the experience and what each discipline will get to build.
- **Leads or producers:** focus on scope, risks and how it supports the project's pillars.
- **Publishers or funds:** add market, budget, timeline, team track record and a playable build. Many publishers list what they want in a pitch deck on their websites; follow their format.

## Handling questions

Questions are good: they mean someone is engaged. Listen fully, answer briefly, and if you do not know, say so and say how you would find out ("We haven't tested that yet; it's our next playtest goal"). Do not argue with feedback in the room. Write it down.

## Common mistakes

- **Starting with lore.** "In the year 3045, the kingdom of..." loses listeners before they know what they do in the game.
- **Feature lists.** Ten features in a row are hard to remember. One hook and one loop are not.
- **No ask.** Listeners do not know what you want from them.
- **Running over time.** Respect the limit; it shows you can scope.
- **Reading slides word for word.** Rehearse until you can speak naturally.

## Quick recap

- Answer four questions: what is it, who is it for, why will it work, what do you need.
- Use a two-minute structure: hook, audience, loop, evidence, scope, ask.
- Show evidence (clips, prototype photos, playtest results) instead of hype.
- Adapt to the audience, welcome questions and stay within time.

## Try it

Open the Do tab, prepare a two-minute pitch and deliver it to someone.


Pitch a game concept clearly in two minutes, with a hook, a core loop and a reason to believe.

Pitching a game

How To Pitch Your Indie Game

Game Pitches

Write a one-page game design document, map studio roles and entry routes, and pitch a concept in two minutes.