BAJO LA PIEL DEL FALCON MULTIPLAYER

Multiplayer: La parte de Falcon que genera ms preguntas tanto por parte de los nuevos
pilotos como de los ms experimentados. Ahora, la mayora de nosotros estamos familiarizados
con las ideas bsicas sobre cmo conectarse con otros jugadores en la red o en una LAN.
Este artculo examinar que es lo que pasa bajo la superficie en el Falcon SP3 y SP4 durante
las sesiones multijugador. Acabar con algunos de los mitos que rodean al asunto espinoso de las
burbujas y explica qu mensajes son los que se dividen entre el host y los clientes. Es la gua mas
detallada hasta la fecha sobre la forma de trabajar del MP en Falcon.
El artculo ha sido compilado entre la mirada de mensajes recibidos de varias fuentes que han
resultado ser las ms informativas. Si no ests seguro sobre los aspectos bsicos del MP en Falcon,
recomiendo que leas el stiky MP More en el Forum de Falcon 4 en frugalsworld. Tambin
puedes leer la gua de Bruce Lytning Hale en http://home.ptd.net/~bhale/BandwidthTable.htm.
En los ltimos 18 meses mas o menos, dos personas han perfilado la forma en que funciona el
MP en las versiones del SuperPak del Falcon: RIK y Schumi. Su trabajo cambi la forma en
que operaba el MP al modificar el cdigo en el exe. Es un material complicado y delicado de
testear pero ha mejorado mucho la experiencia MP del Falcon.

Vuelta a lo bsico.
Antes de empezar con el meollo de la cuestin, un par de definiciones:

HOST: La mquina que pone en lnea el juego (no necesariamente la que tiene la
direccin 0.0.0.0 en la lnea de internet).
CLIENTE: Mquina que se conecta a la sesin del host.
ENTIDAD: Cualquier cosa que exista en el mundo 3D del Falcon, como un edificio,
un tanque, un lanzador de misiles, un avin, sitio SAM, etc.
DISGREGACIN: Proceso mediante el cual un objeto del mundo 3D se transforma
en una entidad completamente operativa. Si todos los objetos en Falcon fuesen
tratados de esta manera, necesitaramos un par de CRAYs para ejecutarlo dado el alto
procesado numrico que hara falta. As que cada jugador, ya sea host o cliente, debe

realizar este proceso en los objetos 3D, de la misma forma que se hace en las
misiones en solitario.
BURBUJA: Esfera imaginaria que est alrededor de cualquier entidad en el mundo
3D. Cuando el avin del jugador se mueve dentro de la burbuja de una entidad, esa
entidad se disgrega y se convierte en una entidad 3D. Este es el mtodo que usa el
Falcon para ahorrar ciclos de CPU.

Para que funcione el MP, necesitamos enviar mensajes entre los distintos jugadores
involucrados. En otras palabras, cada computadora necesita conocer informacin sobre la situacin
de los dems en el mundo 3D. Esto se hace enviando mensajes entre todos los PCs en el juego.
Estos mensajes incluyen actualizaciones en la posicin de cada avin, as como en las posiciones
de unidades como sitios SAM, misiles en el aire, etc.

Hosts, Clientes e Iguales.

Falcon utiliza un sistema cliente-servidor para el multijugador. El mtodo pre-SP de trabajar
en un ambiente multijugador era la conexin de igual-a-igual (peer-to-peer). El problema era que
se utilizaba demasiado ancho de banda, creando cuellos de botella innecesarios en el sistema. De
ah la evolucin a un cdigo cliente-servidor para hacer las cosas ms eficientes. El host en Falcon
controla las actualizaciones posicionales de todos los aviones de la IA. Cuando cambia la posicin
de un avin de la IA, esos cambios se envian a todos los clientes para hacerles saber las nuevas
posicines.
Tomando Control de las Entidades.
F4UT ha hecho pruebas usando programas espia/analizadorer de red para seguir los flujos de
datos entre PCs en un juego multijugador. Ha encontrado que datos como las posiciones de los
aviones de la IA se enva usando un mtodo cliente-servidor, es decir, el host enva los cambios a
los clientes. Como se dijo anteriormente, el host controla los aviones de la IA, de ah el por qu de
que el host experimente una intensa cada en las FPS durante combates intensos A-A con aviones
de la IA el host es el que realiza todos los calculos de las burbujas de esos aviones.
Will, tambin conocido como "Wmulvihilldxr" ha realizado una enorme cantidad de trabajo
probando y rastreando en el sistema MP para verificar que pasa. l concluye:

1.

2.
3.
4.

5.
6.

7.

8.
9.
10.
11.

12.
13.
14.
15.
16.
17.

18.

Cuando el cliente se une al juego, el host enva a cada cliente una enorme cantidad de
eventos de creacin y completa actualizacin (de objetos). Estos eventos son
realmente grandes cuando se trata de una campaa, ya que necesitas recibir uno de
esos eventos para cada unidad terrestre, escuadrn y avin en la campaa. Esto no
incluye los objetivos. Estos eventos de actualizacin completa tambin dan la
localizacin completa de cada una de las entidades as como qu PC posee y controla
la unidad (recordar este hecho para ms tarde). Mientras ests en la misma campaa,
la sesin cliente simplemente carga los objetivos de la mquina local. Como se
calculan los daos se explicar ms tarde
As, el cliente tiene una copia de cada entidad en todo el juego (objetivos, aviones,
unidades terrestres, etc, etc) para comenzar y conoce la localizacin exacta de cada
una.
En este punto, el host es el dueo de todas esas entidades.
Si un objetivo resulta daado, no se enva a no ser que sea necesario. Cundo sera
necesario? Bueno, al usar la ventana de Recon en el UI para ver el objetivo, se
recibira una actualizacin completa en ese objetivo, incluyendo cualquier dao en
los objetos.
Cuando alguien se une al mundo 3D, disgrega todas las unidades en el area de la
base area.
Pero espera, creas que el host era el dueo de todos los objetos? Cuando un cliente
disgrega una entidad, toma posesin de la entidad y disgrega las unidades
individuales de esa entidad. Por ejemplo, si se disgrega una batera de Patriots, se
disgregan los lanzadores individuales y vehculos de apoyo. El cliente toma posesin
de todo eso.
En este punto, el cliente tiene esa unidad terrestre que posee. Pero adems le indica al
host que ha disgregado esa unidad. El host entonces se convierte en un ESCLAVO
(siendo el MAESTRO el dueos, es decir, el cliente). Si el host necesita una
actualizacin de la entidad, se la pedir al cliente.
De esta manera es como los clientes reciben control de las entidades y desde entonces
(hasta que agreguen la entidad), la controlan.
Ahora, un segundo cliente se une al juego. Como antes, el host enva todas las
actualizaciones sobre las entidades.
Entonces el segundo cliente entra en el mundo 3D junto al primer cliente.
Qu pasa ahora? Recordar que el host todava tiene una copia completa y
actualizada de cada una de las entidades. Lo que ocurre es que el primer cliente posee
una batera de Patriot. Pero si se necesitara una actualizacin, el primer cliente hara
los calculos y se la enviara al host.
As que cuando el segundo cliente entra en el mundo 3D, todava pide la informacin
disgregada de la batera Patriot al host.
El host dice, Hey, tengo esa entidad. Ya est disgregada y no la poseo, aqu tienes la
informacin de disgregacin, disfruta.
En ese momento, el segundo cliente tiene la informacin de la entidad y sabe que el
que la posee es otro (a dems del host) as que este segundo cliente no toma posesin
de la entidad.
Sin embargo, si el segundo cliente se mueve y es el primero en disgregar una entidad
distinta, entonces este segundo cliente tomar posesin de esa entidad de forma usual.
Ahora, que pasara si ambos clientes estn en la misma burbuja y el Patriot que
posee el primer cliente se mueve a algn otro sitio?
Esto disparara una actualizacin de posicin que se generara en la mquina del
primer cliente. Por qu? Porque es el propietario de la entidad, manejara la IA y
decidira qu es lo que hace (no os preocupis, no es tan simple como Todos los
clientes se hacen con unidades de tierra y las hacen moverse como idiotas. Hay
algunas reglas para asegurarse que las unidades funcionan de manera consistente con
la guerra en conjunto. No est completamente integrado, pero ayuda a ello).
PASO CRTICO. Aqu est la respuesta a la pregunta que parece estar escondida.
Cuando el primer cliente genera una actualizacin de posicin para esa batera
Patriot, NO la manda al segundo cliente en el cdigo SP3. Se la enva al host. El host
recibe la actualizacin y en su propia copia de la entidad, la marca como usada.
Marcarla como usada significa que el host sabe que ha cambiado y que la prxima

vez que mande actualizaciones de posicin, necesita propagar ese cambio a los otros
clientes que necesitan la actualizacin.

As, la razn de que los clientes posean entidades y no necesiten un montn de ancho de banda
y tambin la razn de que el host necesite una gran cantidad de ancho de banda para soportar ms
cliente es que el host en realidad es el que da las actualizaciones de posicin a todos los clientes.
Sin embargo, son los clientes los que realizan las disgregaciones y hacen todos los clculos
necesarios para controlar esa entidad. El cliente pasa esa informacin al host y as ste puede (si lo
necesita) mandar la informacin a todos los clientes.
Conclusin:
Los clientes gastan ciclos de CPU al disgregar y controlar entidades.
Los clientes pasan esa informacin al host.
De esta manera, el host tiene en todo momento la imagen ms completa del juego.
El host suministra los cambios de posicin a todos los clientes que lo necesiten (por
ejemplo, si los clientes estn en la misma burbuja que los otros clientes o solicitan
disgregacin de esa entidad).
El host lleva la carga del ancho de banda por el punto anterior al tener que propagar
las entidades a cada uno que lo necesite.
Qu pasa con la opcin Host All Units en Falcon? No era la idea descargar a los clientes
al asumir control de todas las unidades de tierra en todas las burbujas de los jugadores?

Bueno, esa era la idea, pero parece que funcion de forma menos eficiente de lo que uno
podra haber esperado al principio. Se necesitan ms pruebas, pero parece que los problemas del
CTD (cumulative transit delay o retraso acumulativo del trnsito, N. del T.) en Falcon son debidas
normalmente a restricciones de ancho de banda de la red.
Compresin: El nombre del juego.
Pero hay an ms magia en Falcon. Utiliza un sistema de compresin para ahorrar ancho de
banda disminuyendo el nmero de paquetes enviados. Por ejemplo, un usuario de conexin va
MODEM que disgrega un objeto terrestre necesita enviar a un amigo volando como su punto una
actualizacin de posicin de esa unidad. No solo eso, tambin podra necesitar enviar una
actualizacin de su propia posicin y viceversa. Parecera que para cada una de ellas se
necesitaran enviar dos paquetes de informacin (posicin de la unidad + posicin de avin). Pero
Falcon tiene un truco bajo la manga. Cuando se necesita enviar actualizacin sobre una unidad
terrestre, ese trozo de informacin se inserta dentro de la actualizacin de posicin regular que se
manda cada medio segundo ms o menos. Dos piezas de informacin al precio de una. Estupendo.

Cada actualizacin posicional es de unos 48 bytes. Para una conexin va MODEM cada paquete
enviado puede contener como 30 actualizaciones de posicin un uso eficiente de ancho de banda.
En realidad, este truco de juntar mensajes en un nico paquete no solo se utiliza en las
actualizaciones de posicin, sino que se usa en todos los paquetes que se aaden a las colas de
envo. As que si se tienen un montn de mensajes que se van a mandar al mismo destino, Falcon
los ir juntando hasta que alguno de ellos se mande o el paquete se haga demasiado grande para
caber en el MTU de una conexin MODEM (MTU significa bsicamente el mximo nmero de
bytes que se pueden transferir en un paquete de red). (MTU: Maximun Transfer Unit, unidad
mxima de transferencia, N. del T.)
Si el primer paquete se hace demasiado grande, Falcon simplemente empieza un nuevo
paquete y contina aadiendo en ese. Cuando el juego es frentico en 3D, puedes apostar a que en
cada paquete de red tiene un promedio de unos 5 a diez mensajes dentro. Una manera fantstica de
comprimir cada byte en la red.
Una cosa que clarificar sobre compresin. Falcon no solo junta los mensajes para usar un solo
paquete como se ha descrito antes, sino que adems, cuando el paquete est listo para ser mandado,
se comprime utilizando un algoritmo de compresin ampliamente conocido. As un paquete de
1500 bytes, puede convertirse en un paquete de 800-1200 bytes. Eso tambin ahorra ancho de
banda.
Extendiendo el mensaje.
Por supuesto, hay ms datos pululando en un juego MP: por ejemplo si fichas a uno de tus
compaeros humanos, se han de mandar mensajes para lanzar el tono de alerta en la cabina de tu
compaero. Y la lista sigue y sigue. A continuacin, una explicacin detallada de lo que ocurre.
Falcon tiene varias formas de mandar un mensaje desde el punto de vista de la red. Primero
unos cuantos apuntes sobre funcionamiento de redes. Puede que hayas odo hablar del TCP y a lo
mejor tambin del UDP. La ventaja del protocolo TCP frente al UDP es que TCP tiene un nmero
de funcionalidades que asegura que los paquetes de red llegan a su destino intactos, en orden, de
forma fiable y sin prdidas. La desventaja de TCP es que hace que los paquetes de red sean
mayores para poder implementar esas funcionalidades. UDP deja de lado fiabilidad y orden para
ganar ms bytes para los datos del paquete.
Falcon manda paquetes de dos formas distintas a nivel de red: UDP y RUDP (Reliable UDP)
(UDP Fiable, N. del T.). UDP no est orientado a conexin (en contra de TCP que puede mantener
una conexin constante entre dos PCs) y asume que cada paquete llega a su destino. El tamao
mximo y mnimo de una cabecera UDP es de 8 bytes. RUDP es una extensin de UDP y hace lo
que dice que hace, es UDP confiable. Proporciona muchas de las funcionalidades de TCP pero usa
UDP como transporte (lo que significa que RUDP va encapsulado en un paquete UDP corriente).
RUDP es un protocolo semipropietario. Cisco, creo, tiene un RFC (RFC= Request for Information.
Bsicamente, los RFCs con los documentos que estandarizan los protocolos de red para su usa en
Internet y ms all) sobre su protocolo RUDP, pero no se parece en nada al que se usa en Falcon.
Pero eso es salirse del tema.
Las cabeceras RUDP (el byte al principio del protocolo de red dentro del paquete de red) en
Falcon tiene nmeros de secuencia, ACKs (ACK son las siglas de acknowledgement o acuse de
recibo en ingls, N. del T.), mensajes fragmentados, etc. Como TCP para asegurar que los datos
lleguen intactos y es aceptado por el receptor. Pero aqu est la diferencia, las cabeceras RUDP no
ocupan ms de 9 bytes. En la mayora de los casos, usa slo 5 bytes para la cabecera. Qu es lo
que eso significa? Bueno con TCP, de acuerdo a los RFCs, tienes que tener AL MENOS 20 bytes
en la cabecera, a veces hasta 192 bytes. Con RUDP, dependiendo del tipo de paquete, tienes de 917 bytes en la cabecera (8 bytes para la cabecera normal UDP, y de 1 a 9 bytes para la cabecera
RUDP). En la mayora de los casos, se tienen alrededor de 13 bytes en contraposicin a los 20 que
requiere TCP.
Qu pasa con la integridad de daros que proporciona TCP? Bueno, Falcon tiene mltiples
campos de tamao en los datos enviados para asegurar que no vas a CTD al recibir datos errneos.
Adems, tanto IP como UDP (y TCP por supuesto) tienen campos de checksum que aseguran que
los datos se transportan de forma correcta por el interfaz de red (tu tarjeta ethernet, MODEM, o lo
que sea).
As que al final, con RUDP, tienes la integridad de datos, transporte fiable, y acuses de recibo
de TCP, pero con ahorro de 3 a 11 bytes en cada paquete. Y de hecho, RUDP es un poco inexacto
en su implemetacin de los ACKs donde en vez de dar acuse de recibo a cada paquete, puede dar
acuse a un gupo de paquetes a la vez simplemente dando el nmero de secuencia del ltimo

paquete recibido en el ACK. Esto indica a la otra parte que ha recibido bien todos los paquete hasta
el nmero de la ltima secuencia y puede marcar esos paquetes como enviados de forma
satisfactoria. As puedes ahorrar ms ancho de banda.
Cual es la desventaja de RUDP? En general, RUDP no es tan robusto ni est tan probado
como la implementacin de TCP. Pero hace su trabajo bastante bien.
Esto nos lleva otra vez al comiezo. Sabemos que Falcon tiene dos formas de mandar paquetes,
UDP y RUDP. Ahora hay un delicado equilibrio en decidir qu mensajes se deben mandar como
UDP y cual en RUDP. No quieres que todos sean RUDP debido al ancho de banda extra necesario.
Pero no quieres que mensajes crticos se pierdan en la red porque se mandaron como un mensaje
UDP normal. Por ejemplo, el juego genera mensajes de radio (no los mensajes radiados entre
wingman y parecidos) como cuando uno de tu equipo (no necesariamente en tu paquete) muere y
oyes el ahhhhhhhhhhhhhhhhhhhhh. Esos mensajes no son crticos para la continuacin del juego
MP. Si los recibes, estupendo! Pero si no, el juego MP no se va a ver afectado por no or ese
sonido. En el lado opuesto, necesitas saber realmente si el misil que lanzaste alcanz el blanco y el
dao que hizo. Eso necesita ser RUDP. Pero hay casos especiales en los que hay que elegir
tambin entre RUDP y UDP. Por ejemplo, las actualizaciones de posicin son tan rpidas que
enviarlas en paquetes RUDP retrasara el proceso debido a los mensajes ACK. Para cuando
acusaras el recibo de un mensaje, podra estar obsoleto y con dos actualizaciones nuevas recibidas.
As que las actualizaciones de posicin se envan UDP no porque no sean importantes (que lo
son!) sino por la latencia que acarrean.
Y por encima de todo eso, hay otra clave en el equilibrio del MP del Falco. Para cada tipo de
protocolo (RUDP y UDP), existe la opcin de enviar inmediatamente el mensaje o ponerlo en una
cola. Los mensajes ahora se denominan tambin OOB (Out of Band) porque no solo se envan
tan rpido como sea posible sino que adems ignoran el ancho de banda disponible, queriendo esto
decir, que no se le hacen los test normales para ver si hay ancho de banda disponible.
And on top of all that, there is another key balancing act involved in Falcon MP. For each type
of protocol (RUDP and UDP), there is the choice of sending stuff immediately or putting it in a
queue. So you have UDP now, UDP queued, RUDP now, and RUDP queued. "Now" messages are
also refered to as "OOB" (Out of Band) messages because not only are they sent as soon as
possible, they also ignore the available bandwidth, meaning, they do not go through the normal
checks to see if bandwidth is available.
Aqui van algunos ejemplos:
UDP ahora Actualizacin de posiciones. Quieres tenerlos mandados inmediatamente y de
forma no confiable como se explic.
UDP en cola Algunos elementos de conexin que no es importante y pueden demorarse.
RUDP en cola Muchos de estos mensajes caen en esta categora. Tienes que ser enviados de
forma fiable pero no se necesitan inmediatamente.
RUDP ahora Pocos mensajes necesitan ser enviados de forma inmediata y fiable, como los
mensajes de seguimiento de misiles (o que te est siguiendo un misil bsicamente).
As que hay ms de una accin para equilibrar cuatro tipos de envo de mensajes. De los
cerca de ochenta tipos de mensajes en Falcon, el 75% se envan RUDP. Es una estimacin tosca.
Las actualizaciones de posicin son las mas usadas y siempre se envan UDP ahora. Pero en
realidad, estas actualizaciones son un caso especial. Se le hacen un nmero de pruebas distintas
para asegurarse que el ancho de banda no se va a exceder por mucho. As que en realidad, las
actualizaciones de posicin se envan de forma inmediata, pero su uso de ancho de banda se
chequea en un nivel ms alto en el cdigo. Es una materia complicada que excede el alcance de
este documento.
Espero que esto haya explicado en ms detalle qu es lo que ocurre durante un juego MP en
Falcon, y dnde se usa el ancho de banda y bajo qu circunstancias. Es un rea complicada y que
causa un alto grado de confusin. La belleza de Falcon es que el cdigo estaba muy adelantado a
su tiempo. La idea de las burbujas se est usando ahora en juegos en primera persona. Y sin lugar a
dudas el motor que usa el Unreal en multiplayer no es distinto que el que usa Falcon.
Mi agradecimiento a la experiencia de Hill, que me ayud considerablemente con este
artculo. Tambin agradecer a Schumi y RIK, cuyos esfuerzos en el cdigo de SP3 nos trajeron lo
que tenemos hoy.
"C3PO"
(Traducido por Adonis).