Construindo um mundo aberto no navegador, parte 3: Os spikes discretos que nos salvaram

Por Oleg Sidorkin, Diretor de Tecnologia e Cofundador da Cinevva

Chegou agora? Consulte o guia da série. Ele explica o que é um spike e traz links para todas as partes.

Esta parte tem menos capturas de tela chamativas e mais segurança arquitetural.

Depois dos Spikes 1 e 2, fizemos três verificações de risco que pareciam pequenas, mas tiveram impacto no produto.

A primeira foi a distribuição de broadcasts com Durable Objects. Testamos a distribuição das posições de vários clientes em frequências de atualização semelhantes às de um jogo e monitoramos a distribuição de latência, o uso de CPU por atualização e a integridade das entregas. Se isso tivesse falhado, teríamos adotado o particionamento antecipado em vez de manter uma única instância responsável por cada ilha.

A segunda foi a validação das restrições de dispositivos móveis. Não um preset para desktop renomeado como mobile, mas um perfil explicitamente de baixo custo, baseado no mesmo terreno de referência.

Abrir o perfil para dispositivos móveis em uma nova aba ↗ · Ver código-fonte

Reduzimos a densidade de segmentos, a quantidade de objetos, a pressão sobre a resolução de renderização e o alcance da névoa. A pergunta era simples: este mundo pode continuar legível e responsivo sob as restrições típicas de dispositivos móveis sem que seja necessário reescrever todo o renderizador?

A terceira foi a confiabilidade da geração de comportamentos para os fluxos de trabalho dos criadores. Avaliamos a taxa de JSON válido, a correção semântica em relação às primitivas esperadas e a latência de resposta. Se isso tivesse falhado, teríamos adotado uma criação de comportamentos estritamente baseada em formulários.

A principal conclusão deste capítulo é que esses spikes discretos mudaram a arquitetura mais rapidamente do que os spikes visuais. Eles estabeleceram limites rígidos para a topologia de rede, as promessas para dispositivos móveis e a UX das ferramentas.

Na parte 4, voltamos ao trabalho visível com o terreno e testamos o comportamento do streaming durante o movimento, não apenas capturas de tela do carregamento estático.

Tecnologias mencionadas neste capítulo

Cloudflare Durable Objects. Instâncias serverless com estado, implantadas na borda, com persistência integrada e suporte a WebSocket. Cada Durable Object mantém o estado autoritativo de um shard (ou chunk) do mundo. Os jogadores se conectam via WebSocket e recebem broadcasts das posições dos outros jogadores no mesmo shard. Quando o jogador se move para um chunk adjacente, ele se conecta ao Durable Object desse chunk. Os Durable Objects persistem automaticamente o estado em disco e podem escalar para milhares de instâncias simultâneas. Consulte a documentação dos Cloudflare Durable Objects e nosso guia de tecnologias 3D para navegadores sobre redes multijogador.

Particionamento espacial. Divisão do mundo entre instâncias de servidor por região geográfica. Cada shard controla uma área retangular da grade do mundo. Conforme a densidade de jogadores muda, os shards podem ser divididos ou combinados. Jogadores próximos ao limite de um shard veem o conteúdo de ambos os shards por meio de consultas de visibilidade entre shards. É assim que o EVE Online comporta milhares de jogadores em um único universo.

Distribuição de broadcasts via WebSocket. Distribuição de atualizações de posição em tempo real de um servidor para vários clientes conectados. A largura de banda downstream por cliente aumenta linearmente de acordo com o número de jogadores visíveis:

$$B_{\text{client}}=N_{\text{visible}}\times b_{\text{player}}$$

Em frequências de atualização semelhantes às de um jogo (20–30 Hz), cada jogador gera $b_{\text{player}}\approx 800$ bytes/segundo de dados de posição. Portanto, 200 jogadores visíveis custam $200\times 800=160$ KB/s por cliente. O custo da abordagem ingênua de todos para todos no servidor é pior, crescendo como $N^2$. É exatamente por isso que a filtragem por relevância (gerenciamento espacial de interesse) limita $N_{\text{visible}}$ antes de enviar os dados para cada conexão dentro do orçamento de cada atualização. Consulte nosso guia de redes para conhecer as diferenças entre compressão delta e frequência de atualização.

Restrições de renderização em dispositivos móveis. As GPUs de dispositivos móveis têm de 1/5 a 1/10 do desempenho das GPUs de desktop, um limite de memória de aproximadamente 1 GB (em comparação com 2–4 GB no desktop) e redução térmica de desempenho sob carga prolongada. Um perfil de qualidade para dispositivos móveis reduz a densidade de segmentos, a quantidade de objetos, a resolução de renderização, a distância de visualização e a qualidade das sombras. O objetivo não é alcançar paridade com o desktop, mas manter a legibilidade e a responsividade. Consulte os números de desempenho 3D em navegadores para ver benchmarks reais de GPU.

---

Parte 3 de 12.
Anterior: Parte 2 — Física em Worker e o receio de atraso nos comandos
Próxima: Parte 4 — Streaming antes de terrenos sofisticados
Guia da série: /pt-BR/blog/2026-02-25-open-world-browser-series-guide