Como funciona o rollback netcode em jogos de luta
A técnica responde ao comando local antes de receber o dado do adversário e refaz a simulação quando a previsão falha, trocando atraso constante por correções pontuais.
R42 / RESUMO
Rollback netcode mantém a partida responsiva ao executar imediatamente o comando local e prever temporariamente a ação remota. Quando o dado verdadeiro chega, o jogo compara a previsão, restaura um estado anterior se necessário e ressimula os quadros até o presente. A técnica não elimina ping, jitter ou perda de pacotes; ela muda a forma como seus efeitos aparecem.
PONTOS-CHAVE
- O jogo não espera todo comando remoto antes de avançar: ele prevê a entrada ausente por alguns quadros.
- Se a previsão estiver errada, a simulação volta ao último estado correto e refaz os quadros com os dados reais.
- Determinismo, salvamento rápido de estado e ressimulação eficiente são requisitos centrais.
- Rollback reduz atraso percebido nos controles, mas não elimina ping, jitter, perda de pacotes ou Wi-Fi instável.
- Correções visuais podem aparecer como pequenos saltos, animações encurtadas ou efeitos que mudam após o fato.
Em uma partida local, apertar um botão e ver o golpe começar são etapas separadas por poucos milissegundos. Pela internet, o comando do adversário precisa atravessar a rede antes de chegar ao outro console ou computador. O rollback netcode não torna esse percurso instantâneo. Ele reorganiza a simulação para que o jogador não precise esperar o pacote remoto a cada quadro.
A ideia central é simples: o jogo executa imediatamente o comando local e, quando ainda não recebeu a entrada remota, faz uma previsão temporária. Em muitos momentos, a aposta mais provável é que o adversário continue fazendo o que já fazia no quadro anterior. Se o dado verdadeiro confirmar a previsão, nada precisa mudar. Se houver divergência, a partida volta a um estado salvo, aplica a entrada correta e calcula novamente os quadros seguintes até alcançar o presente.
Prever agora e corrigir depois
O modelo tradicional baseado apenas em atraso mantém as duas máquinas sincronizadas ao esperar os comandos necessários ou ao adicionar uma margem fixa antes de mostrar cada ação. Isso pode tornar o ritmo visual estável, mas transfere o custo da conexão diretamente para o controle: o botão parece responder tarde.
No rollback, o custo aparece de outra forma. O comando local responde mais perto do tempo de uma partida offline, enquanto erros de previsão podem surgir como um personagem que avança alguns pixels, uma animação que pula quadros ou um efeito que desaparece depois da correção. A técnica troca atraso constante por ajustes pontuais. Não é uma escolha entre “lag” e ausência de lag, mas entre maneiras diferentes de administrar informação que ainda não chegou.
Um exemplo em poucos quadros
Imagine que um lutador continua andando para a frente. Durante dois quadros sem receber novos dados, o jogo remoto prevê que ele manterá a direção. Se o comando real confirmar o movimento, a simulação segue. Se o jogador tiver apertado defesa, o sistema recupera o estado anterior, aplica a defesa e refaz aqueles quadros. Somente o resultado mais recente precisa ser exibido; os cálculos intermediários podem acontecer sem renderização completa.
Por que a técnica exige tanto do jogo
O GGPO, biblioteca criada especificamente para esse tipo de rede, descreve três necessidades fundamentais: a simulação deve ser determinística, o jogo precisa salvar e restaurar estados rapidamente e deve conseguir executar quadros de lógica sem desenhá-los. Determinismo significa que as mesmas condições iniciais e as mesmas entradas precisam produzir o mesmo resultado em todas as máquinas. Se uma delas arredondar física, aleatoriedade ou tempo de forma diferente, os estados podem se separar mesmo com comandos idênticos.
A ressimulação também consome processamento. Documentação da Unity alerta que conexões mais atrasadas podem exigir a repetição de vários ticks em um único quadro. Em um jogo de luta, isso afeta decisões de arquitetura: física, efeitos e sistemas auxiliares precisam distinguir o estado que define a partida da apresentação visual que pode ser reconstruída ou suavizada.
O que rollback não resolve
Rollback não apaga a distância física entre jogadores. Ping alto amplia a janela que precisa ser prevista; jitter faz o tempo de chegada variar; perda de pacotes atrasa ou elimina entradas; e uma conexão sem estabilidade pode exigir correções grandes demais. Bons sistemas limitam a quantidade de histórico, ajustam uma pequena parcela de atraso deliberado e podem interromper partidas quando a qualidade cai além do que a simulação consegue esconder.
Também é importante separar rollback de outras técnicas. Interpolação mantém movimentos remotos visualmente suaves ao exibir dados com uma pequena margem de atraso. Compensação de lag em jogos de tiro pode fazer o servidor consultar um estado anterior para avaliar um disparo. Elas compartilham a ideia de múltiplas linhas do tempo, mas não são sinônimos do ciclo de previsão, restauração e ressimulação popularizado pelo GGPO.
Como avaliar a experiência na prática
Uma boa implementação não se mede apenas pelo rótulo “rollback”. O tamanho das correções, a estabilidade da conexão, o matchmaking por região, o suporte entre plataformas e a capacidade do jogo de manter sua taxa de simulação influenciam o resultado. Um contador de quadros revertidos pode ajudar, mas não substitui métricas de ping, jitter e perda de pacotes.
A latência da rede também é apenas uma parte do caminho entre o botão e a imagem. Controle, lógica do jogo, fila de renderização e tela acrescentam seus próprios atrasos. A distinção é semelhante à explicada pela Rota42 ao mostrar por que mais quadros exibidos não reduzem automaticamente a latência. Rollback melhora a forma como uma partida lida com dados remotos, mas a sensação final continua dependendo de toda a cadeia.
Misael
Responsável pela apuração e redação desta matéria na Rota42.
R42 / FAQ
Rollback netcode elimina o lag?
Não. Ele reduz principalmente a sensação de atraso nos comandos ao prever entradas remotas e corrigir a simulação depois. Ping alto, jitter e perda de pacotes continuam existindo e podem produzir correções visíveis ou tornar a partida inviável.
Por que o rollback é comum em jogos de luta?
Porque lutas dependem de reações e comandos medidos em poucos quadros. Uma simulação determinística com poucos participantes também permite reconstruir o estado da partida a partir das entradas de cada jogador com relativa eficiência.
O que acontece quando a previsão do adversário está errada?
O jogo restaura um estado salvo anterior ao erro, aplica o comando remoto verdadeiro e ressimula os quadros seguintes. O jogador normalmente vê apenas o resultado atualizado, que pode incluir um pequeno salto visual.
Rollback netcode precisa de servidor dedicado?
Não necessariamente. O GGPO foi projetado para partidas ponto a ponto, mas previsão e rollback também podem existir em arquiteturas com servidor autoritativo. A topologia da rede e a técnica de correção são decisões relacionadas, porém diferentes.
Cabo de rede ainda faz diferença com rollback?
Sim. Uma conexão estável reduz jitter e perda de pacotes, tornando as previsões mais curtas e as correções menos frequentes. Rollback tolera melhor algum atraso, mas não transforma uma conexão instável em uma conexão boa.