Production and Post-release

The output of a successful pre-production process is a playable game design. This might exist in fragments of different prototypes, and some will probably exist only on paper. Bearing this end in mind can keep focus on the importance of high value prototypes during pre-production, even if it sometimes feels like it’s at the expense of the game.

Determining when pre-production is complete can be tricky. In commercial games, this assessment is often done via a specific milestone known as a “vertical slice.” The rough definition of vertical slice is that some subset of the final game now exists, which is fully reflective of the final product and can be played as such (this is the “vertical” part). The “slice” part references the idea that this might represent only a tiny amount of the game’s final scope in terms of content. 

In smaller projects, and particularly games for impact, a true vertical slice tends to be something of an unattainable luxury. Having enough bandwidth in terms of asset creation in particular (art, animation, sound, and music) can be challenging when producing a vertical slice. A different metric, particularly for a game designed to create change in the player, might be that the game itself exists in a form that can be tested with players, and some kind of measurement made in terms of its effectiveness (even if that measurement is just a simple survey or interview).

Again looking at grantee Crab God, by Chaos Theory Games, in their pitch they shared a trailer of their prototype and a playable demo. 

Chaos Game Theory Studio's prototype trailer submitted in their UFH grant application

Once pre-production is complete, the process can become very different. During the production phase, the speculative and experimental mode of work used during pre-production is retired in favor of efficiency and quality.Most game developers will tell you that finishing is the hardest part of game creation. Indeed, a lot of projects never quite get done, and often this is because the work continues in a pre-production mentality: continuing to experiment and add features and ideas indefinitely. Sometimes this is fine. Particularly for personal projects, shifting to a production mindset might run contrary to the developer’s desire to learn and experiment. If a project targets a certain date for completion though, and especially if it has a larger team or larger scope, adopting a production process mindset can be extremely valuable.

Project management during production

While pre-production is about discovery and experiments, production is about hitting a target. Therefore the first task of production is to establish that target. Based on what you’ve learned during pre-production, and hopefully what you’ve been able to prove out as potentially valuable as a game for good, do your best to define that target now. What will be the scope of the game? How long do you imagine people playing it for? When do you think it will be complete? After establishing that target, a really traditional type of project management is often the best: 

• Divide the work into chunks.
• Estimate the time for each chunk.
• Complete the game, one chunk at a time.

The “chunks” referenced here would likely be “milestones.” Even if your process is more informal or small scale, using some type of milestone schedule can really help keep up momentum and also provides key moments for the team to pause and reflect on the progress being made.

In production, the main goal is to keep up momentum so you can get your project to the finish line. The “chunking” described above is a great way to do that, especially if at the end of each chunk there’s some accountability you’ve established for your progress.Accountability needn’t be some kind of contractual business arrangement. Any kind of check-in that occurs on a schedule, especially if it involves people other than the development team, serves as a great opportunity to ensure that the game is progressing. For example:

• Milestones make great days for playtesting.
• If there are external experts or stakeholders, share the game with them at the point of a milestone.
• Milestones are a great time to check in with your community!  

Design your own milestone systemHow you decide to form your production milestone system is ultimately up to you. You can select your own cadence, your own expected “chunk size”, how you'll share out your progress, and ideally you’ll get some feedback too.Your milestones don’t have to be all the same either. You can mix things up - maybe on alternating milestones you schedule a playtest on one and a meetup with your dev community on the other. 

Production stage of game development

One last, important note about production: if your goal is to keep going until the game is exactly as you hoped, you’ll never finish. The nature of game software is that it can be modified and iterated pretty much forever, which is both a blessing and a curse. 

There’s no magic formula for knowing when to stop. Often, designers are poor judges of what should be thought of as complete, generally always wanting to make things just a little bit better and a little bit more complete. 

An outsider is often the best resource for helping to decide when the game is done enough to be released to the world. Whoever is helping you with your milestones is probably a great resource to lean on for this. We’ll say it again: maintaining a community of fellow developers is incredibly valuable!

Give a thought to what will happen to your game after it’s complete. This guide hasn’t touched on important issues like marketing and promotion, or operating live services, which may or may not be relevant for your project. However,  even if your game is a small project, not intended to be updated, it’s worth giving a thought to how your project will live on after you’ve stepped away from it.Planning for post-release impact measurementThe most interesting measurements occur well after the game is considered complete. Allocating time and resources to do this work should be included in the game’s overall plan. This might include setting aside time and resources to modify or better collect telemetric data if data collection is part of the measurement plan.Planning for post-release software maintenanceWe recommend you create an organized archive from which you can update the game. Times change, and finding the necessary version of the game’s engine, tools, and other source materials might get very difficult or even impossible.A bug or flaw might be discovered well after the game’s release. Or maybe some small adjustment to its content will make all the difference. Addressing these issues is only possible if there is a complete version of the game’s source and assets available somewhere.The good news is, resources like GitHub make creating and maintaining such an archive far easier than it has ever been. Even if you didn’t use such a service for version control, it can make an excellent repository.Some things to think about:

• As mentioned above, a flaw might be discovered after the game has been released, and you might want to fix it.
• The game’s software platform may make it obsolete and therefore difficult or impossible to play, such as when Adobe deprecated Flash, or certain Apple updates to iOS.
• Someone might like to take the project and extend it or build on it. If you’re supportive of this, a good archive will be necessary to make that happen.
• Academics might like to check it out as part of a study.