Optimierung von Deep Rock Galactic: Survivor für Mobilgeräte

Deep Rock Galactic: Survivor auf Mobile zu bringen bedeutete, ein Bullet-Heaven-PC-Spiel zu nehmen und es auf Hardware mit einem weitaus geringeren Budget an GPU, CPU und Arbeitsspeicher lauffähig zu machen. Den Port übernahm Piktiv, während der PC-Zweig noch aktiv entwickelt wurde, und die Teams drifteten so weit auseinander, dass der Merge nur in eine Richtung lief: vom PC in die Mobile-Version, aber nie zurück. Diese Trennung gab Piktiv die Freiheit, mit den ursprünglichen Systemen destruktiv umzugehen — etablierte Ansätze auseinanderzunehmen und sie um einen völlig anderen Satz an Optimierungszielen herum neu aufzubauen. Die zentrale Einschränkung war der Arbeitsspeicher: Fast alle Zielgeräte hatten 4 GB RAM, mit Ausnahme eines iPads, das nur 3 GB hatte. Darauf blieben dem Team rund 1.850 MB für alles, und ein Überschreiten bedeutete einen Absturz.

Die Performance-Arbeit konzentrierte sich auf die Systeme, deren Kosten mit der Anzahl der Gegner steigen. Schadenszahlen waren ursprünglich GameObjects mit TextMesh Pro, aber die Generierung eines Text-Meshes für tausend Gegner auf einmal wurde zum Flaschenhals. Die Lösung war ein standardmäßiges Unity-Partikelsystem mit einem Sprite-Sheet mit den Ziffern 0 bis 9. Die Wegfindung wechselte vom eingebauten NavMesh-System, das Probleme hat, wenn Tausende Agenten jeweils eigene Pfade berechnen, zu einem Flow-Field-Ansatz, bei dem die Kosten von der Fläche und nicht von der Anzahl der Agenten abhängen. Physikabfragen wurden mit einem KD-Baum für räumliche Lookups beschleunigt — etwa um alle Gegner im Explosionsradius einer Granate zu finden —, was jedoch häufige Neuaufbauten erforderte, während sich die Gegner bewegten. Beim Gegner-Rendering ersetzte man rund tausend Skinned-Mesh-Renderer durch gebackene Vertex-Animation: Jedes Keyframe wird in einer Textur gespeichert und von einem GPU-Shader abgespielt, was die CPU-Kosten auf nahezu null senkt und GPU-Instancing auf einem gemeinsamen Mesh und Material ermöglicht.

Die tieferen technischen Details erklären, wie diese Ersetzungen funktionieren. Das Flow-Field kehrt das Kostenmodell der Wegfindung um: Über das Level wird ein Raster gelegt, und ausgehend vom Ziel zeichnen Kacheln Pfeile zu Nachbarn, die bereits Pfeile haben, bis das gesamte Feld bedeckt ist. Die Kosten hängen dann von der abgedeckten Fläche ab, nicht von der Anzahl der Agenten, und lassen sich weiter begrenzen, indem man einen Begrenzungsquader um alle Gegner und den Spieler berechnet und das Feld nur innerhalb dieser Region aktualisiert. Der KD-Baum teilt den Raum rekursiv auf, sodass eine Abfrage „Punkt und Radius“ schnell alles innerhalb zurückliefert und schwerere Physikabfragen ersetzt. Diese Systeme flossen in eine Kette von Burst-Jobs mit 10 bis 15 Abhängigkeiten ein, die alle Gegner aus dem regulären Physiksystem herausführt und die untere Grenze der Bildrate spürbar anhebt.

Addressables waren zentral dafür, das 3-GB-Limit des iPad einzuhalten. Da das Spiel nie mehr als ein Biom gleichzeitig zeigt, lagerte Piktiv biome-spezifische Grafik-Assets und Einstellungen so aus, dass sie nur bei Bedarf geladen werden. Der Preis dafür ist, dass Addressables Asynchronität in Code bringen, der zuvor synchron war, und die Umstellung eines Systems auf async kann eine erhebliche architektonische Herausforderung sein, doch hier hat es sich gelohnt. Das Testen stützte sich auf ein automatisiertes Messsystem, das sechs Szenarien über alle Biome hinweg durchlief: eine Basislinie mit untätigem Spieler, tausend anrückende Gegner oder 500 Gegner plus automatisch feuernde Waffen. Dabei wurden durchgehend CPU, GPU und Speicher gemessen, und der Unity Profiler führte frühe CPU-Audits durch. Ein Szenario, das innerhalb von zehn Sekunden rund 4 000 blaue Pickup-Würfel erzeugte, war vor der Optimierung eine ernsthafte Belastung und wurde danach unmessbar. Die Level-Geometrie, die prozedural aus einzelnen Objekten aufgebaut wird, wurde ebenfalls durch benutzerdefinierte Draw-Befehle gebatchet, da die feste Kamera von oben die sichtbare Fläche leicht berechnen lässt.

Für Teams, die über einen ähnlichen Port nachdenken, betreffen die Erkenntnisse weniger einen einzelnen Trick als vielmehr das Datenlayout und das Zusammenspiel zwischen Systemen. Daten aus Komponenten hinein- und wieder herauszuschieben wird teuer, wenn Tausende Entitäten jeden Frame ausgeführt werden; daher lohnt es sich, alles in nativen Containern zu halten und dieselben Container durch die gesamte Pipeline zu schleusen. Und ein Spiel, das eigentlich ECS oder den Data-Oriented Technology Stack hätte nutzen sollen, braucht keine vollständige Überarbeitung: Dieses Projekt stützte sich auf den Burst-Compiler und native Datentypen, ohne das gesamte Spiel umzustellen. Deep Rock Galactic: Survivor ist auf Steam, Xbox, im App Store und bei Google Play erhältlich.