Das Thema XR gewinnt in den Anwendungsfällen Schulung und Training immer mehr an Bedeutung. Eine hohe Interaktivität, die Möglichkeit komplexe Umgebungen zu simulieren und diese ohne Aufwand in beliebige Zustände zu versetzen, fördert iteratives Lernen und kann dabei hohe Kosten einsparen.
Wenn potenzielle Kunden das erste Mal eine XR-Anwendung in Betracht ziehen, kommt schnell die Frage nach einer Multiplayer- bzw. Multiuser-Unterstützung auf. Mit einem Multiuser-Feature können auch Aufgaben simuliert werden, für die es mehr als eine Person braucht. Auch können Teilnehmende von Coaches leichter durch Prozesse geführt werden. Da die Interaktion über Chats, Video, Cloud-Dokumenten und Boards mittlerweile ganz alltäglich ist, scheint diese Frage auch mehr als berechtigt.
Welche Fragen müssen sich Entwickler*innen stellen? Welche Lösungen existieren? Die Antworten auf diese Fragen sollen als Starthilfe für die Entwicklung von Multiuser-Anwendungen dienen.
Der Hintergrund dieser Artikel-Reihe sind zwar Industrie-Anwendungsfälle wie XR-Anwendungen rund um das Thema Schulungs- Trainings-Software, doch Antworten auf die Fragen lassen sich vor allem in der Videospiel-Entwicklung finden, welche sich schon seit Jahrzehnten mit dem Thema Multiplayer auseinandersetzt. Aus diesem Grund werden in den Beiträgen Begriffe wie Multiplayer, Game-State, Gameplay oder auch Matchmaking verwendet, um die Vorgänge zu erklären. Das soll die Anwendungsfälle nicht auf Videospiele beschränken, sondern nur vermitteln, mit welcher Terminologie sich Lösungen im Internet finden lassen.
Multiplayer: Synchronisierung einer gemeinsamen Realität
Kurz gesagt, ist Multiplayer die Synchronisierung eines Game-States über ein Netzwerk mit mehreren Clients. Der Game-State enthält alle Informationen von zu synchronisierenden Objekten der Anwendung, wie z.B. Position, Rotation und Skalierung.
Bauen zwei Personen eine Verbindung zueinander auf und bewegt eine Person mithilfe eines Eingabegeräts ein Objekt in der virtuellen Welt und verändert damit seine Position, muss diese Änderung der Anwendung der zweiten Person mitgeteilt werden. Das bedeutet allerdings nicht, dass alles, was sich in der Anwendung verändert, synchronisiert werden muss.
Entwickler:innen sollten sich bewusst machen, ob ein Objekt in eines der folgenden Kategorien fällt:
- Kontinuierlich synchronisierte Objekte
- Eventbasiert synchronisierte Objekte
- Nicht synchronisierte Objekte
Es gilt, die Menge der Daten, welche synchronisiert werden müssen, so gering wie möglich zu halten. Hat ein Objekt, auch wenn es dynamisch ist, keinen Einfluss auf den Gameplay-Loop? Dann muss es auch nicht synchronisiert werden.
Der Screenshot zeigt den „iteratec Cable Playground“ ein VR-Multiplayer Prototyp, der den Anwendungszweck Schulung und Digitaler Zwilling erlebbar macht. Ziel der Benutzer:innen ist es mit interaktiven, beweglichen Kabeln Stromkreise zu schließen und so eine virtuelle Lampe zum Leuchten bringen. Gelingt dies, hat das Auswirkungen auf einen real existierenden Zwilling der Lampe, welche auch angeht.
Im Zuge der Entwicklung der Multiplayer-Funktion dieser Anwendung mussten die zu synchronisierenden Objekte identifiziert werden. Die Avatare der Benutzer:innen fallen in die Kategorie „kontinuierlich synchronisierte Objekte“. Alle Benutzer:innen sollten neben der Position und Rotation der Avatare alle weiteren Daten erhalten, die für das Gameplay notwendig sind. Dabei haben diese Informationen eine hohe Priorität und sollten mit jedem Frame aktualisiert werden, damit alle Benutzer:innen ihre Entscheidungen aufgrund von zuverlässigen Daten treffen können. Würden beispielsweise nur alle 500ms die Daten der Avatare aktualisiert werden, wäre eine Interaktion zwischen ihnen sehr langwierig.
In der Anwendung helfen Tutorial-Tafeln (B) den Benutzer:innen dabei, ihre Umgebung zu verstehen. Es war notwendig diese zu synchronisieren, im Gegensatz zu den Avataren jedoch nicht mehrmals pro Sekunde, weshalb die Synchronisierung dieses Objekts in die Kategorie „eventbasiert synchronisierte Objekte“ fällt. Bei einer Interaktion wird die Tafel aktualisiert und alle Clients benachrichtigt.
In der Abbildung sind einige Palmen (C) zu sehen. Diese sind animiert, bewegen sich im Wind und sorgen für eine tiefere Immersion mit der Umgebung. Allerdings ist für das Gameplay unerheblich, ob Palme #5 gerade etwas mehr nach links oder rechts geneigt ist. Solche Objekte fallen in die Kategorie „nicht synchronisierte Objekte“. Sie können sich von Client zu Client unterscheiden, ohne einen nennenswerten Einfluss zu haben.
Wie man sieht, ist es nicht notwendig, dass die gesamte Anwendung synchronisiert wird. Der Game-State ist nicht alles, was in einer Anwendung existiert, sondern nur das, was für das Gameplay notwendig ist.
Funktion folgt dem Design
Bei Simulationen und Spielen handelt es sich in der Regel um immersive, hoch interaktive Produkte, welche stetige Tests voraussetzen, um am Ende erfolgreich zu sein. Im Zuge der Entwicklung und der Tests entstehen neue Ideen, verändern sich Anforderungen, welche implementiert werden wollen, damit das bestmögliche Produkt entsteht. Es ist ein iterativer Prozess, der zum Ziel führt. Kurz gesagt: Das Gameplay verändert sich stetig und wird neu angepasst.
Die Implementierung eines Multiplayer-Features setzt aber voraus, dass man sich festgelegt hat. Die Funktionsweise der Anwendung entscheidet darüber hinaus, welche Infrastruktur-Lösung, Netzwerk-Topologie und Sicherheitsmaßnahmen notwendig sind. Spätere Umstiege sind zeitintensiv und damit unbedingt zu vermeiden.
Damit entsteht ein Konflikt zwischen der iterativen, meist agilen Natur von Projekten dieser Art und der Notwendigkeit sich früh auf bestimmte Rahmenbedingungen festzulegen, um einen soliden Multiplayer-Prototypen zu entwickeln. Hierzu gibt eine keine einfache Lösung, sondern nur Mittelwege. Vorgefertigte Tooling-Landschaften, welche den gesamten Use-Case abdecken und dank einer erprobten API die Möglichkeit bieten, zwischen den Lösungen zu wechseln, helfen enorm, aber können je nach Produkt kostenintensiv werden und werfen neue Fragen bezüglich des Datenschutzes und der Datensicherheit auf.
Entwickler:innen müssen sich somit zunächst damit abfinden, dass die Integration eines Multiplayers den Entwicklungsprozess verlangsamen und einschränken wird.
Autorität über den State
Neben der Frage, welche Objekte synchronisiert werden müssen, muss sich jeweils die Frage gestellt werden, wer die Autorität über das Objekt besitzt und bestimmt, was die „Single Source of Truth“ ist – entweder ein Client oder der Server.
Standardmäßig verfolgen Multiplayer-SDKs den Ansatz „Server-Authoritative“. Dies bedeutet, dass nur der Server Änderungen an zu synchronisierenden Daten vornehmen kann. Werden diese Daten vom Server aktualisiert, werden diese an die verbundenen Clients versendet. Wenn nun aber alle synchronisierten Objekte vom Server verwaltet würden, gäbe es keinerlei Interaktion durch die Clients. Deswegen wird in den allermeisten Fällen der Input der Benutzer:innen kontinuierlich synchronisiert und als Client-Authoritative behandelt. Die Input-Daten, wie etwa die Information darüber welche Tasten gedrückt sind, können also vom Client verändert werden. Der Server, welcher die Autorität über die Position des zu steuernden Avatars besitzt, verarbeitet den Input, verändert dementsprechend die Position und sendet diese neuen Daten an die Clients.
„Server-Authoritative“ hat neben dem Vorteil, dass es Cheating verhindert, aber auch einen gravierenden Nachteil: Die Kommunikation zwischen Server und Clients besitzt in jedem Fall eine gewisse Latenz. Ein Client mit einer Verbindungs-Latenz von 500ms muss 0,5 Sekunden warten, bis der eigene Avatar auf einen Tastendruck reagiert. Je nach Anwendungsfall und Gameplay kann das zu Frust führen.
Allgemein geben SDKs viele Werkzeuge zur Hand, um den State und die Autorität über den State zu managen. Beispielsweise kann das zuvor erwähnte Latenz-Problem mit Client-Side-Prediction oder Dead-Reckoning aufgelöst werden, was von einigen SDKs angeboten wird. Auf die verfügbare Tooling-Landschaft wird in einem späteren Abschnitt genauer eingegangen.
Missverständnisse
Bevor wir konkreter werden und auf Topologie und Software eingehen, welche für Multiplayer-Anwendungen notwendig sein können, ist es noch wichtig, Missverständnisse vorwegzunehmen. Bei den vielen Ressourcen, die sich zu dem Thema finden lassen, ist es nicht selten, dass sich ein falsches Verständnis festsetzt.
Simulated on the Server.
Häufig liest man diesen Ausdruck neben "Server sends back..." oder "Server manages data...". Es kann das falsche Bild entstehen, dass der Server eine Art Datenbank ist, welche über IDs die verschiedenen Datensätze verwaltet. Doch tatsächlich ist der Server nichts Weiteres als ein spezieller Build der gleichen Anwendung, die auch die Clients verwenden. Diese läuft ohne eine GUI, sozusagen headless, aber es werden gleichen Berechnungen vorgenommen, wie bei den Clients. Der große Unterschied ist, dass der Server standardmäßig über alle synchronisierten Objekte die Autorität besitzt und sozusagen die "Single Source of Truth" abbildet.
Server Builds.
Wie eben erwähnt, läuft auf einem Server ein besonderer Build der Anwendung. Dabei ist es wichtig zu verstehen, dass es sich dabei um einen Build desselben Source-Codes handelt, welchen auch die Clients verwenden. Eine Trennung von Frontend und Backend, wie man es häufig aus der klassischen Software-Entwicklung kennt, gibt es nicht. Server und Client Code existieren parallel, oftmals teilen sie sich dieselben Klassen. Was zunächst für Verwirrung sorgen kann, ist eine Notwendigkeit, da sonst bestimmte Werkzeuge zur Synchronisierung der Game-States, wie z.B. Remote-Procedure-Calls, auf die wir später eingehen werden, nicht möglich wären.
Ein erster Überblick
In diesem ersten Teil der Multiuser-Reihe haben wir uns mit dem grundsätzlichen Verständnis einer solchen Anwendung beschäftigt und wie das Multiuser-Feature von bestehenden Features beeinflusst wird. Auch ging es darum, welche Herausforderungen gezwungenermaßen mit Multiplayer-Anwendungen einhergehen. Im nächsten Beitrag gehen wir weiter ins Detail und werden uns der Infrastruktur- und Software-Landschaft rund um das Thema Multiuser genauer ansehen.
Philip Ewert - ist Fullstack-Webentwickler bei iteratec und fördert zudem die Themen 3D-Entwicklung und Grafikprogrammierung im Web.
Haben Sie Fragen oder benötigen Unterstützung?
Mehr zu den Möglichkeiten von XR-Anwendungen für Ihr Unternehmen finden Sie auf unserer Webseite. Sprechen Sie uns auch gerne an.