One topic that is often discussed, with reason, while discussing video game creation, is production pipelines: the steps and milestones you should follow to ensure smooth sailing toward a solid release.
Games, like any creative endeavor, are naturally prone to unexpected developments: we are all too familiar with games being delayed or straight out canceled. Unlike more traditional software development processes, game developers cannot simply follow a pre-established roadmap and expect to stick to it and ship as planned. Every game must find its soul, what gamers call “the fun”: the magical ingredient that will make everything click together, and this elusive goal cannot easily fit in a 2-year retro-planning.
This reality brings an enormous amount of chaos, and a lot of uncertainty, in the development process. Shipping a game takes nothing short of a miracle, and I have never heard of an easy, straightforward development (even ‘simple’ reskins, straight porting, remasters, or asset flips, bring unplanned surprises).
It then makes perfect sense to try and control this chaos: throw an army of producers, pipelines, and processes at the game, and try your best to stay on course. This approach usually tends to be met with skepticism and dubiousness by designers and creatives: how can you put a time and cost on a creation? Or break down an art piece into stories, weights, value delivered, and sprints?
Well, I thought like this for many years and gave a hard time to my producers before realizing that a proper production pipeline, and the milestones I would be passing, actually structured my creation process. It always improved my designs drastically and helped me get out of the endless cycle of iterations. Even as a solo dev, putting together and sticking to such a pipeline (even drastically simplified) brings structure, and ensures your development is mindful and building on strong bases, one milestone after the other.
In this article, I will break down what to me is a classic, efficient production pipeline, and discuss its various milestones: What should they contain, what should they not, what can they tell us about our designs, what are the risks associated with each of them, and overall open the floor to how we can improve this process.
A Typical Production Pipeline
Every game is unique, and slapping a one-fit-all approach to a production pipeline is dangerous. That being said, our industry tends to like the 2 to 3-year productions (enough to produce solid content and innovative games, not long enough to freak out investors, raise your break-even to impossible heights, or risk missing a trend). Companies also tend to agree on some generic milestones, so this is what we will be considering for this article:
These 2 timelines represent what I consider to be a great start for a video game pipeline:
- First, the Conception phase: an exploration period, here to clarify the direction and promise of the game.
- Once the game’s vision gets clearer, a small and focused Pre-Production will refine topics like scope, pipelines, core gameplay, and feasibility.
- Then comes the actual game Production, where most of the game’s content is created.
- Finally, a healthy Polish period, clearly separated from the Production, to bring it home.
Of Note: every studio will have their own Pipeline: Milestones (Beauty Corner? First Playable (FPP)? Demo?), Phases (Pre-Alpha? Content Lock? Gold Candidate? Day1 Patch?), and Timeline: do not be phased by it as they all roughly translate to the same logic and adapt to different projects and teams (size, structure…).
Flexible, Low-Cost Conception
One thing you may have noticed is that I didn’t put a timeframe on the Conception phase (the timeline starts at M+0 after the Conception Phase). This is done on purpose as Conception is the most chaotic and unpredictable phase of a game’s development. Usually done using very small, surgical teams, often during the Polish phase of the previous game of the studio, they can take a few weeks up to several years (not recommended, but not unheard of). Conception usually ends with a “Kick-off”, sealing the deal on the game’s vision and officially starting the game development: the team would then slowly grow to its cruising size and the game would start taking shape at an exponential rate. This is the reason why I like not to consider it in a typical game timeline, but feel free to disagree.
It is quite common in big studios to have multiple games in Conception at the same time, a cost-efficient way to explore multiple directions before committing a studio to a direction for the next years.
Laser-Focused Pre-Production
Another interesting point is that even if the Production phase doubled in size between the two scenarios above, the Pre-Production phase stayed constant. This take isn’t unanimous but is an important one for me: too often, teams use Pre-Production as early Production, jumping into content creation and hitting walls later on. Pre-production must stay contained and as laser-focused as possible: it is here to confirm that 1) your team has the technical, artistic, and workload capabilities to make this game, 2) to prove that your game’s vision and core loop are valid (will the game be fun?) and 3) to define the scope of the Production phase.
Scope-Aware Production
The Production phase will be the longest of all: it is during this phase that most of the game’s content will be created. The main danger during this period is Scope Creep: Pre-Production concluded on a clear and actionable scope, but video games being video games, this scope will continue changing during Production: new opportunities, Playtests results bringing new considerations, great new ideas… I’ve never seen a Pre-Production scope being the final one, and it shouldn’t: great opportunities arise, and acting on it may greatly improve the game! But this is also the main reason why games get delayed: if new features go into the game, some of the current scope must go out of it. Refining the scope, trimming the weeds, and crystallizing the core experience will be the main challenges during Production. Be smart about it!
Healthy Polish
This point will sound like a no-brainer, but I have yet to find a team that managed to respect it: it is critical to leave a healthy buffer at the end of a production, where the entire team can be focused on polishing the current content instead of producing more of it. Usually, this phase is used as the buffer for all the slip-ups that happen during production and is almost completely eaten. This is a mistake, do not do that (yet I keep doing that most of the time -_-‘): prefer to cut some content or features that couldn’t fit Production and properly polish the existing. This is often the difference between a great launch and a bug-riddled mediocre one that leaves you scrambling for months trying to appease grumpy players.
That’s why the Polish phase of my timelines lasts for 6 months so that even if you waste 2 months of it for extra Production (because you won’t resist, been-there done-that), you still have 4 solid months to make it work!
But enough of this: this is a design blog after all, and I’m fairly sure I lost quite a few readers already (though this is a fascinating discussion that I am more than happy to continue on our Discord!). So let’s now focus less on the phases themselves, or their duration, and more on the key deliverables of this production pipeline, and I will focus on 4 of them:
- Prototypes / Proof of Concept
- Vertical Slice / Horizontal Slice
- Alpha / Feature Complete
- Beta / Content Complete
Prototype(s) / Proof of Concept
Prototypes are a big topic: what should you prototype? How much effort should be put into one? Is it always low-cost or some prototype should try and shoot for more visual fidelity and polish? When to stop?
Well… It all depends on what you want to prove!
- Experimenting with a combat system would require quite an expensive prototype: a basic character, specific 3Cs, a Gym to test, and few enemies or dummies to fight against.
- Prototyping a progression system could be as simple as making a physical prototype, using index cards, like a board game.
- Proving an art direction could be done with mock game screens or a demo scene with unique shaders, materials, and assets.
- Validating a narrative tone, or mood, could be done using a visual novel: a few key arts and dialogues, or a cinematic quickly put together.
- … The possibilities are infinite and not limited to what can be done in-engine!
In the end, choices will have to be made. What aspects of your game must be proven, be it because they are very novel, a challenge for your team to create, or an element so central in your core loop that failing to deliver on it would jeopardize your promise?
In my current game, Snackbar, we identified 3 critical topics to test:
- A polished, approachable combat system: being a very small team, making a compact, yet very juicy combat system is a challenge. It is also one of the key aspects of our game promise. We needed an in-game prototype! Using sprite banks to put together enemies quickly, and grey-boxed levels, we put together some of the 3Cs foundations and iterated directly in-engine.
- An evolved dialogue system: our game will come with a whole bunch of text to read, mainly through dialogue: I needed to find a UI representation and UX paradigm that ensures a pleasant and immersive reading experience. For this one, I went for an Adobe XD prototype: fast to iterate and very close to an in-game experience (it supports gamepads).
- Finally, our game innovates on the cooking section by proposing a micro-gameplay centered around a deck-building mechanic. This is a novel approach (no real benchmark) that naturally imposed some experimentation. Before even trying to represent it visually, I made a physical prototype using blank playing cards (a cheap component), which I later transformed into a Tabletop Simulator Prototype. This allowed me to experiment with many rulesets (currently at iteration 8!) at very little cost.
In the end, all these prototypes and research should work towards the proof of concept of your game to enter Pre-Production:
- Is your game vision consistent, novel, fresh, and/or exciting?
- Does your team have the capacity (number, capabilities) to realize this game?
- Are the most dangerous parts of your promise de-risked as much as possible?
- Are your systems and core designs flexible enough so they can be built upon, reworked, or reshaped easily without endangering the project?
Do not underestimate this phase: making prototypes, iterating on them, throwing them away, and making new ones is cheap and fast, especially compared to the cost such decisions will have during Production when a full team will be spitting content in a constant flow and when shifting production will be close to impossible (or incredibly costly both in terms of time and money).
Vertical Slice / Horizontal Slice
Let’s imagine that you have been working for some time on your game, and during the “Kick-off meeting” your project (thanks to your prototypes) has been greenlit and is now “go-to-production”. Great news! Your game shows promise, it seems viable (money, time, resources, market), and you are ready for the next step: Pre-production.
This is the moment where, with a bigger team (but usually not the full team), you will be tasked to “prove the fun” on the game scale, while also solving all the biggest questions of the promise. At the end of this Phase, you and your team should have a crystal clear vision of the game and can hammer at the content without thinking (too much) anymore. Or at least this is true on paper! But we will get to that.
The deliverables for the pre-production could take 2 forms: the most well-known Vertical Slice, and its lesser-known sibling, the Horizontal Slice:
If you are not familiar with these terms, here’s a breakdown:
- A Vertical Slice takes a small slice of experience from the full game (20mn to 1h depending on the game): this slice will be as complete (no missing core feature or content) and as polished (no placeholders, first balancing) as possible. The rest of the game, outside of this slice, will be ignored: usually all side systems, onboarding, end-game, etc.
Example: If you were working on the latest installment of the Call of Duty campaign, a Vertical Slice would represent one of the game’s missions or even a few checkpoints of one of these missions only. No progression systems, no unlocks, no menus… Instead, only a few weapons, enemies, and tools, and a very contained level design and level art.
I strongly suggest putting your Vertical Slice right after the game onboarding (cf. above graph): this is the first “non-guided” experience (aka ‘Real’ one), but early enough so little systems suffice and the core of your experience can be tested. - A Horizontal Slice is also taking a slice out of the game, just a different one. Instead of focusing on a Release-quality micro-experience, it will focus on representing the entire game in an extremely rough state: the game’s entire loop and all its core systems must be present, and ‘testable’ in their bare form, but no effort will be put in providing polished content or a really “clean” experience.
Example: If you were LocalThunk, working on Balatro, you could very much want to assess the replayability of the game on long sessions, with a hundred or more jokers, full random runs, and all systems present, instead of the same “1 run, 5 jokers” loop. In this case, you would focus your efforts on a Horizontal Slice, with barely any balancing, no Juice, and maybe even no art, just to try the full-scale game engagement and retention before investing in the production of any proper content that may be discarded.
Why Choosing a Vertical or Horizontal Slice?
In 90% of the cases, you will choose a Vertical Slice. Why? Because a Vertical Slice lets you:
- Prove your pipelines (art, tech, design…) from start to finish, ensuring that you have as little unknowns as possible regarding producing content.
- Produce release-level content on a small scale, which lets you project on the cost of scaling this for the entirety of the production. It’s an invaluable metric to enter production confidently.
- Creates a small, contained, finished product: you could use this Vertical Slice to convince investors, showcase your game at conventions, create a demo for your brand new Steam page, or organize playtests with external players.
Most games can follow the “if it’s fun for 20mn, it will be fun for 20h” logic: this is the approach we are taking for the game we are currently working on.
Now, this is not true for all games: extremely systemic games (engine-building games, CCGs), for example, but plenty of other genres (Metroidvania?) may not shine much with so little content and systems, and without having players projecting their experience on extended play sessions: opting for a Horizontal Slice may be the soundest decision to properly judge the overall player experience. It is way rougher, less player-friendly, and will prevent you from using this for the other purposes listed above (apart from having a group of players that can see past this, like our community).
It is worth asking yourself this question while developing your game, as this decision may truly help you while moving into the Production phase.
Alpha / Feature Complete
The Production Phase is slightly more peculiar, as it contains 2 distinct key deliverables. The first one is often referred to as “Alpha”, though I prefer the more straightforward term of “Feature Complete” and usually happens at around 2/3rd of the Production phase.
This deliverable’s content is pretty straightforward: every single feature of the game is in the game, fully developed: menus, UI, progression systems, weapons and combat systems, biomes transition, analytics, loading screens, tooltips and onboarding, game credits, accessibility options, adaptative music, rumbles, boss fights logic, randomizers, player abilities… Everything! The content is not fully there, and much is still in a pretty rough state, but it exists and it is testable.
The goal of this deliverable, and why it is important to try and get to it as soon as possible is to raise the final flags, and solve the last unknowns: it is very easy for systems not to fit with one another, create unforeseen issues, or just not performed on the game’s scale as it should. Typically, this is one of the reasons why games get delayed, and why every production pipeline focuses on features before focusing on content. Content is safe, content is plannable without (much) surprises. But features, and the final player experience, aren’t.
By Feature Complete (or Alpha), you should be able to run your first full-playthrough playtests without much player assistance and to project fully on a multitude of metrics: player engagement, repetitiveness, short-medium-long term motivations, difficulty, complexity and onboarding, and total game time.
Beta / Content Complete
Finally, at the end of the Production phase, is the last big deliverable of the project before Release: “Beta” or, as I prefer, “Content Complete”.
By this time, not only every feature but also the entirety of the content is in the game. It is a finished product, still with rough angles, but a finished product nonetheless. This build is the easiest to work with it has ever been: it could be used for Beta tests, “Friends & Family”, and possibly even ready for a Steam Early Access (though I need to warn you, EA these days means nothing like the EA from the past and is a dangerous game to play).
At this stage you should focus on identifying where are the rough angles of your game: maybe a segment of your game falls flat and is churning hard, or a build is completely OP, or a system is considered subpar by players and simply ignored. Maybe your players missed a critical point of the game due to weak onboarding and are ruining their experience, or a lack of S&F creates blockers for players and excessive frustration… Whatever it is, your game will for sure have problems, and this is why identifying them AND having enough time for polish is critical. Not everything can be flagged by QAs (after all, they know the game by heart at this point, and a brand-new player experience is difficult to replicate).
This transition to Polish at Content Complete is also a good moment to turn to extreme agility: ship fast, often, and be surgical on your tweaks and improvements.
Many studios either minimize this Polish period, leaving only 2 months or so for bug-fixing or shoot themselves in the foot, by having to cancel most of the Polish phase due to content still not being ready (and their inability to cut content). Also, this will be the moment when certifications are happening, and if you are targeting multiple platforms at Launch (particularly if you have console makers involved), you will become so swarmed that Polish will be forgotten in light of more pressing urgencies. Be very careful, as usually a great Launch (and a few extra Metacritic points if you care about it) are at stake here.
Extra Glossary
As I told you, every studio has its pipeline and way of doing things, and the terminology used in milestones can vary widely. Below are some extra terms you may encounter. Do you see extra ones I should add? Ping me!
- Beauty Corner: or beautiful corner, is a small area of the game (a room, a settlement, a bit of forest, a vista…) showcasing how the game will ultimately look like. Not too far from a Vertical Slice, but for the art and LD pipeline, it can be helpful in selling the game to publisher, nailing an art style “in-engine”, or challenging the processes and cost of developing a contained art segment of the game. Usually, Beauty Corners are not playable.
- Gym / Test Room: not a deliverable per se, but some studios consider them as such. These are test scenes, in-engine, used to demonstrate, prototype, and experiment on a specific game aspect (combat Gym, Level Design metrics, etc.)
- FPP / First Playable Prototype: a very common deliverable. Consider an FPP as the aggregate of all the prototypes done in Conception, into a single global proof-of-concept prototype. They are usually used as the deliverable to enter pre-production. Very useful in big games where many separate prototypes aren’t sufficient to confidently approve a game’s direction.
- MVP / Minimal Viable Product: a deliverable that is not part of our industry. Compared to other IT industries, it is very complicated to ship a barebone game and improve on it Live. I have seen this term used to replace the FPP, or to guide prototypes on specific topics, but this is a rare occurrence. I would suggest not using it as it can be misleading.
- Pre-Alpha: used often as the deliverable’s name for the Pre-Production deliverable. I prefer the term FPP as it is more relevant to our industry. I also saw it used for many other Pre-Production or early Production milestones, often to say “ignore the rough patches” to investors, publishers, or players.
- “Locks” (Art Lock, Audio Lock, Design Lock, Animation Lock, etc.): these are many terms used as lesser milestones close to release. These Locks usually happen on massive games that imperatively need to stop production in a contained manner to stabilize and secure a game before Launch. When a department is in “Lock”, it usually means that nothing gets produced anymore, and the only work done is final debugging and fine-tuning realized in an extremely controlled manner and triple-checked. The mother of them all is the final “Content Lock”, the bridge toward Certifications.
- Candidate / Rollout / Gamma, Delta…: as a game is getting close to release, particularly when this game is multi-platform (and involves console makers) it needs to conform to massive lists of requirements that will need to be approved by third parties. Studios then create “Candidate Masters” that hope to become Gold. Some studios call this period the Rollout period, others continue the Greek alphabet after Beta… I like the term Candidates, it’s clear for everyone.
- Gold: when a Candidate build passes all platforms and publishers’ requirements, it becomes Gold. This is the version of the game that will be printed on disks, or released on digital platforms. Legends say that the term Gold refers to the color of the disk the final game was printed on (though I tend to believe it the other way around, as I always had Gold Master disks as plain CD-ROMs).
- Zero-day / Day-one patch: though we are crossing into Post-Launch territory (I have a great article on this here), the Day-one Patch is often the last milestone before Launch. Once the game is Gold, and is being distributed/deployed, we are still 2 months or so before the official release (deploying, manufacturing, and shipping games take time), which is 2 months more available to work on the game! With the current technology allowing us to push patches to players, it is common to use these extra months to fine-tune the game even more and deploy an update that players will download the day of the Release (“day 1” of the release). Just make sure not to be too greedy with it…
To conclude this article, my key pieces of advice would be:
- Even as a solo dev, a pipeline, and timeline can help you structure your development and not end up blindsided by issues you haven’t foreseen.
- A production Pipeline is not playing against creation: use it to your advantage, as each milestone will funnel you toward releasing the game, and it’s a good thing!
- Be open-minded when you are prototyping: not everything requires a prototype in-engine, and sometimes a deck of cards and a stack of Monopoly money is all you need.
- Vertical Slice or Horizontal Slice: choose carefully which one is more suited for your game, but also what you choose to include in these slices. They can be an invaluable tool (even sometimes for PR and marketing!) if properly scoped, or a fake sense of security that later backfires if badly constructed.
- Focus on shipping all your Features before shipping all your Content: this is where the dangers lie.
- Give yourself enough time for Polish! Whatever time you give yourself won’t be enough in the end, and you’ll regret not cutting a few more features to ship a cleaner, more polished game.
Good luck out there and, as always, let’s continue the discussion on our Discord!
Do you want to get regular quality articles on Game Design and join an awesome community of devs and designers on our private Discord to discuss design, learn, and review each other’s games? Then consider supporting GDKeys:
