Hey Anno Community,

After introducing you to the setting and world of Anno 117: Pax Romana as well as several of its features, today we’re diving into the topic of HOW we make games – and look at the work of the Production department.

That’s the team planning and organising the entire development process from the beginning and making sure we stay on track over the course of the multiple years that an Anno game takes until release.

For all this, we’re talking with our Production Director Nadin, and Senior Producer Christoph. Both are Anno veterans and assuring a smooth development process for Anno games for many years already.

Let’s first start with their roles specifically, since while both belong to the “Production Department”, we have a split in terms of responsibility: Producing and Project Management. As with all roles in our team, the Production department is deeply embedded into the rest of the development team here in Mainz.

The Production Department

Project Management

We start with Nadin and Project Management.

Project Management is about the management of hard facts: task planning, milestone planning (more on that later), budget & resource planning. It also means defining, and then always keeping an eye on the scope of the project – and adjusting it when necessary.

Nadin and her team are planning the whole project with its individual phases (pre-production, production, post-launch) by transforming the Creative Vision (see this DevBlog on the responsibilities of Creative Director Manuel and Game Director Jan) into tasks. This always happens hand-in-hand with the different departments, as they – for example – need to provide time estimates for their tasks which then make their way into the production plan.

As early as possible, a first plan is set-up to see how much time realizing this original vision would take – followed by discussions on how to make it fit within the given restrictions. Since the team’s health is very important, making sure the plan works with the capacities we have is central.

Should we already identify issues at this early stage, the team tries to address this by:

• Adding more team members to the development (meaning, hiring additional people or outsourcing certain tasks)
• Reducing the scope (meaning, removing certain features or designs) or postponing features (e.g. moving a feature into the postlaunch period, like the co-op mode for Anno 1800).

The management of those external partners is also a responsibility of the Project Management team: contract negotiations, onboarding and the monitoring of their progress.

During production, the team is also regularly cross-checking the development progress with the plans, to make sure the project runs smoothly and avoids crunch – while also assuring we stay on track for the planned release date.

Producing

Now, we take a look at Christoph’s team and “Producing”.

Christoph himself describes the role of his team as one with both internal (dev team) and external (stakeholders) responsibilities. That includes the creation and management of workflows for the dev team, the checking of milestone results and goals as well as the organisation of meetings and syncs to facilitate communication within the departments (i.e. anything related to the project status).

Part of that is also “risk management”, i.e. the anticipation of risks to the development. Those can be all kinds of topics and are coming from the whole team: worries about the timeline, problems with a certain tool which could cost more time, designs that may be difficult to implement or topics that could be tricky to communicate to our players. Anticipating (and subsequently addressing) takes a high priority throughout the whole development.

On top of that, “externally” the Producing team also communicates with other stakeholders within the company. These are, for example, our production contacts at HQ-level, Editorial or Age Rating managers.

Here exists, of course, a big overlap with Nadin’s responsibilities since both are working hand-in-hand when it comes to e.g. updating stakeholders or defining workflows. Meaning: for many tasks the distinction between Nadin and Christoph and their teams is not that clear-cut and requires close collaboration and steady communication on a daily basis.

Just as some production chains require two input goods (Garum needing Mackerels and Salt), a good production department needs close collaboration between both its teams.

Alright, their roles and scope of work established, let’s go in a bit more detail on the Production planning: Which phases does a game go through from first idea to release?

Similar to the blog on creating the Creative Vision, it’s important to mention that while there are many similarities between how different dev teams approach creating their games, each tries to do things in a way that works best for their team and project. Accordingly, the length of the following phases is defined by each team individually. From experience, our Production Team roughly knows how long the Production of an Anno game will take – and taking this into consideration together with the targeted release date, and the defined length of a milestone (see further below), the Production Team can calculate the length of the phases and number of milestones.

Planning an Anno production

Concept Phase & Pre-production – First Playable

It all starts with a vision – and then the concept phase. Here only a small team is involved in getting a feel for the game, outlining general game design, core features and innovations. The small team is not working in a vacuum, of course: Already in this stage the Production Team is involved assessing the potential scope and working on a first plan and estimates. This includes project goals, project size & cost as well as the overall timeline. Those points are further impacted by input and requirements from other stakeholders at the company. The project planning for a game like Anno 117: Pax Romana is rather comprehensive and it’s the Production Team’s duty to bring all stakeholders together.

It’s also important to note that during these phases, the dev team is working on not only a high concept for each feature and mechanic, but also the detailed design documents (DDDs) for them. We’ll get to them in a future blog, but in short: These documents define the scope, as well as “must have” and “nice to have” elements of each feature before they’re being worked on and implemented into the game.

Over time, more people are added to the new project and a first version slowly takes shape, a proof-of-concept basically: the “first playable prototype” (FPP). This version is an important check for us and our stakeholders if the concept works, or if we have taken a wrong turn somewhere and need to go back to the drawing board.

Pre-production is the time where we build the foundation for main production. It’s a time to de-risk the project, a time where we can also test new or difficult features (that’s a topic we will also be addressing in our future DevBlog on Game Design) but also a time to get all the internal tools ready so that the team can start creating content efficiently.

Pre-Alpha & Alpha – Feature Complete and fully playable

This is also called the Main Production Phase. This phase has the goal to finish the implementation of all features, including a vertical slice of their content.

Example: If the game has quests, the feature of quests should be implemented and come with 2-5 quests, so one can assess the feature, but the Narrative team does not have to finish ALL the quests.

Accordingly, this phase is usually NOT about quality, so loads of things will be (visually & in terms of UX/gameplay) in an unpolished state. One could also say: This phase is about quantity NOT quality.

Beta – Feature & Content Complete and Polished

Contrary to the Main Production, in Beta the team will swap priority and try to apply quality to all the implemented features and content. In addition to that, “missing” content (see Alpha Phase above) will be added, e.g. remaining quests, remaining NPCs and so on.

Master – “Refined”

The last phase of production before the release: This one is mainly about bug fixing, performance and memory optimization but also leaves us room for e.g. adjustments to the balancing and similar feedback that we might still get from our players.

It’s also in this phase where our game is submitted to first parties (e.g. Sony and Microsoft) for them to check and approve the version.

When we reached this this point, we would be seeing the finish line, and the release of Anno 117: Pax Romana would be within reach (hello, November 13th!).

Building huge Roman cities in Latium is just a few months away.

Milestones

As discussed above, the Production team creates a roadmap in order to reach certain production levels at certain times. For those, we use milestones.

To quote from our internal documentation: “A Milestone separates the Production into smaller, manageable chunks.” This helps us structure the overall development process, which means we have regular checks on the progress of the project. Accordingly, all milestones have the same length, as they all follow the same workflows.

The team itself agrees on and commits to specific goals that need to be reached by the end of a Milestone. This usually means getting a specific feature or aspect of the game to a certain quality level. Both these quality levels as well as the Milestone goals are defined by the team itself in accordance with the overall production plan originally laid out, and some general Ubisoft guidelines.

For example, while Level of Quality 0 (“L0”) means there has to be a detailed design of the feature that has been reviewed and approved, L1 means that the feature (even though in a very early state with placeholders and work-in-progress elements) is playable for the first time.

Our “Levels of Quality”, visualized via the World’s Fair from Anno 1800.

And what happens when we reach a milestone? Well, we celebrate, of course! We regularly have “Show & Tell” meetings where individual departments present their achievements of the last milestones to the rest of the team – and then enjoy some food and drink after.

Additionally, we also regularly take Milestones as an opportunity to do playtests. Both external ones but also internal ones, when all of us can take some dedicated time to just focus on playing the game. And like our external playtesters, we also fill out lengthy surveys to judge and give feedback on our own game.

However, as you can guess, not every milestone works like a charm. Estimated tasks might take longer, people might become sick and thus aren’t able to finish their work or we find out that a certain implementation sounded good on paper, but actually isn’t that fun when playing.

All these learnings will need to be assessed, and the plan for the upcoming milestones needs to be adjusted.

That means working in Producing and Project Management is not about creating that ONE plan: it’s about creating a plan and adjusting it over and over again to match the production reality – while keeping the project’s goals in mind.

We don’t have THAT MUCH cake every time, that’s reserved for the big milestones.

Feature Teams

To achieve said Milestone goals, we assemble “Feature Teams”.

These are smaller teams focused on a specific feature or feature group and made up of people from different departments that are all working on this specific feature (for example: roads or diplomacy). People usually are in multiple Features Teams (there are maaaaany different features) and together decide on the goals and are responsible for ensuring that the feature reaches said Milestone goals.

They are supported by the Production team to assure proper workflows and scope: as discussed at the beginning, the development has to be thoroughly planned to account for the available time and staff; to assure we’re delivering a quality game on time and without crunch.

Additionally, the Team Leads and the Core Group (made up of the Directors and Senior Leads) are guiding the process and are approving as well as checking the progress and the Milestone goals.

Closing words & learnings

We’re coming to the end of today’s DevBlog, time for some last questions to Nadin and Christoph:

Are you really planning the whole development at the beginning? How flexible is it should something unforeseen happen?

Yes, you need a first full plan at the beginning. This is important to keep control over the project’s parameters (Time, Budget, Quality). As soon as one of the parameters is in danger, we need to take counter measures to make sure the project stays on track. As said earlier, adjusting the plan to fit the production reality is a big part of our work.

Both you and the team have worked on multiple Anno games over the years. Did that result in some “golden rules” for Production planning?

If the plan is not fitting in the beginning it will NOT fit in the end => you have to adjust it right there to minimize the risks.

Be realistic when estimating tasks => tasks that are estimated too optimistically will later-on result in the plan becoming skewed.

Be open and honest: be it good or bad => only with transparency can you build trust within the team and towards our fans.

Did you encounter situations of “let’s do it differently next time” and generally changes to how we produce games over the years?

Production is about managing change. The best workflow is worthless, if it doesn’t fit the team’s needs. So yes: It is a constant evolution of reviewing what went well and what didn’t.

This is especially true regarding planning: how to set up a plan (backlog) how to monitor, how to adjust the plan to be more flexible are key components of our work.

We hope you found this different but extensive insight into our development processes, and specifically the work of the Production department interesting.

Do you have more questions that we did not answer in this blog? Want to know more about the work of specific other departments? Let us know in the comments!