Player loop de Unity: separar las actualizaciones de entrada, física y cámara

El límite que importa

Un botón de salto, un rigidbody y una cámara que sigue al jugador funcionan con ritmos distintos. Conviene tratar su interacción como una transferencia de intención primero hacia la simulación y después hacia la presentación. La pregunta de diseño útil es qué sistema es responsable de cada transición de estado, y no qué callback puede acceder a todos los objetos. Este artículo se basa en la documentación de Unity 6.0 y en Input System 1.14.

Conocer las tres fases

Update se ejecuta con los fotogramas renderizados; FixedUpdate puede ejecutarse cero, una o varias veces durante un mismo fotograma. Usa este último para aplicar fuerzas a un Rigidbody. LateUpdate se ejecuta después de Update, lo que la convierte en una fase adecuada para la cámara. Estos callbacks forman parte de un player loop más amplio, no son toda la secuencia de ejecución. [1][2]

Transferir la entrada de forma deliberada

Input System puede procesar eventos en actualizaciones dinámicas, en actualizaciones fijas o en actualizaciones manuales. Elige esa opción de forma explícita. [3] En un diseño con entrada dinámica, registra la intención de movimiento y encola una solicitud de salto cuando se dispare la acción. El responsable de la física lee esa intención almacenada; no debe asumir que cada paso de física recibe un flanco nuevo del botón. Define una regla de consumo para los comandos encolados y, si hace falta, un tiempo de expiración.

Ejemplo: un robot repartidor

Imagina un robot que mueve cajas y salta sobre cables. Almacena el último vector de dirección y un único salto pendiente. En el siguiente tick de física, comprueba si se permite saltar, aplica el impulso elegido una sola vez y consume la solicitud. Mantén la dirección disponible para los ticks posteriores hasta que cambie la entrada. En LateUpdate, coloca la cámara según la pose de presentación resultante del robot. Si un fotograma lento provoca tres ticks de física, este diseño aplica tres actualizaciones de movimiento, pero un solo salto. Si no se produce ningún tick de física, la solicitud pendiente sigue disponible. Es un diseño ilustrativo, no una implementación medida.

Límites y verificación

Especifica qué ocurre con la entrada pendiente durante la pausa, la reaparición y la pérdida de foco; de lo contrario, un salto obsoleto puede dispararse al reanudar el juego. Una cola booleana fusiona a propósito las pulsaciones repetidas, así que usa una cola de comandos acotada si cada pulsación importa. No deduzcas el orden entre instancias arbitrarias a partir de su jerarquía. [1] Prueba pulsaciones cortas y movimiento sostenido con varias tasas de fotogramas y luego inspecciona la línea de tiempo del profiler en busca de consumos duplicados de comandos. El suavizado de cámara y la interpolación del rigidbody requieren su propio ajuste; mover código a LateUpdate no garantiza por sí solo un movimiento fluido.

Fuentes

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