Nach einem einzelnen Stillstand rechnet das Spiel die aufgelaufenen Schritte im Block nach und gerät genau dadurch erneut in Rückstand.
Warum Spielsimulation läuft in festen Abständen und bleibt einmal stehen → Folge Aufgelaufene Schritte werden in einem einzigen Frame nachgerechnet → Auf dem Bildschirm Lange Frames folgen in Serie aufeinander und schlagen aus, oder die Obergrenze greift und die Welt läuft langsamer
Obergrenze für das Aufholen pro Frame, Restzeit per Interpolation ausgleichen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Frametime, Anzahl fester Zeitschritte pro Frame
Wo nachsehen
Im Profiler eines Development-Builds zusammen mit der Frametime prüfen, wie oft der feste Zeitschritt pro Frame lief (in Unity Anzahl der Marker der FixedUpdate-Phase wie FixedBehaviourUpdate)
Spricht dafür
Auf einen langen Frame folgen in Serie lange Frames mit mehreren Schritten. Ist die Obergrenze erreicht (in Unity Maximum Allowed Timestep), läuft die Spielzeit langsamer als die reale Zeit
Spricht dagegen
Bleibt es bei einem einzelnen langen Frame: „Frametime-Spikes“ oder „Garbage Collection auf dem Client“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Die Physikberechnung von Unity (FixedUpdate) ist das typische Beispiel für einen festen Zeitschritt (Standard 0,02 s, 50-mal pro Sekunde). Die Obergrenze fürs Aufholen ist Maximum Allowed Timestep in den Time-Einstellungen (maximale Zeit, die in einem Frame aufgeholt wird, Standard etwa 0,33 s). Dauert ein Frame länger, wird die überschüssige Zeit verworfen, und die Spielzeit läuft entsprechend hinter der realen Zeit her.
Handling variation in timeUnity Standardwert Maximum Allowed Timestep 1/3 s (0,3333333). Selbst wenn das Spiel 1 s hängt, vergehen nur 0,333 s Spielzeit. Die Obergrenze verhindert den Teufelskreis, in dem die Aufholschritte alles weiter verlangsamen
Profiler markers referenceUnity FixedBehaviourUpdate: Ausführungsabschnitt von MonoBehaviour.FixedUpdate, die Physik-Marker werden in der FixedUpdate-Phase aufgerufen