Werden nur Befehle wie „geh dorthin“ ausgetauscht und beide Seiten berechnen den Pfad selbst, laufen Charaktere oder Monster schon bei kleinen Rechenunterschieden einen anderen Weg und werden dann an die richtige Position zurückgezogen.
Warum Bei Klickbewegung und Monsterverfolgung nur das Ziel senden, den Pfad berechnet der Client separat → Folge Durch Unterschiede in Geländedaten, Kollisionen mit anderen Charakteren oder Berechnungsreihenfolge Bewegung auf einem anderen Pfad als auf dem Server → Auf dem Bildschirm Monster läuft durch die Wand und wird plötzlich versetzt, der per Klick gesteuerte Charakter ändert rutschend die Richtung
Server: auch Zwischenpunkte des Pfads (Wegpunkte) mitsenden, Positionen regelmäßig abgleichen. Client: Abweichungen weich angleichen, dieselben Geländedaten wie der Server verwenden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl und Distanz der Positionskorrekturen pro Objekt
Wo nachsehen
Pro Objekt die Differenz zwischen der vom Server gesendeten und der vom Client berechneten Position protokollieren und die Koordinaten der Korrekturen auf einer Karte eintragen. Fasst man Pfadergebnisse oder Positionen beider Seiten als Prüfsumme zusammen und vergleicht sie regelmäßig, lässt sich der Zeitpunkt finden, ab dem sie auseinanderlaufen
Spricht dafür
Korrekturen häufen sich an bestimmten Geländestellen (Schwellen, enge Durchgänge, Hänge) oder an belebten Orten und wiederholen sich an derselben Stelle auch bei Spielern mit unauffälligen Netzwerkmetriken
Spricht dagegen
Korrekturen nur in Momenten mit Ausschlägen bei Paketverlust oder Jitter, unabhängig vom Ort: Leitungsproblem. Springt ein einzelnes Monster auf mehreren Bildschirmen gleichzeitig: prüfen, ob die Autorität über das Monster bei einem langsamen Client liegt
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Dieses Verfahren ist ein Grund, warum Spiele mit Klickbewegung und Tab-Targeting wenig empfindlich auf Ping reagieren. Dafür gibt es keine Garantie, dass beide Seiten zum selben Ergebnis kommen, und ein Mechanismus, der die Positionen gelegentlich abgleicht, ist unverzichtbar. Gleitkommaberechnungen können je nach CPU-Typ, Compiler und dessen Optimierungseinstellungen (einschließlich der Unterschiede zwischen Debug- und Release-Build) leicht abweichende Ergebnisse liefern. In Architekturen wie Lockstep und Rollback, die nur Eingaben austauschen und identische Rechenergebnisse auf beiden Seiten voraussetzen, können sich diese kleinen Unterschiede aufsummieren, bis der Spielzustand auf beiden Bildschirmen auseinanderläuft (Desync).
Quellen
Deterministic LockstepGaffer On Games Selbst wenn es auf derselben Maschine deterministisch ist, können Gleitkommaergebnisse bei anderem Compiler, OS oder CPU abweichen
State SynchronizationGaffer On Games Sendet man den Zustand zusammen mit den Eingaben, lassen sich beide Seiten auch ohne perfekten Determinismus abgleichen
Peeking into VALORANT's NetcodeRiot Games Bei Paketverlust oder wenn zwei Charaktere an dieselbe Stelle wollen, laufen die Simulationen von Server und Client auseinander und müssen korrigiert werden
Floating Point DeterminismGaffer On Games Derselbe Gleitkommacode kann je nach Compiler, CPU-Architektur sowie Debug- oder Release-Build unterschiedliche Ergebnisse liefern. Fall, in dem CPUs von AMD und Intel bei transzendenten Funktionen leicht unterschiedliche Werte lieferten
/fp (Specify floating-point behavior)Microsoft /fp:fast kann die Reihenfolge von Gleitkommaoperationen ändern oder Operationen zusammenfassen, sodass die Ergebnisse von anderen /fp-Einstellungen abweichen. Auch per FMA zusammengefasste Operationen können sich vom Ergebnis getrennter Multiplikation und Addition unterscheiden