{"id":37812,"date":"2019-10-31T22:19:55","date_gmt":"2019-10-31T19:19:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov\/"},"modified":"2019-10-31T22:19:55","modified_gmt":"2019-10-31T19:19:55","slug":"megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","title":{"rendered":"Megapaquete: c\u00f3mo los desarrolladores de Factorio lograron resolver el problema del multijugador con 200 jugadores","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Megapaquete:
\nEn mayo de este a\u00f1o particip\u00e9 como jugador en el evento MMO KatherineOfSky<\/a><\/noindex>. Observ\u00e9 que cuando el n\u00famero de jugadores alcanza un cierto n\u00famero, cada pocos minutos, parte de ellos \"se desconectan\". Afortunadamente para ustedes (pero no para m\u00ed), yo fui uno de esos jugadores que se desconectaban cada vez<\/b>, incluso con una buena conexi\u00f3n. Lo tom\u00e9 como un desaf\u00edo personal y comenc\u00e9 a buscar las causas del problema. Despu\u00e9s de tres semanas de depuraci\u00f3n, pruebas y correcciones, finalmente se solucion\u00f3 el error, pero este viaje no fue nada sencillo.<\/p>\n

Los problemas en los juegos multijugador son muy dif\u00edciles de rastrear. Generalmente ocurren en condiciones muy espec\u00edficas de par\u00e1metros de red y en situaciones de juego muy concretas (en este caso, con m\u00e1s de 200 jugadores). Y incluso cuando se logra reproducir el problema, no se puede depurar adecuadamente, porque insertar puntos de control detiene el juego, confunde los temporizadores y generalmente conduce a una desconexi\u00f3n por tiempo de espera. Pero gracias a la perseverancia y a una maravillosa herramienta llamada clumsy<\/a><\/noindex> , logr\u00e9 averiguar qu\u00e9 estaba sucediendo.<\/p>\n

En resumen: debido a un error y a una implementaci\u00f3n incompleta de la simulaci\u00f3n del estado de latencia, el cliente a veces se encontraba en una situaci\u00f3n donde ten\u00eda que enviar en un solo ciclo un paquete de red que conten\u00eda las acciones de entrada del jugador para aproximadamente 400 entidades del juego (nosotros lo llamamos \"megapaquete\"). Despu\u00e9s de eso, el servidor no solo debe recibir correctamente todas esas acciones de entrada, sino tambi\u00e9n enviarlas a todos los dem\u00e1s clientes. Si tienes 200 clientes, esto r\u00e1pidamente se convierte en un problema. El canal hacia el servidor se congestiona r\u00e1pidamente, lo que provoca p\u00e9rdida de paquetes y un torrente de solicitudes de paquetes repetidos. La demora en las acciones de entrada provoca que a\u00fan m\u00e1s clientes comiencen a enviar megapaquetes, y su avalancha se vuelve a\u00fan m\u00e1s intensa. Los clientes afortunados logran recuperarse, los dem\u00e1s \"se desconectan\".
\n<\/a><\/noindex>
\n\"Megapaquete:
\nEl problema era bastante fundamental, y me tom\u00f3 2 semanas resolverlo. Es bastante t\u00e9cnico, as\u00ed que a continuaci\u00f3n explicar\u00e9 algunos detalles t\u00e9cnicos jugosos. Pero primero, necesitas saber que desde la versi\u00f3n 0.17.54, lanzada el 4 de junio, en condiciones de problemas temporales de conexi\u00f3n, el multijugador se volvi\u00f3 m\u00e1s estable y la ocultaci\u00f3n de latencias es mucho menos problem\u00e1tica (menos retardos y teletransportes). Adem\u00e1s, he cambiado la forma de ocultar las latencias en combate y espero que gracias a eso sean un poco m\u00e1s suaves.<\/p>\n

Detalles t\u00e9cnicos del megapaquete multijugador<\/h3>\n

\nSimplificando, el multijugador en el juego funciona de la siguiente manera: todos los clientes simulan el estado del juego, recibiendo y enviando solo la entrada del jugador (denominada \"acciones de entrada\", Input Actions<\/i>). La tarea principal del servidor es la transmisi\u00f3n Input Actions<\/i> y el control de que todos los clientes realicen las mismas acciones en un mismo ciclo. Puedes leer m\u00e1s al respecto en el post FFF-149<\/a><\/noindex>.<\/p>\n

Dado que el servidor debe tomar decisiones sobre qu\u00e9 acciones realizar, la acci\u00f3n del jugador sigue un camino aproximadamente as\u00ed: acci\u00f3n del jugador -> cliente de juego -> red -> servidor -> red -> cliente de juego. Esto significa que cada acci\u00f3n del jugador se ejecuta solo despu\u00e9s de realizar este recorrido de ida y vuelta a trav\u00e9s de la red. Debido a esto, el juego podr\u00eda parecer incre\u00edblemente lento, por lo que casi inmediatamente despu\u00e9s de la aparici\u00f3n del multijugador en el juego se introdujo un mecanismo de ocultaci\u00f3n de latencias. La ocultaci\u00f3n de latencias simula la entrada del jugador sin tener en cuenta las acciones de otros jugadores y las decisiones del servidor.<\/p>\n

\"Megapaquete:
\nEn Factorio, hay un estado del juego Game State<\/i> \u2014 este es el estado completo del mapa, del jugador, de las entidades y de todo lo dem\u00e1s. Se simula de manera determinista en todos los clientes basado en las acciones recibidas del servidor. El estado del juego es sagrado, y si alguna vez comienza a diferir del servidor o de cualquier otro cliente, se produce una desincronizaci\u00f3n.<\/p>\n

Adem\u00e1s Game State<\/i> tenemos un estado de latencias Latency State<\/i>. Contiene un peque\u00f1o subconjunto del estado principal. Latency State<\/i> no es sagrado y simplemente representa una imagen de c\u00f3mo se ver\u00e1 el estado del juego en el futuro basado en la entrada del jugador. Input Actions<\/i>.<\/p>\n

Para esto, almacenamos una copia de las acciones creadas Input Actions<\/i> en la cola de latencias.<\/p>\n

\"Megapaquete:
\nEs decir, al final del proceso, del lado del cliente la imagen se ve m\u00e1s o menos as\u00ed:<\/p>\n

    \n
  1. Aplicamos Input Actions<\/i> todos los jugadores a Game State<\/i> de la misma manera que estas acciones de entrada fueron recibidas del servidor.<\/li>\n
  2. Eliminamos de la cola de retrasos todos los Input Actions<\/i>, que, seg\u00fan los datos del servidor, ya se hab\u00edan aplicado a Game State<\/i>.<\/li>\n
  3. Eliminamos Latency State<\/i> y lo reiniciamos para que se vea exactamente como Game State<\/i>.<\/li>\n
  4. Aplicamos todas las acciones de la cola de retrasos a Latency State<\/i>.<\/li>\n
  5. Con base en los datos Game State<\/i> y Latency State<\/i> renderizamos el juego para el jugador.<\/li>\n<\/ol>\n

    \nTodo esto se repite en cada ciclo.<\/p>\n

    \u00bfDemasiado complicado? No se relaje, esto a\u00fan no es todo. Para compensar la falta de fiabilidad de las conexiones a Internet, hemos creado dos mecanismos:<\/p>\n