Pre-Production? Alpha? What?
Right, let me explain these milestones...
What exactly is “Alpha”?
Most players have heard of games being in “Alpha” or “Beta”, but it’s not commonly known what these actually mean, aside from “mostly done” and “definitely nearly done”, however there is more detail to these definitions. While every game project is unique, there are some terms which have become very common language, and are essential knowledge for a game producer, so I’m going to give a run-down of each of the common phases in a game project. Keep in mind, this structure is mostly relevant for what you would call a “boxed product” game, rather than the common live service model of a mobile game (or similar), and also doesn’t apply as much to some indie games which have a much more free-form development journey.
The image above shows the basic difference between boxed product and mobile game development rhythms: a boxed product gets one big launch day, so all the focus goes into this preparation of a completed, deep product, whereas mobile games will generally focus on growing the audience from smaller sample sizes, observing their player behaviours through thorough data analysis, and releasing regular updates to optimise the experience.
I will be writing a separate article discussing how a live product is studied and managed, so for now I will be focusing on the milestones that take place before any kind of launch, but before we even get into “Concepting”, we have to kick-off the project.
Kick-off (What are we making?)
This is the moment when one or more people commit to making a game. For an indie game this could simply be two friends meeting up in a coffee shop and saying “Ok, so we’re going to make a game about a tiny lumberjack. Where do we start?” However, established development studios and publishers will have a formal process in which a contract is discussed, defined and signed. This contract will stipulate the basic concept (e.g. a co-op fantasy role-playing game), the budget, a high-level schedule, key stakeholders, revenue split and any other constraints such as target platforms and IP rights. The production team will gather information to aid the pitching and contract signing, with the executive producer likely providing one of the closing signatures.
Concepting (Brainstorm the idea)
Project concepting is the short period where the team expands the initial game concept into a huge list of ideas, questions and goals that will lead towards the brief being satisfied. The key goal of project concepting is to identify the questions that will need answering ahead of the production phase, which will effectively create the plan for pre-production, where the questions will actually be answered.
Here are some questions that might be identified during this time:
What is our gameplay loop?
What are the key beats of the story?
What locations will we need to construct?
What gameplay mechanics need designing?
What systems will we need to build?
What team members do we need to recruit?
What outsourcers and services will we need?
This will vary from project to project, but the goal of identifying questions remains the same.
Pre-production (Answer the questions)
In pre-production your team should be answering the questions gathered during concepting. Here are some common methods the various teams will use to do this:
Competitive Analysis - Looking at other games to understand current trends in style, gameplay and design heuristics.
Create style guides - These core documents will help keep the art and audio consistent throughout the project.
Build prototypes - Programmers, designers, artists and sound designers will all need to prove out the systems they think they will need to power the game.
Prove out technical pipelines - The teams should ensure that they can author and submit assets correctly into the game through the desired tools and source control pipelines
Purchase code/asset libraries - There will likely be various libraries that the team identifies for purchase which save a lot of development time early on.
Identify outsourcing needs - All the teams should identify where outsourcing can save them time or fill key skill gaps.
Plan excursions - Some teams may need to plan trips, such as on-location research and reference gathering, or audio field recordings.
Draft up schedules and budgets - The team should be starting to reckon with how much money they each have, and how far it will stretch.
Pre-production is arguably the most important phase in the whole project, as it is the last opportunity to define your direction before you ramp up the size of the team, and accelerate the work. If you accelerate the team without a clear direction, you will burn through time and money without making any progress towards your goal, so it is often better to take the extra time and ensure all the key development questions are answered.
Production (Make the game)
Production is when you stop brainstorming, settle on a plan, and get on with it. You’ve drawn up all your plans, listed up all your features, you’ve got a schedule ahead of you that may stretch on for years, and somewhere at the end of it there is a great new video game waiting to exist. The designers will be blocking out levels and fleshing out the mechanics, artists will be building assets, programmers will be constructing the systems and so on. The production phase is a like an assembly line, and it’s the production team’s job to keep that assembly line running for as long as is needed; it is rare for a non-mobile game to be built in less than two years, and very common for larger games to take 4 years or more for completion, with production being the longest phase.
The producer’s main responsibilities will include tracking the tasks, measuring and reporting on progress, and flagging up potential risks. Also, if your team has a problem, it is your job to see that it is resolved quickly, and to put processes in place to prevent it from recurring. Producers should also be keeping tabs on the health and mood of the team; production is a long haul and you will need to make sure your team can sustain their output without getting burned out.
The production phase nears its end when the majority of features and content have been completed, and then you are ready to proceed to alpha.
Alpha (Polish it)
By the time you reach the famous “alpha” you should effectively have a finished game, and now is the time to polish it and start preparing it for release. During alpha the team will be looking at artistic polish, audio polish, and final game balancing, much of which will come from feedback from leads, directors, publishers, and even the public; many studios invite a number of players to participate in a “closed alpha” in which they sign an non-disclosure agreement (aka “NDA”), are given a license, and play the game, providing feedback en-masse to the community team. Producers should note that the alpha phase can be quite challenging for the team emotionally, because it means time is running out, and the team will have to start turning down opportunities. The producers should regularly provide the team with a clear view of their remaining time and agency, so they can prioritize their best remaining ideas.
Alpha is also when any text, voice and images for translation should be sent to the localization team so they can begin the huge task of re-creating your game’s content in different languages. There will likely be some text polish and vocal pickups still to come, which will need to be sent along later. Meanwhile, the QA team will be running meticulous sweeps of the entire game, testing every feature, every map, and every line of dialogue to verify that the whole game is functioning as the developers intended. This will be generating a huge list of bugs for the team to work through in the beta phase.
Beta (Test it)
The time for polish is over. This is the last stage before you wrap up the game and release it. By the time you reach beta, the QA team should have verified that all the major features of your game are working as intended, and they will now be trying to break the game any way they can. During this time hundreds and maybe even thousands of bugs will be created, prioritized, fixed, and waived. The creative teams will mostly be off the project, and anyone remaining should be focused purely on fixing the bugs that come in. Producers will need to support the bug pipeline, ensuring the QA teams have regular builds, checking that everyone is aware of the bugs assigned to them, and chasing whoever needs chasing to make sure no bugs get stuck in the pipeline. Producers are often the ones prioritizing the reported bugs, balancing the impact on the player with the risk of the fix, trying to ensure the teams’ limited bug-fixing time is spent in the best way possible. Additionally, the last of the text and voice content should now be locked and sent to the localization team for translation.
Some games also run closed/open beta periods with some of the keener members of the public. This is not so much about generating bugs (your QA teams should be handling that) but helping to prioritize them, as the ongoing feedback from the players will highlight which issues they are most concerned about. Some of these issues will be about game balancing, and the design team may have opportunities to fix a few numeric game elements to improve the way the game plays (e.g. weapon damage values, ammo quantities, cool-down timers on abilities etc). This feedback will generally be gathered and reported by your community managers, but production may have to help convey the information to the design and QA teams.
When the release approaches, the production and QA teams will identify a build that is good enough quality to release, and they will prepare this build for the last stage…
Finaling (Wrap it up)
Once a release build has been identified, you are now in the finaling stage. From this point, if nothing goes wrong, you now have the game that will be sent out to a world of players to enjoy. Your QA team’s testing will now be purely focused on the specific criteria for your release platform. For example if you are releasing on a PlayStation console then you will test against the latest Playstation release criteria, so that their own team will find no problems, which could delay the release and cost extra money.
Once your QA team signs-off the build you then hand it over to the release manager/team. They will run their checks on the build, and upload it to the platform, ready to be enabled on release day. We’re almost there…
Release (Ship it)
With your final checks complete, it’s time to ship! This used to mean sending packaged games to high-street stores to be ready for release day, but in the world of digital games it simply means “turning it on” in that platform’s online store. Now players will be able to purchase it, download it and start playing your game. Some of those players may have already pre-ordered and pre-downloaded the game ahead of release day, depending on the release strategy.
To coincide with the release the marketing teams will be flooding all the social media and store channels with content to celebrate and publicize the launch, so that everyone knows you’ve arrived. If you provided any early builds to reviewers, they will now publish their reviews to various websites, magazines and video channels. Meanwhile, the community and QA teams will all be on high-alert, watching the forums and social media channels for any problems that players are having getting access to the game. The producers will be supporting these teams on gathering issues and preparing the live teams to work on hot-fixes. They will also arrange the project post-mortem and, of course, the wrap party!
Congratulations! You’ve shipped the game! It’s over…
Live Content (Retain the players)
…well, to be honest it’s never really over. In the days before the internet, shipping the game generally meant the end of the work on it, and you would set the team to work on the next one. Over time some games would start to do mission packs, map packs and expansions, but these would be another disc entirely. I remember buying additional levels for ID Software’s Quake, and extra missions for Westwood Studios’ Command and Conquer: Red Alert. Nowadays this is routine; nearly every game release will have some kind of follow-up or DLC, ranging from bug-fixing patches, to additional missions and levels, to new multiplayer characters, to cosmetic items for purchase and to new seasonal events for the community.
As mentioned at the top of this article, for live games (including most mobile games) the day of release is only the beginning; as the players arrive and start to explore the game, the shape of the experience starts to truly form for the first time, and the teams will be watching all the analytics, forums, and social media to figure out all the tweaks to keep the momentum going, and to find that sweet spot where the players will never get bored of your game.
Some producers will be working with these live teams on the bug-fixing and patches, helping to identify priorities, keep communication slick and efficient, and help to keep the community supported by the dev team. Others may have moved on to the next piece of DLC, and will be back in pre-production with the development team on something new.
Recap
As a summary for this article, I’m simply going to list the project phases and the purpose of each, as you will likely need to teach this to your teams and developers many times during your career:
Kick-off: What are we making?
Concepting: Brainstorm the idea
Pre-production: Answer the questions
Production: Make the game
Alpha: Polish it
Beta: Test it
Finaling: Wrap it up
Release: Ship it
Live Content: Retain the players with sentiment/data-driven updates
If you are new to the world of game development, hopefully this will have answered your questions, and now you can set out on your own journey to launching your dream game.
Outside of his day job as a game producer, Doug Pennant is a writer and speaker with a dream of growing a healthier and more confident game industry.
Subscribe for weekly game production stories, tips and advice.
