Vernetzung eines Physik-Koop-Spiels: LEGO® Voyager

Light Brick Studio wurde 2020 gegründet und ist ein unabhängiges Team, das sich auf Handwerkskunst und Spielererfahrung konzentriert. Ihr neuestes Spiel, LEGO Voyagers, ist ein Koop-Abenteuer über zwei Freunde, die ihren Traum, Astronauten zu werden, verwirklichen wollen. Es wurde am 15. September 2025 auf mehreren Plattformen gestartet. Das Erlebnis basiert eher auf Ton und Interaktion als auf Dialogen, sodass die Spieler die Geschichte durch das Spielen erleben können.

Die Online-Koop-Funktionalität wurde erst spät in der Entwicklung hinzugefügt, was das Team vor einzigartige Herausforderungen stellte. Wir sprachen mit Kasper Honnens de Lichtenberg, leitender Programmierer bei LEGO Voyagers, und Daniel Zastrow, Programmierer, über die Nachrüstung von Online-Koop in einem physiklastigen Projekt.

Was war das Hauptziel bei der Entwicklung von LEGO Voyagers?

Kasper Honnens de Lichtenberg (KHdL): Wir haben uns zum Ziel gesetzt, ein unterhaltsames Spiel zu entwickeln, das Emotionen weckt und ein starkes Gemeinschaftserlebnis fördert.

Daniel Zastrow (DZ): Unser Ziel war es, die Essenz des LEGO-Spiels einzufangen – Spaß mit einem Freund zu haben, sich so nah wie möglich an einem echten LEGO-Stein zu fühlen und sich auf ein Abenteuer zu begeben, bei dem man gemeinsam die Geschichte erlebt.

Welche Systeme waren technisch am schwierigsten zu implementieren?

KHdL: Das Hinzufügen des Online-Spiels während der Entwicklung bedeutete, dass wir die bestehenden Workflows für Grafik und Design unverändert beibehalten mussten. Wir haben Tools entwickelt, um Objekte und Szenen automatisch zu konvertieren, damit Teams ohne Unterbrechung weiterarbeiten können.

DZ: Die Vernetzung des Befestigungssystems war am schwierigsten. Jeder Stein kann auf unzählige Arten verbunden werden, und zwei Spieler können gleichzeitig interagieren. Da wir das Spiel nicht für das Online-Spiel entwickelt haben, habe ich einen Großteil der Logik umgeschrieben, damit der Host Aktionen validieren kann, während die Clients warten. Ich habe auch die Übergänge zwischen den Ziegeln geglättet, um Latenzzeiten zu verbergen.

Wie hat NVIDIA PhysX dazu beigetragen, mehrere lose LEGO-Steine über das Netzwerk hinweg synchron zu halten?

DZ: Wir haben nicht nach perfektem Determinismus gestrebt. Jeder Client simulierte die Physik lokal und verschob dann Objekte in Richtung Netzwerkaktualisierungen, um visuell kohärent zu bleiben. Bei schnellen Szenarien wie Katapulten war die reine Physik nicht zuverlässig, daher haben wir deterministische Flugbahnen verwendet und PhysX nach der Landung wieder aktiviert. Dieser Hybrid behielt das physische Gefühl ohne Störungen bei.

Wie hat Netcode for GameObjects und Relay Ihren Netzwerk-Workflow optimiert?

KHdL: Mit Netcode for GameObjects und Relay können wir schnell Online-Koop-Spiele einrichten, ohne die Netzwerkinfrastruktur von Grund auf neu aufbauen zu müssen. Da das Online-Spiel erst spät in der Entwicklung hinzugefügt wurde, brauchten wir einen stabilen Stack, damit wir uns auf das Gameplay konzentrieren konnten. Die Möglichkeit, das Paket zu öffnen und anzupassen, war von entscheidender Bedeutung, insbesondere um die automatische Szenenkonvertierung zu beschleunigen, wenn NGO-Workflows manuelle Änderungen erforderten. Diese Flexibilität half uns, Fehler zu beheben, Probleme in der späten Entwicklungsphase zu lösen und das Spiel schließlich auf den Markt zu bringen.

DZ: Designer konnten weiterhin offline arbeiten, und dank automatisierter Tools zur Szenenkonvertierung mussten wir nicht alle in eine einzige gemeinsame Szene zwängen. Wir haben auch einige Anpassungen am Workflow vorgenommen, ohne die Stabilität der Netzwerkschicht zu beeinträchtigen.

Wie haben die plattformübergreifenden Leistungsziele Ihre Physik- und Netzwerkimplementierung beeinflusst?

KHdL: Da LEGO Voyagers so stark auf Physik basiert, hatte die Leistung direkten Einfluss auf die Netzwerkstabilität. Auf der Nintendo Switchᵀᴹ haben wir 30 FPS für die Physik angestrebt, was bedeutete, dass wir alles sorgfältig optimieren mussten: Modelle zusammenfallen lassen, weniger detaillierte Assets und Schatten verwenden und komplexere Features wie Wasser vereinfachen. Die Beleuchtung und der Modellzusammenbruch erfolgten automatisch, wurden jedoch manuell ausgelöst.

DZ: Aus Sicht der Systeme mussten wir sicherstellen, dass die physikalischen Workloads vorhersehbar blieben, damit die vernetzten Interaktionen unter Last nicht beeinträchtigt wurden. Wir haben Skripte optimiert und bei Bedarf komplexere Systeme neu geschrieben. Die Parallelisierung physikalischer Vorgänge mit dem Job-System von Unity hat erheblich zu Casts, Triggern und Signalen beigetragen. Dadurch hatten wir mehr Spielraum, um die Physiksimulation und Netzwerkaktualisierungen reaktionsschnell zu halten.

KHdL: Wir haben jede Szene profiliert, Frame-Einbrüche verfolgt und optimiert, bis die Leistung diese Ziele konsistent erfüllte. Das Erreichen dieser Zahlen war unerlässlich – nicht nur für die Grafik, sondern auch, um sicherzustellen, dass Physik und Netzwerk synchron blieben und sich für die Spieler zuverlässig anfühlten.

Rückblickend betrachtet, welche Networking-Ansätze würden Sie ändern?

DZ: Wir hätten früher mit dem Networking begonnen. Als wir das Online-Spiel hinzugefügt haben, war das Spiel im Wesentlichen fertig. Die Entwickler hatten Szenen und Mechaniken erstellt, die im lokalen Koop-Modus perfekt funktionierten, aber oft implementierten sie dieselben Mechaniken unter der Haube auf unterschiedliche Weise. Als wir versuchten, sie zu vernetzen, wurden diese Unstimmigkeiten zu einem großen Problem – auch wenn im Spiel alles identisch aussah.

KHdL: Wir hatten beispielsweise drei verschiedene Hebel-Skripte. Diese Art von Doppelarbeit entsteht ganz natürlich, wenn Designer frühzeitig Prototypen für das Gameplay entwickeln, aber ohne eine gemeinsame Struktur führt dies später zu Reibungsverlusten, insbesondere beim Networking.

DZ: Ohne vorherige Umgestaltung mussten wir mehrere Versionen derselben Mechanik anpassen. Vernetzung deckt architektonische Probleme auf – Konsistenz ist entscheidend, sonst wird jede Funktion zu einem Sonderfall.

KHdL: Eine frühzeitige Einrichtung einer leichtgewichtigen Netzwerkstruktur wäre hilfreich gewesen. Der Aufbau neuer Funktionen auf einer gemeinsamen Grundlage macht automatische Konvertierungen und Werkzeuge wesentlich effektiver.

DZ: Eine weitere Herausforderung war das physikbasierte Design selbst. Es bot uns das gewünschte Gameplay, erschwerte jedoch die Vernetzung. Es besteht immer ein Spannungsverhältnis zwischen freiem Prototyping und der Festlegung auf technische Stabilität. Im Nachhinein hätte ein klarerer Übergang vom Experimentieren zur Strukturierung geholfen.

KHdL: Es ist ein Gleichgewicht. Hätten wir dieses Gespräch früher als Team begonnen, hätte das viel Leid erspart.

Welche Tipps würdest du für die Handhabung des Netzwerks in einem plattformübergreifenden Koop-Spiel geben?

DZ: Trennen Sie die Ausführung von der Validierung. Lassen Sie Kunden Aktionen ausführen, aber behalten Sie die Validierung auf dem Host oder Server. Wenn diese Verantwortlichkeiten miteinander verflochten sind, wird die Vernetzung wesentlich schwieriger und führt zu fragilem, übermäßig komplexem Code. Zwingen Sie keinen 100%igen Determinismus auf, wenn Sie ihn nicht benötigen. Streben Sie nach Konsistenz, die richtig aussieht und sich richtig anfühlt.

KHdL: Es ist auch wichtig, das Design an den Kontext Ihres Spiels anzupassen. LEGO Voyagers ist ein zwangloses Koop-Erlebnis, das uns Flexibilität ermöglicht. Eine perfekte Synchronisation ist nicht immer erforderlich.

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

*Nintendo Switch ist eine Marke von Nintendo.