mercury-logo-white-new

Developer Insights #8 – What Does A Game Producer Do?

Hi, friends! I’m Nate Robinson, senior producer on the KSP2 team, and I watched a lot of Apollo 13 as a kid – to the point that I practically wore out our family’s VHS copy.

Naturally, I always imagined myself in the role of astronauts Jim Lovell, Fred Haise, and Jack Swigert. Every 90s kid wanted to go to Space Camp, become an astronaut, and fly on the Space Shuttle, and I was no different.

But a funny thing happened a couple of decades later when I watched the film again as an adult: I didn’t find myself associating with the astronauts.

I, of course, had long ago moved on from any dreams of being an astronaut myself (I blame my poor vision, but trigonometry was truly where I gave up the ghost). Instead, I found myself far more engrossed in another role – that of flight director Gene Kranz.

Kranz, spends the entirety of the film not in space, but on the ground, trying to keep on top of an ever-shifting situation. He works feverishly with the bright minds around him for clever solutions to unpredictable problems and to keep everyone focused on the important goals in front of them.

In other words, he’s a game producer.

Dev-Diary-NateR-1

A game producer in their natural habitat.

The role of production in games is often tricky to define as it can vary from studio to studio and game to game, but it’s similar to that of a Product Owner or Project Manager in software development and other industries.

At Intercept, we have a team of three terrific* producers – including Fernanda Diaz and Paige Ketcham – whose job it is to ensure that development is running smoothly. We create and manage team processes, set goals and measure deliverables, coordinate cross-discipline efforts, prevent roadblocks, and do our best to keep everyone pointed in the same direction. Doing the job well requires strong communication, organization, multi-tasking, and leadership skills, along with a deep knowledge of the game you’re trying to make.

As you can imagine, it’s a lot to manage across a game with the mind-boggling size and scale of Kerbal Space Program (I have incidentally come to understand flight director Kranz’s evident chain-smoking habit), but it’s also the most rewarding job I’ve ever had. Establishing or optimizing a workflow that lets your team’s talented artists, engineers, or designers do their job even better may not sound sexy, but the reality is that it results in a much better game — and that never really gets old.

Dev-Diary-NateR-2

The KSP 2 dev team celebrates a successful milestone

On the KSP2 team, production’s fingerprints are everywhere. One day, we may be helping sort out the pipeline for creating new parts (What are the requirements for the part? Who will do the modelling and texturing? How many parts are needed and how much time do we have?) and another you may find us sort through bugs from a recent playtest (What is the priority of this issue? Who can help fix it on the dev team? When should it be looked at? Who replaced the Poodle engine with an actual dog?!). We are intimately involved in practically every aspect of development, which keeps us on our toes and no two days from being quite the same.

Of course, in order to get the answers to a lot of these questions and to ensure that the whole team is on the same page, we make use of another superpower of ours: Meetings. It’s a terrifying power, one that has been known to break lesser men (noted Kerbothropologist Paul Zimmer among them) and one we do not wield lightly. Running a meeting well is a criminally underrated skill and one that is essential to keeping a diverse, multi-discipline team moving forward hand-in-hand.

Dev-Diary-NateR-3

The normal dev-team response to me scheduling a meeting

Perhaps our most important responsibility, however, is managing the team’s short- and long-term tasks. Like much of the software world these days, the KSP2 team runs on a version of Scrum. Every three weeks, we gather our teams to review the previous cycle’s work, discuss how to improve our processes, and then get alignment on what the goals are for the next three weeks. There’s a lot of overhead involved in keeping a team of 30+ people busy, so we are constantly juggling a backlog of tasks in JIRA, our task-tracking software, so that the tasks are correctly prioritized and groomed (read: documented and clear).

For long-term planning, we build and maintain a development roadmap. A roadmap is simply a development schedule that lays out major milestones and when game features will be built. Some sections of the team — the part and planet artists, for instance — have their own roadmaps, but all development efforts are coordinated around a central roadmap for the entire project that is constantly being refined with adjustments to specific features and new estimates from the team itself. Even NASA’s Artemis team has a roadmap:

Dev-Diary-NateR-4

Though, where they’re going, they won’t need roads

We talk a lot about the roadmap on the production team because everything stems from it. No games are made by accident and one as complicated as Kerbal Space Program requires a lot of forward planning to ensure that our rocket leaves the launchpad on time and in one piece.

In future dev diaries, I hope we can give more insight into different aspects of production work as I barely scratched the surface of what is involved in this role. We didn’t get to cover our coordination with the marketing team or Squad, our instinctual need to document everything, or our unshakable convictions as to why Google Docs is a poor substitute for traditional Excel sheets! But I’ll just have to leave you with that tantalizing teaser — nothing gets people more excited for a dev diary than promises of spreadsheets!

… or maybe that’s just a producer’s thing.

*: I’m admittedly biased