Modelos de red en videojuegos

Modelo peer-to-peer

El primer modelo de red utilizado en los juegos multijugador estaba basado en el modelo peer-to-peer. Este modelo se caracteriza por no tener ningún elemento central, sino que cada nodo de la red sirve y solicita información a los demás. Aunque todavía hoy día es posible encontrar juegos que usan este modelo de red , presenta una serie de problemas que desaconsejan su uso en la mayoría de juegos actuales. Actualmente el modelo Peer-to-Peer es usado principalmente en juegos de estrategia en tiempo real(RTS). Como ejemplo representativo, podemos nombrar Starcraft I.

En este modelo, cada par ejecuta una instancia del juego y envía el estado de su mundo a todos los demás pares. Para poder renderizar la escena, antes todos los pares deben recibir los mensajes de los demás. La latencia de todos los jugadores tiene un impacto determinante en la partida, ya que el jugador con mayor latencia tardará mas en recibir los mensajes de los demás jugadores y en enviar los suyos, retrasando la ejecución del juego para todos los participantes; es decir, la latencia de los jugadores tiende a igualarse a la del jugador más «lejano». Esto afecta negativamente a la inmediatez, lo que no es aceptable en juegos donde ésta sea una propiedad básica (tipo FPS). Por otro lado, este modelo tiene dificultades para mantener la consistencia de una partida, ya que comunicar el estado entre todos los jugadores consume mucho ancho de banda, al requerir un gran número de mensajes.

Modelo cliente servidor

Un modelo de red cliente-servidor se caracteriza por tener una entidad central, llamada servidor, que se encarga de enviar información a los demás participantes en la partida, normalmente llamados clientes, que se la solicitan. Este modelo reduce el problema de la latencia debido a que ahora la latencia para un cliente dado solo depende de su conexión con el servidor, no viéndose afectado (al menos no directamente) por la latencia de los demás jugadores.

El primer modelo de red basado en una arquitectura cliente-servidor implementaba el cliente de forma que las únicas funciones que tenía eran muestrear los eventos de entrada del jugador (pulsaciones de teclado/ratón), enviarlos al servidor y renderizar el mundo. El servidor por su parte ejecutaba la única instancia real del juego, recibía mensajes de los clientes y actualizaba el estado del mundo basándose en los mensajes recibidos. Este método conseguía mejorar la consistencia, ya que el servidor se encarga de comprobar la legalidad de las acciones de cada jugador y de enviarles mensajes con el estado actualizado del juego.

Aún con estos cambios, la latencia seguía suponiendo un problema si se quería mejorar la inmediatez. Sin embargo, se desarrollaron una serie de técnicas que conseguirían reducir y enmascarar la latencia. Estas técnicas se pueden resumir en: mecanismos de predicción en el lado del cliente, desarrollados por John Carmack y de compensación de la latencia en el lado del servidor, desarrollados por Yahn Bernier.

Actualmente, la gran mayoría de juegos en red utilizan un modelo cliente servidor ya que reduce el problema de la latencia, ayudando a enmascararla, lo que mejora la inmediatez, al tiempo que reduce las exigencias de ancho de banda.

Mecanismos de reducción de la latencia

En un modelo cliente-servidor actual típico, el servidor envía al cliente una media de 20 mensajes por segundo. Si el cliente renderizase el mundo únicamente con la información que recibe del servidor, no se alcanzaría un framerate (cantidad de cuadros por segundo) aceptable, haciendo que el vídeo del juego no fuese fluido. El mínimo ratio de renderizado aceptado por la industria del videojuego es de 30 frames por segundo. Eso supone 30 mensajes por segundo, por lo que el servidor debería enviar al menos esta cantidad de mensajes para que los clientes pudiesen renderizar el mundo sin implementar ningún tipo de técnica de compensación, todo esto suponiendo que los paquetes no sufren perdidas, no se viesen afectados por factores como el jittering, altas latencias, etcétera.

Para poder alcanzar una tasa de renderizado aceptable en esta situación se usa una técnica que se conoce como interpolación. La interpolación pasa por retrasar el proceso de renderizado en el cliente una cantidad de tiempo aproximadamente igual a la latencia, mientras que se van almacenando en un buffer los snapshots que envía el servidor. En el ejemplo anterior, si el servidor envía 20 mensajes por segundo, el cliente recibiría uno cada 50ms. Al retrasar 50ms el renderizado de la escena, el estado de los objetos del juego podrá ser interpolado tomando el rango de valores comprendido entre el último mensaje recibido y el previo a ese. Este proceso requiere seguir recibiendo mensajes del servidor, no siendo posible llevarse a cabo si se pierden mas de dos mensajes consecutivos, debido a que el cliente se quedaría sin snapshots en el buffer. La forma de solucionar este problema pasaría por aumentar el tiempo de interpolación. Sin embargo, esto aumentaría aún mas la latencia, de modo que se puede aumentar indefinidamente el tiempo de interpolación.

Otra técnica consiste en optar por aceptar como bueno, de forma temporal, la ejecución de un comando del jugador local (recordemos que el servidor debe autorizar todas las acciones de cada jugador), en lugar de esperar la recepción de la confirmación del servidor. Esto permite ejecutar las acciones asociadas a dicho comando inmediatamente. Este proceso sólo es aplicable a las entidades del mundo que se vean directamente afectada por los comandos del usuario local. Esto es así debido a que se necesita la información de los demás usuarios para poder saber qué acciones tomaron. Si el cliente comete un error al predecir sus propias acciones (por ejemplo, porque ocurrió una interacción con otro jugador que el cliente no pudo tener en cuenta durante la predicción) deberá rectificar en base a los mensajes procedentes del servidor. Para poder realizar estas correcciones, el cliente guarda todos las acciones no confirmadas por el servidor en un buffer, de modo que cuando el servidor le informa de su error, el cliente puede «rebobinar» sus acciones y corregir su error con la información recibida del servidor.

El servidor por su parte realiza compresión de datos y compensación de la latencia. La compresión de datos se realiza enviando snapshots, es decir, resúmenes del estado del juego en un determinado momento, en lugar de enviar el estado con cada cambio que se produzca.

La compensación de latencia consiste en tener en cuenta la latencia del cliente a la hora de procesar los mensajes. Comprender cómo funciona la interpolación es importante en el diseño de la compensación de latencia debido a que la interpolación es otro tipo de latencia en la experiencia de un usuario. En la medida en que un jugador está interaccionando a otros objetos que han sido interpolados, el tiempo de interpolación debe ser tomado en consideración de modo que se puedan conseguir un mayor determinismo.

La compensación de latencia es un método de normalización del estado del mundo por parte del servidor, que se lleva a cabo para cada comando de cada jugador. Se podría pensar en la compensación de latencia como en dar un paso atrás en el tiempo para mirar a la situación del mundo en el instante exacto en que el usuario realiza alguna acción Por ejemplo, si el cliente tiene 150ms de latencia, los mensajes que reciba el servidor tendrían sentido con el estado que el tuviese el mundo hace 150ms, de modo que el servidor «rebobina» el estado del juego para este jugador a 150ms antes de recibir un mensaje de dicho cliente, de modo que pueda ejecutar los comandos de usuario en el contexto en el que el cliente estaba inmerso cuando los ejecutó.