Lösung technischer und leistungsbezogener Probleme in Laser Matrix

Marius Thorvaldsen, Martin Sivertsen und Sindre Askim Gronvoll gründeten Breach im Jahr 2016, um immersive Spiele, XR-Erlebnisse und 3D-Simulationen zu schaffen. In den letzten neun Jahren hat das Auftragsstudio XR-Lösungen geliefert und gleichzeitig eigene Spiele entwickelt. Im Jahr 2024 brainstormten sie Ideen und begannen mit dem Prototyping, während sie nach einem neuen internen Projekt suchten. Ein Spielkonzept ging schnell in Produktion und wurde zu Laser Matrix.

Der Titel ist ein Mixed-Reality-Puzzle-Action-Spiel, in dem Fitness, Spaß und futuristische Herausforderungen aufeinandertreffen. Spieler können lichtbasierte Rätsel lösen, sich bewegenden Lasern ausweichen und Levels mit ihrer Agilität und ihrem Verstand freischalten.

Heute hat das Team Laser Matrix auf Meta Quest und Android XR veröffentlicht. Wir haben uns mit Andreas Weibye, dem technischen Direktor von Breach, und Jonathan Jørgensen, einem der Spieledesigner, zusammengesetzt, um über den Bau des Spiels für beide Plattformen zu sprechen und wie sie technische und Leistungsherausforderungen überwunden haben.

Was ist Laser Matrix?

Andreas: Laser Matrix ist ein Bewegungs-Puzzle-Spiel in VR. Es ist sehr arcade-ähnlich und kann dein Wohnzimmer in ein gefährliches Labyrinth verwandeln, in dem du schnell und geschickt navigieren musst.

Wie verlief der Implementierungsprozess für Meta Quest und Android XR?

Andreas: Wir haben Meta Quest und Android XR nicht gleichzeitig von Anfang an im Projekt implementiert. Der Prototyp begann nur für die Meta Quest. Wir haben intensiv mit der Plattform gearbeitet, sodass wir es schnell zum Laufen gebracht haben. Android XR existierte auch nicht, als wir mit diesem Prototypen begonnen haben, also haben wir während des Entwicklungsprozesses portiert.

Jonathan: Wir haben mit Metas "Baustein"-Tool begonnen, um schnelle Prototypen zu erstellen. Es machte die Validierung des Konzepts bequemer. Wir haben schließlich erkannt, dass wir auf plattformübergreifendes XR abzielen wollten und haben darauf geachtet, das Spiel in einer plattformunabhängigen Weise zu strukturieren. Das Kernspiel basiert nicht wirklich auf plattformspezifischen Funktionen, daher war der Übergang zu plattformübergreifend einfach.

Welche Schritte haben Sie unternommen, um das Handtracking in OpenXR zu implementieren?

Jonathan: Wir haben Echtzeit-Tracking-Daten aus der OpenXR-Laufzeit gelesen. Die Daten werden dann durch Abstraktionsschichten verarbeitet, in denen die Rohdaten in Positionen und Rotationen umgewandelt werden, die dann auf Hand-Meshes angewendet werden. Diese Hand-Meshes interagieren dann mit den integrierten Interaktionssystemen in Unity, die Hilfsprogramme für gängige Dinge wie das Berühren von etwas mit dem Finger bereitstellen. Dann, schließlich, unsere eigenen Gameplay-Schichten obendrauf.

Es geht alles um die mehrschichtige Abstraktion dieser Rohdaten. Viele XR-Spiele haben oft ähnliche Bedürfnisse, daher haben wir versucht, so viele stabile bestehende Lösungen wie möglich zu nutzen und sie ordentlich zusammenzubinden. Für Laser Matrix gibt es nicht viele nicht-standardisierte Aspekte beim Handtracking.

Auf welche technischen Herausforderungen ist das Team gestoßen?

Andreas: Es ist ein ziemlich standardmäßiges OpenXR-Setup, wenn es um die Szene und die verwendeten Komponenten geht. Wir mussten mit Problemen umgehen, die sich auf die Momente beziehen, in denen Hände das Tracking verlieren oder gewinnen und in diesem Frame an einem anderen Ort erscheinen würden. Irgendwann begannen die Spieler, das Handtracking zu verlieren, was dazu führte, dass sie Leben verloren.

Jonathan: Das Design rund um das Handtracking war eine der größeren Herausforderungen. Die verschiedenen Kontaktpunkte an der Hand verursachten einige Probleme. Es ist einfacher für normale, langsame UI-Interaktionen wie das Drücken eines Knopfes. In Laser Matrix hingegen bewegst du ständig deinen Körper und Kopf, was die Genauigkeit der kamerabasierten Handverfolgung verringern kann.

Andreas: Für die Benutzeroberfläche außerhalb des Spiels haben wir Tasten implementiert, die du mit deinen Fingern berühren musst, anstatt Raycasting zu verwenden. Nach unserer Erfahrung ist Raycasting mit Handverfolgung nicht präzise genug, um ein großartiges Spielerlebnis zu haben, daher hat dies geholfen.

Jonathan: Für "Flachbildschirm"-Spiele können Entwickler einschränken, wie Eingaben wie Maus, Tastatur und Controller verwendet werden. XR ist anders, weil ein Spiel deine physischen Hände niemals wirklich stoppen kann. Die Tasten im Laser Matrix-Menü sind ziemlich flach, und du kannst deine Hand ganz durch den Knopf stecken. Das ist eine Interaktion, für die du nicht unbedingt designst, und es ist unklar, was tatsächlich passieren sollte. Ist es ein gültiger Tastendruck? Im Allgemeinen gibt es einige interessante Implikationen, die folgen, wenn du traditionellere Benutzeroberflächenmuster auf XR überträgst.

Auf welche leistungsbezogenen Probleme stieß das Team?

Andreas: Unser primäres Leistungsproblem liegt auf der grafischen Seite. Von Anfang an geht es darum, das Gleichgewicht mit Transparenzüberzeichnung zu finden. Es ist eine der größten Herausforderungen im aktuellen Spieldesign, denn wenn du nur Umrisse für diese Kästen verwenden würdest, kannst du sehen, wo sie sind, wenn du nach oben oder unten schaust und sie mit etwas vergleichst. Aber wenn du geradeaus schaust und versuchst zu verstehen, wie weit du von einer Wand entfernt bist oder wie weit du deine Hand ausstrecken kannst, ohne sie zu berühren, ist das schwieriger.

Da wir wollen, dass der Benutzer das gesamte Labyrinth gleichzeitig sehen kann und strategische Standortentscheidungen treffen kann, benötigen wir eine Transparenzlösung oder eine Alternative, die beide GPU-intensiv sind.

Jonathan: Einige unserer Lösungen beeinflussten die endgültigen visuellen Darstellungen des Spiels. Zum Beispiel haben wir den äußeren gelben Rand des Spielbereichs geändert. Es hatte früher einen transparenten gelben Farbton, der die gesamte Wandfläche bedeckte, aber wir haben ihn nur auf die Kanten reduziert, mit einem Farbverlauf zu vollständig transparent. Da der Spielrand während des Spiels jederzeit sichtbar ist, wurde die Anzahl der Überzeichnungaufrufe konstant reduziert, was einer der Hauptfaktoren für unsere Frame-Zeit war.

Wir haben uns auch die roten Laserwürfel angesehen, die der Spieler beim Bewegen im Spiel zu vermeiden versucht. Sie haben ein quadratisches Gittermuster auf ihrer Oberfläche. Wir könnten denselben Ansatz wie beim gelben Randwürfel anwenden und versuchen, die Überzeichnung erneut zu reduzieren. Da nur die Kanten der Gitterzellen vollständig gerendert werden, haben wir die Zellen größer gemacht, was im Durchschnitt zu mehr vollständig transparenten Flächen führte.

Es gab auch einige Leistungsprobleme im Zusammenhang mit dem Laden. Jedes Mal, wenn das Level begann, trat ein großer Anstieg auf. Zunächst gingen wir einfach davon aus, dass es mit dem Laden von Levels im Allgemeinen zu tun hatte. Das Laden eines Laser-Matrix-Levels bedeutet, dass viele verschiedene Elemente erzeugt werden müssen. Der Übeltäter war jedoch speziell die Musik. Durch Profiling entdeckten wir, dass das System die Audioinhalte mit jedem Level neu geladen hat. Wir haben es so konfiguriert, dass die Musik stattdessen mit der Anwendung vorab geladen wird, was den Anstieg unauffällig machte.

Andreas: Einige unserer Leistungsprobleme entstanden, weil wir einen Prototyp in ein Produktionsspiel umgewandelt haben. Wir hätten das System neu schreiben sollen.

Welche Unity-Tools und -Funktionen waren während des Builds entscheidend?

Andreas: Der Vorteil von Unity ist, dass es uns ermöglicht, ein Asset und ein Stück Code zu erstellen und es von Anfang an auf mehreren Plattformen zum Laufen zu bringen.

VFX Graph war großartig, weil er unserem Produktverantwortlichen, der nicht künstlerisch veranlagt ist, ermöglichte, zu skizzieren, wie er sich die visuellen Effekte vorstellte. Von dort aus haben unser technischer Künstler und Entwickler es verfeinert.

Jonathan: Shader Graph war ein sehr wertvolles Werkzeug zur Erstellung des Spiels. Die meisten 3D-Elemente des Spiels sind reine Shader. Abgesehen von einigen Würfeln, Händen und Tasten gibt es in diesem Spiel sehr wenige tatsächliche 3D-Modelle.

Der XR Device Simulator wurde ebenfalls häufig verwendet. Wenn man in XR arbeitet, kann das Testen auf lange Sicht ziemlich körperlich und anstrengend sein. Zwischen all den Schritten – aufstehen, das Headset aufsetzen, sich bewegen und mehr – summieren sich die Stunden wirklich. Durch das Einrichten des Simulators und die Verwendung von Maus-Eingaben zur Simulation von Interaktionen haben wir viel Zeit und Frustration gespart.

Andreas: Da ich von Anfang an den XR Device Simulator zur Verfügung hatte, wollte ich neue Funktionen so entwickeln, dass ich sie leichter isoliert testen konnte. Es hat mich dazu gedrängt, von Anfang an modularere, testbare Systeme zu schreiben, was auch unsere Codequalität verbessert hat.

Jonathan: Der Unity Profiler war ebenfalls entscheidend, um uns zu helfen, herauszufinden, woher die Leistungsspitzen kamen. Zum Beispiel hat der Profiler bei dem von mir erwähnten Audio-Ladeproblem sowohl geholfen, die Spitze zu identifizieren als auch die Aufrufe, die zu diesem genauen Zeitpunkt ausgelöst wurden. Diese Art von Informationen gibt normalerweise einige klare Hinweise darauf, wo man beginnen sollte, wenn man eine Lösung implementiert.

Welche neuen Funktionen oder Updates in Unity 6 waren am vorteilhaftesten?

Jonathan: Wir bauen für ziemlich viele Ziele und in unterschiedlichen Kontexten. Beim plattformübergreifenden Arbeiten müssen die Builds unterschiedliche Konfigurationen für plattformspezifische Funktionen und Dienste haben. Die Möglichkeit, Build-Profile in Unity 6 zu haben, ermöglichte es uns, unsere Builds für diese verschiedenen Plattformen anzupassen. Dies manuell zu tun, wäre mühsam und fehleranfällig.

Welche wichtigen Leistungsbenchmarks hatten Sie?

Jonathan: Als wir die Leistungsprobleme markierten, was ein großes Problem in XR ist, insbesondere wegen der Reisekrankheit, haben wir die durchschnittlichen fps gemessen und nach Frame-Drops gesucht. Es gibt gut definierte Ziele dafür, was komfortabel ist und was nicht.

Durch das Anpassen der Schwellenwerte für die verschiedenen Würfel-Shader haben wir etwa 10 % an FPS gewonnen. Wir haben das Spiel in einer Testumgebung profiliert, in der wir die maximale Anzahl an Würfeln für das Spiel gezeichnet haben. Dies gab uns einen sehr festen und zuverlässigen Kontext für Tests.

Andreas: Für die Leistung liegen unsere harten Grenzen bei 72 FPS auf dem Meta Quest 2 und 90 FPS auf dem Meta Quest 3. Wir sind im Ziel für die durchschnittliche Bildrate, aber wir können Situationen erzeugen, in denen der Benutzer ein niedrigeres Ergebnis erhält. Dies sind sehr spezifische Fälle, in denen man im schlimmsten möglichen Zustand enden kann.

Jonathan: Auf Projekt- und Teamebene ist unsere Iterationszeit in den letzten Monaten viel effizienter geworden. Als Unternehmen haben wir unseren Qualitätssicherungsprozess weiterentwickelt und an unseren Automatisierungsstapel gebunden, und jetzt ist unser Feedback- und Fixzyklus ziemlich schnell. Wir können Probleme schnell genug angehen, sodass sich kein Aufgabenrückstand anhäuft oder außer Kontrolle gerät.

Gibt es etwas, das das Team während der Entwicklung anders gewünscht hätte?

Andreas: Wir hätten OpenXR etwas früher nutzen sollen. Früh im Projekt hatten wir geplant, die Raummarkierungsfunktion von Meta zu verwenden, um die Form und Größe des Spielbereichs zu definieren. Obwohl es funktionierte, gab es uns nicht die Gameplay-Funktionalität, die wir suchten, ohne auch Designherausforderungen zu eröffnen, für die wir noch keine großartigen Lösungen hatten. Das haben wir während der Diskussion über das Scannen des Raums erkannt. Wir hätten dieses System früher abschaffen sollen, weil wir zu lange versucht haben, es zu lösen. Zusätzlich hätte es Zeit gespart, wenn wir rückblickend erkannt hätten, dass das System, als der Prototyp-Code in Produktionscode überging, das Design nicht mehr erfüllte.

Um mehr über Projekte zu lesen, die mit Unity erstellt wurden, besuchen Sie die Ressourcenseite.