La forma más simple de explicar la predicción del cliente
El movimiento en multijugador parece complicado. En realidad son tres pasos: predecir, comparar, corregir.
Por qué hace falta
Sin autoridad del servidor no se pueden evitar las trampas. Pero si envías cada entrada al servidor y esperas respuesta, el jugador ve un personaje que se mueve 80 ms después de pulsar. Eso es injugable.
La solución: el cliente aplica el movimiento localmente de inmediato y envía la entrada al servidor al mismo tiempo. Es decir, predice el futuro.
Tres pasos
Predecir: el cliente simula la entrada al instante y escribe el resultado en un búfer de historial indexado por número de tick.
Comparar: cuando el servidor envía su propio resultado, el cliente lo compara con lo que guardó para ese tick.
Corregir: si la diferencia está dentro de la tolerancia, no se hace nada. Si no, se ajusta a la posición del servidor y se reproducen todas las entradas desde ese tick.
Trampas en la práctica
La simulación debe ser determinista. La misma entrada desde el mismo estado inicial debe dar el mismo resultado. Un paso de física guiado por Time.deltaTime rompe esto: usa un tick fijo.
No corrijas de golpe. Suavizar las diferencias pequeñas a lo largo de unos frames evita que el jugador sienta que se teletransporta.
Por dónde empezar
Primero construye el movimiento de un jugador sobre un tick fijo y hazlo determinista. La capa de red viene después.
Quien invierte este orden acaba depurando a la vez errores de movimiento y de sincronización. Lo digo por experiencia.