26 de junio, 2013
Artículo indiespensable
Indiespensable
Dev Lavde #7 — Los problemas del multijugador online
Dev Lavde #7 — Los problemas del multijugador online

Internet. Esa poderosa interconexión de máquinas con el potencial de, por un lado, unir a millones de personas en una causa tan noble y democrática como votar el ganador de Gran Hermano y, por el otro, de lograr siniestras distopías acabando con la privacidad y convirtiéndonos en esclavos bajo el yugo de un programa informático (llámese Prism, Echelon o Skynet). Por lo menos, hasta que algo de eso llegue, internet también nos sirve para que podamos compartir experiencias lúdicas independientemente de nuestra localización geográfica. De esto, precisamente, tratará el artículo de hoy. Intentaré responder a la pregunta: ¿cómo es posible el juego en red? Y eso que yo aún no lo tengo claro.

Los videojuegos para varios jugadores han estado ahí desde el inicio. De hecho, el que se considera el primer videojuego de la historia, Tennis for Two (William Higinbotham, 1958), era, como indica su nombre, para dos jugadores. Pero lo que no es tan antiguo es la posibilidad de jugar a un videojuego estando los jugadores a miles de kilómetros de distancia. Para llegar a ello ha tenido que haber una evolución increíble de la tecnología, las infraestructuras y las técnicas de desarrollo de videojuegos, porque, aunque lo damos por sentado en muchas ocasiones, el juego en red no es nada sencillo.

Los avances de internet

Cualquier programador, ingeniero, o hijo de vecino con curiosidad habrá oído o leído la historia del origen de internet a finales de los años sesenta. Lo interesante no fue la comunicación entre dos máquinas, sino la forma en que se hizo. Conectar dos ordenadores requiere un medio por el que transmitir la información y si están muy alejados entre sí, hay un problema de infraestructura. El gran avance en este caso, fue reutilizar una red de conexiones eléctricas ya disponible y muy extendida: la red telefónica, que lleva construyéndose, más o menos, desde 1880.

Pero, quizá lo más importante para el caso que nos ocupa, es otro de los avances que vinieron de la mano de las primeras comunicaciones entre máquinas a través de la red telefónica: el uso de paquetes de datos. Es fácil olvidarse de que un cable sólo puede tener un valor eléctrico en todo su recorrido, y eso complica la tarea de comunicar múltiples máquinas a la vez por el mismo canal. Sin embargo, si dividimos la información en pequeños fragmentos, se pueden intercalar los procedentes de distintas máquinas y transmitirlos por el mismo cable. Sólo hay que colocar un dispositivo (un switch o un router) que se encargue de almacenar temporalmente esos paquetes y transmitirlos en el momento adecuado por el sitio correcto. Además, si en esos paquetes va incluida la información del destinatario, remitente y el número de paquete, pueden viajar incluso por caminos diferentes y desordenados y aún así llegar a su destino que ya se encargará el receptor de reordenar la información.

Lo que tenemos hoy en día es una red enorme que conecta millones de máquinas alrededor de todo el mundo de múltiples formas: por cable, fibra óptica, ondas electromagnéticas, por tierra, mar, aire y espacio, lo que haga falta. Para que este lío absurdo funcione, se inventaron una serie de protocolos que las máquinas siguen escrupulosamente. Estos protocolos, como el protocolo TCP/IP, indican los tipos de paquetes que se han de enviar y qué información deben llevar para que dos máquinas se entiendan. Continuamente estas máquinas se están enviando, unas a otras, paquetes con información que se desordenan, pierden, retrasan, estropean y son escuchados por los espías chinos, los hackers rusos y las agencias de defensa estadounidenses. Y aún así, gracias los protocolos, todo funciona y podemos entrar, desde nuestra casa, en la página de Facebook para descargarnos, a través un servidor alojado en Siberia, las últimas fotos de las vacaciones de nuestro compañero de pupitre del colegio subidas con un teléfono móvil en Punta Cana.

EXPERIMENTO: Animo al lector a hacer la siguiente prueba para observar en sus propias carnes la complejidad de la red: Abrir la línea de comandos y escribir: tracert www.facebook.com – El comando tracert (trace route) nos informa de las direcciones IP de las máquinas por las que pasan los paquetes de datos y el tiempo que tardan en llegar de unas a otras, en este caso nos devolverá la ruta seguida por los paquetes para llegar hasta Facebook. También podemos hacer lo mismo en GNU/Linux o Mac.

Los problemas de Internet

Así que todo listo para que cojamos nuestro juego, mandemos unos paquetitos con la posición del jugador a la otra máquina y ya está: juego en red. Pues desgraciadamente no. Hay muchos problemas derivados de todo esto que no parecen evidentes a simple vista pero que están ahí, y aquí tenéis unos ejemplos.

Uno de esos problemas es la latencia, o el tiempo que tarda en llegar la información. Debido a la propia estructura de la red, y que, para alcanzar la máquina de destino, un paquete puede pasar por muchos lugares distintos, los mensajes tardan en transmitirse. Todo funciona a la velocidad de la luz, pero a pesar de todo podemos tener una latencia de entre 30 y 150 milisegundos. Parece poco, pero si pensamos en el Counter Strike (Valve, 1999) y que un jugador pulsa furiosamente su ratón para disparar mientras otro se está moviendo y cambiando de dirección con el objetivo de esquivar las balas, esos 30 milisegundos pueden ser cruciales para que el sistema pueda decidir si le acabas de hacer el headshot de tu vida a ese chaval inglés de 11 años tan prepotente, o le has dado nuevamente a la pared.

Otra pega es la pérdida de paquetes. ¿Os han perdido alguna vez la maleta en un viaje en avión? Pues internet funciona mucho peor, los paquetes se pierden continuamente. Esto es fácil de arreglar añadiendo información del número que hay y el orden en cada paquete de datos. Si falta uno, el receptor puede averiguarlo y pedir de nuevo el paquete perdido. Pero eso hace que la latencia aumente considerablemente, porque hay que esperar a completar el mensaje. Y ¿para qué queremos la posición del jugador de hace medio segundo si ya ha llegado la actual, que es la que importa? En este caso la pérdida de paquetes no significa demasiado, pero sí que hay momentos en los que es crucial que los mensajes no se pierdan. De hecho, hay dos protocolos extensamente usados para comunicaciones a través de red que se diferencian principalmente en esto: en el protocolo TCP los mensajes llegan seguros pero más lentos, y en el UDP no sabemos si llegará o no el mensaje, pero si llega lo hace más deprisa y transmitiendo menos información.

El ancho de banda también puede suponer un problema. La cantidad de datos que podemos enviar y recibir a través de internet en función del tiempo es limitada (sobretodo la de enviar). Por ello hay que tratar de transmitir la menor cantidad de información posible, o el juego no funcionará en cuanto otra persona en la casa decida ver un video en streaming con el iPad (y no le queda otra ya que estamos acaparando el salón jugando a un juego multiplayer como posesos). Eso significa dejar de transmitir cualquier cosa que no afecte al gameplay directamente o que se pueda reconstruir a partir otra información.

La solución

¿Cómo se pueden solucionar estos problemas para que jugar en red resulte casi tan fluido como el juego single player? Pues lo cierto es que no se puede, así que no se trata de solucionarlo sino de minimizar el impacto lo más posible y que el jugador no se de cuenta. Para ello los juegos están adivinando continuamente lo que harán los demás jugadores. Debido a la latencia o la pérdida de paquetes, sabemos que la información llegará con retraso o no llegará, así que hay que prevenirlo y calcular esa información desconocida con suposiciones basadas en los datos que ya tenemos, lo que se llama extrapolación, aunque también puede que os suene la expresión «dead reckoning», que es una forma de extrapolar la posición en función de la trayectoria y la velocidad usada a menudo en los juegos. Sin embargo, la extrapolación es falible si hay un cambio brusco que nos hemos perdido, por lo que seguramente habrá que usar algún tipo de interpolación para volver a poner las cosas en su cauce sin que se noten los saltos. Además, debido a que no podemos enviar toda la información que queremos, hay multitud de cosas que no se transmiten, como la posición de los fragmentos de un objeto roto.

El resultado es que lo que ve un jugador en un juego online, no es necesariamente lo que ven los demás, ni siquiera tiene porqué ser la realidad del juego. Esto da lugar a infinidad de situaciones incómodas: ¿Qué ocurre si dos jugadores cogen a la vez el mismo power-up? Cosa factible, ya que cada uno en su propia máquina puede estar en una posición ligeramente distinta. Dependiendo del juego, se puede resolver de dos formas: O bien dándole a los dos el power-up, o bien preguntando antes si ya lo ha cogido alguien y decidiendo quien lo tiene, enviando y recibiendo unos cuantos mensajes (que, de nuevo, podrían no llegar). Hay que conocer todas esas discrepancias e intentar resolverlas tratando de que ningún jugador vea nada demasiado raro, pero no siempre es posible.

En resumen

El juego online conlleva unos problemas muy serios que sólo se pueden resolver por las malas, y suele ser una de las partes más difíciles de desarrollar y que más preocupaciones crea. Por supuesto, depende del tipo de juego que estos problemas sean más influyentes o no, afectando menos a los juegos por turnos, en los que sólo hace falta transmitir el estado una vez cada cierto tiempo y sin prisa. Sin embargo, en los juegos de acción en tiempo real habrá que tener mucho cuidado y tratar de que el jugador no se entere de lo que está pasando en realidad y no se lleve una sorpresa desagradable.

Cuanto mejor sea la conexión (de todos los jugadores que participen en el juego), los errores en la transmisión serán menos frecuentes. Pero eso tampoco ayuda mucho, el problema es que no se sabe, son cosas que pueden ocurrir o no, por lo que el juego debe estar preparado igualmente para los peores casos. Como además depende del juego que tengamos que tratar el modo online de una forma u otra, no existe un estándar. Casi siempre hay que montarlo prácticamente desde cero, y hay realmente pocas cosas que faciliten la tarea de sincronizar los juegos a través de internet. Por ello es muy importante que se tenga en cuenta desde el principio, porque adaptarse a todos estos problemas hace que cambie mucho la forma de jugar y de realizar el juego, y si no se ha previsto correctamente puede ser una fuente inagotable de bugs y complicar de forma inimaginable el desarrollo.

Acerca de Enrique Hervás


Humano Nivel 32. Diseñador y Programador de videojuegos Nivel 6. De esos a los que sus padres prohibieron jugar a "las maquinitas" por estar demasiado enganchados. No sabían lo que les esperaba. Actualmente trabajo como Game Designer en Exient, e intento no olvidarme de mi pasado indie de Game Jams y jueguitos con Join2 Games

No hay comentarios