Hey Anno Community,

We talked about features and designs in the last weeks – and will continue very soon! – but let’s stop for a moment and instead talk about the process of designing game mechanics: let’s talk about Game Design!

In our blog last year, we covered the origins of Anno 117: Pax Romana and how go about creating the creative vision and the basic outlines for a new Anno game. We heavily recommend reading it first before continuing with this blog.

Today – once again with our Game Director Jan Dungel – we’re leaving the initial phase of vision creation and enter the day-to-day work of the Game Design team. A large focus is also put on the creation of design documents with some examples from our current project.

What even is Game Design?

We certainly have covered aspects of this questions already in part one, when we introduced Manuel’s (Creative Director) and Jan’s (Game Director) jobs – but we have many more experts in our team. To lay the groundwork, we quote two definitions for game design from the web:

“Game Design is primarily concerned with player psychology: how will players feel when they experience this? What will they be thinking about? What will they expect, what will they want to do?” – Daniel Klein

“Game Design is the process of creating and shaping the mechanics, systems and rules of a game.” – Wikipedia

These definitions we can wholeheartedly subscribe to. The Game Design Team creates the rules of the game – and translates an experience for the game (e.g. the freezing/cold/desperate feeling of Frostpunk or the growth/progress/exploration feeling of Anno 1800). It translates the game experience into understandable documents (“dreams into reality”) – but it doesn’t BUILD the game. That’s what other departments do based on the designs.

Religion, as a feature, is led by Game Designer Markus as feature coordinator. While Gameplay Programmer Jannik is coordinating the multiplayer feature.

Of course, the team is made up of different specialists and specialist teams, in the same way that e.g. in architecture (a field Jan has previously worked in) you also differentiate between multiple sub-disciplines: architects for the garden, interior, cities, etc.

For design, we have both systems-driven designers for economy and balancing (“excel sheet fans”) and feature designers who create specific features (also with a lot of excel-use, usually). Depending on the game’s genre, you might have different types of specialists or even specialist teams: a hack & slash game, for example, has dedicated combat designers since this plays such a huge role for that type of game.

Then there are Narrative Designers and Writers who create content (story, campaign, …) and support the features (e.g. resident types). We also have a dedicated UX/UI designer in the game design team who forms a strong inter-departmental link to the UX/UI team.

And then we have topics like multiplayer, retention, menu flows, postlaunch etc., which also all have a specialist assigned.

Generally, we aim to assign specialists to the features they do best and prefer to do.

High Concepts

About time we talk about the design process, and specifically: the design documentation. First comes the “High Concept”.

Every single feature in the game receives a dedicated design document in our internal “wiki”. That means, everything from new features like “Romanization” to things like trade routes, residences, placing & destroying buildings, construction areas etc., all receive their own page.

The High Concept is the first step on the “dream to reality” road, and basically is an easy-to-read document with just a few simple statements to give an overview of what the feature is supposed to do. The high concept also aims to answer the “why” question (see the topic of goals from the first blog) and links to other, related features.

Let’s have a look at the high concept page for the Blueprint Mode:

As you can see, it’s fairly concise, and therefore also useful in giving people outside the dev team a quick overview. At the top, it would usually list the members of the feature team (here removed) and the feature coordinator (more on feature teams in our DevBlog on the Production team)

Every design document has to first be approved by the Design Leads before Designers can work on DDDs (Detailed Design Documents), and a DDD has to be approved before work on the feature can begin. This status is also listed at the top.

The approval process ensures that features are in line with the overall vision, but also the scope and the ambitions for the project. However, this process also is an opportunity for designers to convince e.g. Jan of a feature or a way to approach a feature.

Feature Approach

When looking at the screenshot, you may have also noticed a column called “feature approach”.

For Anno 117: Pax Romana (and already back in the days for Anno 1800), we’re splitting our features into three categories: tradition, iteration and innovation

After all, we have a series with long tradition and established features, meaning we have to check every feature with both the series’ DNA as well as the vision for the next game. The three categories are defined as follows:

• Tradition: Makes up the largest part of all features of the game. Features in this category function largely as in Anno 1800 (or older Annos) and only receive very minor changes (e.g. the transportation of goods or the Blueprint mode mentioned above).
• Iteration: Existing features/mechanics that receive larger changes (e.g. workforce or residences)
• Innovation: These are either completely new features, or existing features that receive very strong changes (e.g. romanization).

The idea behind this system is, to ensure we’re creating an Anno game that has all the features that our fans would expect from an Anno game, but also that we’re not stagnating and that we’re improving upon the formula.

Detailed Design Documents (DDDs)

Alright, we have our high concept for the Blueprint Mode approved – time for the DDD!

The Detailed Design Document is the next stage in the design process for a feature: It’s broken down into multiple rules with detailed descriptions for each. Let’s have a look at the DDD for the Blueprint Mode before we continue:

These rules are important for what comes next: the creation of the actual game content. That involves for example the Gameplay Programming department, who assures these rules are reflected in the game itself.

Like the “High Concept”, the DDD also has an approval status.  Only after receiving the “green light” do we move on to the next stage: the kick-off meeting with the feature teams (i.e. with other departments). Kick-off meetings are used for discussing the feature and its implementation, and therefore also serve as a reality check for the feature and the likely efforts involved for all teams. Additionally, questions and concerns might lead to further iterations of the design.

Even though the majority of features do not see any big changes after the DDD has been approved and discussed, occasionally we do run into “oh, it’s not as fun as expected” situations when the development has begun, and the feature has started to take shape.

We said earlier that every single feature receives its own page, and you can imagine that adds up to A LOT over time (roughly 200 feature pages, each with dozens of aspects) . These documents are not necessarily continuously updated and in cases like above, we work with a dedicated “change request” workflow (via JIRA) to document any changes to the designs.

To quote Jan, it’s always worth keeping in mind that “game development can’t be perfect”.

And this is how the blueprint mode then ended up looking in-game in Anno 117: Pax Romana

Prototyping

Not all design documents can be made ready at the same time, of course. Therefore, different features are in various stages of implementation while Game Design continues with the DDDs for others. The order of them and the progress goals (we call them “levels of quality”) for each feature are planned in advance by the Production Team together with the Core Group.

That’s a topic we tackled in the aforementioned Production team DevBlog.

Aside from creating these designs, the team oversees the implementation of said designs and rules, makes further adjustments and handles topics like balancing, for example.

Some features also first get a prototype before “proper” development on them starts. This is reserved for big, important features that either seem tricky or are very new. The diagonal roads were such a case, for example, as mentioned in the DevBlogs we released for them. The prototyping phase tends to be very work-intensive (you want a working prototype quickly but also do regular iterations, sometimes more sometimes less radical) but also is extremely useful – and has about an 80% success chance.

This phase lasts until you either fail – or feel that things are safe now and you have something that can get a proper design document and ultimately an implementation in the actual project. The tricky thing really is figuring out if it’s just not working… or if it’s just not working YET.

As in other blogs, we want to add a general reminder here: All of the processes, the way the team is structured etc., is 100% specific to Anno. Other teams and developers will likely have different approaches that work best for them and their project – for us, this approach has proven to be efficient and effective.

In addition to diagonal roads, land units were also something we worked with prototypes for at first. We had to try out and find the right way for the feature to work in our game.

Working in Game Design

There’s one last question we wanted to ask Jan: how do I become a Game Designer if I’m interested in the field?

Moving from a different department into the job is a common route, for example from QA as some in our team have done. Nowadays, however, there are also dedicated courses at schools/universities that teach you the fundamentals and the combined lessons of now multiple decades of video game development.

Additionally, having a portfolio is a great: be it creating mods for video games or having designed your own board or card game, for example. These things also teach you a lot about what it means to be a designer: it’s not just about generating ideas, but about translating them into a game in the form of rules and features – and “selling” the ideas to your audience.