Chapter 40 — Exercises

These are the capstone exercises. They are longer, more open-ended, and more personal than the exercises in earlier chapters. The deliverables are real documents you will use — a post-mortem you publish publicly, a portfolio you use for job applications, a design philosophy essay you can reuse in cover letters, a playbook for your next game. Budget 15-25 hours across all five. Do them in the order given — each exercise produces an input for the next.

Exercise 40.1 — Write Your Post-Mortem

This is the main deliverable of the chapter. Write the post-mortem of your shipped action-adventure game. Target length is 1,500 to 3,000 words, written for public consumption — assume a stranger will read it and want to learn from your experience.

Use the six-section structure from the chapter.

Section 1: Project Overview (2-4 paragraphs). Name the team even if the team is one person. State the dates (concept start, shipping date, total elapsed months). Name the engine, the tools, the platforms, the price. Quantify the scope: number of levels, estimated playthrough length, number of enemy types, number of unique mechanics. Estimate the total hours you poured into the project — a real number, even if it is uncomfortable. State the budget: what you spent on assets, contractors, software licenses, domain names, promotional work. If the budget is zero, say so. The numbers calibrate everything that follows.

Section 2: Vision and Pillars (1-2 paragraphs). Open your concept document from Chapter 2. Read it again. Now describe, in two or three sentences, the experience you were aiming to create. List three or four design pillars — the words or phrases that anchored your decisions (for example: "tight combat," "atmospheric world," "accessibility-first," "tight runtime"). Then, honestly, compare: did the shipped game deliver on the vision? Where did it deviate? Where was the deviation good, where was it bad, and where did you only realize the deviation had happened in retrospect?

Section 3: What Went Right (3-5 items). For each item, write a header that names the specific thing, a paragraph that describes what happened, and a sentence or two about why it worked in terms another designer could apply. Examples of what "specific" looks like:

• "Cutting multiplayer at week 12 saved the project" — yes.
• "The team was great" — no.
• "The assist mode we added in Chapter 11 turned out to be the feature most-praised by reviewers" — yes.
• "Design decisions were good" — no.
• "Switching from Unity to Godot in month two saved us six weeks of tooling pain" — yes.
• "We chose the right tools" — no.

Be specific. Specificity is the currency of useful post-mortems.

Section 4: What Went Wrong (3-5 items). Same structure. Own the mistakes. Name them specifically. Do not inventory every small issue — inventory the issues whose mechanism was structural enough that another designer could learn from hearing about them. If an external factor genuinely contributed (a contractor delay, a tool bug, a platform policy change), name it, but name your own contribution first. The stance is clinical: here is what happened, here is why, here is what we now understand. Do not catastrophize. Do not minimize.

Section 5: What We'd Do Differently (1-2 paragraphs). Summarize, forward-looking. What process changes would you adopt? What tools would you try? What scope rules would you enforce? If you started the same project over tomorrow, what would you build first, what would you cut, what would you leave for a sequel? The goal of this section is not self-criticism; it is to distill the lessons into actionable rules for the next project.

Section 6: What the Experience Taught You (1-3 paragraphs). The personal reflection. What changed about your understanding of design, of craft, of yourself? What did you learn about how you work under pressure, how you handle feedback, how you persist? What would you tell the version of yourself who pressed "New Project" in Godot twelve or eighteen or twenty-four months ago?

Publishing. Publish the post-mortem publicly. Use your itch.io page's devlog, or a blog post on your portfolio site, or a Medium/Substack/LinkedIn article. The point is that the document exists in public. Commit to a publication date within 30 days of shipping — pick the date now, write it down, and honor it. A rough post-mortem published on deadline is worth 100x a polished post-mortem that lives forever in your drafts folder.

Submit: The published URL plus a note about what surprised you in writing it.

Why this exercise matters. The post-mortem is the single most important document you will produce in the shipping phase. It consolidates the learning. It becomes a portfolio piece. It contributes to the community's shared knowledge. Most designers who ship do not write post-mortems, which is why the ones who do have an outsized impact on the next generation. Be one of the ones who do.

Exercise 40.2 — Assemble Your Portfolio

Build the portfolio site this week. Not this month. Not when you "have time." This week.

The concrete checklist is below. Work through it in order. At the end, you should have a public URL that a hiring manager could find via Google, could navigate in under two minutes, and could use to evaluate whether you are a designer they should interview.

Domain and hosting. Pick a domain. Use yourname.com if it is available, or yourname.design, or yourname.games. Budget $12-$18 for the year. Services like Namecheap, Porkbun, or Cloudflare Registrar are fine. Point the domain at a hosting platform — Notion with a custom domain, Squarespace, Carrd ($19/year for a simple personal site), Wix, or GitHub Pages with a static-site generator like Hugo if you want to hand-code.

Home page. One screen of content above the fold. The game's name, the genre tagline, a hero image or trailer embed, a visible "Play on itch.io" button (or Steam button). Two sentences that describe what the game is. A link or section for "About Me" below. Do not clutter. Do not add parallax scroll or animated backgrounds. Load time under two seconds.

About page. Two or three paragraphs. Who you are, where you are, what you do, what you are looking for. A professional-looking photo (not a selfie — a photo where you are clearly visible, decently lit, dressed appropriately for the industry context). A short list of the three or four things you care about in design. A contact email.

Work page. Your shipped game front and center. Screenshots (six to twelve, curated). Trailer. Playable build (the itch.io embed is fine). Links to store pages. A brief description — two or three paragraphs about what the game is, who it is for, what the core design challenge was. Below the game, list the design artifacts: concept document, post-mortem, scope list, selected chapter exercises. Link each to a PDF or publicly-shared Google Doc.

Secondary projects (optional). If you have other work worth showing — a student game, a completed game jam entry, a mod that is genuinely polished — include it here, but gate it below the main project. The reviewer should have no doubt which project is your headline.

Contact page. Email. LinkedIn. Twitter or Bluesky. Optionally Discord. That is all. Do not include a contact form that might fail silently. A mailto link with your actual email address is fine.

Cross-linking. Link your itch.io devlog to the portfolio site. Link your Twitter bio to the portfolio site. Link your LinkedIn profile to the portfolio site. Update your Github profile README to link to the portfolio site. The portfolio site is the hub; everything else spokes back to it.

Final review. Ask one person who is not in games to open the site on their phone, spend sixty seconds on it, and then tell you — without looking again — what the site is about, what you do, and what your one project is. If they can answer all three, the site works. If they cannot, fix the top of the home page until they can.

Submit: The portfolio URL plus a one-paragraph description of the decisions you made about what to include and what to cut. The cuts are often the most interesting decisions.

Exercise 40.3 — Write Your Design Philosophy

This is a 500-word personal essay titled "What I Believe About Game Design." Write it for yourself first, then edit it for public reading.

The genre of the design-philosophy essay is specific and unusual. It is not a list of design rules you learned from a book. It is not a manifesto. It is a set of beliefs — genuine, idiosyncratic, specific — about how games work and what they are for. Every designer you respect has an implicit design philosophy, and the good ones can articulate theirs in a few paragraphs.

The essay should contain roughly five components, though the order and proportion are up to you.

Your definition of a good game. One or two sentences. Your own definition — not Sid Meier's "series of interesting decisions," not Raph Koster's "fun is learning," not some received answer from a textbook. What do you mean when you say a game is good?

The kind of games you most want to make. Not your favorite games to play — your favorite games to make. These can be the same games, but often they are not. A designer who loves playing Civilization might be a designer whose heart is in small, melancholy adventure games. Notice the gap. Name what you want to make, specifically.

The design principles you have found most useful. Two or three. Not generic ones ("playtest often"). Specific to your practice. "I find that my mechanics get better when I prototype them in paper first, even when paper cannot actually simulate the physics." "I consistently under-scope my art budget and over-scope my system complexity, so I try to cut systems before cutting art." Principles that came from your actual shipped project.

What you reject. What design trends, techniques, or philosophies do you not believe in? Not the ones it is fashionable to attack. The ones you genuinely disagree with. Maybe you think skill trees are usually a crutch. Maybe you believe narrative-driven RPGs have been doing the wrong thing since Knights of the Old Republic. Maybe you think roguelike meta-progression undermines the form. Pick something you actually dissent from, and name it.

What you hope to learn next. One or two sentences. What specific craft skill are you trying to improve in the next year of your work? What are you weakest at? What would you want a mentor to teach you?

Write the essay. Let it sit for a week. Edit it. Cut it to exactly 500 words — the tightness is part of the exercise. Post it on your portfolio site under an "Essays" or "Writing" section.

Submit: The 500-word essay plus a short reflection on what writing it was like. Which of the five components was hardest to articulate? That is probably the one where your design beliefs are still forming — worth revisiting in a year.

Exercise 40.4 — Playbook for the Next Game

This is a forward-looking document. It is the playbook for the next game you will make, informed by everything the first one taught you.

Format: a one-page document (500-800 words). The structure below. Write it within two weeks of shipping, while the lessons are fresh.

The next project's elevator pitch. One or two sentences. The high-concept description of what you want to make next. If you do not know yet, write the three candidate pitches you are deciding between.

Scope ceiling. How big is this next game allowed to be? Name specific limits. "Under 90 minutes of playthrough." "Under 30 unique assets." "Solo dev only for the first six months." "Budget of $500 for contracted work." If scope creep is how first-time designers fail their second project, the scope ceiling is the primary defense.

What I am bringing from the first project. Name three to five specific things from the first project that you are keeping. Code modules you wrote (the dialogue system? the save manager? the screen-shake juice module?). Design patterns you now trust. Art-pipeline workflows. A list of playtesters whose feedback proved reliable. A tool configuration that took weeks to dial in the first time. Reusing these assets is how the second game ships in half the calendar time of the first.

What I am changing. Name three to five specific things you are going to do differently based on the first project's lessons. Process changes (different pacing of milestones?). Tool changes (different audio middleware?). Design process changes (more paper prototyping up front? more playtesting earlier?). Scope changes (fewer enemy types, more variation?). Reference your post-mortem's "what we'd do differently" section directly — the playbook operationalizes those lessons.

The first milestone. What will "Week One Done" look like on the next project? Be specific. "Character controller implemented, one test level built, build running on itch.io's draft-public setting." A concrete first-week goal keeps early-stage momentum honest. Designers who cannot define Week One's deliverable often never leave pre-production.

The shipping plan. When, approximately, will the next game ship? A range is fine ("6-9 months from start"). Name the platform. Name the price. Name the target number of sales or downloads in the first month post-launch — your intention, not a prediction. A target you believe in is more useful than a forecast you do not.

Known risks. Three to five things you already know will be hard. "Audio is my weakest area — I need to budget for a contract composer from the start." "I have never shipped a game with a procedurally generated system — prototype the generator in the first month or cut the feature." Known risks, named at the start, are risks you have a plan for. Unnamed risks are the ones that eat your schedule.

Submit: The one-page playbook. Revisit it at every milestone of the next project and mark which of the predictions proved right and which did not. The gap between what you predicted and what happened is, itself, the next layer of learning.

Exercise 40.5 — Community Contribution

Give back. Pick one of the three options below and complete it within 90 days of shipping.

Option A: Write a craft blog post. Pick one specific lesson you learned during development — not a big general lesson, a small specific one. Write a 1,000-1,500 word blog post teaching that lesson. Include screenshots, code snippets, or diagrams where they clarify. Publish on your portfolio site or a community-facing blog. Examples of the level of specificity: "How I built a grid-based dialogue system in 200 lines of GDScript." "The three playtest findings that completely changed my boss-fight design." "Why I rewrote the save system three times and what the third version got right."

Option B: Write a GDC talk outline. Even if you will never give the talk. Pick a topic you have genuine expertise in from your shipped project. Write the GDC talk you would give — full 40-minute talk, structured as an introduction, four to six main sections, and a conclusion. Each section should have a title, a one-paragraph summary, and two or three key slides described. Publish the outline on your portfolio site. Many designers' first GDC talk started as an outline written before they ever pitched it. The outline exists to be pitched next year.

Option C: Record a tutorial. Video, podcast, or written — pick the format. Teach one specific technique from your shipped project. Keep it under 20 minutes for video or 3,000 words for written. Publish on YouTube, on your blog, on a community site, or all three. Examples: "Screen-shake in Godot — the 15-line solution from MyGame." "How to prototype a metroidvania backtracking gate in 30 minutes." "Accessibility settings — what I added, what I skipped, what I learned."

Whichever you pick, the deliverable is the same: a piece of craft content, publicly available, that teaches one specific thing you learned. The community that taught you — the Mark Browns and Matt Thorsons and Masahiro Sakurais and thousands of anonymous forum posters — built your designer-self by putting their craft into the world. You are now in a position to add to that library.

Submit: The published URL plus a one-paragraph note on why you picked the topic you picked, and what you learned from teaching it.

Why this exercise matters. The craft community is a gift economy. Designers give their knowledge away because earlier designers gave theirs. The chain continues or it breaks. You are now a link. Make a small contribution and pass it forward.

Closing Note on the Capstone Exercises

Do not try to do all five exercises in one week. They are a three-month arc.

Week 1-2: Exercise 40.1 (post-mortem). Write while the memories are fresh.

Week 2-3: Exercise 40.2 (portfolio). Use the post-mortem as a centerpiece.

Week 3-4: Exercise 40.3 (design philosophy). With the post-mortem in front of you, the beliefs are clearer.

Week 4-8: Exercise 40.4 (playbook). Let the playbook marinate as you rest and consider next projects.

Week 8-12: Exercise 40.5 (community contribution). When you are ready to talk about the project rather than grieve it, teach.

The arc from shipping to contributing is roughly three months. Trust the arc. Do not skip the rest. Do not rush the reflection. The capstone is not a sprint — it is the beginning of a career's worth of practice.

Go make the next one.