Verarbeitet der Client empfangene Pakete pro Frame nur bis zu einer festen Menge, schieben sich angestaute Pakete immer weiter in die nächsten Frames.
Warum An belebten Orten treffen Tausende Updates pro Sekunde ein → Folge Main-Thread stößt an die Verarbeitungsgrenze pro Frame und kommt mit dem Lesen nicht nach → Auf dem Bildschirm Bewegungen anderer Spieler werden immer später und gebündelt übernommen
Client: Empfang und Parsing in einen eigenen Thread verlegen, ältere Positions-Updates desselben Objekts zusammenfassen und nur das neueste anwenden. Server: an belebten Orten Updates entfernter Charaktere seltener senden und so die Datenmenge reduzieren.
Größenordnungen
Stauen sich unverarbeitete Pakete, reichen wenige Sekunden, um eine ganze Sekunde in Rückstand zu geraten.
Im Graphen
Steigt mit Spielerzahl und Last · Anzahl unverarbeiteter empfangener Pakete, Verzögerung zwischen Empfang und Anwendung
Wo nachsehen
Im Client protokollieren, wie viele Pakete pro Frame unverarbeitet liegen bleiben und wie lange es vom Eintreffen eines Pakets bis zur Anwendung im Spiel dauert, und beides der Spielerzahl in der Umgebung gegenüberstellen
Spricht dafür
An belebten Orten wachsen die Zahl liegengebliebener Pakete und die Anwendungsverzögerung stetig, Ping und Sendeintervall des Servers sind zur selben Zeit normal
Spricht dagegen
Keine Anwendungsverzögerung, aber die Pakete selbst kommen spät an: Netzwerkstrecke. Frametime steigt stark: „Renderlast durch große Spielermengen“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen
Actor Priority in Unreal EngineEpic Games Bei knapper Bandbreite priorisiert die Engine Actors nach Entfernung zum Betrachter und Zeit seit der letzten Replikation und repliziert nicht jeden Actor bei jedem Durchlauf
Replication Graph in Unreal EngineEpic Games Spiele mit vielen Spielern und Replikationsobjekten (etwa MMORPGs) müssen nach Position gruppieren und nur die nötigen Objekte senden, um einen CPU-Engpass auf dem Server zu vermeiden