Splitscreen- und GameShare-Netzwerk in Survival Kids

In diesem Sommer veröffentlichte Unity sein erstes Spiel, das in enger Zusammenarbeit mit dem Publisher-Partner KONAMI erstellt wurde. Survival Kids ist ein unterhaltsames Update für den Kinderspielklassiker, der als Day-One-Titel für Nintendo SwitchTM 2 veröffentlicht wurde.

Das Spiel war komplett auf Unity 6 aufgebaut, daher arbeitete das Entwicklungsteam mit neuer Software, um das Spiel auf einer neuen Plattform zu veröffentlichen – eine große Herausforderung. Darüber hinaus kann das Spiel in einer Vielzahl von Netzwerkkonfigurationen genutzt werden, sodass das kleine Unity Team, das an dem Projekt arbeitet, eine robuste Multiplayer Architektur entwickeln musste, die diese Optionen unterstützt.

Sehen Sie sich den ersten Teil der Multiplayer Networking Story für Survival Kids an, in dem wir erklären, wie die Grundlagen der Netzwerkarchitektur des Spiels zusammengekommen sind. In diesem Beitrag wird auf dieser Basis gezeigt, wie das Team den Split Screen und die Nintendo Switch 2-GameShare-Funktionen des Spiels entwickelt hat.

Nintendo Switch ist eine Marke von Nintendo.

Nachdem wir viele Probleme in der Netzwerkarchitektur des Spiels gelöst hatten, begannen wir darüber nachzudenken, wie wir Split Screen machen würden, was nicht sofort in Netcode for Entities enthalten ist. Das war eine andere Herausforderung. Beim Split Screen muss es mehr als einen Spieler geben, aber diese Spieler gehören zu einem Client.

Netcode for Entities geht davon aus, dass es einen Spieler pro Client gibt – wenn es ein separates Spiel gibt, an das eine separate Konsole angeschlossen ist, dann hat es einen Spieler. Wenn sich das ändert und es tatsächlich zwei oder drei Spieler gibt, gibt es keine Möglichkeit, die Eingabe für jeden einzelnen Spieler hochzuschicken. Sie müssen als Einheit hochgeschickt werden.

Wir haben einen virtuellen Eingabeplayer erstellt, den niemand sehen kann. Es ist komplett unsichtbar, sammelt aber alle Eingaben für alle lokalen Spieler, bis zu vier davon (obwohl wir letztendlich keinen Splitscreen mit vier Spielern durchgeführt haben). Es verwaltet alle eingehenden Eingaben und sendet dann alle Eingaben pro Frame an den Server.

Im Spiel verwalten die Spieler ihre Eingaben nicht selbst. Der imaginäre virtuelle Eingabespieler sagt ihnen, was die Eingabe für einen Frame ist. Bisher geht Netcode for Entities davon aus, dass ein Spieler für die Eingabe verantwortlich ist und seine Eingaben für alle seine Bewegungen verwendet, aber hier gibt es einen anderen Spieler, der keine Bewegung ausführt, aber für alles andere die Eingaben hält.

Split Screen war die größte Herausforderung aus Netzwerksicht. Um ein Problem mit mehreren Kameras zu vermeiden, haben wir zunächst einen zweiten Spieler, der herumläuft, während die Kamera beim ersten Spieler bleibt. Das kam schnell zusammen, aber dann hatten wir andere Probleme, wie zum Beispiel eine zweite Kamera einzurichten? Wie hält man eine Kamera links auf dem Bildschirm und die andere rechts auf dem Bildschirm? Wir mussten auch Probleme mit der Benutzeroberfläche lösen, da es ziemlich viel Benutzeroberfläche gibt, die nur ein Spieler sehen kann. Wenn sich beispielsweise ein Spieler vor einem Log befindet, sieht er eine kleine Eingabeaufforderungsschaltfläche, auf der steht: „Hey, drücke X, um dieses Log aufzunehmen“, aber natürlich soll das der andere Spieler nicht sehen.

Wir mussten herausfinden, wie wir die Benutzeroberfläche verstecken können, damit der andere Spieler sie nicht sieht, wenn er in der Nähe ist. Dafür haben wir Layer verwendet, aber unser Fix bezog sich mehr auf die Benutzeroberfläche als auf das Netzwerk. Wir hatten entschieden, dass wir das Spiel letztendlich für ein besseres Gameplay auf zwei Splitscreen-Spieler festlegen wollten – selbst wenn es auf einem großen Bildschirm läuft, können es nur zwei lokale Spieler sein. Wir konnten intern vier auf einem Split-Screen ausführen und das haben wir eine ganze Weile so beibehalten, weil es eine großartige Möglichkeit war, Stresstests durchzuführen, da jeder Spieler ein bisschen mehr Verarbeitung, ein bisschen mehr Rendering und einen anderen Spieler simuliert.

Eine der Funktionen während der Entwicklung für Nintendo Switch 2 ist GameShare. Sie senden effektiv einen Videofeed an eine andere Konsole – aus Netzwerkperspektive ist es nur ein geteilter Bildschirm – außer dass das System eine Kamera an eine andere Konsole sendet, anstatt sie auf einem Bildschirm zu rendern.

Unser geteilter Bildschirm für vier Spieler war die Grundlage für unsere Herangehensweise an den GameShare-Modus. Wir konnten so viele Spieler verbinden, wie wir wollten, solange die Leistung in Ordnung war, und wir konnten Videos auf diese Konsole streamen. Der Hauptgrund, warum wir den Splitscreen für vier Spieler nicht nutzen wollten, war eigentlich nur die Bildschirmgröße. Wenn Sie nicht über einen riesigen Fernseher verfügen, ist es wirklich schwer, die Windows zu sehen – aber wenn Sie Ihre eigene Konsole haben, kann das Video dorthin gestreamt werden.

Wir haben uns sehr bemüht, uns von unserem Splitscreen-Modus für zwei Spieler zu unterscheiden, damit wir einen zusätzlichen dritten Spieler in GameShare unterstützen können. Sie können einen Gastgeber und zwei Gäste haben und den Spielern trotzdem eine großartige Erfahrung und eine reibungslose Leistung bieten. Wir waren nicht bereit, unsere Standards zu senken, aber wir konnten trotzdem die Split-Screen-Architektur für GameShare nutzen.

Eine wirklich hilfreiche Funktion, die wir hinzugefügt haben, war ein Debug-Befehl. Wir haben ein Entwicklungsmenü, sodass Sie eine Taste drücken, das Menü aufrufen und dann Befehle eingeben können. Das war praktisch, weil wir dadurch jede Menge Debugging-Kram ausführen konnten – alles wurde aus dem finalen Spiel kompiliert, also konnte das natürlich niemand im finalen Spiel tun, das die Leute kaufen und spielen. Aber einer der Modi, die wir im Split Screen hatten, war, dass Sie den Hauptplayer duplizieren konnten – so haben Sie einen Split Screen, auf dem ein Controller beide Player ausführt. Es war eine großartige Möglichkeit, den Split Screen zu testen, ohne jede Menge Controller in der Nähe zu haben, und das machte es einfacher zu testen.

Das Split Screen Setup hat auch den normalen Netzwerkcode ausgeführt, den wir getan haben. Da die Spieler voneinander getrennt waren, sendete der Server Informationen, um zu zeigen, wie das Online-Spiel funktioniert. Sie können aber auch testen, ob Code im Multiplayer funktioniert hat, ohne einen Player mit einem anderen Client zu verbinden, indem Sie den Split Screen-Modus mit einem anderen Controller im Editor starten, um dort zu spielen. Sie müssen keinen neuen Build erstellen, da es möglich ist, den Code auf dem Split Screen als Proxy für ein normales Online-Spiel zu testen.

Es gab noch zwei weitere Unity Tools, die wir wirklich nützlich fanden, obwohl wir sie erst direkt am Ende des Projekts genutzt haben. Unity 6 enthält neue Multiplayer Play Mode Tools, die es uns ermöglichen, ohne separaten Player Build zu testen.

Beim Öffnen des Editors dauert es mehr als eine Stunde, bis ein ordentlicher Player-Build erstellt wurde, da es so viele Grafiken und andere Informationen gibt. Das Testen von Code mit einem Remote-Player bedeutet also, mindestens so lange zu warten. Es ist nicht besonders gut für Iterationen. Aber mit dem Multiplayer Play Mode können Sie effektiv ein anderes Fenster wie eine andere virtuelle Version des Editors hochdrehen und sich so verbinden.

Netcode for Entities verfügt auch über Play-Mode-Tools zur Simulation schlechter Netzwerkverbindungen. Sie können eine bestimmte Ping-Stufe spezifizieren und simulieren – beispielsweise einen 300-Millisekunden-Ping, eine wirklich schreckliche Runde, um zu simulieren, wie es wäre, mit einem Freund zu spielen, der sein Handy in einem Flughafen an seinen Laptop gekoppelt und so mit dem Spiel verbunden hat. Dann können Sie dies im Editor testen, um herauszufinden, wie spät oder instabil es ist. Manchmal funktioniert das bei einer Netzwerkverbindung, bei der Daten verloren gehen und Pakete gelöscht werden, nicht, und wir könnten das einfach simulieren.

Diese Tests fanden ständig statt. Für eine Weile galt die Regel, dass niemand mit ausgeschaltetem Simulator im Editor spielen durfte – jeder musste mit einer Art simuliertem Lag spielen, da keiner unserer Spieler mit einer perfekten Verbindung spielen würde. Auf diese Weise konnten wir uns nie dem Glauben hingeben, dass ein superschnelles Bürobreitband repräsentativ ist.

Schlussendlich hat sich all das ausgezahlt – wir konnten ein flüssiges, leistungsstarkes Spiel mit 60 FPS über verschiedene Netzwerke und Multiplayer-Setups hinweg liefern. Seit der Veröffentlichung des Spiels vor einigen Wochen haben wir gesehen, dass Spieler weiterhin über Lobby und Relay online interagieren und hoffentlich ein nahtloses und robustes Spielerlebnis genießen, unabhängig von ihren Heimnetzwerkbedingungen.

Sehen Sie sich die anderen Teile unserer Blog-Serie an, die sich eingehend mit <Survival Kids-Produktion befasst:
- "Grafik- und Rendering-Tipps von Survival Kids"
"Level-Layout und Gelände-Workflows in Survival Kids"
"Innerhalb der Infrastruktur des Multiplayer-Netzwerks für Survival Kids"

Weitere Informationen zu Projekten Made with Unity finden Sie auf der Seite Ressourcen.