O que realmente é necessário para criar um mundo aberto em um navegador
Por Mariana Muntean, CEO da Cinevva
A equipe da Cinevva acaba de publicar um dos diários de engenharia mais transparentes da história recente do desenvolvimento de jogos: uma série em 12 partes que documenta nossa tentativa de criar um mundo aberto multijogador que roda inteiramente no navegador. Sem download. Sem loja de aplicativos. Apenas uma URL.
O projeto abrangeu 24 experimentos técnicos que chamamos de "spikes" — protótipos curtos e focados, cada um projetado para responder a uma única questão de alto risco. Cada spike foi publicado com código-fonte funcional que você pode abrir e executar em seu navegador agora mesmo. A série foi escrita por Oleg Sidorkin, CTO e cofundador da Cinevva, e parece menos uma peça de marketing e mais um diário de campo vindo da linha de frente do que os navegadores realmente conseguem fazer em 2026.
O que torna a série interessante — mesmo que você nunca pretenda criar sistemas de terreno — é o método por trás dela. É um estudo de caso sobre como reduzir os riscos de um projeto ambicioso antes de assumir qualquer compromisso caro.
Começando pela pergunta mais difícil
A maioria dos projetos de mundo aberto morre seguindo uma sequência previsível. Primeiro, surge um conceito bonito. Depois, uma cena atraente. Então você descobre que o orçamento de frame já foi totalmente consumido antes mesmo de existir jogabilidade.
Nossa equipe inverteu a ordem. O primeiro spike era deliberadamente feio: uma malha de terreno de 512 metros, 500 objetos instanciados, ruído procedural de altura, um plano de água e neblina. Sem sombras, sem etapa de embelezamento. A única pergunta era se um navegador conseguiria manter uma taxa de quadros estável enquanto a câmera se movia pelo cenário.
Conseguiu. E esse "sim" estabeleceu algo que Oleg chama de "contrato de referência" — um custo de referência medido para uma cena mínima, em relação ao qual todos os recursos posteriores precisariam se justificar. Se um novo efeito ficasse ótimo, mas estourasse o orçamento de frame, ele não seria lançado. Pelo menos, ainda não.
Esse tipo de disciplina parece óbvio. Na prática, é raro em ambientes de prototipagem acelerada, nos quais todos estão empolgados com o próximo avanço visual.
A aposta na física
O segundo experimento abordou um debate arquitetural que divide os desenvolvedores de jogos para navegador: a física deve rodar na thread principal, onde é mais simples, ou em um Web Worker, onde não pode bloquear a renderização?
No papel, executar a física em um worker é mais organizado. Na prática, o receio é a latência. Cada evento de entrada precisa atravessar duas vezes uma fronteira de mensagens: uma para chegar ao worker e outra para trazer o resultado de volta. Se esse percurso de ida e volta for lento demais, pressionar uma tecla e ver o personagem se mover dará a sensação de falta de resposta.
A equipe integrou o motor de física Rapier (compilado de Rust para WebAssembly) em um worker dedicado, conectou o pipeline de mensagens e fez as medições. A sobrecarga foi insignificante. Os controles continuaram respondendo imediatamente. Mas tivemos o cuidado de observar que havíamos validado um cenário específico, e não uma regra universal. Quando a pressão sobre a GPU e a complexidade do streaming mudassem mais tarde, as premissas precisariam ser verificadas novamente.
Os spikes sem graça que salvaram o projeto
A terceira parte da série não tem capturas de tela. Ela aborda três experimentos que pareciam pouco interessantes, mas tiveram consequências para o produto como um todo.
O primeiro testou se os Durable Objects da Cloudflare conseguiriam lidar com transmissões de posição em tempo real nas taxas de atualização típicas de jogos — a base do modo multijogador. Se isso tivesse falhado, toda a arquitetura de rede precisaria adotar fragmentação antecipada, em vez de atribuir cada ilha a uma única instância.
O segundo validou um perfil de qualidade para dispositivos móveis: não uma predefinição para desktop rebatizada, mas um caminho explícito de renderização de baixo custo a partir da mesma referência de terreno. A questão era se o mundo poderia continuar legível e responsivo sob as limitações das GPUs de dispositivos móveis sem reescrever o renderizador.
O terceiro avaliou se scripts de comportamento gerados por IA para os fluxos de trabalho dos criadores seriam confiáveis o suficiente para uso em produção.
Nenhum deles produziu vídeos de demonstração. Os três estabeleceram limites rígidos que moldaram todas as decisões arquiteturais posteriores. Oleg escreve que esses "spikes pouco chamativos mudaram a arquitetura mais rapidamente do que os spikes visuais".
Streaming: onde projetos bonitos desmoronam
É possível esconder muita coisa em uma imagem estática. Não é possível esconder uma travada de 40 milissegundos ao atravessar a fronteira de um chunk correndo.
A equipe testou o streaming antes de criar o terreno avançado, separando deliberadamente as questões envolvidas. O Spike 6 validou o carregamento de chunks vizinhos com conteúdo simples. Somente depois desse resultado claro o Spike 11 introduziu o streaming de mapas de altura comprimidos com refinamento progressivo — carregando primeiro o terreno com resolução de 17 amostras, depois 33 e, por fim, a grade completa de 65 amostras.
A ordem importou mais do que esperávamos. Se tivéssemos começado diretamente com chunks de altura comprimidos, cada travada teria uma causa ambígua. Era um problema de decodificação, uma interrupção no upload de texturas ou um problema de atualização da geometria? Testar primeiro o streaming simples eliminou uma categoria inteira de incerteza.
Surgiu uma lição prática: meça diretamente as interrupções de upload, não por meio do FPS médio. As médias escondem picos no tempo de frame, e são esses picos que os jogadores realmente sentem.
As guerras pelo orçamento visual
Três experimentos separados atacaram os custos de renderização de forma isolada, em vez de agrupá-los. Densidade da vegetação e animação pelo vento. Materiais de terreno com múltiplas camadas e mapeamento triplanar para faces de penhascos. Mapas de sombras em cascata sob uma carga realista de terreno.
O spike de vegetação revelou que agrupar instâncias em menos malhas era mais importante do que reduzir a quantidade de polígonos de cada folha de grama. O spike de materiais constatou que a projeção triplanar em superfícies verticais justificava o custo de GPU, mas adicionar uma quinta camada de mistura de texturas não. O spike de sombras determinou que três cascatas com resolução de 1024 produziam sombras de contato aceitáveis sem ultrapassar 2 milissegundos de tempo de GPU.
A equipe adotou uma regra direta: um recurso só avança se conseguir justificar seu custo com dados medidos de tempo de frame. Essa restrição, estabelecida desde cedo, tornou significativamente mais claras as decisões arquiteturais posteriores relacionadas a terreno volumétrico e clipmaps.
A mudança de rumo que alterou a trajetória do projeto
Antes do Spike 10, nosso modelo mental era "um mundo maior significa mais geometria". Depois do Spike 10, passou a ser "orçamento de geometria constante, com atualizações de anéis centralizados na câmera".
Clipmaps de geometria — anéis concêntricos de terreno centralizados na câmera, cada um progressivamente menos detalhado — permitiram que a contagem de triângulos permanecesse aproximadamente constante, independentemente da distância de renderização. O truque prático foi aplicar geomorphing nas fronteiras dos anéis: combinar suavemente as alturas dos vértices no shader para que a mudança entre os níveis de resolução se tornasse invisível durante o movimento.
Uma lição sutil surgiu da metodologia de testes. Clipmaps parecem bons em capturas de tela. Seus artefatos só aparecem durante o movimento contínuo da câmera pelas fronteiras dos anéis. A equipe passou um tempo realizando percursos em velocidade constante e procurando ruído temporal. "As capturas de tela mentiram", escreve Oleg. "O movimento revelou a verdade."
Indo para o subsolo
Mapas de altura não conseguem representar cavernas. Eles armazenam um único valor de elevação para cada ponto de uma grade. No momento em que você precisa de túneis, saliências ou faces rochosas esculpidas, precisa de terreno volumétrico.
O Spike 12 implementou marching cubes na GPU usando compute shaders do WebGPU, extraindo malhas triangulares de um campo de distância com sinal 3D. Quatro chunks de 64 ao cubo rodaram simultaneamente, com atualizações da malha a cada frame a partir de edições animadas do SDF. O compute shader cuidou de tudo — avaliar o campo, classificar as células e emitir os vértices — sem nenhuma leitura de volta pela CPU.
O desafio não era fazê-lo funcionar. Era fazê-lo funcionar junto com todo o resto. Integração com o grafo de cena do Three.js, gerenciamento do ciclo de vida dos buffers (buffers WebGPU não podem ser redimensionados), tratamento de fences para evitar destruir recursos da GPU ainda em uso — a série dedica duas partes completas ao que chamamos de "fortalecimento incremental", o processo pouco glamouroso de adicionar uma capacidade de cada vez e verificar se a camada anterior continua funcionando após cada adição.
O pesadelo das emendas
A seção tecnicamente mais angustiante da série abrange as Partes 9 a 11 e trata do que acontece quando chunks de terreno com resoluções diferentes se encontram.
Quando um chunk de alto nível de detalhe fica ao lado de um chunk de baixo nível de detalhe, as malhas geradas de forma independente não se alinham na fronteira. O resultado são rachaduras visíveis, bordas tremeluzentes e junções em T pelas quais a luz vaza. O algoritmo Transvoxel resolve isso com células especiais de transição que conectam as diferenças de resolução — mas implementá-lo corretamente em todas as configurações de chunks, com uma ordem de enrolamento consistente, gerenciamento adequado de buffers e intervalos de desenho precisos, consumiu seis experimentos separados.
A história de depuração mais memorável da equipe: dois dias perseguindo um artefato de emenda que atribuímos à lógica de transição. O verdadeiro culpado eram dados obsoletos. O compute shader da GPU escrevia N vértices em um buffer, mas a chamada de desenho ainda estava configurada para renderizar N+M vértices do frame anterior. Esses vértices extras continham lixo que produzia triângulos finíssimos e tremeluzentes. A correção foi uma única linha: limitar o intervalo de desenho à contagem de vértices ativos do contador atômico.
"Bugs de renderização muitas vezes se disfarçam de bugs de geração de malha", observa Oleg. "A geometria esteve correta o tempo todo."
Do caos à governança
Depois da batalha das emendas, a equipe substituiu o comportamento improvisado dos chunks por um sistema explícito de políticas. Uma função central passou a decidir o nível de LOD de cada chunk, o modo de renderização (mapa de altura ou marching cubes) e quais faces precisavam de células de transição. Anéis de distância determinavam o LOD básico. Uma restrição de adjacência garantia que dois chunks vizinhos não diferissem em mais de um nível de resolução. Um bitmap de edições mantinha chunks volumétricos no modo marching cubes independentemente da distância caso contivessem modificações feitas por criadores.
Sobreposições de depuração com código de cores — verde para chunks de mapa de altura, azul para marching cubes e laranja para faces de transição — transformaram "vi um bug em algum lugar perto daquela elevação" em "o bug aparece na posição (142, 12, -67), voltado para noroeste".
"A política não reduziu a complexidade", escreve Oleg. "Ela organizou a complexidade."
O resultado de tudo isso
O spike final combinou anéis de clipmap, neblina do céu por fragmento (amostrando a cor real do skybox na direção de cada fragmento do terreno) e a conexão de módulos do Three.js em uma demonstração unificada. O resultado é um sistema de terreno que combina edição volumétrica no campo próximo, chunks de mapas de altura a média distância e anéis de clipmap ao longe, sob uma camada de políticas que governa modo, LOD e transições.
A série termina com lições que Oleg diz que repetiria em qualquer projeto futuro:
- Comece com spikes de risco antes do trabalho em recursos. Elimine as dúvidas do tipo "será que conseguimos mesmo fazer isso?" antes de investir em pipelines de conteúdo.
- Congele referências comprovadamente funcionais antes de grandes saltos de integração. O dia gasto estabelecendo um ponto de controle limpo economiza vários dias investigando regressões mais tarde.
- Imponha políticas e observabilidade antes de maratonas de otimização. Condições nomeadas com regras de acionamento sempre superam bugs misteriosos.
- Teste em movimento, não com capturas de tela. Mudanças bruscas, tremulação e travadas de streaming se escondem em imagens estáticas.
- Meça o tempo de frame de cada recurso, não o FPS médio. As médias escondem os picos que os usuários realmente sentem.
- Publique as partes complicadas. Os caminhos errados, as caçadas a fantasmas, os dois dias culpando o sistema errado. Essas são as partes com as quais as pessoas realmente podem aprender.
Por que isso importa para além da Cinevva
A série é significativa por três motivos que vão além do pipeline de terreno de uma única empresa.
Primeiro, ela demonstra que compute shaders do WebGPU, física em WebAssembly e Durable Objects implantados na borda ultrapassaram um limiar. Um mundo aberto multijogador com terreno volumétrico, edição em tempo real e LOD com streaming é arquiteturalmente viável em uma aba do navegador em 2026. Isso não era verdade dois anos atrás.
Segundo, a metodologia de spikes — experimentos pequenos e focados, cada um respondendo a uma única questão de alto risco com resultados funcionais e mensuráveis — oferece um modelo para qualquer equipe que esteja tentando algo que talvez não funcione. A disciplina de medir antes de assumir compromissos, de estabelecer referências antes de integrar e de identificar casos extremos antes de otimizar se aplica a muito mais do que sistemas de terreno.
Terceiro, a transparência radical é o ponto central. Publicar o código-fonte de todos os 24 experimentos, incluindo os becos sem saída e os desvios de dois dias para depuração, transforma isso em algo maior do que um blog técnico. É um caderno público de engenharia que trata o leitor como colega, e não como cliente. A série completa está disponível em nosso guia da série, com todos os protótipos exploratórios rodando ao vivo no navegador.
Este artigo foi publicado originalmente no Medium.