"The best way to learn game development is to finish a game. Not a perfect game. A finished one."

---

Prerequisites

Module	What You Used From It
Any completed learning path	At least one full path gives you the technical vocabulary and patterns to build something original. You don't need all of them — depth in one area beats shallow coverage of many.

---

Week 1: Planning & Scoping

The Hard Part

You know how to build a game loop, handle input, detect collisions, manage state. You've implemented specific genres with specific mechanics. Now comes the hardest part of game development: deciding what to build and — more importantly — what not to build.

Every successful indie game started with a scope that was aggressively smaller than the developer's ambition. Undertale (Toby Fox, 2015) was one person working for nearly three years on what is essentially a turn-based RPG with a bullet-hell twist. Celeste (Matt Thorson & Noel Berry, 2018) started as a game jam entry — a 2D platformer with a single mechanic (the dash) that they polished relentlessly. Papers, Please (Lucas Pope, 2013) is a document-checking simulation. None of these games tried to do everything. They each did one thing extraordinarily well.

Choosing Your Project

Your capstone is a game you design and build from scratch. It can be a single genre or a blend of genres — Hades blends roguelike + action RPG + narrative, Baba Is You blends Sokoban + meta-puzzle, FTL blends roguelike + real-time strategy. The genre encyclopedia on this site covers dozens of possibilities.

Pick something you are genuinely excited to play, not just to build. If you wouldn't play a game like this, you'll lose motivation halfway through.

Core Concepts (Must Implement)

1. Scope Management

The single most important skill in game development is knowing what to cut. Every feature you add multiplies the complexity of your project — not additively, but combinatorially. Five features don't make a game five times harder to build; they make it ten or twenty times harder, because each feature interacts with every other feature.

project_scope = {
    "core_mechanic":     "The ONE thing the player does most",
    "win_condition":     "How the player knows they succeeded",
    "lose_condition":    "How the player knows they failed (if applicable)",
    "content_units":     "How many levels / rounds / scenarios",
    "art_style":         "Minimalist, pixel, geometric, text-based",
    "audio":             "None, SFX only, SFX + music",
    "menus":             "Title screen, pause, game over",
}

// If your core mechanic isn't fun in isolation, no amount
// of features will save the game. Test the core loop FIRST.

Why it matters: Professional studios with hundreds of employees still fail at scoping. As a solo developer or small team, your only advantage is agility — the ability to cut scope fast and ship something real.

2. The Iterative Loop

Build in layers, not in sequence. Don't build the menu system, then the game, then polish. Instead: build the ugliest possible version of the core loop, playtest it, improve it, repeat. Each pass adds a layer of quality.

iteration_0:  "Gray boxes moving on screen. Core mechanic works."
iteration_1:  "Basic art. Sound on key actions. One level/scenario."
iteration_2:  "Three levels/scenarios. Difficulty progression. Score."
iteration_3:  "Title screen. Game over. Restart. It's a complete game."
iteration_4:  "Polish. Juice. Screen shake. Particles. The feel."

// Each iteration produces a PLAYABLE game.
// You can stop at any point and have something finished.

Why it matters: If you build linearly (art first, then code, then levels, then polish), you won't know if the game is fun until it's too late to change course. Iterative development means you always have a playable game and you find problems early.

3. Playtesting

Watch someone play your game without saying a word. Don't explain the controls. Don't say "oh, that's a bug." Just watch. Where do they get confused? Where do they get bored? Where do they smile? Those observations are worth more than a hundred hours of solo development.

playtest_protocol = {
    "setup":     "Hand them the game. Say nothing.",
    "observe":   "Note where they hesitate, fail, or disengage.",
    "ask_after": "What was confusing? What was fun? What would you change?",
    "never":     "Never explain or defend your design during the test.",
    "fix":       "Prioritize fixes by frequency: if 3/5 testers hit the same wall, fix that first.",
}

Why it matters: You can't playtest your own game objectively. You know where every hidden path is, what every button does, how every enemy moves. Your testers don't. Their confusion is your design flaw.

---

Week 2: Build Your Game

What You're Building

An original, complete, playable game. "Complete" means: it has a start, gameplay, and an end state. "Original" means: you designed it, not followed a tutorial step-by-step. You may use any genre, any combination of genres, or invent something new.

The MVP Checklist

Element	Requirement
Core Mechanic	One clear, polished interaction the player performs repeatedly
Game Loop	The player can start, play, and reach an end state (win, lose, or score)
Content	At least 3 levels, rounds, or scenarios — enough to show progression
Feedback	The player always knows what happened and why (visual, audio, or both)
Restart	The player can restart or replay without refreshing the page
Polish	At least one "juice" element: screen shake, particles, easing, sound

Stretch Goals

• Genre blending: Combine two genres you studied into something new. Roguelike + rhythm game? Tower defense + deckbuilder?
• Persistent progression: Save high scores or unlocks to localStorage.
• Procedural content: Generate levels, enemies, or items so every playthrough feels different.
• Accessibility: Add key remapping, colorblind modes, or difficulty options.
• Postmortem write-up: Document what you planned vs. what you built vs. what you'd change.

Deliverable

A playable game hosted online (itch.io, GitHub Pages, or any web host) with a short write-up covering: what you built, what you learned, and what you'd do differently with another week.

---

Analogies by Background

For Backend Developers

Concept	Analogy
Scope Management	Like defining an API contract before writing implementation — decide the interface first, build the minimum behind it.
Iterative Development	Like deploying a service with feature flags — ship the skeleton, then enable functionality incrementally.
Playtesting	Like monitoring production logs after a deploy — real user behavior reveals bugs and UX issues your tests never caught.

For Frontend Developers

Concept	Analogy
Scope Management	Like choosing a component library wisely — each dependency adds bundle size and maintenance burden exponentially.
Iterative Development	Like progressive enhancement — make it work first (HTML), make it look right (CSS), make it interactive (JS).
Playtesting	Like usability testing — watching a real user struggle with your navigation is more valuable than any design review.

For Data / ML Engineers

Concept	Analogy
Scope Management	Like choosing which features to include in a model — more features means more overfitting risk, not necessarily better performance.
Iterative Development	Like training in epochs — each pass over the problem space improves the result, and you can stop when the loss plateaus.
Playtesting	Like A/B testing in production — the only way to know if your model works is to observe real users interacting with it.

---

Discussion Questions

1. The Scope Knife: You're two-thirds through development and realize one of your three core features isn't fun. Do you cut it, rework it, or ship it anyway? What factors inform that decision?
2. Originality vs. Familiarity: Players need to understand your game within seconds. How do you balance doing something new with leveraging genre conventions players already know?
3. When Is It Done? A game is never truly "finished" — you just stop working on it. How do you decide when a project is ready to ship?
4. The Postmortem: Professional studios write postmortems after every project. Why is reflecting on what went wrong (and right) more valuable than the project itself?