Grundlagen des Online-Multiplayer-Spiels [geschlossen]

9

Ich arbeite derzeit an einem Online-Multiplayer-Spiel in Echtzeit. Ziel ist eine Client / Server-basierte Verbindung mit dem UDP-Protokoll. Bisher habe ich UDP für Spielerbewegungen und TCP für Ereignisse verwendet (ein Spieler schießt, ein Spieler verliert das Leben), weil ich sicher sein muss, dass solche Daten bei allen mit dem Server verbundenen Spielern ankommen. Ich weiß, dass UDP als "unzuverlässig" bezeichnet wird und einige Pakete verloren gehen können. Aber ich habe überall gelesen, niemals TCP und UDP zu mischen, da dies die Verbindung beeinträchtigen kann.

Die Hauptfrage ist, wie ich mein Netzwerk organisieren soll.

UDP ist verbindungslos. Wie soll ich speichern, wer wer ist? Soll ich IP-Adressen der Kunden in einer Liste speichern?

Soll ich TCP für wichtige Ereignisse oder UDP verwenden? Wie kann ich sicherstellen, dass keine Daten verloren gehen, wenn ich UDP verwenden muss?

Wenn ich sowohl TCP als auch UDP verwende, muss ich für jeden Spieler seine IP in einer Liste (für UDP) und den TcpClient speichern, der in einer anderen Liste (für UDP) verbunden ist. Wie könnte ich das ändern, um effektiver zu sein?

c#  networking  multiplayer  websocket 
— Lowip
quelle
@JoshPetrie diese Frage ist legitim "Die Hauptfrage ist, wie ich mein Netzwerk organisieren soll?". Es geht nicht darum, ob ich dies oder das benutze. Das OP verwendet eine und benötigt Ratschläge zum Hinzufügen einer anderen Technologie, die er bereits ausgewählt hat. Es ist weit gefasst, da die Antwort nicht darin besteht, welche Technologie verwendet werden soll, sondern wie die Software strukturiert werden kann, um ein Aufblähen der Rohre zu vermeiden, Verzögerungen zu verringern und die Zuverlässigkeit unabhängig von der zugrunde liegenden Technologie zu erhöhen.
— Coyote
Es ist auch zu breit. Die Frage sollte bearbeitet werden (zögern Sie nicht, sie ist ziemlich alt), um themenbezogener zu sein, und kann dann erneut geöffnet werden.

Antworten:

6

UDP hat weniger Overhead, aber auf Kosten des Verlusts von Paketen, ohne es zu wissen (ein Teil des Overheads mit TCP stellt sicher, dass verlorene Pakete erneut gesendet werden).

Das große Problem bei der Verwendung von UDP ist jedoch, dass es viele Sites gibt, die den gesamten UDP-Verkehr blockieren (außer DNS), da viele Administratoren der Meinung sind, dass dies eine gute Sicherheitspraxis ist.

Gehen Sie auch nicht davon aus, dass jeder Ihrer Spieler eine andere IP-Adresse hat - es gibt viele Situationen, in denen mehrere Benutzer dieselbe Internetverbindung nutzen, und wenn Schulkinder von Ihrem Spiel begeistert sind, können Sie darauf wetten, dass sie es wahrscheinlich sind Sie werden herausfinden, wie Sie es während des Unterrichts installieren und ausführen können, anstatt ihre Arbeit zu erledigen (und möchten Sie nicht lieber, dass sie diese kostbare Zeit für Ihr Spiel verbringen, anstatt für die eines anderen?).

Sobald Ihr TCP-Stream geöffnet ist, ist er immer noch ziemlich effizient. Der nächste Schritt besteht darin, die Datenmenge, die Sie senden / empfangen, zu minimieren. Hier kommt das Protokolldesign ins Spiel. Wenn Sie nur ein paar Bytes für jeden Befehl senden (z. B. "vorwärts gehen"), anstatt beispielsweise denselben Befehl in Hunderte von Bytes XML-Code zu verpacken, ist Ihr Gesamtverbrauch an Netzwerkbandbreite geringer UND weniger CPU-Zyklen erforderlich sein, um die Informationen zu verarbeiten (einige Bytes können leicht mit dem Zerlegen und Interpretieren und Syntaxprüfen eines großen Teils von XML verglichen werden).

Sie können sicherlich mehrere TCP-Streams öffnen und für verschiedene Zwecke verwenden, z. B. einen für Befehle, einen für Grafikübertragungen, einen für audio-basierten Chat usw. Auf diese Weise, wenn Sie eine große Grafik übertragen, die 5 bis 10 dauert Sekunden nach dem Herunterladen werden zumindest die Befehlsbewegungen der Spieler nicht verzögert, da sie sich in einem anderen Stream befinden (und Sie können ein Standard-Sprite anzeigen, bis das neue Sprite heruntergeladen ist, was immer mehr Spaß macht als zu warten).

— Randolf Richardson
quelle
1
Die ursprüngliche Frage erwähnte ein Client-Server-Modell, daher sind "Sites", die alle UDP blockieren, irrelevant. Das ist das Problem des Clients, und ich bezweifle, dass viele Clients tatsächlich alle UDP blockieren. "Die Verwendung von TCP ist der schlimmste Fehler, den Sie bei der Entwicklung eines vernetzten Spiels machen können! Um zu verstehen, warum, müssen Sie sehen, was TCP tatsächlich über IP tut, damit alles so einfach aussieht!" Siehe gafferongames.com/networking-for-game-programmers/udp-vs-tcp
— Indeed005
@ Indeed005: Dies hat Vor- und Nachteile - UDP bietet definitiv einen Leistungsvorteil, jedoch auf Kosten der Zuverlässigkeit (hier hat TCP den Vorteil). Was die UDP-Blockierung betrifft, haben Sie absolut Recht damit, dass es sich um das Problem des Clients handelt. In vielen Unternehmens- und Bildungsumgebungen habe ich jedoch festgestellt, dass UDP (mit Ausnahme von Port 53) von ahnungslosen Administratoren blockiert wird, die UDP für ein Sicherheitsproblem halten Daher kann die Option für den Client, auf TCP zurückzugreifen, zumindest bedeuten, dass der Spieler das Spiel erleben kann (insbesondere wenn die Netzwerkbandbreite schnell genug ist).
— Randolf Richardson
@ Indeed005: Auch die Verwendung einer Mischung aus UDP und TCP kann durchaus akzeptabel sein, da TCP für Datenübertragungen mit niedrigerer Priorität verwendet werden kann, während UDP für die Hochgeschwindigkeits-Aktionsseite verwendet werden kann. Interessant ist auch, dass mit IPv6 neue Optionen verfügbar sind (die mit IPv4 nicht verfügbar sind), die möglicherweise die Echtzeitanforderungen von Spielen erfüllen, obwohl sie nicht verbindungslos sind, aber ich denke, es wird eine Weile dauern, bis IPv6 verfügbar ist kann von Spielen genutzt werden, ohne sich auch auf IPv4 verlassen zu müssen (dies ist bedauerlich, daher kommen wir mit IPv4 so gut wir können aus).
— Randolf Richardson
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.