Carta dos Desenvolvedores: Melhorias no Desempenho do Servidor - PubgBR
Principal Notícias Carta dos Desenvolvedores: Melhorias no Desempenho do Servidor
Carta dos Desenvolvedores: Melhorias no Desempenho do Servidor
Hoje estamos compartilhando alguns dos avanços que fizemos para melhorar significativamente o desempenho do servidor, bem como melhorias adicionais que estamos trabalhando atualmente.
Atualização: As melhorias detalhadas nesta carta de desenvolvimento também são aplicáveis à versão Xbox do PUBG. Especificamente a adição do Net Send Flush foi feita no Game Preview Update #17 e o Replication Interleaving System foi aplicado na atualização mais recente, a Atualização do Game Preview #18.
No Dev Letter de hoje, gostaríamos de compartilhar alguns dos avanços que fizemos para melhorar significativamente o desempenho do servidor, bem como as melhorias adicionais que estamos trabalhando atualmente.
A versão do Unreal Engine que o PUBG usa atualmente é baseada em um modelo cliente-servidor e, portanto, o status de cada ator (objetos colocados em níveis que representam caracteres, edifícios, cenários, câmeras etc.) deve ser atualizado através do servidor para cada jogador.
O desempenho do servidor é geralmente indicado pelo tick rate do servidor ou pelo Frame Time. À medida que o desempenho do servidor aumenta, o tempo por quadro diminui. À medida que o tempo por quadro diminui, o Tempo de Resposta do Servidor também melhora.
Quanto mais rápido o servidor responde, mais rápido suas ações ações/movimentos são atualizados para outras pessoas. Por exemplo, com que rapidez você desaparece da tela do seu oponente depois de se esconder atrás de uma parede. Se quisermos reduzir o que é comumente conhecido como dessincronização, o Tempo de Resposta do Servidor precisa ser melhorado.
Melhorias através da atualização 14
A estrutura do processo de rede antes da atualização #14 e delivery
Antes da Atualização 14, a rede foi processada no servidor no Unreal Engine, conforme mostrado abaixo.
Vamos primeiro explicar o fluxo de processo de rede acima. No estágio "Net Dispatch", o pacote recebido do cliente é processado no servidor. Por exemplo, você recebe informações como Gunfire, Movement, etc. As coisas que são processadas durante essa etapa geralmente são distribuídas para outros clientes de duas formas: RPC (Remote Procedure Calls) e Replication. Depois disso, a lógica do jogo, como a Physics Simulation, é processada durante o estágio "Simulate & Render" e o resultado é entregue a todos os clientes via "Net Flush".
No entanto, quando os RPCs são enviados como resultado do processo do Net Dispatch, eles não são enviados imediatamente, mas enfileirados no buffer. As muitas coisas armazenadas no buffer são enviadas para todos os clientes durante o estágio "Net Flush" e o buffer é então esvaziado.
Nesta estrutura, o RPC tem que passar pelo estágio "Simulate & Render" para ser entregue de "Net Dispatch" para "Net Flush" e, portanto, causa um atraso. Talvez o Unreal Engine tenha sido estruturado dessa maneira para minimizar o número de pacotes entregues ao UDP. Independentemente disso, quando o número de pacotes é minimizado, a rede funciona de forma mais eficiente.
A nova estrutura de processo de rede e melhorias
Decidimos que melhorar o tempo de resposta do servidor era mais importante do que diminuir o número de pacotes para o PUBG. Portanto, a equipe redesenhou a estrutura conforme mostrado abaixo na Atualização #14. A equipe adicionou um estágio "Net Send Flush" antes do estágio "Simulate & Render".
No estágio "Net Send Flush", todos os dados UDP armazenados no buffer serão enviados e o buffer será esvaziado. Através deste novo fluxo, o tempo usado para "Simular e renderizar" não é mais necessário, diminuindo o tempo de atraso. Durante a fase Net Send Flush, não há cálculos abrangentes para a replicação do ator e os dados UDP pendentes são liberados.
Como há duas atualizações de rede, "Net Send Flush" e "Net Flush", na nova estrutura, a taxa de atualização da rede dobrou após a Atualização # 14, o que levou algumas pessoas a supor que o tick rate do servidor aumentou. No entanto, não foi a taxa de transmissão do servidor, mas a taxa de atualização de rede que saltou para 60 de taxa de transmissão conforme outra atualização de rede é entregue durante o processamento do Server Tick.
Estes resultados podem ser encontrados em Update Netcode Analysis de Battle (Non) Sense. Como você pode ver na tabela abaixo, quando 40 pessoas estão vivas, o atraso médio de tiroteio é reduzido de 94,5 ms para 77 ms (queda de 18%).
Melhorias para a atualização nº 19
Perfis de resultados antes da atualização 19 e uma nova hipótese
Dados do perfil antes do PC Update #19, medido quando 90 jogadores estão vivos em 25 de junho de 2018 é a seguinte.
O tempo de descarga líquida é 43.2 mseg, 41% do tempo total do frame. Grande parte desse tempo é usada para "serializar", a fim de replicar cada ator para o cliente. "Serializar" é um processo de gravação de dados em uma ordem na memória para entregar o status do ator ao cliente através da rede.
Como estávamos procurando o método de otimização com base no resultado de criação de perfil acima, pensamos "se conseguirmos reduzir o número de atores replicados, especialmente os caracteres, o tempo total de liberação líquida diminuirá significativamente".
Ao contrário de outros jogos que usam um servidor dedicado no Unreal Engine, até 100 jogadores jogam simultaneamente em um jogo no PUBG, o que significa que o número de atores é significativamente maior. O grande tamanho dos dados dos atores é uma questão, mas o grande volume de atores é o maior problema. Enquanto pensávamos em maneiras de reduzir o número total de atores, pensamos em replicar personagens distantes com uma frequência menor ajudaria. Como os personagens distantes não são relevantes a essa distância, o número de atores serializados pode ser bastante reduzido sem afetar o modo de jogar e, como resultado, o tempo do Net Flush pode ser reduzido.
Processo de desenvolvimento: sistema de intercalação de replicação
A partir da ideia acima, chegamos a uma conclusão para implementar um sistema que ignore as solicitações de replicação para uma frequência mais apropriada com base na distância do cliente e do ator. Chamamos isso de sistema de "Intercalação de replicação". Primeiro, retiramos a seção onde os atores são replicados e diminuímos as frequências de replicação de caracteres distantes. Em seguida, analisamos os problemas e os tipos de alterações visuais.
Uma vez que pudemos resolver os problemas que ocorreram quando a frequência de replicação foi reduzida, testamos até onde iríamos e chegamos à conclusão de que baixar as frequências de replicação para ¼ do nível original ainda não tinha impacto no jogo.
O sistema de Intercalação de replicação concluído foi implementado da seguinte forma:
-Decida quantos quadros de replicação serão ignorados, dependendo da distância
– Execute uma das três etapas: a etapa 1 pula 1 quadro, a etapa 2 pula 2 quadros e a etapa 3 pula 3 quadros.
Depois de implementar o sistema, nossa equipe de controle de qualidade testou para encontrar o valor de distância apropriado para cada etapa. Os resultados do teste mostraram que pular 3 quadros causou nervosismo no movimento do personagem, então removemos a etapa 3. O valor aplicado para cada etapa era agora o seguinte:
-Etapa 1: ignore 1 quadro nos caracteres localizados a mais de 70 m
-Etapa 2: Ignore 2 quadros nos caracteres localizados a mais de 400 m
(Nota: Este é o status a partir de hoje, e este valor pode mudar no futuro para melhor desempenho do servidor e movimentos mais suaves)
O desempenho do servidor aumentou 20% depois que o novo sistema foi implementado. No diagrama abaixo, rastreamos a taxa de quadros de um servidor da região de NA quando 85 jogadores estavam vivos. Após a atualização, o tick rate do servidor aumentou em 22% de 18,5 para 22,9. Outras regiões também apresentaram uma média de aumento de 20% na taxa de quadros.
O que é ainda melhor é a alteração que ocorreu no tempo de resposta.
Na tabela acima, você pode ver que quando 85 jogadores estão vivos, o tempo médio de atraso para o tiroteio caiu 58%, de 149.4ms para 61.6msec, o que indica que o problema conhecido como dessincronização melhorou significativamente.
Por meio de outras melhorias, além do Interleaving de Replicação, o tick rate do servidor aumentou em 20% e o atraso da rede caiu 50% quando mais de 80 jogadores estão ativos.
Melhorar o tick rate do servidor desde o lançamento do PUBG tem sido uma prioridade constante para a equipe. Além de resolver problemas de software, melhorias também foram feitas no hardware. No entanto, sabemos que não houve melhorias notáveis ​​nos jogadores nos últimos meses antes da Atualização #19.
Durante o FIX PUBG, dobramos a melhora no desempenho do servidor e continuamos pesquisando e experimentando várias ideias, mas esse processo é demorado.
Para implementar uma única função, uma pesquisa preliminar deve ser feita e, após a implementação da função, é necessário um grande volume de análises, verificações e testes. É difícil resolver todos os problemas em um curto período de tempo, porque o esforço e o tempo devem ser investidos constantemente em cada problema. A implementação incorreta de novos recursos pode causar problemas maiores. Portanto, novos recursos devem ser implementados e aplicados com o maior cuidado possível.
Dito isso, depois de aplicar as melhorias sobre as quais já falamos, agora estamos trabalhando na otimização do estágio de "Envio de Rede" do processo. De acordo com nossa análise, a maior parte do tempo é consumida no processamento de movimentação de caracteres, e nós identificamos algumas oportunidades para otimizá-lo. O movimento de personagens tem um alto impacto no jogo PUBG. Portanto, essa tarefa requer muita atenção cuidadosa para garantir que quaisquer melhorias feitas não afetem o modo como os personagens se movem de uma forma anormal, como o jittering descrito acima.
Já estamos experimentando algumas idéias e estamos antecipando o tempo necessário para que o estágio "Dispatch de Rede" caia mais de 50% dos atuais 41,8 ms se essas ideias não precisarem ser modificadas pelo que encontramos durante o processo de teste . Espera-se que a estabilização do recurso após a implementação de novas ideias demore mais de um mês, mas continuaremos a trabalhar rapidamente e implementar isso o mais rápido possível.
O objetivo final é manter sempre o tick rate do servidor em 30, de 100 jogadores para o último marcador. Continuaremos a trabalhar arduamente para alcançar este objetivo, para que possamos continuar a proporcionar a melhor experiência Battle Royale possível para todos vocês.