Dec 17, 2017
The game production process commonly referred to as the production cycle, is the primary responsibility of the video game producer. It starts from the moment the game is conceived and goes on until the gold master (final release build) version hits the shelves – or your favorite digital distribution platform.
It is essential to keep in mind that every game and every studio works differently. Game production is hardly a standardized practice. Therefore, for anyone reading this from a development studio, it is likely that some of the descriptions in the article might not match 100% your particular cycle, and that is ok. Moreover, the relatively new introduction of modern software practices, such as Scrum, has started a shift towards an iterative process. I will cover both the “traditional” (noniterative) and “agile” (iterative) production processes.
Traditional production cycle
All games start as a concept that is pitched to either a publisher or the public (Kickstarter) to secure initial funding for a small core team to begin pre-production.
Pre-production
This is the time to think what kind of game you want to make, and plan how will you make it. The development team is very lean in pre-production, consisting mostly of the different discipline’s leads and a producer. This core team will decide the theme, art style, level design, game mechanics, story elements, and technology. The different leads will proceed to estimate what is going to cost to put all of this together, regarding people and money. Meanwhile, the producer will work with the leads to document game design decision, roadmap all the necessary work and note down any potential risk.
When the team feels it has nailed down what the game is and the economics of it they will proceed to create a vertical slice prototype and present it to the publisher. If the publisher likes the prototype, the game will be green-lighted. As a result, the developer will receive resources to move to production.
Production
This is where most of the game is made; the expanded development team becomes an industrial production line churning out art assets, level and character models and game code.
The producers play a significant role in production to ensure the game is fun and is not being bogged down by features that are either unnecessary, unfun or that pose a schedule risk for the project. This is easier said than done; the temptation to squeeze in a new mechanic can come from everywhere at any time – say a weekend gaming session. However, adding a new mechanic or changing an existing mechanic mid-production, can be incredibly risky and wasteful. Hundreds of previously created assets might need to be thrown away to account for the changes. As an example, imagine adding the ability to fly to an action RPG game, some of the levels and encounters might become trivial and require a complete rework, existing 3d models might also need improvements as the artists did not expect the camera to see the top of certain objects.
Production typically ends at a predefined date, usually to make sure the game is out before a financially important event. A few studios might be willing to keep production rolling until a certain level of quality is attained, but this is not the norm. Usually, the publisher and developer will decide the needed polish can be applied to a reduced team and move to Alpha testing, and thus, post-production.
Post-production
In this phase, most of the development team starts to leave and QA steps in. The objective is to polish the game and make it as stable and bug-free as possible.
The game at Alpha testing is called feature complete, all the game mechanics are locked down, but designers can still tune values and artists improve or create new assets. QA and the engineers start to hunt bugs proactively. As the game becomes more stable the leads begin to lock down entire sections of the game; the game enters Beta testing when all the game content is locked down.
In Beta, the development team is only allowed to fix bugs and optimize assets and code for performance. QA has the final say whether the game is ready to be shipped, this decision is based on the type and number of bugs remaining.
Bugs are categorized into one these three classes: Class A (Game crashes), Class B (Noticeable gameplay or graphical errors), and Class C (all others). For a game to be considered in a releasable state it must have no Class A and Class B errors – sometimes QA will allow the game to launch with some Class B errors, on the condition that a patch to fix them will be coming soon.
Console releases must pass Certification by the console manufacturer before launch. This is an extensive test of the game on the console hardware. The game can technically be resubmitted if it fails the certification process, but the financial risk of failing the test is so big that the big publishers have in-house teams to do a Precertification. This bears repeating, failing Certification is so bad that publishers will have people on hand whose only job is to do a mock certification test before sending it to the console manufacturer. Not only is the test expensive on its own, but we also must factor the cost of delaying launch for months!
Agile game development
Agile studios have the same milestones and 
production stages (pre-production, production, post-production) as traditional studios. However, agile studios iterate over the course of the project in short timeboxed periods called sprints that roll up to potentially shippable “releases”. Every sprint is a little production cycle, it starts with planning and ends with polished and optimized code and assets.
The breadth and scope of sprints and releases vary depending on the current production stage. The objective of pre-production is to keep iterating mechanics and gameplay until a fun game emerges. The objective of production is to add new features and content iteratively. Finally, the objective of post-production is to polish the game and clean up any technical debt – Technical debt is the technical term for any open bugs.
The way the studio operates also changes between phases. In pre-production, the development team is entirely agile, very lean and continuously iterating. In production, the sheer amount of assets and the dependencies this creates forces the studio to change to a Kanban / lean production methodology that is reminiscent of the auto industry. In post-production, some teams start to shut down, as features and content are complete and polished, and the remaining teams go back to agile for an iterative bug hunt.
A more thorough comparison of Agile and traditional (i.e., Waterfall) methodologies is beyond the scope of this article. For our purposes, suffice to say, that traditional development shines when there is little “uncertainty” (DLC, direct sequels, platform ports), for anything else I would recommend looking into Agile and seeing what works for your particular project and team.
