Unity-Player-Loop: Eingabe, Physik und Kamera-Updates trennen

Die entscheidende Grenze

Eine Sprungtaste, ein Rigidbody und eine mitlaufende Kamera arbeiten nach unterschiedlichen Zeitplänen. Ihr Zusammenspiel lässt sich als Übergabe einer Absicht zuerst in die Simulation und dann in die Darstellung verstehen. Die nützliche Entwurfsfrage lautet, welches System welchen Zustandsübergang verantwortet, und nicht, welcher Callback auf alle Objekte zugreifen kann. Dieser Artikel stützt sich auf die Dokumentation von Unity 6.0 und Input System 1.14.

Die drei Phasen kennen

Update läuft im Takt der gerenderten Frames; FixedUpdate kann innerhalb eines Frames keinmal, einmal oder mehrmals aufgerufen werden. Für Kräfte auf einen Rigidbody ist Letzteres zu verwenden. LateUpdate folgt auf Update und eignet sich dadurch als Phase für die Kamera. Diese Callbacks sind Teile eines grösseren Player Loops, nicht der vollständige Ablauf. [1][2]

Eingabe gezielt übergeben

Das Input System kann Events in dynamischen Updates, in Fixed Updates oder in manuellen Updates verarbeiten. Diese Einstellung ist ausdrücklich zu wählen. [3] Bei einem Design mit dynamischer Eingabe wird die Bewegungsabsicht festgehalten und eine Sprunganforderung eingereiht, sobald die zugehörige Action auslöst. Der Verantwortliche für die Physik liest diese gespeicherte Absicht; er sollte nicht davon ausgehen, dass jeder Physikschritt eine frische Tastenflanke erhält. Eingereihte Befehle brauchen eine Verbrauchsregel und bei Bedarf eine Ablaufzeit.

Beispiel: ein Lieferroboter

Als Beispiel dient ein Roboter, der Kisten bewegt und über Kabel hüpft. Gespeichert werden der zuletzt eingegebene Lenkvektor und ein einzelner ausstehender Hüpfer. Beim nächsten Physik-Tick wird geprüft, ob Hüpfen erlaubt ist; der gewählte Impuls wird genau einmal angewendet und die Anforderung verbraucht. Die Lenkung bleibt für spätere Ticks erhalten, bis sich die Eingabe ändert. In LateUpdate wird die Kamera anhand der resultierenden Darstellungspose des Roboters positioniert. Löst ein langsamer Frame drei Physik-Ticks aus, wendet dieses Design drei Bewegungsupdates, aber nur einen Hüpfer an. Findet kein Physik-Tick statt, bleibt die ausstehende Anforderung erhalten. Es handelt sich um ein illustratives Design, nicht um eine gemessene Implementierung.

Grenzen und Überprüfung

Festzulegen ist, was bei Pause, Respawn und Fokusverlust mit ausstehender Eingabe geschieht; andernfalls kann ein veralteter Hüpfer auslösen, sobald das Spiel weiterläuft. Eine boolesche Warteschlange fasst wiederholte Tastendrücke absichtlich zusammen; wenn jeder Tastendruck zählt, ist eine begrenzte Befehlswarteschlange zu verwenden. Aus der Hierarchie ist keine Reihenfolge zwischen beliebigen Instanzen abzuleiten. [1] Kurze Taps und gehaltene Bewegung sind bei mehreren Bildraten zu testen; anschliessend ist die Profiler-Timeline auf doppelt verbrauchte Befehle zu prüfen. Kameraglättung und Rigidbody-Interpolation müssen jeweils eigens abgestimmt werden; das Verschieben von Code nach LateUpdate garantiert für sich allein keine flüssige Bewegung.

Quellen

1. Event function execution order — Unity Technologies.
2. MonoBehaviour.FixedUpdate — Unity Technologies.
3. Input System 1.14: Input settings — Unity Technologies.