Vor einigen Monaten, im Juni, haben wir angekündigt, dass wir am diesjährigen Green Game Jam teilnehmen werden.

Mehrere Videospielstudios hatten sich damals verpflichtet, sich etwas einfallen zu lassen und in ihren Spielen zu implementieren, um das Bewusstsein für Umweltprobleme wie zum Beispiel die Abholzung von Wäldern zu schärfen. Das Ganze wurde von der UNO im Rahmen von “Playing For The Planet” organisiert – mehr dazu findet ihr hier.

Wir haben uns entschieden, die “Play 4 Forests”-Kampagne mit unserer Teilnahme am Green Game Jam zu unterstützen und weisen daher gern nochmal darauf hin, die Petition auf ihrer Website zu unterschreiben, um Wälder weltweit zu schützen.

Während unseres gamescom-Streams im August haben wir ein paar Details zu unserer Vision für den neuen Spielmodus, den wir planen, mitgeteilt und das finale Artwork für den Modus enthüllt.

Jetzt stehen wir kurz vor der Veröffentlichung des neuen Modus – ein Szenario, das wir “Eden am Ende” nennen!

Liebe Isabel, …

Beleuchten wir zuerst einmal den Hintergrund von “Eden am Ende” – worum geht es in diesem Szenario?

Ihr spielt die berühmte Isabel Sarmento und erhaltet einen dringenden Brief von Yaosca Rodriguez (kommt euch der Name bekannt vor?): Die Besetzung der Insel durch die Pyrphorianer konnte zwar dank eurer Hilfe beendet werden, doch viele ihrer Gebäude und Fabriken sind noch immer vorhanden und fügen dem Ökosystem der Insel weiteren Schaden zu.

Der Hauptverursacher: Ein umweltverschmutzender Generator.

Doch Yaosca und die anderen Bewohner der Insel La Xultuna haben inzwischen die modernen Zeiten kennengelernt – und genießen die Vorteile der Elektrizität – und wollen nicht in eine (buchstäblich) dunklere Zeit zurückkehren. Sie bitten Isabel, das Steuer in die Hand zu nehmen: Beseitigt die Spuren der pyrphorianischen Besatzung und helft den Menschen, einen Staudamm mit Wasserkraftwerk zu bauen!

Ihr seht: Es wartet viel Arbeit auf euch, viele Herausforderungen auf dem Weg, La Xultuna mit einer nachhaltigeren Energieform zu versorgen. Und vielleicht möchtet ihr auch die kleineren Inseln auf der Karte erkunden…

Na gut, lassen wir es dabei bewenden, denn wir möchten, dass ihr die restlichen Details beim Spielen des Szenarios selbst entdeckt 😉

Spielmechaniken – was ist neu?

Ihr habt mittlerweile alle reichlich Erfahrung damit, wie man in Anno 1800 erste Siedlungen hochzieht und sie zu Städten ausbaut. Für dieses Szenario werdet ihr jedoch einige eurer Strategien überdenken müssen.

Zunächst einige allgemeine mechanische Änderungen, die den Schwierigkeitsgrad bereits erhöhen: Beim Abriss von Gebäuden werden die Baumaterialien nicht zurückerstattet (lediglich ein Teil der monetären Kosten), und ihr könnt die Gebäude nicht mehr verschieben. Ihr könnt aber immer noch den Blaupausenmodus verwenden, um eure Siedlung zu planen.

Zweitens: Während “Eden am Ende” in einer Sitzung der Neuen Welt mit ihren zwei Bevölkerungsschichten (Jornaleros und Obreros) stattfindet, haben wir einige Änderungen an ihren Bedürfnissen vorgenommen: Ihr erstes Bedürfnis ist Wasser, das von einer Pumpe geliefert wird, die wie ein normales Öffentliches Gebäude funktioniert. Später muss man sie auch mit Fischen, Bananen und Werkzeugen versorgen, bevor sie aufgewertet werden können.

Die Obreros haben natürlich ihre eigenen Bedürfnisse, z. B. Kaffeekannen oder Atole (ein Getränk aus Mais, Zucker, Wasser und einigen Gewürzen – in diesem Szenario benötigt ihr jedoch nur Mais und Zuckerrohr).

Einige andere Mechanismen, wie Einfluss oder Zufriedenheit, sind in diesem Szenario überhaupt nicht relevant und wurden daher deaktiviert.

Die Ökobilanz

Bis jetzt sind das noch Mechaniken, die ihr kennt, also lasst uns einen Blick auf die eigentliche Herausforderung des Szenarios werfen: Die Ökobilanz.

Die Ökobilanz zeigt den Gesundheitszustand eurer Insel an, aufgeteilt in drei Kategorien: Wasserqualität, Bodenqualität und Luftqualität. Jede Kategorie kann durch euer Handeln positiv oder negativ beeinflusst werden und wird als “Gesundheitsbalken” visualisiert.

Der größte Übeltäter zu Beginn sind die auf der Insel verstreuten pyrphorianischen Ruinen. Deren Beseitigung verbessert nicht nur eure Ökobilanz, sondern schafft zudem wertvollen Bauplatz. Dies kostet jedoch Zeit und Teile eurer Arbeitskräfte, was ihr mit eurem regulären Produktionsbedarf in Einklang bringen müsst.

Auch der Fischfang wirkt sich negativ auf die Wasserqualität aus, während das Abholzen von Bäumen (sie werden vom Holzfäller nicht mehr nachgepflanzt) und generell alle Arten von Industrie ebenfalls nicht gut für eure Ökobilanz sind. Ihr könnt jederzeit überprüfen, welche Faktoren die einzelnen Kategorien derzeit beeinflussen, indem ihr die Ökobilanzübersicht öffnet (siehe unterhalb):

Für jede Kategorie gibt es bestimmte negative Ereignisse, wenn die Qualität zu stark abnimmt, die euch zum Handeln zwingen, und (wenn sie noch weiter abnimmt) Katastrophen wie eine Dürre. Ihr könnt den aktuellen Zustand eurer Insel auch einfach durch einen Blick auf das Wasser oder die Insel selbst beobachten: La Xultuna sieht schnell nicht mehr schön aus, wenn die Ökobilanz zu niedrig ist. Wenn eine der drei Kategorien den Wert Null erreicht, gilt das Szenario als gescheitert.

Neben der Umweltverschmutzung durch die Industrie solltet ihr vielleicht auch eure übliche Taktik ändern, alle Farmgebäude einer Art um eine Handelskammer und ein Lagerhaus herum zu gruppieren: Monokulturen sind nicht gut für die Bodenqualität. Pflanzt stattdessen Farmen unterschiedlicher Art nebeneinander, um die Bodenqualität von La Xultuna zu verbessern.

Aber halt, das ist noch nicht alles: Nicht nur die Anzahl der Bäume ist begrenzt, auch die Minen und Lehmgruben sind nicht mehr endlos und auch die Fischpopulation solltet ihr im Auge behalten. Setzt die verfügbaren Ressourcen klug ein und lasst euch nicht zu viel Zeit, um das Hauptziel zu erreichen: Eine eurer wichtigsten Herausforderungen wird es sein, die Effizienz aufrechtzuerhalten und gleichzeitig die Umwelt intakt zu halten.

Der negativen Ökobilanz entgegenwirken

Das klingt nun eventuell ein wenig kompliziert, aber keine Sorge, es gibt Möglichkeiten, der Verschlechterung der Ökobilanz eurer Insel entgegenzuwirken oder sie zumindest zu verlangsamen.

Einige haben wir bereits erwähnt (Vermeidung von Monokulturen, Beseitigung von Ruinen), aber sehen wir uns mal an, was ihr sonst noch tun könnt – und mittendrin: Crafting!

Dank des Forschungszentrums in der nahegelegenen Stadt könnt ihr im Hafen von Yaosca einige nützliche Items für eure Herausforderung herstellen. Diese werden entweder in einer Handelskammer oder einem Rathaus aktiviert, um zum Beispiel die Umweltbelastung eines Gebäudes zu verringern oder seine Produktivität zu erhöhen. Alle diese Items haben jedoch deutliche Nachteile, auf die ihr achten solltet.

Bei einigen anderen Items handelt es sich im Grunde um Baupläne, mit denen neue Gebäude freigeschaltet werden können, wie z. B. die Wasseraufbereitungsanlage, mit der man die Wasserqualität verbessern kann. Es gibt auch Methoden, um bestimmte begrenzte Ressourcen mittels Items wieder aufzufüllen – und für Bäume könnt ihr einen Förster bauen.

Schließlich könnt ihr natürlich auch einige eurer umweltverschmutzenden Industrien pausieren, um dem Ökosystem eine kurze Verschnaufpause zu gönnen. Aber bedenkt, dass eure Bevölkerung weiterhin Waren nachfragen wird.

Als ob der Aufbau einer funktionierenden Siedlung nicht schon genug wäre, gibt es noch das eingangs erwähnte Hauptziel: Den Staudamm. Er wird in mehreren Phasen gebaut, die jeweils einen Teil eurer Arbeitskräfte und immer fortschrittlichere Güter erfordern, so dass ihr weiter expandieren und mehr Industrie errichten müsst.

Scheitern

Und nicht zuletzt: Scheitern ist Teil der Erfahrung. Rechnet damit, zu scheitern, und habt keine Angst davor, zu scheitern.

Wenn ihr das Szenario nach einem gescheiterten Versuch neu startet, können ihr auf einigen eurer früheren Errungenschaften aufbauen, was euch den nächsten Durchlauf erleichtern sollte: Die drei Ruinen im Tal tauchen nicht wieder auf, wenn ihr sie entfernt habt, und bestimmte fortgeschrittene Technologien, die ihr zuvor erworben habt, bleiben ebenfalls freigeschaltet.

Außerdem werdet ihr wahrscheinlich das eine oder andere gelernt haben, was ihr bei eurem nächsten Versuch verbessern könnt ? .

Moment, was ist ein Szenario?

Nun, da wir den Begriff “Szenario” verwendet haben, wollen wir ein wenig über das Szenario-System sprechen, das wir für “Eden am Ende” entwickelt haben.

Das Szenario ist von der Kampagne und dem Freien Spiel getrennt und hat sein eigenes Untermenü auf dem Startbildschirm.

Auf dem Übersichtsbildschirm von “Eden am Ende” wird euch ein Intro für das Szenario selbst sowie die Siegbedingungen angezeigt. Je nachdem, wie ihr das Szenario abschließt, gibt es verschiedene Qualitätsstufen – in diesem Fall die Zeit, die ihr für den Bau des Staudamms benötigt, und die Gesundheit der Insel.

Jede Qualitätsstufe bietet auch eine bestimmte Belohnung. Diese Belohnung wird dann für alle regulären Kampagnen- und Sandkastenspiele freigeschaltet.

Während ihr das Szenario spielt, könnt ihr die Siegbedingungen des Szenarios immer über den separaten Tracker auf der linken Seite im Auge behalten.

Mehr zu Szenarien im nächsten Jahr, wenn wir die Inhalte von Season 4 vorstellen.

Der “Pflanze einen Baum” DLC

An diesem Tag wird auch der kosmetische DLC “Pflanze einen Baum” veröffentlicht. Dieser ist etwas Besonderes, denn das Geld aus diesem DLC geht an Ecologi, ein Social Enterprise, das sich für das Pflanzen von Bäumen einsetzt. Mehr über sie erfahrt ihr hier.

Dieser CDLC ist für 2,99€ erhältlich und fügt eurem Spiel ein neues Baumornament hinzu, das auf dem Ceira-Baum basiert, den ihr auch auf der Insel La Xultuna finden könnt. Wir verdienen kein Geld mit diesem DLC: Von jedem Kauf geht der gesamte Nettoerlös (d.h. nach Abzug aller Gebühren und Steuern) an Ecologi (mindestens $1/1€/1£ pro Kauf).

Ihr könnt den “Pflanze einen Baum” DLC bis Ende März 2022 kaufen, um die Wiederaufforstung zu unterstützen. Nach diesem Datum wird er aus dem Ubisoft Store entfernt. Aber keine Sorge, das Ornament wird anschließend mit einem Update Ende 2022 für alle kostenlos hinzugefügt.

Und falls ihr es verpasst habt: Heute haben wir die Anfänge des Szenarios “Eden am Ende” live im Stream gezeigt. Schaut auf unserem Twitch-Kanal vorbei und werft einen Blick auf die Aufnahme des Streams, wenn ihr die neuen Inhalte in Aktion sehen wollt.

Was bleibt uns noch zu sagen? Ach ja, richtig: Unser Green Game Jam-Szenario “Eden am Ende” wird als Teil von Game Update 13 am 14. Dezember um 18 Uhr kostenlos für alle veröffentlicht!

Behaltet bis dahin die Anno Union im Auge, denn am Freitag werden wir die vollständigen Release Notes für Game Update 13 veröffentlichen – und in nur einer Woche könnt ihr La Xultuna dann selbst retten!

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!