Letter from the Devs - Producers and Roadmaps

A brief introduction to game production and roadmap construction

Producers: can’t draw, can’t code, can do spreadsheets a little

Game development is very much a team effort. A range of roles - programmers, artists, animators and many others - perform their own specialized functions, directly or indirectly dependent on each other. Some of these roles are self-explanatory. An artist creates visual assets; in 2D or 3D depending on specialization. A programmer writes the code that makes everything go. An animator makes things move and so on. I am none of those things. I do not write code, draw, model or animate anything. I am a producer. Let me tell you a little bit about what I do.

In some ways, producer is a paradoxical term, since we tend not to actually produce anything (if by produce we mean to create), apart from spreadsheets, meeting invites and carbon dioxide. You could perhaps say that a producer creates structure - thereby ensuring the ability of others on the team to create the best possible game and the best possible experience for our players. In the game development character roster, producer is definitely one of the support classes.

Another role with largely overlapping responsibilities is project manager. In practice, the titles are nearly interchangeable. Someone who manages a project and is responsible for making sure that the outcomes of our initiatives match our intentions, and that we keep the timelines we set for ourselves. In other words: that we, as a development team, create what we intend to create and release it more or less when we were planning to.

The tools we have at our disposal are largely communicative: sharing and disseminating information and enabling others to do the same. So, again: meetings and spreadsheets (to be fair, there are other types of documentation than spreadsheets, but they are by far the most fun).

As a producer, I try my best to ensure that everyone on the team has all the information they need, that vision and designs are shared and understood and that work is broken down into manageable bits. What are we doing? Who does which bits? How much work is left? What do you mean we’re out of coffee?

Different types of projects require slightly different approaches, as do different developmental stages within one and the same project. Generation Zero is an operational live service game - meaning it has been released, is available to players and we are continually releasing new updates and patches at more-or-less regular intervals - what we might call a release cadence.

Roadmap: bringing relative order to absolute chaos

For live service titles, one crucial piece of documentation is the roadmap. A roadmap is a high-level (as in not detailed) specification of what updates we plan on releasing for the game, and when. Which month or date will a new patch go out and which features, missions, weapons, vehicles, fixes and so on will go in it?

The purpose of a roadmap is not to give an exact explanation of how every feature is meant to work or what a weapon pack will contain; that goes in design documentation. It does not specify who will be working on what; we have specialized planning tools - like JIRA - for that.

The roadmap should give an easy and quick overview of type and theme for each part of the update. Scope or size of individual parts, as well as the update as a whole, is commonly indicated, as is price point for any paid content. To keep alignment between teams and departments, it is important to include release date and any other important dates such as feature lock dates or build handovers (when a work in progress build passes from one stage of development to another, such as active development to testing, or testing to publishing).

The above constitutes what we would call the development roadmap, which is not exactly the same as the public roadmap that is shared with players and community. The latter will usually contain a subset of data from the former and might be framed as an informative teaser, including some enticing visuals if such exist. Initially, dates are often approximate, but get more precise as the release date approaches. Names or titles and some brief description is also usually included.

While the development roadmap itself should be easy to read and non-complex, the process of setting it up - what we might call balancing the roadmap - is anything but. There are many factors to consider, some of which are difficult to align or harmonize. This part of a producer’s job is a little like doing a jigsaw puzzle, only the pieces keep moving around by themselves and some of them will try to bite your finger when you pick them up.

Some of the factors that go into roadmap balancing are:

• Team bandwidth
• Product vision
• Community feedback
• Technical constraints
• Commercial considerations
• Publishing platforms
  
  It is worth noting that this list is not exhaustive and the items on it partially overlap and tend to interact in sometimes unpredictable ways. It is difficult to illustrate a messy process in a clear and concise way, but here we go.
  
  
  Team bandwidth
  At the heart of roadmap balancing is the shared capacity to create - the team bandwidth. It is crucial not to commit to more than there is potential to accomplish and work needs to be spread out to accommodate this.

As teams and developers gain experience working together within the same project, gauging this capacity - making estimates - gets a little easier. The general interconnectedness of all disciplines and the fact that any feature will consist of many assets and sub-features worked on in parallel, still makes it a delicate and complex process. There are many ways to measure bandwidth and estimate workload, from highly detailed to quite rough, but the goal remains to ensure that ambition matches capacity and that timelines can be kept.

Product vision
A good starting point when deciding where to direct development effort is the long-term, creative vision for the game, as formulated by someone like a lead designer, creative director, or product owner. How do we wish to evolve the story? Which major features do we wish to add? What are our intentions for this world that we have created and populated?

There is a lot to say about how to set, structure and clarify a product vision, but as we have established, producers are not the best equipped to speak about the creative aspects of game development. The purpose of a producer in discussions on product vision is to make sure the team remains more or less grounded in reality and that no one gets too worked up about an idea before we have done at least some cursory investigation of bandwidth. See: blankets, wet.

Community feedback
The community constitutes your end-users and customers. In some respects, they will know the game as well as the development team and their feedback can be invaluable and should be considered. Listening to suggestions from players can be a great help when weighing options or deciding between alternatives. For that purpose, we actively monitor the feedback tabs on our forum and incorporate the popular topics we see there in our discussions.

It can also be worth looking at actual, in-game player behavior. Which missions are started and completed - or more importantly not completed? Which cosmetic items are popular and which are left unused? Are there areas in the game world where players tend to congregate and others that are rarely explored? It is important to listen to what people say, but just as important to observe how they act.

Technical constraints
There will always be technical constraints and limitations to consider. As a game ages and new functionality is appended to old, it grows in complexity. Decisions made in implementation of one feature will have consequences for all subsequent development and bugs tend to accrue. A lot of them will be trivial and can be fixed as time and priorities allow, but some will have tendrils reaching into deep, dark crevices of the project and will be difficult to fix without ripping out substantial chunks of technical infrastructure.

Any game engine and toolchain will also come with its own set of features, limitations or just plain quirks that will impact its suitability for specific types of features or functionality. Ideas that seem self-evident and seemingly simple can come with substantial technical complexity and risk.

Commercial considerations
While game developers are passionate about their craft and not primarily motivated by money, we do occasionally need to eat. We also need to consider expectations from studio management, shareholders or other parties with vested interest in the performance of the games and the studio as a whole. Long story short: games need to generate some revenue.

You need to strike a delicate balance between adding paid content, which brings revenue, and free content, which attracts new, curious players as well as keeps existing players engaged and sticking around.You will also want to pace high-impact releases carefully and ensure you always have something nice and shiny lined up for periods of naturally high engagement - like Christmas.

Publishing and platform owners
Regardless of how and where you want to make your game available to players, it is highly likely that, in one way or another, you will need to deal with a platform provider - someone who owns and controls the delivery and payment mechanisms for your game and any DLC. For consoles, this will be the same company that makes the console itself. For PC or Mac, it might be a game publisher or an online game store / service provider.

Different platforms will have different requirements and expectations, meaning complexity and effort of publishing scales with the number of platforms your title is available from. Usually there will be a period of at least several weeks where an update goes through additional testing to ensure compliance with any platform or store requirements and stability threshold. Depending on your organizational and technical capabilities for parallelization, this can make it difficult to publish concurrent updates too close to each other.

So what now?

Some of you may now ask “What about the 2024 roadmap?”
While we have a good idea for how this year is going to look for GZ, a lot of it is not yet set in stone and we are not sure a roadmap asset like the ones we’ve been doing is the best way to present our plans. Once we’ve decided on more precise timelines, we’ll let you know as soon as possible! Until then, we have a hotfix for stability and the 60FPS for PS5 patch in the pipeline that will be nice to get out of the way.

You see, that’s quite a few hurdles for a dev team to get over in order to bring some structure into the chaos that is game development. It is my job to make all these processes go as smoothly as possible. I hope you’ve enjoyed this little excerpt from my daily life and taken some valuable information about the behind-the-scenes of Generation Zero (and really, every other game) with you. Thank you for reading!

Tommy Forslund
Lead Producer, Generation Zero