Umgang mit Latenz in vernetzten Spielen

Question

Ich denke darüber nach, ein vernetztes Spiel zu machen.Ich bin ein wenig neu in diesem Bereich und bin bereits auf viele Probleme gestoßen, als ich versuchte, einen guten Plan für Koppelnavigation und Netzwerklatenz zusammenzustellen. Deshalb würde ich mich über gute Literatur zu diesem Thema freuen.Ich werde die Methoden beschreiben, die ich in Betracht gezogen habe.

Ursprünglich habe ich nur die Eingaben des Spielers an den Server gesendet, dort simuliert und Änderungen im Spielstatus an alle Spieler gesendet.Das machte das Betrügen schwierig, aber bei hoher Latenz war es etwas schwierig, die Dinge zu kontrollieren, da man die Ergebnisse der eigenen Aktionen nicht sofort sieht.

Dieser GamaSutra-Artikel verfügt über eine Lösung, die Bandbreite spart und die lokale Eingabe reibungslos erscheinen lässt, indem sie auch auf dem Client simuliert wird, aber sie scheint die Cheat-Proof-Funktion überflüssig zu machen.Außerdem bin ich mir nicht sicher, was ich tun soll, wenn Spieler anfangen, die Umgebung zu manipulieren, Steine ​​zu schieben und dergleichen.Diese zuvor neutralen Objekte würden vorübergehend zu Objekten, über die der Client PDUs senden muss, oder möglicherweise mehrere Spieler gleichzeitig.Wessen PDUs würden gewinnen?Ab wann würden die Objekte nicht mehr von jedem Spieler doppelt verfolgt werden (im Vergleich zur Koppelnavigation)?Der Himmel bewahre, dass zwei Spieler an einem Sumo-Kampf teilnehmen (z. B.fangen an, sich gegenseitig zu schubsen).

Dieses Gamedev.net-Bit zeigt die Gamasutra-Lösung als unzureichend an, beschreibt aber eine andere Methode, die mein Beispiel für das kollaborative Felsschieben nicht wirklich löst.Die meisten anderen Dinge, die ich gefunden habe, beziehen sich speziell auf Schützen.Ich würde gerne etwas sehen, das stärker auf Spiele ausgerichtet ist, die sich wie SNES Zelda spielen, aber mit etwas mehr Physik/Momentum.

• Notiz:Ich frage hier nicht nach physikalischer Simulation – andere Bibliotheken decken das ab.Nur Strategien, um Spiele trotz Netzwerklatenz reibungslos und reaktiv zu gestalten.

Answer 1

Schauen Sie sich an, wie Valve es in der Source Engine macht: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Wenn es sich um einen Ego-Shooter handelt, müssen Sie sich wahrscheinlich mit einigen der dort genannten Themen befassen, wie zum Beispiel:Vorhersage, Kompensation und Interpolation.

Answer 2

ich finde Dieser Blogbeitrag zur Netzwerkphysik von Glenn Fiedler, und vor allem die Antwort/Diskussion darunter, großartig.Es ist ziemlich langwierig, aber es lohnt sich.

Zusammenfassend

Der Server kann mit der Wiederholung der Simulation nicht Schritt halten, wenn in einer modernen Spielphysiksimulation (d. h.Fahrzeuge oder Starrkörperdynamik).Daher ordnet der Server die Latenz + Jitter (Zeit) aller Clients dem Server voraus, sodass alle eingehenden Pakete in JIT eingehen, bevor der Server sie benötigt.

Er gibt auch einen Überblick darüber, wie mit der von Ihnen gewünschten Eigentumsform umzugehen ist.Die Folien, die er auf der GDC gezeigt hat, sind großartig!

Über Betrug

Herr Fiedler selbst (und andere) geben an, dass dieser Algorithmus den Nachteil hat, dass er nicht sehr betrügerisch ist.Das ist nicht wahr.Dieser Algorithmus ist nicht weniger einfach oder schwieriger auszunutzen als die herkömmliche Client/Server-Vorhersage (siehe Artikel zur herkömmlichen Client/Server-Vorhersage in Antwort von @CD Sanchez).

Um es ganz klar zu sagen:Der Server ist nicht einfacher zu betrügen, nur weil er die physische Netzwerkpositionierung gerade rechtzeitig erhält (und nicht x Millisekunden zu spät wie bei der herkömmlichen Vorhersage).Die Clients sind davon überhaupt nicht betroffen, da sie alle die Positionsinformationen ihrer Gegner mit der exakt gleichen Latenzzeit erhalten wie bei der herkömmlichen Vorhersage.

Unabhängig davon, für welchen Algorithmus Sie sich entscheiden, möchten Sie möglicherweise einen Cheat-Schutz hinzufügen, wenn Sie einen großen Titel veröffentlichen.Wenn ja, schlage ich vor, eine Verschlüsselung hinzuzufügen Handlanger-Bots (zum Beispiel eine XOR-Stream-Verschlüsselung wobei der „Schlüsselstrom von einem Pseudozufallszahlengenerator generiert wird“) und einfache Plausibilitätsprüfungen gegen Cracks.Einige Entwickler implementieren auch Algorithmen, um zu überprüfen, ob die Binärdateien intakt sind (um das Risiko eines Crackings zu verringern) oder um sicherzustellen, dass der Benutzer keinen Debugger ausführt (um das Risiko der Entwicklung eines Crackings zu verringern), aber diese sind umstrittener.

Wenn Sie nur ein kleineres Indie-Spiel entwickeln, das möglicherweise nur von einigen wenigen tausend Spielern gespielt wird, machen Sie sich nicht die Mühe, Anti-Cheat-Algorithmen zu implementieren, bis 1) Sie sie benötigen;oder 2) die Benutzerbasis wächst.

Answer 3

Wir haben ein Multiplayer-Schlangenspiel implementiert, das auf einem obligatorischen Server und Remote-Spielern basiert, die Vorhersagen treffen.Alle 150 ms (in den meisten Fällen) sendet der Server eine Nachricht zurück, die alle konsolidierten Bewegungen jedes Remote-Spielers enthält.Wenn Remote-Client-Bewegungen zu spät beim Server eintreffen, verwirft er sie.Der Client wird den letzten Satz wiederholen.

Answer 4

Informieren Sie sich über die Themen zur Netzwerkbildung auf der Website des XNA Creator's Club.Es befasst sich mit Themen wie Netzwerkarchitektur (Peer-to-Peer oder Client/Server), Netzwerkvorhersage und einigen anderen Dingen (natürlich im Zusammenhang mit XNA).Dies kann Ihnen dabei helfen, die Antworten zu finden, nach denen Sie suchen.

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

Answer 5

Sie könnten versuchen, allen Ihren Clients eine Latenz aufzuerlegen, abhängig von der durchschnittlichen Latenz in der Region.Auf diese Weise kann der Client versuchen, die Latenzprobleme zu umgehen, und es wird sich für die meisten Spieler ähnlich anfühlen.

Ich schlage natürlich nicht vor, dass Sie jedem eine Verzögerung von 500 ms aufzwingen, aber Leute mit 50 ms können mit 150 (zusätzliche 100 ms hinzugefügt) zufrieden sein, damit das Gameplay flüssiger erscheint.

Kurzgesagt;Wenn Sie 3 Spieler haben:

• John:30ms
• Paul:150ms
• Amy:80 ms

Anstatt die Daten nach der Berechnung alle gleichzeitig an die Clients zurückzusenden, berücksichtigen Sie deren Latenz und beginnen beispielsweise mit dem Senden an Paul und Amy vor John.

Dieser Ansatz ist jedoch in Situationen mit extremer Latenz nicht praktikabel, in denen DFÜ-Verbindungen oder drahtlose Benutzer die Situation wirklich für alle durcheinander bringen könnten.Aber es ist eine Idee.