Part IX: Ship It

Chapters 37--40

Here is the truth about game development that nobody tells you early enough: finishing is a skill. It is a separate skill from designing, from programming, from art, from sound, from writing. It is the skill of looking at everything you want your game to be, accepting what it actually is, and releasing it into the world anyway.

Most games are never finished. Not most bad games --- most games, period. The graveyard of unfinished projects stretches to the horizon, and it is full of brilliant ideas, clever mechanics, beautiful art, and passionate developers who could not bring themselves to stop adding, stop tweaking, stop polishing, and ship. I have been there. I have a hard drive full of prototypes that were going to be amazing. They are not amazing. They are nothing, because nobody has ever played them.

A shipped game teaches you more than ten unfinished ones. Not because shipped games are better --- they often aren't. Some of the best game design I've ever seen lives in prototypes that never went public. But shipping is where you confront every lesson this book has taught you at once: scope management, prioritization, player experience, polish, production, marketing, community, feedback, and the psychological challenge of saying "this is done" when every instinct tells you it could be better.

This is the final part of the book, and it has one job: get your game out the door.

What You Will Learn

Chapter 37: Scope Management might be the most practically valuable chapter in this entire book. Scope is the set of features, content, and polish that your game includes. Scope management is the discipline of matching your ambitions to your resources --- time, skill, energy, money --- and making the hard decisions about what stays and what gets cut. Every designer's first game is scoped too large. Mine was. Yours will be, despite my warnings. The question is not whether you will need to cut --- you will --- but whether you will cut strategically or cut in a panic at the deadline. This chapter covers estimation (how to figure out how long things actually take, not how long you want them to take), prioritization frameworks (must-have, should-have, nice-to-have, and the ruthless application of "cut"), the minimum viable product mindset (what is the smallest version of your game that is still your game?), and feature creep (the silent killer of indie projects). The Celeste team has spoken publicly about features they cut: an entire chapter, multiple mechanics, a different ending. The game is better for those cuts. Cutting is not failure. Cutting is design. You will perform a scope audit of your project: a complete must-have/nice-to-have/cut list that determines what your final game includes.

Chapter 38: Publishing, Marketing, and Finding Your Audience covers the part of game development that most designers either ignore or dread. You are making a game to be played. Played by whom? Found how? The indie market in 2026 is vast and brutally competitive. Thousands of games release every week. Quality alone does not guarantee an audience. You need a platform (we will use itch.io --- free, developer-friendly, and the best launchpad for a first game), a page that sells your game in seconds (screenshots, description, tags), and at minimum a basic understanding of how people discover games (social media, community building, press outreach, algorithmic visibility). This chapter is not about turning you into a marketer. It is about ensuring that the game you spent an entire book building actually reaches human beings. You will create your itch.io page, export a build from Godot, upload it, write your store description, take your screenshots, and set your price (free, for a first game --- we will discuss why). The moment you click "publish," you will have done something that most aspiring game developers never do: released a game.

Chapter 39: Post-Launch addresses what happens after you ship. Your game is public. People are playing it. Some of them are leaving feedback. Now what? This chapter covers community management (how to respond to feedback, both positive and negative), live updates (what to patch, what to add, what to leave alone), analytics (what player data tells you and what it doesn't), and the emotional experience of having your work critiqued by strangers. Post-launch is where you discover how your design actually works in the wild --- not with carefully recruited playtesters, but with real players who found your game, downloaded it, and formed opinions. Some of those opinions will be wrong. Some will be devastating and correct. Learning to tell the difference is a career-long process that starts here. You will collect feedback on your published game, plan a v1.1 patch based on that feedback, and release it. The patch cycle --- ship, listen, fix, ship again --- is the rhythm of professional game development. Getting comfortable with it now will serve you for the rest of your career.

Chapter 40: Capstone is the final chapter. It has two purposes. First: the post-mortem. You will write a structured reflection on the entire development process --- what worked, what didn't, what you would do differently, and what you learned. The post-mortem is the single most valuable document in game development, and the industry standard for a reason. Every studio writes one after every project. The honest ones produce better games next time. Second: the portfolio. You will compile your game, your design documents, your post-mortem, and your process artifacts into a portfolio package that demonstrates your skills as a designer. Whether you are applying for jobs, applying to graduate programs, or just building a body of work, the portfolio is the proof that you can do this. Not that you can talk about doing it. That you can actually do it.

The Hardest Part

I want to be direct with you: shipping is emotionally difficult.

You have been building this game for the entire duration of this course or this book, and it is not what you imagined at the start. It is smaller than you planned. It is rougher than you wanted. There are features you designed in Part II that you had to cut in Part IX. There are levels you prototyped in Part IV that never made it past paper. There are narrative beats you wrote in Part V that don't land the way you hoped. There are systems you built in Part VI that are simpler than the games you admire.

That is normal. That is what making a game feels like. The gap between the game in your head and the game on the screen is permanent and universal. Shigeru Miyamoto feels it. Hidetaka Miyazaki feels it. The Celeste team feels it. Every designer who has ever shipped anything feels it.

The discipline of shipping is the discipline of accepting that gap and releasing anyway. Not because the game is perfect, but because the game is done enough --- done enough to be played, done enough to be learned from, done enough to be the foundation for the next game, which will be better.

Your first game will be bad. I have said this throughout the book, and I mean it without cruelty. Virtually every designer's first game is bad. The ones who become great are the ones who shipped that bad first game, learned from it, and made a second game. And a third. And a tenth. Each one better than the last, because each one taught them things that no book --- not even this one --- can teach.

The knowledge in this book is necessary but not sufficient. It gives you the vocabulary, the frameworks, the theory, and the tools. But the understanding --- the deep, instinctive, hard-won understanding of how games work and how to make them well --- that only comes from making games. From shipping them. From watching people play them. From failing and trying again.

Your Project: Finished

By the end of these chapters, you will have:

  • A scope audit with must-have/nice-to-have/cut decisions finalized
  • A game exported from Godot and published on itch.io
  • A store page with screenshots, description, and tags
  • Feedback collected from real players
  • A v1.1 patch planned and released
  • A written post-mortem
  • A portfolio package

You will have a shipped game. A real one. Publicly available. Playable by anyone in the world. With your name on it.

That is the thing I care about most in this entire book. Not the mechanics chapter or the systems chapter or the level design chapter. Those are means. The end is this: you made a game, and you shipped it. You joined the ranks of people who have done the hard, unglamorous, emotionally complicated work of finishing something and putting it into the world.

The game industry does not need more people with great ideas. It needs more people who can execute, iterate, and ship. Ideas are free. Execution is everything. And execution ends with a game that exists outside your hard drive, in the hands of players, doing the thing games do: creating experiences.

I don't care if your game is innovative. I don't care if it's original. I don't care if it wins awards or goes viral or gets covered by press. I care that you made it and you shipped it and you learned from it. Because that is how designers are made. Not in classrooms, not in books, not in design documents. In the act of shipping.

Ship it.

Chapters in This Part