Netzwerk für Anfänger

[Kojote]

Grüß Euch!

Da nun meine erste App langsam aus den Kinderschuhen raus ist, funktioniert und nur noch die Textur braucht und ein paar Kleinigkeiten. Will ich mich langsam dem nächsten Projekt zu wenden und schon mal ein paar Vorinformationen holen.

Geplant ist ein kleines Multiplayer Spiel, wie man es schon vermutet, ich bin Anfänger und wird mein erstes Multiplayer Spiel.

Hierzu würde ich gern eine kleine Gesprächsrunde beginnen und einmal eure Meinung hören, damit ich ungefähr abschätzen kann, wohin die Reise geht.

Geplant sind erst einmal zwei Terrains, die je in einer Szene sind und man durch Teleport erreichen kann.

Erste Frage wäre schon einmal, wie groß können Terrains sein, bzw. welchen Polycount vertragen sie überhaupt. Habe da leider keinerlei Anhaltswerte gefunden. Mein Gedanke war, in der Szene mehrere kleine Terrains zu erzeugen und nur die Bereiche zu laden, die derzeit für den Spieler relevant sind, andere wieder zu löschen, um Performance zu sparen. Frage Zwei wäre nun, was machen NPC`s in deisen Bereich, die der Spieler nicht sieht, werden hier trotzdem Bewegungen und der gleichen berechnet?

Somit wären wir bei Frage drei, leider habe ich bisher keine guten Tutorials gefunden, die wirklich Steo by Step mal anschaulich erklären, wie man was aufbaut. Wie eine Serververbindung programmiert wird und funktioniert, Benutzerkonten angelegt werden, irgendwann mal Chat, ect.

Könnt ihr mir da irgendwelche Tipps für Tutorials geben (bevorzugt auf Deutsch^^).

Des weiteren, ich habe gelesen, dass man einen Headless Client benötigt, wenn der Server selbst und nicht ein Spieler hosten soll.

Schon einmal vielen Dank für eure Mühen!

[Sascha]

Gut, dass du dich vorher informierst - Nachträglich auf Multiplayer aufrüsten macht wenig Spaß

Performance ist bei Multiplayer wie bei Singleplayer. Du musst dir Multiplayer so vorstellen, dass du ein Singleplayer-Spiel hast, das Zahlen verschickt und bekommt, und dann Sachen in der Singleplayer-Welt nach diesen Zahlen anpasst. Die Clients einigen sich auf Dinge (und sei es auch dadurch, dass der Server ein Machtwort spricht), wie z.B. welche Szene geladen werden soll. Dann haben beide Clients dieselbe Szene offen. Das allermeiste dieser Szene ändert sich nicht und deshalb wird auch nicht darüber geredet. Ob dein Terrain dann groß oder klein ist, macht für das Netzwerk keinen Unterschied, da es sowieso kein Thema ist.

Wenn die Frage auf Terrain-Performance im Allgemeinen bezogen war, dann ist die Antwort: Da geht ne Menge, versuch's mit Ausprobieren und Abändern. Unity-Terrains machen ja Terrain Tessellation und andere distanzbasierte Optimierungen. Bäume und Büsche, sogar Bodenflächen, die weit weg sind, werden runteroptimiert. Mach einfach mal in der Scene View oben links den Wirerframe Mode an und bewege die Kamera über das Terrain, da sieht man das gut.

Jetzt geht's aber schon zum Laden. In Unity ist es nicht vorgesehen, dass dein Multiplayer-Spiel in mehreren Szenen gleichzeitig läuft. Auf deinem Unity-Server läuft dieselbe Szene wie auf den Clients. Gerne auch dieseben Szenen. Aber nicht so, dass der Server mehrere Clients unterhält, die auf verschiedenen Szenen agieren. So etwas zu bauen, wird sehr krampfig. Also lieber so wie bei Borderlands: Sobald jemand die Szene wechseln will, gibt's da für alle Spieler einen Countdown. Wenn der vorbei ist, laden alle die neue Szene. Wenn jemand vorher noch etwas erledigen will, kann er den Countdown unterbrechen.

Will man jetzt wirklich ein Spiel machen, bei dem die Spieler in verschiedenen Szenen herumlaufen können (als Beispiel jedes MMORPG), dann sollte man einen Master Server anschaffen. Soweit ich weiß, ist der, den Unity selbst angekündigt hat, noch lange nicht fertig, aber theoretisch kann man den selber schreiben. Es handelt sich dabei um ein Programm, das Unity-Server-Instanzen managed. Wenn ein Spieler in eine neue Instanz geht, startet dieses Programm einen neuen Unity-Prozess auf dem Server und trägt ihn in einer Datenstruktur ein. Der Client connected dann direkt auf diesen neuen Prozess und der Master Server kümmert sich darum, dass die anderen Spieler in dieselbe Instanz kommen, wenn sie das sollen.

In deiner Zwei-Szenen-Welt wäre das noch ein wenig einfacher. Da startest du einfach für beide Szenen je einen Prozess und lässt sie laufen. Da müssten dann keine Prozesse dynamisch gestartet und beendet werden.

Zu den NPCs: Parktischerweise sind alle Multiplayer-Bibliotheken clever genug, sich nicht über Dinge zu unterhalten, die sich nicht ändern. Wenn deine Spieler alle zu weit weg sind, um Einfluss auf den NPC zu nehmen (oder umgekehrt), dann lass ihn einfach idlen und ändere keine seiner Werte mehr - nicht die Position, nicht die Animation und auch sonst nichts. Nur Werte, die sich ändern, werden übermittelt.

Zu Frage drei: Klar gibt's dafür keine Tutorials, weil alleine in deiner kurzen Frage schon drei völlig verschiedene, eigenständige Themen drinstecken. Benutzerkonten haben fast überhaupt nichts mit Multiplayer zu tun. Da kannst du ein Web-Backend mit Datenbank bauen und das über HTTP (also die WWW-Klasse oder UnityWebRequest) ansprechen. Beim tatsächlichen Mutliplayer musst du dich dann für eine Netzwerkbibliothek entscheiden. UNet, also die in Unity eingebaute, ist ziemlich gut, Photon ist auch sehr beliebt, was aber daher kommt, dass es das schon gab, als Unitys eigene Bibliothek noch echt schecht war.

Zu UNet kannst du hier anfangen (und dann nach rechts immer weiter durchklicken). Das ist ein Riesenhaufen Text und nicht gerade interaktiv, aber das ist halt auch kein Anfängerthema mehr und nur mit fundiertem Wissen kommt da kein Murks raus.

Was den Headless Client angeht: Du baust in/mit Unity ein Projekt, das am Ende Server und Client sein kann. Dein Code enthält dann sowas wie

if(isServer)
{
  DoServerThings();
}
else
{
  DoClientThings();
}

Wenn du dann einen Server starten willst, musst du entweder Kommandos beim Ausführen in deine Executable reinschmeißen oder hübsch unterschiedliche Builds rausschmeißen. Deine Server-Executable kannst du dann mit zusätzlichen Unity-Argumenten befeuern (oben ist für den Editor, weiter unten sind die Standalone Commands). Relevant hier wären -batchmode und -nographics.