What does it mean to finish a game?  Well to me it means the game has passed the platform submission process on all the platforms you intend to deliver. Work does continue after that of course, with patches, DLC, ports to new platforms, etc, but I would consider those new phases of development. The finishing stage normally starts a few months before the intended release date, but lets start by going over the phases already completed. 

Honeymoon (Pre-production)

The world is your oyster at this point. No tech too complicated to build, no poly budgets unachievable, etc. At the end of this stage you have a game pitch someone wants to publish, a workable prototype and a rough idea of the engine tech required and the amount of content.


This is where the really complicated tech and design issues need answering. All the great stuff you hoped to do is gradually whittled down into a few core features which are actually achievable within a given time frame. This is by far the longest phase.


The definition of this stage varies from company to company but essentially the game is mostly complete. Most levels are playable. The Q.A. department starts ramping up and submitting bugs to the bug tacking database. All major gameplay questions should have been answered. Any content not going to make it to final quality should be cut early so the team can focus on polishing the stuff that is in there. By the end of this phase all content should be in and at final quality level. Bear in mind that this phase is also where things crop up like trade show demos, press hands-on time for preview articles, etc. Prepare for these in advance by planning for them and keeping regular deliverable builds.


This is it. The end is in sight. This phase varies from a few weeks to several months. The publisher has a release date in mind, the marketing juggernaut is rolling by now, missing the date is going to cost you. A lot. This is the final stretch people. Expect to be working some crunch time if you’ve been lucky enough not to have already started.

The Final Furlong

The Q.A. department at your publisher has had its hands on your builds for a while now, there are probably hundreds (I’m being kind here!) of bugs in the database. The producers start producing regular burn down charts which show the number of bugs in the system, the current and predicted bug rate (new bugs found versus bugs fixed per day) and a line heading down to 0 bugs on the day you are due to submit the build. Hint – they always look really bad at the start! Things improve rapidly as more people transition to pure bug fixing.

Typical early burn down chart! 

As time progresses and the bug count comes down it becomes more and more important to not introduce new bugs with each fix.This involves testing on all platforms, more in depth code reviews by fellow coders, and can be helped if there are automated tests available to catch obvious problems. One dangerous response to this is to try and fix bugs in a localised manner. Fixing the symptoms of a bug without understanding the real cause. While this may get the bug fixed it will very likely come back and bite you in the ass.

Eventually when the game hits 0 bugs (or more likely the bugs that remain are judged acceptable for the final product) the game will be submitted to the platform vendor. They will verify the game passes all their requirements and if so the game has officially passed! Congratulations!

Often the game will not pass first time though. The total submission time varies depending on platform, scope, time of year and even publisher clout to some degree, but will normally be less than a month. During this month the team does not sit around twiddling thumbs, the Q.A. department is still active submitting bugs. Bug fixing still continues, but on a separate branch to the submission build.

If a submission fails you will get a detailed report indicating the reasons for failure. Normally it is prudent to fix only the key issues, along with any bugs your QA dept. found that are judged serious enough. Every bug fix applied has the chance of causing unexpected side effects so these are normally applied with great care! Finally the build is ready for submission again.


As I touched on before even when the product passes submission there is still more to go! Bugs that are considered serious by the developer but did not fail submission may be applied in a patch available on the day the product ships, so work on the patch needs to be completed soon as the patch needs to pass a submission process as well.

This article was written from experience of shipping games with sizable teams – I have no idea what it’s like for indie developers but I imagine it’s similar. Please let us know about your experiences in the comments!