How To Use Phases Of Game Dev To Your Advantage

Read Time: 6 Minutes

The Game Development Life Cycle

What is the progression of a game from idea to finished product? How can we use what we know about that progression to spot problems before they happen? Let’s talk about it.

Game development is split into a series of phases. Games go from ideation or prototyping, to pre-production, to production, to post-production, and then finally to sustainment or post-launch.

Some people only use 3 phases (usually pre-pro, prod, and post-pro), some have a ton more, it’s all fine as long as your studio knows what they mean. No matter what you call them, you start with a lot of uncertainty and creativity, and you end with a concrete shipped title that either does or does not need ongoing support.

Each phase has a different purpose to it. Here’s an oversimplification: 

• Ideation (prototyping, concept, etc.) is about discovering a game idea that might be worth building and fleshing that out a bit.

• Pre-production is about showing that the game idea is something that could be built AND that we want to build it.

• Production is about building the game.

• Post-production is about finishing and polishing the game.

• Sustainment is about maintaining the game as players play it.

Many variables change as you move through the phases. Here’s a few:

• Cost / Burnrate (typically goes up)

• Size/Scale of Team (typically goes up)

• Uncertainty of Game (should go down, sometimes does not)

• Quality of Experience (typically goes up)

• Work system complexity (typically goes up)

• Time left (typically goes down)

• Cost of Failing (typically goes up)

• Cost to pivot (typically goes up)

The Value of Having Targets

Alright, let’s get into the good stuff.

In each phase and depending on a bunch of contextual decisions (genre, quality bar, timeline, market, platform(s), etc.) each of the variables I mentioned above has a range where it should be, and a range where it probably shouldn’t be.

It’s not hard to guess - at least roughly - what’s “healthy” for each variable. If you can notice a particular variable is outside of the “healthy” range, that can warn you of problems and even help you avoid them.

For example, in Ideation for most games, I would expect “Size of Team” to be between 1 and 15 people. In Post-production, I would expect the “Cost to Pivot” to be very high and that to not be a problem. 

BUT, if “Size of Team” is 100 in Ideation, or the “Cost to Pivot” is very high in Ideation, you’re probably in trouble and experiencing pain. 

If you realize you’re pushing towards or past 15 people while still in Ideation, having someone or something sound an alarm can help with being more careful in hiring and at least make people think twice before doing something potentially unwise.

Two things to note:

1. There is no one size fits all answer here. The variables for an indie mobile game look very different than for a AAA PC/console game. Size of team could be different in those scenarios by an order of magnitude. Relying on generic answers will hurt you. You have to think it through in your specific context.

2. Most people don’t think about this at all, and end up way outside the “healthy” range on one or multiple variables before realizing what they’ve done, to the great detriment of their game and studio.

Making this Practical

I want you to do an exercise right now as you read this.

Step 1

I want you to think about what phase your game is in. Are people acting like the game is in production? Does everyone know it’s in ideation? How much alignment is there?

Step 2

Determine what phase the game SHOULD be in. You can use my descriptions of each phase from above or some other method, but make a call about where the game really is. 

A guideline for this: since different parts of the game can be in different “phases” simultaneously, where is your core game? If it’s a story-driven game, you better have a really good handle on that story being compelling before stepping forward in phases. If it’s a combat-driven game, that combat better be dialed in before you enter production. 

Don’t let the fact that art is doing some high quality work trick you into thinking you’re in production when the fundamental experiential elements are still undecided and/or unknown.

Quick Sidebar: if where people say the game is and where the game actually is do not align, that’s a flag and it means you or others are misaligned and probably have mismatched expectations for what development should look like. Worth solving.

Step 3

OK, think about the following variables:

• Size of Team

• Uncertainty of Game

• Quality of Experience

• Cost to Pivot

Map the game you’re working on against each of these four variables through the phases of development. Avoid being anchored by your current reality as best you can. Provide a range (it’s ok to use subjective language) for each variable in each phase. It may look something like this:

Step 4

I want you to compare the reality of your game today against what you would have expected. Does it line up? Is the level of uncertainty, the size of the team, the quality of the experience, and the cost to pivot where you’d want them to be?

If so, great! You can go through and look at other variables to see if anything else pops out as incorrect.

If not, there are probably consequences already occurring within your org. People might be reacting to them, talking about them, or trying to work around them.

Step 5

If things didn’t line up, share what you’re thinking with people around you. Talk to your manager, or peer leaders. Check in with your team, see what they say. 

Especially if you’re early in dev, you have a chance to course correct. Even if you think everything is fine, you might realize there is misalignment and that’s messing with expectations and development.

A Warning: just because you are outside of the range doesn’t mean anything is necessarily wrong. If you expected to be 20 or more people in production, and you’re at 18, that doesn’t mean you need to flip a table. But it can be an indicator that something about your assumptions isn’t lining up to reality. You want to dig in and understand that better.

The Fatal Cascade of Game Dev

The most foundational variables that drive the phases of game dev are:

• Uncertainty of Game

• Size of Team

• Quality of Experience

• Money Remaining

Most dev teams can easily tell you the size of their team and how much runway they have left. That’s good, but...

…I have found misalignment about the amount of uncertainty in the game to be common. 

Uncertainty affects the game and development in a ton of ways. If you have high uncertainty, you should NOT be scaling much. If you have low uncertainty (the game is well understood and good), you should not be investing in big pivots. Level of certainty impacts the questions you ask, the day to day style of collaboration and work that is most effective, and how “long-term” you need to be as you build things, as well as what’s an appropriate quality bar to hit.

Keep an eye on the level of uncertainty. It’s a pain to track because it’s subjective and difficult to measure, but it’ll blowback badly if you don’t keep the team on the same page. In my experience, I’ve maybe seen one dev team that was pretty well calibrated on uncertainty, one (maybe two?) that were overly cautious (they were acting as if things were less certain than they were), and all the rest that have been overconfident (acting as though they knew more than they did.)

Overconfidence leads to asking questions about the next phase before answering questions from the current phase. This skips learning and assumes unvalidated answers. Overconfidence leads to scaling the team up. It leads to less of a focus on playtesting because you’re too sure you’ve got something great. It leads to people focusing on execution of work instead of asking questions about the unknowns. It leads to divergent work as unanswered questions get answered differently by different people.

Scale (increasing the size of the team) is perhaps the worst consequence of overconfidence, because it drives far more than people want it to. 

As your scale increases, your burnrate goes up and the remaining money goes down faster. Additionally, there are more people to align. The organization gets more complicated, the work system gets bigger, overhead then starts to rise, people end up further away from each other, and maintaining visibility across the org becomes a challenge.

An overly large team size will reduce efficiency across the organization as people try to manage around the misalignment, overhead, and slowness that results from scale. You aren’t in a speedboat any more, you’re in an oil tanker. It can move a LOT of stuff, but it doesn’t turn well, and since you’re overconfident, you probably don’t even know you’re headed in a bad direction.

Because you weren’t as sure as you thought you were, you’re now finding that new people don’t make you faster. They seem to make you slower. You wonder why - despite having twice as many people - you can’t seem to keep pace with yourselves from a year ago.

This reaches its final form when it starts destroying the quality of the game experience.

“Quality of Experience” is what game dev is all about. It’s also what breaks down way before we’d like. 

More than scope or any other part of the “iron triangle”, quality is what tends to give way to make everything else work. But, like uncertainty, it’s subjective and difficult to measure. This makes it hard to create good accountability around it - especially once you abandon or stop paying attention to internal and external playtests. You just don’t have time to do or react to that any more with all the work you need to get done.

I want to be super clear here. When I am talking about “quality of the experience”, I do not mean individual craft quality. Often, when everyone goes heads down to get more work done, the individual disciplines can get obsessed about their craft and create some really cool assets. 

But the game as a whole? That’s left for someone else to figure out. Everyone is focused on their own piece because the whole was left behind long ago.

Unfortunately, the quality of the experience is not dictated by the visual fidelity of the assets or the cleanliness of the code. Amazing assets can be brought together to create a terrible game. And that’s all the more sad because you spent even more time creating amazing assets only to have it all fall flat.

In the end, often even the quality gives way, as everyone begins rushing to dig themselves out of the hole, never addressing the fundamental alignment problems that got them there in the first place.

Wrapping Up

To recap, studios frequently cascade from overconfidence (not taking uncertainty and unknowns about their game seriously) to scaling too quickly (not recognizing how painful scale is) to reducing the quality of the final experience (not realizing that you can’t work your way out of an alignment problem).

We’ve referred to this in the past as the problem of “rushing to production,” It is everywhere.

To avoid wrecking the experience late, keep a strict eye on how much uncertainty is really present, and how big your team is. Stay grounded in reality.

What about you? How’s your team doing? Do you feel like the game and the phase you are in match? Shoot me a reply to let us know, I’m genuinely curious about your experiences with phases in game dev. It’s not an easy thing to get right!

Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].