How To Create Effective Iterations In Game Dev

Read Time: 9 Minutes

Games are a mix of art and science. Some stuff is known when you start, but a lot of what you end up doing is based on the unique people on your team and what you learn along the way. 

Even sequel games can’t be exactly like their predecessors. You have to create new content. You’ll probably add, remove, or change features. You can’t be sure how it will all go when you begin. No matter what type of game you’re making, you need to figure things out rather than plan everything out.

And if you’ve been reading this newsletter for any length of time, you’ve heard me say this stuff before: your best shot at making a successful game is to iterate. Call it the scientific method, call it some type of cycle like OODA or PDCA or any of the other ones out there, but the point of it is to try something, see how it goes, and then try something else. 

I think most game devs intuitively understand this. However, when you look at companies in the wild making games, too many aren’t actually iterating. Even if every leader would say “iteration” or “experimentation” or “learning” is a key to success in game dev, many work in environments that discourage such learning.

Let’s talk about iteration and what it means to set it up inside your studio.

Setting Your Team Up To Iterate

Iteration is doing something, then doing it again with some changes based on how it went the first time. If you keep doing that, whether the changes are huge or tiny, you are iterating. Once you reach a place where whatever you are iterating on is “good enough” OR you abandon the effort or run out of time, you’ve stopped iterating.

Really quickly, we hit our first obstacle to setting up real iteration in studios: Large, detailed plans. 

If you are working from a big plan with all the work that you think you need to do, often iteration is not factored in. Someone asked an animator how long an animation would take for a particular asset. They got a number, they put it into the plan. This was repeated until “everything” was accounted for and ordered.

These plans assume that everything we do will get finished the first time we do it. If we’re building a feature, we’ll build it in one shot. If we’re creating a piece of content, our first attempt will be good enough to ship.

Anyone who has spent much time in game dev knows this is not how things work. In fact, it is not uncommon to build an entire functioning experience only to throw it out and start over from scratch midway through development. This is especially true early in development, when we know the least.

The game and all its components need iteration to be as good as they can be. 

To set yourself up for healthy iteration, make sure you have time in the schedule to take a shot at building the most important parts of your game, test what you’ve built, and then possibly rebuild them more than once. Less important things may not get done OR you might discover new things you need to do while learning and building. That’s normal and good. 

Recognize up front that you don’t know how much iteration each part of the game (or the game idea overall) will need to reach a good state. Some things might work on the first go. Others may take multiple tries. A lot of your devs can use their experience to guess which parts are riskier and more likely to need to be iterated on, and which seem pretty straightforward and will be ok in one shot. They won’t be totally accurate, but it’ll get you a lot closer than assuming you’re getting everything done just right the first time.

By the way, this is not the “buffer” I often see people throw into plans. That will get eaten up by things taking longer than we expect them to, especially on the first try. This is more radical, and involves acknowledging that the stuff way down the pecking order of priority is unlikely to be done ever. 

A simple way to frame this is to consider the essential elements of your game that are critical for providing a compelling experience for players. Now, assume you’ll build that whole thing 2-4 times end to end. If that terrifies you, good! If you don’t have time for that, that’s valuable to know NOW. It will help you focus on the few pieces that are most important.

This leads us to the first step of healthy iteration:

• Create a culture and environment that accepts the game will be iterated on before becoming good, and realizes not everything you wanted to do will get done because of that.

Speeding Up Iteration

Iteration is a cycle. The faster you go through that cycle, the faster you learn. If you’re in an environment like game dev where learning is important to success, increasing the speed of iteration will increase your odds of building an amazing game.

I want to look at iteration through two lenses.

Development Iterations

The first is what most people think of when they hear the word “iteration.” How long does it take you to try something new, learn from it, and get ready to try another new thing?

At an individual developer level, this might involve how easy it is to create something, put it in the build and know that it’s working, then have people playtest or otherwise interact with it, and finally decide whether you will remove or improve what was just done or start something new.

The faster an individual can iterate, the faster they’ll be able to deliver what the game needs.

A huge barrier to fast individual iteration is often tools. If the tools are unreliable, if the build doesn’t get put together very often or takes a long time, if everyone works in a silo and then integrates all at once, all of these things increase the time of one iteration and reduce the amount of valuable learning at your studio.

Engineering processes like CI/CD systems, automated test suites, and good definitions of done will help iterations go faster.

Having a culture focused on finishing work we’ve already got started, rather than starting new work will also help iterations go faster.

And as I mentioned above, tools for artists, designers, QA, narrative, etc. can be a huge help or a huge problem to moving fast and learning quickly. 

For all the people out there leading game dev, you want to be asking (or having the leaders in your orgs asking) developers how quickly and smoothly they are able to iterate. How hard is it to check things in? How hard is it to see their work either in game or a very close approximation? How hard is it to get time from the people who need to review work to actually review it?

If any of those things are hard, your devs are working slower than they could be. This can have huge consequences. Let me give you an example.

In game dev, one or more disciplines usually ends up being the bottleneck to getting things done in the game. Engineering is a common bottleneck. QA is another. 

The solution that we apply to bottlenecks is often to hire more of them (if we have the resources) or to ask them to work more (if we don’t have the resources). 

What we rarely do is ask about the state of their tools and how long it takes them to do anything. If your engineers are spending every Friday fighting the build to get all the weekly work checked in while also dealing with a ton of integration problems because they were working separately up till that point, you may not help the problem by adding more people or asking them to work overtime. Adding more people just means more collisions and more problems making builds even harder to do, while asking for overtime reduces the quality of checkins with the same effect. Sadly, most studios do both. Things get bad fast.

If you went to those same engineers and asked them what it would cost to improve the build pipeline, you might get some surprising answers that may not cost as much as you think. And if those solutions mean that you can iterate daily instead of weekly, you’ve now unlocked a LOT of learning and made life much easier for your entire team.

I’m not saying your teams will get a week's worth of work done in a day. I AM saying you might get a week’s worth of work done in a week. Because right now, you aren’t.

I’ve been focused on individual devs, but I want to scale this up real quick to talk about teams and entire studios. The iteration length for a team or studio is often gated by the frequency of playtests. The more often you are playtesting what has been developed, the faster you are learning what is and is not working.

I’m currently working with a client, and it’s predictable (and correct) that when we talk about problems, he’ll often say the answer is “to playtest more and more often.” It seems simple, but it works. It’s so basic and yet so often lost.

Many teams and studios struggle with this because the culture of the studio, or the way builds function, or how branching works, or whatever else means that playtests take a long time to set up, are unreliable, and don’t have a lot of attendance.

Any of those three problems will slow your collective iteration and dramatically reduce learning. Don’t let that happen. I’m not kidding. Fix the technology. Make playtests mandatory for everyone. Do what you need to do. 

So, the next steps to healthy iteration:

• Figure out what is slowing down your devs’ iteration time and see if you can fix it.

• Playtest as frequently as you can. If that’s not often (rough guide: less than once a week), figure out what’s preventing that from happening and fix it. 

Communication Loops

The second iterative lens I want to go over is not about the work itself. It’s about the communication loop between the game’s most senior people and the people doing the work.

You’ve all probably been in a studio or environment where a decision needed to be made by someone not immediately available. Work was blocked, perhaps you started doing other stuff, but the most important thing was stuck because no one who knew about the problem had the authority to decide how to proceed.

This is a painful thing to experience. But it happens a lot.

Often, the people who have the most decision-making authority are incredibly busy. They are overwhelmed with a million tasks; people meeting with them, stuff to create, pitches to give … and all of that pulls them away from being present for the game they are leading.

I have a lot of sympathy for leaders in that situation, but I don’t like how often the consequences of that busyness are borne by the team, not the leaders. The consequences of that delayed decision are people being unable to proceed, or making the decision only to have it reversed after a bunch of work has been done. If people aren’t “acting autonomously” or “taking ownership” this might be why.

If you’ve got senior people, let’s say the CEO or a VP of Design, and they have a huge say in the direction of the game, but don’t interact with it or talk about it to others regularly, you are going to have a slow communication loop. That leads to a slow and/or volatile development loop.

The speed with which you get key decision-makers playing the game and then communicating their intentions for what’s next will dictate how fast you spread learning and direction across your studio.

There are different ways to tackle this problem. One is to admit that some people simply don’t have time to be key decision makers on the game. They have too many other responsibilities. They need to delegate that away and accept that things won’t go exactly as they would have directed. The gain in speed can be worth that loss. 

If that is not tenable, you need to find ways to clear your schedule to have time to unblock the teams that need feedback. Another way to do this is to get really efficient in giving the feedback - but that has to be from the perspective of the person receiving it, not you giving it. 

Another thing to do, especially in multi-level organizations building games, is to try to synchronize your meetings, top to bottom. An example of this:

Imagine you’re a studio with a group of senior stakeholders who direct the game’s leadership, who directs a set of teams working on different parts of the game.

Let’s say on a Tuesday you have an “executive playtest” where all the most senior people engage with the latest version of the game. Right after the playtest they get together - perhaps with the game/design director or executive producer - and talk about the state of the game and what they think is important to do next. 

On Wednesday, the game’s leadership team figures out how that work will adjust priorities and goals, and then on Thursday you discuss that with the team leadership (designers, producers, whoever makes sense). 

On Friday, the team leaders adjust any backlogs or priorities for their own team, allowing the devs to start planning on Monday with an updated model of what the goals are from top to bottom. 

That’s almost a week and it might seem like a long time because it is. But, it is much better than that same Tuesday playtest, followed by the executives not getting together to talk about what’s important till Thursday because they are busy, then they don’t get a chance to talk to the game leadership until the monthly Stakeholder Review the following week, and then leadership spent another week getting all the team leads into a room…

…you get the idea. And perhaps you’ve experienced it.

You want as much decision making as possible pushed downward via delegation as you can manage, and you want the top-to-bottom communication loop to be as rapid as it can reasonably be.

Even if your development processes are pristine and iterations take less than a day to pull off, if your communication loop is a month, you’re still going to be iterating and learning slower than you should be. Not only that, you’ll probably have low morale, a lot of rework, and lots of people working on things that aren’t that meaningful.

Keep your communication loop tight.

Third set of things to get to healthy iteration:

• As much as you can, delegate decision-making down the organizational hierarchy

• Adjust meetings to create the fastest possible loop between feedback from decision-makers to actionable information for devs

Summary

If you aren’t learning, you probably aren’t succeeding in game dev. Our environment is inherently uncertain and you can’t fix that with up front planning. Learning is achieved via iteration. The better the iteration, the better the learning. The faster the iteration, the faster the learning. You want to maximize your time to learn valuable info about what will make your game a success. 

To recap all the actions:

1. Create a culture and environment that accepts the game will be iterated on before becoming good, and realizes not everything you wanted to do will get done because of that.

2. Figure out what is slowing down your devs’ iteration time and see if you can fix it.

3. Playtest as frequently as you can. If that’s not often (rough guide: you can’t playtest once a week), figure out what’s preventing that from happening and fix it. 

4. As much as you can, delegate decision-making down the organizational hierarchy.

5. Adjust meetings within the work system to create the fastest reasonable loop between feedback from decision-makers to actionable information for devs.

You iterate to get better, and building a better game is the goal. Create a studio that can iterate well and quickly, and you’ll be ahead of the curve.

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].