Westeros für Mobilgeräte in Game of Thrones nachbauen: Drachenfeuer
Für Warner Bros. Games Boston brauchte mehr als nur die Adaption einer beliebten Spielereihe, um die Welt von Westeros auf mobile Geräte zu bringen. Mit House of the Dragon als Grundlage, Game of Thrones: Drachenfeuer Verbindet groß angelegte Multiplayer-Strategie und Drachenkämpfe zu einem Free-to-Play-Erlebnis, das für moderne mobile Hardware entwickelt wurde.
Die Spieler schlüpfen in die Rolle eines valyrischen Nachkommen, dessen Aufgabe es ist, Drachen auszubrüten, aufzuziehen und zu befehligen, während sie mit Tausenden anderer Spieler um die Kontrolle über den Eisernen Thron wetteifern. Um diese Fantasie Wirklichkeit werden zu lassen, war es notwendig, hochwertige Grafik, skalierbare Leistung und Live-Multiplayer-Systeme auf einer Vielzahl von Geräten in Einklang zu bringen.
Wir sprachen mit Ara Yessayan, dem technischen Direktor, und Taia Lee, der fortgeschrittenen technischen Künstlerin, über die Entwicklung von Drachen für mobile Hardware, die Unterstützung von groß angelegten Strategie-Gameplays und die Verwendung von Unity , um die Welt von Westeros zum Leben zu erwecken.
Was waren Ihre Hauptziele und Einschränkungen für das Spielerlebnis in der ersten Sitzung?
Ara Yessayan: Für die erste Spielsitzung ist es unser Ziel, den Spieler bei der Stange zu halten und jegliche Ausfallzeiten zu vermeiden, die sein Eintauchen in die Spielwelt stören könnten. Es ist wichtig, die Grundlagen unseres Spiels und die Geschichte, die wir in der Welt von „House of the Dragon“ erzählen wollen, schrittweise einzuführen.
Welche Strategien haben Sie angewendet, um die Ladezeiten für neue und wiederkehrende Spieler zu minimieren, und wie unterscheiden sich diese Erfahrungen?
AY : Bei einer Neuinstallation liegt der Fokus darauf, so wenige Daten wie möglich im Vorfeld abzufragen. Wir haben Techniken untersucht, um die Datenmenge zu reduzieren, die wir herunterladen oder in den Speicher laden müssen, bevor wir die Spieler zum Start unseres Erlebnisses bringen, und um Übergänge als Möglichkeit zu nutzen, einen Teil dieser Ladevorgänge abzudecken. Für einen zurückkehrenden Spieler benötigen wir mehr Daten, um Ihren Spielerstatus zu ermitteln und Sie an der richtigen Stelle auf der Karte zu platzieren. Obwohl die Grundidee ähnlich ist (Warten auf Daten minimieren), konzentrieren sich die Techniken stärker auf die Kosten der Deserialisierung und strategische Wege, um weniger Vorlaufaufwand zu erfordern.
Wie haben Sie während der Entwicklung die größten Engpässe bei den Ladezeiten identifiziert?
AY: Um die Ladezeiten zu verkürzen, haben wir verschiedene Ansätze verfolgt. Um einen Gesamtüberblick über die Engpässe zu erhalten, haben wir für jede Phase unseres Ladevorgangs benutzerdefinierte Profiling-Ereignisse eingerichtet, die in eine CSV-Datei geschrieben wurden. Wir haben die Werte über mehrere Sitzungen hinweg aggregiert, um die kritischen Phasen zu identifizieren. Wir haben diese außerdem in Chrome Trace Events und OpenTelemetry-Traces umgewandelt, um besser visualisieren zu können, wie die Phasen parallel geladen wurden.
Von dort aus haben wir uns in eine bestimmte Phase vertieft. Das CPU-Modul des Unity Profilers ermöglichte uns einen tieferen Einblick in ineffizienten Code, den wir bereinigen konnten. In einigen Fällen half uns die Aufzeichnung mehrerer Profile und die Verwendung des Unity Profile Analyzer dabei zu beurteilen, wie sich die Anpassung bestimmter Lastwerte auf die Ladezeiten auswirkte (oder verschlechterte).
Der CPU-Profiler erwies sich regelmäßig als nützlich, wenn es darum ging, Frames mit großen Rucklern zu untersuchen, den Ursachen für die Framerate-Einbrüche auf den Grund zu gehen und bessere Techniken zu finden.
Neben dem Laden half uns das Rendering-Modul dabei, Ineffizienzen beim Rendern im Spiel aufzudecken, und RenderDoc war ein weiteres Werkzeug, das wir nutzten, wenn wir eine detailliertere Analyse eines Laufzeitproblems durchführen mussten.
Um die Sitzungen aufrechtzuerhalten, mussten wir schließlich sicherstellen, dass unser Speicherverbrauch unter Kontrolle blieb. Wir haben mithilfe von Memory Profiler- Snapshots unnötige Asset- und Objektlasten identifiziert, insbesondere auf der Karte und in den Marschgebieten, was wiederum die Ladeanforderungen für den Spielstart verringerte.
Wie haben Sie den Memory Profiler von Unity verwendet, um die Speichernutzung von Asset-Bundles zu analysieren, einschließlich der Erkennung von Duplikaten und der Überprüfung des Entladens von Assets? Könnten Sie bitte ein konkretes Beispiel nennen?
Taia Lee: Wir verwenden üblicherweise den Memory Profiler, um Fälle zu identifizieren, in denen Assets zu unerwarteten Zeitpunkten im Spiel geladen werden und im Speicher verbleiben. Dies kann beispielsweise vorkommen, wenn eine Textur an mehreren Stellen verwendet wird, sich aber in einem einzigen Bundle befindet, was dazu führt, dass das gesamte Bundle geladen wird, obwohl nur diese eine Textur benötigt wird.
Dies ist ein weiterer Grund, warum wir darauf abzielen, spezifische gemeinsame Pakete zu erstellen, um dies zu verhindern. Das Tool ist auch hilfreich, um die größeren Gedächtnisstörer aufzuspüren, insbesondere solche, die uns vielleicht nicht bewusst waren oder die größer sind als erwartet.
Welche unerwarteten Leistungsprobleme traten in der Anfangsphase auf, insbesondere im Zusammenhang mit der Inhaltsbereitstellung und der Spielperformance?
AY: Eine Überraschung war, wie viel Speicherplatz zum Laden der Kartendateidaten benötigt wurde, die den Kartenaufbau darstellten. In Game of Thrones: Drachenfeuer Die Spieler nutzen ihre Armeen und Drachen, um Gebiete (Felder) auf der Karte zu erobern. Diese helfen dem Spieler, Ressourcen zu sammeln und schränken ein, wohin er seine Armeen entsenden kann, basierend auf der Voraussetzung, dass er oder ein anderes Mitglied seiner Fraktion ein angrenzendes Feld besitzen muss.
Uns war klar, dass wir die Kartendaten in einzelne Abschnitte unterteilen mussten, um die Inhalte laden zu können. Die Daten waren notwendig, damit das Spiel verstehen konnte, was sich an jeder Koordinate befand, insbesondere angesichts der zusätzlichen Daten, die wir für Knoten speichern mussten, die mehrere Kacheln umfassen. Das Laden aller Strukturen, die mit einer 2000×4000-Karte verknüpft sind, verbrauchte so viel Speicher, dass einige Geräte abstürzten.
Im Zuge der Verbesserungen und Optimierungen, die dazu führten, dass nur die relevanten Teile der Karte anstatt der gesamten Karte geladen wurden, verkürzte sich die Ladezeit für unsere wiederkehrenden Spieler erheblich.
Eine weitere Technik, die wir zur Optimierung der Karte einsetzten, bestand darin, GameObjects, die das Terrain auf der Karte darstellten, durch direktes Rendern der Meshes zu ersetzen. Dadurch konnten wir die Speicherkosten für die Instanziierung dieser GameObjects vermeiden. Die Kombination dieser Methode mit dem strategischen Laden nur der für die Umgebung benötigten Meshes und Modelle verbesserte sowohl die Performance beim Kartenaufruf als auch beim Scrollen.
Wie entscheidet man, welche Inhalte zum Start verfügbar sein müssen und welche später gestreamt oder geladen werden können?
AY: Der erste Schritt besteht darin, herauszufinden, was wir für das Erstnutzererlebnis (FTUE) benötigen, bevor die Spieler in den Mehrspielermodus unseres Spiels eintreten. Dies gibt uns die Möglichkeit, alle Daten herunterzuladen, die Spieler beim Betreten des vollständigen Spiels verwenden.
Es gibt weitere Arten von Inhalten, die sich auf den laufenden Betrieb oder Funktionen in fortgeschrittenen Entwicklungsstadien beziehen und die ebenfalls später im Prozess heruntergeladen werden können. Wir möchten sicherstellen, dass die Spieler das Spiel genießen können, sobald sie mit einem System in Berührung kommen.
Bei zukünftigen Ladevorgängen gilt es, ein sorgfältiges Gleichgewicht zu finden zwischen dem Laden von Inhalten im Voraus (was die Ladezeit verlängern kann) und dem asynchronen Laden (was möglicherweise einen Ladekreis aktiviert, bevor ein Bildschirm oder Bereich angezeigt wird). Wir arbeiten kontinuierlich an Verbesserungen in diesem Bereich, um die bestmögliche Benutzererfahrung zu erzielen.
Wie haben Sie Ihre Asset-Bundle-Pipeline strukturiert und automatisiert, um Downloadgröße, Speichernutzung und Laufzeitflexibilität in Einklang zu bringen?
TL: Wir sind in der Regel bestrebt, unsere Asset-Bundles unter 8 MB zu halten, wobei es je nach Anwendungsfall und den im Bundle benötigten Assets einige Ausnahmen gibt. Dies führte dazu, dass wir die Pakete so strukturierten, dass Assets, die üblicherweise zur Laufzeit zusammen verwendet werden, gleichzeitig verfügbar sind.
Umgekehrt vermeiden wir extrem große Pakete, bei denen nur ein Teil der Vermögenswerte genutzt wird. Wir haben Pakete nach Spielbereich, Funktion oder gemeinsam genutzten Asset-Typen geordnet. Wir haben beispielsweise verschiedene Biome auf unserer Karte, und jedes Biom verfügt über separate Objekte, die zu diesem spezifischen Ort passen.
Wir brauchen nicht die schneebedeckten Berge des Nordens zusammen mit unseren südlichen Wüstenbergen. Allerdings werden einige Meshes und Texturen von mehreren Biomen gemeinsam genutzt, sodass diese Assets in einem gemeinsamen Paket zusammengefasst werden.
Es geht um ein Gleichgewicht, das ein Verständnis dafür voraussetzt, wo im gesamten Spiel Ressourcen eingesetzt werden, um die Leistung zu optimieren. Wie bei jedem Live-Spiel handelt es sich um einen kontinuierlichen Prozess, den wir regelmäßig überprüfen und neu organisieren müssen, sobald weitere Funktionen hinzugefügt werden.
AY: Bevor Addressables auf den Markt kam, entwickelten wir intern eine Reihe von Tools, die uns dabei halfen, viele der Probleme anzugehen, die Addressables jetzt löst. Einige dieser internen Tools ermöglichen es uns, die Zusammensetzung unserer Bundles zu verstehen und fortgeschrittene Techniken zum Herunterladen von Patches für deren Aktualisierung zu nutzen (wir nennen dies „Binary Patching“).
Welche Kompromisse oder Herausforderungen sind Ihnen bei der Arbeit mit Asset-Bundles begegnet, und wie haben Sie diese bewältigt?
TL: Die größte Herausforderung, vor der wir stehen, ist, dass die Größe von Asset-Bundles drastisch ansteigen kann, wenn jemand ein bestehendes Prefab bearbeitet oder viele neue Assets hinzufügt, ohne sich der potenziellen Auswirkungen auf die Bundle-Größe und -Organisation bewusst zu sein.
Es kam vor, dass Bundles um mehr als 5 MB anwuchsen, ohne dass die Nutzer es bemerkten. Im schlimmsten Fall führte dies dazu, dass unsere .aab-Datei die Größenbeschränkung für die Einreichung im Store überschritt. Seitdem haben wir Warnmeldungen in unsere Build-Pipeline integriert, um solche Fälle zu erkennen und Entwicklern zu helfen, besser zu verstehen, wann ihre Änderungen die Bundle-Größen auf unerwartete Weise erhöhen könnten.
Wie handhaben Sie Abhängigkeiten von Assets, um redundante Downloads und unnötigen Speicherverbrauch zu vermeiden?
TL: In unserem internen Tool zur Verwaltung von Asset-Bundles können wir doppelte Assets in verschiedenen Bundles erkennen. Generell möchten wir nicht viele doppelt vorhandene Assets sehen, insbesondere keine größeren Assets. Deshalb fügen wir diese Assets direkt einem Bundle hinzu, anstatt zuzulassen, dass sie als Abhängigkeit aus mehreren Bundles eingebunden werden. Wir müssen sicherstellen, dass es in ein Paket aufgenommen wird, das an verschiedenen Stellen verwendet werden kann, aber normalerweise erstellen wir ein separates, gemeinsam genutztes Paket.
Welche Techniken haben Sie eingesetzt, um CPU-Spitzen oder Verzögerungen zu reduzieren, die durch die Deserialisierung von Assets beim App-Start verursacht werden?
AY: Eine der Techniken, die wir für unsere Designdaten verwenden, ist die Verwendung des Protocol Buffers (Protobuf)-Formats zur Speicherung anstelle des typischen JSON-Formats. Protobuf (das von gRPC verwendete Binärformat) bietet eine kompaktere Speicherung und schnellere Deserialisierung.
Durch die Verwendung einer zugehörigen strukturierten Schemadatei können wir Daten viel schneller in den Speicher laden, ohne den Inhalt von JSON-Zeichenketten zu analysieren und deren Struktur zu tokenisieren. Wir haben auch andere Optionen wie BSON und Odin Serializer geprüft, um Daten effizienter zu speichern und zu deserialisieren, aber die Möglichkeit, gRPC auch für eine effizientere Kommunikation mit unseren Servern zu nutzen, machte es zur richtigen Wahl für uns.
Ein effektives Thread-Management ist ebenfalls entscheidend. Ermitteln Sie, welche Aufgaben Sie vom Unity -Hauptthread auslagern können, damit Sie sich auf das Laden von Assets und Szenen an dem einzigen Ort konzentrieren können, an dem Sie diese Aufgaben erledigen können.
Wie lassen sich Build-Größe und Deployment-Pipelines optimieren, um schnellere Patches und Inhaltsaktualisierungen zu gewährleisten?
AY: Wir verwenden verschiedene Techniken. In erster Linie konzentrieren wir uns darauf, das richtige Gleichgewicht zwischen den im Binärcode des Spiels enthaltenen erforderlichen Assets und den später herunterladbaren Assets zu finden. Unser Spiel verfügt über ein Tutorial, dessen Abschluss einige Minuten dauert. Dadurch haben wir die Möglichkeit, bei Bedarf zusätzliche Ressourcen herunterzuladen, ohne die Spieler bei ihrem ersten Login zu unterbrechen.
Durch die Nutzung der Android Play Asset Delivery-Funktion standen uns außerdem mehr Ressourcen im Vorfeld zur Verfügung. Wir begannen damit, ausgewählte dynamische Datentabellen in den Spielclient zu integrieren, wobei wir davon ausgingen, dass einige davon veraltet sein würden. Durch das Herunterladen nur der geänderten Tabellen konnten wir die Ladezeit verkürzen.
Von dort aus haben wir unsere Binärpatching-Technik eingeführt, die es uns ermöglicht, schlankere Binär-Diffs herunterzuladen und modifizierte Dateien zu patchen, anstatt die neue Version direkt herunterzuladen. Wir können dies auch mit Asset-Bundles verwenden und Spielinhalte bei Bedarf für neue Live-Events patchen.
Welche Änderung, die Sie rückblickend vorgenommen haben, hatte die größte Wirkung auf die Ladezeiten der Spieler?
AY: Die einfache Antwort besteht darin, sicherzustellen, dass die Spieler nur das laden, was sie benötigen. Vor dem Soft-Launch haben wir festgestellt, dass die Karte einer unserer größten Engpässe bei den Ladezeiten ist. Damals lud das Spiel alle Kartenressourcen im Voraus, bevor wir mit unseren Optimierungen begannen, um nur die Regionen um die Heimatbasis des Spielers anzuzeigen.
Indem wir ermittelten, was wir benötigten, und Techniken implementierten, um den Rest später asynchron zu laden, konnten wir die Ladezeit um mehrere Sekunden selbst bei High-End-Geräten reduzieren. Unser Team hat die Mission, die Ladezeiten für die Spieler zu verbessern, erfolgreich umgesetzt und uns auf den Weg zu einem besseren Benutzererlebnis gebracht, und ich kann ihnen für ihre harte Arbeit hier nicht genug danken.
Um mehr über mit Unity erstellte Projekte zu erfahren, besuchen Sie die Seite „Ressourcen“ .