Multiplayer-Networking mit der Physik


12

Ich bin neugierig, wie die Multiplayer-Vernetzung mit der Physik in Rennspielen umgesetzt wird. Wir haben eine physische Welt mit mehreren sich schnell bewegenden Fahrzeugen, die von verschiedenen Menschen gesteuert werden. Angenommen, Fahrzeuge haben Waffen und können aufeinander schießen (Twisted Metal, Vigilante v8).

Ich bin besorgt über Treffer und Kollisionen. Autorisierter Server oder eine bessere Alternative?

Antworten:


5

Normalerweise wird ein Server eingesetzt, der den "Wahrheits" -Zustand speichert, der regelmäßig mit den Clients geteilt wird. Kollisionen treten auf Clients und Servern unabhängig voneinander auf, wobei die Zustände der Clients aus den vorherigen Zuständen geschätzt werden. Dabei wird ein Prozess verwendet, der dem entspricht, der normalerweise als Dead Reckoning bezeichnet wird . Wenn ein Serverstatus einen Client erreicht und Unterschiede bestehen, führt der Client einen Übergang von seinem aktuellen Status zu dem gerade empfangenen Status durch, meistens durch Interpolation.

Bei vielen Objekten können Kollisionen jedoch ein echtes Problem sein. Daher wird häufig versucht, die simulierte Zeit der Clients ein wenig hinter der simulierten Zeit des Servers zu halten, um verschiedene zusätzliche Flexibilitätsgrade zu ermöglichen. Dieser Artikel über Valves Source Engine-Netcode ist ziemlich erklärend. Wenn Sie sich immer noch nicht sicher sind, welche Netzwerk-Middleware / Bibliothek Sie verwenden sollen, sollten Sie sich mit RakNet und seiner Komponente "ReplicaManager3" befassen .


2

Sie können verschiedene Dinge tun.

  1. Sie können alle physischen Objekte auf dem Server zentralisieren und die Koordinaten mit den Objekten des Spielers auf allen Clients synchronisieren. Dies ist die einfachste und funktioniert ohne viele Mängel. Sie verbraucht jedoch viel Ressourcen und benötigt viel Bandbreite. Sie können die Bandbreitennutzung optimieren, indem Sie nur Werte an den Player anderer Player senden, die sich in einem bestimmten Umkreis befinden.

  2. Sie können wie von Neenster erwähnt vorgehen und den Server und die Clients die Physik simulieren lassen. Von Zeit zu Zeit korrigiert der Server die Clients. Dies bedeutet, dass alle Clients für jeden Spieler ihre eigene Physik berechnen und Sie Tastendruckereignisse über den Server synchronisieren, um die Flugbahn jedes Spielers auf jedem Client zu ermitteln. Alle 5 Sekunden sendet der Server seine Physiksimulation und alle Clients akzeptieren die Änderung. Dies kann zu geringfügigen Abweichungen führen, die in den meisten Fällen nicht bemerkt werden. Bei Netzwerkverzögerungen und Paketverlusten (unvermeidlich bei starkem UDP-Datenverkehr) werden Sie jedoch feststellen, dass Ihr Player und / oder andere Player auf dem Bildschirm herumhüpfen und ihre Position schnell und unruhig ändern (ist dies ein Problem) Wort?).

  3. Jeder Client kann seine eigene Physik berechnen und seine Koordinaten synchronisieren. Dies macht es schwierig, die Physik von Objekten zu simulieren, die von Clients gemeinsam genutzt werden. Es ist ein ziemlich komplexes Konzept, das implementiert werden muss, wenn Sie etwas pfiffiges tun möchten, da bestimmte Objekte nicht unbedingt zu einem Client gehören.

Der erste ist wahrscheinlich der einfachste und sollte Ihnen erlauben, ungefähr 4-5 Spieler mit wenig Verzögerung zu haben. Es würde erfordern, dass jedes Match einen eigenen Server hat. Wenn Sie LAN-Übereinstimmungen machen, ist dies zweifellos der richtige Weg.

Die zweite ist wahrscheinlich die praktischste, kann jedoch schwierig zu implementieren sein. Es ist auch ziemlich einfallsreich, Physiksimulationen auf dem Server auszuführen. Wenn Sie zentralisierte Server haben, müssen Sie wahrscheinlich den Lastausgleich auf mehrere Computer durchführen, möglicherweise 10 Übereinstimmungen mit einem Server zulassen und neue Übereinstimmungen auf den Server mit den geringsten Übereinstimmungen laden.

Der dritte ist definitiv der am wenigsten belastende auf dem Server und ist wahrscheinlich die beste Lösung, wenn Sie ein Peer-to-Peer-Netzwerkschema durchführen. Wie bereits erwähnt, kann es schwierig sein, andere Objekte als Ihr Player-Objekt zu synchronisieren, da diese Objekte auch von anderen Clients geändert werden können.

Ich kann dir nicht sagen, welches du verwenden sollst, weil ich nicht weiß, wie dein Spiel funktioniert. Ich kann Ihnen nur die Fakten geben. Wenn Sie weitere Fragen haben, können Sie diese gerne kommentieren.


Sie schlagen vor, dass es eine akzeptable Lösung ist, Kunden seine Physik machen zu lassen, aber Sie haben nichts mit Schummeln zu tun.
Cubuspl42

@ cubuspl42 Für die Mühe, beim Thema zu bleiben, habe ich Details weggelassen. Ich halte es für richtig, dass das OP die Lösung weiter ausloten kann, um mögliche Möglichkeiten zur Minderung von Betrug zu finden.
tsturzl

Eine Möglichkeit besteht darin, die Abweichung von dem, was jeder Kunde bereitstellt, auf einen Schwellenwert zu beschränken. Zum Beispiel sagen die meisten Kunden, dass sich ein bestimmtes Objekt an Position 5,8 oder 6,9 befindet, aber man meldet 12,19 als die Koordinate, die möglicherweise einen Schwellenwert unterschreitet, verglichen mit der Abweichung von den anderen Kunden. Dies ist nur eine Teillösung, aber die meisten Spiele bieten nur Teillösungen für das Betrügen an, weshalb dies immer noch der Fall ist. Diese Lösung bedeutet nicht, dass sie betrügen, sondern dass ihre Positionierung korrigiert werden muss und ihnen als Verzögerung erscheint.
tsturzl

Nun, ich bin etwas anderer Meinung. Einige Arten von Cheats können repariert werden, andere nicht. Zum Beispiel ist es meiner Meinung nach ein schlechtes Spieldesign, wenn man einen Speedhack für einen wettbewerbsfähigen Online-Shooter machen kann. Oder ein verrückter Hack, mit dem Sie mit einem Gottmodus und unendlicher Munition auf der Karte herumfliegen können (ich glaube, dass es irgendwann in Crysis 1 passiert ist). Diese können repariert werden. Gestalte dein Spiel einfach richtig. Sachen wie Wallhack sind nahezu unfixierbar (es würde enorme Ressourcen vom Server erfordern). Aimbot ist praktisch nicht fixierbar. Ihre Lösung Nr. 3 erhöht das Risiko dieser schlimmsten Art von Cheats.
Cubuspl42

@ cubuspl42 Ich denke, du vermisst die Idee, was ein Beispiel ist. Option 3 kann genau das Problem verhindern, über das Sie sprechen. Normalerweise verfügen Sie über einen TCP mit gemeinsamer Geschwindigkeit. Anschließend können Sie problemlos die Geschwindigkeit zwischen den Clients überprüfen und einen Konsens erzielen. Sie können auch mithilfe einfacher Berechnungen feststellen, ob die Koordinaten von UDP bei der angegebenen Geschwindigkeit plausibel sind, vorausgesetzt, Ihre Clients haben eine synchronisierte Uhr (kann bei Verbindung von HW-Uhr hergestellt werden).
Tsturzl
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.