How to Apply The Iterative Process in Game Design

Iterative game design is the standard process for turning a game idea into a well-executed game through a cycle of steadily improving changes.

Games are not conceived, perfectly specified, then built to an exact plan.

Instead, quality games require near constant iteration from prototype to final product. Each iteration slightly improves upon the last, moving the product steadily towards a shippable state.

For many games, the iteration doesn’t stop there, as additional patches improve the quality of the experience for months or even years after shipping.

Ori and the Will of the Wisps had the most iterative game design process I’ve ever worked on. Each level was first blocked out in simple shapes to show movement patterns, tested and tweaked until they played well, then created with final graphics.

My favorite thing about an iterative game design process like that is how it alleviates the anxious and overwhelming need to get your design just right from the start.

Instead of becoming paralyzed by a fear that your idea or rules or scope isn’t good enough, you can push yourself to make something playable and testable fast, and improve from there.

Ironically, the better your iterative design, the fewer iterations you will need on future features, but great designers know there’s no avoiding an iterative approach. It’s just a matter of how early in the production cycle you realize its importance.

How does the iterative design process work?

Iteration is the best way to avoid the biggest failure scenario in the games industry. Game design is innately risky, and a great idea is not a great game.

I can’t count how many times I’ve seen game designers approaching their game with this flawed idea about how the process works:

1. Make game
2. Fix bugs
3. Sell game
4. Profit

A linear development process like this limits your ability to discover the heart of fun in your concept, iterate deeply to improve it, and release a better video game.

Instead, the iterative game design process is an adaptive approach. You make small, well-built pieces of the game, check in frequently to evaluate what’s working and what’s not working, then adjust your plan.

Here’s the best way I can describe it: you aren’t building one game, you’re building ten games, each one slightly bigger and more expensive than the last, informed by the lessons of the previous ones.Games can change many times during development.

Ten might even be a bit generous. Many video games have twenty or even one hundred major revisions before going into full production.

A fun game is not made by chance, and iteration doesn’t mean trying things at random. Game designers need to be deeply in touch with both the player experience and the game systems to resolve problems in a prototype.

Strong development methodology and good project management will enable designers to iterate faster and evaluate prototypes more effectively.

Game design is hard, and you need to be willing to move away from your initial vision. From the core mechanics to the little flourishes, learning from user feedback and your own experimentation is vital.

Stages of iterative game design:

Stage 1 – Plan

The first stage of iterative game design is to conceptualize the core idea of your game:

•  What’s the fundamental core framework?
  • Is it a platformer? A sim? Shooting gallery? A narrative exploration?

• What’s going to make it unique?
  • The narrative? A gameplay hook?

• What will you focus on improving above and beyond this core?
  • Deep gameplay systems? Beautiful presentation? Fine-tuned competitive balance?

You won’t be able to achieve everything you can imagine, but knowing what you want to preserve and what you can replace or improve on is essential in iterative development.

Next, you need to ruthlessly prioritize these.

• What do you absolutely need to move forward?
• What’s the ONE unique element you cannot skip out on?
• What’s the riskiest change that you feel must happen?

Sorting these out early will help guide you through the next steps.

Stage 2 – Prototype

It is essential to prototype quickly and efficiently. If you haven’t yet, be sure to check out this guide to game prototypes and their stages, where I go into much more depth.

At the start, just aim for any playable prototype – the bare minimum core game at the minimum quality level. The goal is to understand the decisions the player is faced with and understand what is compelling to them.

(Image credit: Lars Wobus at LinkedIn)

If possible, make your first prototype on paper so you can learn this before you put in the effort of coding a complicated game prototype.

Build just enough to prove you understand the fundamentals, then prioritize your unique element. It’s important to do this early and not get stuck trying to polish every feature of a video game endlessly.

The goal of rapid prototyping is to test your ideas and (hopefully) confirm the value of spending your time on the full game. This iterative design approach helps you avoid the trap of making a single, perfect game system with nothing built around it.

Each time you move to the next iteration, layer in an additional system or series of improvements that the development team wants to focus on next.

Deciding how much to change for each prototype is a delicate balance. You want to add enough to push your understanding and testing forward, but not so much that your playtesting is unfocused and doesn’t lead you in a clear direction.

Stage 3 – Playtest

Game studios have multiple approaches for playtesting. Early playtests are typically just the designer and programmer testing a specific feature.

Further in development, the playtest group grows to the entire video game studio, and eventually to outside testers who have no idea about the design methodology – or even what Super Mario Bros is!

Whatever the particular set of users, the point is to test if the implemented features provide the experience the game design team intended.

Game designers don’t get it right the first time – except sometimes when they poached something that worked from elsewhere. (Which is an important part of game design.)

So you always need to test how clear, motivating, engaging and satisfying your gameplay is with people who have no idea what your game design was supposed to be about. They give you that rare first-look insight into what’s working and what isn’t.

This is why it’s essential that you minimize the amount of hand-holding with your playtesters. The goal is not to prove to the playtesters you’ve made a fun game. It’s to observe what people do when they first encounter your video game.

Typically, this is all you need to do to start playtest your game:

1. Give the testers a written list of basic controls to refer to.
2. Set them loose without instructions.
3. Only jump in and correct mistakes if they specifically ask you for help.

This can be painful when you watch someone wander the same room for 30 minutes not realizing the ‘A’ key opens both doors and chests!

“That’s right, the cylinder goes in the square hole!” – Alison Burke went viral for this video capturing the necessary pain of a developer watching testers break everything.

But remember, your job is not to explain, it’s to observe your playtesters:

1. Make note of their emotions as they play, and what caused them.
2. Encourage the playtester to share their thoughts out loud for everyone to hear.
3. For a multiplayer game, make note of what they ask other players to clarify for them.
4. Ask for their thoughts and write them down without interrupting or clarifying (within reason).
5. Finally, ask pointed, specific questions about challenging, confusing or exciting moments related to the focus of the playtest.

Remind your playtesters that their goal is not to beat the game silently, but to help the game designers understand what’s interesting or flawed about the prototype’s gameplay.

Stage 4 – Evaluate

Once the playtest is over, take all of the feedback and sit with it. Ask yourself and your team these questions:

• What did the playtesters struggle with?
• Did your latest changes move your designs toward your goals?
• What did you discover that undermines the overall vision, theme or experience of the game?
• What did you discover that was unexpected and worth keeping?

If your answers all seem to say “full steam ahead,” stop and check yourself. Are your playtesters biased toward wanting you to feel good? Did you ask leading questions and give away your game design intentions?

Maybe your game really did hit the mark. But more likely, your playtest will reveal issues with your plan or new directions you want to go in.

Stage 5 – Go to stage 1.

Now it’s time to start over again. Iterative game design is a repeated process. Each time you go through these stages, you’ve completed one cycle of development.

The more cycles you go through, the better your game will get. Full stop. Fast, effective iteration is the key to designing great games.

Really bad games are not bad because they wanted to be. They either didn’t iterate enough or ran out of funds and had to ship before they were ready.

A successful AAA or indie game might go through a hundred or even thousands of these cycles before launch. Ori took us five years. WoW took ten.

Great games are a product of this iterative design process, and making games this way takes a lot of time and focus. Even yearly sports games are building upon previous years of technology and testing.

The benefits of iteration in video game design

1. Identify problems early – If there’s something fundamentally wrong with your game idea, you discover it quickly and are forced to change it.
2. Stay flexible – You learn as you go and have the flexibility to adapt if a better approach or unexpected idea comes along.
3. Spend less time waiting – More people can work on the game at once. Testers get involved after each prototype, instead of waiting until all the work is done and then becoming a bottleneck.
4. Improve collaboration – Teams learn to work with each other in mind. You’re continuously producing with the intent to test soon, ensuring your game is stable and playable. This brings clear benefits to every team.
5. Make your design process transparent – Your game becomes its own design document, with the features in place representing the core spirit of the game design.
6. [Most importantly] Reduce risks – This process allows you to continuously spread dev resources based on player feedback rather than blindly guessing.

Is iterative design right for all game designers?

It’s rare to say anything is right for every game studio, but for iteration this rings true. Even games which update on a yearly cadence still benefit from rapid iteration cycles.

Even when you’re making yet another zone for Warcraft or another level for Call of Duty, the stages of the iterative design process remain the same.

If you want to design great games, embrace iterative design.

Project management for an iterative design approach

The biggest mistake in game development is to assume it’s like building a toy car. You don’t sketch out the size, cut the pieces, assemble them and BOOM, you’re done.

Instead, it’s more like growing a garden. You plan out the general structure, but once the seeds are planted, you have to give your garden constant, loving maintenance season after season.

Which seeds won’t sprout at all, and which ones will take over the entire garden?

You can’t predict this in advance. You can only adopt a reactive approach, responding to issues as they happen.

It’s the same with iterative design. You won’t be able to guess exactly how many cycles you’ll get or how quickly features will come online.

What you can do is ruthlessly prioritize and estimate how much time at most you’re willing to spend on a feature. Without this cap, you’ll iterate forever or spend too long on one failed idea.

The exact process and tools don’t matter – Scrum, Kanban, Agile, post-it-notes, Google Sheets – as long as you do the following things:

• Plan
• Prioritize
• Time box (set a limit)
• Triage (cut what isn’t going to make it)

The purpose is to not overload your team with an impossible amount of work. Work can fill any amount of time you set for it.

How long will it take to make your game?

While there’s no absolute schedule that is perfect for every team, the general rule of thumb I use requires some background.

You have three resources:

1. Time
2. Money
3. Willpower

When you run out of *any* of them, your project can’t be completed. You can sometimes exchange one for the other temporarily, but all three are finite.

Rule #1: Achieve 100% of your features before you’ve spent 25% of your Time, Money and Willpower.

This doesn’t mean they are finished, polished or debugged.

Why? Because feature complete is not content complete. Creating content takes a lot of time.

Rule #2: Achieve 100% of your content before you’ve spent 50% of your Time, Money and Willpower.

This doesn’t mean the content is perfectly written, but it should be playable and be a reasonable approximation of the final game.

Rule #3: Once you’ve hit the goals in rules 1 and 2, spend the rest of your resources on polish and promotion.

Polish is even more expensive than content and features. It’s the pinnacle of what makes games high quality or low quality. At Blizzard, Rob Pardo used to say “Polish early, but not too much.”

You will spend most of your time not on getting the initial features into place, but on making them palatable to your team and players.

Breaking your game development into milestones

Those three rules should help you plan your overall timeline, and to pull back if scope creep is using up too many of your resources.

But you still need to decide which features to make first (and, later, which content and polish to prioritize).

To do this, choose regular milestones that give everyone a clear, shared goal.

Some major systems, like streaming, world development or networking, might take game studios months or years to fully develop. However, you should be able to showcase improvements every two to three months.

That’s long enough to get a good chunk of work done, and can be broken up further into two-week sprints focused on updates and accountability.

For one secret project, we broke it up into these milestone phases:

• Build basic character controls
• Build a player vs player arena
• Build a player vs enemy arena
• Build more player weapons
• Build more enemies
• Build an explorable region of the map
• Build a small version of the central hub
• Build a small farm

Each milestone built on the previous one, and included changes to previous features. For instance, we’d improve character controls for the context of the current milestone, or we’d realize we needed healing in PvE and figure out how to deal with that in PvP.

But the ultimate goal of each two- to three-month phase was clear and everyone pulled their weight to ensure it happened, then used the remaining time to make improvements.

How long should you spend on each game testing cycle?

Ideally, break your milestone phases into playtesting cycles that test your game once a week. This doesn’t mean every team is adding to every weekly playtest, but rather that you are constantly testing something.

On that same secret project, we roughed out individual features quickly. We’d sometimes hold daily playtests ourselves, and weekly tests with a few key members outside of design and programming.

This rapid iterative game design process kept us all on the same page. It’s natural for people to have different impressions on what’s being built and how it should work. Regular playtesting and honest and respectful communication keeps everyone on track and working toward the same goals.

Ideally, with each phase, parts of the game become more and stable as the game designers lock in on what works. If you’re redesigning everything from the ground up early on, that’s normal. If it continues years into the project, you’re probably in trouble!

The bigger picture: What iterative design teaches us about game development

Iterative design teaches us that game development is essentially making a lot of bets on what will be the most fun.

Video game design is not a concrete, knowable truth. A fun game is the product of hundreds or even thousands of less fun games being tweaked over and over again.

Game studios and game designers alike get paralyzed by perfectionism. Planning is good, but the perfect plan doesn’t exist. By getting features into the game, trying them out and experiencing them, you’ll eliminate the uncertainty around what works and what flops.

However, the more time you spend on quality, the riskier the features become. This is why it is essential to prototype it roughly and quickly so you can test before spending resources on richer visuals, sounds and so on.

When I worked on World of Warcraft pet battles, we started with simple paper descriptions of the abilities, and very simple health numbers written on a notebook.

This allowed us to focus on the core theme and game mechanics front and center. Once we knew it was fun to play in the imagination, we started figuring out what it would take to play inside the game engine.

That phase took months of execution to support exploration, battles and quests. However, we still managed to test something every few weeks, trying out new pet abilities, kits or quests.

Darren Williams and Patrick McKellar worked to ensure that we built out each feature in small, discrete chunks. Regular team playtests with input from the programming, art and level design teams helped keep us going.

At the end, we still had to rush… because a certain game designer built more abilities than he had the time and energy to polish alone. Fortunately, we stayed flexible and adapted, cut abilities that weren’t quite working and ultimately made it just in time with the help of Jeremy Feasel and Alex Tsange.

Collaboration across the teams and the frequent check-ins was never higher for any project I worked on at Blizzard. Fortunately, we had a solid basis to build on and clear design pillars to guide us.

Game design iterative process final thoughts

Games are complicated, collaborative, multi-disciplinary efforts. The secret to a fun game is to start with a bad game. A game studio with strong design methodology and a dedication to rapid iterative game design will turn that bad game into a fun one.

Iterate quickly while it’s cheap to do so.

Meet the core goals of your game concept and prove it’s fun before you add extra features or expensive visuals. If you can create the fun before throwing on the polish, your game will only get better the more time you can spend on the iterative design process.

And if you enjoyed this look into how games are made, come join our Discord for more discussion, and specific feedback as you try out iterative design on your own game project.