When was the last time you worked on your game idea?

And by “working” I don’t mean just letting your mind bounce between a view of future success and a large wall full of questions. I mean actually getting your hands dirty. Don’t worry there is no such thing as Game Designer’s Block, it’s just a lack of methodology. Game Designers know that executing an idea means constantly improving it by understanding what works and reacting accordingly. Every game is different but every one of them is crafted with the same framework, that it’s proven to work after many years of use in the game industry.

I’m talking about the Game Design Iteration Cycle.

‍

Follow me and you’ll discover:

• What it is and why it’s crucial for your day-to-day work.
• How to effectively manage it.
• The 4 steps you need to master it.

There’s a lot to cover; let’s dive right in.

What Is The Iteration Cycle And Why You Need It

More often than not your ideas are amazing until you really think them through.

The most common mistake aspiring game designers make is to keep adding things to the game without actually understand what they already have. This is what the act of iteration has at its core. Iterating on a game system means extrapolating its most elegant version, the one that manages to generate the target experience with the least amount of effort possible for the player.

In essence, iterating on a game system results in understanding it.

‍

The process of understanding your game seem counterintuitive but it’s a necessary step to avoid caos.

You may think: “Of course I understand what my game is because I created it in the first place!”. Yes you did, but the game designer’s work is not like others: you first define the rules and only after you can really understand how it works. Let me explain.

When you come up with some game concept, you have just a fuzzy idea in your mind that seems awesome, and as soon as you write it down you realize some missing details. Covering up this little holes the description starts to grow and grow until you realize that you have a hard time wrapping your mind around it. In this situation iterating means to stop adding things and test and refine a portion of it to discover fallacies and eliminate useless elements.

At this point many aspiring game designers forget a fundamental concept.

‍

Iteration is always a repeated process and never a single cycle.

It’s tempting to stop after the first loop and move on by adding something new, but don’t do it. The Iteration Cycle is meant for constant improvement. It takes time, but the method brings excellent results, and during those iterations you may lead in direction that you would never have imagined.

Stopping after the first test will also deny you more opportunities to fail, and that’s a bad thing.

‍

Embrace failure as a tool and always ask yourself what you learned from it.

You’re going to fail often, so be open to it. But let me give you a mindset trick from the science world to handle this.

The Iteration Cycle is rooted in the scientific method (when we’ll dive into the steps, you’ll realize this similarity more clearly). Scientists learned to always treat failure as an opportunity to improve, especially if it happens in a project’s early stages. If you adopt this mindset you can enjoy experimentation without the fear of mistakes. This way failure becomes a guide and also builds up the motivation to cover holes in your game. Every veteran game designer seek earlier mistakes because they can make many problems visible and fix them to avoid growing bigger and blowing up everything down the road.

However, don’t get too excited by throwing yourself into the unknown because “making mistakes is always good”. Be aware of what you’re doing because a veteran is not the one that made thousands mistakes but the one who learned from them.

Also, treat the Iteration Cycle as a tool that goes alongside your work and not as a substitute for it.

‍

Always remember that you are using the Iteration Cycle and not the other way around.

You, as a Game Designer, are always in charge of the process and a tool (even an excellent one) cannot guarantee the quality of the craft or the success of the whole game. The process is always uncertain and always will be because the possibilities are endless, and so are the outcomes. The ultimate purpose of the Iteration Cycle is to help you improve the design to craft the best game you can at that moment in time with the resources you have.

Now let me give some useful advice to practically use the Iteration Cycle without going mad.

The Game Design Iteration Cycle is a tool for continual improvement that turns mistakes into opportunities to create the most elegant version of a game that generates the target experience.

How To Manage Iterations Without Headaches

Constant improvement refines your experience by streamlining your communication.

In Game design there is a crazy variable you have to account for: the player. You cannot control him directly and if there’s something that he can do in the game he will do it, no doubt about that. The solution is to offer him an interactive system you designed that generates your desired experience. This is where the Iteration Cycle comes really handy. It will help you determine which routes you want to explore while also, loop after loop, building a pile of knowledge to craft the best experience you can.

Iteration makes your design stronger cycle after cycle and makes you overcome the fact that people tend to interpret sign an symbols differently. When iterating this is one of your main concern because it’s never a good idea to assume that players will get it; you want to know that they do.

And what about the length of a single cycle?

‍

The shorter the loop the better.

Iterate on one feature at a time; the whole point is to define and implement a limited and rough set of features and get feedback. It takes a long time to design and code a small set of mechanics with production quality, but a few minutes for your colleagues to give you feedback about them. Shortening loops allows you to improve your design one tiny step at a time. You can focus on something small and make the experience as good as possible instead of wrapping your mind around many extensive features all at once.

Minor and meaningful incremental steps reduce errors and result in a better design in the long run.

But, pay attention! The need to be quick at iterating is often a misunderstanding.

‍

Loops must be short, not the whole design process.

People tend to conclude that the design process must be quick, but the key takeaway is the single cycle must be short, not the whole design process. If you shorten the iteration loop, you will have a better design because you can focus on details and quality. Instead, if you shorten the entire design process, you will end up with a worse design because trimming the process means reducing the number of iteration cycles.

Now, how many cycles are enough cycles to declare the design finished?

‍

The “feeling of enough” in game design is acquire only with experience and it’s not too reliable.

It's impossible to spot a right moment to stop the iterations that is good for any game, nor a formula that you can apply. In this case, the experience can be convenient since, after you have developed a good number of games, you can "feel" when a game is good enough and does not need further improvements. But experience is only obtained with... well... experience, so it’s not the best approach to start.

Here’s a mental model I use to determine if a feature (or a whole game) is finished.

‍

A game’s design is finished when it no longer makes sense to change something.

It seems obvious and simplistic but remember that you are the Author of that design so the responsibility of declaring it finished relies on you, and you cannot delegate it to a tool. When you want to make a change, you have to evaluate the pros and cons of that change; if the improvement is insignificant, then it’s not worth making it. It doesn't mean the design will never change again, as making this statement is practically impossible, but it means it’s good enough concerning what you want to achieve. But let me clarify this a little bit better. Suppose you want to add a weapon to a combat system.

If this weapon is merely content and just increases the “size” of the combat system without adding anything significance in terms of mechanical complexity, it’s not part of the iterative process of refining the gameplay. The reason is it doesn’t bring any additional depth to the gameplay but only adds content variation, which is good, but you can consider it later if it still make sense.

All right then, now it’s time to finally unpack all the Iteration Cycle steps.

Shortening the Iteration Cycle allows you to focus on small quality changes, leading to better designs in the long run. It also helps you understand when it no longer makes sense to change something and end the iteration.

The 4 Steps To Master The Iteration Cycle

The Game Design Iteration Cycle has four steps:

1. Conceptualize
2. Prototype
3. Test
4. Analyze

Let’s explore them one by one in detail.

Conceptualize

Think and structure your idea by imagining how it will work.

Your goal is to understand how the implementation works and discover if it generates your target experience, so don't try to be fancy adding details you don't need. You must always keep the target experience in mind, and everything that you define must be done respecting it.

It’s seem tricky and abstract, and it is, but that’s because documents are so important.

‍

Writing design documents inherently makes you think.

Design documentation is one of the most powerful tools at your disposal to flash out all the details of your game. Here it's crucial to be analytical and precise, but don't make the mistake to dive deeper than you need, or you will fall into an "analysis paralysis state." Don’t underestimate this phase and don’t rush through it to build the prototype, this step will avoid you a lot of future pain.

Let me give you a mindset trick to handle this phase in the proper way.

‍

First define your design idea and then try to break it.

You may think that’s counterintuitive, but that’s exactly how scientists work and think. Ask yourself how the player could exploit and break what you defined. When your idea will collapse (because it will) just redefine it to fix that issue. Keep trying to break it until it stands still and it’s logically solid.

Now you can go to the next phase and build a prototype to test it further.

Prototype

The input of the Prototype phase is the output of the Conceptualize phase.

The best way to figure out how the game will look, feel, and act is to dive in and start making it. There is no standard choice for prototyping; it could be paper, quick and dirty code, even the designer's own body performing the game's actions. Pick the fastest and easiest way to implement what you defined in your documents.

Let me save you some headaches by revealing the right process of turning your documents into a prototype.

‍

You have to bounce back and forth between these first two phases to cover design holes.

A common mistake all aspiring (and often not) game designers make is to think that they can wrap they’re mind around what they’ve created. I can assure you that your brain (everyone’s brain actually) can't examine all the circumstances that your design, however simple, can generate. While building the prototype you’ll identify deficiencies and flaws in your documents. Therefore, it’s necessary to go back to the Conceptualize phase to define all the missing parts to implement the prototype in the best possible way. This creates an inner cycle between step 1 and 2.

It’s very common, even for veteran designers, to ignore this small but powerful inner cycle. And that’s a big mistake because with that you can save time and create a more accurate preview of your target experience.

When your prototype is ready, you have to test it.

Test

Test your prototype as soon as possible to make changes cheaper.

The number 1 mistake aspiring designers make is to test their prototype too late because they want to wait until the game is complete. But trust me, you just need a focused piece of the game to see if there are design flaws in it. Also this will help you to keep in focus your target experience and avoid getting off track and miss something or, even worse, pay attention to non-priority things at this stage of development.

If you find your prototype too simple and rough don’t worry, record all the flaws you identify so you can improve it with further iterations.

You will always be the first tester of your design prototypes, but that’s not enough.

‍

Include other people or colleagues to gain new perspective on your work.

As you go on with iterations your point of view of the game will stagnate and your judgment will be less useful with every cycle. At some point the testing phase must involve people outside the design process like colleagues (other designers, programmers, artists, etc.) or even not developers. However, be careful about close friends and parents because they could have an hard time giving you the honest feedback you need.

Once you have a giant pile of feedback, it’s time to analyze them.

Analyze

Carefully evaluate all playtest results and decide whether and how to modify the game design.

When you analyze a prototype, you can frame it in two points of view:

• Technical: check if the prototype "is broken" from a design perspective (e.g., you can play it, but game systems are unlinked to each other, or gameplay is full of useless clutter, etc.).
• Experiential: check if the gameplay generates the targeted experience.

Don't mix these two points of view, or you end up with incorrect correlations between future changes. For example, sometimes the design works properly, and the game is enjoyable, but the experience generated is not what you initially meant.

But how can you determine exactly what to change?

‍

To identify what to change always look at your target experience.

Every game is a different world, so the clearer the target experience you have in your mind, the easier it will be to figure out what changes to make from one iterative cycle to the next. Focus on identify the gap between the experience you want and what you have at the moment. However, don’t change too many variables at once or you’ll not be able to understand if any consequences are due to one change rather than another. Focus on one of few elements at a time and try to understand what the effects of that change will be.

It's always better to make a lot of short cycles rather than a few big ones.

Congratulations, you’ve reached and completed the last step!

‍

Now it’s time to restart the cycle all over again.

Every iteration is about learning something new and applying it in the next cycle. A well-done game design process takes time and you can’t skip it. Also it varies from game to game because every time you will face new challenges to explore new player experiences. By cycling through this you’ll improve alongside your game.

So it’s time to go back to the same questions you began with in the Conceptualize phase.

To master the Iteration Cycle you need to Conceptualize your thoughts on docs, Prototype to make your ideas concrete, Test to evaluate them and Analyze to know what’s in the next cycle.