Optimierung von Spieler-gestalteten Welten: Die Rendering-Strategie von SEED in Unity

SEED ist eine persistente MMO-Sandbox von Klang Games, entwickelt mit Unity. Die Handlung spielt auf einem fernen Planeten, wo Spieler autonome Charaktere, sogenannte Seedlings, steuern. Das Spiel bietet eine spielergetriebene Wirtschaft, Gesellschaftsbau und eine kontinuierliche Welterweiterung, die auch nach dem Abmelden der Spieler fortbesteht. Jede neue Struktur, jeder Baum oder jeder Charakter, den Spieler hinzufügen, erhöht die Rendering-Last im Unity-Client, der diesen dynamischen Zustand über ein breites Spektrum an Hardware verarbeiten muss, von High-End-PCs bis hin zu Smartphones. Die Simulation läuft auf dedizierten Servern, während der Client für das Rendern des gestreamten Zustands und die Weitergabe von Spielerinteraktionen wie Klicks und Kamerabewegungen zuständig ist.

Der Kunststil von SEED ist bewusst stilisiert und low-poly. Die meisten Oberflächendaten werden direkt in der Geometrie gespeichert, anstatt auf Texturen zu setzen. Dieser Ansatz reduziert die Kosten für das Shading und den Speicherbandbreitenverbrauch, was für die mobile Leistung entscheidend ist. Gebäude werden aus kleinen, ziegelartigen Modulen auf einem Gitter mit einem Meter Abstand errichtet. Jeder von einem Spieler platzierte Voxel wird in etwa 15 Module ausgedehnt, wobei Innenräume nur bei der Ansicht generiert werden. Die größte Gesellschaft auf einer belebten Insel umfasst 172 Gebäude, rund 12.500 Voxel und 190.000 Module. Diese werden mit BatchRendererGroup gerendert, wobei Jobs im C# Job System ausgeführt und mit dem Burst-Compiler kompiliert werden, um die Effizienz trotz der hohen Objektanzahl sicherzustellen.

Klang Games verwendet die Universal Render Pipeline (URP) und folgt eng den Standardlösungen von Unity, um die Kompatibilität mit zukünftigen Updates zu gewährleisten. Das Spiel läuft derzeit auf Unity 6.3, und das Team aktualisiert die Engine etwa ein- bis zweimal im Jahr, um auf neue Rendering-Funktionen zugreifen zu können. Eigene Effekte werden über eigene Renderer Features implementiert, anstatt die URP zu ersetzen, wodurch Kernfunktionen wie SRP Batching und GPU Resident Drawer erhalten bleiben. Für Natur-Assets wird Shader Graph mit dem Standard-Lit-Shader verwendet, während Charaktere Unlit-Shader mit einem eigenen Beleuchtungspass nutzen. Diese Strategie stellt sicher, dass das Erstellen eigener Shader Graphs die zugrunde liegenden Leistungsmechanismen nicht beeinträchtigt und eine stabile Grundlage für eine Welt schafft, in der die Spieler die Rendering-Komplexität bestimmen.

Die Interaktion mit der dichten, von Spielern gestalteten Umgebung erfordert präzise Auswahlmethoden. Bei Nahaufnahmen verwendet das Spiel pixelgenaues Picking, indem Objekte in ein Off-Screen-Render-Target mit eindeutigen IDs gezeichnet werden, sodass der Client das genaue Objekt unter dem Cursor identifizieren kann. Auf Mobilgeräten, bei denen die Touch-Eingabe weniger präzise ist, prüft das System die umliegenden Pixel und zeigt eine Auswahlliste an, wenn mehrere Objekte erkannt werden. Bei weiten Ansichten wechselt das System zu physikalischen Raycasts und nutzt Unity Physics, um eine große Anzahl von Collidern für Bäume, Objekte und Baumsteine zu initialisieren und abzufragen. Ein kontinuierlich laufender Job bestimmt, ob sich Objekte innerhalb von Gebäuden befinden, um Render-Ebenen und Beleuchtung zu verwalten. Dies ermöglicht Funktionen wie das Deaktivieren von GameObjects oder die Anpassung der Sichtbarkeit basierend auf der Position des Spielers innerhalb einer Struktur.

Die Leistungsoptimierung stützt sich stark auf realistische Daten aus Live-Server-Snapshots, die lokal wiederhergestellt werden, um große Gesellschaften zu testen. Dieser Ansatz zeigte, dass das Spiel auf dem PC oft CPU-lastig ist, da Draw Calls übermittelt werden müssen, obwohl GPU Resident Drawer verwendet wird. Das Problem wurde auf animiertes LOD-Crossfading zurückgeführt, das das Instancing von Objekten verhinderte. Durch Deaktivierung des animierten Teils und die Verwendung manueller Übergänge stellte das Team das Instancing wieder her, was die CPU-Last erheblich verringerte. Auf Mobilgeräten ist der Hauptspeicher das primäre Limit, nicht die CPU. Mit dem Memory Profiler identifizierte das Team Probleme wie duplizierte Texturen und überdimensionierte C#-Sammlungen. Um den Speicherbedarf für Geometrie zu senken, ersetzten sie klassische LOD Groups durch Mesh LOD in Unity 6.2. Diese Funktion speichert alle Detailstufen in einem einzigen Mesh, was den Speicherbedarf reduziert und das Asset-Management für mobile Plattformen vereinfacht.