Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

1

24.10.2007, 22:15

[Netzwerk] Server und Client Synchronisation

Mal ein Beitrag für unsere angedachte Netzwerkdiskussion:
Ich habe eine deterministische Physiksimulation auf Server- und Clientseite implementiert. Alle soundsoviel auf dem Server vergangenen Frames werden alle Objekte mit ihrer aktuellen Position, Orientierung, linearen und vertikalen Geschwindigkeit und Beschleunigung auf den Client übertragen. Jedesmal wenn auf Clientseite eine Aktion vom Spieler ausgeführt wird, wird diese an den Server gesendet.

Es treten verschiedene Probleme auf:
1. Obwohl ich mit festen Zeitschritten pro Frame arbeite (Zielzeit 20ms), laufen die beiden Simulationen natürlich nicht exakt gleichschnell ab. Dadurch kommt es auch in kurzen Zeiträumen zu Unterschieden im Fortschritt der Simulation, was auch bei häufigen Synchronisationen (mehr als 1 pro Sekunde) zu sichtbaren Lags führt (kleine, trotzdem sichtbare Sprünge einiger Objekte). Immerhin laufen bei einer Synchronisation pro Sekunde noch 50 Frames ab.

2. Die Änderungen auf Clientseite kommen natürlich nicht im selben Frame auf dem Server an, in dem sie beim Client abgesendet wurden, was sehr schnell zu großen (nicht akzeptablen) Unterschieden in der Simulation führt, was nach einer Synchronisation wieder zu unschönen Sprüngen führt.

3. Was mache ich bei großen Latenzzeiten oder Paketverlusten, wenn ein Spieler vorwärts läuft? Er geht 20 Frames lang nach vorne, beim Server kommen aber nur 10 Vorwärtsbewegungen an.

Client und Server laufen im Moment noch auf dem selben Rechner, und jetzt gibt es schon große Sprünge, wie soll das erst im echten Netzwerkbetrieb werden?
Ich habe über Clientseitige Vorhersage gelesen, da stand aber auch, dass das für größere Simulationen mit mehreren Objekten kaum anwendbar sein würde, zudem müsste ich dafür in manchen Frames die physikalische Simulation mehrfach ausführen, und ich habe schon bei einmaliger Berechnung Probleme mit hohem Aufwand.

Hat vielleicht jemand Erfahrung oder lesenswerte Tutorials, bevor ich groß drauflos probiere? Ich denke meist an Halflife2, da findet eine ähnlich komplexe Simulation statt wie bei mir, trotzdem sind Lags nicht unter einem Ping von 200 spürbar, wie wird das gemacht?

Black-Panther

Alter Hase

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

2

25.10.2007, 00:52

Also:

Das Schlüsselword heißt (wie du schon erwähnt hast). Clientprediction. Nur darst du keine exakten Vorhersagen machen, sondern lineare, oder maximal quadratische Approximationen!

btw: Unter 1Hz Synchronisationsfrequenz wirst du nicht wegkommen.

Hab grad mal ein paar nützliche Artikel, Codes und Tutorials für dich zusammengestellt und hochgeladen: Müsste einiges dabei sein, was dir hilft (vor allem der NetworkedPhysics Code!)

Ich könnte jetzt zwar auf einige Techniken zur Latenzkompensation eingehen, doch ich glaub, da muss man tiefer gehen, deshalb verweis ich schlicht auf diese Tutorialsammlung!

Latenzkompensations-Tutorials
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

3

25.10.2007, 20:12

Soweit schonmal vielen Dank, ich habe jetzt die ersten Artikel gelesen. Verstehe ich es richtig, dass dann auf Clientseite gar keine Physiksimulation mehr stattfindet, sondern die Objekte nur noch auf die aktualisierten Koordinaten vom Server "geschoben" werden?

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

4

25.10.2007, 21:55

Ich habe jetzt einige der Artikel überflogen, aber wirklich die Erleuchtung kam nicht :roll: . Aber gut, lasst uns doch mal ein wenig überlegen.

[Anmerkung]Was ich nur nicht verstehe ist, warum alle Welt unbedingt UDP nutzen will? Weil verdammt noch mal WoW nutzt auch TCP und das ist meiner Meinung nach durchaus ein Spiel was man als Massstab nehmen kann.[/Anmerkung]

Eine der Grundlegenden Ideen ist ja das, was schon Galilei axiomatisch festgestellt hat:
"Ein Körper verharrt im Zustand der Ruhe oder der gleichförmigen Translation, solange die Summe aller auf ihn einwirkenden Kräfte Null ist." (Quelle: http://de.wikipedia.org/wiki/Newtonsche_Axiome).

Sprich immer brav weitermachen, solange bis was anderes kommt. Das sollte eigentlich in keinsterweise ein Problem sein und eigentlich schon von Grund auf implementiert sein.

Eine zusätzliche Idee wäre, dass man nicht die aktuelle Position schickt, sondern den Anfangspunkt und einen Endpunkt + die Zeiten wann das Objekt vom Anfangspunkt gestartet ist und wann es den Endpunkt erreicht. Natürlich müsste man dafür die Uhren von Server und Clients abgleichen. Dies sollte relativ genau gehen, wenn man den Zeitpunkt eines Systems auf das andere überträgt und dabei den Ping berücksichtig. Natürlich muss man hoffen, dass die Laufzeit des Ping System1 -> System2 = System2 -> System1.

So weitere Ideen?
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

5

25.10.2007, 22:05

Da sehe ich aber gegenüber des Versendens der aktuellen Position keine Vorteile.. Vielleicht für geskriptete NPCs, aber für willkürliche Bewegungen eines Spielers bestimmt nicht geeignet. Da hat man dann auch das Problem, was passiert, wenn zwar der Weg eines NPCs klar ist, er aber auf halber Strecke von einem Spieler umgeboxt wird?

Soweit ich das jetzt verstanden habe simuliere ich mit Dead Reckoning die Bewegung der Objekte, sprich sowohl Client als auch Server berechnen aus letzter gesendeter Position und Geschwindigkeit die aktuelle Position, wenn berechnete und tatsächliche Position auf dem Server zu stark voneinander abweichen, sendet der Server ein neues Update. (hier sollte man womöglich eine obere Grenze für Aktualisierungen einbauen)

Was noch offen ist:
Soll auf dem Client trotzdem noch eine Physiksimulation durchgeführt werden? Eigentlich überflüssig so wie ich das sehe.
Wie werden die Steuerungen eines Spielers an den Server gesendet? Ich will nicht die absolute Position des Spielers übertragen, um Cheating zu unterbinden. Wenn ich aber nur die Änderungen übertrage kommt es wieder zu großen Unterschieden zwischen Client und Server, was auch mit Dead Reckoning Bewegungen bewirkt, die offensichtlich nicht durch den Spieler selbst ausgelöst wurden.
(also entweder der Spieler bewegt sich wie er will und muss irgendwann wieder an die richtige Stelle geschoben werden, oder er muss mit der Bewegung immer auf die Bestätigung des Servers warten [Update des Spielfigurobjektes], was ein verzögertes Steuern wäre. Beides nicht akzeptabel)

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

6

25.10.2007, 22:51

Nein überflüssig ist es nicht, weil dir sonst sowas wie in unserem spiel passiert:
Spieler setzt Ziel für Einheit->Server bearbeitet das und ändert die Bewegung->sendet Update an Client. So während nun aber der Client gerade die Nachricht erhalten hat und die Flotte auf den Anfangspunkt setzt ist vielleicht schon 0.2s vergangen. Ergo hinkt die Bewegungen der des Servers hinterher. Das merkt man vorallem dann deutlich, wenn man das Ziel ändert und die Flotte wegen dem Update auf die eigentliche Position(die aber schon wieder 0.2s alt ist) gesetzt. Hässliche Sprünge sind die folge. Aber eigentlich reicht es wenn man den Bewegungsvektor hat und eine Position mit der Angabe zu welchen Zeitpunkt das Objekt an dieser Position war.

Diese von dir erwähnte Technik ist soweit ich das verstanden habe nur eine von vielen Möglichkeiten, um festzustellen, wann ein Update nötig ist. Damit kann man ständige Updates durch "Zittern" des Objektes vermeiden.

Clientseitig würde ich nur dann machen, wenn es der Vorhersage dienlich ist. Also sprich wenn das Umfallen einer Tonne vorausgesagt werden kann, wenn der Mensch sich auf die Tonne zubewegt. Vom Client würde ich nur den "Wunsch des Clients" übertragen. Also z.b. die Pfeiltastendrücke zu einem Bewegungsvektor zusammengefasst. Außerdem sollte der Client auf den Input nur bei Animationen usw. direkt reagieren. Alles andere wie Bewegung usw. sollte indirekt, also über den Server laufen. Soweit mein Vorschlag.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

7

25.10.2007, 23:13

ok aber das ist ja ein ganz anderes genre als bei mir, ich arbeite mit einer ähnlichen situation wie ein egoshooter.. starcraft macht soweit ich weiß auch immer ein update und wartet bis alle spieler synchronisiert sind, und setzt erst dann das spiel fort, das führt dann bei lag zwar zu zeitlupe, aber dafür gibt es keine synchronisationsunterschiede

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

8

25.10.2007, 23:28

Das System, wie ich es mir vorstelle käme ohne diese Bremse aus, wobei das natürlich für gewisse Bereich schon wieder interessant wäre.

Aber du kannst nicht dafür sorgen, dass der Client seine eigene Bewegung am Server für seine Darstellung vorbeischleust und die der anderen Clients dann verspätet (im Vergleich) vom Server kommen. Dann sieht man sich doch immer an einem Ort an dem man für andere noch garnicht steht.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

9

25.10.2007, 23:40

ja genau, und jetzt ist meine frage wie man das cheatsicher hinbekommt, wie bei einem aktuellen egoshooter.. oder lassen die dann einfach anticheat-prüfprogramme nebenher laufen und übermitteln ansonsten nur die aktuelle position des clients an den server?

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

10

26.10.2007, 00:18

Naja...man könnte aus den Extrembedingungen auf den Algo schließen. Wenn man einen massiven Lag oder gar einen Disc hat, bewegt man sich immer weg von der Position beim einem Tastendruck, wird aber sofort wieder zurück gesetzt. Also vermute ich, dass der Client erstmal die neuen Positionen vermutet und dann die letzt vom Server bekanntgebene Position drüberhaut. Wenn der Client anständig war, werden die Positionen ziemlich genau identisch sein. Wenn nicht, macht man halt einen ziemlichen Sprung.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Werbeanzeige