Iterating is rarely a favourite use of time, but Mike Simpson explains why getting it right is essential
Iteration is dumb compared with getting it right first time, but because we can’t perfectly predict how our ideas will actually play out, it’s an absolute necessity.
Iteration being a necessity is believed religiously by the majority of games developers, but in one particular area – gameplay mechanics – it’s not 100 per cent true.
For novice designers iterating is the only option. Give them a good iterative methodology, and they will eventually produce good work. Fling enough mud and some will stick. Add design by metrics, and you can target your mud somewhat better, but believing too strongly in the methodology can encourage lazy design and eternal novices.
At best it’s inefficient and at worst it can send projects on a spiralling death march. It contributes to rising project costs and unpredictable results.
A CASE IN COUNTER POINT
So how do you maximise your chances of getting gameplay right first time? To answer that, first you have to be clear about what gameplay is. There are several factors that characterise good gameplay – immersion, adrenaline, simplicity, depth, progression and so on, but the one thing that defines gameplay is counterpoint.
Counterpoint is the simple idea that for everything you can do there has to be a reason not to do it – a circumstance where it’s the wrong choice.
It’s what Sid Meier calls ‘interesting decisions’ and he says they’re important for gameplay. I’d go further and say counterpoint is gameplay. It’s the defining difference between a game and an ‘interactive experience’. So in a racing game, going faster wins, but going faster around bends crashes.
Let the player bounce around bends without slowing and the gameplay is gone. In a shooter, aiming longer increases the chance of a kill, but also the chance of being shot.
And so it goes – at the core of every feature of every game ever made is counterpoint, and the difference between great gameplay and bad gameplay is that the counterpoint is strong. Everything else is wrapper, and while the wrapper may in some cases be astounding, wrapping alone cannot make a great game – there will always be a nugget of sound gameplay at the core. There are no exceptions.
So counterpoint equals gameplay, but what does that gain us? Creating counterpoint is science, not art, so it can be engineered, and if it can be engineered it can be done right first time – no iteration.
You won’t learn counterpoint engineering from a book. The only way to learn is by deconstructing games – lots of games – in minute detail to figure out how they tick. The principles are the same regardless of genre, very much like systems dynamics has parallels between electrical, mechanical, and economic systems etc. The form is wildly different but the maths is the same.
So, for example, the shrinking targeting reticule on my (recently clumsily nerfed) VK2801 has the same gameplay mechanics as declaring railway shares in the board game Union Pacific. Those parallels let you cut and paste proven and fully understood gameplay mechanics between very different genres, and understand how they fit in to their new context.
IN THE BALANCE
For each feature we need to evaluate whether its counterpoint is strong enough to earn its place in the game, and whether changes would make it stronger or weaker. We need to make sure the risk/reward trade-off is comparable with other choices. Too much reward and it becomes a ‘right answer’, and too little makes the choice not worth taking.
Lastly, we need to make sure circumstances around the decisions change in a way that affects outcomes. The player can then combine his skill with his judgment of the situation to make the best choice. However, there are many other factors that affect counterpoint, such as perfect balance, luck and predictability. These are the traps waiting for designers.
So, by engineering counterpoint it is possible to design in strong counterpoint from the start with little or no iteration, especially when you’re on familiar ground. This frees the team up to use their creativity to craft the rollercoaster ride, rather than being stuck bolting wheels on carts.
Of course, it’s not easy, and in reality we all end up having to iterate gameplay to some extent, but it’s not something we should be proud of.
[Interested in contributing your own article for Develop's readers? We're always on the lookout for industry-authored pieces on development-related topics. Email firstname.lastname@example.org for more details.]