PlanetSwitch Planet3DS PlanetVita PSP.de PlanetiPhone Classics Forum

PGN-ID:[?] (Nicht eingeloggt)
Login
Registrieren
PlanetDS PlanetGameboy N-Page.de

-

Sonstiges: Entwicklertagebuch - Der Weg zum eigenen 3DS/Switch-Spiel

Michael Grönert, am 26.12.2016, Seite 12 von 18

Artikel mögen: Weitersagen:



Teil 12: Netzwerk-Spiele
Heute wagen wir uns an ein gewaltiges Thema: Multiplayer via Netzwerkverbindung. Dies betrifft Spiele lokal über WiFi mit dem 3DS, im LAN (am PC) und über das Internet (am PC). Dank meiner Erfahrung in der Spieleentwicklung ist mir bewusst, dass man mit der Implementierung eines Multiplayer-Modus niemals früh genug beginnen kann, da sehr viele Vorgänge darauf vorbereitet sein müssen. Ich möchte an dieser Stelle auch nicht festlegen, dass das Spiel bei Release wirklich einen Multiplayer-Modus haben oder wie umfangreich dieser sein wird, da ich schon viele Entwickler daran scheitern sehen habe, was Verschiebungen des Erscheinungsdatums nach sich ziehen kann oder gar ein kurzfristiges Streichen oder Einschränken des Modus. Durch meine folgenden Erläuterungen wird es vielleicht auch etwas verständlicher, woran dies liegt.

Nichtsdestotrotz brauche ich zunächst einen Plan, in welche Richtung der Multiplayer gehen soll, den es später zu erproben gilt. Und da möchte ich zunächst keine Aufwände und Risiken scheuen und das Beste versuchen, das ich mir vorstellen kann. Optimal wäre ein Coop-Modus über das komplette Spiel mit allen denkbaren Freiheiten. Ein Spieler soll jederzeit das Spiel und die damit verbundene Welt eines anderen betreten können und dort nur wenigen Einschränkungen unterliegen - etwa vergleichbar mit Minecraft. Wenn ein Spieler gerade mit einem Minispiel beschäftigt ist, soll ein anderer dazu kommen können, um zuschauen und sogar mitzuspielen. Außerdem sollten Spieler miteinander kommunizieren können.

Unity vs. 3DS
Unsere Entwicklungsumgebung Unity bietet auch zum Thema Netzwerk-Multiplayer eine passende Lösung an. Es werden Tutorials und Muster-Projekte angeboten, anhand derer man diese Lösung besser kennen lernen kann. Es handelt sich um ein recht umfangreiches Paket zum Erstellen und Verwalten von Netzwerk-Spielen mit nützlichen Werkzeugen, die man häufig gebrauchen kann. Dazu gehört beispielsweise eine Lobby, in der sich die Spieler vor oder eventuell sogar während des Spiels treffen können. Auf dieser Ebene muss man sich weniger mit der darunter liegenden Technik auseinandersetzen, wie die Verwendung der Protokolle TCP und UDP. Leider lässt sich genanntes System nicht auf dem 3DS verwenden, da hier gewisse Richtlinien eingehalten werden müssen. Unsere Lösung erlaubt Direktverbindungen zu anderen Teilnehmern aufzubauen oder einen kostenpflichtigen Service von Unity in Anspruch zu nehmen, welcher die Spiele-Findung verwaltet. Beim 3DS hingegen sind wir dazu verpflichtet, zunächst eine Verbindung zu Nintendos Servern herzustellen, welche vor einem Spiel Sicherheitsprüfungen durchführen und somit unserer Lösung einen Strich durch die Rechnung machen. Tatsächlich lernen wir aus Beispielcode für Verbindungen zwischen 3DS-Systemen, dass alles auf deutlich niedrigerer Ebene behandelt werden muss. Hier müssen wir uns selbst um das Erstellen und Versenden von Datenpaketen kümmern.

Ich werde diese Problematik an dieser Stelle nicht genauer erläutern. Aber ich habe für mich hiermit festgelegt, dass ich eine 3DS-Konnektivität zwar parallel zur höheren Unity-Variante mit implementieren werde, aber diese zunächst nur für lokale WiFi-Spiele umsetzen werde, anstatt über Internet. Einigen von euch mag es schon oft komisch vorgekommen sein, dass relativ viele 3DS-Spiele zwar einen lokalen Multiplayer anbieten, aber auf Onlinespiele verzichten. Wie ihr euch jetzt denken könnt, dürfte das deutlich mehr Gründe haben, als „nur“ weitere Netzwerk-Infrastruktur zahlen zu müssen oder die Spiele auf höhere Latenzen auslegen zu müssen.

Ein Spiel starten
Betrachten wir zunächst die Nicht-3DS-Variante. In diesem Fall nutzen wir die Lobby, die uns Unity zur Verfügung stellt, damit sich Spieler dort treffen und vorbereiten können. Der Spieler, der das Spiel hostet, also erstellt und anderen zur Verfügung stellt, landet als erstes in der Lobby. Andere Spieler, die sich via IP-Adresse mit ihm verbinden, landen ebenfalls in der Lobby. Bis der Host das Spiel startet, können alle Teilnehmer einen Namen und eine Farbe festlegen. Fertige Spieler können sich als „bereit“ markieren, wenn sie so weit sind. Dann kann der Host das Spiel starten. Ich habe das alles ein wenig abgewandelt, so dass Spieler nun auch noch beitreten können, nachdem das Spiel bereits gestartet wurde.


Multiplayer-Lobby auf dem PC

Da es heutzutage nicht mehr üblich ist, IP-Adressen manuell einzugeben, möchte man dem Benutzer eine automatisierte Spielefindung anbieten. Damit meine ich, dass man seinem Spiel bzw. Lobby-Raum einen Namen gibt, und der Benutzer dann aus einer Liste an Spielen auswählt, oder nach diesem Namen suchen kann. Um dies zu verwirklichen ist aber ein weiterer Rechner nötig, ein Server der irgendwo steht und diese Liste verwaltet. Mit anderen Worten: weiterer Aufwand und weitere Kosten. Wie bereits erwähnt, bietet Unity hierfür einen kostenpflichtigen Service an. Dieser nimmt einem dann die Arbeit und Kosten für ein eigenes Serversystem ab. Auf dem 3DS beschränken wir uns wie gesagt zunächst auf lokalen Multiplayer via WiFi. Hier kann man es theoretisch etwa genauso umsetzen, denn der große Unterschied spielt sich erst auf niedrigerer Ebene ab. Aktuell existieren hierfür allerdings nur sehr minimalistische GUI-Buttons ohne tolles Design oder Komfort, daher ist es noch nicht der Rede wert.

Die Kommunikation zwischen den Geräten
Nachdem sich Teilnehmer gegenseitig gefunden haben, müssen sie stetig miteinander kommunizieren. Dabei agiert der Host als Vermittler zwischen allen anderen Spielern, welche untereinander keinen direkten Kontakt haben. Dies beginnt bereits in der Lobby - wenn ein dritter Spieler beitritt, berichtet der Host diesem über den zweiten Spieler und den zweiten über den Neuankömmling. Sobald das Spiel begonnen und jeder Teilnehmer seinen eigenen Charakter hat, den er steuern kann, wird die Kommunikation auf die Zustände dieser Charaktere ausgedehnt. Jeder Spieler muss also dem Host seine aktuelle Position schicken und dieser verteilt diese an die anderen Teilnehmer, sofern vorhanden. Dazu kommt, dass man auch sehen möchte, in welche Richtung ein Spieler blickt und ob er gerade läuft oder steht. Besonders wichtig ist, dass man bedenken muss, dass das Versenden dieser Informationen eine gewisse Zeit benötigt, im Speziellen weil nicht alle Spieler direkt miteinander kommunizieren. Diese Versanddauer (Latenz = Verzögerungszeit, siehe auch Ping) hängt von sehr vielen Faktoren ab und kann stark variieren. Dies und die zeitliche Dichte der Informationen haben zur Folge, dass Spieler scheinbar von einem Punkt zum nächsten springen. Deshalb müssen die Spieler-Bewegungen interpoliert werden. Das bedeutet, dass jeder Rechner versuchen sollte, die Bewegung aller nicht lokalen Teilnehmer vorherzusagen, um so ein Ruckeln zu vermeiden. In unserem Fall geht dies sogar relativ einfach, da es bereits genügt, Bewegungsrichtung und -geschwindigkeit mit zu übermitteln. Die Abweichungen sind dann so minimal, dass ein Spieler dies gar nicht wahrnehmen kann, sofern der Ping nicht zu hoch ist. Aus den Bewegungsinformationen können wir dann auch die Blickrichtung und die Laufanimation ableiten.

Mit der Unity-Variante lässt sich dies sehr einfach verwirklichen. Objekte, für welche diese Funktionalität umgesetzt werden soll - wie die Charaktere der Spieler - benötigen lediglich entsprechende vorgefertigte Komponenten. Unser Spieler bekommt also eine „Network Identity“, welche aussagt, dass es sich um ein Objekt handelt, welches mit anderen Netzwerkteilnehmern synchronisiert werden muss. Diese Identität wird einer Netzwerkverbindung zugeordnet, sodass entsprechende Spieler sie kontrollieren können. Dazu kommt noch ein „Network Transform“-Skript, welches Transformationen dieses Objektes mit synchronisiert. In diesem Skript lässt sich dann einstellen, wie häufig und wie genau welche Informationen abgeglichen werden sollen. In unserem Fall also die Bewegung, bestehend aus Richtung und Geschwindigkeit, sowie die Rotation des Objektes.

Für die 3DS-Variante müssen wir dies manuell verwalten. Dazu lesen wir in bestimmten Zeitabschnitten genannte Werte aus und codieren sie in Bytes. Das bedeutet, dass wir mit mathematischen Funktionen die Werte unserer Bewegungen und Rotationen auf ganze Zahlen größer Null abbilden, welche ein gewisses Maximum nicht übersteigen. Dabei geht natürlich etwas an Genauigkeit verloren, da wir nicht beliebig komplexe Zahlen abbilden können. Diese Bytes schicken wir dann in Paketen über die entsprechenden Verbindungen weiter. Auf der anderen Seite werden diese wieder decodiert und zurück auf die gewünschten Zahlenbereiche abgebildet.


Ein alter 3DS XL und ein New 3DS XL sind zum Spielen miteinander verbunden.

Aussicht
Aus diesem Artikel lässt sich der benötigte Aufwand und die Komplexität, zu lösender Probleme und Schwierigkeiten nicht annähernd erahnen. Aber genau so soll es ja auch im Rahmen dieses Entwicklertagebuchs bleiben. Für diese Aufgaben habe ich jedenfalls einige Zeit benötigt und ich kann mich nicht zu lange damit aufhalten, ohne am eigentlichen Inhalt weiter zu arbeiten. Aktuell ist bereits etwas mehr möglich als bisher beschrieben. Auf obigem Screenshot lässt sich bereits erkennen - es gibt ein Chat-System, über welches man Texte und sogar Smileys austauschen kann. Ein versandter Smiley erscheint auch kurzzeitig in etwas größer über dem Kopf des Senders. Er soll die aktuelle Emotion des Benutzers widerspiegeln. Ein weiteres Feature ist, dass man sehen kann, in welchem Minispiel ein anderer Spieler sich gerade befindet. Ist jemand mit einem Spiel beschäftigt, sehen alle anderen das Icon des Spiels über seinem Kopf. Währenddessen können andere, wenn sie neben diesem Spieler stehen, mit der Aktionstaste genauere Infos erfragen. An dieser Stelle soll es dann möglich sein, diesem Minispiel beizutreten, falls dieses solch eine Funktion anbietet. Damit dies möglich ist, muss aber noch Einiges getan werden. Unser erstes Minispiel „Gong“ bietet sich natürlich prima dafür an, dass bis zu drei weitere Spieler einsteigen. Dazu benötigen Minispiele aber ebenfalls eine Art von kleiner Lobby und etliche Anpassungen. Bei „Gong“ müssen die Pads den Teilnehmern zugeordnet werden. Im Multiplayer müssen auch das Erfahrungssystem und die Achievements anders gehandhabt werden. Man kann nicht einfach leichtfertig Erfahrung für jemanden verteilen, der gegen einen anderen Menschen spielt, denn so könnte man leicht schummeln.

Das soll es zunächst zum Netzwerk-Multiplayer gewesen sein. Im nächsten Tagebucheintrag kümmern wir uns um etwas künstliche Gesellschaft, doch mehr möchte ich noch nicht verraten. Bis zum nächsten Mal!

Ihr möchtet die Auszüge aus dem Leben eines Entwicklers lieber in englischer Sprache lesen? Unter diesem Link findet ihr die englische Version dieses Tagebucheintrags!


Gehe zu Seite:
Vorherige Seite | Nächste Seite

ANZEIGE:
Kommentare verstecken

- Kommentare


- Noch keine Kommentare vorhanden -

Um Kommentare zu schreiben, bitte oben einloggen oder jetzt Registrieren!