StarCraft, o lendário RTS da Blizzard, sempre carregou uma peculiaridade técnica em seu modo multiplayer: o netcode baseado em lockstep. Esse modelo exige que cada jogador espere o comando do outro antes de avançar o estado do jogo, gerando um input delay perceptível que, em partidas competitivas, pode ser a diferença entre vitória e derrota. Agora, uma abordagem nascida nos fighting games – o rollback netcode – está sendo aplicada para eliminar esse atraso, transformando a experiência online do clássico e levantando questões sobre o futuro do gênero RTS.
O gargalo do lockstep: por que StarCraft sempre teve input delay
O sistema lockstep foi projetado para garantir sincronia absoluta entre todos os participantes de uma partida. Cada jogador executa as mesmas instruções na mesma ordem, e para isso o servidor espera receber os comandos de todos antes de avançar o frame. Esse mecanismo evita dessincronizações (desyncs), mas impõe um atraso fixo no input: enquanto um jogador move suas unidades após clicar, o jogo precisa aguardar o sinal dos demais. Em StarCraft, especialmente no Brood War, esse delay podia chegar a centenas de milissegundos em partidas com latência elevada, tornando micro-gerenciamento reativo praticamente impossível. A comunidade competitiva historicamente aceitou essa limitação, mas ela sempre foi um ponto cego no design online do RTS.
Rollback netcode: a filosofia que veio dos arcades
Nos jogos de luta, o rollback netcode popularizado por títulos como Street Fighter V e Guilty Gear Strive funciona de maneira oposta ao lockstep. Em vez de esperar, o sistema prediz o próximo estado do jogo com base nos inputs locais e exibe uma simulação imediata. Quando o comando real chega do oponente, o cliente corrige (“rollback”) os frames anteriores, ajustando a posição e a animação para o estado correto. A percepção para o jogador é de latência quase zero, pois o input never wait. O custo é computacional: o jogo precisa armazenar estados anteriores e ser capaz de reverter a simulação rapidamente. Em fighting games, onde o número de entidades é pequeno (dois personagens), o rollback é eficiente e já virou padrão para partidas online de qualidade.
Aplicando rollback em StarCraft: um salto técnico
Implementar rollback em um RTS com centenas de unidades simultâneas, fog of war, pathfinding complexo e interações em tempo real é um desafio muito maior. Os desenvolvedores precisam prever não só a posição de cada unidade, mas também decisões de IA, colisões e sincronia de produção. A solução encontrada foi adaptar o rollback para operar em chunks de frames (blocos de tempo), limitando o alcance da predição a intervalos pequenos (por exemplo, 4 frames). O sistema armazena checkpoints de estado do jogo a cada chunk e, ao receber inputs divergentes, aplica a correção apenas naquele bloco, recalculando o restante em background. Isso reduz drasticamente o input delay original sem sobrecarregar a CPU ou causar dessincronizações catastróficas.
Resultados práticos: fluidez competitiva
Testes realizados pela comunidade mostraram que a latência percebida caiu de aproximadamente 150 ms (em lockstep com ping de 50 ms) para menos de 30 ms, tornando viáveis ações como split de arquivos, micro-stutter de zerglings e cancelamentos de construção que antes eram penalizados pelo atraso. O rollback também elimina os “freezes” momentâneos que ocorriam quando um jogador com conexão instável atrasava o lockstep. Em contrapartida, o sistema exige mais poder de processamento local e largura de banda ligeiramente maior (cerca de 15% de tráfego extra para transmitir os estados de checkpoint).
Comparativo técnico: lockstep versus rollback em RTS
| Aspecto | Lockstep (StarCraft original) | Rollback adaptado |
|---|---|---|
| Sincronização | Espera todos os inputs antes do próximo frame | Prediz localmente e corrige ao receber inputs reais |
| Input delay (ping 50 ms) | ~120 ms (2 frames + latência de ida e volta) | ~20 ms (processamento local) |
| Vulnerabilidade a lag spikes | Congelamento do jogo para todos | Apenas correções visuais esporádicas |
| Complexidade de implementação | Baixa (modelo determinístico) | Alta (precisa de checkpoints de estado) |
| Requisitos de hardware | CPU modesta; largura de banda baixa | CPU mais potente; 10-15% mais tráfego |
O que isso significa para o futuro dos RTS online
A aplicação bem-sucedida do rollback netcode em StarCraft abre precedente para outros jogos do gênero. Títulos como Age of Empires II, Command & Conquer e até mesmo Warcraft III poderiam se beneficiar de uma abordagem semelhante, eliminando o delay histórico que sempre limitou o potencial competitivo online. A principal barreira é técnica: o custo computacional de reverter e reprocessar estados com centenas de entidades exige hardware moderno e otimizações de engine. Por outro lado, a experiência do jogador melhora dramaticamente. Em um cenário onde a latência zero nunca será alcançada, o rollback oferece a melhor aproximação prática para jogos de estratégia em tempo real, transformando partidas casuais e competitivas.
A decisão de adaptar uma tecnologia de fighting games para um RTS não é apenas uma curiosidade técnica: ela revela que o problema fundamental de sincronização online tem solução além do lockstep. O que antes parecia um limite inerente do gênero agora pode ser superado com engenharia bem aplicada. Se essa implementação for adotada oficialmente ou se tornar padrão em remasters e novos lançamentos, o cenário competitivo de RTS pode ganhar uma nova camada de velocidade e reatividade que há muito era desejada.
