April 7, 2014

Don't Change, Iterate!

In the game industry, developers love sharing their experiences with others. By sharing their experiences, they allow others to learn from their mistakes while internalizing the lessons they’ve learned. But what I find is that a lot of developers do not differentiate between change and iteration:

“So for our platformer, we had a jump mechanic. It worked, but it didn’t mesh with the feel of our game. After changing the jump for nearly a week, we nailed the jump, and it made our game even better.”

Rather than digging into what drove these decisions in more meaningful detail, they are described as “change,” as if the iterative process didn’t exist. Change has become a romanticized idea that values bold action over careful thought and planning; as if doing something different will always yield better results.

This is wrong.

Change vs. Iteration

Why do I find the word “change” so troubling? Well, change is making something different.


Iteration, however, is the process of refining a concept by analyzing it critically and improving it over and over until it reaches its goal.

This is fundamentally different.

Change doesn’t think about the reasons why something has to be different or the circumstances that made it appear as a problem.

Change doesn’t consider the consequences of its action because Change doesn’t care, nor is it its responsibility to care.

Change is just supposed to change.

But iteration is smarter than that. To iterate means to have end-goals in mind. To iterate means analyzing and drawing conclusions based on gathered data. To iterate means improving something while acknowledging that the next version may have flaws that need to be addressed. Iteration can answer the who/what/where/why/and how questions with ease while Change whines when it doesn’t get its way.

To simplify iteration to change undermines its power and makes game development feel like a series of “just right” changes based on circumstance. I know that developers aren’t purposefully phrasing it this way but by not explaining the processes and information that led to game-changing decisions we’re unintentionally teaching that if someone has a problem, they should change something rather than think through it and make informed decisions.

The “Change” Explanation

Let’s examine the change explanation:

“So for our platformer, we had a jump mechanic. It worked, but it didn’t mesh with the feel of our game. After changing the jump for nearly a week, we nailed the jump, and it made our game even better.”

I understand that you had some jump mechanic and that felt like a problem. So you changed some stats until it got to the point that you liked it? But why didn’t it feel right with the game? What drove your decisions to change the velocity and air times once you found it to be a problem? Did you just change values at random? How did you know when you had it right?

This explanation is vague and has no substance.

The Iteration Explanation

Now let’s describe the steps that led to these decisions and see what that looks like:

“So for our platformer, we had a jump mechanic. Since our game was a 2D side-scrolling shooter, we wanted our controls to be responsive, snappy, and easy to understand. One problem we noticed was that our jump felt too floaty and conflicted with how responsive our game felt to players and our team. First we worked on airtime. We tested a variety of jumps with the airtime modified and found that the jump felt best to players when it was an immediate jump over a jump that built momentum over time. At first, we went with an immediate force that made the player move up two units immediately, but visually it looked buggy even though it was responsive. So then we decided to have an immediate force but with a sharp ease-in. Once this feature was in the game, the jump not only felt responsive but in close moments created a bullet time feel since it slowed down at the end.”

So one of the design goals was to make the controls feel responsive and easy to understand. Okay, now I have some context. Also, that would explain why a floaty jump would feel awkward since floaty != snappy.

Before even going into the iterative steps I understand as a reader the problem, the reason why it’s a problem, and the developer’s end-goals for the jump mechanic.

Now, what steps did the team take? Hmm, okay, still not a great explanation of the values they tweaked but I know that they focused on the airtime and tested a few jump variations. The jump that felt best to the players was the immediate jump. Alright. But then the character looked buggy, so they tweened it with a sharp ease-in. Cool; this could be useful.

By showing that there is a process, game developers not only give the reader tools to tackle problems they may face in development but also help reinforce what they learned to themselves.

Don’t Change, Iterate!

  1. Change and iteration do not mean the same thing! Do not use them as synonyms for each other
  2. Just because one part of the cheese is moldy does not mean the entire block is bad
  3. Just because you have a leaky faucet does not mean that the kitchen needs to made from the ground up
  4. Just because you have a zit doesn’t mean you need a new body
  5. And just because one part of your game isn’t working, doesn’t mean that you need to change everything

Anyone can change. Few can iterate.