Several months ago, in June, we announced that we’re participating in this year’s Green Game Jam.

Multiple video game studios pledged to brainstorm and implement something in their games to raise awareness for environmental issues like for example deforestation. All this was organized by the UN under the “Playing For The Planet” umbrella – you can find out more about it here.

We specifically decided to support the “Play 4 Forests” campaign with our participation in the Green Game Jam and highly encourage you to sign the petition on their website to protect forests worldwide.

During our gamescom stream in August, we shared a few details on our vision for the new game mode we were planning to add and revealed the final artwork for the mode.

Now we’re nearing the release of the new mode – a scenario we call Eden Burning!

Dear Isabel, …

Let’s set the scene for Eden Burning – what is this scenario all about?

You play as the famous Isabel Sarmento and receive an urgent letter from Yaosca Rodriguez (does the name sound familiar to you?): While the Pyrphorian occupation was ended thanks to your help, many of their buildings and factories remain, dealing continuous damage to the island’s ecosystem.

The main offender: A polluting generator.

However, Yaosca and the other citizens of the island of La Xultuna have now had a taste of modern times – enjoying the advantages of electricity – and do not want to go back to a (literally) darker time. They call for Isabel to take the wheel: Remove the traces of the Pyrphorian occupation and help the people build a hydroelectric dam as a greener source of energy!

You see: Plenty of work awaits you, plenty of challenges on the way to provide La Xultuna with a more sustainable form of energy. And you might want to also explore the smaller islands on the map…

Alright, let’s leave it at that for now because we want you to discover the remaining details for yourself when playing the scenario 😉

Game mechanics – what’s new?

You’re all familiar with how to build your early settlements and cities in Anno 1800. However, for this scenario, you will have to rethink some of your strategies.

First, some general mechanical changes which already up the difficulty: Demolishing buildings will not refund their construction materials (just a portion of their monetary costs) and you won’t be able to move buildings. You can still use the blueprint mode to plan your settlement, though.

Secondly, while “Eden Burning” takes place in a New World session with their two population tiers (Jornaleros and Obreros), we did quite a few changes to their needs: Their very first need is water, supplied by a pump acting like a regular public service building. Later, you will also need to supply them with fish, plantains and tools before being able to upgrade them.

The Obreros, of course, come with their own set of needs, for example Coffee Pots or Atole (a beverage made of corn, sugar, water and some spices – but you will only need corn and sugarcane in this scenario).

Some other mechanics, like influence or happiness aren’t relevant at all in this scenario and have been disabled.

The Eco Balance

So far, those are still mechanics you know, so let’s take a look at the real challenge of the scenario: The Eco Balance.

The Eco Balance displays the health of your island, split into three categories: Water Quality, Soil Quality and Air Quality. Each category can be positively and negatively impacted by your actions and is visualized as a “health bar”.

The main offender at the beginning will be the leftover Pyrphorian ruins scattered across the island. Removing them will not only improve your Eco Balance, but it will also free up valuable building space. However, this does take time and parts of your workforce which you will have to balance with your regular production needs.

Fishing also negatively impacts water quality, while cutting down trees (they’re not replanted by the lumberjack anymore) and generally all kinds of industry also aren’t great for your Eco Balance. You can always check which factors currently influence each category by opening the Eco Balance Overview, see below:

For each category there are specific negative events when the quality decreases too far, requiring you to intervene and (when it decreases even further) catastrophes like a draught might happen. You can also observe the current state of your island by simply looking at the water or the island itself: La Xultuna quickly stops looking pretty when the Eco Balance drops too low. If one of the three categories reaches zero, the scenario is considered failed.

In addition to the pollution through industry, you might also want to change your usual tactic of grouping all farms of the same kind around a Trade Union and Warehouse: Monocultures are not great for soil quality. Instead, plant farms of different types next to each other to improve the soil quality of La Xultuna.

But wait, there is more: Not only the number of trees is limited, mines and clay pits aren’t endless anymore either and you should also keep an eye on the fish population. Make sure to use the available resources wisely and don’t take too much time to tackle your main objective: One of your key challenges will be to maintain efficiency while keeping the environment intact.

Countering negative Eco Balance effects

That does sound tricky, doesn’t it? But don’t worry, there are ways to counter or at least slow down the deterioration of your island’s Eco Balance.

Some we already mentioned (avoiding monocultures, removing ruins) but let’s see what else you can do – at its centre: Crafting!

Thanks to the research centre in the nearby town, you can get your hands on some useful items for your challenge by crafting them at Yaosca’s harbor. Those are either slotted into a Trade Union or Town Hall to for example reduce the eco impact of a building or increase its productivity. They all come with clear downsides, though, so be aware.

Some other items are basically blueprints to unlock new buildings, like for example the water purification plant to help you improve the water quality. There are also methods to replenish certain limited deposits with items – and for trees, you can build a forester.

Finally, you can of course also e.g., pause some of your polluting industry to give the eco system a short breather. But keep in mind your people will still demand goods.

As if building a functioning settlement isn’t enough, there is still your main objective we mentioned at the start: The hydroelectric dam. It is constructed in several phases, each requiring a portion of your workforce and increasingly more advanced goods which require you to expand further and erect more industry.

Failing

Last but not least: Failing is part of the experience. Expect to fail and don’t be afraid to fail.

When restarting the scenario after a failed attempt, you can build on some of your previous achievements which should make your next run easier: The three ruins in the valley don’t reappear if you removed them and certain advanced technologies which you acquired previously will also stay unlocked.

Plus, you will most likely also have learned a thing or two to improve on your next attempt 😉

Wait, what’s a scenario?

Now, we dropped the term “scenario”, let’s talk a bit about the scenario system we developed for “Eden Burning”.

The scenario is separate from your campaign or sandbox games, having its own submenu on the starting screen.

On the overview screen for “Eden Burning”, you will be presented with an intro for the scenario itself, as well as the victory condition. There are different quality levels depending on how you finish the scenario – in this case it’s the time it takes you to construct the dam as well as the island’s health.

Each quality level also provides a certain reward. This reward is then unlocked for all your regular campaign and sandbox games.

While playing the scenario, you can always keep an eye on the victory conditions of the scenario via their separate tracker on the left side.

More on scenarios next year, when we’re looking at Season 4’s content.

The “Plant a Tree” DLC

Also releasing that day is the “Plant a Tree” Cosmetic DLC. This is a special one, since the money from this DLC is going to Ecologi, a social enterprise dedicated to the planting of trees. You can find out more about them here.

Available for 2,99€ (or your regional equivalent) this CDLC adds a new tree ornament to your game which is based on the Ceira tree you can also find on the island of La Xultuna. We are not making any money from this DLC: From each purchase, all net proceeds (that means after any fees or taxes are deducted) are going to Ecologi (at least $1/1€/1£ per purchase).

You will be able to purchase the “Plant a Tree DLC” to support reforestation efforts till the end of March 2022. After this date, it will be removed from the store. No worries, though, as the ornament will be added for free for everyone with an update at the end of 2022.

And in case you missed it: Earlier today we showed off the early stages of the “Eden Burning” scenario live on stream. Head on over to our Twitch channel and have a look at the VOD, if you want to see the new content ‘in action’.

What’s left for us to say? Ah, right: Our Green Game Jam scenario “Eden Burning” will release as part of Game Update 13 free for everyone on December 14^th at 6PM CET!

Stay tuned for Friday when we will publish the full Release Notes for Game Update 13 – and in just a week you’ll be able to save La Xultuna yourself!

Last week we celebrated Anno 1701’s 15th anniversary! With it being the first Anno title developed here at Ubisoft Mainz (back then still Related Designs) and marking the start of a series of Anno titles developed by us, we thought it’s a good time to talk about what’s powering all the Anno games since 2006: The Anno Engine. 

For this purpose, we acquired the help of our colleagues Frank (Senior 3D Programmer) and Jan (Gameplay Programmer). 

Before we dive a bit into the history and developments of the Anno Engine, we should first clear up one big question: What, by Old Nate’s beard, actually is a “game engine”? 

Game Engine Definition 

The game engine is one of the key technologies that our developers rely on to bring all different game elements together and build the overall experience. You can think of it as a platform or framework containing toolsets for integrating elements like audio, graphics, physics simulation, AI, networking (i.e. multiplayer) gameplay code and turn all of them into a playable game. 

Here assets from various other tools are brought together, e.g., all kinds of different audio files, 3D models, textures, etc., and transformed. Usually, the engine also provides you with tools to create different types of assets (in our case we have “Bob” for adding effects, assigning textures and animations as well as configuring the 3D models, as well as the Anno Editor to create islands) which the engine can then use. 

Without a game engine, the development would have to start from scratch each time. And when we’re saying, “from scratch”, we really mean it. Every single logic would need to be created first. Now we can rely on some basic functionalities we will always need, like drag & drop functionalities, water physics, etc.  

An example from another genre would be, for example, that you don’t need to program each time how a character jumps. Just need to tell your character to jump when button X is pressed. The jumping with animations and physics is already in the engine – you just have to provide the character who does the action and the level to jump in. 

We only talked about video games so far, but can such an engine also be used for non-gaming-related things? 

But yes! Game Engines are probably most famously used by (amateur) movie creators to either create whole animated movies or add visual effects. A well-known candidate here would be the Unreal Engine and you can find quite a few examples for that e.g. on YouTube, like this student project here involving dancing birds (a student project from 2019 from students of the University of Applied Sciences Darmstadt). 

A big advantage of using a Game Engine is that it allows for real-time rendering of assets, meaning you can directly adjust, change and add elements and immediately see the results. Using a rendering software (like most big-budget productions) means having to wait for the rendering process to finish before seeing the whole scene in action. 

There certainly are more possible applications, e.g. simulations, visualization of building projects and more.

Another point that’s often discussed when talking about Game Engines is the “graphics quality”. 

Is a game automatically beautifully looking just because it was developed in engine X? Which elements are relevant for visual fidelity?

Yes, to a certain degree the respective engine is responsible for it because of the features and assets it provides.  Those can be things like: 

• The number of objects it can handle (e.g. in one level, on screen at the same time, …) 
• The shader and illumination effects (e.g. raytracing, ambient occlusion, global illumination, …)  

• The quality of the texture streaming (i.e. the resolution of textures as well as the loading and unloading of textures. Bad streaming leads to, for example, texture taking longer to load, first displaying a low-res variant when walking through a level before the high-res version appears.) 
• Animations (e.g. combining different animations for a smooth result) and particle effects (e.g. from explosions, sandstorms, …) 

However, it’s worth keeping in mind that the use of the engine (related to: How well does the developer know the engine and its features?) and the choice of art style also impact what’s often generalized as “graphics quality”. On top of that, the individual user’s hardware and the chosen graphic settings of course also impact the player’s experience. 

Finally, you most likely have heard about other game engines, the two most famous ones probably being Unreal and Unity. This leads us to the question: 

Are some engines better for certain types of games? Could we also create a racing game with our Anno Engine?  

It’s first important to note that big engines are often built to support different kinds of games and styles, while the ones from smaller studios – like ours – are very much built around their specific mechanics and requirements. For example, our engine has to deal with constant changes to the level (things getting built, demolished, transferred, etc. ) as well as masses of objects (displaying a lot of houses, street tiles, etc.). 

Other genres like racing or a roleplaying game are not something the Anno Engine is built for: There’s no support for systems like clothing/equipment for characters or physics effects required for car handling. Additionally, the rendering of the game world is set for a high-up camera perspective, not a first-person view: First-person or third-person games can optimize their engine differently, since for them it’s fine to only render the currently visible objects (albeit in higher resolution), while our game has to be prepared for the player to quickly switch different places in the level (or even to entirely different levels/regions), meaning objects have to stay readily accessible in the memory. 

The Anno Engine 

Now that we cleared up what a game engine is and what it does, it’s time take a look at the Anno Engine itself – how did it come to be? 

Let’s go a bit back in time: While Anno 1701 was the first Anno title the team here at Ubisoft Mainz (back then still: Related Designs) developed, the team had created several strategy games before. So, there was a basis from which to work from, especially since their previous title (Castle Strike, have a look) already was a 3D game – in contrast to the first two Anno titles. 

The team built on this foundation for Anno 1701  – using a variety of new shade techniques like e.g. what the team called the “Schön-Shader” (beauty shader) – and has done so ever since.

As mentioned at the beginning of the article, an engine is like a collection of different tools – and those can also be separately updated, for example, to support new technologies. And while we have been calling it the “Anno Engine” a few times already in this article, this is actually not quite right: Officially, our engine does not even have a name, even though the idea to name it in some way was discussed a few times over the years. A few tools inside the engine have their own names, though, as briefly mentioned earlier.

We already mentioned above in which ways our engine is specialized to fit the requirements of an Anno game. But, of course, we’re already regularly updating our various tools to make the Anno Engine ready for the challenges of our respective next project. 

Bigger changes and updates are usually not added to the live version of one of our games, instead our teams are looking out for and testing new features to be added later, for the next project. To a certain degree, each Game Update is a minor update to the engine, though, when we’re adding new features or further optimizations. 

Improvements are usually proposed by members of the team, even if the final decision lies with the team leads as well as the production team. 

Updates can be improvements to solve issues we noticed during production (e.g. making it easier for artists to add their assets to the engine, adding new illumination/light effects) or other usability improvements and the support for new technologies (e.g. GPU features like tessellation or AMD’s FidelityFX Super Resolution. 

Do you have some more examples?

For 2205 specifically, we greatly reworked the terrain system which then allowed for massive mountain systems and generally more detailed environments. Since back then we’re also using external programs (e.g. World Machine and Mudbox) to make the work of our Level Artists easier. 

If you played Anno 2205 and Anno 1800 you probably also noticed the changes to the session system: Switching between the different regions in Anno 1800 is almost instant and without loading screen – with the downside of the game always having these other sessions “ready”, as described further above. 

Whenever the team is planning to do major engine updates, it is also important to keep in mind those changes can affect other teams as well. For example, changes to the terrain system (e.g. uneven terrain) might have an impact on Game Design topics like street connections (can they still connect everywhere on the building?). 

We hope you enjoyed this excursion behind the scenes of Anno!  

Do you have questions to any of the points of today’s article? Maybe you have worked on some projects of your own, maybe with Unity or Unreal? Let us know in the comments. 

In summer, we talked about the work of our QA teams, which focus each team has and the importance of these teams for the overall production process of the game – doing a lot more than just looking for bugs or playtesting Anno 1800. If you haven’t checked it out yet, we heavily recommend you do so before you continue reading to first learn about the tasks and areas of responsibility of our three teams: our internal QA team, the Live QA team and the Quality Control teams.

And as we mentioned back then, we now want to give you some insights into which steps are taken from finding an issue to a fix being released

In order for you to get a quick first overview, have a look at the graphic below. We will then go into more detail in the blog itself.

Finding or Reporting an Issue

Usually, there are two ways for an issue to pop up on our radar: either it’s being reported by you via one of our channels (or forwarded to us by one of the Anno Companions) or we notice it during internal testing – or playing 😉

In both cases the issue is being put into JIRA, which is a tool that can be used for various purposes, in this case, we use it to report and track bugs. During this process, each issue is categorized on several factors and tagged if required, most importantly: severity (impact of bug if encountered) and probability (how likely will players encounter this issue)

These two factors then make up the priority (e.g., a high probability but low severity issue will result in low or medium priority).

Reproduction

The next step is super important: We attempt to reproduce the issue, meaning we try to make it appear on purpose on our end. This helps us locate potential causes for the issue which in turn makes it a lot easier for us later to address and fix the problem later.

This step can sometimes be quite work-intensive. For example, to reproduce issues from the live version, the QC team sometimes needs a very specific hardware combination for tests, which might be extremely hard to come by.   Sometimes this also means having to work with hardware manufacturers like AMD or Nvidia directly to get or test specific hardware combinations to reproduce and investigate specific issues.

It’s therefore extremely helpful for us if you, when reporting issues to us, add as many details as possible: Can you reproduce it yourself? What did you do before the issue appeared? Which hardware are you using? Etc.

For Anno 1800, due to the variety of options to set up a game and each player’s unique playstyle, it often happens that the Live QA team might need to ask for save files, screenshots, videos or system information after receiving the initial report. This is when the Customer Support and the Community Management teams come into action: They will reach out to the player and provide more information if possible.

These reproduction steps are therefore also detailed in each JIRA ticket so that everyone working on this issue can quickly check it for themselves. Also added is a reproduction rate: Can the issue be recreated every time when following certain steps or does it only happen occasionally? Or are we even unable to reproduce an issue that has been reported to us?

Fixing the Issue

Fixing the issue means further investigating the cause of the problem based on the information provided.

This happens based on the prioritization we’ve done in step 1. Additional factors are available resources inside the team, which can mean that even if an issue has a low priority, the fix will still end up in the update if we have free resources in the responsible department. Keep in mind that the team is simultaneously also working on the next content update or DLC.

We also want to highlight here that of course the team responsible for the fix greatly depends on the kind of issue. A wrong quest text? A missing texture? An item effect not working? Misaligned icons? Each might need a certain specialist to address it.

While in some cases it can be, for example, possible for one of our coders to figure out the cause and location of an issue without reproduction steps, this is not the norm and always greatly extends the time required to create a fix.

That said, any kind of fix can take time because usually finding the exact cause is not a matter of minutes: We must figure out what exactly is leading to the behavior we have observed and reproduced. Additionally, there are possible risks, especially since video games like Anno 1800 are super complex: Fixing one issue can lead to a different system not working as intended anymore, new bugs can appear, etc. Some systems of the game are far more tricky to work on than others.

Testing the Fix

Therefore, each fix needs to be tested properly. Not only isolated just for itself (is the bug solved?) but also in combination with the rest of the Game Update – i.e., the new version of the game. This is to make sure that a fix is not breaking something else, as mentioned above.

Detailed reproduction steps are therefore also important for the testing since we need to know how one could initially encounter the bug: Does the issue now NOT appear anymore after following the outlined steps?

As you might have guessed, similarly to the previous steps, testing isn’t done in a day. We usually enter a “validation period” before we deploy a Game Update. This period usually is about 2 weeks long and consists of two phases:

1. The first one happens internally here in Mainz and it’s a “Feature Freeze” which we call the “Golden Ticket Phase” – because only QA-approved, “golden” JIRA tickets are still allowed to be worked on and included in the update. Everything else will have to wait for a future update.
2. In the second week, our colleagues in the QC teams are doing the validation of the update. We are not working on the update anymore at this point.

Of course, it can happen that a specific fix or even the Game Update itself turns out to be not working or to have issues. In that case, we need to go back to the previous steps (including another round of validations) which in the worst case can mean having to delay the release of the Game Update.

Game Update Release

When the new version has been tested and validated, we’re almost ready for release. During this process, we’re also in contact with colleagues in other teams so everyone is aware we’re planning to release the update that day.

We also usually bundle multiple fixes together in such a Game Update: This might mean that some issues are already fixed and waiting to be released to the live version of the game, but due to the amount of work involved, there is a balance we have to strike between addressing a problem in time while still not overburdening our teams with constant releases.

The “Hotfix” is an exception, and we talked about it in our previous DevBlog.

Our major Game Updates which release alongside a DLC usually go live at 6 PM CET while the smaller ones usually go live at 2 PM CET. And if you haven’t noticed yet: Our favorite release day is Tuesday. ?

Since we regularly see misunderstandings about our internal processes and the time it takes to address and fix bugs and other technical issues, it was a priority for us to shed some more light on this topic specifically.

As we have hopefully made clearer in this blog, the process behind bug reporting and bug fixing is not an easy one: It takes time and, most importantly, a lot of patience and resources. If you have any questions about it or would like to know more about other specific processes, don’t hesitate to reach out in the comments below!