한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › Synchronisationsdesign

Feedback erst nach der Serverantwort (Request-Response) Request-response (no client-side feedback)

Ursachen-ID sy-request-response · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Nach einem Tastendruck gibt es weder Animation noch Ton, bis die Antwort des Servers eintrifft. Der Ping bestimmt direkt die Reaktionszeit.

Warum Skills, Bewegung und Aufheben erst nach Bestätigung durch den Server abgespielt → Folge Ab dem Tastendruck keinerlei Reaktion für die Dauer von Round Trip + Tick-Wartezeit → Auf dem Bildschirm Bei 150 ms Ping wirkt jede Aktion um 0,2 s träge

Symptome
Input-Lag
Faktoren
Latenz
Wer ist betroffen
Nur ich
Wann
Immer, Bei bestimmten Aktionen
Zuständigkeit
Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Client: Animation, Ton und Effekte sofort beim Tastendruck starten (clientseitiges Feedback), nur Ergebnisse (Schaden, Belohnungen) nach Bestätigung durch den Server anzeigen, Bewegung und Standardangriffe vorhersagen und sofort umsetzen, nach einer Positionskorrektur des Servers die noch unbestätigten Eingaben ab dieser Position erneut anwenden. Server: Bewegung aus den empfangenen Eingaben selbst berechnen und Korrekturwerte nur senden, wenn die Abweichung von der vom Client vorhergesagten Position einen Schwellenwert überschreitet.
Größenordnungen
Reaktionszeit ≈ Ping + halbes Tick-Intervall + ein Frame. Bei 20 Ticks pro Sekunde und 150 ms Ping etwa 190 ms.
Im Graphen
Von Anfang an dauerhaft hoch · Zeit von der Eingabe bis zum Start des Feedbacks, RTT (Ping)
Wo nachsehen
Im Client-Log eines Entwicklungs-Builds Zeitpunkt des Tastendrucks, Start der ersten Animation bzw. des ersten Tons und Ankunft der Serverantwort protokollieren und neben die RTT im Spiel legen. Mit der Netzwerkemulation der Engine (Unreal NetEmulation.PktLag) oder mit Linux tc netem auf dem Testserver Latenz hinzufügen und bei unterschiedlichem Ping messen
Spricht dafür
Feedback startet immer genau mit dem Eintreffen der Serverantwort, die Zeit von der Eingabe bis zum Feedback entspricht RTT + Tick-Wartezeit und wächst genau um die hinzugefügte Latenz
Spricht dagegen
Feedback startet sofort beim Tastendruck, nur Ergebnisse wie Schadenszahlen kommen später: korrektes Design. Auch bei niedrigem Ping mehr als ein Tick-Intervall Verzögerung: „Doppeltes Warten auf den Tick“ oder Frame-Probleme im Client
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Für Spiele, die keine schnelle Reaktion brauchen, etwa rundenbasierte Spiele, Kartenspiele oder Idle-Games, ist dieses Verfahren am einfachsten und sichersten. Problematisch wird es, wenn ein Spiel mit Echtzeitsteuerung auch Bewegung und Standardangriffe so umsetzt.

Quellen

  1. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
    Ein Client, der nur auf Serverergebnisse wartet, zeigt bei 500 ms Latenz jede Aktion erst 500 ms später. Abhilfe durch clientseitige Vorhersage und Serverabgleich
  2. Using Gameplay Abilities in Unreal Engine Epic Games
    Local Predicted führt sofort beim Tastendruck aus, die endgültige Entscheidung trifft der Server. Server Initiated hat keine Vorhersage, der ausführende Spieler sieht die Latenz
  3. Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
    Der Client sagt Bewegungen voraus und speichert sie. Der Server korrigiert nur, wenn die Abweichung den Grenzwert (MAXPOSITIONERRORSQUARED) überschreitet, danach wendet der Client die gespeicherten Bewegungen erneut an
  4. Using Network Emulation in Unreal Engine Epic Games
    Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar
  5. tc-netem(8) — Linux manual page iproute2
    Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden

Verwandte Ursachen

Gleiche Schicht: Synchronisationsdesign

Ursachen aus anderen Schichten mit demselben Symptom (Input-Lag)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen