Wie Wishfully „Planet of Lana II“ gleichzeitig auf allen Plattformen veröffentlichte

„Planet of Lana II“ ist ein filmisches Rätsel-Abenteuer, das von Wishfully entwickelt wurde, einem schwedischen Indie-Studio, das 2018 in Göteborg gegründet wurde. Dieses Spielerlebnis auf PC, Xbox, PlayStation® und Nintendo Switchᵀᴹ – einschließlich der Hardware der nächsten Generation – zu bieten, stellt eine große technische Herausforderung dar.

Wir haben uns mit dem Co-Studioleiter und Kreativdirektor Adam Stjärnljus, dem leitenden Programmierer Edvard Rutström und dem leitenden Programmierer Mattias Wargren zusammengesetzt, um zu erörtern, wie sie ihre Codebasis vereinheitlicht, ihre Build-Pipeline skaliert und das Spiel so optimiert haben, dass es auf den meisten Plattformen 60 FPS erreicht und gleichzeitig für PC und Konsolen veröffentlicht werden konnte.

*Nintendo Switch ist eine Marke von Nintendo.

Könntest du uns einen Überblick über „Planet of Lana II“ und dessen Umfang als plattformübergreifendes Projekt geben?

Adam Stjärnljus: „Planet of Lana II“ baut auf dem Original auf und bietet etwa doppelt so viel Inhalt sowie einen erweiterten Umfang. Im Gegensatz zum ersten Spiel, das zunächst auf Xbox und PC erschien, bevor wir es auf andere Plattformen portierten, haben wir die Fortsetzung für eine gleichzeitige Veröffentlichung auf mehreren Plattformen entwickelt, darunter PC, Xbox One und Xbox Series X|S, PlayStation 4 und PlayStation 5 sowie Nintendo Switch. Wir haben es am 5. März 2026 auf den Markt gebracht.

Es handelt sich nach wie vor um ein Rätsel-Abenteuerspiel, das Lana und ihren Begleiter Mui auf einer storybasierten Reise begleitet, die Rätsel, Plattform-Elemente und Stealth-Action miteinander verbindet. Im Mittelpunkt des Spielablaufs stehen die kooperativen Interaktionen zwischen Lana und Mui, während die Handlung die Welt und den Konflikt aus dem ersten Spiel weiter ausbaut.

Welchen Ansatz verfolgte das Team bei der Festlegung der Vision für eine gleichzeitige Einführung auf mehreren Plattformen, und welche Faktoren bestimmten die Auswahl der Plattformen?

AS: Wir sind an die Fortsetzung mit dem Ansatz „Multiplattform zuerst“ herangegangen und haben auf der Plattformabstraktion und den Tools des ersten Spiels aufgebaut. Unser Ziel war es, bereits in einer frühen Produktionsphase kontinuierliche Builds auf allen Zielplattformen durchzuführen, damit wir die Leistung während der gesamten Entwicklungsphase testen und optimieren konnten, anstatt diese Arbeit bis zum Schluss aufzuschieben.

Wir haben die Plattformauswahl – PC, Xbox, PlayStation und Nintendo Switch – auf der Grundlage des Erfolgs der ursprünglichen Veröffentlichung und unseres Ziels getroffen, einen zeitgleichen Start auf allen Plattformen zu gewährleisten. Um dies zu unterstützen, haben wir bestehende Tools und Arbeitsabläufe weiterentwickelt, damit das gesamte Team schon frühzeitig zu Leistungsverbesserungen beitragen konnte, auch wenn es nach wie vor eine Herausforderung war, die Kompatibilität über alle Zielplattformen hinweg zu gewährleisten.

Inwiefern hat Ihre technische Architektur effiziente plattformübergreifende Builds und Deployments ermöglicht, ohne dass plattformspezifische Codesilos entstanden sind?

Mattias Wargren: Wir haben eine Plattformfragmentierung vermieden, indem wir ein einziges Unity-Projekt ohne Plattform-Forks verwendet und auf einer gemeinsamen Plattform-Abstraktionsschicht aus dem ersten Spiel aufgebaut haben. Wir haben Plattformunterschiede mithilfe von Kompilierungsdefinitionen, bedingten Systemen und Tools bewältigt, anstatt separate Codebasen zu pflegen.

Außerdem haben wir Tools zur Inhaltsfilterung implementiert, um Inhalte je nach Plattform einzubinden oder auszuschließen, sowie abgestufte Qualitäts- und Detailstufen, die wir für jedes Gerät individuell anpassen konnten. Zusätzlich zu den integrierten Einstellungen von Unity haben wir ein benutzerdefiniertes Qualitätssystem hinzugefügt, um mehr Kontrolle zu ermöglichen.

AS: Dank dieser Konfiguration konnten Designer und Entwickler Inhalte und Leistung an das jeweilige Endgerät anpassen und gleichzeitig alles in einer einzigen Pipeline zusammenfassen. Dadurch blieben die Builds während der gesamten Produktion effizient und überschaubar.

Wie haben Sie die Build-Pipeline so gestaltet, dass sie das Deployment auf allen Plattformen unterstützt und gleichzeitig Engpässe beim Build-Prozess vermeidet?

Edvard Rutström: Wir haben der Build-Pipeline schon früh Priorität eingeräumt und zunächst eine lokale Lösung mit TeamCity und dedizierten Build-Agenten eingerichtet, um die Builds von den Entwicklerrechnern fernzuhalten und Konflikte zu vermeiden. In der Endphase des Projekts sind wir auf eine vom Publisher gehostete Infrastruktur mit mehr Build-Agenten umgestiegen, was automatisierte nächtliche Builds auf allen Plattformen ermöglichte und Engpässe reduzierte.

Außerdem mussten wir eine öffentliche Demo auf allen Plattformen unterstützen, was die Komplexität der Builds erhöhte und die Anzahl der Builds praktisch verdoppelte. Wir haben dies innerhalb desselben Repositorys und Projekts mithilfe eines Build-Flags umgesetzt, um zwischen Demo und Vollversion zu unterscheiden, wobei Inhalte, die nicht zur Demo gehören, beim Erstellen entfernt wurden. Technisch gesehen funktionierte das zwar gut, doch die Verwaltung der zahlreichen Builds – insbesondere da die Qualitätssicherung sowohl Debug- als auch Release-Varianten benötigte – wurde zu einem erheblichen Mehraufwand.

MW: Wir haben die Pipeline so konzipiert, dass sie portabel ist. Bei der Migration der Infrastruktur mussten wir weder unseren Code noch unsere Build-Skripte ändern, sodass der Übergang reibungslos verlief und die Entwicklung nicht beeinträchtigt wurde.

Welche Integrationsstrategie sorgte für Stabilität, während parallel dazu zahlreiche plattformspezifische Optimierungen entwickelt wurden?

MW: Wir haben Stabilität erreicht, indem wir einheitliche Qualitätsstufen mit leistungsstarken Validierungstools kombiniert haben. Wir haben plattformspezifische Qualitätsmodi implementiert, die wir direkt im Unity-Editor simulieren konnten. So konnten Designer und Grafiker vorab sehen, wie sich Inhalte auf unterschiedlicher Hardware verhalten würden, ohne das Projekt verzweigen zu müssen.

Außerdem haben wir automatisierte Tools entwickelt, um Kontrollpunkte durchzugehen, Screenshots zu erstellen und Leistungskennzahlen einzublenden. Dadurch erhielt das Team einen kontinuierlichen Einblick darin, wie sich Änderungen auf die verschiedenen Zielplattformen auswirkten, und konnte parallel weiterentwickeln, während die Codebasis stabil blieb.

Wie haben Sie Ihre Asset-Pipeline strukturiert, um die plattformübergreifende Entwicklung zu optimieren und die doppelte Erstellung von Assets zu vermeiden?

ER: Wir haben uns von einem Ansatz verabschiedet, bei dem der Schwerpunkt stark auf der Bündelung von Inhalten lag. Es erwies sich als schwierig, Doppelungen bei den Assets zu vermeiden, zumal wir Biomen-Inhalte im gesamten Spiel wiederverwendeten, was eine klare Trennung unpraktikabel machte.

Stattdessen setzten wir auf einen besser kontrollierten Arbeitsablauf bei der Erstellung der Grafikelemente. Für die Audioverarbeitung haben wir isolierte Bänke in FMOD verwendet, für die Grafik Sprite-Atlas. Um die Leistung für verschiedene Hardware-Stufen zu optimieren, haben wir uns auf das „Asset Stripping“ und die Größenbeschränkungen von Atlas-Dateien konzentriert, wodurch der Speicherbedarf gesenkt werden konnte, ohne dass zusätzliche Duplikate entstanden sind.

Dieser Ansatz sorgte für einfachere Builds und stellte gleichzeitig ein vorhersehbares Ladeverhalten sowie eine stabile Speicherauslastung auf allen Geräten sicher.

Inwiefern haben Ihre Spielmechaniken, die das C# Job System und den Burst-Compiler nutzen, das plattformübergreifende Deployment von Builds unterstützt?

ER: Wir haben das Unity C# Job System und den Burst-Compiler in einigen ausgewählten Systemen eingesetzt, vor allem in einer Elementarsimulation, die Feuer, Hitze und Wasser abdeckt, sowie in einem System zur Schneeverformung.

Da diese Systeme klar definiert und datenorientiert waren, ließen sie sich problemlos auf unterschiedliche Hardware übertragen, ohne dass eine besondere Handhabung erforderlich war. Es traten weder Abstürze noch Race Conditions auf, sodass die üblichen Best Practices für das Job-System ausreichten.

Wie haben Sie Profiling-Daten genutzt, um Build-Konfigurationen und plattformspezifische Optimierungen zu optimieren?

MW: Wir stützten uns auf Profiling-Ergebnisse aus den Entwicklungsversionen auf allen Plattformen und nutzten automatisierte Momentaufnahmen, um Problembereiche auf den einzelnen Ebenen zu identifizieren. Anstatt jede Plattform von Anfang an separat zu optimieren, haben wir uns zunächst auf Verbesserungen konzentriert, die allen Zielplattformen zugute kamen, und erst danach bei Bedarf bestimmte Engpässe gezielt behoben.

ER: Wir begannen mit einem Basisdurchlauf mit niedrigen Spezifikationen und gingen gezielt gegen CPU-Engpässe – und manchmal auch gegen GPU-Engpässe – vor, wobei wir durch Optimierungen die visuelle Qualität beibehielten. Diese Arbeit zahlte sich aus und half uns, auf den meisten Zielplattformen 60 FPS zu erreichen. Außerdem haben wir intensiv Speicherprofilierung eingesetzt, um das Laden von Assets und den Speicherbedarf zu optimieren.

AS: Es war ein endloser Kreislauf. Wir haben Analysen durchgeführt, Probleme wie Draw Calls und Framerate-Einbrüche identifiziert, Optimierungen vorgenommen und den Vorgang wiederholt. Im Laufe der Zeit entwickelte sich daraus ein Arbeitsablauf, bei dem die Entwickler Leistungsbeschränkungen früher erkannten, wodurch Nacharbeiten in späten Phasen reduziert wurden.

Wie haben Sie Navigationssysteme konfiguriert und entwickelt, um sicherzustellen, dass sie effizient beim Deployment eingesetzt werden und auf verschiedenen Plattformen einheitlich funktionieren?

MW: Wir haben eine Kombination aus statischen und dynamischen NavMesh-Volumen verwendet, wodurch ein Gleichgewicht zwischen vorberechneten Daten und Flexibilität zur Laufzeit hergestellt wurde. Wir haben die Navigationseinstellungen für jede Plattform über Qualitätskonfigurationen angepasst, wodurch wir Präzision und Leistungskosten pro Gerät steuern und gleichzeitig ein einheitliches Verhalten gewährleisten konnten.

Was würdest du im Nachhinein anders machen, und welchen Rat würdest du Teams geben, die einen gleichzeitigen Start auf mehreren Plattformen planen?

ER: Eine Sache, die wir ändern würden, ist die Automatisierung der Patch-Erstellung in der Build-Pipeline. Das manuelle Vorgehen war zeitaufwendig und nicht skalierbar.

Unsere wichtigste Erkenntnis ist, von Anfang an auf mehrere Plattformen zu setzen. Erstellen und testen Sie frühzeitig auf allen Zielplattformen und verschieben Sie die Optimierung nicht auf den Schluss. Außerdem haben wir eine Plattform-Abstraktionsschicht entwickelt, die gängige Funktionen wie das Speichern von Daten, Erfolge und die Benutzerverwaltung hinter einer einzigen API bündelt. Dadurch blieben die Implementierungen voneinander isoliert, und es war einfacher, neue Plattformen zu unterstützen, ohne den Rest des Codes zu beeinträchtigen.

Weitere Informationen zu Projekten, die mit Unity erstellt wurden, finden Sie auf der Seite „Ressourcen“.