Wie synchronisiere ich Aktionen wie das Springen im Mehrspielermodus?

Ich bin ein Neuling in der Spieleentwicklung und habe über Multiplayer-Spiele recherchiert. Ich habe festgestellt, dass es immer eine gewisse Latenz gibt und die Spieler immer Updates von früheren Aktionen erhalten. Es gibt jedoch Techniken wie Dead Reckoning, um die Latenz zu bewältigen. Ich kann die Bewegung vorhersagen und Bewegungen reibungslos machen. Aber wie würde ich Aktionen wie Springen, Anhalten des Gehens usw. synchronisieren?

Angenommen, Client A bewegte sich, er befand sich um 10,2 Uhr mit einer Geschwindigkeit von 100 m / s auf 100 m und sendete diese Informationen. Client B würde diese Informationen etwas später erhalten, sei es 10.4. Bei Client B kann ich also Vorhersage verwenden und Client A auf 120 m platzieren. Was aber, wenn der Kunde um 10.3 Uhr einen Sprung auf 110 m machte? Ich kann das nicht vorhersagen und da ich Vorhersage verwendet habe, kann ich Client A keinen Sprung in die Vergangenheit zeigen.

Ich kann dieses Problem lösen, indem ich überhaupt keine Sprungaktion sende. Aber was ist, wenn mein Spiel einige Lücken hat, in denen Spieler fallen und sterben können? Wenn ich also keine Sprungaktionen synchronisiere, werden andere Spieler feststellen, dass ein Spieler lief, dann fällt er ins Leere und erscheint erneut auf dem Bildschirm, wodurch das visuelle Engagement zerstört wird.

Sprung ist nur ein Beispiel, es kann viele Szenarien geben, in denen Vorhersage nicht funktionieren kann. Also, wie gehe ich mit ihnen um? Ein solches Beispiel können Multiplayer Online-Kampfarenaspiele wie Awesomenauts sein.

— Suyash Mohan
quelle

Ich weiß nicht viel über Multiplayer, daher kann ich keine richtige Antwort geben. Aber nach dem, was ich aufgegriffen habe, wäre das ideale Setup, dass Ihre Clients mehr oder weniger dumm wären und nur Tastatur, Maus, Gamepad oder was auch immer Eingaben an den Server senden würden, und der Server macht diese ganze Bewegung und Weltaktualisierung und sendet Positionen und alle anderen relevanten Daten an die Kunden zurück, die dann das Ergebnis anzeigen. Dies eliminiert so gut wie Vorhersagen und ähnliche Dinge.

— Christian

@ Christian hey! danke für die Antwort. Ich kenne diesen Ansatz, aber dies kann das Gameplay ruckeln lassen, wenn die Latenz hoch ist. Außerdem verwende ich das BaaS-Echtzeitsystem von AppWarp, sodass meine gesamte Logik nur auf der Clientseite liegt.

— Suyash Mohan

Die Kombination Ihrer beiden Methoden ist der autorisierende Server. Clients und Server simulieren beide, Clients senden ihre Eingaben, Server sendet den autorisierenden Status zurück. Clients passen ihren Status an den autorisierenden Status an. Wenn also Zustände übereinstimmen, werden die Clients so ausgeführt, als würden sie lokal simuliert (keine Verzögerung).

— MichaelHouse

Ich habe kürzlich diese Tutorial-Serie gefunden, um gute Tipps zum Verwalten der Latenz zu geben. Es scheint, als wäre sie für Ihre Interessen relevant: Link

— Kris Welsh

Dead Reckoning ist in diesem Fall möglicherweise nicht die beste Idee. Sie sollten eine Entitätsinterpolation durchführen (die anderen Spieler in der Vergangenheit effektiv rendern, wodurch Sie immer echte, gültige Positionen erhalten). Ich habe hier viel ausführlicher darüber geschrieben . Ob es akzeptabel ist, Spieler in der Vergangenheit leicht zu sehen oder nicht, hängt von den Details ab, die Sie versuchen zu tun.

— ggambett
quelle

Ich habe diesen Ansatz verwendet, als ich mein erstes vernetztes Multiplayer-Spiel geschrieben habe. Tatsächlich habe ich @ ggambett's als Referenz verwendet. Es hat gut für mich funktioniert.

— NoobsArePeople2

Es gibt eine ziemlich detaillierte Beschreibung der Quell-Engine. Es scheint, dass ein Teil des relevanten Quellcodes auch als Teil des Quell-SDK verfügbar ist.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Es verwendet eine Reihe von Techniken, um die Netzwerklatenz in einem Server-Client-Modell zu bewältigen. Der Hauptpunkt scheint zu sein, dass der lokale Client Eingaben und andere Ereignisse lokal behandelt, als ob es keinen Server gäbe, und sich dann mit der Möglichkeit befasst, dass der Server sagt, der Client habe es später falsch gemacht.

— Wille
quelle