When Design Iteration Goes Wrong

Fast and continual iteration is key to making a good game. But how exactly do you iterate? When do you keep going on a feature and when do you scrap it?

On Cannon Brawl there were a bunch of mechanics in the early versions of the game that went away after many iterations. Soon, the original feeling of the prototype was lost and the game was no longer fun.

Eventually we worked our way back to most of the original ideas. The core mechanics in the final version of the game are relatively close to the prototype.

How do we keep ourselves from iterating out what could actually be the core ideas?

My mistake was not being able to determine whether an idea was just bad, or just unclear. Here’s an example. Central to Cannon Brawl is that you can fire cannon towers and they have a long cool down (around 10 seconds) before they can be fired again. This gives you time to do something else while you wait for the towers to be ready to fire again. There is great skill in optimizing your time between firing your towers, setting up defenses, and growing your forces.

This ‘long cool down’ key concept was in the very first prototype. However, in playtests it didn’t go over well. Players seemed to be having a bad time, constantly trying to fire cannons that were not available because they were on cool down, and asking “Why can’t I fire faster? Why won’t this cannon work?”

I then made it so you could fire faster, I tried adding a concept of an ammo ‘clip’ for the attack towers. I then ended up re-balancing the game to try and work with these much much faster cool downs. But now it felt different and the other mechanics weren’t really meshing together anymore.

My mistake was that I did not solve the core problem given the initial playtest notes. The problem wasn’t that the long cool down mechanic was bad, it was that it just wasn’t clear. Play-testers were having a bad time because they were confused. It was hard to tell when a cannon was ready to be fired, and when it was on cool down:

The building on the left is actually on cool down, unavailble to use, the building on the right is ready. 

You could still select a building that was on cool down and the the visual difference between the two states was minimal. The UI for the cool down counter was exactly the same as the UI for the ready state (the green boxes in the screenshot above).

We eventually iterated back towards longer cool downs, and realized it was the clarity of the concept that needed improving, not the concept itself. We replaced my confusing programmer art, added clocks, dimmed buildings that were on cool down, and made them unselectable. We also popped up a contextual UI when you hovered over a building that was ready to fire.

The feedback to the player is now much more clear, whereas before there was really no feedback at all. We should have originally iterated on the feedback, rather than on the mechanic itself.

Final version, the cannon on the left is ready, the cannon on the right is on cooldown.

So how do you know if the concept is bad, or if it's just communicated poorly? If the player doesn't understand what is happening, it's poor communication. People didn't understand why they couldn't fire their cannon, they didn't even notice it was on cool down or that there were cool downs at all. But if players understand exactly what's happening and they still don't like it, then the concept itself might be bad.

Back to our early prototype for another example: to expand your forces you shot new buildings from your headquarters out of a cannon. Play-testers fully understood this mechanic, they just didn't like it. The core problem here was not confusion, it was that the mechanic introduced uncertainty in where your building would land. New buildings were a high cost in both resources and player attention, so missing your 'building shot' was incredibly frustrating. No amount of improved feedback and polish would have fixed this. We ended up replacing the mechanic with direct building placement (to remove the uncertainty) and the game was better for it.

When evaluating what to do with a mechanic or feature in your own games for the next iteration, make sure the problem isn’t confusion. Make sure the problem can’t be solved first with better feedback, UI, and a little polish. Ultimately, make sure you identify the core reason for your play-testers’ reactions before changing anything.

Like what you read? Don't miss the next one on my blog.