The whole course converges here: go and ship. Not the "perfect architecture" but a vertical slice under hard scope, risk-first ordering and the discipline of saying no. Your capstone is Novgorod 1207; below is how to get it to release without drowning.
~16 min🚢 delivery → shipping
The gist in 30 seconds
A capstone is about delivery, not perfection. The method: prototype the core loop in any form → a vertical slice (one level/scene at 80%, every system present) → content/progression → juice and polish (the 80%→95% jump) → marketing → release + postmortem. Scope is hard: with time fixed, quality per feature is — cut the number of features to raise . The order is risk-first: do the thing that can kill the project first (an unproven mechanic, the AI asset pipeline) while you still have room to turn around. Remember the power law of polish: the last 10% takes 90% of the time. Five capstone tracks (a game / an engine subsystem / a design breakdown / an ML experiment / an LLM NPC demo) — pick 1–3. Claude is a companion for review/explanation/debugging, but not a substitute for writing your own code or for the art and narrative. The deliverable always includes a postmortem.
The mechanism: vertical slice, risk-first, scope
The capstone arc (by week)
The key idea is the vertical slice: don't build all the rendering first and then all the gameplay (horizontally), build one level/scene where every system is present at least minimally and which is playable start to finish. That way you see emergent dynamics early (they can't be derived on paper) and you know the game works at all, rather than "it'll come together at the end".
Scope: cut features, not quality
With a fixed time budget, quality per feature is inversely proportional to the number of features:
Ten raw mechanics are worse than one polished one. "The best games say no to most features": define the core loop and judge every idea by "does it serve the loop?". Tetris has 5 pieces. And keep a reserve for the power law of polish: the last 10% (juice, sound, feedback, bug fixing) takes ~90% of the time — that's the planning fallacy, budget for it.
Risk-first ordering
Do first whatever can kill the project, while there's still time to turn around: an unvalidated core mechanic, an unfamiliar technology, a bottleneck. For Novgorod the main risk isn't rendering (Godot 4.6 handles it) but the AI asset pipeline (no artist/designer on the team → you're covering it with Meshy and generative tools): it has to be validated by the first vertical slice — "one hut + one NPC + one mechanic, entirely through the AI pipeline" — before you scale. If the pipeline doesn't deliver the quality/speed you need, you want to know that in week 2, not in month 6.
Claude as a companion (and where it isn't)
✓ What for
Reviewing scene architecture; a step-by-step explanation of an algorithm on your case; working through a trade-off (ECS vs OOP for your shooter); code review "as a senior game dev"; simulating a playtest ("what would a casual player do? a Souls veteran?"); intuition for the math; context for debugging; reviewing marketing copy and a draft postmortem ("what blind spots am I showing?").
✗ What NOT for
Replacing writing your own code/design — the friction is where the learning happens. Generating the final narrative/art/audio — that's the value of the project, do it yourself. Skipping the play-and-analyze cycle — Claude can describe Hades, but you have to be the one who plays Hades.
And keep a "second brain": a notebook of "what I asked Claude and what I understood" — that's how patterns accumulate (next lesson).
🎮 Five tracks — and their precedents
A · A whole game 4–6 weeks
One mechanic, shipped with polish on itch.io/Steam: core loop + juice + progression + analytics + a store page + a trailer + a postmortem. The precedents are Flappy Bird, Crossy Road, Balatro (solo/small team, narrow scope).
🚢 For Novgorod: this is your track, but phase 1 = a vertical slice for the grant (a proof of concept out of Canada), not the whole game. One region, one loop, the AI pipeline proven — enough to show an investor/grant body that it's viable.
B–D · Subsystem / breakdown / ML 2–4 weeks
B: implement a subsystem from M08 (2D physics, a software renderer, rollback netcode, a BT runtime, a PCG generator) + a tech blog post. C: a design breakdown of a game (essay + diagrams). D: an ML/AI experiment (RL/supervised) + a report with learning curves.
🚢 Notice: B/D are your home turf (an ML engineer). A PCG generator (B5) or an ML experiment (D) can be done inside Novgorod as a separately publishable artifact — double value: a portfolio piece and a piece of the game.
E · An LLM NPC demo 4–6 weeks
Persona + memory + function calling (the LLM emits JSON actions, the state changes) + optional TTS, with measurements of latency/cost/character consistency and a postmortem. Straight out of the LLM NPC lesson.
🚢 For Novgorod: historical NPCs on a local LLM are a strong differentiator and a hook for a grant. But per the ML lesson: first prove that NPC control runs on the classics (a BT) and the LLM is only for dialogue, with a latency budget and guardrails.
Deep end · the time budget and the vertical slice as de-riskingskippable
The weekly time budget (track A)
~50–80 hours, 10–15 h/week: week 1 prototype (the core loop moves in some form); week 2 the vertical slice (one scene at 80%, every system minimally); week 3 content+progression (the difficulty curve is in place); week 4 juice+polish (animation/sound/particles/hit-stop — the 80→95% jump); week 5 marketing (page/trailer/screenshots); week 6 release+postmortem. Every week produces a showable artifact. If a week didn't produce a playable increment, the scope is too big — cut.
The vertical slice = validating the unknown early
Horizontal development ("all the rendering first, then all the gameplay") hides the risk at the end: whether the game comes together is something you learn when there's no time left. A vertical slice moves the uncertainty to the front: you build a thin end-to-end strip through every system, and (a) you see emergent dynamics early, (b) you validate the scariest risk (for Novgorod, the AI assets), (c) you have a showable build in week 2 (grant/investor/feedback). It's the same principle as "prototype before architecture": build for real needs, not imagined ones.
Analogy
A capstone is like cooking one perfect set menu rather than opening a restaurant with 200 items. The vertical slice is serving one complete meal from starter to dessert (every "system" in the kitchen is exercised), instead of prepping a mountain of half-finished components for every dish that will "come together later". Scope is removing everything from the menu except what you do superbly. Risk-first is testing the hardest sauce on day one, not on opening night. And the postmortem is the debrief after service: what worked, what burned, and what was just luck.
Why it matters
Knowing everything in the course and shipping nothing is a common failure. The capstone turns knowledge into delivery skill: scope, the vertical slice, risk-first ordering, the discipline of no, and a release with reflection. For you it's literally the roadmap for Novgorod (phase 1 = a grant vertical slice out of Canada), and as a frame it's a way to take any project from idea to release without drowning in the "perfect architecture".
🔁 Beyond games — where this transfers
The lesson is about delivering a project under uncertainty: a slice instead of layers, risk at the front, hard scope.
ML / AI (your domain): the vertical slice ⇄ an end-to-end baseline first: assemble a thin end-to-end pipeline (data→model→metric→demo) before perfecting any single piece — that way you see early whether the problem works at all, and you measure the real bottleneck rather than the imagined one. Risk-first ⇄ de-risking: attack the biggest unknown (the data? the metric? is the accuracy even achievable?) in week 1, not after months of infrastructure. Scope ⇄ cut the number of experiments/features and go deeper on a few; the power law of polish ⇄ the last few percent of the metric/production readiness eats almost all the time. "Claude for friction, not instead of it" ⇄ AI assistance speeds up review/debugging, but the learning and the ownership come from what you do yourself. And "ship, then postmortem" ⇄ ship-and-learn iteration instead of endless polishing before release.
Startup/product: the MVP = a vertical slice; de-risk first; "sell it before you build it"; release as a source of learning, not as the finish line.
Principle: build a thin end-to-end strip early, attack the risk first, cut scope down to what you do excellently, ship and reflect.
🔧 Plan your capstone
🚢 A vertical-slice plan for Novgorod ~30 min
Define the phase-1 slice for the grant: one region + one core loop + one NPC, all of it through the AI asset pipeline. Lay out 6 weeks along the arc (prototype→slice→content→juice→marketing→release). Mark the main risk (AI assets) and how you validate it in week 2. Decide which 2–3 tracks (A + B/D/E) give you both the game and portfolio artifacts.
✂ The scope knife ~15 min
Write out every feature you want. For each, ask "does it serve the core loop?". Cross out everything that doesn't. Sort what's left by risk (scariest first). Estimate : if is large, cut more.
Checklist: laid out the 6-week arc for the Novgorod slice; named the main risk and the plan to validate it in week 2; ran the features through the scope knife; picked 2–3 tracks with double value; budgeted for the power law of polish.
Connections
foundation
Indie production — scope, the planning fallacy, the vertical slice at the project level.
foundation
Studio economics — burn/runway and "survive the failure": a capstone lives inside the same frame.
next
Pattern synthesis — what exactly you took from the course and will carry into the project.
next
Postmortem — the mandatory deliverable: the debrief after release.
Questions worth asking
Why a vertical slice instead of "engine first, game second"?
Because horizontal development hides the main risk at the end. If you build all the rendering, then all the gameplay, then all the audio, you only learn whether the game comes together and whether it's fun (emergent dynamics you can't derive on paper) when everything is done and there's no time to change course. A vertical slice — a thin end-to-end strip through every system in one scene — moves the uncertainty to the front: in week 2 you have a playable chunk, you see whether the idea works, you measure real bottlenecks and you validate the scariest risk. For Novgorod that's critical: the main risk is the AI asset pipeline (no artist), and it has to be tested with a single slice ("hut+NPC+mechanic through AI") before scaling to the whole game. Plus the slice is a showable build for a grant/investor/feedback right at the start. It's the same principle as "prototype before architecture": build for real needs, not imagined ones.
How do you tell that the scope is still too big?
Three signals. (1) A week with no playable increment — if a week of the arc has passed and there's nothing to show (everything is "in progress"), the scope is too big: cut. (2) Many raw features instead of a few polished ones — remember : with time fixed, every extra feature takes quality away from the rest; ten mediocre mechanics are worse than one excellent one. (3) No reserve for the last 10% — if the plan doesn't leave roughly half the time for juice/polish/bugs (the power law of polish), the release will be raw. The test for every feature: "does it serve the core loop?" — if not, or if it's "just would be cool", cross it out. The discipline of no is the most underrated skill: Tetris (5 pieces) and Dark Souls (no difficulty settings) are strong precisely because of what isn't in them. For a grant capstone it matters even more: the goal is to prove viability with one polished slice, not to show a raw "whole game".
How do you use Claude without killing the learning?
The rule: Claude is for accelerating understanding and review, not for replacing doing. Friction is where learning happens, so write your own code, design and final art/narrative yourself: if Claude generates your gameplay code, you don't grow as a developer, and if it generates the narrative/art, the value of your project disappears. But Claude works well as: a senior on code review ("tear this Godot script apart"), an explainer of an algorithm on your concrete case (not abstractly), a sparring partner on trade-offs ("argue both ECS and OOP for my situation"), a playtest simulator ("how does a casual player get through this, how does a veteran?"), context for debugging ("here's the bug, here's what I tried, where do I look?") and a critic of a draft postmortem ("what blind spots?"). And keep an "asked → understood" journal: it accumulates patterns and protects you from the illusion of understanding that comes from reading an answer. A practical test: if after a session with Claude you can explain/reproduce the solution yourself, you used it right; if you only copied it, you replaced the learning.