Evitar Trampas
Si los clientes le dijeran al host dónde están y qué están haciendo en el juego, y el host les creyera, los clientes podrían hacer trampa. Ellos simplemente necesitarían enviar datos diciendo que están al otro lado de la pared, o que han atacado a un jugador que no pueden alcanzar, etc. Para mitigar esto, en cambio los clientes sólo le dicen al host sus comandos de entrada, como qué teclas de flecha ellos están presionando actualmente. El host recibe esto y empieza a mover ese jugador, y a enviar datos de vuelta diciendo al jugador dónde cree que está.
El problema inmediato con esto es que añade un retraso a las entradas el jugador. Si un jugador presiona "Izquierda" con una latencia de 100ms, el host recibirá ese comando 100ms después de ser presionado. Luego tomará otros 100ms para que la actualización del host con la nueva posición del jugador llegue de vuelta. Esto significa que todos los controles de los clientes se sienten con lag, sólo tomando efecto tras una significante fracción de segundo. Para resolver esto, el juego local del cliente utiliza predicción de entrada local.
Predicción de entrada local
En cambio, presionar izquierda enviará una mensaje al host indicando la entrada que fue presionada, entonces el juego local del jugador empieza a moverlos de todas formas, ¡sin esperar la confirmación del host! ya que el host y el cliente están corriendo el mismo juego, ellos generalmente se coordinan muy cercanamente. Entonces el jugador toma un control que se siente responsivo, y aun así no pueden hacer trampa: ellos simplemente están enviando sus entradas, y no pueden pretender estar en algún otro lugar. Incluso si han hackeado su juego local, sólo serviría para ponerlos en desventaja, ya que todo lo que pueden hacer es mostrarse a sí mismos como si estuvieran en el lugar equivocado comparado con el host.
Los jugadores clientes sin embargo, inevitablemente, derivaran a la posición en la que el host los ve. Hay un montón de pequeños errores que pueden acumularse en los tiempos de red, la sincronización de la tasa de frames, las medidas de variación de tiempo, etc. El cliente todavía está recibiendo mensajes del host diciendo donde se encuentran, pero los mensajes van retrasados. En el ejemplo anterior, el cliente recibe su posición del host con un retraso total de 200ms. Para corregir desviaciones, el motor multijugador mira la historia del objeto y la comprar con su posición hace 200ms. En otras palabras, las correcciones se hacen mirando dónde estaba el objeto en el pasado, tomando en cuenta la latencia hacia el host. Si el objeto está en el lugar incorrecto, el motor lo moverá gradualmente para compensarlo. Esto ocurre en el tiempo para tratar de hacerlo menos notorio. En algunos casos extremos una gran cantidad de notable corrección será necesaria, pero bajo buenas condiciones de red el movimiento coincide muy bien y los pequeños ajustes se hacen en una manera que sea difícil de notar.
Vale la pena señalar que esto no está limitado a posiciones. El motor tiene la habilidad de hacer toda esta sincronización con cualquier variable de la instancia, no sólo coordenadas X y Y.
Lag
Bajo pobres condiciones de red, habrá obvios efectos en la experiencia de juego. Los jugadores se refieren generalmente a este problema como "lag". Éste puede incluir movimientos bruscos (cuando la memoria intermedia de actualización de 80ms está vacía), saltos o discontinuidades en el juego (Cuando una pérdida de paquetes ocurre y la siguiente actualización cambia significativamente el estado de juego), el jugador cambiando de repente de posición (Cuando la predicción de entrada local encuentra un gran error), o consecuencias que no parecen justas (Usualmente el resultado de cada jugador viendo el juego con un retraso distinto, y el host haciendo una decisión autoritaria en favor de un cliente en particular).
Desafortunadamente no hay una buena solución para evitar permanentemente estos problemas, otra que encontrar la mejor calidad en la conexión de Internet. Estos problemas usualmente sólo ocurren bajo circunstancias severas, como una completa pérdida de paquetes por algunos segundos, o cambios temporales súbitos y extremos en latencia o PDV. En tales casos es casi imposible para las varias técnicas de compensación resolverlos. Esto algunas veces es simplemente la realidad de la comunicación en el Internet.