Something that has always tickled me about the production role are the mental images we attach to it in the games industry.
Some say that a game is ready to ship when your producer touches you gently on the shoulder and says “it’s time,” leading you away from your desk into a beautiful field filled with flowers.
Some might picture a Grim Reaper with a scythe with “feature murderer” written on the side. While all of these are absolutely true, I do take issue with one part of the fantasy. Production is not about taking features away, in that it’s not about denying or declining an experience to a player. Production is about knowing when to cease discussion on problems that are unable to find a conclusion. It’s about balancing the needs of the end user against the needs of the team creating the experience.
This doesn’t necessarily mean ceasing discussion forever, but knowing when and where the line needs to be drawn to ensure you don’t impact the past, present and future negatively. It’s about knowing when to next have the conversation, whether it needs to be had ever again, or whether you can encourage the team to forget it ever happened and focus their time and energy elsewhere.
The reason for this article (and the twitter thread it’s based on) sparked off the back of a great Gamasutra post-mortem by Sara Casen, who was the CEO & Producer at an indie studio called Midnight Hub who released a game called Lake Ridden. Within a number of great insights, one sentence jumped out at me.
“It’s important to be mindful of the fact that if one discipline of developments decides to cut something it will most likely affect someone else along the line instead.”
Removing a feature is not as simple as saying it is cut from your development process and moving on. Let’s say you decided at one stage to communicate information to your player through a visual asset, for example, a signpost in the centre of a town. That is a task that will feed through the entire team. You need to decide the message, the look, the placement and more before even thinking about implementation.
Let’s say the team is unsure if this is the best way to communicate something to the player. This is a conversation that with many different opinions and disciplines to consider, every decision made will shift the balance and distribution of workload across the team — sometimes imperceptibly, sometimes to a conclusion of potential disaster.
The role of the producer is to come in and recognise the impact of these potential shifts, quickly and impartially, whether they are minute or huge. They need to be able to know the value of the information that needs to be communicated to the player from as many possible perspectives — time needed to create or implement, value it contributes to sell-able product, will this information have a huge impact on game play experience — and more.
Then once you’ve ascertained whether the information has enough value to be a must have implementation, it’s time to decide how. This discussion process, gone unmoderated could take up more team time and energy than the original approach and might settle on the same conclusions. If you leave this to discussion without curation (or a team without a producer, whose end goal should be to find a balanced solution), you can end up with any or all of the following:
- An unhappy team member/members walking away feeling unheard or like their knowledge, discipline, and/or opinion isn’t respected
- An unfair distribution of work across certain disciplines (just code in a new X/Y/Z system in its place!) that will lead to bottlenecks further down the line, often thrown around by team members when a solution seems impossible to find
- People in the pipeline implementing or making changes against what they think is the best solution anyway, regardless of the impact it might have on others down the line, because they feel the solution reached didn’t meet their needs/understanding
The list goes on. You see, the problem isn’t the feature itself. A sign post has probably never caused a game to fail to launch on time. However, when one sign post becomes one hundred sign posts, and there is a failure to make efficient decisions that the team can understand the reasoning behind, you find yourself losing control of your pipeline, milestones fall behind and your studio culture can suffer as a result.
I’m not trying to scare you out of indie development (though that probably wouldn’t be the worst thing - you know that scene in Monty Python where they charge at the castle then they send flying cows and the knights are like RUN AWAY — game dev is being the flying cows and the castle and the knights at the bottom and the top all at once—but that’s another article).
There are many things that can be put in place to help with this — clear design documents, clear vision of a game and its concept, hell, working as a solo developer — but none of them will necessarily streamline your process like a good producer can. A producer is able to step in and recognize where there is a lack of value in continuing to examine a problem that isn’t finding a natural conclusion. For example — in Paperville Panic’s development process, we had a concept from almost day one for a specific ‘paint room’ in a level. I can’t count the amount of iterations this level underwent initially. Everyone was committed to finding a way to make the game play work — to make the time and energy involved in its creation, all the concepting, all the discussion — somehow come to fruition and create a great experience.
The paint room just wasn’t fun. This wasn’t the teams fault. We couldn’t make it fun the way we wanted it to be and we were spending so much time trying to, we were ignoring the myriad of ideas we had to make other parts of the level and game better. We eventually had to decide whether the value that this additional game play time from this unfinished room was going to outweigh the impact it was having on our development process — even just the fact that it was always at the back of our minds as something that needed a resolution.
We measured the business case against the internal effect it was having on the team and the answer was clear — there was no answer. So, we cut the room. There’s no magical formula to say whether these are the right calls at the time, and the timeline wasn’t drastically improved by this room that we cut. It was the right decision in the end, but it meant we then had to pivot the time and energy we would’ve spent on that area (and forget the hours we’d already invested) into the game play surrounding it to ensure the rest of the level was cohesive.
It was a redistribution of time and energy in that level, and therefore a redistribution of time and energy across the game. It didn’t save us a thousand years and cause us to ship two months early, bugless. What it did allow us to do however was to move our discussion forward, redistribute our workload as equally as possible and keep to our initial milestone goals, rather than getting bogged down in the minutia of why it wasn’t working. That’s what a post-mortem is for, after all.
Hire a producer — or at least get someone you can consult part time when things get sticky to help you move forward. A good producer can understand your delivery process, understand how each member of your team delivers and help drive decision making towards the most beneficial and economical moves to satisfy vision, team and timeline.
Maybe some producers are grim reapers (and if planning deliverables hasn’t made a producer shiver with pleasure at least once, I’m not sure they’re in the right role), but many many more of them are simply shepherds, trying to please both the wolves and the sheep.