Unity 6.6 schickt AssetBundles in den Ruhestand: inkrementeller Build von Slime Rancher 2 von 32 Minuten auf drei beschleunigt

Unity hat in Version 6.6 content directories veröffentlicht — eine neue Art, Inhalte zu packen und zu laden, die die Engine-Entwickler ausdrücklich als Ersatz für AssetBundles bezeichnen. Der wesentliche Unterschied: Die Runtime adressiert, lädt und entlädt nun einzelne Artefakte — etwa ein bestimmtes Mesh oder eine Textur — und nicht mehr ein ganzes Bundle. Der Zuschnitt der Bundles, für den sich Teams jahrelang Gruppierungsstrategien ausgedacht haben, ist keine Design-Entscheidung mehr.

Unity nennt Zahlen aus einem realen Projekt: Slime Rancher 2, von Addressables auf content directories portiert. Der inkrementelle Build sank von 32 Minuten 16 Sekunden auf 3 Minuten 4 Sekunden, der Clean Build von 58 Minuten 6 Sekunden auf 37 Minuten 13 Sekunden. Das fertige Spiel schrumpfte von 4 GB auf 2,88 GB, und das Laden beschleunigte sich von 45 auf 30 Sekunden — also um rund ein Drittel. Gemessen wurde in Unity 6.6 Beta (6000.6.0b10) auf einem MacBook Pro mit M5 Max.

Warum das Bundle als Ladeeinheit nicht mehr genügte

Ein AssetBundle ist eine unteilbare Einheit für Verteilung, Speicherung und Laden. Abhängigkeiten werden auf Bundle-Ebene verfolgt, und laden wie entladen lässt es sich nur als Ganzes. Daher der ganze begleitende Aufwand: das manuelle Aufteilen der Assets in Gruppen, das Nachverfolgen von Abhängigkeitsketten, der Kampf gegen doppelt abgelegte gemeinsame Ressourcen in mehreren Bundles.

Content directories sind anders aufgebaut. Unity verwendet ein inhaltsadressiertes Speicherschema — dieselbe Idee, die auch git zugrunde liegt: Jede Content-Datei wird über einen Hash ihres eigenen Inhalts benannt und adressiert. Deduplizierung wird damit von einer Aufgabe der Entwickler zu einer Eigenschaft des Formats. Untereinander verweisen die Artefakte dabei nicht über Hashes, sondern über stabile Identifikatoren — sonst würde die Änderung einer einzigen Datei kaskadierend die Hashes der gesamten Kette verändern; die Zuordnung von Identifikatoren und Hashes liegt im Build-Manifest.

Was in den Build kommt, wird nun nicht mehr durch das Markieren jedes einzelnen Assets festgelegt, sondern über Root-Assets — gewöhnliche ScriptableObjects. Abhängigkeiten werden automatisch mitgezogen und pro einzelnem Asset statt pro Bundle verfolgt. Im Code gibt es den neuen Typ Loadable<T>

— eine ladbare Referenz auf Engine-Ebene: Man deklariert ein Feld der Form Loadable<Mesh> bodyMesh und ruft anschließend bodyMesh.Load() auf; einzelne Assets lassen sich synchron oder asynchron über async/await laden und entladen. Objekte, auf die ein Loadable verweist, landen im Build, werden aber erst in den Speicher geladen, wenn sie angefordert werden. Das Laden selbst ist sowohl beim Lesen als auch beim Deserialisieren vollständig asynchron und nutzt die async-APIs der jeweiligen Plattform; zugrunde liegt das Content-File-Format, das 2022 in DOTS eingeführt wurde.

Was tun, wenn man bereits auf Addressables sitzt

Unity hat bestehende Projekte nicht kaputtgemacht. Content directories sind mit dem Addressables-Paket kompatibel, das weiterhin die Schnittstelle zum Organisieren von Inhalten bleibt, und bestehende Projekte lassen sich auf das neue Backend konvertieren: Slime Rancher 2 wurde ohne eine einzige Codeänderung umgestellt. Der Ablauf der Konvertierung und ein Vergleich der Varianten sind in der Addressables-Dokumentation beschrieben.

Es ändert sich der Ansatz dazu, was überhaupt markiert werden muss. Unity nimmt Assets, auf die ein Loadable verweist, automatisch in den Build auf und entfernt Duplikate selbst, sodass separate Bundles für gemeinsame Abhängigkeiten nicht mehr nötig sind. Die Dokumentation empfiehlt, ein einziges Root-Asset für das gesamte Projekt anzulegen — und wenn der Code viele Assets über String-Schlüssel lädt, ein ScriptableObject als Asset-Liste zu verwenden statt vieler Root-Assets.

Einschränkungen, die man vorab kennen sollte

In 6.6 funktionieren content directories nur mit lokalem Content — also dem, was mit dem Player ausgeliefert wird. Für die Remote-Auslieferung und das Nachladen nach der Installation braucht es weiterhin AssetBundles oder einen eigenen Mechanismus. Eine vollwertige granulare Auslieferung „über die Luft“ verspricht Unity für die Unity-7-Generation, Details sollen 2027 folgen.

• Die API BuildUsage

ist mit content directories nicht kompatibel: Assets, die sie verwenden, müssen angepasst werden; zum Aufspüren der Problemstellen wird Project Auditor vorgeschlagen;

Assets mit zyklischen Abhängigkeiten werden zu einem einzigen ladbaren Block zusammengeklebt — Unity gibt eine Warnung aus, und übersteigt die Gesamtgröße des Zyklus 64 MB, schlägt der Build fehl;

ein Clean Build kann langsamer ausfallen als ein Build mit AssetBundles;

das Mischen von AssetBundles und content directories in einem Projekt führt dazu, dass gemeinsame Abhängigkeiten zweimal gebaut werden;

jeder Build ist in sich geschlossen: Verweisen zwei content directories auf dasselbe Asset, landet in jeder eine Kopie.

Eine content directory wird zur Laufzeit registriert, danach stehen ihre Assets zur Verfügung; auch Szenen werden über ladbare Referenzen eingebunden. Die Details sind in der offiziellen Unity-Dokumentation zu content directories beschrieben.

Warum Unity ausgerechnet jetzt das Fundament austauschen musste

Content directories wirken wie ein Wechsel des Unterbaus für den gesamten Content-Stack und nicht wie ein einzelnes Feature von 6.6. Die Grenzen des AssetBundle scheinen auch im Design von Addressables durch: Ein spürbarer Teil der Arbeit mit diesem Paket lief darauf hinaus, die Unteilbarkeit des Bundles zu kompensieren. Wird die Basiseinheit atomar, verlieren manche vertrauten Aufgaben von Tech-Artists und Build-Engineers — die Aufteilung in Gruppen, die Jagd auf Duplikate, das manuelle Verwalten von Abhängigkeitsketten — von selbst ihren Sinn.

Die Richtung deckt sich mit der allgemeinen Bewegung der Branche hin zu inhaltsadressierten Speichern und inkrementellen Builds: Dasselbe Prinzip arbeitet längst in Versionskontrollsystemen und Build-Caches, und in großen Projekten zahlt es sich in erster Linie bei der Iterationszeit aus. Die zehnfache Verkürzung des inkrementellen Builds im Beispiel von Slime Rancher 2 trifft weniger den finalen Build als den täglichen Zyklus aus Ändern und Prüfen — und genau dort verbringen Teams ihre Arbeitsstunden.

Addressables verschwindet dabei nicht: Nach der Art der Migration zu urteilen, bleibt das Paket die Benutzerschnittstelle, während die content directories darunter ihren Platz einnehmen. Da Unity die Remote-Auslieferung in der Unity-7-Generation an das neue Fundament koppelt, dürfte der Umstieg auf dieses Backend mit der Zeit zur Voraussetzung für granulares Nachladen von Inhalten werden — und Projekte, die heute von einer manuellen Bundle-Aufteilung leben, sollten sich die Konvertierung frühzeitig ansehen.

Warum wurden AssetBundles erst jetzt in den Ruhestand geschickt: der Druck von Godot und Unreal, der aufgestaute Frust mit Addressables, ein Kurswechsel nach dem Abgang von John Riccitiello?