This article is part of the game-dev advice newsletter Levelling the Playing Field by Rami Ismail. If you want to know more about the art, craft and science of game development, subscribe here.
A lot of studios spend years making a bad version of a good idea – until they go and figure things out. It’s not because their ideas or team are bad – it’s because their development process does not have One Way Doors.
Countless games studios have a tendency to wish to be “flexible” – to be able to make the game the best version it can be. These studios mostly tend to move back-and-forth between the Pre-Production and Production sections of development. They refer to this as an ‘iterative process’ and suggest that moving back and forth between stages of development is part of the creative process.
Important pre-production questions
This often leads to games that “get ahead” of where they actually are in development. Teams will have moved into production prior to actually answering all the important pre-productions questions: “what are we making (and why?)”, “is it worth making?”, and “can we make it?”.
If those three questions are not clearly answered, what you get is a situation where certain central assumptions might turn out to be untrue (much) later in development, forcing you back to pre-production. The further back in the process you end up having to go, the more expensive any change becomes: as games grow more than they’re built, any foundational change ripples forward into additional adjustments, reworks, and removals of anything downstream of the affected decision.
That leads to development reaching a strange limbo state – while the team is working hard continuously, a significant part of their work ends up having to be scrapped or deprioritized as things get re-done, removed, or re-prioritized. Despite all the hard work, development never moves forward.
Not very flexible
So, instead of a flexible process, reality is that the primary thing this approach creates is a very unpredictable development process. Unpredictability will often produce a worse game & a less motivated team. Ironically, it’s also not very flexible: it might be near the start, but as resources get wasted on the back-and-forth between pre-production & production, it leads to more urgency & less time to experiment on everything that eventually does get locked in.
To make things worse, this approach also reveals a complete misunderstanding of “iteration”. Iteration is meant to be part of a healthy development process – not an overarching ideology that allows movement forward and backwards throughout the steps of your process. Your process is meant to move in a forward direction, with cycles of iteration moving you along a path that generally leads you towards your project goals.
One Way Doors
Go with me on a quick detour. Airports are generally divided into two areas: the airside and the landside. The landside is the unsecured area of the airport, which usually includes some stores, the check-in area, and the greeting area. The airside is the secured area of the airport, which generally includes the gates, shopping areas, and lounges.
At most commercial airports, the exit transition is marked by an automated door with sensors only on the airside. In older airports, you’ll find a guard near some doors that ensures nobody uses those doors the other way. In most modern airports there’s a set of small transparent corridors with two automated doors at each end. The corridors function like a lock: after you enter the first door – exiting the airside, it closes behind you, and then the second door opens – allowing you to enter the landside. Combined with additional automated security sensors, these doors ensure nobody can avoid security and transition from landside to airside by using those doors.
It also means that many passengers, as they approach those doors or that guard, might do a quick mental double-check – did I bring my wallet, did I bring my phone, my suitcase, my sweater, my backpack, my passport, my headphones – whatever items are most important to you. If you catch that you’re missing something before the doors, you can simply run back to the gate. If you only realize after the doors, the only way to get the item back is to file a Lost Items claim by filling out a bunch of paperwork and then wait at home hoping someone finds and returns the item to you.
One-directional process
To bring it back to game development: you can improve your process significantly with a simple trick: add the One Way Doors from the airport to your Milestones process – to be exact, add them between stages of Ideation, Production, and Polish.
What that means is this: you should always treat a transition between stages of development as a one-directional process. That is true both on a project level (Pre-production, production, post-production), but also on a feature or asset level (ideation, production, polish).
Your processes should allow plenty of flexibility before locking in what something is going to be. There should be space for exploration, for chasing ideas, for throwing away things that don’t work. The base assumption is that most of what happens in ideation stages is not for production – it’s helping define production. But at the end of ideation, there should be a clearly defined plan for production. What you’re going to make, how you’re going to make it, what risks might occur, and how you could handle them.
But when it’s locked in, your team should be able to rely on the fact that it’s locked in, and that it won’t change anymore unless that is absolutely necessary and all reasonable alternatives have been exhausted.
Define, Discuss, Document, Decide
The best way I’ve found of creating One Way Doors is to follow a simple process of Defining, Discussing, Documenting, and Deciding (please know that I really wasn’t trying to make that alliterate, it simply happened to!).
First, have your team agree on the Definition of the problem at hand: that means that we establish what our goals are, what we’re doing in the process, and to what purpose. What does this “One Way Door” represent, process-wise?
Well, we’re trying to answer the question of “are we ready to move from Pre-Production to Production?”. We’re answering that question by having each vertical of development presenting its definitions and their understandings of the project, ensuring we’re all aligned. We’re doing it with the purpose of creating as much clarity as possible before moving on.
I’d suggest you keep the following two questions in mind, and ask project leaders, team leaders, and producers to document their understanding of the current project by answering the following questions:
Did we answer all the question marks in our product definition?
- Is the project Core defined and is the team in agreement on what it means?
- Is the design defined, and do we understand how the dynamics of the mechanics work, and do we agree the play is interesting and versatile enough?
- Is the visual style defined, and does the team understand what the visual style is, what considerations exist for that visual style, and what the goals of the visual style are?
- Are other relevant parts of the product defined to the point where there can be no misunderstanding of what our goals are?
- If there are things that are undefined, how are we ensuring that their current lack of definition does not block other disciplines or segments of the production process, and that their work catching up does not jeopardise any of the decisions being locked in now?
Did we prove our ability to produce the game at the targeted production quality?
- Has the vertical slice proven our ability to produce content at a rate that does not invalidate our timeline or budget estimations?
- Does the timeline seem reasonable, and are appropriate margins in place?
- Does the budget seem reasonable, and are appropriate margins in place?
- Is the team complete, and if not, is there a clear understanding of what kind of talent needs to be acquired and what the feasibility of those acquisitions are?
- What content are we going to be developing, how much, and what is the process of creating it?
- What risks exist to the production and how can we mitigate those we have control over?
- Discuss these questions with the stakeholders for each discipline of the development process. We don’t need a perfect answer for each of these questions, or a resounding “absolutely” – we just need to make sure everybody agrees on what the answer is, and what the answer means for them.
This transition is a critical moment for the game’s development, and as such, should have plenty of time for discussion and debate. This is not a time for new ideas or trying to change things – the only point of this meeting is to get a binary answer: “yes, we’re ready” or “no, we’re not ready”.
Final decision
If there is alignment, have someone take all the documentation provided and merge it into one coherent document that is distributed back to the stakeholders (leads, directors, etc.) for feedback. It usually takes a few “back and forth”s to get things ‘good enough’ – and as soon as they are, and with the explicit buy-in of all relevant stakeholders, the game director and producer take a final decision on proceeding or not.
This might sound like a lot of friction, especially if you’re a small team, or you’re used to not have processes like these in place – but the amount of stress and arguing and time you can save yourself down the line is worth it. In going through this process, you gain a number of incredibly useful advantages:
- You have ensured alignment on the project, and gotten buy-in from every relevant stakeholder. That means the vision of the project is clear, communicable, and achievable.
- You have created a clear blueprint for the game’s production process – with clear goals for each department, and clearer timelines for your producers.
- You’ve created a document to keep people accountable to – while it’s not meant to be a lawbook, it can help create appropriate levels of consideration when changing things in it that had already been agreed upon.
The threat of having to fill out paperwork before going through the One Way Doors is enough to have us check for our wallet before we go through the One Way Doors. The threat of wasting time, money, and morale on throwaway work that we could’ve avoided doing in the first place while we’re attempting something as complicated, time-consuming, and expensive as the development of a game – now that should be more than enough to do a little work for.