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.
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
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!