Como funciona o Apex: imersão profunda nos servidores e Netcode

[EA_Mari]

O engenheiro-chefe de Apex Legends, Ricklesauceur, explora problemas online comuns, suas causas e nossos esforços para resolvê-los.

---

INTRODUÇÃO

Olá, sou @ricklesauceur , engenheiro chefe do Apex Legends e hoje quero oferecer a você um pouco de ideia sobre a infraestrutura online que oferece suporte ao Apex Legends.

No passado, não falávamos publicamente sobre servidores, Netcode ou infraestrutura online para Apex Legends, e hoje queremos começar a mudar isso. Resumindo, hoje queremos:

• Compartilhar um pouco sobre como estamos trabalhando para melhorar sua experiência online no Apex Legends
• Reconhecer e explicar alguns problemas comuns de conectividade que você pode encontrar ao jogar Apex
• Abordar especificamente as perguntas mais frequentes sobre tópicos como servidores em câmera lenta, registro de ocorrências e como nosso sistema de compensação de atraso funciona
• Oferecer algumas notas abrangentes sobre a taxa de serviço do nosso servidor e explicar nosso pensamento por trás do que isso pode ou não afetar

Um aviso: esta postagem é longa porque pretende ser um verdadeiro mergulho na infraestrutura online do Apex Legends - algo que vimos alguns jogadores solicitarem há muito tempo. 

Estamos pensando nisso como o ponto de partida de uma conversa mais longa, então, embora anglobamos muito terreno aqui, provavelmente há muitos tópicos (ataques DDOS! Bugs de travamento de servidor! Etc.!) em que poderíamos gastar mais tempo. 

Com certeza, se você gosta deste blog, diga-nos sobre o que gostaria de ouvir na próxima vez, e nós continuaremos.

Para aqueles que estão prontos para saber mais sobre Netcode, servidores, tickrate e muito mais ... bem-vindo! Vamos começar falando sobre algumas melhorias recentes que lançamos.

---

MELHORANDO NOSSO TEMPO DE RESPOSTA COM MÉTRICAS DE DESEMPENHO

Na Temporada 6, introduzimos a exibição de desempenho. Ela serve para você obter informações básicas sobre o seu desempenho.

"In" e "out" são os dados de internet consumidos pelo jogo (em kB/s). Também aparece a latência (em milissegundos). A perda e redução de pacotes são representados em porcentagem de pacotes por segundo.

Esses números ajudam você (e nós) a compreender sua experiência ao jogar. Em outras palavras, podemos traduzir o que você sente em informações técnicas e úteis.

Antes disso, as pessoas diziam que "alguma coisa" estava errada, mas não conseguiam ser mais específicos que isso. Agora, você pode dizer com precisão "Tenho 10% de perda de pacotes, 300 ms de latência" etc. Isso muda tudo porque esses números geralmente são o melhor indicador possível do que está acontecendo. Daqui a pouco falo mais disso.

Enquanto estávamos trabalhando na exibição de desempenho, também começamos a acompanhar as métricas essenciais de desempenho para quem joga e servidores. Isso significa que, se alguém reportar problemas, podemos pegar a partida e ver os dados de todo mundo no jogo no momento, incluindo informações sobre o servidor específico que hospeda o jogo.

Esse foi o primeiro passo para dar meios personalizados e direcionados de investigação à nossa equipe. Tivemos alguns sucessos com essa abordagem, mas achamos que isso não funciona bem a longo prazo. Primeiro, precisamos ouvir você, depois despachar um engenheiro para ver de onde vem o problema, e depois (dependendo do problema) nós buscamos uma solução.

Nas temporadas recentes, começamos a usar a nossa incrível equipe de ciência de dados para coletar e analisar uma semana de dados ao mesmo tempo para detectar perda excessiva de pacotes e erros de desempenho de servidor. Essa abordagem já está funcionando. Por exemplo, descobrimos que um equipamento de rede no nosso centro de dados estava defeituoso, fazendo com que todos os jogos hospedados em alguns servidores tivessem desempenhos de rede horríveis. Os servidores estavam funcionando, mas o hardware que conectava as pessoas aos servidores em questão estava causando perda massiva de pacotes. Encontramos vários exemplos assim.

O principal benefício que temos ao analisar dados sistematicamente é que isso nos permite cruzar métricas e as pessoas para descobrir padrões. Então, semana após semana, podemos dizer com confiança se o estado da nossa frota de servidores melhorou ou piorou. A análise de dados também é uma ótima ferramenta para ajudar nossos parceiros a corrigir problemas quando é algo fora do nosso controle. Em vez de dizer que algo está errado, podemos dizer "essa coisa específica está errada", o que economiza tempo para todas as pessoas envolvidas. (Aliás, você pode optar por não fazer isso, se quiser. Basta ir até "Jogabilidade" e depois "Compartilhamento de Uso" no menu de configurações.)

Então a automação ajuda bastante. Mas não é suficiente.

De fato, com essa abordagem, ainda somos um pouco lentos para reagir aos problemas. Precisamos esperar uma semana para que a maioria dos dados seja coletada e reportada com confiança, então pode levar ainda mais uma semana para realizar uma investigação completa. A partir do momento que você começar a notar problemas, pode demorar até duas semanas para encontrar uma solução e ainda mais para implementar a solução caso seja necessária uma atualização de servidor.

Podemos ser melhores. Vamos ser melhores. Então, vamos falar sobre as soluções.

Antes de tudo, além do nosso relatório semanal, chegamos a um sistema de alerta em tempo real. Isso nos dará o mesmo nível de informação que temos agora, mas muito mais rápido. Vamos poder resolver problemas de hardware imediatamente ou começar a investigar e trabalhar em um patch. Nós entendemos a frustração de ter que esperar e tentamos diminuir consideravelmente o tempo entre um alerta e uma solução.

Em segundo lugar, vamos introduzir uma nova ID de servidor exclusiva ("SID") para a exibição de desempenho que nos permitirá encontrar o servidor no qual você está jogando mais rápido. Atualmente, você nos informa uma hora e data e nós consultamos os dados que temos sobre você para encontrar o servidor no qual você estava jogando. Logo não teremos mais que fazer isso.

Esperamos que ambas as soluções acima comecem a ser implantadas durante a nossa próxima temporada, Apex Legends: Legado. O resultado para quem joga será uma resolução de problemas de servidor mais rápida, às vezes duas vezes mais rápida do que é no momento.

UMA IMERSÃO PROFUNDA DOS PROBLEMAS COMUNS

Agora, para a parte divertida, vamos categorizar de maneira ampla os problemas de servidor que você pode encontrar. A lista abaixo não é completa, mas espero que responda a maioria das suas perguntas.

O servidor está em câmera lenta.

Nossos servidores estão funcionando a 20Hz. Isso significa que eles simulam o estado do mundo inteiro uma vez a cada 50 ms (1 segundo - ou 1.000 ms - dividido por 20).

Não falamos sobre FPS (quadro por segundo) ao discutir o desempenho do servidor porque um servidor não exibe imagens. Em vez disso, um servidor calcula “estados”, mas o princípio subjacente é o mesmo. Ele recebe as entradas do usuário (da rede), executa a física, envia de volta o novo estado do mundo aos clientes e, em seguida, repete. Se esse processo leva mais de 50 ms de forma consistente, seu jogo ficará lento para permitir que o servidor termine a simulação. Assim, você obtém servidores em câmera lenta.

Visão do tempo de quadros de um servidor. A coluna 5 é o alvo de 50ms. Tudo abaixo é mais rápido. Você pode ver que este servidor está estável e mais rápido do que o necessário.

Em comparação, este servidor nunca atingiu o tempo de quadros e estava rodando com quase 200ms (ou seja, 4 vezes mais lento). Exemplo típico de um servidor em câmera lenta.

Há várias coisas que podem causar isso, mas às vezes o problema ocorre por causa de máquinas no centro de dados que não estão funcionando como deveriam. Pense em uma CPU em underclock, superaquecimento etc.

Quando detectamos problemas assim, normalmente removemos essas máquinas. Isso significa que literalmente ligamos para o provedor de serviço, explicamos o problema com a máquina e pedimos para eles a tirarem do ar.

A solução de detecção em tempo real explicada anteriormente nessa publicação deve reduzir consideravelmente esse problema quando for lançada na próxima temporada. Estamos muito determinados a solucionar esse problema, então vamos ficar de olho.

Minha latência está aumentando e diminuindo.

Se você joga com conexão sem fio, não há muita coisa que possamos fazer! Caso contrário, latência com mudanças drásticas pode às vezes ser um problema de desempenho do nosso servidor.

Todos nós sabemos que, mesmo se um jogo normalmente é executado a 60fps, isso pode mudar quando acontece muita coisa na tela. Mesmo que você só esteja perdendo alguns quadros, você perceberá. Funciona de forma similar nos servidores. Aqui, a detecção automática não ajuda muito a encontrar a raiz do problema. Até então, tivemos que recriar as condições da lentidão num servidor de teste, mas isso demora bastante e é sempre meio que um tiro no escuro. Sua máquina provavelmente não roda no mesmo hardware do servidor, e nem com as mesmas configurações, por isso é difícil reproduzir tudo de maneira exata.

Felizmente, nossa equipe de operações criou uma ferramenta para nos permitir obter o que chamamos de arquivo RPROF. Isso é basicamente uma visão do que o servidor está fazendo durante cada quadro (simulação balística, rede de entrada e saída, movimentos de quem joga etc). Graças aos arquivos RPROF, conseguimos saber o que desacelera as coisas para que um engenheiro possa otimizar. Geralmente, o problema tem a ver com exigências de desempenho aumentadas introduzidas pelos recursos novos que chegam temporada após temporada.

Você deve se lembrar, por exemplo, da lentidão da tela de Campeão no início do jogo durante as Temporadas 7 e 8. Isso ocorria porque todo mundo na partida surgia no mesmo lugar e até mesmo sobrepondo entre si. (E não dava para ver por causa da interface!) As simulações de física odeiam quando objetos se sobrepõe a outros e o nosso simulador estava tentando afastar todos os corpos uns dos outros, causando picos enormes de CPU no servidor.

Porcentagem de partidas afetadas por um servidor com desempenho lento (não necessariamente em câmera lenta) por regiões. Você pode ver que algumas regiões ficam melhores com o tempo e outras piores (o eixo X é o tempo).

Uma visão detalhada da região oeste dos EUA que nos permite detectar máquinas com defeito (o eixo X é o tempo). As quedas são muito nítidas nos gráficos. Algumas máquinas são afetadas, enquanto outras permanecem estáveis.

Esperamos que o nosso uso de arquivos RPROF nos ajude a otimizar os novos recursos que adicionamos ao jogo e reduza a latência de maneira geral no futuro. Reduzir a latência para todo mundo é um objetivo importante para nós, e ferramentas melhores como essa são essenciais para nos ajudar a alcançá-lo. 

Eu tenho muita perda/redução de pacotes.

Essa é extremamente difícil. Provavelmente a culpa não é sua, mas geralmente ela também não é nossa!

Isso tem a ver com a forma como o tráfego da internet vai da sua caixa até o nosso centro de dados e volta para você. No começo, seu tráfego de rede está na sua rede de ISP. Seu provedor pode estar tendo uma queda no qual suas informações, junto com as informações de outros clientes, estão sendo perdidas/desconectadas. Isso faz com que o cliente do jogo não saiba o que está acontecendo com jogadores e jogadoras ao seu redor ou com o servidor do jogo, não sabendo que você quer atirar ou se mover em uma certa direção. Também há a conexão entre a rede do seu ISP e nossa rede. Podem ocorrer problemas em qualquer ponto desse caminho.

Quando as coisas correm tranquilamente, chamamos esse processo de "peering". Muitas vezes, problemas de peering ocorrem quando uma conexão entre duas redes é fraca. Pode haver múltiplos saltos como esse ao longo do caminho. E, é claro, todas as informações dos servidores de Apex precisam voltar até você, muitas vezes tomando uma rota diferente. Você já deve estar entendendo por que isso é complexo.

Para resolvermos isso, a primeira coisa a fazer é ser capaz de detectar onde está o problema. Isso é difícil de automatizar, pois precisamos de dados seus e do servidor, para que possamos olhar a situação de ambas as "perspectivas" e tentar investigar o caminho para encontrar o problema.

A partir de hoje, pedimos a vocês para fornecer algum tipo de rastreamento de rede e fazemos o mesmo do nosso lado no centro de dados para tentar detectar onde está o ponto de congestionamento. Isso é extremamente demorado e lento para resolver porque, dependendo das nossas descobertas, temos que negociar com parceiros diferentes de negócios no mundo todo. Esperamos que a automação ajude a melhorar esse processo e que tenhamos algumas melhorias nos trabalhos que ainda estão nos estágios iniciais.

Quando se trata de problemas de tráfego de rede, como esses que estamos discutindo, uma coisa boa é que os problemas tendem a acontecer em volume em vez de serem vinculados a um indivíduo específico. Isso significa que corrigir o problema de alguém geralmente soluciona muitos outros. Também reduzimos ativamente a largura de banda usada pelo jogo, o que ajuda a reduzir o problema.

Esse é um rastreador de rede (mostrando latência) de alguém da nossa equipe que joga profissionalmente, do modem da sua internet para um dos nossos servidores. Nós analisamos várias vezes para avaliar o estado verdadeiro da conexão à internet. Você pode ver que é capaz de jogar na melhor condição com latência de 31ms. Mas na pior fica em torno de 522ms. Então, nesse caso, a experiência de jogo dele é extremamente ruim porque sua conexão oscila com uma diferença de 500ms. A conexão está um pouco afetada na sua rede local de ISP, mas a média mostra que é rara (uma média de 31ms com o pior em 264ms, deve ser um incidente isolado.) Mas depois vemos uma latência entre o ISP local e o ISP1, que é um dos pontos entre quem joga e o nosso servidor de jogo. Então podemos supor que há problemas de perda de pacotes e roteamento entre os dois. Está fora do nosso controle, mas podemos informar os parceiros sobre esse problema. Geralmente é do interesse de todos resolver a situação.

Me eliminam enquanto estou atrás de uma porta/parede, e às vezes eu volto para a minha posição anterior.

Esse é um tópico importante. Tem a ver com compensação de lag.

Em todos os jogos desde o início dos jogos online, o principal problema para os desenvolvedores resolverem é como simular a ação em tempo real em algo que não funciona em tempo real. Essencialmente, tudo que você faz em jogos online está atrasado devido à latência do servidor e da volta. Muitas coisas resultam nisso: entradas, renderização e, sim, até a tickrate do servidor.

E o pior disso tudo é que seus oponentes, quase que certamente, joga com um nível de latência diferente do seu. Para resolver isso, nossos servidores têm que olhar constantemente não só o que está acontecendo para você e seu oponente no momento, mas também o que estava acontecendo nas suas perspectivas no momento em que vocês dois enviam suas ações. Compensação de lag é a arte de mesclar experiências um pouco diferentes em uma realidade compartilhada.

Não há uma solução perfeita. Não existe uma verdade. No fim das contas, o servidor é uma espécie de máquina do tempo. O estado do mundo constantemente volta para ver se seu disparo acertou alguém e então atualiza o mundo para todos de acordo.

Para ilustrar melhor este princípio, meu colega Earl Hammon escreveu um pouco sobre justiça e compensação de lag e como tudo isso funciona no Apex Legends. Vou compartilhar com vocês abaixo:

Vamos passar por vários cenários com duas pessoas em Apex Legends chamadas de ALTA e BAIXA. Vamos dar um ping de 300ms para ALTA e um ping de 50ms para BAIXA. A diferença nos pings deles é de 250ms.

O que acontece se elas atirarem uma na outra ao mesmo tempo? Bem, o disparo de BAIXA vai chegar ao servidor muito antes do disparo de ALTA, então BAIXA tem a vantagem.

O que acontece se uma delas virar em um canto e elas se depararem uma com a outra? Bom, BAIXA também tem a vantagem aqui. BAIXA está menos "no passado", então ela vê ALTA primeiro. Mais uma vez, BAIXA tem a vantagem devido ao ping. Isso aumenta a vantagem das balas de BAIXA chegarem ao servidor mais rápido.

Esses casos são "injustos" no sentido de que BAIXA tem uma vantagem, mas são "justos" no sentido de que é razoável esperar que a pessoa com ping mais baixo tenha a vantagem nessa situação.

Agora, o que acontece se BAIXA estiver atrás de uma parede para se proteger? Bem, ALTA ainda está no passado, quando BAIXA não está coberto, então ALTA pode atirar em BAIXA antes que ela se proteja, mas BAIXA não vai saber disso até que os pacotes de ALTA tenham passado para o servidor e depois chegarem até BAIXA. A esta altura, BAIXA vê que está segura e, mesmo assim, foi atingida. Na perspectiva de BAIXA, isso é bobagem.

Porém, isso é exatamente simétrico para algumas das bobagens anteriores que eram vantagem para BAIXA! Quando BAIXA sai da cobertura para atacar ALTA, BAIXA pode ver e disparar em ALTA enquanto ALTA acha que BAIXA ainda está se escondendo. Do ponto de vista de ALTA, isso também é bobagem, ser atingido por alguém que estava escondido. Essas bobagens não podem ser eliminadas, transferidas apenas entre uma pessoa ou outra, por causa da simples realidade que o ping é real e que as pessoas possuem pings diferentes.

Alguns sugerem que é injusto para BAIXA que ALTA possa atirar nele enquanto BAIXA acha que ele está escondida. A alternativa sugerida é que o ALTA deve compensar pelo seu ping alto sozinha. Isso exigiria que implementamos uma forma desigual e assimétrica de latência.

É ruim levar um tiro quando você acha que está atrás da cobertura por causa de ping ruim, que é o que pode acontecer com BAIXA. Também é ruim levar um tiro de alguém antes que você possa ver a pessoa por causa de ping ruim, que é o que pode acontecer com ALTA. Mas essas bobagens são distribuídas simetricamente.

Queremos que fique tudo bem claro: Nem todos os jogos online funcionam da mesma forma que o Apex. Alguns jogos sempre dão vantagem a quem joga com ping mais baixo, mas nós optamos por não fazer isso com o nosso sistema. É uma postura que assumimos intencionalmente após olharmos para os prós e contras e pensar seriamente sobre justiça na competição online.

Para explicar nosso sistema de forma simples, quem joga com ping baixo nem sempre têm vantagem sobre quem joga de ping alto e, às vezes, vivenciam bobagens (para nós, esse é um termo técnico).

Isso é um troca que é projetada intencionalmente para o nosso sistema. Mas a vantagem é que você pode jogar Apex Legends relativamente bem, mesmo se tiver uma latência maior que a média, o que é muito importante para quem joga do interior ou para quem joga em regiões onde a conectividade é instável. Acreditamos que devemos reduzir as "bobagens" a cada oportunidade, mas quando temos que lidar com experiências menos ideais, queremos fazer isso de uma forma igual e justa para todo mundo.

Esse é o motivo para que, quase toda vez que você lida com uma bobagem como levar um tiro através de uma parede ou ser atingido ao virar uma curva, isso provavelmente ocorre devido a uma variação inevitável de latência entre quem joga e a forma como o nosso sistema a distribui. Ainda assim, nos comprometemos a reduzir isso a cada oportunidade que recebermos. Além de querermos que todo mundo tenha uma experiência justa, também queremos que todo mundo se divirta.

Alguns dos meus disparos não são registrados.

Vamos falar sobre registro de disparos. Um "sem reg" ou falta de registro de um disparo significa que você acha que atingiu seu alvo, mas o servidor discorda. Da sua perspectiva, você tem todos os tipos de confirmação na forma de gotas de sangue e sons, mas nenhum contador de dano aparece. Em um jogo de tiro como Apex Legends, isso é extremamente desagradável.

Isso pode acontecer por vários motivos. Às vezes, a latência alta ou perda de pacotes pode fazer a sua simulação local ficar um pouco fora de sincronia com o servidor. Você disparou onde viu alguém, mas na verdade estava atirando onde a pessoa estava antes. Infelizmente, você só vai descobrir quando sua versão do mundo voltar.

Às vezes, é apenas um erro na simulação de física do jogo. Para você ter resposta instantânea, contamos com um conceito chamado previsão. Ao atirar, nós sabemos a balística da arma, então podemos prever para onde a bala está indo localmente sem precisar que o servidor lhe diga. Isso faz o jogo ser mais responsivo.

Normalmente, o cliente e o servidor concordam, e a bala vai para onde foi prevista. No passado, tivemos alguns bugs tinham com o modo como computávamos armas e trajetórias de projétil (para todas as armas com tamanho de projétil que não eram um ponto, como fuzis de precisão, por exemplo). Esse tipo de erro pode ser difícil de detectar, então colocamos um visual para os nossos testes de jogo para ajudar as pessoas a identificarem o problema imediatamente. Infelizmente, esse código de diagnóstico é muito pesado para ser executado no jogo ao vivo (por causa da largura de banda), então só podemos confiar em nossos testes internos.

Toda vez que um disparo não é registrado, nós desenhamos a caixa de acerto e a trajetória da bala (aproximadamente, a trajetória deve curvar um pouco). É uma ajuda visual para sabermos o que aconteceu e nos ajudar quando olharmos os registros dos nossos servidores.

Há duas maneiras de progredir aqui:

A primeira é investigar constantemente os diferentes erros que resultam em problemas de detecção de acertos. Também estamos desenvolvendo ferramentas para automatizar a detecção, para que possamos ajudar os desenvolvedores a não ter que fazer outras. Isso será um esforço contínuo de nossa parte.

A segunda é trabalhar com você! Quando vocês nos enviam vídeos de problemas de detecção de acertos em ação, isso pode nos ajudar a descobrir se há um erro que precisamos resolver. Muitas vezes, nós percebemos que os clipes que recebemos realmente têm a ver com um problema de latência em vez de um problema de detecção de acertos, então não deixe de verificar sua tela de desempenho antes de reportar um problema desse tipo. Porém, como mencionamos acima, nós encontramos e resolvemos os bugs dessa forma no passado, então as denúncias podem nos ajudar a melhorar o jogo para todo mundo. Agradecemos desde já!

E quanto a erros que me impedem de fazer login, como "code:net?"

"Code:net" é uma mensagem de erro genérica que é exibida sempre que o seu jogo perde conexão com o servidor. Isso pode ser causado por diversos problemas, tanto da parte quanto da sua. Na verdade, descobrimos que a maioria dos bugs code:net mais sérios (e erros relacionados, como code:leaf etc.) pode ter mais a ver com os serviços da Respawn que suportam o jogo que pode precisar ser investigado.

Nós tomamos algumas medidas para reduzir a probabilidade de ocorrer um code:net na rede e muitas pessoas podem resolver a situação após entrar em contato com a nossa equipe de suporte. Se você não consegue fazer login e está recebendo o a mensagem code:net ou algo do tipo, considere reportar o problema no site de Ajuda da EA.

Como code:net é uma mensagem genérica, pode se referir a diversos problemas diferentes. Tivemos sucesso nas últimas semanas para resolver alguns desses problemas, mas sabemos que ainda temos mais a fazer. Reporte problemas para nós e faremos o melhor que podemos para resolvê-los o mais rápido possível. Pode acreditar, nós odiamos esse bug tanto quanto vocês.

TICKRATE NO SERVIDOR

Aí vem o grande problema. Queremos enfrentá-lo de forma transparente. Muitas pessoas perguntam sobre a tickrate dos nossos servidores e por que não simplesmente a aumentamos a partir de 20Hz, como alguns outros jogos de tiro online.

Explicamos como as taxas impactam a taxa de atualização geral do que você vê na tela, por isso essa pergunta é totalmente válida. Porém, é mais difícil do que você imagina comparar as tickrates de um jogo com outro. Vamos tentar explicar por quê.

A tickrate de um servidor é o número de simulações que o servidor executa por segundo. É um número fixo (veja a seção sobre câmera lenta). Apex usa um modelo de replicação instantâneo. Isso significa que, ao final de cada tick, o servidor salva o estado do mundo e o reproduz em todos os clientes. Isso inclui muitas informações que permitem que o design das nossas armas, mapas e Lendas seja da mais alta fidelidade.

Para ganhar no Apex Legends, é preciso prestar atenção em um monte de informações acontecendo por todo o mapa. Habilidades táticas sendo usadas, ou passidas sendo ativadas, ou supremas sendo ativadas, ou cápsulas de suprimento chegando, ou um novo esquadrão entrando dentro do alcance do drone do Crypto. Não queremos que vocês percam nada disso. E nossos designers podem criar brinquedos e ferramentas que são realmente globais em natureza. Muitos jogos não computam estados do mundo inteiro em cada tick, fazendo com que seja desonesto tentar comparar um jogo com outro com base em um único dado, como "20Hz" vs. "30Hz".

A pergunta é: o que está acontecendo exatamente durante cada tick? Queremos que o estado do mundo seja o mais preciso possível, e é por isso que nossos servidores salvam o estado do mundo inteiro a cada tick. Se não fosse por isso, provavelmente pouparia alguns custos da CPU em nossos servidores, mas perderíamos precisão nas nossas simulações, e isso não vale o risco.

Simplificando, quanto maior a tickrate, maior será a largura de banda enviada a todo mundo. Se a gente fosse passar de um servidor de 20Hz para um servidor de 60Hz, isso significaria triplicar a largura de banda que o jogo usa. Atualmente, o Apex Legends consome aproximadamente 60kB/s no começo de um jogo. Um servidor de 60Hz consumiria 180kB/s. Isso pode não parecer muito, mas é bem complicado, e estamos sempre buscando maneiras de reduzir a largura de banda necessária.

Mas por que importaria se a largura de banda fosse um pouco maior? Manter os custos de largura de banda baixos para jogos é muito mais importante do que, digamos, para transmissões de vídeo. Para aplicativos com largura de banda alta (transmissões, download etc), atrasos e problemas são fáceis de mascarar com o buffer de uma transmissão, reduzindo a qualidade de transmissão etc. Provavelmente você não vai encontrar atrasos em um download e provavelmente não se importa que a velocidade varie por alguns segundos ou até centenas de milissegundos.

Jogos não têm esse luxo. Pular até dois intervalos de 50ms pode começar a ser ruim. Pular um pouco mais pode significar que você vai receber atualizações cada vez maiores para recuperar o tempo. Não existe nenhuma exceção para não enviar essas atualizações para você, pois seu jogo precisa de um estado do mundo perfeito para ser preciso.

O exemplo acima mostra como a comparação de tickrate entre jogos é complicada, porque as informações contidas em cada tick variam. Também há outra complicação, que é que os limites das entradas que os servidores podem receber e enviar não são sempre os mesmos, mesmo se têm a mesma tickrate. Para ser específico: em muitos jogos, se um servidor é executado a 60Hz, significa que o cliente só pode enviar entradas de 60Hz. Se você roda o jogo em 60 fps, não tem problema, mas se seu jogo for executado a 120fps, você perde metade das suas entradas. Não é o caso em Apex Legends. Nós processamos tickrates bem. (Como resultado, quanto maior for o seu fps, maior será o seu uso de largura de banda.)

Certo, então nós discutimos algumas possíveis desvantagens que vêm com o aumento da tickrate. Mas e a vantagem de ir de 20Hz a 60Hz? Vamos, ressurja! Isso não deixaria os servidores três vezes mais rápidos e três vezes melhores? É só fazer!

Com base em nossas descobertas, isso não resultaria em uma experiência significativamente diferente, e queremos explicar por quê.

Vamos supor que você tenha uma média de cerca de 50ms de ping, ou latência. Lembre-se de que seu ping mede a velocidade de uma viagem completa entre o seu computador e o servidor. Então, supondo que não haja outros problemas como latência oscilante ou lag de hardware (como a tela apresentando atraso de 20 a 50ms), o servidor receberá seus dados de 25ms (metade do ping) depois de apertar um botão ou mover o mouse.

Como nossos servidores são de 20Hz, eles atualizam o estado do mundo a cada 50ms (1.000ms em cada segundo / 20 ticks por segundo = 50ms por tick). Então, na pior das situações, suas entradas serão processadas pelo servidor após 75ms (25ms + 50ms).

Para descobrir o que esse atraso de 75ms realmente significa em termos de experiência, você precisa pensar na sua taxa de quadros. A matemática aqui pode ficar difícil, mas lembre-se que em um jogo de 60 fps, cada frame leva cerca de 16,67ms (1.000ms em cada segundo / 60 fps = 16,67ms por frame). Se os seus dados estão sendo processados pelo servidor depois de 75ms, como no nosso exemplo acima, e o seu jogo estiver sendo executado em 60fps, significa que o lag entre os seus dados e seu impacto no jogo é de cerca de cinco frames (75ms para cada atualização / 16,67ms por frame = cerca de 4.5 frames, arredonde para 5 frames, já que não existe meio-frame).

Se fizer todos os mesmos cálculos acima para um servidor de 60Hz, você obterá 41,67ms para atraso máximo entre a entrada e o servidor a processando (ping de 25ms + [1.000ms / 60 ticks por segundo = 16,67ms por tick] = 41,67ms).

41,67ms certamente é melhor que 75ms, mas o que isso significa na taxa de quadros? Vamos assumir novamente que estamos rodando a 60fps. Cada frame leva 16,67ms, então agora o lag entre suas entradas e o servidor as reconhecendo é de cerca de três quadros (41,67ms para cada atualização / 16,67ms por frame = cerca de 2,5 quadros, arredonde para 3 frames, já que não existe meio-frame).

Juntando toda essa matemática, você percebe que servidores de 20Hz resultam em cerca de cinco quadros de atraso, e servidores de 60Hz resultam em três quadros de atraso. Portanto, para triplicar os custos de largura de banda e da CPU, você pode economizar dois quadros de latência no melhor cenário. A vantagem está lá, mas não é enorme, e não faria nada para problemas que estão atrelados ao bom e velho lag (como ser atingido ao se esconder), problemas a nível de ISP ou bugs (como registro de acerto e servidores lentos).

Nosso exemplo examinou as vantagens de ir de 20Hz para 60Hz. Você pode fazer os cálculos de outros saltos, como de 20Hz a 30Hz ou até 40Hz, e vai descobrir que os ganhos de taxa de quadros seriam bem pequenos. Seria preciso aumentar a tickrate drasticamente antes de começar a senti-la. Até mesmo o salto de 20Hz para 60Hz seria como a diferença entre 58fps e 60fps. Essa diferença não é nada, mas acreditamos sinceramente que não é o suficiente para priorizar mudanças na tickrate em relação a outras melhorias mais eficientes que poderíamos fazer.

CONCLUSÃO

Queremos concluir confirmando algo que é a frustração real e genuína que os problemas online causam para quem joga. Lidar com lags, falta de registro de acertos, ou servidores lentos, é um saco. Isso te tira do jogo e pode ser desmotivador para você quando está tentando avançar no jogo, ou fazer jogadas decisivas com amigos e amigas ou apenas relaxar à noite.

Parte do desafio sobre falar sobre problemas online é que quando começamos a explicar nossos sistemas, ou nossa posição sobre problemas como compensação de lag ou tickrates, pode ser muito frustrante para quem joga e que só quer que o jogo seja melhor. Se tiver problemas com latência, bugs que travam o servidor, problemas de corrupção de contas ou qualquer outro desafio que você possa enfrentar enquanto joga Apex Legends, você provavelmente não quer saber do que não estamos fazendo.

No fim das contas, só queremos tornar o jogo melhor. Quanto melhor for a experiência online para você, mais pessoas jogarão, o que nos permite continuar fazendo o trabalho que amamos.

É por isso que, em todo este blog, compartilhamos algumas melhorias que estamos seguindo no futuro próximo, incluindo:

• Alertas em tempo real que nos permitirão identificar problemas e responder mais rapidamente
• Ferramentas para identificar servidores para que possamos remover e substituir rapidamente servidores problemáticos
• Focar em servidores em câmera lenta: remover servidores problemáticos é um passo, mas nosso objetivo é tornar isso drasticamente menos comum com alterações de códigos
• Redução da latência com otimização melhor dos novos recursos
• Corrigindo erros de recuperação de acerto e construindo ferramentas de detecção automatizadas para nos ajudar a evitar ter que criar ferramentas novas

Mas queremos que você saiba que essas não são as únicas coisas que estamos fazendo. Estamos trabalhando com parceiros desde o nível do servidor até o nível de ISP para melhorar e investir na nossa infraestrutura online, com o objetivo final de ver vocês relatarem menos problemas e uma experiência geral melhor. Pretendemos falar mais sobre esses esforços em uma publicação futura, quando começarmos a ver esses esforços dando resultados.

Nossa esperança é que, se começarmos a nos comunicar mais com vocês sobre os problemas que nos preocupam, começaremos a compartilhar ter mais abertura para falar sobre as raízes dos problemas que estamos resolvendo. É por isso que escrevemos esta publicação. Esperamos que isso explique nosso pensamento e desmistifique as questões técnicas da execução de um jogo de tiro online. E esperamos que este seja o início de mais conversas no futuro.

Obrigado por ler! 

- Samy e a equipe de Apex Legends