Predecir tu propio movimiento

Actúas según tu propia entrada antes de que el servidor responda, y donde los dos no coinciden, tu cliente se corrige solo. Un error aquí cuesta una pequeña corrección visual y nada más; por eso, de los tres mecanismos de predicción, este es el único con el que puedes ser agresivo sin riesgo.

La predicción vuelve a aplicar las reglas declaradas, no es una segunda copia de ellas

Tu cliente no ejecuta una implementación paralela de tu movimiento. Ejecuta el mismo modelo declarado que ejecuta la plataforma — el modelo pertenece a Locomotion, y la predicción solo lo aplica antes. Por eso los dos lados coinciden la mayor parte del tiempo: un solo conjunto de reglas, aplicado dos veces.

Así que no hay ninguna operación “predecir” que llamar, ni tampoco una operación “corregir”. La predicción ocurre porque el aspecto se declaró predecible.

Lo que se predice se declara por aspecto

La predictibilidad es una declaración en el aspecto de la entidad, no un interruptor global:

Un aspecto que el cliente puede calcular — la posición según tu propia entrada — se puede predecir.
Un aspecto que la autoridad cambia con reglas que el cliente no tiene no debe predecirse. Si el cliente no puede deducirlo, adivinarlo produce un rollback que el jugador percibe como si el juego le mintiera.

El protocolo de corrección y los dos números que lo definen

El estado autoritativo llega con el número de la última entrada que aplicó, así que tu cliente sabe exactamente qué parte de su propio búfer sigue sin confirmar. A partir de ahí:

Acepta el estado autoritativo.
Vuelve a aplicar las entradas del búfer posteriores a la que confirma.
Reconcilia el resultado con lo que ya estabas mostrando.

Dos números declarados deciden cómo se siente eso. El umbral de divergencia: por debajo, la corrección se suaviza; por encima, tu cliente salta al estado correcto y vuelve a aplicar las entradas. Y el límite del búfer de entradas sin confirmar: el desbordamiento no queda indefinido — la degradación está declarada y es observable, así que un cliente con mala conexión sabe que dejó de predecir en lugar de desviarse en silencio.

La divergencia es observable para el cliente que la tuvo, y solo para ese cliente. Puedes saber que tu predicción se corrigió y cuánto — útil para ajustar y para mostrarle al jugador un indicador de conexión preciso. No puedes leer la divergencia de otro: el tamaño de una predicción fallida es información sobre su conexión, no sobre el juego. La corrección ocurre del lado del cliente, porque el estado de la autoridad es lo que todos los demás ya estaban viendo.

Si vienes de otra herramienta

Mover 2.0 de Unreal. La forma te resultará familiar: entradas con marca de tick, un modelo de movimiento, correcciones de la autoridad. La diferencia está en dónde vive el modelo: aquí lo declaras y la plataforma lo simula, así que no hay ningún componente de movimiento nuestro que tengas que heredar o reemplazar.
Netcode con rollback y replay, como en Photon Fusion. Volver a aplicar tus propias entradas sin confirmar después de una corrección es el mismo mecanismo, y aquí está completo. Lo que no está, a propósito, es volver a ejecutar el mundo a posteriori — consulta Lag Compensation para ver qué pasa en su lugar y por qué.

Qué no cubre esta página

Las entidades de otros jugadores no se predicen, se muestran — eso es Cómo mostrar a otros jugadores. Juzgar un disparo en la línea de tiempo del tirador es un mecanismo del servidor y está en Lag Compensation. Y ninguno de los tres aplica cuando el modo de autoridad de la sala (room) es externo: entonces el tick le pertenece a quien lo ejecuta, y la predicción también.