{"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\/pt\/blog\/administrirovanie\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","title":{"rendered":"Mega pacote: como os desenvolvedores do Factorio resolveram o problema do multiplayer para 200 jogadores.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mega
\nEm maio deste ano, eu participei como jogador de um evento MMO chamado KatherineOfSky<\/a><\/noindex>. Notei que, quando o n\u00famero de jogadores atinge um certo limite, a cada poucos minutos, parte deles \"cai\". Felizmente para voc\u00eas (mas n\u00e3o para mim), eu fui um dos jogadores que desconectavam todas as vezes<\/b>, mesmo com uma boa conex\u00e3o. Eu encarei isso como um desafio pessoal e comecei a procurar as causas do problema. Ap\u00f3s tr\u00eas semanas de depura\u00e7\u00e3o, testes e corre\u00e7\u00f5es, o erro foi finalmente resolvido, mas essa jornada n\u00e3o foi t\u00e3o simples.<\/p>\n

Os problemas em jogos multiplayer s\u00e3o muito dif\u00edceis de rastrear. Geralmente, eles ocorrem em condi\u00e7\u00f5es de rede muito espec\u00edficas e em situa\u00e7\u00f5es de jogo bastante espec\u00edficas (neste caso, a presen\u00e7a de mais de 200 jogadores). E mesmo quando \u00e9 poss\u00edvel reproduzir o problema, n\u00e3o \u00e9 f\u00e1cil depur\u00e1-lo adequadamente, porque a inser\u00e7\u00e3o de pontos de controle interrompe o jogo, confunde os temporizadores e geralmente leva a uma desconex\u00e3o devido a tempo limite. Mas, gra\u00e7as \u00e0 persist\u00eancia e a uma ferramenta incr\u00edvel chamada clumsy<\/a><\/noindex> , consegui descobrir o que est\u00e1 acontecendo.<\/p>\n

Resumindo: devido a um erro e \u00e0 implementa\u00e7\u00e3o incompleta da simula\u00e7\u00e3o do estado de lat\u00eancia, o cliente \u00e0s vezes se encontrava em uma situa\u00e7\u00e3o onde precisava enviar, em um \u00fanico ciclo, um pacote de rede composto por a\u00e7\u00f5es de entrada do jogador envolvendo cerca de 400 entidades de jogo (n\u00f3s chamamos isso de \"megapacote\"). Ap\u00f3s isso, o servidor n\u00e3o s\u00f3 precisava receber corretamente todas essas a\u00e7\u00f5es de entrada, mas tamb\u00e9m envi\u00e1-las para todos os outros clientes. Se voc\u00ea tem 200 clientes, isso rapidamente se torna um problema. O canal para o servidor rapidamente se entope, resultando em perda de pacotes e um efeito cascata de pacotes solicitados novamente. O atraso nas a\u00e7\u00f5es de entrada leva ainda mais clientes a come\u00e7ar a enviar megapacotes, aumentando ainda mais a avalanche. Os clientes sortudos conseguem se recuperar, enquanto todos os outros \"caem\".
\n<\/a><\/noindex>
\n\"Mega
\nO problema era bastante fundamental e levei 2 semanas para resolv\u00ea-lo. \u00c9 bastante t\u00e9cnico, ent\u00e3o abaixo explicarei os detalhes t\u00e9cnicos complexos. Mas, para come\u00e7ar, voc\u00ea precisa saber que desde a vers\u00e3o 0.17.54, lan\u00e7ada em 4 de junho, a conectividade multiplayer se tornou mais est\u00e1vel em condi\u00e7\u00f5es de problemas temporais, e a oculta\u00e7\u00e3o de lat\u00eancias \u2014 muito menos bugada (menos engasgos e teletransportes). Al\u00e9m disso, mudei a forma de ocultar lat\u00eancias em combate e espero que, com isso, elas sejam um pouco mais suaves.<\/p>\n

Multiplayer Mega Pack \u2014 detalhes t\u00e9cnicos<\/h3>\n

\nSimplificando, o multiplayer do jogo funciona da seguinte maneira: todos os clientes simulam o estado do jogo, recebendo e enviando apenas a entrada do jogador (chamada de \"a\u00e7\u00f5es de entrada\", Input Actions<\/i>). A principal tarefa do servidor \u00e9 transmitir Input Actions<\/i> e controlar que todos os clientes realizem as mesmas a\u00e7\u00f5es em um ciclo. Mais detalhes podem ser lidos no post FFF-149<\/a><\/noindex>.<\/p>\n

Como o servidor deve decidir quais a\u00e7\u00f5es executar, a a\u00e7\u00e3o do jogador percorre aproximadamente este caminho: a\u00e7\u00e3o do jogador -> cliente do jogo -> rede -> servidor -> rede -> cliente do jogo. Isso significa que cada a\u00e7\u00e3o do jogador \u00e9 executada apenas ap\u00f3s fazer a viagem de ida e volta pela rede. Devido a isso, o jogo pareceria extremamente lento, portanto, quase imediatamente ap\u00f3s a introdu\u00e7\u00e3o do multiplayer, foi implementado um mecanismo de oculta\u00e7\u00e3o de lat\u00eancias. A oculta\u00e7\u00e3o de lat\u00eancias simula a entrada do jogador sem considerar as a\u00e7\u00f5es de outros jogadores e a tomada de decis\u00f5es do servidor.<\/p>\n

\"Mega
\nNo Factorio, existe o estado do jogo Game State<\/i> \u2014 \u00e9 o estado completo do mapa, do jogador, das entidades e de tudo mais. Ele \u00e9 simulado de forma determin\u00edstica em todos os clientes com base nas a\u00e7\u00f5es recebidas do servidor. O estado do jogo \u00e9 sagrado e, se alguma vez come\u00e7ar a diferir do servidor ou de qualquer outro cliente, ocorrer\u00e1 uma desincroniza\u00e7\u00e3o.<\/p>\n

Al\u00e9m de Game State<\/i> temos o estado de lat\u00eancias Latency State<\/i>. Ele cont\u00e9m um pequeno subconjunto do estado principal. Latency State<\/i> n\u00e3o \u00e9 sagrado e simplesmente representa uma imagem de como o estado do jogo parecer\u00e1 no futuro com base nas entradas do jogador. Input Actions<\/i>.<\/p>\n

Para isso, mantemos uma c\u00f3pia das a\u00e7\u00f5es criadas Input Actions<\/i> na fila de lat\u00eancias.<\/p>\n

\"Mega
\nOu seja, no final do processo, do lado do cliente, a imagem se apresenta aproximadamente assim:<\/p>\n

    \n
  1. Aplicamos Input Actions<\/i> todos os jogadores a Game State<\/i> de acordo com as a\u00e7\u00f5es de entrada que foram recebidas do servidor.<\/li>\n
  2. Removemos da fila de atrasos todos Input Actions<\/i>, que, segundo o servidor, j\u00e1 foram aplicados a Game State<\/i>.<\/li>\n
  3. Removemos Latency State<\/i> e o redefinimos para que ele apare\u00e7a exatamente como Game State<\/i>.<\/li>\n
  4. Aplicamos todas as a\u00e7\u00f5es da fila de atrasos a Latency State<\/i>.<\/li>\n
  5. Com base nos dados Game State<\/i> e Latency State<\/i> renderizamos o jogo para o jogador.<\/li>\n<\/ol>\n

    \nTudo isso se repete em cada ciclo.<\/p>\n

    Muito complicado? N\u00e3o se preocupe, ainda n\u00e3o acabou. Para compensar a instabilidade das conex\u00f5es de internet, criamos dois mecanismos:<\/p>\n