Chapter 40: Your Game Is Done — Ship It, Show It, Reflect on It

You finished a game.

Very few people ever do. That sentence is the most important sentence in this book, and if you read nothing else in this chapter, read that one and let it land. Most people who set out to make a game do not finish one. They quit at the prototype stage. They quit during the middle chapters of development, when the novelty of the idea has worn off and the grind of actually making the thing has set in. They quit at polish, because polish is the longest, least glamorous phase. They quit at playtesting, because playtesting is humiliating and humbling and most people cannot take it. They quit at launch, because shipping is terrifying.

You did not quit.

Whatever else is true about your game — whatever its flaws, whatever its scope, whatever its commercial fate — you crossed a finish line that the overwhelming majority of aspiring designers never cross. That fact, alone, changes your identity. You are now a person who ships. That is a small club. Welcome to it.

The rest of this chapter is about what comes next. How you actually ship (the mechanics of the final day). How you write a post-mortem that is honest without being self-flagellating. How you compile a portfolio that demonstrates craft rather than performs passion. How you think about careers and communities and the long arc that this first game begins. And — because this is the last chapter of a forty-chapter book — how you look back at everything you just learned and notice who you have become.

Let's ship it.

The End Is the Beginning

Before we get mechanical, sit with the feeling for a moment.

If you are reading this chapter because you finished the progressive project from Chapter 1 — the 2D action-adventure you have been building across thirty-nine chapters — you are in a specific psychological state right now. You have been living with this game for months, maybe years. You know every inch of it. You know the bugs you gave up on. You know the scenes that should have been cut. You know the levels you are secretly ashamed of and the levels you are secretly proud of. You are tired of it. You cannot imagine playing it for pleasure. The music loops are burned into your hippocampus. The first-level tileset haunts your dreams.

This is normal. This is what the end of a project feels like. The exhaustion is real. The disgust with your own work is real. The inability to evaluate the game on its own terms — because you have seen every seam — is real.

Push through. The ship is close. The post-release perspective is kinder than the pre-release perspective. The people who play your game will not see the seams. They will see a game. They will play it with the attention you are no longer capable of giving it. They will find things in it you did not know were there.

📜 Reflection: There is a particular exhaustion that attends the end of a creative project, different from the exhaustion of hard labor or long hours. It is the exhaustion of having given the thing everything you had. Sit with it. Do not confuse it with evidence that the game is bad. At the end of every meaningful creative project, the creator is convinced the work is worthless. This is the tax the work extracts for being real. Pay the tax. Ship anyway.

The shipping day itself is almost anticlimactic. Let's walk through it.

Shipping Day — The Mechanics

The shipping day is less mystical than you think. It is a checklist day.

Final QA pass. Run the game one more time, start to finish, on a machine that is not yours. Someone else's laptop, a friend's Steam Deck, a cloud build system — anywhere that the game has not already been launched a thousand times. Fresh machines expose the bugs your machine has been hiding. Missing fonts. Missing DLLs. Missing save directories. Permission prompts you never saw because you were running as admin. This pass is not the full QA pass Chapter 31 covered — that happened months ago — this is the belt-and-suspenders pass, a sanity check before the upload.

Version number. Pick a version number and stick to it. Semantic versioning (MAJOR.MINOR.PATCH) is the standard: your first shipped build is almost never 1.0.0. Most ship as 0.9.0 (late beta) or 1.0.0-rc1 (release candidate one) or, if you are honest about the state, 1.0.0 and plan for 1.0.1 patches within the week. The version number goes in your game's title screen, in your build's filename, in your storefront release notes, in your git tag. Future-you will be grateful when a player asks, "which version has bug X?" and you can answer.

Build signing. On Windows, unsigned executables will trigger the SmartScreen warning — the dreaded "Windows protected your PC" dialog that makes new players think your game is malware. Proper code signing requires an EV certificate from DigiCert or Sectigo, which costs $200-$400 per year and requires business verification. Many small indies skip this for the first release and accept the friction. If you plan to distribute widely outside of Steam (which handles signing for you), budget for the certificate. On macOS, notarization is required by the OS and is handled through Apple's Developer Program ($99/year). On Linux, signing is not typically required, but proper packaging (.deb, .rpm, AppImage) helps distribution.

Platform upload. The specific upload flow depends on where you are shipping.

• itch.io is the indie default and the one this book has nudged you toward since Chapter 38. Upload via the Butler CLI tool (butler push my-game.zip user/slug:channel). Set a price or mark it pay-what-you-want. Attach screenshots, a trailer, a description. Flip the "public" switch. It goes live in seconds.
• Steam is a multi-week process. You create a Steamworks partner account, upload builds through SteamPipe, configure store pages, set regional pricing, submit for review. Valve review is usually fast (a few days) but the storefront configuration is extensive. Budget two to four weeks from "build is final" to "store page is live."
• GOG, Epic, consoles each have their own workflows, most of which require a signed deal with the platform holder. For a first-time indie, Steam and itch.io are the realistic channels. The others can wait for your second or third game.

Store page going live. The moment you click the publish button, the page is visible to anyone on the internet. Your friends will find it within minutes if you told them the release date. Search indexes will pick it up within hours. Strangers will start arriving.

First purchase notification. This is the weird part. You will be sitting somewhere — your desk, a coffee shop, a friend's couch — and your phone will buzz with an email that says, "You sold a copy of YourGame for $9.99." Or your itch.io dashboard will update from zero to one. Or the Steam partner dashboard will show a tick mark where there was a zero.

The feeling is strange. It is not triumph. It is not relief. It is a specific hollow kind of arrival — the sense that a thing you have been anticipating for months has happened, and it turns out the happening is quieter than you imagined. Someone, somewhere, gave you money for a thing you made. They are now downloading it. They are now playing it. You will never meet them. They may leave a review. They may refund. They may finish your game and never think about it again. They may love it and tell five friends.

The first-purchase feeling is a good feeling and a strange feeling. Sit with the strangeness. It is the moment your game becomes something other than yours.

💡 Intuition: The emotional flatness of shipping is almost universal among first-time devs. The work of shipping is so sustained, so attritional, that by the time you cross the line your nervous system has already burned the adrenaline the milestone deserves. Do not interpret the flatness as disappointment in the game. It is just the body's accounting, settling the books. Go to bed early. The celebration can wait until tomorrow, or next week, or next month.

The Post-Mortem — What Went Right, What Went Wrong

Now you write the post-mortem.

A post-mortem is a structured, public reflection on a shipped project. It is a genre of writing with its own conventions, born in the pages of Game Developer Magazine in the late 1990s and popularized by Gamasutra (now GameDeveloper.com) through the 2000s. For two decades, the Gamasutra post-mortem was the indie developer's yearly inheritance — a steady flow of honest, specific, lessons-learned essays from the people who shipped the games that shaped the medium.

The structure is nearly fixed. A good post-mortem has six sections:

1. Project overview. The team, the dates, the engine, the platform, the budget, the hours. A paragraph or two of context so readers can calibrate the lessons to their own situations.
2. Vision and pillars. What were you trying to make? What three or four words describe the game's intended experience? This is the pitch, in retrospect — the thing you were aiming at.
3. What went right. Three to five specific things the team did well. Not generic things like "the team was passionate." Specific things like "we cut the multiplayer mode at week 12 and it saved the project." Specific process decisions, specific tools, specific team structures, specific design choices.
4. What went wrong. Three to five specific things that did not work. Same rule — specific, not generic. "We spent four months on a procedural generation system that we eventually cut" is useful. "We had scope issues" is not.
5. What we'd do differently. What a future version of the team would change. Not blame, not regret — design lessons for the next project. The structural claim is: given what we know now, here is the process we would adopt.
6. What the experience taught you. The personal reflection. What the project changed about you as a designer. What you learned about your own instincts, your own tendencies, your own craft.

The classics of the genre are worth studying. Eric Barone's Stardew Valley post-mortem is a study in what five years of solo development actually looks like — the repeated rewrites of the entire codebase, the loneliness, the Twitch streams that became his only human contact during the final year. Matt Thorson and Noel Berry's Celeste post-mortem is a masterpiece of specificity, documenting exactly how the four-day PICO-8 prototype grew into the final game and which design pivots mattered most. Lucas Pope's Papers, Please post-mortem discusses the moment he realized the game's tone had to be darker than he had originally planned. Toby Fox's comments about Undertale across various interviews — he never wrote a traditional post-mortem, but the body of his reflection is a post-mortem distributed across a decade of conversations — demonstrate that you can make a lasting cultural object without a permanent team, without a publisher, and with a budget small enough to raise on Kickstarter.

What these post-mortems share is honesty without self-flagellation.

The temptation on the "what went wrong" side is to either minimize (defensive: "we had some small challenges but mostly things went fine") or catastrophize (self-flagellating: "I am terrible, the game is terrible, I will never make another game"). Both are failures of the form. The post-mortem's purpose is to surface lessons for yourself and for the community. Defensive writing hides the lessons. Catastrophizing writing drowns them. The stance you want is clinical: here is what happened, here is why it happened, here is what we now understand. A doctor's stance, not a patient's.

The temptation on the "what went right" side is the opposite — to minimize your successes out of a sense that bragging is unseemly, or to generalize them into meaninglessness ("team communication was good"). Resist. If something went right, name it specifically, and explain the mechanism by which it went right, because the mechanism is what other designers can learn. "Team communication was good because we held a fifteen-minute standup every morning at 9:30 where each person shared their top blocker" is a lesson. "Team communication was good" is a platitude.

🛠️ Practitioner Tip: Write the post-mortem within a month of shipping, while the specifics are still in your head. Wait longer than six months and the lessons soften into generalities — you lose the texture of the actual decisions. If you cannot write the full thing in a month, write a draft of the "what went wrong" section within the first week, because those memories are sharpest immediately after the crunch ends and blur fastest as you recover.

Writing Your Own Post-Mortem

Here is the specific structure to follow for your own post-mortem. Budget 1,500 to 3,000 words. Write it for public consumption — assume someone you have never met will read it and want to learn from your experience.

Section 1: Project Overview. Two to four paragraphs. The team (even if it was just you). The dates (when you started, when you shipped). The tools (Godot, the specific version; Aseprite for art; etc.). The scope (number of levels, length of playthrough, feature list). The budget (dollars spent on assets, contractors, tools). The hours (honest estimate of total hours sunk into the project). The platform (itch.io, Steam, both). The price (free, pay-what-you-want, $X). Do not skip the numbers. Future readers, including future you, need them for calibration.

Section 2: Vision and Pillars. One to two paragraphs. What were you trying to make? What experience did you want players to have? What three or four design pillars anchored your decisions? If you wrote a one-page concept document at Chapter 2, compare it now to what you shipped. Where did the shipped game match the original vision? Where did it drift? The drift is interesting — it is usually where you learned something about what the game wanted to be versus what you wanted it to be.

Section 3: What Went Right. Three to five items. Each item gets a header (the claim), a paragraph explaining what specifically went right, and a sentence or two about the mechanism — why it went right, in terms other people could adopt. Candidates include process choices ("we cut scope at month three"), design choices ("the assist mode we added in Chapter 11 turned out to be the feature most-praised by reviewers"), tool choices ("switching from X to Godot in month two saved us at least six weeks"), team choices ("bringing in a contract musician for a week of dedicated audio work beat six months of my own amateur attempts"). Be specific enough that another designer reading the item could identify whether the same choice applies to them.

Section 4: What Went Wrong. Three to five items. Same structure. Do not inventory every minor problem — inventory the problems whose mechanisms were structural enough that other designers could learn from them. "A bug in the save system cost two days" is not worth a post-mortem item. "We under-scoped the combat system and it took three times longer than estimated" is — because the lesson about combat-system estimation generalizes. Own the mistakes; do not blame the tools or the timeline or the market. If an external factor genuinely contributed, name it, but name your own contribution first.

Section 5: What We'd Do Differently. One to two paragraphs summarizing the design lessons for the next project. This is the forward-looking section. What process changes would you adopt? What tools would you try? What scope rules would you enforce? If you were starting the same project over tomorrow, what would you build first, what would you cut, and what would you leave for a sequel?

Section 6: What the Experience Taught You. One to three 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 started this project?

Publish the post-mortem somewhere public. Your itch.io page's devlog is a natural home. A blog post on your portfolio site works. A Medium post or a Substack newsletter is fine. A Google Doc linked from your Twitter bio is enough. The point is that the document exists in public — both because other designers will benefit and because the act of public commitment sharpens the writing. A post-mortem written only for yourself will be polite. A post-mortem written for the community will be honest.

⚠️ Common Pitfall: The most common post-mortem failure is to write it, save it in a private drive, and never publish. The project stays unprocessed; the lessons stay private; the community does not benefit. Set a publication date when you start writing. Tell at least one person the date. Publish on the date even if the draft feels rough. A rough, published post-mortem is worth more than a perfect, unpublished one.

The Portfolio Compile

Now the portfolio.

A portfolio is not a résumé. A résumé is a list of claims. A portfolio is evidence. It is the proof that you can actually do the thing you say you can do. In a field as driven by output as game design, the portfolio is the primary document — often the only document a studio cares about. The résumé exists to set context for the portfolio.

What goes in a designer's portfolio? Here is the honest list.

The ONE project. Your action-adventure game. The full thing. This is not a portfolio of tech demos or unfinished prototypes — it is a portfolio of the real thing you actually shipped. The itch.io link, the store page, the trailer, the playable build. A studio reviewer opens your portfolio and, within five seconds, understands: this person shipped a game. They know what it takes. That understanding alone puts you in a different pile than the candidates who only have "interested in game design" on their résumés.

Screenshots. Six to twelve high-quality screenshots that show the range of your game — the first level, a mid-game area, a boss fight, the UI, an emotional moment, a high-action moment. Not random gameplay shots — curated, composed, captured for clarity. These are the thumbnails that reviewers scroll through in thirty seconds.

Trailer. Sixty to ninety seconds. Not ten minutes of gameplay footage. A trailer is a trailer — it cuts fast, it lands hooks in the first ten seconds, it ends on your logo and store link. If you cannot edit video, hire a contractor for $200-$500 on Fiverr or Upwork. A bad trailer costs you more than a good trailer costs to make.

Playable build. The actual game, downloadable. itch.io handles this for you automatically — the page is the playable build. Make sure the build works on Windows, Mac, and Linux if you can; Windows-only is acceptable for a first game but limits your audience.

Design documents. Your concept document (Chapter 2). Your one-page narrative outline (Chapter 20). Your scope list (Chapter 37). Your post-mortem (above). These show the process behind the product. A studio reviewer looking for design hires will spend as much time on your process artifacts as on the shipped game, because the process is what you will be paid to do at their studio.

Selected exercises from this book. Not all of them — curated. The three or four best analytical exercises you completed. Chapter 11's difficulty curve tuning write-up. Chapter 17's level-design pacing chart. Chapter 35's genre-position analysis of your own game. These demonstrate that you can think about design, not just execute it. Pick the ones where your writing was clearest and your thinking was sharpest.

Post-mortem. The document you just wrote. It is the single most valuable portfolio piece after the game itself.

What does not belong in the portfolio: half-finished prototypes you abandoned, projects from classes where you did not ship, mods you made for other games (unless they are genuinely polished and relevant), art or writing that is not specifically about your game, a long list of game jam entries with no standout. A small, curated portfolio showing depth in one project is stronger than a large portfolio showing shallow engagement with ten.

Portfolio Formats

Where your portfolio lives matters less than the fact that it exists and is discoverable. But some formats work better than others.

Personal website. The default recommendation. Build one. It does not need to be custom — Notion pages, Squarespace templates, Wix, or Carrd work fine. The domain matters (yourname.com is better than yourname.wixsite.com), so spend $12/year on a domain. The site should have four pages at most: home (with the One Project featured), about (two paragraphs of bio and a photo), work (the portfolio pieces above), and contact (email, Twitter/Bluesky, LinkedIn). If you can code HTML/CSS, a custom site is nice but not required. Most studios will spend two minutes on your site — the information hierarchy matters more than the visual polish.

itch.io page. For indie developers, the itch.io page often serves as the de facto portfolio. The page has the trailer, the screenshots, the description, the devlog posts (where your post-mortem and dev updates live), and the playable build. Many indies do not have a separate website — the itch.io page is the website. This is fine. It is, in fact, preferred by many indie-focused studios, because it shows you understand the ecosystem.

Github. Public code repositories are a second-tier portfolio asset for designers. You are not primarily being hired for code, but evidence of clean, readable GDScript (or C#, or C++) helps for hybrid roles and for indie studios where designers write code. Pin two or three of your best repos to your profile. If your main project's source is public, link it prominently. If it is closed-source (because of third-party assets with restrictive licenses, or because you plan to charge money), that is also fine — say so clearly on your site.

LinkedIn. The professional layer. Keep a basic, up-to-date LinkedIn with your role, your shipped game, and a link to your portfolio. Recruiters use LinkedIn heavily; designers use it less. A clean, current LinkedIn with your game listed as a project takes an hour to set up and opens doors you cannot see from outside.

Not Twitter/Bluesky as primary portfolio. Social media is where you are discoverable, but a timeline is not a portfolio. Use social media to share updates, link to your site, and build a presence. Do not expect a reviewer to scroll your timeline to evaluate your work. Make them one click from your pinned post to your portfolio site.

The strong examples are worth studying. Derek Yu — the creator of Spelunky — runs a personal site at derekyu.com that has barely changed in a decade and remains an exemplar of "small, deep, updated" design. Matt Thorson's site (mattmakesgames.tumblr.com historically, with updated properties since) shows the trajectory of a career across multiple shipped games, each with its own page. Tom Francis (creator of Gunpoint, Heat Signature) keeps a running devlog that doubles as portfolio — you can read through his process for every game he has made. Pippin Barr — experimental game designer, professor — keeps an encyclopedic project list at pippinbarr.com, demonstrating that a portfolio can be a career-scale archive rather than a snapshot. Study these. Copy what works. Your portfolio should look like theirs in five years.

🎮 Case Study: Look at derekyu.com right now. Notice: a simple blog. A list of projects. Screenshots. Links to store pages. Nothing flashy. Nothing animated. No parallax scroll, no video background. The site loads in under a second. The information is findable in under thirty seconds. This is what a professional game designer's portfolio looks like. The quality of the work speaks; the site stays out of the way.

The Cover Letter for Design Roles

When you apply to design roles — whether at a studio, an indie label, or a contract gig — you will need a cover letter. The cover letter is a short document, three to five paragraphs, that accompanies the portfolio and résumé.

The generic "I have been passionate about games since childhood" cover letter is a waste of your time and theirs. Every applicant writes that letter. Every hiring manager has read five hundred versions of it. It demonstrates exactly nothing about your capability as a designer.

The cover letter that works demonstrates design thinking in the letter itself.

Paragraph 1. Open with a specific observation about the studio's most recent game. Not a compliment — an observation. "I noticed that YourGame's second-tier enemies telegraph their attacks with a 200ms wind-up frame, which I read as a deliberate accessibility choice — most action games in the genre use 150ms or less, and the extra 50ms is exactly the reaction window that changes who can play your game." That sentence shows that you played the game, noticed a specific craft decision, and can articulate the tradeoff. This is design thinking. The studio will read the rest of your letter.

Paragraph 2. Reference your own work. Not "I made a game" — "I shipped a 2D action-adventure on itch.io last month, and in building its combat system I made the opposite decision to yours — I went with tighter 120ms windups and compensated with a generous parry window. It worked for the tone I was going for, but I have been thinking about the accessibility tradeoff your approach solves more elegantly." Two design decisions in conversation. Now you are a colleague having a conversation, not an applicant begging for attention.

Paragraph 3. Make the ask. What role are you applying for? What do you think you could contribute? Be specific. "For the junior combat designer role, I would want to start on enemy design — I have been building an encounter-design spreadsheet framework that I would love to pressure-test against your team's process."

Paragraph 4. A sentence or two on logistics. When you can start. Whether you are willing to relocate or remote. Salary expectations if asked.

Paragraph 5. A one-sentence close. Not effusive. Functional. "Portfolio at yoursite.com. Resume attached. Happy to send a specific writing sample or walk through a playable build if useful."

That is the letter. Four paragraphs of design-thinking, one of logistics, one of close. No "I am passionate." No "I have always loved games." You demonstrated the passion by analyzing their game. You demonstrated the craft by referencing your own work. You demonstrated professionalism by making the ask clearly and closing cleanly.

🛠️ Practitioner Tip: If you cannot find a specific observation about the studio's game to open with, you are not ready to apply to that studio. Play the game. Actually play it. Take notes. Find the observation. If you cannot find one that is both genuine and specific, the fit probably is not there — find a different studio whose work you actually admire and can speak to.

Design Tests and Portfolio Reviews

Some studios will ask for a design test or portfolio review as part of the interview process. Prepare for both.

Design tests. These are take-home exercises — sometimes a written design brief, sometimes a small playable prototype. Common prompts include: "design a fishing minigame that would fit in our next Zelda-like," or "here is our current inventory system — write a one-page critique and redesign." The test is usually timeboxed (a week, sometimes two days) and unpaid. The work you produce is evaluated for design thinking, clarity of writing, and fit with the studio's tone.

Preparation: practice writing design briefs on your own. Pick a game you love, pick a system that bothers you, write a one-page "if I were the designer, here is what I would change." Do this a dozen times before you need it for an interview. By the time a real design test arrives, the genre of writing — the specific voice of a design brief, the specific structure, the specific level of detail — is in your hand. This practice is the single highest-leverage thing you can do to get good at design tests.

Whiteboard design. Some studios ask live design questions in the interview. "Design a fishing minigame for a Zelda-style game, on the whiteboard, in twenty minutes, while we ask questions." This is terrifying and is meant to be. The test is whether you can think out loud about design, respond to pressure, and iterate under scrutiny.

Preparation: practice with friends. Give yourself a prompt, stand at a whiteboard, and think out loud for twenty minutes while someone asks hostile questions. This feels stupid the first time. By the fifth time, you have built the muscle. Every time you do it, you learn to slow down, to ask clarifying questions before diving in, to name your assumptions out loud, to offer multiple alternatives rather than committing to one idea, to notice when you are stuck and verbalize the stuckness productively.

Portfolio reviews. A senior designer will sit with you for an hour and walk through your portfolio piece by piece. They will ask: why did you choose this enemy placement? What was the original plan for this level, and what changed? Why does the combat system use a stamina bar instead of cooldowns? How did you handle accessibility in the settings menu?

Preparation: play through your own game before the interview, explicitly thinking about the why behind every decision. Take notes. Be ready to articulate the design intent behind every system. The reviewer is not trying to trip you up — they are looking for evidence that you can defend decisions, recognize their costs, and articulate what you would change. An honest "we tried X, it did not work, so we shipped Y, but if we had another month I would revisit" is stronger than a confident "Y is obviously the right answer."

Networking Without Being Sleazy

The word networking makes most designers' skin crawl. It evokes cheap transactionality — the kind of person who collects business cards at parties and never reads them again. Most designers are bad at networking because they are good at design, and the skills that make you good at design (patience, long-form thinking, introversion, internal focus) are nearly the opposite of the skills conventional networking rewards.

Good news: the networking that actually works in game design is the opposite of the networking you are afraid of.

The core rule: give before you take. Share your work publicly. Help other designers when you can. Answer questions on Discord servers. Leave thoughtful comments on devlogs. Retweet interesting things with context. Review other people's games on itch.io — actually play them, write two paragraphs, link back to them. The pattern is: you contribute to the community in small, consistent ways. Over months, people start to recognize your name. After a year, you are a known quantity. After two years, you have a network — not because you networked, but because you showed up.

The venues.

• GDC (Game Developers Conference) — the industry-wide professional conference, held annually in San Francisco. Expensive ($1,500-$3,000 per pass for non-speakers), intense, and the main event where the industry actually meets in person. If you can afford one industry event, this is it. Budget for the trip once every two to three years, and when you go, prioritize the hallway conversations over the talks (the talks will be on the GDC Vault afterward).
• Local IGDA chapters. The International Game Developers Association has local chapters in most major cities. Free or cheap monthly meetups. Designers, artists, engineers, producers. Low-pressure, practical, and a durable source of local collaborators.
• Indie meetups. Most cities have some form of "indie night" — a pub meetup, a co-working space, a monthly demo showcase. Find yours. Show up consistently. Bring your build when it is ready.
• Discord servers. The Godot server, the r/gamedev Discord, genre-specific servers (roguelikes, platformers, visual novels). Find two or three you care about and participate. Not cross-post-and-leave — participate. Answer questions. Ask questions. Show your work.
• Twitter/Bluesky. Still valuable, especially for indies. Build a presence. Post your work. Engage with other developers' work. Follow the designers whose work you admire. The conversations on dev Twitter, at their best, are a rolling masterclass in craft.
• Game jams. Ludum Dare, GMTK Jam, itch.io hosted jams. These are networking-as-making: you meet other designers by collaborating on 48-hour projects. The relationships formed in jams are often stronger than relationships formed at conferences, because you have actually worked together.

The practical rule: pick two or three venues, show up consistently for a year, be generous with your time, and let the network form naturally. Do not attempt to network at six venues simultaneously. Depth beats breadth. A Discord server where you are a trusted regular is worth more than six servers where you are a lurker.

⚠️ Common Pitfall: The networking anti-pattern is cold-messaging senior designers asking for mentorship, job leads, or portfolio reviews without any prior interaction. This almost never works and it poisons future interactions. Instead: engage with their public work for six months, comment thoughtfully, share their work, and then — if you have something specific to ask — send a concise, well-framed question. The senior designer who has watched you engage thoughtfully with their work for six months will answer. The one who sees a cold message from a stranger will not.

The 7 Themes — Revisited

Forty chapters ago, this book opened with a promise to organize the craft of game design around seven recurring themes. It is time to see how those themes played out in your project.

1. Design is systems, not ideas. You learned this by Chapter 5 and re-learned it in every chapter since. The idea "make an action-adventure game" is free. Anyone can have that idea. The system that delivers the idea — the movement mechanic, the core loop, the enemy AI, the progression curve, the level pacing — is where the craft lives. Every designer who has ever quit before shipping quit at the moment they realized ideas were not the thing; implementation was the thing. You did not quit. You built the systems. You discovered, somewhere around Chapter 9 on emergence and Chapter 24 on economies, that the feeling of a game is not assembled from ideas but from systems interacting. Your action-adventure feels the way it feels because you spent forty chapters tuning systems — not because you had better ideas than other designers.

2. Player experience is the only thing that matters. Chapter 4 opened this theme and Chapter 31 on playtesting brought it home. The player's experience, not your design intent, is the measure of the work. You learned this the hard way in Chapter 31 when you watched a playtester miss the thing you thought was obvious, and in Chapter 32 when you rebalanced a boss fight because five out of five testers found it unfair. Every time the playtesting data contradicted your intuition, you learned the theme again. Your shipped game is good to the degree that players experience it as good. That is the only scoreboard.

3. Constraint is the engine of creativity. Chapter 7 named it; Chapter 37 on scope enforced it. You started with too many ideas. You cut most of them. The game you shipped is better than the game you imagined, not because your imagination was bad, but because the cuts forced you to make the remaining ideas work harder. The levels you are proudest of are the levels you designed inside your tightest constraint — the one tileset you could afford, the one enemy variant you could animate, the one boss you had time to polish. Constraint made the game. Unconstrained, you would still be in pre-production.

4. Every design decision is a tradeoff. Chapter 11 introduced the flow channel as a tradeoff between challenge and boredom. Chapter 13 taught difficulty as a tradeoff between accessibility and mastery. Chapter 24's economies, Chapter 25's progression, Chapter 26's combat — all tradeoffs, all the way down. Your game exists in a specific position along dozens of axes, and every position is a choice against other positions. The mature designer does not seek the nonexistent "optimal" design; they understand the tradeoffs of their chosen design and defend them clearly.

5. Games teach through play. Chapter 13 named this; Chapter 16 on level design showed how to use space to teach, and Chapter 23 on cutscenes showed what happens when you teach the wrong way. The best tutorial in your game is invisible — a level that teaches a mechanic by forcing the player to use it. The worst is a text box that explains what the player should do. You internalized this, probably, by the middle of level-design work when you redesigned your opening three times because playtesters kept missing the jump mechanic. The third redesign was silent. It taught through play. It worked.

6. Fun is not an accident. Chapter 11 on flow, Chapter 12 on motivation, Chapter 13 on mastery — the entire psychology unit argued that fun is the product of engineered interactions between challenge, reward, feedback, and mastery. You engineered fun. You tuned it. You iterated on it. When you look back at the version of yourself who started this project expecting to "find" fun through inspiration, you will not recognize that person. Fun is craft. You built fun. It took forty chapters, but you know how it is built.

7. Your first game will be bad — ship it anyway. This is the theme that runs through every other theme, and we will spend the rest of this chapter on it. Your first game is probably rough. Your second game will be better because you shipped the first. Your fifth game will be substantially better because you shipped the first four. Every designer in this book — Miyamoto, Kojima, Meier, Wright, Barone, Thorson, Fox, Sakurai, Spector, Gaynor, Yu, Blow — shipped a bad first game. The pattern is so universal it is almost the definition of the craft. The designers who never became designers are the ones who did not ship the bad first game. You shipped. You are in the pipeline.

Your First Game Will Be Bad

Let's linger on the seventh theme.

Your first game will be bad. Not because you are bad. Not because you did not try hard enough. Not because the tools failed you or the genre is played out or the market is tough. It will be bad because first games are bad. It is statistically, historically, culturally true across every medium humans have ever created. The first novel is bad. The first album is bad. The first film is bad. The first game is bad. First things are bad.

The craft is not that the first thing is good. The craft is that you shipped it, and in shipping it you learned things the unshipped cannot teach.

The reason it matters: a bad shipped game teaches more than a beautiful unshipped game. The unshipped game is still in your head. You can convince yourself it would have been great. You can keep rewriting it in your imagination, perfecting it, never finishing it, never testing it against reality. The shipped game is out. Players have played it. Reviews exist. The post-mortem is written. You know — in a way you could never have known otherwise — what works and what does not.

The mechanism: shipping forces completion, completion forces decisions, decisions build the skill. You cannot ship without making a thousand small decisions — this tileset, this BPM on the boss music, this hit reaction, this UI hierarchy, this ending. Each decision, good or bad, is a unit of learning. The designer who made a thousand decisions has a thousand units of learning. The designer who is still in pre-production has zero.

The evidence: every designer in this book. Toby Fox's pre-Undertale work was a series of EarthBound ROM hacks, including the famously disturbing Radiation's Halloween Hack — genuinely rough work that would be embarrassing on a CV if it had not led to Undertale. Eric Barone's pre-Stardew experience was nearly nothing — he started Stardew from the beginning of his game-dev career, and the first two years of its development produced code he had to rewrite multiple times. Markus Persson's pre-Minecraft work included multiple abandoned projects, a small shipped game called Wurm Online, and years of day-job programming. Derek Yu's first shipped game was Eternal Daughter, a freeware platformer from 2002 that is genuinely rough compared to Spelunky or UFO 50. Toby Fox, Eric Barone, Markus Persson, Derek Yu — every designer whose later work became industry-shaping shipped rough work first.

The rough first work was not wasted. It was the tuition.

You paid the tuition. Your first game is the receipt. The degree is what comes next.

📜 Reflection: There is a specific kind of grief that attends finishing a first game. It is the grief of realizing, now that you can see the whole thing, that it is not what you imagined. The game in your head — the one you pitched to yourself at Chapter 2 — was perfect. The game on itch.io is not. The gap between the two is not a failure. It is the space where your craft grew. Every chapter you completed was a bet that the shipped thing would teach you more than the imagined thing. You won the bet. The grief will lift. The craft will stay.

What Happens Next — The Second Game

The second game is where craft consolidates.

The first game was the learning — every mechanic was new, every system was a puzzle, every chapter of this book was a new tool. You were acquiring the vocabulary. The second game is where the vocabulary becomes a language. You will still learn — you will always still learn — but you will start most chapters of the second game's development already knowing what you are trying to do, already knowing the trap to avoid, already knowing what "scope too big" feels like before you are twelve weeks in.

Decide what the second game is. Your options, in roughly increasing order of ambition:

Improve this one. A sequel, an expansion, a remaster. The same universe, the same core systems, a larger canvas. This is the safest second project because you are not reinventing the foundations. Celeste started as a four-day PICO-8 prototype called Celeste Classic; the full Celeste that shipped on Switch in 2018 was, in effect, the second version of that idea. Spelunky HD (2012) and Spelunky 2 (2020) are each Derek Yu revisiting the same core with more time, more team, more craft.

Pivot. A new genre, a new art style, a new set of systems. This is higher risk because you are building from scratch again, but lower risk than the first game because you now know how to ship. Thomas Was Alone was Mike Bithell's breakthrough after earlier unsuccessful attempts in other genres. Return of the Obra Dinn was Lucas Pope pivoting from the paperwork-simulator space of Papers, Please into detective puzzle games — a genre move that nobody predicted but that worked.

Partner. Join a studio. Apply your post-shipped portfolio to a junior or mid-level design role at an indie studio or AAA. Your shipped game is your ticket. The studio context will teach you a different set of skills — collaboration, communication, negotiating scope in a shared vision — that solo projects cannot teach. Many designers whose names appear in this book spent their middle career inside studios before returning to indie work, and many are still at studios. There is no wrong answer.

Continue solo. Stay independent. Keep shipping small games on itch.io. Build a back catalog. Develop a voice across multiple shipped titles. This is harder financially but builds the kind of designer whose name becomes associated with a particular feel — Daniel Mullins (Pony Island, Inscryption), Bennett Foddy (QWOP, Getting Over It), Pippin Barr (dozens of experimental short games).

The decision is yours. The decision is revisitable. You can pivot between these paths many times across a career. The only wrong choice is paralysis — letting the question of "what next" prevent you from starting anything at all.

Careers in Game Design — An Honest Overview

The honest overview of career paths in game design. I am going to be blunt here, because nothing in this book has been served by being dishonest with you.

Indie full-time. Supporting yourself entirely on the revenue from indie games you self-publish. This is rare. Most games do not make enough to pay one developer's rent, let alone a full-time salary. The indies who sustain this path — Eric Barone, Lucas Pope, Matt Thorson, Toby Fox — are outliers, and even among outliers most have stretches of financial anxiety that do not show up in interviews. To attempt this path safely, you want one of: meaningful savings (18-24 months of runway), a partner whose income covers basics while you build, grants (Indie Fund, various national arts councils, publisher advances), or a day-job you can reduce to part-time. Treat "indie full-time" as a goal to work toward, not a launch condition.

Studio designer. The most common paid path in game design. The tiers:

• AAA entry — usually via QA (quality assurance), with internal moves into design over 2-5 years. The QA path is long and frustrating, but it is the realistic entry point for most people without industry connections. Some AAA studios hire directly into junior design roles from portfolios, but the postings are rare and competitive.
• AA/indie-label direct hire — smaller studios hire junior designers directly from portfolios. Your shipped game is the qualifier. Expect $50-$75k in the US, less in most other countries, more in a few tech-center cities. Expect long hours during crunches, though crunch is trending down across the industry.
• Mid-size studio mid-career — after 3-5 years at smaller studios, mid-size studios hire into mid-level and senior design roles. This is where salaries meaningfully increase and where design ownership becomes real.

Consulting. Experienced designers (typically 5+ years of shipped work) can do consulting gigs — advising other studios on design, contracting for specific systems, freelance narrative or level design. This is not an entry path. Most consultants reach consulting only after their portfolio and reputation can carry the work.

Teaching. MFA programs in game design exist at NYU Tisch, USC, RIT, Carnegie Mellon, DigiPen, and many others. They hire faculty with shipped credits. YouTube educator paths are open to anyone (Mark Brown's Game Maker's Toolkit, Adam Millard's channel, Masahiro Sakurai's own channel) — the rise of designer-as-educator is one of the positive stories of the last decade. A fraction of designers make YouTube their primary income.

Adjacent roles. The skills this book taught you apply beyond game design proper. UX research (the practical sibling of playtesting — Chapter 31). Narrative writing (Chapter 20-23). Game journalism (write post-mortems of other people's games). Esports (design informs competitive balance — Chapter 28 on multiplayer, Chapter 32 on balance). Product design in software (Chapter 29 on UI/UX translates directly). Teaching at the K-12 level. If game design proper does not work out as a career, the design thinking you built transfers to a dozen adjacent fields, at salaries often higher than game design itself pays.

When to Walk Away

Here is the hardest part of the honest overview.

Games are a hard industry. The labor economics are brutal. Studios close. Projects get canceled six months before ship, taking two years of your life with them. Layoffs are common — the industry shed tens of thousands of jobs across 2023-2024, and the cycle is structural. The work is creative in a way that demands emotional investment; the compensation is, on average, below what the same skills would earn in software engineering, product management, or UX design roles outside games.

Most people who love games do not make careers in them. This is not a failure of those people. It is the shape of the industry. A field that produces one shipped title for every ten attempts, that pays its junior staff below-market wages, that expects crunch, that layoffs punctuate — that field does not have room for everyone who wants to be in it. Some percentage of the people reading this book will work in games for a long, satisfying career. Some percentage will work in games for five or ten years and then leave. Some percentage will ship one game, realize they like making games more as a craft than as a career, and find another way to fund their lives while continuing to make games on the side.

Walking away is valid. Walking away is often correct.

The skills you built are not trapped in the game industry. Design thinking — the core thing this book tried to teach — is one of the most transferable skill sets in knowledge work. Product designers at tech companies are, in effect, game designers for software that is not explicitly a game. UX researchers are playtesters. Data analysts are game economists. Software engineers are system designers. Teachers are level designers, in a sense. Writers of every kind are narrative designers. The post-mortem you write about your first game will demonstrate, to any of these adjacent fields, that you are a person who can think about systems, ship under pressure, and reflect honestly on their work. That is the most valuable thing on a résumé in any industry.

The book you wrote — the design thinking, the craft — is yours. It does not leave when the job title changes. You are a designer now. The word "designer" is a thing you are, not a thing you do for an employer.

📜 Reflection: There is an ugly cultural pressure in the games industry that treats "making games for a living" as the only valid career outcome. This pressure is wrong. It costs people their mental health, their savings, and often their relationship with games themselves. If you ever reach a point where you love games as a player but find game-making as a profession is grinding you down, leave. Keep making games on weekends if you want. Go work somewhere that pays better and treats you humanely. The design craft you built will travel with you. The games you make after that, on whatever schedule, will still be games. You will still be a designer.

The Letter to Your Future Self

Before you close this book, write one more document.

A letter to yourself, one year from today. Save it somewhere you will find it — a calendar reminder, a dated email to yourself via something like FutureMe.org, a text file on your desktop with the dated filename. Set it to surface in twelve months.

In the letter, describe where you are right now. The game you just shipped. The hardest problem you solved during development. The thing you most regret cutting. The thing you are most surprised you shipped. The person you were at Chapter 1 versus the person you are at Chapter 40. The decision you are about to make — second game, studio job, walk away, other — and why.

Write honestly. Write specifically. Write the things you would never tell a stranger and the things you would only tell your designer-self a year from now.

Then set it aside.

In twelve months, the letter will arrive. The you that reads it will be a different you. Your shipped game will be twelve months old — still the same game but different in your memory, softened by distance, newly recognizable as the first thing rather than the only thing. The you that reads the letter will either have shipped a second game (in which case the letter is a time capsule of where you were when the second game was only a possibility), or you will still be in the middle of the second game (in which case the letter is a reminder of why you started), or you will have walked away (in which case the letter is proof that the you who made this choice knew themselves well enough to make it).

The point of the letter is that design, like life, is a long game. The first shipped project is a single point in a long career, or a single point in a life that includes many other things. The distance between the you-who-shipped and the you-who-reads-the-letter-in-a-year is the thing you are growing. Make the distance visible to yourself.

What This Book Tried to Teach

No book can teach you how to make a great game.

Making great games is a craft that takes decades to develop, requires talent the book cannot give, demands luck the book cannot provide, and depends on relationships, contexts, and cultural moments the book cannot construct. The books that claim to teach game design as a replicable algorithm are lying to you, usually by accident, usually because their authors have internalized their own practice so thoroughly that they have forgotten how much of it is not transferable.

This book tried to teach something smaller and more honest.

It tried to teach you how to think about games as systems. How to recognize that the play experience is a product of interacting mechanics, not a single ingredient you can name. How to iterate toward fun instead of waiting for inspiration. How to playtest, even when playtesting is humiliating. How to cut, even when cutting hurts. How to ship, even when shipping scares you. How to look at a game you love — Celeste, Dark Souls, Breath of the Wild — and reverse-engineer what it is actually doing, system by system, decision by decision, so that next time you design something you have more tools in your hand.

The book is a companion to your own design work, not a replacement for it. Everything that happens now — the second game, the tenth game, the long career or the short one — is yours. The book stays on the shelf. Your next design decision is yours alone.

Progressive Project — Final Checkpoint (Chapter 40)

The final progressive-project tasks are these.

Ship the game. If it is not already live, make it live. Today or this week. Upload the final build to itch.io. Flip the public switch. Set the price. Write the store description. Post the trailer. Do not wait for one more polish pass. The last 5% of polish cost you 50% of the remaining time — cut it, ship, patch later.

Write the post-mortem. Follow the structure above. 1,500 to 3,000 words. Publish it publicly. Link it from your itch.io page's devlog and from your portfolio site.

Compile the portfolio. Build the site. The domain, the pages, the screenshots, the trailer, the playable build, the design documents, the post-mortem. One evening of work, at most two. Do not let portfolio-perfectionism prevent portfolio-existing. A rough portfolio that is public beats a beautiful portfolio that is unpublished.

Send the link to three people. Specifically: three people whose opinions you respect and whose taste you trust. Not family. Not your most supportive friends. The ones who will tell you the truth. Ask them — in the email, in the DM — to look at the portfolio and tell you the one thing they would change. Listen to what they say. Change it if it is right.

Thank the five people who playtested. Actually write the thank-you. Email them, DM them, or if you know them in person, buy them coffee. Name specifically what their feedback changed. Tell them the version number their feedback is in. A playtester who hears "the save-game bug you reported is fixed in 1.0.3, which shipped yesterday" will playtest your next game too. A playtester who never hears anything will not.

That is the project. You are done.

A Final Thought on Play

We design games because play matters.

Play is how humans learn. From the age of six months — when infants discover peek-a-boo — through childhood's games and adolescence's sports and adulthood's board nights and a player's thousandth run through their favorite roguelike, play is the universal human technology for practicing the world. It is how we build the skills that do not yet have real-world consequences. It is how we model social systems, physical systems, emotional systems. It is how we experiment with identities — the avatars we make, the characters we inhabit, the small selves we try on in low-stakes worlds before committing to bigger ones.

Play is how we connect. Two strangers sitting at a board game have something to talk about. Four friends on a couch playing Mario Kart are doing something together that is specifically, irreducibly, a shared event. A raid guild that meets every Tuesday is a social unit as real as any club. The esports audience watching a finals match is participating in a communal narrative. Games are one of the few technologies that make connection and play indistinguishable.

Play is how we express. Every game someone makes is a small statement about what they think play can be. Papers, Please says play can be a vehicle for moral weight. Journey says play can be a meditation. Dark Souls says play can be hard-won transcendence. Celeste says play can be about mental health and persistence. Breath of the Wild says play can be curiosity without agenda. Disco Elysium says play can be a novel with a dice roll. Every designer who ships is adding a sentence to this collective statement about what play is for.

Making a game is contributing a small object of delight to the world. Someone will play your game. They will laugh at a joke you wrote. They will die to a boss and try again. They will find a secret you hid in a corner of a level. They will finish the game and sit with the credits and feel something — small, specific, real — that did not exist in the world before you built it.

This is not frivolous work. It is not a waste of your twenties or thirties or forties. It is real contribution, and the fact that the medium looks like toys does not change the fact that the contribution is to how humans experience being human.

You made a thing that gives people something to play with.

That is a good life's work, if you keep at it. It is a good thing to have done once, if you do not. Either way, you did it. You built a system of delight and released it into the world. The world is, incrementally, better for it.

Common Pitfalls

Five final pitfalls specific to the shipping-and-reflection phase.

Never finishing the post-mortem. You ship the game, collapse for two weeks, then drift away into other projects. The post-mortem sits in a Google Doc forever, 40% written. Commit to a publication date in the first week post-launch. Publish rough. Rough-and-public beats perfect-and-unpublished.

Not shipping because "one more polish pass." The mid-fidelity version of the game is the shippable version. The always-just-one-more-polish-pass mindset is how perfectionist designers never ship. The rule: polish has diminishing returns after the first 80%. The last 20% of polish costs as much as the first 80%. Decide when the diminishing returns flatten, and ship there.

Portfolio with too many things. You include every prototype, every game-jam entry, every abandoned side project. The reviewer does not know where to look. They give up. They move on. Curate ruthlessly. Two or three deep projects > ten shallow ones. The shipped action-adventure is your headline piece. Everything else supports it or gets cut from the portfolio.

Treating the second game's scope like the first game's. You shipped one game. Your first instinct for the second game is to make it twice as big. Three times as big. With multiplayer this time. And procedural generation. The second-game-scope-creep is the most common way first-time shippers never ship again. The rule: your second game should be the same scope as your first, executed with the lessons you now have. Growth in quality, not in size. Scope up on the third game, maybe the fourth.

Burning out before seeing the impact. Shipping exhausts you. The post-launch period exhausts you further. If you immediately jump into full production on the next project, you will burn out within three months and disappear from the field entirely. Take the real break. Two weeks minimum. A month if you can afford it. Your career is measured in decades, not months. The rest is the work.

Summary — Go Make the Next One

You finished the book. You finished the game.

The book's lessons: Design is systems. Player experience is the only scoreboard. Constraint is generative. Every decision is a tradeoff. Games teach through play. Fun is engineered. Your first game will be bad — ship it anyway.

The game's proof: you did it. You shipped.

The second game is waiting. Or the studio job is waiting. Or a life outside game-making is waiting, a life that still includes play, still includes design thinking, still includes the craft you built. Whichever of these is next for you, the preparation is done.

Go make the next one.

Or, if the next one is not a game, go make the next thing. The design mind you built inside these forty chapters is portable. It will be useful wherever you point it.

Either way: thank you for reading. Thank you for building the game. Thank you for shipping. Thank you for contributing one more small object of delight to a world that is, every day, in need of objects of delight.

The game is done. The book is done. The craft is yours.

Go.