Tickrate do servidor versus sendrate do cliente em FPS competitivos: Atraso de interpolação, arquiteturas sub-tick e a vantagem do peeker (Peeker's Advantage)

Introdução: A física invisível dos jogos de tiro competitivos

Em jogos de tiro em primeira pessoa de alto nível competitivo — como Counter-Strike 2, Valorant, Rainbow Six Siege e Overwatch 2 —, confrontos diretos são rotineiramente decididos em frações de 15 a 50 milissegundos. É comum presenciar situações em que um adversário surge correndo em uma quina e elimina o defensor antes que este sequer veja a arma do rival ser erguida, ou situações opostas em que o jogador recua com sucesso para trás de uma parede de concreto e tomba morto um instante depois.

Esses acontecimentos raramente decorrem de ilusões de ótica ou de disparidades na velocidade biológica de reação. Trata-se, na realidade, de desfechos matemáticos determinados pelo modelo cliente-servidor, pela latência de propagação de pacotes na rede, pelos buffers de interpolação de entidades no cliente e pelos algoritmos de compensação de lag no servidor.

Com a transição dos motores gráficos de sistemas clássicos de taxa fixa (como servidores de 64-Tick e 128-Tick) para arquiteturas modernas baseadas em sub-tick com marcação de tempo em microssegundos, compreender o funcionamento dessa infraestrutura é indispensável para eliminar gargalos de conexão e dominar a física do peeker's advantage.

Anatomia do ciclo de rede: Tickrate do servidor, sendrate do cliente e snapshots globais

A sincronização de rede em jogos multijogador opera em um ciclo periódico discreto, e não em uma escala de tempo analógica contínua:

[Fila de entrada local]         [Taxa de envio Sendrate]          [Tickrate do servidor]
 Comandos de teclado e mouse ──> Pacotes UDP UserCmd (128Hz) ──> Simulação de física global (128Hz)
                                                                    │
                                                                    ▼
                                                            Envio de snapshot do mundo
                                                                    │
                                                                    ▼
                                                         [Buffer do cliente defensor]
                                                         Interpolação de entidades (cl_interp)

1. Tickrate do servidor

O tickrate do servidor corresponde ao número de vezes por segundo em que o servidor dedicado recalcula o estado lógico e físico da partida:

• 64-Tick (15.625 ms por tick): Comum em filas de pareamento público. Trajetória de projéteis, caixas de colisão e posições de jogadores são atualizadas a cada 15.625 milissegundos.
• 128-Tick (7.8125 ms por tick): Padrão absoluto em campeonatos profissionais e plataformas de alta fidelidade (como FACEIT e Valorant). Reduzir o intervalo pela metade aprimora o registro de tiros e a consistência do recuo.

2. Sendrate e updaterate do cliente

• Sendrate: A frequência com que o cliente do jogador empacota as ações locais (movimentação, mira do mouse e cliques) em pacotes UDP direcionados ao servidor.
• Updaterate: A frequência com que o cliente recebe os snapshots do mundo enviados pelo servidor, contendo posições de entidades, níveis de vida e eventos do mapa.

Se o jogo opera a 240 FPS locais em um servidor de 64-Tick, os quadros gráficos gerados entre as atualizações de rede dependem de predição no cliente (client-side prediction) para evitar travamentos visuais.

Interpolação de entidades (cl_interp): Por que você sempre enxerga o passado

Os pacotes UDP transmitidos pela internet não chegam em intervalos perfeitamente homogêneos. A variação de latência (jitter) faz com que pacotes se aglomerem ou cheguem fora de ordem. Para garantir que outros personagens se desloquem na tela com fluidez contínua, os motores de jogo aplicam a Interpolação de Entidades (cl_interp).

Snapshots recebidos do servidor: [Tick 100] ------------> [Tick 101] ------------> [Tick 102]
                                     │                        │
Linha do tempo de renderização:      └── (Exibindo o passado) ┴── Posição na tela do defensor
                                         <-- Atraso de interpolação -->

1. O buffer de interpolação: O cliente retém propositalmente os dados recebidos de outros jogadores por uma janela temporal preestabelecida antes de projetá-los na tela (configurada classicamente por cl_interp_ratio / cl_updaterate).
2. Impacto temporal do buffer: Em um servidor de 128-Tick com ratio 1, o atraso de interpolação é de 7.8125 ms; em um servidor de 64-Tick com ratio 2, o retardo sobe para 31.25 ms.
3. A ilusão indispensável: Ao avistar um adversário atravessando uma porta, você não está presenciando sua posição física em tempo real, mas sim uma projeção matemática interpolada entre dois estados históricos registrados dezenas de milissegundos atrás.

A física do Peeker's Advantage: Decomposição matemática

A "vantagem do peeker" (peeker's advantage) define a janela temporal em que um atacante em movimento ao abrir uma quina consegue visualizar e reagir contra um defensor estático antes que o monitor do defensor exiba a chegada do agressor.

Equação da janela de vantagem

A vantagem líquida obtida pelo atacante que abre o ângulo pode ser expressa matematicamente pela seguinte soma de latências:

$$\text{Janela de Peeker's Advantage} = \frac{\text{RTT}{\text{atacante}}}{2} + \frac{\text{RTT}{\text{defensor}}}{2} + \text{BufferInterp}{\text{defensor}} + \text{IntervaloTick}{\text{servidor}} + \text{AtrasoMonitor}_{\text{defensor}}$$

Tomando como base um cenário competitivo comum:

• Ping do atacante: 30 ms (Tempo de transmissão unidirecional = 15.0 ms)
• Ping do defensor: 30 ms (Tempo de transmissão unidirecional = 15.0 ms)
• Intervalo de tick do servidor (64-Tick): 15.6 ms
• Buffer de interpolação do defensor: 15.6 ms
• Latência de processamento e tela do defensor: 5.0 ms

Linha do tempo ao abrir um ângulo:
T = 0.0 ms: O atacante abre a quina localmente (visão instantânea do defensor parado).
T = 15.0 ms: O pacote de movimentação do atacante alcança o servidor do jogo.
T = 30.6 ms: O servidor processa o próximo tick e registra as coordenadas do atacante.
T = 45.6 ms: O snapshot do mundo alcança o roteador do defensor.
T = 61.2 ms: O cliente do defensor esgota o buffer de interpolação e inicia a renderização.
T = 66.2 ms: Os pixels do atacante são finalmente exibidos no monitor do defensor.

Vantagem temporal líquida do atacante: ~66.2 milissegundos.

Nesses 66 milissegundos, o atacante já processou a imagem do defensor estático em seu córtex visual, alinhou a mira e disparou antes que o primeiro fóton do seu modelo atinja os olhos do defensor.

Arquiteturas Sub-Tick versus ticks discretos fixos (CS2 e Valorant)

A criação da arquitetura Sub-Tick pela Valve no motor Source 2 (Counter-Strike 2) buscou fornecer precisão extrema de registro de tiro sem a necessidade de manter clusters dedicados puramente em 128-Tick.

[Tick discreto tradicional (64/128-Tick)]
Limite de tick N ─────────────────────────── Limite de tick N+1
       │                                            │
       └── Clique no meio do intervalo ─────────────┘ (Processado apenas em N+1)

[Arquitetura Sub-Tick]
Limite de tick N ─────────────────────────── Limite de tick N+1
       │                                            │
       └── Clique ocorre em T+4.2ms (Marca de tempo em microssegundos)
           O servidor retrocede a física para T+4.2ms exatos na validação

Ticks discretos fixos (ex: Valorant 128-Tick)

Em sistemas puramente discretos a 128-Tick, o mundo se move em blocos homogêneos de 7.8125 ms. Disparos executados entre dois ticks são consolidados e resolvidos no início do tick subsequente. Como o intervalo entre ticks é mínimo, o erro de quantização temporal não ultrapassa 7.8 ms.

Arquitetura Sub-Tick (Counter-Strike 2)

O sub-tick desacopla o momento da ação do ciclo de envio dos pacotes:

1. Marcação temporal precisa: Ao disparar, o cliente insere um registro temporal em microssegundos no pacote de comando, indicando exatamente quando o gatilho foi acionado.
2. Validação histórica determinística: O servidor processa os dados em sua taxa de tick normal, mas ao calcular o traçado da bala, ele rebobina as hitboxes dos adversários para o microssegundo exato assinalado no pacote.
3. Divergência entre lógica e imagem: Como os quadros de animação e os dados de rede continuam atrelados aos snapshots regulares de tick, nas versões inaugurais os jogadores notavam uma sensação de que a morte do adversário ocorria um quadro após o disparo.

Compensação de lag, limites de retrocesso e a morte atrás do cover

Nada frustra tanto os jogadores quanto tombar eliminado após já ter recuado com folga para trás de uma barreira impenetrável. Essa ocorrência decorre diretamente do mecanismo de Compensação de Lag (Lag Compensation) do servidor.

[Estado real do defensor: Já protegido atrás da parede em T_atual]
                    Parede
       Defensor ── [ Parede ]
                    Parede

[Tela do atacante de alto ping: Mirando no rastro do defensor em T_histórico]
Visão atacante:     O defensor ainda aparece exposto devido ao atraso de transmissão
Ação do servidor:   Lê a marca temporal e rebobina a hitbox para T_histórico -> Tiro validado!
Consequência:       O defensor cai morto atrás do cover em T_atual.

1. Rebobinamento de hitboxes: No instante em que o agressor atira, o servidor recupera as coordenadas históricas de todos os personagens no momento em que o atacante os avistava e checa se a mira coincidia com a hitbox.
2. Janela de corte de retrocesso (Rewind Clamp): A fim de impedir que usuários com pings exorbitantes (como 400 ms) acertem alvos segundos após sua ocultação, os servidores travam a compensação em uma janela limite (em geral, 200 ms).
3. O dilema inevitável: Sem compensação de latência, qualquer jogador precisaria mirar à frente do alvo com base em seu próprio ping, anulando o tiro intuitivo. A compensação viabiliza a mira direta, mas transfere o ônus da latência para o defensor na forma de mortes atrás de paredes.

Matriz de diagnóstico de netcode e otimização de rede

Dominar a dinâmica dos jogos de tiro competitivos vai muito além da precisão do mouse, exigindo o domínio das leis físicas de transmissão de dados. Apoiados nas análises técnicas aprofundadas do 365Finds, os jogadores podem calibrar suas conexões, tirar o máximo proveito do peeker's advantage e anular armadilhas posicionais intrínsecas ao modelo cliente-servidor.

Referências

• Source Multiplayer Networking - Valve Developer Community
• Networking Overview for Unreal Engine - Epic Developer Community
• Windows Sockets 2 - Win32 apps | Microsoft Learn
• IETF RFC 7567: IETF Recommendations Regarding Active Queue Management