Hinter den Kulissen: Die Neuerschaffung der Kriegsanstrengungen für Ahn'Qiraj

Krieg ist über uns gekommen. Anfang des Monats wurde eines der heiß ersehntesten Ereignisse von World of Warcraft Classic veröffentlicht – die Kriegsanstrengungen für Ahn'Qiraj. Ganze Classic-Realms – die geballte Macht von Horde und Allianz – haben sich zusammengeschlossen und Ressourcen bereitgestellt, um die Tore zu öffnen und die Schlachtzüge von Ahn'Qiraj freizuschalten. Als der Krieg der Sandstürme 2006 zum ersten (und einzigen) Mal stattfand, machten sich Tausende von Spielern auf nach Silithus, um dem Chaos beizuwohnen oder sich daran zu beteiligen. Der Zulauf übertraf selbst die kühnsten Erwartungen des Entwicklerteams um ein Vielfaches. Auf diese Massen waren sie schlicht und einfach nicht vorbereitet. Die Server waren in kürzester Zeit überlastet und viele Spieler waren über einen Zeitraum von zwölf Stunden hinweg in einem scheinbar endlosen Kreislauf gefangen, in dem sie sich einloggten, die Verbindung verloren, und dann versuchten, sie wiederherzustellen. Und während alledem rannten unsere Techniker umher und versuchten, Fehler zu beheben und Spielern das Einloggen zu ermöglichen. Zwar haben wir es geschafft, die Server während des Ereignisses zu stabilisieren und daraus viel zu lernen, aber trotzdem gab es noch reichlich Spielraum für Verbesserungen. 15 Jahre später waren wir dann bereit, einen der epischsten Momente in der Geschichte von WoW in WoW Classic neu aufleben zu lassen. Dafür mussten wir unsere Server optimieren, um Lags und Serverzusammenbrüchen vorzubeugen – und das mit doppelt so vielen Spielern in Silithus wie beim ersten Durchlauf des Ereignisses im Jahr 2006.

In diesem Artikel wollen wir näher beleuchten, wie wir dieses sehnsüchtig erwartete Ereignis neu erschaffen konnten. Zu diesem Zweck schauen wir uns an, wie wir automatisierte Spieler und Stresstests nutzen, um Schwachstellen zu ermitteln und passgenaue Lösungsansätze zur Optimierung zu entwickeln, wie wir mithilfe der Software Lösungen für Probleme gefunden haben, die für die Hardware unlösbar waren, und wie wir ein weltweites Ereignis organisieren konnten, bei dem sich die Serverabstürze in Grenzen hielten und gleichzeitig die Spielerfahrung von WoW Classic gewahrt blieb.

Der Krieg der Sandstürme – die Zweite

Bei unseren Überlegungen, wie wir dieses Ereignis aufziehen wollten, hatten wir drei konkrete Ziele: Wir wollten verhindern, dass es zu einer Reihe von Abstürzen kommt, die Anzahl der Spieler erhöhen, die sich gleichzeitig in einer Zone befinden können, und herausfinden, wie hoch die Schmerzensgrenze für Lags war, bevor Spieler aus Silithus hinausteleportiert würden. Bevor wir uns im Detail ansehen können, wie wir die Serverleistung maximiert haben, müssen wir auf die Rahmenbedingungen eingehen, mit denen wir es zu tun hatten: die Einschränkungen durch den Code von WoW Classic, die Funktionsweise der Bevölkerungsbegrenzungen und wie sich das alles auf das Gameplay auswirkt.

Jenseits der Grenzen

Die moderne Version von World of Warcraft wurde auf Basis des Originalcodes erschaffen, der vor 15 Jahren veröffentlicht wurde. Seit der Veröffentlichung des Spiels haben wir verschiedene moderne Methoden entwickelt, um in Battle for Azeroth mit einer hohen Spielerzahl umzugehen, darunter vor allem das Sharding. Shards erlauben es WoW-Servern, viel mehr Spieler gleichzeitig aufzunehmen, als es 2006 möglich war. In Battle for Azeroth benutzen wir Shards, um die Auslastung eines Servers zu verringern, indem wir eine Kopie der jeweiligen Zone erschaffen (z. B. Zuldazar), sobald die Spieleranzahl einen gewissen Schwellenwert erreicht. Wir vermeiden mögliche Lags, indem wir die Spieler auf verschiedene Versionen der Zone verteilen, denn Spielerinteraktionen nehmen besonders viel Rechenleistung in Anspruch. Das liegt daran, dass ständig große Mengen an Datenpaketen an den Server geschickt werden müssen, um die Bewegungen und gewirkten Zauber akkurat abzubilden. Zusätzlich entschärft das Sharding potentielle Lags, die dadurch entstehen, dass Spieler in eine neue Zone wechseln, wo die Spieleranzahl den Schwellenwert übersteigt. Das klingt alles recht einfach, aber es gibt einen Haken – WoW Classic wurde als möglichst originalgetreues Abbild der ursprünglichen Daten von Patch 1.12 erschaffen, und dazu zählen auch die dazugehörigen Eigenheiten beim Gameplay. In seltenen Fällen kann es durch Sharding dazu kommen, dass euer Ziel (etwa ein gegnerischer Spieler oder ein NSC) verschwindet, wenn ihr in eine andere Zone wechselt. Das Beibehalten von Sharding hätte zur Folge, dass einige der nostalgischen Gameplay-Momente verloren gehen, bei denen Spieler NSCs oder andere Spieler über Zonengrenzen hinweg verfolgen. Also mussten wir eine Lösung finden, die keine Auswirkung auf das ursprüngliche Gameplay hatte, aber uns gleichzeitig ermöglichen würde, mehr Spieler auf einem Server zu haben, ohne dass das Spiel aufgrund von Lags unspielbar wäre.

Um dieses Problem zu lösen, entschieden wir uns für die Verwendung von Layers – Kopien ganzer Regionen (z. B. der Östlichen Königreiche) –, um die Bevölkerungsdichte und die Lags unter Kontrolle zu halten, ohne den unvergesslichen Charme des ursprünglichen Spiels zu verlieren. Mithilfe dieses Ansatzes würden Spieler Weltbosse erneut in andere Zonen locken und gegnerische Spieler innerhalb einer Region über Grenzen hinweg verfolgen können, ohne dabei das Risiko einzugehen, einem anderen Shard zugewiesen zu werden. Aber Layer waren nie als dauerhafte Lösung gedacht. Da die ursprüngliche Version 1.12 weder Sharding noch Layering verwendete, haben wir Spielern versprochen, Layer nur für die Veröffentlichung von WoW Classic zu verwenden und mit der Zeit zu deaktivieren, wenn sich die Spieler gleichmäßiger in der Welt verteilt hatten. Es gibt einige wenige Fälle, in denen wir aufgrund von hohen aktiven Spielerzahlen immer noch Layer verwenden (z. B. auf dem nordamerikanischen Server Faerlina), aber wir haben die Anzahl der aktiven Layer auf diesen Realms seit der Veröffentlichung des Spiels stark reduziert. Mit 15 Jahren Vorfreude ist das Ereignis rund um Ahn'Qiraj eines der am sehnsüchtigsten erwarteten Ereignisse von WoW Classic. Unseren Erwartungen nach würde sich dabei, abgesehen von den Startgebieten am Tag der Veröffentlichung, die bislang größte Anzahl an Spielern in einem Gebiet aufhalten, und das ohne Layer, mit denen wir die Auswirkungen abmildern konnten. Ohne die technologische Hilfe von Layering oder Sharding brauchten wir eine kreative Lösung, und zwar schnell.

Eine unvergessliche Erfahrung nach Maß

Unsere Suche nach einer Lösung für die Bevölkerungsdichte ohne Layering oder Sharding haben wir damit begonnen, dass wir sogenannte „kopflose Clients“ – automatisierte Spielercharaktere – erschaffen haben, die wir das Verhalten echter Spieler nachahmen ließen. Also ließen wir sie Zauber wirken, NSCs bekämpfen und durch die Gegend laufen. Dadurch konnten wir einen Eindruck gewinnen, wie die Serverleistung aussehen könnte, wenn Tausende von Spielern in einer einzigen Zone agieren. Nach diesen Simulationen haben wir dann Stresstests mit Freiwilligen organisiert, um uns realistisches Spielerverhalten anzusehen und diese Daten mit unseren bisherigen Ergebnissen zu vergleichen. So erhielten wir einen Eindruck davon, wo bestimmte Schwachpunkte lagen und welche Teile unseres Servercodes bei hoher Spieleranzahl die meisten Probleme hatten. Die Daten zur Framezeit der Server wurden genau analysiert, um zu sehen, wie nah sie dem Zustand kamen, bei dem ein Server nicht mehr reagiert (auch Deadlock genannt).

Der nächste Schritt war die Analyse, was genau die Serverleistung beeinträchtigte, damit wir diese gewaltige Aufgabe langsam in überschaubare Ziele aufgliedern konnten. Wir standen vor einer polynomischen Aufgabe, was bedeutete, dass wir sie nicht durch den Einsatz von schnellerer Hardware lösen konnten, weil sich Hardware nicht exponentiell verbessert. Stattdessen mussten wir die Optimierung von Hand durchführen, indem wir bewusst auswählten, welche Daten wie oft an die Spieler übermittelt wurden. Lasst uns dieses Problem veranschaulichen: Sagen wir, wir haben 20 Spielercharaktere, die im Kreis hüpfen. Der Server übermittelt die Aktionen jedes Charakters mithilfe von Datenpaketen an die anderen 19 Spieler. Bei dieser Gruppe aus 20 Spielern verarbeitet der Server 380 Datenpakete (20 Spieler insgesamt * 19 Empfänger = 380 Pakete). Das Ganze wird noch verzwickter, wenn eine größere Anzahl an Spielercharakteren in einer Zone die gleiche Aktion ausführt. Wenn wir unser Beispiel auf 500 Spieler ausdehnen, dann werden 249.500 Pakete vom Server verschickt. Erhöhen wir die Anzahl auf 1.500 Spieler, sind es schon 2.248.500 Pakete. Je nachdem, welche Aktionen die Spieler ausführen, werden pro Sekunde mehrere Datenpakete übermittelt – nicht vergessen, die obigen Beispiele beziehen sich nur auf jeweils eine Aktion. Je mehr Datenpakete an den Server übermittelt werden, desto länger braucht der Server, um die Aktionen eines einzigen Spielers zu verarbeiten, bevor er die der anderen Spieler in Angriff nehmen kann. Wenn sich dieses Problem verschlimmert, nähern sich die Server einem Deadlock. In WoW Classic haben wir auf jedem Realm deutlich mehr Spieler als damals im Jahr 2006. Es wird also erwartet, dass sich mehr Spieler als je zuvor in der Nähe der Tore aufhalten können.

Optimierung der Serverleistung

Unsere Server sind darauf ausgelegt, bei einem Deadlock abzustürzen und danach neu zu starten. Wir wussten also, dass wir alles in unserer Macht Stehende tun mussten, um die Verarbeitungszeit zu minimieren. Nach einigen Tests war klar, dass Bewegungen den größten Teil der Rechenleistung ausmachten, der unseren Servern zu schaffen machte. Als erstes unterbanden wir Updates zur Charakterausrichtung (die anzeigen, in welche Richtung jedes Charaktermodell blickt) und schickten nur noch Spielerupdates, wenn der Spieler eine Bewegung einleitete, sie beendete oder seinen Charakter mithilfe der Tastatur bewegte. Da die Latenz bei einer großen Anzahl von Spielern bereits gefährdet ist, machte die Verwendung von Rechenleistung für geringfügige Updates zur Charakterausrichtung die Qualität nur schlimmer. Daher war es besser, sie zu unterbinden. Wir entschieden uns, lieber mehr Spielercharaktere in einer Zone unterzubringen, und dafür seltener Ausrichtungsupdates zu übermitteln. Hierbei sollte man nicht vergessen, dass es unser Ziel war, die Grenze zu finden, bevor die Server zusammenbrechen, und gleichzeitig so viele Spieler wie möglich nach Silithus zu lassen. Schließlich ist es besser, ein paar Bewegungsupdates weniger zu erhalten, als sich gar nicht erst mit seinem Charakter einloggen zu können. Außerdem begannen wir damit, Daten mit niedriger Priorität zu drosseln. Aktionen, die als „weniger wichtig“ eingestuft werden, sollten nicht mit der gleichen Rate verschickt werden, wie „wichtigere“ Aktionen. Viele Nachrichten wurden ungeachtet der Wichtigkeit alle gleichzeitig verschickt. Also optimierten wir den Code, damit weniger wichtige Informationen nur gesammelt und weniger häufig übermittelt wurden.

Auch Stärkungs- und Schwächungseffekte wirkten sich negativ auf die Serverleistung aus. Überall in der Welt werden vor allem im Kampf ständig Stärkungs- und Schwächungseffekte eingesetzt. Das mag zwar trivial klingen, aber mit so vielen Spielercharakteren auf engem Raum müssen diese Informationen erst mal an alle übermittelt werden. Ähnlich wie mit der Drosselung von Daten mit niedriger Priorität haben wir die Stärkungs- und Schwächungseffekte gebündelt, um zu vermeiden, dass nacheinander mehrere Datenpakete an Spieler verschickt werden.

Bewältigung hoher Spielerzahlen

Während wir unsere Server dafür optimierten, mehr Spieler in jeder Zone zu bewältigen, war uns trotzdem klar, dass wir unmöglich die Bevölkerung eines gesamten Realms (mehr als doppelt so viele Spieler wie auf dem ursprünglichen WoW-Realm von Version 1.12) gleichzeitig in Silithus unterbringen konnten. Wir mussten die schwere Entscheidung treffen, den Zugang zu dieser Zone zu beschränken, indem wir festlegten, wer hinein durfte und wie viele Spieler sich gleichzeitig dort aufhalten durften. Wir beschlossen, dass nur Charaktere auf Stufe 60 nach Silithus kommen durften und dass auch diesen Charakteren der Zugang verweigert würde, sobald die maximale Spieleranzahl erreicht war. Diese Einschränkung war die richtige Entscheidung, da das Ereignis in Silithus bekanntermaßen für Charaktere der Höchststufe ausgelegt war. Außerdem konnten sich niedrigstufige Charaktere trotzdem in anderen Zonen an den Kriegsanstrengungen beteiligen, zum Beispiel, indem sie die Anubisath bekämpften, die durch das Brachland streiften und für Charaktere auf Stufe 20–30 konzipiert waren. Die zweite Streitfrage war folgende: Wir wussten, wie viele Spieler sich maximal in einem Gebiet aufhalten durften, bevor der Server in die Knie ging. Aber um wie viel sollten wir diese Zahl senken, um die beste Serverleistung für alle zu gewährleisten? Durch Tests fanden wir heraus, dass das Optimum bei etwa 1.500 Spielern lag, wenn sich die Charaktere alle an einem Fleck aufhielten. Aber da das Ereignis in der kompletten Zone stattfand, stellte sich heraus, dass nur minimale Probleme auftraten, wenn sich die Spieler verteilten.

Das Ereignis sollte in allen Regionen stattfinden, also mussten wir sicherstellen, dass alles über mehrere Layer hinweg funktionierte. Das bedeutet, dass der Träger des Szepters, der auf einem Layer den Gong läutete, das Ereignis auch für alle anderen Layer dieses Realms auslösen sollte. Da der Auslöser des Ereignis mit einer Spieleraktion verknüpft war, wollten wir sichergehen, dass der Träger des Szepters für alle Spieler desselben Realms auch auf jedem Layer sichtbar war. Dadurch ergab sich ein interessantes Problem, weil die Server jetzt diese Information übermitteln mussten, die sie normalerweise nicht untereinander austauschen würden. Es kann viele Komplikationen zur Folge haben, wenn wir Updates zusammenstellen und durch die Server schicken, um sicherzustellen, dass wir die Daten auf jedem Layer potenziell an Tausende von Spielern übermitteln.

Mit der Entwicklung dieser Technologie haben wir bei der Einführung des Angelwettbewerbs im Schlingendorntal begonnen. Später kam sie dann bei den globalen Stärkungseffekten im Zusammenhang mit Onyxia, Nefarian, Zul'Gurub und Rend zum Einsatz. Als wir uns schließlich sicher waren, dass alles wie vorgesehen funktionierte, waren wir bereit, unsere gesamte Technologie für das Ereignis rund um Ahn'Qiraj zu testen.

Experimente mit Lösungsansätzen

Jetzt, da wir die größten technischen Probleme gelöst und mehrere Möglichkeiten gefunden hatten, die Serverleistung zu optimieren, war es an der Zeit, unsere Arbeit einem Test zu unterziehen. Wir erstellten eine verkürzte Version des zehnstündigen Krieges, die nur eine Stunde andauern sollte.

Während des ersten Stresstests ließen wir fast alle Spieler in die Zone, um zu sehen, was passieren würde. An einem Punkt waren wir bei fast 150 % der Kapazität eines gesamten Realms von Version 1.12. Und an genau diesem Punkt stürzte unser Testrealm ab. Wir wussten, dass wir eine sehr hohe Anzahl von Spielern als Limit für die Zone gewählt hatten, und diese Anzahl übertraf dieses Limit um ein Vielfaches. Als wir der Sache nachgingen, fanden wir heraus, dass der Code, der es Spielern erlaubte, eine Zone sowohl zu betreten als auch wieder zu verlassen, eine Warteschlange war, die mit vielen Spielern auf einmal nicht zurechtkam. Deshalb wurden die Spieler nicht aus der Zone teleportiert und steckten ungewöhnlich lang auf Flugrouten fest. Wir brachten den Server wieder auf Vordermann und führten den Stresstest fort. Und währenddessen passten wir einige Dinge an. Wir verringerten das Limit auf einen Punkt, an dem der Lag zwar immer noch spürbar, aber auszuhalten war, und behielten eine viel größere Anzahl an Spielern in der Zone als je zuvor. Das Ereignis hätte eigentlich nur eineinhalb Stunden dauern sollen. Tatsächlich brauchten wir wegen der Abstürze bis zu vier Stunden.

Der zweite Stresstest wurde eine Woche später durchgeführt. Dadurch konnten wir sehen, ob unsere Optimierungen Wirkung zeigten. Direkt beim Einloggen zum Stresstest waren die Verbesserungen spürbar – es hingen keine Spieler mehr auf den Flugrouten nach Silithus fest! Wir konnten genug Daten sammeln, die zeigten, wie viele Spieler Silithus ohne größere Probleme verkraften konnte. Nach beiden Tests konnten wir uns dann auf eine Zahl festlegen, die unserer Meinung nach am besten für die Bewältigung von Lags und die Serverstabilität geeignet war. Durch diese Tests konnten wir feststellen, ob unsere Optimierungen funktionierten, und da wir so die optimale Spieleranzahl pro Zone herausfinden konnten, waren sie ein voller Erfolg.

Serverlösungen für ganz Azeroth

Ursprünglich sollten die Optimierungen während des Kriegs des Sandstürme nur in Silithus aktiv sein. Nachdem wir sichergestellt hatten, dass sie problemlos auch global eingesetzt werden konnten, implementierten wir diese Änderungen mit Patch 1.13.5 in der gesamten Spielwelt. Mit Beginn der Kriegsanstrengungen begannen die Spieler, Ressourcen abzugeben und massenweise Käferkadaver zu plündern. Nicht nur in Silithus stieg die Spielerzahl sprunghaft an, sondern auch in den Hauptstädten und der offenen Welt. Diese Optimierungen trugen dazu bei, dass sich die Spielerfahrung flüssiger anfühlte, und ermöglichten riesige PvP-Schlachten in ganz Azeroth. Manche Spieler gingen sogar so weit, den Weltboss Donneraan zu beschwören, damit er ihnen dabei half, die andere Fraktion von einem Schwarmbau zu vertreiben.

Obwohl das Ereignis zum Öffnen der Tore noch nicht stattgefunden hatte, traten auf manchen Servern seltsame Fehler auf, durch die sie die Kriegsanstrengungen nicht vorantreiben konnten. Das Tempo, mit dem manche Server die Kriegsanstrengungen vorantrieben, war so rasant, dass in der Logik jeder Abgabe eine Wettlaufsituation entstand, die verhinderte, dass der fünftägige Timer startete. Da die Wahrscheinlichkeit für das Auftreten eines solchen Ausnahmefalls so gering war, konnten wir den Fehler für diese Server manuell beheben und dann dafür sorgen, dass er bei zukünftigen Kriegsanstrengungen anderer Server nicht mehr auftreten konnte.

Nach Abschluss der Kriegsanstrengungen und nach Ablauf des fünftägigen Timers behielten wir die chinesischen Realms im Auge, die die Tore als erste öffnen würden. Der erste Server in China, für den der Gong aktiv wurde, war Ouro. Wie wir feststellten, befanden sich auf jedem Layer die meisten Spieler in Silithus. Das Ereignis würde auf mehreren Layers mit maximaler Besetzung für mehrere Tausend Spieler gleichzeitig starten. So etwas hatten wir noch nie zuvor versucht. Obwohl deutliche Lags auftraten, stürzten unsere Server beim ersten Öffnen der Tore in China nicht ab.

Der Gong ertönt

Am 4. August wurde klar, dass mehrere Realms in Nordamerika kurz nach den Serverneustarts bereit sein würden, den Gong zu schlagen. Mithilfe von Game Master-Accounts und unseren Beobachtungswerkzeugen wachten wir mit Argusaugen über diese Realms, um mögliche Probleme beheben zu können. Alle Realms fuhren hoch und begannen reibungslos mit dem Ereignis. Die Träger des Szepters erhielten ihre prestigeträchtige Schwarze Qirajipanzerdrohne als Reittier, die Spieler konnten gegen noch größere Käfer antreten und wir freuten uns über die Stabilität. Während wir darauf warteten, dass unser erster Server nach dem Serverneustart seine fünftägige Wartezeit abschloss, fiel uns ein schwerwiegendes Problem auf: das Ereignis blieb nach dem Serverneustart nicht bestehen. Sollte also ein Server abstürzen oder neu starten, würde der gesamte Ereignisfortschritt verloren gehen. Diesen Fehler gab es zwar schon seit Beginn der Entwicklung von WoW Classic, aber bisher hatte es einfach noch nicht viele Ereignisse gegeben, die über den Serverneustart hinweg bestehen bleiben mussten. Unser Team konnte den Fehler schnell beheben, aber wir mussten dafür sorgen, dass kein weiterer Serverneustart stattfand, bevor wir nicht den Hotfix aufgespielt und den bisherigen Status aller Kriegsanstrengungen in unserer Datenbank gespeichert hatten, und das alles, ohne die Spieler zu stören.

Mancher würde behaupten, dass die Serverabstürze den ursprünglichen Krieg um Ahn'Qiraj so chaotisch und dadurch so denkwürdig gemacht haben. Stattdessen wollten wir dieselbe Leidenschaft hervorrufen, indem wir eine viel stabilere Spielerfahrung schufen, die Spieler zeitgleich mit 1.500 anderen Spielern in Silithus erleben konnten. Wir wollten, dass der Krieg um Ahn'Qiraj in WoW Classic als ein Ereignis in Erinnerung blieb, bei dem so viele Spieler wie möglich ohne Unterbrechung am zehnstündigen Krieg teilnehmen konnten. Es kam zwar zu einigen Serverabstürzen, aber die Server waren immer schnell wieder online. Diese Realms erholten sich vollständig und waren innerhalb weniger Minuten wieder online, ohne dass es zu weiteren Abstürzen kam.

Über 4.000 Spieler wurden weltweit zu Skarabäusfürsten, und diese Zahl steigt weiterhin, während jeder Server bei den Kriegsanstrengungen voranschreitet. Die Begeisterung und der Eifer der Spieler in WoW Classic seit Beginn der Kriegsanstrengungen für Ahn'Qiraj sind für uns unbeschreiblich. Vielen Dank an alle, die sich uns für den zweiten Krieg der Sandstürme angeschlossen haben!