Letzte Woche haben wir das 15-jährige Jubiläum von Anno 1701 gefeiert! Da es der erste Anno-Titel war, der hier bei Ubisoft Mainz (damals noch Related Designs) entwickelt wurde, und den Beginn einer ganzen Reihe von Anno-Titeln markiert, die von uns entwickelt wurden, dachten wir, es sei ein guter Zeitpunkt, um über das zu sprechen, was alle Anno-Spiele seit 2006 angetrieben hat: Die Anno-Engine.

Zu diesem Zweck haben wir uns die Hilfe unserer Kollegen Frank (Senior 3D Programmer) und Jan (Gameplay Programmer) gesichert.

Bevor wir ein wenig in die Geschichte und Entwicklung der Anno-Engine selbst eintauchen, sollten wir zunächst eine große Frage klären: Was, beim Barte des Alten Nates, ist eigentlich eine „Game Engine“

Game Engine Definition

Die Game Engine ist eine der zentralen Technologien, auf die sich unsere Entwickler verlassen, um alle verschiedenen Spielelemente zusammenzubringen und das Gesamterlebnis zu gestalten. Man kann sie sich als eine Plattform oder ein Framework vorstellen, das diverse Werkzeuge für die Integration von Elementen wie Audio, Grafik, Physiksimulation, KI, Netzwerk- (d. h. Multiplayer) und Gameplay-Code enthält und all diese Elemente in ein spielbares Spiel verwandelt.

Hier werden Assets aus verschiedenen anderen Tools zusammengeführt, z. B. alle Arten von unterschiedlichen Audiodateien, 3D-Modellen, Texturen usw., und umgewandelt. In der Regel stellt die Engine auch Werkzeuge zur Verfügung, um verschiedene Arten von Assets zu erstellen (in unserem Fall haben wir „Bob“ zum Hinzufügen von Effekten, Zuweisen von Texturen und Animationen sowie zum Konfigurieren der 3D-Modelle, sowie den Anno-Editor zum Erstellen von Inseln), die die Engine dann verwenden kann.

Ohne eine Game Engine müsste die Entwicklung jedes Mal bei Null beginnen. Und wenn wir sagen „bei Null“, dann meinen wir das auch wirklich so. Jede einzelne Spiellogik müsste erst erstellt werden. Jetzt können wir uns auf einige grundlegende Funktionen verlassen, die wir immer brauchen werden, wie Drag & Drop-Funktionen, Wasserphysik usw.

Ein Beispiel aus einem anderen Genre wäre zum Beispiel, dass man nicht jedes Mal programmieren muss, wie eine Figur springt. Es reicht, der Figur zu sagen, dass sie springen soll, wenn die Taste X gedrückt wird. Das Springen ansich samt Animationen und Physik ist bereits in der Engine enthalten – man muss nur die Figur, die die Aktion ausführt, und den Level, in dem gesprungen werden soll, bereitstellen.

Wir haben bisher nur über Videospiele gesprochen, aber kann eine solche Engine auch für andere Dinge als Spiele verwendet werden?

Aber ja! Game Engines werden wahrscheinlich am bekanntesten von (Amateur-)Filmemachern verwendet, um entweder ganze Animationsfilme zu erstellen oder visuelle Effekte hinzuzufügen. Ein bekannter Kandidat wäre hier die Unreal Engine und man kann eine ganze Reihe von Beispielen dafür finden, z.B. auf YouTube, wie dieses Studentenprojekt hier mit tanzenden Vögeln (ein Studentenprojekt aus dem Jahr 2019 von Studenten der Hochschule Darmstadt). 

Ein großer Vorteil der Verwendung einer Game Engine ist, dass sie das Rendering von Assets in Echtzeit ermöglicht, d.h. man kann Elemente direkt anpassen, ändern und hinzufügen und sieht sofort das Ergebnis. Die Verwendung einer Rendering-Software (wie bei den meisten Big-Budget-Produktionen) bedeutet, dass man warten muss, bis der Rendering-Prozess abgeschlossen ist, bevor man die ganze Szene in Aktion sieht.

Es gibt sicherlich noch mehr Anwendungsmöglichkeiten, z.B. Simulationen, Visualisierung von Bauprojekten und mehr.

Ein weiterer Punkt, der oft diskutiert wird, wenn es um Game Engines geht, ist die „Grafikqualität“.

Sieht ein Spiel automatisch schön aus, nur weil es mit der Engine X entwickelt wurde? Welche Elemente sind für die visuelle Qualität relevant?

Ja, bis zu einem gewissen Grad ist die jeweilige Engine aufgrund der von ihr bereitgestellten Features und Assets dafür verantwortlich. Das können Dinge sein wie:

• Die Anzahl der Objekte, die sie handhaben kann (z.B. in einem Level, gleichzeitig auf dem Bildschirm, …)
• Die Shader- und Beleuchtungseffekte (z.B. Raytracing, Ambient Occlusion, Global Illumination, …)
• Die Qualität des Textur-Streamings (d.h. die Auflösung der Texturen sowie das Laden und Entladen der Texturen. Schlechtes Streaming führt z. B. dazu, dass die Textur länger zum Laden braucht und beim Durchlaufen eines Levels zunächst eine niedrig aufgelöste Variante angezeigt wird, bevor die hochauflösende Version erscheint).
• Animationen (z.B. die Kombination verschiedener Animationen für ein flüssiges Ergebnis) und Partikeleffekte (z.B. von Explosionen, Sandstürmen, …)

Es gilt jedoch zu bedenken, dass die Verwendung der Engine (bspw.: wie gut kennt sich der Entwickler mit der Engine aus?) und die Wahl des Grafikstils ebenfalls einen Einfluss auf das haben, was oft allgemein als „Grafikqualität“ bezeichnet wird. Dazu kommt, dass die verwendete Hardware sowie die gewählten Grafikeinstellungen des einzelnen Spielers sich natürlich ebenfalls auf das Spielerlebnis auswirken. 

Schließlich habt ihr wahrscheinlich auch schon von anderen Game Engines gehört, wobei die beiden bekanntesten wohl Unreal und Unity sind. Das führt uns zu der Frage: 

Sind manche Engines besser für bestimmte Arten von Spielen geeignet? Könnten wir mit unserer Anno-Engine auch ein Rennspiel erstellen? 

Zunächst einmal ist es wichtig zu wissen, dass große Engines oft so gebaut werden, dass sie von Grund auf verschiedene Arten von Spielen und Stilen unterstützen, während die Engines kleinerer Studios – wie unsere – sehr stark auf ihre spezifischen Mechaniken und Anforderungen zugeschnitten sind. Unsere Engine muss zum Beispiel mit ständigen Änderungen im Level (Dinge werden gebaut, abgerissen, verschoben usw.) sowie mit Massen von Objekten (Anzeige vieler Häuser, Straßenkacheln usw.) umgehen.  

Für andere Genres wie Rennspiele oder Rollenspiele ist die Anno-Engine nicht ausgelegt: Es gibt keine Unterstützung für Systeme wie Kleidung/Ausrüstung für Charaktere oder physikalische Effekte, die für das Fahrverhalten von Autos erforderlich wären. Außerdem ist das Rendering der Spielwelt auf eine hohe Kameraperspektive eingestellt, nicht auf eine Ego-Perspektive: First-Person- oder Third-Person-Spiele können ihre Engine anders optimieren, da es für sie in Ordnung ist, nur die aktuell sichtbaren Objekte zu rendern (wenn auch in höherer Auflösung), während unser Spiel darauf vorbereitet sein muss, dass der Spieler schnell zu anderen Stellen im Level (oder sogar zu ganz anderen Leveln/Regionen) wechseln kann, was bedeutet, dass die Objekte im Speicher leicht zugänglich bleiben müssen. 

Die Anno-Engine  

Nachdem wir nun geklärt haben, was eine Game Engine ist und was sie leistet, ist es an der Zeit, einen Blick auf die Anno-Engine selbst zu werfen – wie ist sie entstanden?

Schauen wir ein wenig zurück: Anno 1701 war zwar der erste Anno-Titel, den das Team hier bei Ubisoft Mainz (damals noch: Related Designs) entwickelt hat, aber das Team hatte schon vorher mehrere Strategiespiele entwickelt. Es gab also eine Basis, auf der man aufbauen konnte, zumal der vorherige Titel (Castle Strike, schauts euch doch mal an) bereits ein 3D-Spiel war – im Gegensatz zu den ersten beiden Anno-Titeln. Auf dieser Grundlage baute das Team für Anno 1701 auf und verwendete eine Vielzahl neuer Shader-Techniken, wie z.B. den vom Team so genannten „Schön-Shader“.  

Wie zu Beginn des Artikels erwähnt, ist eine Engine wie eine Sammlung verschiedener Werkzeuge – und diese können auch separat aktualisiert werden, um beispielsweise neue Technologien zu unterstützen.  

Und auch wenn wir in diesem Artikel schon ein paar Mal von der „Anno-Engine“ gesprochen haben, ist das eigentlich nicht ganz richtig: Offiziell hat unsere Engine nicht einmal einen Namen, auch wenn die Idee, sie in irgendeiner Form zu benennen, im Laufe der Jahre einige Male diskutiert wurde. Ein paar Werkzeuge innerhalb der Engine haben allerdings eigene Namen, wie wir weiter oben schon einmal kurz erwähnt hatten. 

Wir hatten ebenfalls erläutert, in welcher Weise unsere Engine auf die Anforderungen eines Anno-Spiels spezialisiert ist. Aber natürlich sind wir schon jetzt regelmäßig dabei, unsere verschiedenen Tools zu aktualisieren, um die Anno-Engine für die Herausforderungen des jeweils nächsten Projekts fit zu machen.  

Größere Änderungen und Updates werden in der Regel nicht in die Live-Version eines unserer Spiele eingepflegt, sondern unsere Teams suchen und testen neue Features, die später für das nächste Projekt hinzugefügt werden. Bis zu einem gewissen Grad ist jedes Game Update jedoch bereits ein kleines Update der Engine, wenn wir neue Features oder weitere Optimierungen hinzufügen.  

Vorschläge für Verbesserungen und neue Features kommen in der Regel von diversen Mitgliedern des Teams selbst, auch wenn die endgültige Entscheidung bei den Teamleitern und dem Produktionsteam liegt.  

Bei den Updates kann es sich um Verbesserungen zur Lösung von Problemen handeln, die uns während der Produktion aufgefallen sind (z. B. Erleichterung für Artists, ihre Assets zur Engine hinzuzufügen, Hinzufügen neuer Beleuchtungs-/Lichteffekte), oder um andere Verbesserungen der Benutzerfreundlichkeit und die Unterstützung neuer Technologien (z. B. GPU-Funktionen wie Tessellation oder AMDs FidelityFX Super Resolution.

Habt ihr noch ein paar aktuelle Beispiele?

Speziell für 2205 haben wir das Geländesystem stark überarbeitet, was damals massive Gebirgssysteme und allgemein detailliertere Umgebungen ermöglichte. Seit damals nutzen wir auch externe Programme (z.B. World Machine und Mudbox), um die Arbeit unserer Level Artists zu erleichtern.  

Wenn ihr Anno 2205 und Anno 1800 gespielt habt, sind euch wahrscheinlich auch die Änderungen am Session-System aufgefallen: Der Wechsel zwischen den verschiedenen Regionen in Anno 1800 erfolgt fast sofort und ohne Ladebildschirm – mit dem Nachteil, dass das Spiel immer diese anderen Sessions „bereit“ haben muss, wie weiter oben beschrieben.  

Wann immer das Team größere Engine-Updates plant, ist es auch wichtig, zu bedenken, dass diese Änderungen auch andere Teams betreffen können. Zum Beispiel können Änderungen am Geländesystem (z.B. unebenes Gelände) Auswirkungen auf Game Design Themen wie Straßenverbindungen haben (können sie noch überall am Gebäude angeschlossen werden?). 

Wir hoffen, dass euch dieser Ausflug hinter die Kulissen von Anno gefallen hat!   

Habt ihr Fragen zu einem der Punkte aus dem heutigen Artikel? Habt ihr vielleicht selbst schon an einem Projekt gearbeitet, vielleicht mit Unity oder Unreal? Lasst es uns in den Kommentaren wissen!