Wie Jam City Disney Magic Match 3D für hohe Leistung entwickelt hat

In Disney Magic Match 3D sind die Spieler eingeladen, die verzauberte Magie von Book of Magic, deren Magie fehlgeschlagen ist, wieder in Ordnung zu bringen und ikonische Disney- und Pixar-Elemente über die Seiten zu verteilen. Die Spieler müssen verzauberte Objekte zusammenbringen, die skurrile Unordnung organisieren und die Freude am Aufräumen wiederentdecken, um die Ordnung im Buch der Magie wiederherzustellen – ein gemütliches Level nach dem anderen.

Während der gesamten Entwicklung setzte sich jedes Team von Jam City ehrgeizige Ziele: Das Grafikteam drängte auf hohe visuelle Wiedergabetreue bei strengen Polybudgets; das Produktteam optimierte für ideale Session-Time-Targets; Designer sorgten für einen stetigen Fluss neuer Inhalte und QA-Tester benötigten leistungsstarke Tools. Währenddessen legten die Ingenieure von Jam City für alle Plattformen Wert auf erstklassige technische Leistung, Stabilität, Schnörkeligkeit und mehr. So meisterten sie komplexe Herausforderungen, um ihre Vision zum Leben zu erwecken.

Disney Magic Match 3D: Eine Unity-Fallstudie

Wie hält ein Studio die Leistung aufrecht und bewältigt gleichzeitig Herausforderungen wie Überhitzung, Inhaltsbereitstellung und andere technische Probleme?

Während der Produktion bedeutete das Rendern von Hunderten von 3D-Objekten mit Physik in einer einzigen Ebene, dass man bei Beleuchtung, Nachbearbeitung und Polyanzahl vorsichtig sein musste.

"Überhitzung war schon früh ein großes Problem, insbesondere bei 20-minütigen Sitzungen – Telefone wurden unangenehm heiß", sagt Hebby Mathew, Software-Engineering-Managerin bei Jam City und technische Leiterin von Disney Magic Match 3D. „Wir haben die Leistung verbessert und eine Möglichkeit entwickelt, die Gerätewärme über verschiedene Hardware hinweg konsistent zu messen.“

Eine weitere Herausforderung war die Bereitstellung von Inhalten – das asynchrone Streaming von Assets ohne Beeinträchtigung der Framerate. „Der erweiterbare Editor von Unity hat uns geholfen, effiziente Tools zu entwickeln, um zu verwalten, wann und wie Inhalte geladen wurden“, sagt Mathew.

Schließlich identifizierte das Team bei der Profilerstellung für Low-, Mid- und High-End-Geräte zentrale Probleme wie übermäßige Kollisionsaufrufe und High-Poly-Modelle, insbesondere für Low-End-GPUs.

„Die Optimierung brachte sowohl Leistungszuwächse als auch half, die Überhitzungsprobleme zu lösen“, sagt Mathew.

Die Ergebnisse

- Erhöhung der Bildrate um 40 FPS auf Low-End- und 35 FPS auf Mid-End-Android-Geräten

- Reduzierung der Anzahl der Draw Calls um 40 % auf iOS und 45 % auf Android Geräten

- RAM-Nutzung auf iOS- und Android-Geräten um 30 % reduziert

- Verringerung der Ladezeit für Nicht-Netzwerkverarbeitung um 55 %

- Verringerung der Anzahl der Meshes mit über 10.000 Dreiecken von 33 auf 0

- Reduzierung der Anzahl der Meshes mit 5.000 bis 10.000 Dreiecken von 324 auf 235

- Reduzierung der Lichtanzahl um 67 %

Performance über Frames und Systeme hinweg verfolgen

Als das Team auf Leistungsprobleme traf, wandte es sich an Profilerstellungstools, um tiefere Einblicke zu erhalten.

„Unity Profiler-Marker waren besonders hilfreich für die Verfolgung von Multi-Frame-Aufgaben“, sagt Kevin Johnson, Software Engineer bei Jam City. „Ich habe auch die Profiler Analyzer für Vergleiche verwendet.“

Andrea Ramirez, ein weiterer Techniker, erweiterte die Analyse mit Binärlogdateien, um spezifische Frame-Snapshots zu erfassen. „So konnten wir die Leistung analysieren, ohne den Profiler live zu brauchen“, erklärt sie.

Das Team passte den Profiler weiter an und fügte Einwegartikel hinzu, um die Auslösung und Protokollierung zu optimieren. Neben dem CPU-Profiling überwachten sie den Speicher mit dem Memory-Profiler und lösten Rendering-Probleme mit dem Frame Debugger. Profiler Recorder ermöglichte es ihnen, globale Leistungsstatistiken während reproduzierbarer Tests zu verfolgen.

„Eine der größten Stärken der Engine ist die Erweiterbarkeit des Editors“, fügt Ramirez hinzu. „Durch die Erfassung von Multi-Frame-Schnappschüssen und Skripting-Tests haben wir konsistente, zuverlässige Leistungsdaten gesammelt.“

Reduzierung großer Leistungsspitzen

Das Profiling zeigte große Leistungsspitzen beim Levelstart, die hauptsächlich durch Shader-Kompilierung verursacht wurden, als Assets zum ersten Mal auftauchten. Mithilfe von Addressables identifizierte das Team doppelte Assets, die unnötige Shader-Kompilierungen auslösten.

„Wir haben UI-Elemente und Spielfiguren früher vorgeladen“, sagt Entwickler John Enney. „Unsachgemäß gruppierte Asset-Pakete waren ein Schlüsselproblem, das zu einer wiederholten Shader-Kompilierung führte – etwas, das ich anfangs übersehen habe.“

Schon früh integrierte man Quick Outline, um schnell Highlights hinzuzufügen. Es wurde zwar ein gewisses Overdrawing eingeführt – zusätzlicher Rendering-Overhead – aber Optimierungen ermöglichten es ihnen, es ohne vollständiges Umschreiben beizubehalten.

Audio trug ebenfalls zu Leistungsspitzen bei. „Jede Spielfigur löste ihren eigenen Kollisionsklang aus“, erklärt Enney. „Anfangs hat das gut funktioniert, aber bei gleichzeitigem Fallen von 300 Teilen stieg die Bildwiederholzeit auf 500 ms. Durch das Ersetzen dieser mehreren Sounds durch einen einzigen Umgebungsgeräuschpegel wurde dieser auf 20-30 ms reduziert – und es klang tatsächlich besser.“

Auch haptisches Feedback erforderte Feinabstimmung. „Wir haben haptische Anrufe bei Massenkollisionen begrenzt“, sagt Technikdirektor Troy Lee. „Diese Zurückhaltung hat die Leistung während des gesamten Spiels durchgängig verbessert.“

Die Beleuchtung stellte eine weitere Herausforderung dar. Das verzögerte Rendering verbesserte zwar die Leistung, widersprach aber künstlerischen Zielen. „Vorwärts-Rendering hat Schwierigkeiten mit mehreren Lichtquellen, da es pro Objekt teure Durchläufe erfordert“, erklärt Ramirez. Um Qualität und Effizienz ins Gleichgewicht zu bringen, entwickelte Enney eine Baked-Lighting-Lösung, die die visuelle Qualität bewahrt und gleichzeitig die Laufzeitleistung verbessert.

Auch die Geometriekomplexität war ein Problem. „Unsere anfänglichen Modelle haben 10.000 Dreiecke überschritten“, sagt die technische Leiterin Kristen Weeks. „Wir haben die meisten Modelle auf unter 2500 Dreiecke reduziert, um eine gute Leistung auf niedrigeren Geräten zu gewährleisten.“

Optimierung der Initialisierung und des Asset-Handlings

Schon früh verursachten das Laden von Assets und die Systeminitialisierung mit Webaufrufen große Probleme. Um Verzögerungen während des Gameplays oder der Benutzeroberflächeninteraktionen zu vermeiden, lud das Team zunächst alle Assets im Voraus. Mit der Erweiterung der Funktionen und Assets des Spiels wurden die Anlaufzeiten jedoch übermäßig lang.

Sie optimierten, indem sie einige Assets asynchron im Hintergrund laden ließen, wodurch die anfänglichen Ladezeiten reduziert wurden und gleichzeitig ein reibungsloses Spielerlebnis gewährleistet wurde. Sie parallelisierten auch das Laden von Aufgaben mit dem Aufgabensystem von .NET, und diese Verbesserungen brachten erhebliche Vorteile mit sich.

Auch die Netzwerklatenz, insbesondere während der anfänglichen Belastung, beeinträchtigte die Leistung. Um dies zu erreichen, wechselte das Team von Unity zu C# async/wait for network calls und reduzierte die Latenz. „Außerdem haben wir die JSON-Deserialisierung optimiert, indem wir den reflexionsbasierten Ansatz von Newtonsoft durch Codegenerierung ersetzt und die Leistung verbessert haben“, sagt Johnson.

Die Instanziierungskosten beeinträchtigten die anfänglichen Ladezeiten weiter, mit einer spürbaren Verzögerung – auf Mittelklassegeräten etwa eine halbe Sekunde – da das Spiel unmittelbar nach der Veröffentlichung viele UI- und Hintergrund-Prefabs erstellte.

„Ein großer Teil der Kosten war die umfangreiche Awake()-Initialisierung für viele Objekte“, erklärt Johnson. „Wir haben die Instanziierung optimiert, indem wir Objekte bei der Erstellung deaktiviert und nur bei Bedarf aktiviert haben. Wir haben auch die Instanziierung verschoben oder gestaffelt, anstatt alles auf einmal zu tun, was die sichtbare Latenz reduzierte.“

Um die Leistung genauer zu messen, verwendete das Team System.Diagnostics.Stopwatch, um Instanziierungsintervalle zu zeitabhängigen, und instrumentierte verschiedene Teile des Codes.

Trotz dieser Optimierungen beeinflusst die reale Netzwerkqualität die Ladezeiten. Um dies zu beheben, experimentiert das Team mit Lazy Loading – das Spiel wird mit allen Konfigurationen ausgeliefert und die Spieler können sofort einsteigen, während die Konfigurationen asynchron im Hintergrund aktualisiert werden. „Frühe Tests sehen vielversprechend aus, aber wir beobachten die Live-Ergebnisse vorsichtig“, sagt Mathew.

GPU-Beschränkungen auf weniger leistungsstarken Geräten

Während der Leistungsoptimierung stellte das Team fest, dass einige weniger leistungsfähige Geräte nur minimale Verbesserungen aufwiesen. Sie entdeckten, dass diese Geräte hauptsächlich Mali-GPUs verwendeten, die Schwierigkeiten hatten, die Zielobjektzahlen des Spiels effektiv zu verarbeiten. Das Ziel von 60 FPS konnte jedoch über alle Gerätestufen hinweg beibehalten werden.

Weeks erläutert diese Einschränkungen: „Ältere Mali-GPUs der dritten und vierten Generation sind strenge kachelbasierte Renderer, die leicht geometrisch gebunden werden können. Im Gegensatz dazu verwenden viele andere GPUs hybride Rendering-Techniken, die helfen, diesen Engpass zu vermeiden. Neuere Mali-GPUs, wie die der letzten Pixel-Telefone, haben mehr Recheneinheiten und handhaben die Geometrie viel besser.“

Um diese Einschränkungen besser zu verstehen, entwickelte Mathew bereits in einer frühen Entwicklungsphase ein Tool, das die zunehmende Anzahl von Objekten auf verschiedenen Geräten instanziierte, um Framerate-Abfälle zu verfolgen. Das Tool zeigte, dass bestimmte GPUs niedrigere Schwellenwerte hatten, was die Notwendigkeit unterstrich, Spielmodelle sorgfältig zu optimieren, ohne die Grafikqualität zu beeinträchtigen.

„In der Vorproduktion verlangte der Art Director einen starken Einsatz von Nachbearbeitungseffekten und mehreren dynamischen Lichtquellen“, sagt Weeks. „Allerdings haben wir die Nachbearbeitung für die Produktion entfernt, da sie einen erheblichen Beitrag zur Geräteüberhitzung und Leistungstreffern leistet.“

Enney steigerte auch die Effizienz, indem es ein Punktlicht direkt in Shader einbrannte und die Anzahl der aktiven Lichter von drei oder vier auf nur eins reduzierte.

Dieser kollaborative Ansatz ermöglichte es dem Team, ein optimales Gleichgewicht zwischen visueller Qualität und Leistung zu finden und ein reibungsloses Erlebnis auf einer Vielzahl von Geräten zu gewährleisten.

Unity Pro noch heute herunterladen

Machen Sie erste Schritte in der Spieleentwicklung mit mächtigen Tools, verifizierten Partnern und einer dynamischen Community. So können Sie mit der Qualität und dem Erfolg der Veröffentlichungen großer Studios konkurrieren und sie noch übertreffen.