Los juegos en línea tienen problemas que los juegos para un solo jugador o solo en LAN no tienen que preocuparse, como el jitter, el tiempo de ida y vuelta (RTT) o la pérdida de paquetes.

Cualquier tipo de retraso entre el envío, la recepción y la cola de información entre clientes y servidores puede causar un problema en el juego. Para una lista completa de definiciones y problemas, consulta esta guía aquí.

Para abordar con éxito los problemas de latencia, necesitas considerar la prioridad y la relación entre los siguientes elementos:

1. Seguridad

2. Reactividad

3. Precisión y consistencia

Ninguna solución es perfecta, y cada forma de abordar los problemas de latencia tiene fortalezas y debilidades. La clave es encontrar la forma que mejor funcione para tu juego y esta guía te ayudará a entender cómo tomar esa decisión.

Autoridad define quién tiene el derecho de tomar decisiones finales sobre el juego en relación con los objetos en la relación cliente-servidor. El modelo de autoridad que selecciones tiene implicaciones para la latencia de la red en tu juego.

Hay dos tipos de autoridad en los juegos multijugador, y cada uno tiene su propia relación con la seguridad, la reactividad y la consistencia:

• Autoridad del servidor: Más seguro, menos reactivo, sin problemas de sincronización.
• Autoridad del cliente: Menos seguro, más reactivo, posibles problemas de sincronización.

Cualquier código que exista del lado del cliente puede ser manipulado y los jugadores pueden falsificar mensajes de red falsos enviados al servidor.

Si quieres saber cómo podría terminar viéndose esto en tu juego, considera el ejemplo de un juego donde no puedes matar a los duendes desde cierta distancia.

Si especificas en la lógica de tu cliente que no puedes matar a estos duendecillos a más de 10 metros de distancia, pero el mensaje de "matar duende" es un RPC del servidor que no verifica la distancia del lado del servidor, los jugadores pueden falsificar ese mensaje de red para eludir tu lógica del lado del cliente.

Desafortunadamente, algunas personas siempre intentarán interferir en tu juego, así que siempre debes tener en cuenta que nunca puedes confiar plenamente en los clientes. Por el bien de esos pobres duendecillos y de todos los demás que juegan a tu juego, tu servidor necesita lógica para validar las acciones de los jugadores que provienen de los clientes.

Un juego autoritativo de servidor tiene todas sus decisiones finales de jugabilidad ejecutadas por el servidor.

Seguridad ✅

Los datos críticos, como la salud de tu personaje o su posición, pueden ser autoritativos del servidor para garantizar que los tramposos no puedan interferir con ellos. En ese caso, el servidor tendrá la última palabra sobre el valor de esos datos.

Consistencia ✅

Una ventaja de los juegos autoritativos de servidor es la consistencia de tu mundo. Dado que todas las decisiones de juego son tomadas por el mismo nodo en la red (el servidor), puedes estar seguro de que estas decisiones se toman al mismo tiempo.

Reactividad 🚫

Un problema con la autoridad del servidor es que terminas esperando a que tu servidor te diga que actualices tu mundo. Sin embargo, mantente atento ya que hay patrones que puedes usar para resolver este problema mientras sigues siendo autoritativo en el servidor.

En un juego autoritativo de cliente, todavía tienes un servidor que se utiliza para compartir el estado del mundo, pero los clientes poseerán e impondrán su propia realidad.

Reactividad ✅

Un modelo autoritativo de cliente se puede utilizar a menudo cuando confías en tus usuarios o en sus dispositivos, y es un modelo útil para la reactividad. Dado que el propio cliente está tomando todas las decisiones importantes del juego, puede mostrar el resultado de las entradas del usuario tan pronto como ocurren.

Consistencia 🚫

Los juegos autoritativos del cliente pueden tener problemas de sincronización. Si dejas que tu cliente tome una decisión autoritaria utilizando información desactualizada, te encontrarás con desincronizaciones, objetos físicos superpuestos y otros problemas similares.

Seguridad 🚫

La autoridad del cliente es una puerta bastante peligrosa para dejar abierta en tu servidor, ya que cualquier jugador malicioso podría falsificar mensajes para ganar el juego.

Al diseñar tu función, utiliza la autoridad del servidor como predeterminada y luego identifica qué función necesita reactividad y no tiene un gran impacto en la seguridad o la consistencia del mundo.

Las entradas de usuario son un buen ejemplo. Dado que los usuarios ya son propietarios de sus entradas (yo soy el propietario de mi pulsación de tecla, el servidor no puede decirme "no, no has pulsado la tecla W"), los datos de entrada del usuario pueden ser fácilmente impulsados por el cliente.

En los juegos de FPS, tu dirección de mirada puede ser fácilmente impulsada por el cliente sin mucho impacto. El cliente enviará al servidor su dirección de mirada en lugar de los movimientos del ratón. Tener una corrección sobre dónde miras se sentiría raro y la seguridad para esto tiene sus propios desafíos.

La predicción puede mantener tu servidor de juego autoritativo mientras se mantiene reactivo. Su cliente simula y ejecuta código de juego que anticipa las entradas de activación de sus jugadores en lugar de esperar un RTT completo para los resultados de la acción.

Este es el momento en que "reconciliación" entra en juego, cuando ocurren errores en la predicción. El cliente mantiene un historial de las posiciones que predijo y, al ser el servidor autoritativo, el cliente sigue recibiendo posiciones que provienen del servidor. El cliente validará si las posiciones que predijo en el pasado se ajustan a las antiguas posiciones que provienen del servidor.

El cliente puede detectar discrepancias y corregir su posición de acuerdo con la posición autoritativa del servidor.

Nota Este método no está completamente soportado por Netcode para GameObjects en este momento.

Hay múltiples razones para no tener el código de juego autoritativo del servidor ejecutándose tanto del lado del cliente (con predicción) como del lado del servidor. Pero, ¿cómo te aseguras de que el lanzamiento se sienta receptivo y de que tu cliente no tenga que esperar un RTT completo antes de ver algo reaccionar a su entrada?

Un truco que a menudo se utiliza para ocultar el retraso es activar una animación, sonido o VFX que no impacte en la jugabilidad de inmediato al recibir la entrada del jugador, pero aún así esperar a que los elementos de jugabilidad autoritativos del servidor impulsen el resto de la acción.

Si el servidor tiene un estado diferente, lo peor que puede pasar del lado del cliente es que has reproducido una animación rápida pero inútil. Es fácil dejar que la animación termine o cancelarla. Esto se refiere a la proyección de acción o anticipación de acción.

La retroalimentación del servidor es un control de seguridad en una función impulsada por el cliente para asegurarnos de que mantenemos la autoridad del servidor.

El cliente envía junto con su entrada un mensaje al servidor diciendo "He alcanzado mi objetivo en el tiempo t". El servidor, al recibir esto en el tiempo t+RTT/2, rebobinará su simulación en el tiempo t-RTT, validará el disparo y corregirá el mundo en el último momento (es decir, matará al objetivo). Esto permite que el jugador sienta que el mundo es consistente mientras sigue siendo seguro y autoritativo del servidor.

Nota: El retroceso del servidor del estado del juego se realiza todo en el mismo fotograma y esto es invisible para los jugadores. Esta es una verificación del lado del servidor que permite validar a un cliente diciéndote qué hacer.

Nota Este método no está completamente soportado por Netcode para GameObjects en este momento.

Construir un juego multijugador es un esfuerzo desafiante, pero también emocionante. Ya sea que estés construyendo el próximo éxito de batalla real o un acogedor juego cooperativo en línea, entender las sutilezas de la latencia y cómo gestionarla es esencial.

Consulta nuestra documentación multijugador para comenzar con tu próximo proyecto hoy.