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.
