Hey Anno Community,

Not too long ago we told you about Attributes and Needs in Anno 117: Pax Romana, and how fulfilling them will grant you bonuses for your island. In that DevBlog we hinted at 8 different attributes, but didn’t reveal the full list to enjoy the suspense for a little bit longer.

Well, it’s now time to reveal one of those previously hidden attributes: Belief! What does Belief do and what is it connected to? Well, as the word suggests, it is connected to Religion: this is a brand-new feature added for the first time to an Anno game.

The Background

There are different reasons why Religion and Belief have been added to Anno 117: Pax Romana. Firstly, this will allow an additional level of customisation for our players, who will have the chance to strengthen their island identity by choosing which deity to worship on their islands. Secondly, it was important for us to portray the polytheism and cultural diversity of the ancient world which Anno 117 is inspired by.

As you might already know, Roman religion was primarily polytheistic, involving the worship of numerous deities who were believed to influence all aspects of life, by playing an important role in daily events. Among these deities, for example, we can find Jupiter – also known as Jove – god of the sky and thunder, who was worshipped in Rome itself. Or if we think of the “home” of Anno, Ubisoft Mainz: did you know that our office is built above a Roman Sanctuary of Isis and Magna Mater?

How is this been translated in Anno 117: Pax Romana? Let’s now take a closer look at this new feature and its impact on your settlements.

How does it work?

You’ll be able to unlock the Religion feature as soon as you have settled a few Plebeians on one of your islands: this will allow you to place a small temple in your city – the sanctuary.

Once you’ve built your sanctuary, it will be time for you to choose the patron deity of this very island, aka the primary deity you want your residents to worship on that island. You’ll be able to do so from accessing the Religion menu from any religious public building. Every island you have settled can have its own patron that its population worships.

At first, you will only have the option to choose among four deities, but you will unlock more by reaching specific conditions in the game and discovering them via the Discovery Tree. More on that feature in the next DevBlog.

Your starting deities will be Ceres, Neptune, Minerva and Mars; based on your playstyle and what you would like to achieve, it’s important for you to pick the right one: each deity will have its own unique effects for your cities, production and units.

Buff effects

These Patron god effects are unlocked by gathering Devotion over time – with Devotion being tied to the Belief (more on that in a second) in the chosen island Patron. To unlock a buff effect, you will need to reach a specific threshold of Devotion on the progress bar in the dedicated menu. Whenever the Devotion passes a marked threshold, you unlock an improvement to the primary or secondary Patron effect.

What if you would like to change your Island Patron, switching from a peaceful farming community to a war economy? Don’t worry, you can still do that. However, changing the Patron resets the Devotion to zero.

Let’s look together at an example: Neptune, protector of freshwater and the sea. If you choose Neptune as your island Patron, your fishers will feel significantly more courageous: you will notice an increase in productivity of all sea food. Additionally, you’ll attract master craftsmen who not only construct ships faster but also make them more durable.

Ceres blesses your agriculture and population! Her worshippers can increase the yields of farms and the production and storage of farming goods.

And Mars… well, he’s not so much a deity of growth and construction but your troops will have higher morale and fight better when global devotion to Mars is high enough.

Local vs Global effect

Not only do Patrons have a local effect on your islands, but they also have a global effect on all provinces, affecting all islands under your control. This is the effect of your dominant Patron. A Patron becomes “dominant” when its global devotion is larger than a certain threshold: the Patron that has the most added-up devotion on all islands you control becomes the dominant Patron.

Let’s go back to the Neptune example: his global bonus will affect your ships speed, making them faster when sailing the high seas across the map.

The Belief Attribute

Alright, let’s take one step back and talk about HOW you increase Devotion – and Belief.

As we mentioned at the beginning of this blog, Belief is one of the new attributes introduced in Anno 117: Pax Romana. The two main ways of increasing the Belief attribute are:

• Public buildings (like the Sanctuary we showed earlier) which affect building in their radius, resulting in them each providing Belief
• Goods which you provide via the Needs categories (like for example Wine)

There may be some other way (e.g. via items), but let’s keep it at that for now. In short: the more buildings are affected by various effects like these, the higher your Belief.

Devotion in turn comes from your island’s Belief. Over time, Devotion will rise to the same value as the island’s Belief. Therefore, the more Belief you have, the more Devotion will result from it, unlocking the higher buffs mentioned above.

Where do gods live?

As you probably have gathered from the paragraphs above, Anno 117: Pax Romana doesn’t feature “physical” deities which roam your cities or throw lightning bolts at people who offend them.

What we wanted to represent in our game is rather the psychological effect: your people are worshipping certain deities, and find courage and motivation in doing so. They believe that this worship has an effect and work harder (e.g. farmers worshipping Ceres) or fight better (when worshipping Mars).

The sanctuary we showed you earlier is a rather humble place of worship. Later, you will be able to construct mighty temples to dedicate to your Patron of choice. Not only do they influence a much larger area of your island, but they also provide much higher Belief buffs to the surrounding buildings.

No matter which Patron you choose for your respective island: the sanctuaries and temples, as well as the priests they spawn will visually change to fit the worshipped deity.

The ancient time we were inspired by was a polytheistic one, and while each island can only dedicate itself to one dominant Patron god, you can still construct shrines to other deities. These shrines will buff buildings in their vicinity and increase your attributes like fire safety, happiness or income further. It pays off to be a devoted governor.

“What about Albion?”, we hear you ask. Well, let’s say the Celts have their own deities and places of worship. More on that later this year.

Your population is always demanding something new: food, clothes, public buildings, … what do you get from it? Why fulfil all these demands?

Well, alright, because it’s part of the core gameplay-loop of course; but also cause each need you fulfil gives you something in return: citizens pay more taxes, have a lower chance of setting their own houses on fire or are simply happier and less prone to rebel against your glorious governorship.

These bonuses of needs and – as you’ll soon see – also buildings we call “Attributes”.

In today’s DevBlog we will take a look at how we handle these attributes in Anno 117: Pax Romana and how we spice it up with a new little puzzle system.

If you haven’t watched our livestream on the topic, we also recommend to check it out here.

Attributes General

Anno veterans know: attributes are nothing entirely new, things like income, happiness or population have already been a part of past Anno’s and picking which needs to fulfil first and which additional happiness needs (Anno 1800) to fulfil for bonuses are a part of progression strategy.

In Anno 117: Pax Romana, attributes are values provided by different buildings, but to large parts by residences and are primarily increased by fulfilling their needs. Let’s use an example and reference the topic of “Optional Needs” which we have discussed in the previous DevBlog.

Providing your Tier 1 residents with Fish (+1 Population, +1 Income), Tunics (+2 Income) and access to a Market (+1 Population, +1 Income) means all residences supplied this way give you +2 Population and +4 income total (and the residence is now upgradeable).

If you provide them with Porridge (+2 Population), Pileus (hats) (+1 Income, +1 Happiness) and access to a Tavern (+1 Population, +1 Happiness) on top, each residence will provide you with the total following attribute values: +5 Population, +5 Income, +2 Happiness.

(Please note: as we are still very much in development, these and any other balancing values mentioned throughout this blog might still change.)

You can check which kind of attributes each residence is currently providing for you and each respective island directly via the object menu of the building.

It’s not just happiness, income and population, though: we also include fire safety, health and some others (that are related to features we haven’t talked about yet) in this attribute group. Having such a wide range of different attributes and linking them to the needs system means, that we have more options to work with for the needs – and you get a larger number of choices to fulfil the needs that make the most sense for your playstyle or the island’s current situation.

We also want to provide more overall visibility on your islands’ “values” , and therefore now list all these attributes and the source of e.g. the -100 fire safety points in detail in a dedicated bar at the top of the screen. This will make it much clearer to you what’s contributing to the positive or negative value and will help you address e.g. the low fire safety by moving buildings or adding new ones.

Let’s take a closer look at what has an impact on said attributes.

Attributes Details

Of course, needs are something we have already touched on in far more detail in our DevBlog on “Optional Needs”. We highly recommend checking out how needs are handled now in Anno 117: Pax Romana and how we increase your flexibility in regard to with which types of production chains you want to engage with, how fast and where you want to expand to and how this helps you setting your own level of game complexity.

Fulfilling needs plays the main role in how you make money and increase your population: all attribute values a residence provides are dependent on the needs they are supplied with. Higher-level needs also provide higher attribute values, both for fulfilled needs and as buffs (if they’re buildings – see the “Building Buffs” section below).

We always try to link the attributes of a need narratively to the object in question, so that soap – besides increasing your income – also increases the health attributes of the residences supplied.

We also differentiate between two major different layers for the attributes: island values and global values.

An island value impacts island-related features like incidents (fire safety, health, happiness) or workforce, while global values (like province-wide population) unlock new buildings and needs. Income of course also is a global value that can be accessed from any province or island.

Finally, on the topic of calculation, attributes are calculated with decimals and then summed up over the island (e.g. 10 houses with 10% fulfilment provide 10×0,1=1 income), so you’re not losing out on partial values. We’re only rounding numbers for displaying it in the UI, meaning, an income of 1,1 provides 66 money per hour, not 60.

While workforce is linked to your population (or rather: the population attribute of a residence), it’s calculated via a workforce factor that’s also displayed in-game: not every citizen is a worker.

Building Buffs

But wait, we basically only talked about the impact of needs on the attributes of your residences. However, those aren’t the only things that have an impact on your attributes. Let’s talk about “building buffs”.

At the core, this also isn’t something entirely new, since e.g. a fire station already existed in Anno 1800. It increases the fire safety in its vicinity and helps should any fires break out after all. This principle exists the same way in Anno 117: Pax Romana, but we’re now providing more visibility on the fire chance in your city: In the aforementioned attributes bar at the top, you can see how high the fire safety of your island is, which buildings have a positive and which have a negative impact.

The fire station (or Vigiles in Anno 117: Pax Romana), therefore is a buff building.

Similarly, a public service building essentially also provides a buff to residences within its area: if it’s a residence need, it counts towards its fulfilment and gives attributes. If it’s not a need, it still provides additional attributes to the affected residence (and other buildings in its radius)  in the form of a status effect.

What’s new in Anno 117: Pax Romana, however, is that production buildings now also provide buffs (and debuffs) to buildings in their vicinity.

Let’s use the bakery for this example: Within a certain radius around it, the bakery provides a buff of +2 income and a debuff of -2 fire safety to all buildings. This leaves you with the interesting choice of where you want to want to place it: somewhere outside where the reduced fire safety may only impact a few other production buildings? Or in the city to make the most of its income buff?

Other production buildings similarly come with a range of buffs and debuffs which can greatly impact your island attributes. The intention here is to give you something else to puzzle with within your cities and to further home in on the attributes that you need most.

This buff is always applied to all buildings within its radius, which you can already see while constructing the building in question:

As mentioned earlier already, we try to tie the attributes narratively to the object they’re originating from, and anything with an open fire naturally is a risk for any city. Please be careful.

These buffs are non-stackable, meaning that the hat maker, for example,  will only give residences +1 income, multiple hatmakers in the vicinity do not provide the income buffs multiple times

It’s also important to note that the building in questions needs to be functional (e.g. neither damaged/destroyed nor paused) to apply the buff – and production buildings have a productivity threshold which decides if the (de)buff is applied or not.

And finally, to answer a question from previous week’s livestream: Supplying the need to a residence (e.g. hats, to receive +1  income and +1 happiness) and the residence being in vicinity to the production building (+1 income) count as two separate buffs, meaning, the result here would be +2 income and +1 happiness.

Outro

This concludes our two blogs on the topic of Needs and Attributes, which essentially are an evolution of the systems our veterans know from previous Anno games. The Building Buffs are a new feature, which we hope has an impact on your city building strategies.

The Needs Attributes are also closely tied to for example incidents (fire safety, health, happiness) and ways to reduce the chance of them happening, workforce and its relationship to your military (ships require workforce to be built) and some more features which we will talk about in the coming months.

To summarise, our goals are more choice for you which needs to fulfil, greater transparency on the different island attributes and more ways to influence said attributes if you want to get the most out of your cities and production chains.

We’d love to read your comments on these changes and are also happy to answer any further questions you might have on the topic. Leave them in the comment section!

Sometimes playing Anno feels like being a bird parent trying to fulfil the needs of the ever-demanding offspring: Your citizens want clothes, they want sausages, beer, carpets, pasta and energy drinks. Let’s also not forget the marketplace, tavern, laboratory or the concert hall.

Granted, your citizens pay taxes (usually) to make up for the hassle, but they really make you work for that.

In short: needs are a core aspect of Anno gameplay loop, you fulfil them to make money, to make your people happy and to level up residences in order to progress through the game.

Want to see us talk about today’s DevBlog subject? Then have a look at our past livestream from April 15th!

Needs in general

This hasn’t changed much in Anno 117: Pax Romana, on first glance: We still separate needs into two types: consumption needs and service needs.

The former require the player to produce goods (e.g. Porridge) in certain quantities which are then consumed by the residence. As long as enough goods are produced, the need fulfilment slowly rises to 100% and the need is considered fulfilled.

As in past Anno games, the consumption is always calculated for the whole island (“island demand”) and goods are consumed directly out of the island storage. Like in Anno 1800, you can also pause needs (which also pauses the consumption of the respective good).

Service needs are fulfilled via public service buildings. Accordingly, they are fulfilled by the residence simply being within the radius of the service building.

If you’ve played any of our previous games, all of this should feel familiar, just like the next part: Fulfilling needs is how you advance through the game. If you fulfilled enough needs, residences can be upgraded to unlock the next population tier, as well as new buildings and production chains.

The actual activation of a need (i.e. when the people demand for it and start consuming it) is tied to the amount of population of each tier of an island.

Making things optional

Alright, so, but what has changed?

A quick look into the object menu for any residence building will immediately make our Anno veterans stop: needs are ordered in categories! Let’s compare the needs of the Farmers from Anno 1800 with the needs of the Liberti from Anno 117: Pax Romana.

These changes in Anno 117: Pax Romana we sumarised under the feature name “optional needs”.

The different types of needs now all belong to one of multiple categories, for example food, fashion or public services. Higher population tiers have additional need categories that unlock as you progress.

Providing a residence with any kind of good will contribute to the overall supply value of a category. Reach the required supply threshold in all categories and the residence is ready to be upgraded.

Let’s dive a bit deeper into these supply values with two colleagues from the Game Design team: Christian, Senior Game Designer and Jan, Game Director.

Each need has a certain supply value for a category. For example, delivering porridge OR sardines to our residents is equal to a supply value of 1 each. Luckily, the supply threshold for food for the Liberti tier also is exactly 1, meaning we can already consider this category “done” by simply supplying one of the two food needs. If we now also fulfil the “fashion” and “public service” category, we can level-up this residence.

The food category of the Plebeians, however, has a supply threshold of 3. Even if we supplied both sardines and porridge, it wouldn’t be enough. We will have to set up at least one of the new food production chains to reach this threshold.

As a general rule, the supply threshold of a category is always lower than the sum of all supply values of a category – and it will increase with each upgrade of a residence. That means, you will not need to provide all the needs of a category and not setup all the production chains at your disposal, but you also can’t just stick to only providing the lowest (and easiest to produce) type of need in a category.

To visualize this a bit better, have a look at the object menus of a Libertus and Plebeian residence side-to-side. You can see:

• Each needs category has a certain minimum threshold, split into multiple bars
• Each need has a certain value, also represented by bars, which feeds into the category threshold
• The food category of Plebeians has a higher threshold than the Libertus food category
• Fulfilment is represented in green (regular) and golden (more than minimum)

As you might have guessed from the context already, however, upgraded population tiers keep the needs of all previous tiers. Your early game goods and public buildings will therefore continue to be useful, and you can decide if you want to reach the supply thresholds of the different categories by also fulfilling multiple lower-level goods or fewer higher-level ones that each provide higher supply values.

You can’t provide lower-level population tiers with higher-level goods or services, though.

What happens if you provide a residence with more than the required supply threshold, you might ask.

Well, let’s first take a closer look at the individual needs: Each need, no matter if a consumption need or a service need also provides certain attributes.

For example, providing your residents with sardines gives you +1 income and +1 population per residence, while providing them with porridge gives you +2 population for this particular residence. Garum (a need of the second population tier in Latium) gives you +2 income and +1 happiness for said residence, just to name another example.

Accordingly, assuring more than the minimum supply for a category means the respective residences also receive additional attributes – providing both sardines and porridge nets you +3 population and +1 income from the food category per residence.

When a consumption need is only partially fulfilled, you also only receive a part of the attribute bonus (e.g. only +1 population instead of +2 when fulfilling the porridge need only to 50%). At the same time, however, this also means you can reach the supply threshold of a category by combining several partially fulfilled needs.

These “needs attributes” in Anno 117: Pax Romana encompass more than just income, happiness and population and require some more explaining. Today, we’ll leave it at this since it’s enough to understand the basics of the “Optional Needs” feature – and go into more detail in a separate DevBlog soon.

Implications

So much for the “how”, let’s take a look at the impact of these changes on the game and the answer to the “why” question.

Firstly, something we have already alluded to earlier in this blog: choice and flexibility.

This was especially important since we wanted to let players choose the level of complexity for the game themselves. The goal here is to give enough choice that both veterans as well as newcomers can enjoy Anno 117: Pax Romana, and for the latter to slowly grow into their role as governor.

With a lucky combination of fertilities on your starting island, you might even be able to continue to progress through the population tiers there for longer, allowing you to stick to fewer islands and only expand later, if you so desire.

This focus on choice also impacts the type and complexity of production chains you can pick: how many complex needs do you fulfil? Will you go for fewer but more complex production chains or more but less complex ones? Which ones take up more space?

Another point of choice also related to the provinces: As already announced last year, you will be able to start in either of the two provinces at the start of a new game. With the optional needs system, you will be able to remain in a single province and still reach the highest population tier by solely relying on providing needs that you can produce locally.

Higher population tiers mean more needs – and more choice! Let’s compare the needs categories of a Libertus with that of a Plebeian. As mentioned earlier, there’s also a fourth category added now: household goods.

As mentioned, it was equally important to us to provide challenges and reward experienced players if they provide their citizens with more than the minimum of needs category. The additional attribute bonuses will help you sustain ever larger cities and militaries, compete more effectively against opponents and strategically grow your influence in both provinces by, e.g., taking key islands.

Making use of both provinces will therefore provide different rewards and options. As will Romanising your population in Albion – if you manage to provide them with goods imported from Latium – and following both the local and the Roman path at the same time.

Lastly, this system also gives us as developers more flexibility: new content and new needs can be integrated into the game much easier than it has been the case in Anno 1800. It gives you more choice and makes expanding the game easier for us, if we’re looking at the topic of “postlaunch”. And we already have more different needs in the basegame compared to Anno 1800!

Outro

We hope this has given you a good idea of the changes we have done to the needs system and how it gives you, the player, more flexibility in terms of how you want to set up your islands both in Latium as well as Albion and how you can scale the challenges of the game to a degree you feel the most comfortable with.

Additionally, there’s a cool new puzzle aspect to city building that will hopefully also motivate you to build more than the minimum required production chains. What that is? Well… that’s a topic for a future DevBlog.

Until then, leave all your questions and feedback below, we’re looking forward to your comments!

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.

Salvete, Anno community!

My name is Björn Frechenhäuser and I am a Senior Level Artist working on Anno 117: Pax Romana. I have been at Ubisoft Mainz for 12 years and after Anno 2205 and Anno 1800, this is the third Anno game I have the pleasure of working on. If you’d like to see some of my work on previous installments, you can check out my Artstation profile.

Level Art can mean a lot of different things, very dependent on which company, which studio and which project you work for. It can be more centric around the creation of 3D assets and textures or the visual development and dressing of levels or storytelling in the world and its locations. So, what does it mean for Anno? In short: all of the above (and more). But either way, at the heart of Level Art is always – you guessed it – the level. For Anno the level consists of the game world and its islands, which serve as canvas for players to build their cities on.

In today’s DevBlog I want to give you an insight into how islands are being created, what our processes are and how we tried to achieve the next step after an extremely successful Anno 1800.

From Anno 1800 to Anno 117 – what has changed in island creation?

At the beginning of every new Anno game, we ask ourselves: What do we want to achieve? What do we want to improve? What do we want to drop? For us in Level Art, the mission was clear right from the start: We wanted to create the best looking, most natural, most diverse, most immersive game world in the series. Sounds easy enough, right?

Of course, going forward meant more of an evolution than a revolution because the levels are still bound by the game’s rules, the balancing of its features and the performance of our target platforms – as they have always been. During the postlaunch of Anno 1800 we started researching in different directions and in this blog, you will see some of the breakthroughs we achieved.

Procedural Texturing

In the past we had already established a procedural content creation pipeline for some aspects of our island creation process, namely the generation of the island’s terrain – you can read up on it in this older DevBlog for Anno 1800. However, the texturing process of the islands (which involves adding materials such as grass, rock, sand, etc. to your terrain) was mostly a manual, elaborate but somewhat repetitive procedure back then. Furthermore, the resolution at which our textures could be added to our islands, the so-called “texture splatting resolution”, was too low. So, with the help of our Graphics Programming department we quadrupled our texture splatting resolution for the ability to splat textures with much more control and way more detail.

Now we use the so-called “splat maps” generated together with our terrain that use algorithms that simulate aspects of nature such as erosion, thermal weathering, deposition, terrain wear and many more.

Texture Displacement

The procedural texturing already added a layer of diversity and natural look that we couldn’t achieve before, but we wanted to go further to improve how the textures themselves shape our visuals. We implemented a technique called “displacement mapping” that allows textures to not only sit on top of the terrain but change the shape of the terrain and increase its visual quality without the use of actual 3D assets.

Terrain Steepness

Another lever we wanted to pull to make our islands look more natural and realistic was playing around with the steepness of the terrain and consequently the slope on which our buildings could be built. Anno 1800 had a maximum terrain angle of 12%, which presented us a significant limit for island design.

For Anno 117: Pax Romana, we aimed to increase this angle. Researching this topic was a significant collaborative effort involving multiple departments, including not only Level art, but also Art Direction, Game Direction, Graphics Programming, Game Design, 3D Art, and Gameplay Programming. This extensive teamwork was necessary because the topic is closely related to nearly every aspect of our building system. After a lot of back and forth and countless hours of testing we decided to go for it and doubled our maximum buildable terrain slope to 24%.

With these new improvements on our toolbelt – among many others – it was time to start our journey of designing and creating the world of Anno 117: Pax Romana. Below I will show you a simplified breakdown of how an island is being created from the first to the last step. 

Island creation in Anno 117 – from simple ideas to in-game islands

Setting a course

Before creating even just a single pixel of an island, we ask ourselves some questions: What should our world look like? What expectations do we want to fulfil? What stories do we want to tell? During this phase, we gather hundreds of reference pictures and explore many different ideas together with Concept Art to nail down what look and feel we want to achieve. This is when, together with Art Direction, Game Direction and Game Design we developed our two provinces Latium and Albion. We designed their look, established their uniqueness and set the ground to develop a visual direction that would serve as a guide for our creation process.

Island Conceptualisation

The first step to creating an island is always thinking about shapes, volumes and topology. Additionally, we need to establish a set of rules with Game Design: rough island size, available construction space, required beach areas, mining lode amount, etc. Once this is done and we have all the ingredients, we can start creating the first island concepts.

Unlike Anno 1800, we start our island concepts directly in 3D, using a tool called “World Machine” which has already been in use since Anno 2205. By doing this we can already get a much better feeling for an island, and this lays the groundwork for later iterations. Thanks to the procedural pipeline we set up, we can create dozens of island concepts relatively quickly. Once a batch of concepts is produced, we sit together with Game Design and Art Direction to decide which islands are fitting to be approved for further production.

Blockout

Once an island concept is approved, we create a first playable blockout version of it to further iterate its topology and the balancing of construction areas, beach locations, mining lode amounts etc. Moreover, we do a first texturing pass to check the look and feel. Besides World Machine, during this phase we work quite a bit with our proprietary tool called “Anno Editor”, to implement the gameplay features mentioned above. Still, we stay as open and flexible as possible because we might need to make a lot of changes to the island along the way.

Visual Design

After numerous iterations of the blockout version we eventually reach a state where all gameplay and balancing aspects of the island are set and approved. Now we start working on the visual aspects of the island. A lot of the visual detail already came from our procedural workflow as described and additionally we scatter vegetation assets using a tool called “Houdini”.

Once all the procedural steps are done, our base island is ready: it’s now time to start working manually on the details and flesh out the visuals of the island by adjusting textures, placing rocks and vegetation assets, adding decals, giving more character to the topology, implementing particle effects, adding waterbodies, and so on. 

Polishing

The final step of our island creation process is a polishing pass. On the one hand, it encompasses visual polishing according to feedback we receive, adding more unique details such as environmental storytelling or adding points of interest, and on the other hand it encompasses gameplay polishing to make sure all the features work as expected (e.g. buildable beaches, mining lode, forest locations, etc.), implementing audio with our Audio team and making sure that there are no bugs occurring.

We cannot wait to see your awesome cities built on our islands, read about what your favourite (or least favourite) islands are and which of the details we so carefully crafted you discover along the way!

Not long ago we gave you a first look at how we’re handling roads in Anno 117: Pax Romana and how we improved the grid with additional functionality by allowing for diagonal building of roads and buildings. If you missed it, catch up by following this link.

In today’s blog, we’ll be looking at the challenges the team faced when making the game work with these new options and how they resolved them.

We’ll also cover a few further implications of these changes, since roads aren’t the only thing you’ll build in Anno 117: Pax Romana, of course.

A quick recap

For Anno 117: Pax Romana, we upgraded the building grid with additional functionality to allow for diagonal roads and buildings. For this, we sub-divided each grid tile into 4-subtiles, which allows us to still calculate and place objects precisely into the grid even at a 45° angle.

Building diagonally does help making both streets and anything connected to them look significantly more organic and changes the look and feel of your cities, production areas and the islands overall.

Despite these new options, our focus was to still make building roads as straightforward and simple as before, where a few clicks connect two points on the island no matter how they are orientated on the grid and where buildings snap to the roads automatically when placed nearby.

The challenges

Now, let’s dive a bit deeper into what we did to get there.

There are a few different ways to bring more flexibility into a builder game like ours, and before the project went into production, we made a prototype and tested all possibilities (all angles allowed, only 45° angles allowed, different rasterizations, different connectivity logics). The most drastic would’ve been to completely remove the grid. A clear disadvantage, however, would have been that it would have become almost impossible to play “Anno-Tetris”. Like playing Tetris without a grid, it would have felt rather strange and unsatisfying and not really like an Anno game anymore.

Once we had found a solution that seemed like it would benefit the game, we went with it.

Let’s cover a few more topics that we had to work on due to the upgrade of the traditional Anno grid:

If you build a road from point A to point B, the game has to suggest a path for the road to take – but diagonal roads mean far more potential paths for the roads. In Anno 1800 a street in an open field has only two options: It can either go first vertical and then horizontal or first horizontal and then vertical. In Anno 117, there is also the option to go first in diagonal or to end in diagonal. More options are cool, but it can be tricky to know what to use when we build streets.

We experimented a bit on this topic, trying different solutions. At first, we tried to guess the intent of the player. Depending on the mouse movements we tried to guess if the player wanted to go first diagonal, or have a 90° angle, or finish in diagonal. In practice it was not reliable enough and the player had to manually change the orientation of the street.

After a lot of tweaking and experimenting, we’ve decided to try a much simpler solution: to always first use a diagonal street and then end with a vertical or horizontal one for the second segment. Sometimes the simpler solutions are the best.

And of course, if there are buildings in between, the street will automatically avoid them.

Farm fields were also adjusted to work in this new context, now able to fill gaps that aren’t the size of a full tile. This is done via a polygon tool that can take full advantage of the sub-tiles we described in the first blog. You probably already spotted this on previous screenshots, but let’s take another look:

The wider impact

We’ve only talked about roads so far but of course any changes to the grid system also impact everything else you build – from houses over ornaments to the mentioned farm fields.

It’s also important to go back to a point from earlier and state that while these changes will turn your cities into significantly more beautiful creations, the efficiency-focused builders among you will probably appreciate to know: Yes, you are losing more space by building diagonally, for a few different reasons.

Firstly – and that’s a lesson from the Anno 1800 days: building beautiful always means “wasting” precious grids that could be used for more residences or more production buildings. Making full use of the new flexibility with diagonal roads and buildings is very much a feature aimed at players who prefer a more organic look for their cities.

Also, we are actually changing the “logical scale” of objects upon rotation. Why and how? Well, let us explain:

Since the single tiles of the old 90 degrees grid are now divided into 4 sub-tiles each, we have to make buildings fit this more detailed grid-structure when turning them by 45 degrees. This can mean slightly increasing or decreasing their size – whatever value in the grid is closer. That, however, doesn’t mean that the building itself, the house (the “mesh”) changes in size, but that the space it occupies/blocks gets larger. Its groundplane (i.e. the ground the building/ornament is placed on) automatically adjusts to make sure there aren’t any weird gaps or overlaps.

Let’s make it a bit easier by visualizing what happens on rotation in our grid:

As you can see, the objects, after being rotated, do not align with the sub-tiles and have to be adjusted first to fit the grid. Of the two options, the one closest in terms of blocked area is chosen. The side length of the 1×1 object changing so much here was one of the reasons we opted for a separate solution for the farm fields, as mentioned previously.

Even if the blocked area increases, the building itself stays the same size. Below you can see what the potential impact of the rotation and scaling can look like. These are just examples for visualization, there are no 1×1 houses 😉

As you can see here, the mesh always remains the same size, even if we have to block more space to make the object in question fit into the grid. 

Non-square buildings are handled in the same way, of course, and depending on the building the blocked area might be bigger or smaller compared to it being built in the traditional grid layout. 

Additionally, we also opted to slightly increase the width of streets (visually) so that they’re a bit wider than a single grid. With both these solutions we avoid what we had internally started calling the “green gap”. 

On average, taking advantage of the diagonal option means that you will use slightly more space.

And when we’re already talking buildings: Let’s not forget a key aspect of Anno’s city building – connecting all your buildings with roads! Production buildings don’t function, and residences don’t get their needs fulfilled if they aren’t connected to a road.

In Anno 1800, at least one road tile had to connect to the building with one of its edges. Simply being in proximity and passing by the building would not count.

In Anno 117: Pax Romana, however, with the option of diagonal roads, we are suddenly faced with more ways in which roads and buildings could interact. For example, a road can just pass by one corner of the building – do we still count it as connected?

The answer is: yes, we do. The game will also help visualize this connection by adding a little cosmetic connection between road and building (marked in blue below). This way something like the below is possible, if you so desire:

As you can see, only 45° angles count for the road connection. 90° connection as in the example on the left side, still are not possible.

Well, that concludes our two-part series on the grid in Anno 117: Pax Romana! 

We hope this not only calms anyone who was worried that we’re getting rid of the grid, but also gave everyone who enjoys a little bit of a look behind the scenes some insights into our processes and the sometimes-unexpected challenges when doing changes to something so central like the grid. 

Please let us know if you liked these kind of development deep-dives and leave any open questions you might still have for us on our social channels, Discord or Reddit, so we can address them later.  

You can also expect to see the new diagonal building options in action later on in videos and livestreams. Until then: have a fantastic Friday!

Hello Anno Community,

As you might have guessed from the title, today’s DevBlog will focus on modular ships in Anno 117: Pax Romana. If you watched our segment at IGN FanFest, you have probably heard Manuel Reinher, Creative Director, talk about this new feature; therefore, let’s have a closer look at modular ships!

Anno & ships: a 27 yearlong cruise (and counting)

Since 1998, ships have always played a key role in Anno games: whether you were transporting tools after desperately buying the whole stock from the travelling merchants in Anno 1602 or efficiently coordinating trade routes in Anno 1800, you certainly have sailed the high seas in some shape or form while playing Anno.

It should not be a surprise to you all, then, to see ships play a key role in Anno 117: Pax Romana. However, unlike earlier Anno games, Anno 117: Pax Romana will change things up a bit with a new feature: ships will be modular, and you will be able to select different types of modules to customise and specialise them for economic or military roles.

We spoke to Markus, Game Designer on Anno 117: Pax Romana about this new feature: “The idea of introducing modular ships to the Anno was going around already for a while. With the Roman setting we had the perfect platform to do it, since it is very true to how the Romans themselves built their ships. In Anno 1800, we made good experiences with the ship items and wanted to build on the experience of customizing your ships to the specific tasks you had in mind for them and represent your choices also in the visuals of your ships this time.”

Thus, just like Romans, in Anno 117: Pax Romana you’ll build your ships modularly: this design is historically inspired by their building techniques. Romans typically constructed their ship hulls with a flat deck and then attached different modules to them.

Ships: how do they work?

“They float on water”, you might answer. That’s true, however, we are not here to discuss physics.

Just like previous Anno games, you will build ships in the Shipyard. When opening its menu, you’ll be offered a list of pre-designed ships. Upon selecting and clicking on a ship, you will initiate the construction phase and consume the resources needed; the ship production, of course, will also require time. During this phase, the Shipyard will cost workforce and money; if the workforce is insufficient, the construction speed is reduced, resulting in longer production times.

In the Shipyard construction menu, you’ll be able to choose between three different types, based on the size of their hull, that you unlock throughout the game:

• Penteconter – small ship
• Trireme – medium ship
• Quinquireme – large ship

The new modular system

If you feel that none of the predefined ships quite suit your needs, then it’s time to customise them based on your preferences and requirements.

When it comes to the customisation of your ships (aka modularity), the hull will influence the number of modification slots your ship gets. Slots determine the cargo capacity of a ship and can be used to install modules. However, larger ships also mean slower acceleration – something you’ll need to keep in mind when preparing your fleet!

• Penteconter: 2 modification slots
• Trireme: 3 modification slots
• Quinquireme: 4 modification slots

By adding modules, you will influence different aspects of your ship: its stats (e.g. health points, speed), its function (e.g. naval combat) and, of course, its appearance.

There are multiple types of modules that you can use, each one with a different feature:

• Mast: additional speed when sailing with the wind on long distances, reaching higher max speed and higher speed when sailing between regions
• Rows: additional speed, reaching higher minimum speed and acceleration, with smaller turn radius; it’s perfect for short ranges and combat
• Reinforced Hull: additional HP
• Archer Tower: shoots many small arrows in all directions on short range
• Scorpio: shoots high-precision spears and deals high damage mid-range, only on the sides
• Onager: Shoots rocks with high range and highest damage, but low accuracy and towards the front

With the construction menu, we wanted to show the player a preview of the ship configuration while setting it up. However, it was not feasible to only use regular 2D elements like Icons in the UI, as it would either look too simple, by just listing the elements, or too complex, by trying to show a preview in 2D which follows the exact same rules as the ship would follow in game. Therefore, we tried to show the full 3D model of the modular ship in the UI, the same as it would show up in game when built. That worked quite well, and we are going with that approach since then.

-Jannis, Gameplay Programmer

When building your ships, there will be some limitations in place. Each module can only be built a limited number of times per ship; for example, on a trireme you’ll be able to build only a maximum of 2 catapults or archer towers. If you like numbers, you might be interested in knowing that for a penteconter there will be up to 16 different combinations of modules, 60 for a trireme, and 114 for a quinquireme.

Once you finish adding modules to your ships, the cargo slots will be calculated from its original capacity minus the used modification slots. Each module always takes up exactly one cargo space slot. However, to ensure that ships always retain some cargo capacity, we have made sure that a certain number of cargo slots remain free and cannot be used for modules.

Be careful, though: you can choose and modify modules for each slot only during ship construction – once the ship is built, you won’t be able to modify its configuration anymore. And if you’re wondering: yes, you will be able to save your ship configurations! Each Shipyard has 2 slots per ship type, this means 6 slots in total. If you want to have a third custom ship, you will need to build a new Shipyard.

Modular ships and Items

We know what you’re about to ask – what about Items? Yes, just like in Anno 1800, you will be able to equip Ship Items. For example, each of your ship can have its own Captain equipped on board! But let’s not get ahead of ourselves, we’ll talk about this in more detail in the future.

Dev insights: some behind-the-scenes about the modular system

As you can imagine, implementing this feature came with its fair challenges – from different points of view. When it comes to Game Design, for example, Markus mentioned that it was crucial to design the system in a way that it as flexible as possible without breaking any logic or visuals, while keeping it simple and intuitive for players to use.

For the art team instead, one of the challenges was to understand how big a ship module should be in order to be compatible with the beloved Anno grid. It might not seem obvious at first, but just like roads and buildings, the grid applies to the ocean too – that means that ships move within the grid. “This required a lot of back and forth: first we prototyped by building simple grey blocks and figuring out if that measure worked in the grid, then we made it work visually.” – Rolf, Expert Artist

Jannis, Gameplay Programmer, told us about the challenges they faced to create a system that is flexible and at the same time easy to maintain. “The placement of modules on the ships is dynamical. As the number of possible combinations is quite high it is not possible to create static files for all combinations, but we have to create the ship dynamically on runtime in the game when a ship is created, as in we calculate on which positions which slot gets installed and place it visually and logically at that slot index.

How this happens is defined by a few rules that we had to iterate on a lot. Furthermore, we had to split the system into a logical part: ‘where and how should modules be linked to?’, and a visual part: ‘which 3D models are used in which situations?’. For example, a mast at the front of the ship has to look different than a mast in the center of it. This allows us to efficiently set up modular ships, validate each possible configuration and create different visual variations e.g. for special participants such as pirates.”

This means that, not only does each module have a different feature, but they also have a different priority in relation to other module types. This priority influences the slot the module will occupy when the ship is configured: each module has a preferred slot to be on; however, if the slot is already occupied by a module with higher or same priority, the module is placed on the next open slot that is further outside. If all slots further outside are occupied, it will move to the next open slot towards the middle of the ship. This is to make sure that placement of the modules will result in a nice, good-looking structure on the ship.

Workforce, construction and maintenance costs

Unlike previous Anno games, ships will now require workforce not only during the construction phase, but also to function. “We moved away from the more artificial and abstract influence limitation established in Anno 1800 to the more grounded and realistic workforce approach. This will lead to a much tighter tie between your economy and your Naval capacity.” – Markus, Game Designer. However, this is a bigger topic that will be addressed in a future blog – so, watch this space if you’re curious to know more!

The construction and maintenance costs of the ships change depending on the installed modules. For example, rows will be more labour intensive then sails – this means they will require more workforce. Same thing for the Archer Tower compared to the Onager, as there are more soldiers involved.

Well, we hope you enjoyed reading through this (quite long) blog on Modular Ships! As mentioned above, expect more to come on the ship topic, in which we’ll focus on naval combat and the ship system in general. In the meantime, if you have any questions, never hesitate to reach out!