“Game design, like most forms of design, is an iterative process. That means that the game is quickly prototyped, played, and refined again and again before it is finalized.”
Brathwaite and Schreiber; “Challenges for Game Designers”
Iteration is a word game developers use to describe the magic that makes games happen. But what we actually do when we iterate, and what we iterate on, isn’t exactly consistent. Rather, “it’s an iterative process” is a dismissive and handwavy equivalent to “God works in mysterious ways.”
There are dangers to iteration as a solution rather than a process and some may even seem like they’re good things when they’re not.
The Dangers of “It’s an Iterative Process”
One common problem comes from iterating on late-stage production content. Say, a character that took twelve weeks to make and has to be remade because someone wants some large changes; or an in-engine cinematic that’s already been put together and turns out to be too long, too short, or uses the character that needs large changes.
Editing on late-stage content isn’t easy since in-game assets and engine tools are used. Redoing a cinematic can be a painful process. Redoing a character may require revisiting every moment in the game where that character is used, making sure the sword on its back doesn’t cut through its leg while moving or making sure that the colors match what the art director wants.
It may seem trivial to “just” rotate a thing or change a color value, but sometimes it’s not. Sometimes it snowballs into disaster faster than you can spell overtime. If you need a specific card from a house of cards, just pulling it out collapses the whole thing. Same with late-stage iteration.
At one point, this once went so far that a director said “if this is still a problem closer to launch, let’s revisit it.” But, as everyone knows, anything that gets pushed “closer to launch” will be put way down on the list of priorities and the problem will persist into the finished game. In that specific unnamed case, the problem did persist and is in fact in the finished game.
This place is where we often end up when we say, “it’ll be better later,” or some variation of the same. When we hide behind the iterative process itself without thinking too closely on the hows or whats of iteration.
The Dangers of Cheap Iteration
Some things are much faster and cheaper to iterate on than others and can therefore be iterated on for too long during a project’s lifetime. Sometimes because we have people hired to do the iterative job. (Sorry, but game designers are often the baddies here.)
Three specific things stand out:
- Theoretical design. “Wouldn’t it be cool if” is another theoretical design iteration that doesn’t necessarily have any practical meaning for your project but can still be pushed through at late stages. Designers without practical skills tend to be the worst culprits here.
- Writing. Writing is rewriting, as they say. A writer can come up with literally anything at a moment’s notice. When writers drive the content, this is what often happens. Five minutes putting words in a document and suddenly there’s another six months of work.
- Sketch art. Good sketch artists can draw things faster than you can blink, and can similarly introduce new coolness and greatness with very short notice. Of course, they rarely do this spontaneously but because a director/designer/writer-person asks for it.
These three are so cheap to iterate on that it often causes another kind of problem: you never stop iterating on them and by extension the features or content they affect. Especially if you have many meetings of the sort where you talk about your project in abstract high level terms.
Even deep into production of your game, you can still backpedal on some story element, introduce a new character that the creative director came up with for some reason, or change fundamental designs because “wouldn’t it be cool if?”
This is where much of the bad type of iteration comes from, and trickles down through production like acid rain. If you want to know where game development delays come from, this is often it. You probably know it by the name “feature creep,” or “creative vision.”
You should do less of these three once you reach production. Preferably none at all. Do spend a lot of time in preproduction iterating on these three cheap things, and prototype them to your heart’s content while they remain cheap. But once you hit production, you must stop.
The Dangers of Deliverables and Iteration
Deadlines are like Terminators. They can’t be bargained or reasoned with, and they won’t stop until you are dead. This makes them completely incompatible with the loose approach to iteration, where we’ll “fix it later.”
Once you hit the deadline, what you have is what you have – if the iteration didn’t work out, you have nothing, or you are forced to fall back on the bare minimum. Or, worst case, what you have simply isn’t very good.
There’s an idea that things can only be known to be good at the end of a project, when all things come together. But this is only because we often spend our whole project time iterating on production content and don’t force ourselves to iterate early and cheaply.
How Nintendo works on their controls for a very long time, and how art direction can be constructed carefully around communicating your gameplay, are examples of good iteration. Once you hit your deadline, you must know what you have, and you must have already finished all the iteration you needed to do.
If not, whether your game is good or bad will basically be a coin toss. A coin toss based on professional experience, surely, but still a coin toss.
The Dangers of Third-Party Game Engine Iteration
There’s a natural inclination to jump straight into the scripting or programming tools and churn out a playable demo. You open up a third-party engine, throw some ready-made templates into a project, and voila: you can move and shoot stuff!
This is often great, because it lets you answer hard questions and push your design forward. But chances are that you create a kind of illusion of progress, where making the bare essentials work feels like good progress because you didn’t have it before. But once you try to take the next step, you get bogged down in minutiae that are entirely irrelevant for the iterative work you aimed for. Especially if your engine of choice relies on ready-made packets of logic that can become black boxes for your implementation team. Say, a ready-made AI feature packed with extraneous functionality or a system for handling input that causes high latency.
What happens is that you spend more time fixing the ready-made solutions than you do iterating on your game. There’s also a great risk that you start skipping features you wanted to make because the engine doesn’t have good support for them, or they are too hard to make without extensive refactoring or source code additions.
Or the opposite happens and you start building features based on cool stuff in the engine rather than the game you had in mind. All of it is problematic.
The Dangers of Stakeholder Iteration
For most of us, some kind of external stakeholder pays our salaries. Bless them for that. But they can also be hard to please or not really know what they want. There can also be multiple tiers of stakeholders that are equally hard to please and may have their whole employment hinged on making your life difficult.
There are three specific situations where an external stakeholder will typically ask you to “iterate,” except it’s usually in a visual way and doesn’t necessarily help the game itself move forward.
Best case, you can allocate specialised resources or even use the stakeholder’s own resources to do this iteration. Worst case, you have to reallocate parts of your team from production onto the request.
The following are three situations where stakeholder iteration risks sidelining your project:
- In advance of announcements, marketing events, and so on. It’s not unusual to be asked to make a video for E3 or some similar event. Some stakeholders – like game publishers – have marketing departments that do this for you; others will require you to do it yourself. Sometimes it’s planned for way in advance; sometimes you learn about it two weeks before the fact and you have to work overtime or pay expensive outsourcing to do the overtime for you.
- When you pitch, game publishers can be especially awful to work with. Sorry, game publishers, but it’s true. They want to see a video, you make a video; now they want gameplay. You make gameplay; now they want to see more, or they invent a buzzword they need you to realise. All for the sum total of $0. Pitching can be desperately frustrating, or as Guillermo del Toro phrased it for movie-making; “it takes Hollywood two fucking years to say no.” Game publishers are the same. This can change to some extent if you have other kinds of stakeholders, but convincing people that you can in fact do what they are paying you to do is an incredibly frustrating process.
- Scrambling against competition. Some stakeholder requests are complete shots in the dark. On one project, we were asked to add a train level because Uncharted 2 had just come out to some fanfare, and it had a train level. If you fail to see the correlations in that sentence, you understand how we felt. If you have a good relationship with your stakeholders, you can push back against these types of requests. If not, it’s something you simply have to do. I call these “spot requests,” and they run the gamut between useful fixes and complete waste of time.
Should We Not Iterate?
Yes we should! In fact, we should do a lot more of it. In the past year (2021), I spent a lot of time working on prototyping and finding out where the boundaries are. What is it you need to iterate on? What tools are there to use? How can you iterate faster and in a more focused manner?
I’ll be sharing my findings in a series of posts on prototyping frameworks, in the coming months.
Playtank 