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! 

Im Sommer haben wir über die Arbeit unserer QA-Teams gesprochen, welche Schwerpunkte jedes Team hat und wie wichtig diese Teams für den gesamten Entwicklungsprozess des Spiels sind – sie machen viel mehr als nur Bugs zu suchen oder Anno 1800 zu testen. Falls ihr es noch nicht gelesen habt, empfehlen wir euch dringend, dies zu tun, bevor ihr weiterlest, um zunächst etwas über die Aufgaben und Verantwortungsbereiche unserer drei Teams zu erfahren: unser internes QA-Team, das Live-QA-Team und die Qualitätskontrollteams.

Und wie bereits erwähnt, wollen wir euch nun einen Einblick geben, welche Schritte vom Finden eines Problems bis zur Veröffentlichung eines Fixes unternommen werden

Damit ihr euch schnell einen ersten Überblick verschaffen könnt, werft einen Blick auf die folgende Grafik. Im Blog selbst werden wir dann ins Detail gehen.

Finden oder Melden eines Problems

Normalerweise gibt es zwei Möglichkeiten, wie ein Problem auf unserem Radar auftaucht: Entweder wird es von euch über einen unserer Kanäle gemeldet (oder von einem der Anno Companions an uns weitergeleitet), oder wir bemerken es beim internen Testen – oder Spielen 😉

In beiden Fällen wird das Problem in JIRA eingetragen, einem Tool, das für verschiedene Zwecke verwendet werden kann, in diesem Fall verwenden wir es, um Fehler zu sammeln und zu kategorisieren. Während dieses Prozesses wird jedes Problem anhand mehrerer Faktoren kategorisiert und bei Bedarf mit Tags versehen, die wichtigsten Beiden: Schweregrad(Severity) (Auswirkung des Fehlers, wenn er auftritt) und Wahrscheinlichkeit(Probability) (wie wahrscheinlich ist es, dass Spieler auf dieses Problem stoßen)

Aus diesen beiden Faktoren ergibt sich dann die Priorität (z.B. ein Problem mit hoher Wahrscheinlichkeit, aber geringem Schweregrad, hat eine niedrige oder mittlere Priorität).

Reproduktion

Der nächste Schritt ist sehr wichtig: Wir versuchen, das Problem zu reproduzieren, d. h. wir versuchen, es bei uns absichtlich auftreten zu lassen. Das hilft uns, mögliche Ursachen für das Problem ausfindig zu machen, was es uns wiederum viel leichter macht, das Problem später anzugehen und zu beheben.

Dieser Schritt kann manchmal recht arbeitsintensiv sein. Um beispielsweise Probleme der Live-Version zu reproduzieren, benötigt das QC-Team manchmal eine ganz bestimmte Hardware-Kombination für Tests, die unter Umständen nur sehr schwer zu beschaffen ist.   Manchmal bedeutet dies auch, dass wir direkt mit Hardwareherstellern wie AMD oder Nvidia zusammenarbeiten müssen, um bestimmte Hardwarekombinationen zu erhalten oder zu testen, um bestimmte Probleme zu reproduzieren und zu untersuchen.

Daher ist es für uns äußerst hilfreich, wenn ihr uns bei der Meldung von Problemen so viele Details wie möglich gebt: Könnt ihr das Problem selbst reproduzieren? Was habt ihr getan, bevor das Problem auftrat? Welche Hardware verwendet ihr? Etc.

Bei Anno 1800 kommt es aufgrund der vielfältigen Einstellungsmöglichkeiten und des individuellen Spielstils jedes Spielers häufig vor, dass das Live QA-Team nach Erhalt der ersten Meldung um Speicherstände, Screenshots, Videos oder Systeminformationen bitten muss. An dieser Stelle kommen der Kundensupport und das Community Management Team ins Spiel: Sie setzen sich mit dem Spieler in Verbindung und stellen nach Möglichkeit weitere Informationen zur Verfügung.

Diese Reproduktionsschritte werden daher auch in jedem JIRA-Ticket aufgeführt, damit jeder, der an diesem Problem arbeitet, es schnell selbst überprüfen kann. Außerdem wird eine Reproduktionsrate hinzugefügt: Kann das Problem jedes Mal reproduziert werden, wenn bestimmte Schritte befolgt werden, oder tritt es nur gelegentlich auf? Oder können wir ein Problem, das uns gemeldet wurde, eventuell gar nicht reproduzieren?

Behebung des Problems

Die Behebung des Problems bedeutet, dass die Ursache des Problems mit Hilfe der bereitgestellten Informationen weiter untersucht wird.

Dies geschieht auf der Grundlage der in Schritt 1 vorgenommenen Prioritätensetzung. Weitere Faktoren sind die verfügbaren Ressourcen innerhalb des Teams. Das kann bedeuten, dass selbst wenn ein Problem eine niedrige Priorität hat, der Bugfix trotzdem in das Game Update wandert, wenn wir in der zuständigen Abteilung freie Ressourcen haben. Bedenkt, dass das Team gleichzeitig auch am nächsten größeren Update oder DLC arbeitet.

Wir möchten an dieser Stelle auch betonen, dass es natürlich stark von der Art des Problems abhängt, welches Team für die Behebung zuständig ist. Ein falscher Questtext? Eine fehlende Textur? Ein Item-Effekt, der nicht funktioniert? Falsch ausgerichtete Icons? Jedes Problem kann einen bestimmten Spezialisten erfordern.

Obwohl es in einigen Fällen möglich sein kann, dass einer unserer Programmierer die Ursache und den Ort eines Problems ohne Reproduktionsschritte herausfindet, ist dies nicht die Regel und verlängert die Zeit, die für das entwickeln eines FIxes benötigt wird, erheblich.

Abgesehen davon kann jede Art von Fehlerbehebung geraume Zeit in Anspruch nehmen, da die Suche nach der genauen Ursache in der Regel keine Sache von Minuten ist: Wir müssen herausfinden, was genau zu dem Verhalten führt, das wir beobachtet und reproduziert haben. Außerdem gibt es mögliche Risiken, vor allem weil Videospiele wie Anno 1800 sehr komplex sind: Die Behebung eines Fehlers kann dazu führen, dass ein anderes System nicht mehr wie vorgesehen funktioniert, neue Fehler können auftreten, usw. Einige Systeme des Spiels sind weitaus schwieriger zu bearbeiten als andere.

Test des Bugfixes

Deshalb muss jeder Fix richtig getestet werden. Nicht nur isoliert für sich selbst (ist der Fehler behoben?), sondern auch in Kombination mit dem Rest des Game Updates – d.h. der neuen Version des Spiels. Damit soll sichergestellt werden, dass eine Fehlerbehebung nicht, wie oben erwähnt, etwas anderes kaputt macht.

Detaillierte Reproduktionsschritte sind daher auch für die Tests wichtig, da wir wissen müssen, wie man ursprünglich auf den Fehler stoßen konnte: Tritt das Problem jetzt NICHT mehr auf, nachdem man die skizzierten Schritte befolgt hat?

Wie ihr vielleicht schon erraten habt, ist das Testen, ähnlich wie bei den vorherigen Schritten, nicht an einem Tag erledigt. Bevor wir ein Game Update veröffentlichen, legen wir in der Regel eine „Validierungsperiode“ ein. Dieser Zeitraum ist in der Regel etwa 2 Wochen lang und besteht aus zwei Phasen:

1. Die erste findet intern hier in Mainz statt und ist ein „Feature Freeze“, den wir die „Golden Ticket Phase“ nennen – denn nur von QA genehmigte, „goldene“ JIRA Tickets dürfen noch bearbeitet und in das Update aufgenommen werden. Alles andere muss auf ein zukünftiges Update warten.
2. In der zweiten Woche führen unsere Kollegen in den QC-Teams die Validierung des Updates durch. Wir arbeiten zu diesem Zeitpunkt nicht mehr an dem Update.

Natürlich kann es vorkommen, dass eine bestimmter Fix oder gar das Game Update selbst nicht funktioniert oder Probleme aufweist. In diesem Fall müssen wir zu den vorherigen Schritten zurückkehren (einschließlich einer weiteren Validierungsrunde), was im schlimmsten Fall bedeuten kann, dass wir die Veröffentlichung des Game Updates verschieben müssen.

Release des Game Updates

Wenn die neue Version getestet und validiert wurde, sind wir fast bereit für die Veröffentlichung. Während dieses Prozesses stehen wir auch in Kontakt mit Kollegen in anderen Teams, damit alle wissen, dass wir das Update an diesem Tag veröffentlichen wollen.

In der Regel bündeln wir in einem solchen Game Update stets mehrere Bugfixes: Das kann bedeuten, dass einige Probleme zwar bereits behoben sind aber erst darauf warten müssen, in die Live-Version des Spiels übertragen zu werden. Aufgrund des hohen Arbeitsaufwands müssen wir ein Gleichgewicht zwischen der rechtzeitigen Behebung eines Problems und der Vermeidung einer Überlastung unserer Teams durch ständige Game Update Veröffentlichungen finden.

Der „Hotfix“ ist eine Ausnahme, und wir haben in unserem vorherigen DevBlog darüber gesprochen.

Unsere großen Game Updates, die zusammen mit einem DLC veröffentlicht werden, gehen in der Regel um 18:00 Uhr live, während die kleineren Updates in der Regel um 14:00 Uhr veröffentlicht werden. Und falls ihr es noch nicht bemerkt habt: Unser bevorzugter Veröffentlichungstag ist der Dienstag.  😉

Da wir regelmäßig Missverständnisse über unsere internen Prozesse und die Zeit, die für die Behebung von Fehlern und anderen technischen Problemen benötigt wird, erleben, war es für uns eine Priorität, dieses Thema genauer zu beleuchten.

Wie wir in diesem Blog hoffentlich deutlich gemacht haben, ist der Prozess, der hinter dem Melden von Fehlern und der Fehlerbehebung steht, nicht einfach: Er erfordert Zeit und vor allem viel Geduld und Ressourcen.

Wenn ihr Fragen dazu habt oder mehr über andere spezifische Prozesse wissen möchten, zögert nicht, uns das in den Kommentaren unten mitzuteilen!