Lock the game, then polish

There is a day in a release when you agree the game will not gain another mechanic, puzzle, or system. It feels like giving up, and it is the opposite. Until that day, every bug fix competes with a new idea, and the new idea usually wins, because ideas are more fun than the bug. After that day, the hours go into the thing players will actually touch.

Polish before the lock is how projects stall. You shine a feature you are about to replace. The lock is what makes a checklist meaningful: performance, the first minute, the crash, the sentence on the store page matching the build. A game can ship with a small feature set. It struggles to ship with an undecided one. Decide, in writing, what will not be in this version. That sentence is the release.

Content lock is the moment you agree the game will gain nothing else. No more mechanics, puzzles, systems, or cutscenes. Every hour left goes into improving what is already built.

The rule is easy to state and hard to hold. An unfinished idea always looks like the piece that would make the whole thing click, and a rough corner is an open invitation to invent a new system rather than repair the old one.

On a small puzzle game, holding the line means admitting there is already enough game there. Making it bigger stops being the job. Making it shippable takes over.

One addition survived content lock: a developer commentary mode. Portal and Left 4 Dead popularized the format, scattering small audio nodes through levels so the team can explain how a mechanic, a test, or a puzzle came together.

Commentary is useful because it shows design as craft rather than magic. Tutorials are constructed on purpose. Level layouts steer where the player looks. Playtesting rewrites things that seemed settled.

So the magnet game shipped with commentary unlocked after the credits. Finish it once, play again, and you can walk into small speaker nodes and hear short notes on how each part was built.

It earned the exception because it added nothing to the campaign and disturbed nothing in the design. It simply turned the finished game into a record of how it was made.

With the feature list closed, finding bugs became the whole project. A small group of testers played the game end to end under one instruction: report everything, however small it looks.

They delivered. Turning magnetism off at one precise moment sent the magnet character ricocheting off a ceiling at a strange angle. A polarity-switching platform jammed if you hammered the button. Binding movement to the mouse wheel let a character travel at absurd speed.

With that many reports, triage was unavoidable. Everything went into a spreadsheet with a severity score from one to five, where one covered harmless visual glitches and five covered anything that broke the game outright.

Ranking them is what made the pile survivable. The worst problems got attention first, while there was still energy left and before "it will probably be fine" started sounding reasonable.

A fix is not proof of health. Some bugs took minutes; others took days to reproduce, understand, and repair. The worst were the ones that looked solved until the pressure reappeared somewhere else in the game.

That is why the end of a project needs repeated QA rounds instead of a single sweep. You are not checking that one bug is gone, you are checking that the build as a whole still holds together, which you only learn by playing it.

Weeks in, the reports thinned out. Either the testers had caught the serious problems, or nobody could think of a new way to break the thing. Either way, the project had earned the right to cut a release build.

Uploading the final build through Steamworks is the point where the game becomes an object. It is a dull task and a strange one at the same time: years of prototypes, demos, feedback, and rewrites compress into a package sitting behind a button.

The paperwork lands here too. Keys have to be generated for friends, family, reviewers, interviewers, and press contacts, and the store page, builds, depots, and platform settings all have to agree with each other.

The odd part is the silence. Reviews, interviews, and features may be written and scheduled but not yet public. The game is finished enough to sell, and the verdict on it does not exist yet.

Releasing changes what the project is. It stops being a private problem to solve and becomes something strangers can buy, play, finish, recommend, criticize, or scroll past.

For the magnet puzzle game, the button closed three years of work. Along the way it had needed character controllers, level editing tools, interfaces, transition shaders, sound effects, and puzzles, and it had absorbed prototypes, demos, feedback, bug reports, and advice.

It had also refused to sit still. The genre focus moved. The art style changed. The mechanics sharpened. What shipped was not the original idea polished for three years; it was the result of finding out, over and over, what the game wanted to be.

Shipping makes the support around a project visible. Music, promotional art, legal work, animation help, name suggestions, code assistance, tools, and playtest notes all end up inside the thing that goes on sale.

The sources vary. Some of it is specialist work. Some comes from friends and family. Some comes from strangers willing to record themselves stumbling through a rough build. Some is one piece of advice from an experienced developer, delivered at the right moment.

That is worth saying because a small game looks like a solo act from the outside. One person may carry it, but the release usually holds a long list of help: practical, technical, creative, financial, and emotional.

Launch is not where the lessons land. It sets up the postmortem that follows: how the game sold, how players reacted, what held up, what did not, and what to do differently on the next one.

The pre-launch stretch still teaches something on its own, though. Finishing does not look like a moment of inspiration. It looks like one final feature that fits, a spreadsheet of ranked bugs, another test pass, a release build, a batch of keys, a credits list, and a button somebody has to press.

After years of not knowing, that button is what matters. It is where the game stops living in the developer's head and starts existing as a real thing other people can pick up.

In the Flockbay app, play the build and write the list of what you will not add before you show it to anyone. Then only change what that play exposed. If a new mechanic occurs to you, write it down for a later version and do not build it tonight.

The page on making a Steam game is about the destination. A start-here template is small enough to lock.