Tecnologia de mundo aberto 3D no navegador para mundos multiplayer de criadores

Queremos colocar nossos criadores em um mundo aberto compartilhado. Não em um lobby. Não em uma galeria. Em um espaço 3D vivo, onde as pessoas possam explorar, construir e encontrar por acaso o trabalho umas das outras. Algo que carregue em uma aba do navegador e pareça um lugar onde vale a pena estar.

Esse é um problema difícil. Skyrim e The Witcher 3 gastaram centenas de milhões de dólares na construção de seus mundos e, ainda assim, rodam em hardware dedicado, com dezenas de gigabytes armazenados em disco. Nosso objetivo é uma aba do navegador, com estado compartilhado entre centenas de jogadores e um mundo que os criadores possam realmente remodelar.

Este guia documenta o que descobrimos ao pesquisar a tecnologia. O que é possível hoje, o que está por vir e qual arquitetura nos permitiria chegar lá.

O que podemos aprender com Skyrim e The Witcher

Antes de escolher a tecnologia, é útil entender como os dois mundos abertos de maior sucesso realmente funcionam. Suas técnicas se adaptam surpreendentemente bem às limitações do navegador.

O sistema de células de Skyrim

O mundo aberto de Skyrim faz streaming de uma grade de 5x5 células ao redor do jogador. As montanhas distantes são impostores de baixa resolução. Você nem percebe.

Skyrim divide seu mundo em uma grade de 57x37 células externas, cada uma com 4096x4096 unidades de jogo (aproximadamente 59 metros). O motor carrega, a qualquer momento, uma grade de 5x5 células ao redor do jogador. Conforme você caminha, as células na borda de trás são descarregadas, enquanto as da borda à frente entram por streaming. Os espaços internos (masmorras e edifícios) são mundos separados, carregados por gatilhos nas portas.

Isso se aplica diretamente a um mundo no navegador. Você não carrega o mapa inteiro. Carrega uma região ao redor do jogador e troca os blocos conforme ele se move. A percepção essencial é esta: Skyrim nunca permite que você veja todos os detalhes do terreno distante. Ele usa uma abordagem de múltiplas resoluções.

Níveis de LOD (nível de detalhe) em Skyrim:

• Detalhamento completo dentro de 1 a 2 células (a área imediata do jogador)
• Malhas simplificadas a média distância (os objetos perdem pequenos detalhes geométricos)
• Impostores em billboard para árvores e rochas além da média distância
• O LOD do terreno usa malhas pré-calculadas de baixa resolução para paisagens distantes
• Distâncias de desaparecimento ajustadas individualmente para cada objeto (a grama desaparece primeiro; os edifícios, por último)

A paisagem de Skyrim usa um terreno baseado em mapa de altura, com trechos de 32x32 vértices por célula. Cada trecho pode ter texturas diferentes combinadas com mapas alfa. Isso é barato de armazenar e renderizar. Os dados de terreno de uma única célula são medidos em quilobytes, não em megabytes.

O que podemos aplicar: streaming baseado em blocos, terreno com mapa de altura, LOD agressivo, separação entre interiores e exteriores e a ideia de que o terreno distante não precisa ser geometricamente preciso, apenas visualmente convincente.

A arquitetura de streaming de The Witcher 3

O mundo de 136 km2 de The Witcher 3 usa streaming sensível ao conteúdo. Árvores a mais de 200 m são impostores planos. Os edifícios são transmitidos independentemente do terreno.

O mundo de The Witcher 3 é maior que o de Skyrim (aproximadamente 136 km2 considerando todas as regiões) e usa um sistema de streaming mais sofisticado. A CD Projekt RED criou um motor personalizado (REDengine 3) no qual o mundo é dividido em setores de streaming, em vez de uma grade rígida.

Cada setor contém uma hierarquia de camadas de conteúdo:

• Terreno transmitido em trechos com 4 níveis de LOD
• Vegetação usa instanciamento na GPU com descarte baseado na distância
• Geometria estática (edifícios e rochas) é transmitida independentemente do terreno
• Objetos de gameplay (NPCs, itens e gatilhos) são carregados com base no estado das missões e na proximidade

O renderizador usa sombreamento diferido com materiais baseados em física. Um truque particularmente relevante: The Witcher 3 usa impostores de forma agressiva. Uma árvore a 200 metros de distância não é um modelo 3D com galhos e folhas. É um quadrilátero plano texturizado que está sempre voltado para a câmera. O motor pré-renderiza esses impostores de vários ângulos e os troca conforme a câmera se move. Você nem percebe, porque eles estão longe o suficiente.

Composição do mundo: o mundo aberto de The Witcher 3 foi construído em camadas por equipes distintas trabalhando simultaneamente. A equipe de terreno esculpiu a paisagem. A equipe de arte de ambientes posicionou as estruturas. A equipe de missões configurou os gatilhos e as rotas dos NPCs. Esse sistema de composição em camadas permitiu que uma equipe grande trabalhasse sem que seus integrantes interferissem no trabalho uns dos outros.

O que podemos aplicar: composição do mundo em camadas (essencial para uma plataforma de criadores), renderização por impostores para objetos distantes, renderização diferida para muitas fontes de luz e a percepção de que o streaming deve ser sensível ao conteúdo (não carregue interiores que não podem ser vistos nem gere NPCs dos quais o jogador não está próximo).

O motor de química de Breath of the Wild

BotW roda em hardware de nível tablet e tem um visual impressionante. Estilo cel-shading, névoa de distância em aquarela e interações sistêmicas em vez de conteúdo roteirizado. A referência máxima para mundos abertos estilizados.

A abordagem da Nintendo ao design de mundo aberto inverteu a fórmula típica. Em vez de preencher o mundo com conteúdo roteirizado, a empresa criou regras sistêmicas e deixou que os jogadores descobrissem comportamentos emergentes. O fogo se espalha pela grama. O metal conduz eletricidade durante tempestades. O vento carrega objetos. Tudo interage com todo o resto por meio de uma camada consistente de física e química.

Isso é importante para um mundo de criadores porque sugere que o próprio mundo pode ser mais interessante do que qualquer objeto colocado individualmente. Se os criadores puderem definir propriedades dos materiais e regras de interação (em vez de apenas posicionar malhas estáticas), o mundo ganhará comportamentos emergentes que farão a exploração valer a pena até mesmo em áreas que ninguém projetou explicitamente.

Conclusões técnicas de BotW:

• Contagem de polígonos e resolução relativamente baixas (900p no Switch conectado à base). O visual estilizado com cel-shading disfarça a baixa fidelidade. Um mundo no navegador poderia alcançar hoje uma qualidade visual semelhante.
• A renderização à distância usa uma névoa com sombreamento toon que se dissolve em skyboxes no estilo aquarela. Barata de renderizar e bonita na prática. Esse tipo de perspectiva atmosférica é praticamente gratuito em um fragment shader.
• O mundo tem aproximadamente 84 km2, mas é esparso. A maior parte do mapa consiste em terreno percorrível, com pontos de interesse distribuídos por ele. O conteúdo denso fica reservado para cidades e santuários. Essa abordagem “esparsa, mas interessante” reduz drasticamente os requisitos de assets em comparação com a Novigrad densamente povoada de The Witcher 3.
• Objetos físicos têm etiquetas de material (madeira, metal, comida e explosivo) que determinam as interações. O número real de regras é pequeno (talvez de 20 a 30 tipos de interação), mas elas se combinam de maneiras que parecem infinitas.

As camadas de mundo de GTA V

Los Santos, de GTA V, parece viva graças a sistemas ambientais em camadas: trânsito, pedestres, horário do dia e clima. Os edifícios distantes são fotografias compostas, não modelos 3D.

A abordagem da Rockstar para Los Santos ensina uma lição diferente. O mundo de GTA V parece vivo por causa de sistemas ambientais em camadas, não porque cada NPC tenha uma missão.

A cidade tem sistemas de trânsito que simulam centenas de veículos em uma malha viária. Pedestres percorrem rotas, reagem ao jogador e interagem entre si. O horário do dia altera a densidade populacional, os tipos de NPCs presentes e a atividade ambiente. O clima afeta a física da direção e o comportamento dos NPCs.

Para um mundo de criadores, a percepção é que a vida ambiente faz a diferença entre um mundo que parece um museu e outro que parece um lugar real. Até mesmo comportamentos simples (pássaros voando no céu, ondas batendo na costa e NPCs caminhando entre edifícios) criam a ilusão de um mundo vivo.

Conclusões técnicas de GTA V:

• O mapa tem 75 km2 e usa LOD agressivo combinado com um sistema de streaming que carrega conteúdo com base na velocidade (dirigir rapidamente carrega áreas mais distantes à frente do que caminhar).
• GTA Online coloca 30 jogadores simultaneamente nesse mundo. Mesmo com 30, a Rockstar descobriu que precisava de gerenciamento espacial de relevância: você recebe atualizações detalhadas sobre jogadores próximos e atualizações menos frequentes sobre os distantes. O mesmo princípio se aplica à nossa meta de 200 jogadores.
• O pipeline de assets de GTA V é um dos mais eficientes já criados. O jogo inteiro ocupa aproximadamente 80 GB graças à compressão extrema de texturas, ao compartilhamento de malhas e aos detalhes procedurais. Os interiores dos edifícios reutilizam extensivamente peças modulares.
• O jogo usa um sistema sofisticado de impostores no qual os edifícios distantes são, na verdade, fotografias planas combinadas. O jogador nunca percebe porque as distâncias de transição são ajustadas para ângulos de visão específicos.

O mundo aberto contínuo de Elden Ring

O mapa de 79 km2 de Elden Ring combina terreno aberto esparso com masmorras densas e criadas à mão. Os mesmos assets de ambiente aparecem por toda parte em arranjos diferentes. A repetição desaparece quando a composição e a iluminação variam.

A FromSoftware construiu Elden Ring sobre o mesmo motor de Dark Souls, mas o ampliou para um mundo aberto. O resultado é interessante porque mostra como uma equipe relativamente pequena (em comparação com a Rockstar ou a CD Projekt) pode construir um grande mundo aberto.

O truque é a variação de densidade. O mapa de Elden Ring é enorme (aproximadamente 79 km2), mas grandes áreas são terrenos abertos com inimigos e pontos de interesse espalhados. O conteúdo denso e criado à mão (as Legacy Dungeons, como o Castelo Tempesvéu) está integrado ao mundo aberto e usa a mesma separação entre interiores e exteriores de Skyrim.

Conclusões técnicas de Elden Ring:

• O mundo é transmitido em grandes blocos. A cavalo, é possível enxergar muito longe, mas o terreno distante é extremamente simplificado. De perto, o nível de detalhe é comparável ao de Dark Souls 3.
• As telas de carregamento só aparecem durante viagens rápidas ou ao entrar em determinadas masmorras. O próprio mundo aberto é transmitido sem interrupções.
• O jogo reutiliza extensivamente assets de ambiente. Os mesmos modelos de árvores, formações rochosas e peças de ruínas aparecem pelo mapa em arranjos diferentes. Com variedade suficiente na disposição e na iluminação, a repetição não é perceptível. Isso se aplica diretamente a um mundo de criadores, no qual uma biblioteca de peças modulares pode gerar variedade infinita.
• O multiplayer é baseado em sessões (outros jogadores são invocados para o seu mundo), e não persistente. Porém, os recursos assíncronos (mensagens, manchas de sangue e fantasmas de outros jogadores) criam uma sensação de existência compartilhada sem o custo de rede de um servidor persistente. Esses recursos multiplayer ambientais seriam baratos de adicionar a um mundo no navegador.

No Man's Sky: tudo procedural

18 quintilhões de planetas gerados a partir de sementes compartilhadas. Todos os jogadores veem o mesmo universo sem que ele seja armazenado em um servidor. Os dados de construção de bases são compactos: IDs de peças mais transformações.

No Man's Sky é o caso extremo de geração procedural. São 18 quintilhões de planetas gerados a partir de uma semente compartilhada, de modo que todos os jogadores veem o mesmo universo sem que nada disso seja armazenado em um servidor.

O pipeline de geração funciona em etapas: sementes no nível da galáxia determinam as posições das estrelas; sementes de estrelas determinam a quantidade e os tipos de planetas; sementes de planetas orientam a geração do terreno (ruído em múltiplas oitavas), a atribuição de biomas, as espécies de flora e fauna, as paletas de cores e a distribuição de recursos. Tudo é calculado deterministicamente a partir da semente, de modo que dois jogadores que visitem as mesmas coordenadas vejam o mesmo planeta sem trocar nenhum dado sobre ele. Principais conclusões técnicas de No Man's Sky:

• A geração de terreno usa marching cubes baseados em voxels com uma pilha de funções de ruído. Isso permite cavernas, saliências e ilhas flutuantes que terrenos baseados em mapas de altura não conseguem representar. A desvantagem é o maior custo computacional por chunk, mas o resultado é um terreno visualmente mais interessante.
• O sistema de construção de bases é o que mais se aproxima do que estamos imaginando. Os jogadores posicionam estruturas que persistem no servidor e ficam visíveis para outros jogadores. Os dados da base são compactos (uma lista de peças com posições e rotações) e são transmitidos sob demanda quando alguém visita o planeta.
• O jogo foi inicialmente criticado pelo conteúdo repetitivo, apesar da variedade infinita. A geração baseada em seeds pode produzir terrenos infinitos, mas com surpresas limitadas. A lição: a geração procedural funciona para criar a tela em branco, mas é o conteúdo posicionado por criadores que faz um lugar parecer planejado e intencional.
• A Hello Games adicionou o modo multijogador anos após o lançamento. Até 32 jogadores compartilham uma sessão com construção e exploração completas. O modelo de rede é simples: um jogador hospeda e os demais se conectam. Para um mundo no navegador com estado persistente, um modelo autoritativo no servidor funciona melhor, mas No Man's Sky comprova que mundos procedurais compartilhados são viáveis.

Minecraft: o modelo para mundos de criadores

300 milhões de cópias vendidas. Texturas de 16x16 pixels. Terreno totalmente editável. Geração infinita. Multijogador. A referência mais importante para um mundo de criadores. Clones para navegador comprovam que o conceito funciona em WebGL.

Minecraft é a referência mais importante para o que estamos construindo, mais do que qualquer título AAA com gráficos avançados. Foram 300 milhões de cópias vendidas. O mundo tem geração infinita, é totalmente destrutível e conta com modo multijogador. No Minecraft, os criadores não apenas posicionam objetos. Eles remodelam o próprio terreno.

Principais conclusões técnicas do Minecraft:

• O mundo é dividido em chunks de 16x16x384 blocos. Apenas os chunks próximos ao jogador são carregados (a distância de renderização é configurável). Esse é o mesmo padrão de streaming de chunks do Skyrim, mas com terreno totalmente editável.
• Cada chunk é armazenado como um array de IDs de blocos compactado por paleta. Um chunk com apenas 5 tipos diferentes de bloco armazena um índice de paleta de 4 bits por bloco, em vez de um ID completo do bloco. Isso torna os dados do chunk muito compactos (normalmente, de 10 a 50 KB por chunk após a compactação).
• O protocolo multijogador do Minecraft é bem documentado e relativamente simples. O servidor envia os dados dos chunks à medida que o jogador se move. Alterações em blocos são transmitidas como pequenas atualizações incrementais (posição + novo tipo de bloco). Esse é exatamente o modelo que usaríamos para as edições dos criadores.
• O jogo roda em Java e agora tem uma Bedrock Edition em C++. Existem clones do Minecraft para navegador (ClassiCube, eaglercraft) que comprovam que o conceito central funciona em WebGL. Normalmente, eles conseguem manter uma distância de renderização de 8 a 12 chunks a 60 fps, o que proporciona uma vista de cerca de 200 a 400 metros.
• O ecossistema de mods do Minecraft é sua verdadeira vantagem competitiva. Os mods adicionam novos blocos, entidades, biomas e sistemas de gameplay. Para um mundo de criadores, isso sugere que a extensibilidade é tão importante quanto a experiência básica. Se os criadores puderem definir novos tipos de interação (e não apenas posicionar objetos), o mundo se tornará mais rico com o tempo.
• A redstone (o sistema de circuitos dentro do Minecraft) demonstra que criadores construirão sistemas complexos se tiverem acesso a elementos básicos simples e combináveis. Portas lógicas, fazendas automáticas, calculadoras. O conjunto simples de regras gera uma complexidade extraordinária. É a mesma lição do mecanismo químico de BotW.

Padrões comuns em mundos abertos AAA

Ao analisar todos esses títulos, os mesmos padrões continuam aparecendo:

O particionamento espacial é universal. Sejam células (Bethesda), setores (CD Projekt), chunks (Mojang/Rockstar) ou blocos (FromSoftware), todo mundo aberto divide o espaço em unidades carregáveis. Nenhuma engine tenta manter o mundo inteiro na memória.

Tudo em múltiplas resoluções. Terrenos, malhas, texturas e até o áudio têm vários níveis de qualidade. A resolução obtida depende da proximidade e da importância do objeto.

O descarte por oclusão importa mais do que a capacidade bruta de processar triângulos. Não renderizar o que não pode ser visto economiza mais desempenho do que otimizar aquilo que pode. Skyrim usa um sistema simples baseado em distância. The Witcher 3 usa oclusão por software com grandes elementos oclusores (edifícios, penhascos). Engines modernas, como a Nanite da UE5, levam isso adiante com consultas de oclusão por hardware.

O carregamento assíncrono oculta as transições. Esses jogos não exibem telas de carregamento no mundo aberto (apenas durante viagens rápidas ou transições para interiores). Eles carregam conteúdo em threads de segundo plano, descompactam em paralelo e inserem o novo conteúdo gradualmente.

Direção de arte acima da contagem de polígonos. Skyrim foi lançado em 2011 com gráficos que já eram modestos para a época. BotW roda em um chip da categoria de tablets e é visualmente belíssimo. Minecraft usa texturas de 16x16 pixels e é um dos jogos visualmente mais reconhecíveis já feitos. Para um mundo no navegador, isso é extremamente importante. Um estilo artístico bem dirigido e com menor fidelidade sempre superará um mundo tecnicamente avançado, mas artisticamente sem graça.

O design sistêmico supera o conteúdo roteirizado. O mecanismo químico de BotW, as interações entre blocos do Minecraft e os sistemas de trânsito de GTA V criam comportamentos emergentes a partir de regras simples. Isso é mais barato de desenvolver, mais barato de executar e gera mais histórias para os jogadores do que sequências roteirizadas e feitas à mão. Para um mundo de criadores, o design sistêmico significa que o mundo continua interessante mesmo em áreas que ninguém projetou explicitamente.

O conteúdo posicionado por criadores precisa de persistência e visibilidade. As bases do Minecraft e de No Man's Sky, assim como as propriedades do GTA Online, persistem entre sessões e ficam visíveis para outros jogadores. O modelo de dados do conteúdo criado sempre é compacto (IDs de peças + transformações), enquanto a representação visual é rica (o cliente expande os dados em cenas 3D completas).

Renderização: o que um navegador realmente consegue fazer?

Three.js

Three.js é a base. Tem a maior comunidade (mais de 100 mil estrelas no GitHub), o maior número de exemplos e a compatibilidade mais ampla. Ele abstrai o WebGL 2 e oferece suporte experimental ao WebGPU por meio do WebGPURenderer.

Para um mundo aberto, Three.js oferece:

• Renderização instanciada para vegetação, rochas e geometria repetida (InstancedMesh)
• Sistema de LOD integrado (THREE.LOD alterna as malhas de acordo com a distância)
• Descarte de frustum automático por objeto
• Terreno por meio de BufferGeometry personalizada ou PlaneGeometry baseada em mapa de altura
• Materiais PBR por meio de MeshStandardMaterial e MeshPhysicalMaterial
• Pós-processamento por meio do EffectComposer (bloom, SSAO, mapeamento de tons)
• Mapas de sombras, com a possibilidade de usar mapeamento de sombras em cascata por meio de código personalizado
• glTF/GLB como principal formato de assets (compacto e pronto para a GPU)

Three.js também tem um ecossistema ativo de ferramentas importantes para mundos abertos. three-mesh-bvh acelera o raycasting e as consultas espaciais em malhas complexas. postprocessing (de vanruesc) oferece uma pilha de pós-processamento com melhor desempenho do que a integrada ao Three. three-gpu-pathtracing permite renderização com qualidade de referência.

Limitações para mundos abertos: Three.js não tem um grafo de cena integrado que gerencie streaming, LOD ou particionamento espacial em grande escala. Você precisa desenvolver tudo isso. Não há um sistema entidade-componente (ECS) integrado, nem física ou sistema de terreno. É um renderizador, não uma engine. Na verdade, isso é uma vantagem para um mundo aberto personalizado, pois permite controlar o layout da memória e a estratégia de carregamento, mas exige mais trabalho inicial.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js é a outra grande opção. Com apoio da Microsoft, oferece recursos integrados mais completos do que o Three.js para o problema específico dos mundos abertos.

Recursos integrados relevantes:

• Particionamento de cena baseado em octree para descartar com eficiência partes de cenas grandes
• Solid Particle System para renderização instanciada em massa
• Terreno baseado em mapas de altura com LOD integrado e combinação de múltiplas texturas
• Node Material Editor para criação visual de shaders
• Suporte a WebGPU (mais maduro do que no Three.js, pois o Babylon investiu nisso antes)
• Integração com a física Havok (compilada em Wasm e com qualidade de produção)
• Streaming de glTF com carregamento progressivo

A extensão DynamicTerrain do Babylon gera chunks de terreno dinamicamente a partir de dados de mapas de altura, gerencia o LOD automaticamente e oferece suporte à combinação de texturas. Isso se aproxima muito mais do que Skyrim faz do que qualquer recurso oferecido pelo Three.js sem extensões.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

A desvantagem: Babylon.js é uma biblioteca maior (a compilação completa tem cerca de 1 a 2 MB minificados, contra aproximadamente 600 KB do Three.js). Porém, para um mundo aberto, provavelmente seria necessário adicionar tanto código personalizado ao Three.js que a diferença de tamanho se tornaria insignificante. O Babylon também conta com seu próprio sistema Node Material, inspetor e ferramentas de desenvolvimento, que aceleram as iterações.

O Babylon.js 8.0 (lançado em março de 2025) reforçou sua posição como engine central para este projeto. Todos os shaders principais da engine agora são distribuídos em GLSL e WGSL, portanto o WebGPU funciona sem uma camada de conversão, e o pacote WebGPU tem aproximadamente metade do tamanho anterior. A mesma versão trouxe para a engine o controlador de personagem completo da Havok, luzes de área, uma engine de áudio reconstruída e melhorias no Gaussian splatting (formatos SPZ e PLY compactado, harmônicos esféricos e menor consumo de memória e CPU).

PlayCanvas

Vale a pena mencionar o PlayCanvas porque é a engine 3D voltada para a web com maior comprovação em produção. Snap, Facebook e inúmeros clientes do setor publicitário lançaram experiências 3D complexas com ela. A engine tem cerca de 1 MB, carrega rapidamente e o editor na nuvem permite a criação colaborativa de mundos.

Especificamente para mundos abertos, o PlayCanvas oferece grupos de lotes para otimizar chamadas de desenho, um gerador de mapas de iluminação integrado e suporte a Gaussian splatting (relevante para ambientes do mundo real capturados por fotogrametria). O runtime é enxuto e bem otimizado para navegadores móveis.

WebGPU: o salto de desempenho

O WebGPU muda o cenário dos mundos abertos no navegador. Os dois recursos mais importantes são:

Shaders de computação permitem a geração de terreno, o posicionamento de vegetação, a simulação de partículas e até física simples na própria GPU. Em um mundo WebGL, tudo isso é executado pela CPU em JavaScript. Com o WebGPU, é possível gerar trechos de terreno inteiramente na GPU, calcular transições de LOD na GPU e executar etapas de descarte na GPU. Isso libera a CPU para a comunicação em rede, a lógica do jogo e o streaming de conteúdo.

A renderização indireta permite que a GPU decida o que desenhar com base na saída do shader de computação. Você envia uma única chamada de desenho, e a GPU decide quantas instâncias renderizar para cada nível de LOD com base na distância. É assim que engines modernas processam milhões de folhas de grama ou árvores. Sem renderização indireta (para a qual o WebGL não oferece suporte), a CPU precisa ordenar e agrupar tudo, tornando-se o gargalo em cenas densas.

O WebGPU agora está disponível em todos os principais navegadores. Chrome e Edge oferecem suporte desde a versão 113, o Firefox o adicionou no Windows (141) e no macOS em Apple Silicon (145), e o Safari 26 o levou ao macOS, iOS, iPadOS e visionOS no fim de 2025. Isso coloca o suporte global em cerca de 82%, incluindo dispositivos móveis (Chrome para Android e Samsung Internet também oferecem suporte). Ainda seria necessário manter um fallback para WebGL 2 em navegadores e dispositivos mais antigos nos quais o WebGPU não esteja ativado, mas essa lacuna diminuiu rapidamente.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

Stack de renderização recomendada

Para um mundo aberto no navegador voltado a criadores em computadores:

Principal: Three.js ou Babylon.js com o renderizador WebGPU quando disponível e fallback para WebGL 2. O Babylon tem recursos integrados mais robustos para mundos abertos. O Three.js tem uma comunidade maior e mais flexibilidade.

Nossa escolha: Babylon.js como núcleo da engine devido ao LOD de terreno integrado, ao descarte por octree, à física Havok (Wasm) e ao suporte maduro ao WebGPU. Usar ferramentas do ecossistema Three.js quando não houver equivalentes no Babylon (por exemplo, BVH de malhas para consultas espaciais). Envolver tudo em uma camada personalizada de streaming do mundo.

Arquitetura de streaming do mundo

Esta é a parte difícil. Uma aba do navegador tem aproximadamente de 2 a 4 GB de memória em computadores (devido aos limites impostos pelo navegador), cerca de 1 GB em dispositivos móveis e nenhum acesso direto ao disco. Tudo vem pela rede. É necessária uma arquitetura que mantenha o mundo visível na memória enquanto transmite conteúdo um pouco à frente da direção em que o jogador está se movendo.

Grade do mundo baseada em chunks

Assim como o sistema de células do Skyrim, divida o mundo em uma grade regular de chunks. Cada chunk é uma unidade independente que pode ser carregada, renderizada e descarregada separadamente.

O tamanho dos chunks é importante. Se forem pequenos demais, haverá carregamentos e descarregamentos constantes com alto custo adicional. Se forem grandes demais, cada chunk demorará muito para baixar. Para um mundo no navegador com conexões de banda larga típicas:

• Chunks de 64x64 metros no nível do solo
• Cada chunk contém: trecho do mapa de altura (2 a 4 KB), mapa de combinação de texturas (16 a 32 KB compactados), malhas estáticas como referências instanciadas (1 a 50 KB de dados de instâncias), objetos posicionados por criadores como um manifesto (1 a 10 KB)
• Raio de carregamento: 5x5 chunks em detalhes máximos (vista de 320 m), 9x9 em LOD médio, 17x17 apenas com o terreno
• Meta: dados completos de cada chunk abaixo de 200 KB, para que uma vizinhança de 5x5 fique abaixo de 5 MB

Pipeline de carregamento progressivo

Não carregue tudo de um chunk de uma só vez. Use uma fila de prioridades:

1. Primeiro, a geometria do terreno (apenas o mapa de altura, 2–4 KB por chunk). O jogador vê o solo em até 100 ms.
2. Texturas do terreno (mapas de splat, primeiro em baixa resolução e depois aprimorados). O solo ganha cor em até 200 ms.
3. Estruturas principais (edifícios, rochas grandes). As silhuetas aparecem em até 500 ms.
4. Objetos de detalhe (vegetação, pequenos elementos de cena, itens de criadores). O mundo é preenchido ao longo de 1–2 segundos.
5. Texturas em alta resolução são aprimoradas por último. Ninguém percebe se a textura de um edifício distante leva um segundo a mais para carregar.

Isso corresponde à forma como o olho humano funciona. Percebemos quando o solo ou as estruturas grandes estão ausentes. Não percebemos a ausência de grama.

Gerenciamento de memória

A memória do navegador é limitada, e o coletor de lixo é seu inimigo. Uma única pausa de GC pode derrubar a taxa de 60 fps para 10 fps durante um quadro.

O pool de objetos é obrigatório. Pré-aloque pools para objetos comuns (árvores, rochas, trechos de grama) e recicle-os conforme os chunks são carregados e descarregados. Nunca crie novas instâncias de THREE.Mesh ou BABYLON.Mesh no caminho crítico. Em vez disso, troque as referências de geometria e material nos objetos do pool.

Atlas de texturas reduzem tanto as chamadas de desenho quanto a fragmentação da memória. Agrupe todas as texturas do terreno em alguns atlas grandes. Agrupe no servidor as texturas enviadas pelos criadores em atlas por chunk e transmita-as como imagens únicas.

A compressão de geometria com Draco ou Meshopt reduz o tamanho do download em 5–10 vezes, e a descompressão é executada em um Web Worker para não bloquear a thread principal. Especificamente para terrenos, mapas de altura quantizados (valores de 16 bits comprimidos com codificação delta simples) são menores do que qualquer formato de malha de uso geral.

A transferência de propriedade de ArrayBuffer entre workers e a thread principal evita cópias. Quando um worker descomprimir uma malha, transfira o buffer para a thread principal sem cópia usando postMessage com objetos transferíveis.

Entrega de assets

Use uma CDN com cache na borda para dados estáticos do mundo. Chunks de terreno, malhas básicas e atlas de texturas que não mudam com frequência devem ser armazenados em cache de forma agressiva (Cache-Control: max-age=31536000, immutable).

O armazenamento endereçado por conteúdo significa que cada versão de um asset recebe um hash exclusivo em sua URL. Quando um criador modifica um chunk, a nova versão recebe um novo hash, e a antiga permanece no cache para quem ainda estiver visualizando-a. Não é necessário invalidar o cache.

Use texturas KTX2 com compressão Basis Universal. Elas são descomprimidas para qualquer formato de GPU compatível com o dispositivo (BC7, ASTC, ETC2 ou RGBA como alternativa). Uma textura de terreno de 1024x1024 passa de 4 MB sem compressão para aproximadamente 150 KB em KTX2. Em um mundo com milhares de texturas exclusivas, essa compressão faz a diferença entre um projeto viável e um inviável.

Use glTF Binary (GLB) para todos os assets 3D. É o JPEG do 3D. Todos os mecanismos para navegador conseguem carregá-lo, ele é compacto e pode incorporar texturas, materiais e animações em um único arquivo. Use extensões Draco ou Meshopt para comprimir as malhas. Os assets enviados pelos criadores são processados no servidor e convertidos em GLBs otimizados antes de entrar no mundo.

Rede multijogador

Colocar centenas de criadores no mesmo mundo exige uma arquitetura de rede capaz de lidar com movimentação em tempo real, estado persistente do mundo e edições dos criadores sem entrar em colapso.

Arquitetura do servidor

Use um servidor autoritativo para o estado do mundo. O navegador não é confiável. Todas as ações relevantes (posicionar objetos, modificar o terreno, mover-se entre chunks) são validadas no servidor. O cliente faz previsões localmente e depois as reconcilia com o estado do servidor.

O particionamento espacial divide o mundo entre instâncias de servidor. Cada partição controla uma região retangular da grade do mundo. À medida que a densidade de jogadores muda, as partições podem ser divididas ou mescladas. É assim que o EVE Online lida com milhares de jogadores em um único universo, e o mesmo princípio se aplica em menor escala.

Para um mundo de criadores no qual a maioria das interações é local (você constrói em sua área e seus vizinhos conseguem ver), o particionamento espacial funciona de maneira natural. Um jogador parado no limite de uma partição vê o conteúdo das duas partições, o que exige consultas de visibilidade entre elas, mas esse é um problema já resolvido.

Opções de tecnologia para o servidor:

Tecnologia	Pontos fortes	Caso de uso
Cloudflare Durable Objects	Implantação na borda, escalonamento automático, persistência integrada, suporte a WebSocket	Estado das partições do mundo, autoridade por chunk
Hathora / Rivet	Hospedagem gerenciada de servidores de jogos, proteção contra DDoS, implantação global	Instâncias dedicadas de servidores de jogos
Colyseus	Framework de servidor de jogos de código aberto para Node.js, sincronização de estado baseada em esquemas	Multijogador baseado em salas com diferenciação de estado
PartyKit	Implantação na borda, WebSocket + WebRTC, baseado em Cloudflare Workers	Colaboração em tempo real, multijogador leve
Rust/Go personalizado	Controle máximo, melhor desempenho por instância	Partições de alta densidade que exigem física de baixa latência

Nosso contexto (infraestrutura da Cloudflare): Durable Objects são uma escolha natural. Cada chunk do mundo se torna um Durable Object que mantém o estado autoritativo do conteúdo daquele chunk. Os jogadores se conectam via WebSocket ao Durable Object responsável pelo chunk atual. Quando se movem para um chunk adjacente, eles se conectam ao DO correspondente. Durable Objects persistem automaticamente o estado em disco, portanto os dados do mundo sobrevivem a reinicializações.

Comunicação entre cliente e servidor

Use WebSocket para mensagens confiáveis e ordenadas (chat, edições do mundo, inventário, estado do jogo). Uma conexão para cada partição ativa que o jogador consegue ver (normalmente de 1 a 4 conexões).

Use WebRTC DataChannel para mensagens não confiáveis e não ordenadas (posições dos jogadores, animações, efeitos efêmeros). O WebRTC permite conexões ponto a ponto, mas, em um mundo com muitos jogadores, você o executaria por meio de uma SFU (Selective Forwarding Unit) para evitar N2 conexões. Cloudflare Calls ou LiveKit podem atuar como SFU.

A sincronização de estado usa compressão delta. O servidor acompanha o que cada cliente já viu e envia apenas as alterações. Isso é particularmente importante em um mundo de criadores porque o estado do mundo (quais objetos existem, onde estão e quais propriedades possuem) muda com muito menos frequência do que as posições dos jogadores. É possível enviar atualizações do estado do mundo a 2–5 Hz, enquanto as posições dos jogadores são atualizadas a 20–30 Hz.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

Resolução de conflitos em edições de criadores

Quando dois criadores modificam a mesma área simultaneamente, é necessária uma estratégia de resolução de conflitos. É nesse ponto que a escolha do modelo de colaboração em tempo real se torna importante.

A última gravação vence é a opção mais simples. Cada objeto tem apenas um proprietário por vez. Se você estiver editando um edifício, ninguém mais poderá editá-lo até que você o libere. É simples e não gera conflitos, mas limita a colaboração.

A Transformação Operacional (OT) é o que o Google Docs usa. As operações são transformadas em relação a operações concorrentes para produzir um resultado consistente. Isso funciona para texto, mas se torna complexo em operações espaciais 3D. O Figma usa uma variação desse modelo em sua tela 2D.

CRDTs (Tipos de Dados Replicados sem Conflitos) permitem edições simultâneas que sempre convergem para o mesmo estado sem coordenação. Para um mundo com objetos distintos (cada um com um ID e propriedades), um registrador Last-Writer-Wins por propriedade combinado com um conjunto Add-Wins para a coleção de objetos proporciona convergência automática. Yjs e Automerge são bibliotecas CRDT para JavaScript com qualidade de produção.

Nossa recomendação: use CRDTs para o estado dos objetos do mundo (o que existe, onde está e quais propriedades possui) e um servidor autoritativo para a validação espacial (impedir dois objetos no mesmo lugar e manter os objetos dentro dos limites do mundo). O CRDT cuida da colaboração. O servidor cuida da física.

Como lidar com a escala: quantos jogadores?

MMOs para navegador já existem. Hordes.io executa cenas com mais de 200 jogadores no navegador. BrowserQuest (o experimento da Mozilla) comportava centenas de jogadores com um mundo simples baseado em blocos. A questão não é se os navegadores conseguem lidar com multijogador, mas qual fidelidade visual pode ser mantida à medida que o número de jogadores aumenta.

Orçamento de renderização dos jogadores: cada jogador visível precisa de uma malha, animações e, possivelmente, uma aparência personalizada pelo criador. A 60 fps, você tem 16 ms por quadro. Um orçamento razoável:

• 50 jogadores totalmente animados a curta distância: cerca de 2 ms para animação + skinning
• 200 jogadores a média distância (animação simplificada, com instanciação): cerca de 1 ms
• Mais de 500 jogadores como pontos/ícones no minimapa: impacto insignificante

Isso proporciona uma população visível de aproximadamente 250 jogadores em uma única visão, o que é mais do que suficiente para um mundo de criadores. As capitais de World of Warcraft raramente renderizam mais de 200 personagens na tela ao mesmo tempo.

Orçamento de rede: cada jogador enviando sua posição a 20 Hz consome aproximadamente 40 bytes * 20 = 800 bytes/segundo. Com 200 jogadores visíveis, são 160 KB/s de dados de posição. Somando o estado do mundo, o chat e as ações dos criadores, o total fica entre 200–500 KB/s por cliente. Isso está bem dentro da capacidade da banda larga, mas ainda vale a pena comprimir.

Sistema de terreno

O terreno é a base de qualquer mundo aberto. Também é onde as limitações do navegador pesam mais, pois ele precisa estar em toda parte e sempre visível.

Terreno baseado em mapa de altura

Assim como em Skyrim, use um mapa de altura. Uma grade 2D de valores de altura gera o terreno 3D por meio de um shader de vértices. Isso é muito mais compacto do que um terreno formado por malhas arbitrárias.

Um mapa de altura de 4096x4096 com precisão de 16 bits ocupa 32 MB sem compressão. Mas ele nunca é carregado por inteiro de uma só vez. Cada chunk de 64 m usa uma seção de 65x65 do mapa de altura (cerca de 8,4 KB em 16 bits). Comprima-a com codificação delta e zlib, e o tamanho fica abaixo de 2 KB por chunk.

O texture splatting aplica vários materiais de terreno (grama, rocha, terra, areia) usando um mapa de mesclagem. Cada chunk possui um mapa de splat RGBA de quatro canais, em que cada canal controla o peso de mesclagem de um material. Com quatro texturas por mapa de splat e a possibilidade de variar esses mapas por chunk, você obtém diversidade visual em todo o mundo.

Renderizadores modernos de terreno usam texturização virtual (também chamada de megatexture, originada da tecnologia da id Software em Rage). Em vez de fazer o splatting em tempo de execução, você pré-renderiza a textura mesclada do terreno em alta resolução e transmite blocos dela conforme a câmera se move. Isso troca espaço de armazenamento por desempenho em tempo de execução. Os shaders de computação do WebGPU conseguem lidar com o feedback e o gerenciamento de tabelas de páginas exigidos pela texturização virtual.

Clipmap ou geoclipmapping

Para renderizar grandes terrenos em um navegador, as abordagens CDLOD (LOD de C. Dick) ou geoclipmapping funcionam bem. O terreno é renderizado como um conjunto de anéis concêntricos ao redor da câmera, cada um com metade da resolução do anterior. Perto da câmera, você vê o terreno em resolução total. À distância, vê uma versão menos detalhada. As transições são suaves porque a geometria se transforma entre os níveis.

Essa técnica é eficiente para a GPU (uma chamada de desenho por anel), permite terrenos infinitos com uso constante de memória e funciona no WebGL 2. É o que Flight Simulator e a maioria dos jogos modernos de mundo aberto usam em algum nível.

Terreno modificado por criadores

Se os criadores puderem esculpir o terreno, será necessário armazenar e transmitir as modificações sobre o mapa de altura base. Há duas abordagens:

Mapas de altura delta armazenam a diferença entre o terreno base e o terreno modificado. A maior parte do mundo não é modificada (os deltas são zero), portanto isso gera uma compressão extremamente eficiente. Ao carregar um chunk, aplique o delta sobre a base.

Sobreposições de voxels permitem modificações mais radicais (cavernas, saliências, arcos). Um mapa de altura não consegue representar um terreno no qual um único ponto tem duas alturas. Uma grade esparsa de voxels armazenada apenas nos chunks modificados resolve isso. Marching cubes ou contorno dual geram a malha. Essa abordagem é mais cara, mas permite editar o terreno no estilo Minecraft.

Geração de mundos com IA

É aqui que os recursos existentes de IA generativa da Cinevva se tornam um multiplicador de força. Em vez de construir manualmente cada rocha e árvore, os criadores podem orientar a IA para povoar o mundo.

Geração de terreno com campos neurais

Pesquisas recentes sobre geração neural de terrenos (GET3D da NVIDIA, o modo de rede neural do Terragen e artigos como "Terrain Generation Using Procedural Models") mostram que modelos treinados podem gerar terrenos plausíveis a partir de prompts de texto ou esboços. Um criador poderia desenhar um litoral aproximado e dizer "colinas arborizadas encontrando uma costa rochosa" para obter um mapa de altura com erosão, máscaras de vegetação e atribuições de materiais adequadas.

Para disponibilização no navegador, a geração seria executada no servidor e o resultado seria transmitido. O modelo de geração não precisa ser executado no navegador. Ele produz mapas de altura e mapas de splat que o navegador pode renderizar com o pipeline de terreno padrão.

Geração de assets 3D

Modelos como Hunyuan3D, Meshy, Tripo e Rodin podem gerar malhas 3D a partir de texto ou imagens. O fluxo de trabalho para um mundo de criadores seria:

1. O criador descreve ou esboça o que deseja ("um arco de pedra coberto de musgo" ou "um poste de iluminação futurista")
2. O servidor executa o modelo de geração e produz uma malha com muitos polígonos
3. O servidor faz o processamento automático: reduz para uma contagem de polígonos adequada à web, gera LODs, incorpora as texturas em um atlas e exporta como GLB com compressão Draco
4. O asset aparece no inventário do criador, pronto para ser colocado no mundo

Esse pipeline já existe parcialmente na Cinevva. O que falta é a etapa de LOD/otimização e o sistema de posicionamento no mundo.

Povoamento procedural

Mesmo com assets gerados por IA, posicionar manualmente cada árvore de uma floresta é tedioso. Regras de distribuição procedural permitem que os criadores definam zonas ("esta área é uma floresta densa", "esta encosta é um pedregal rochoso") e o sistema as povoe automaticamente.

Shaders de computação da GPU podem executar a distribuição no navegador. Com base em um mapa de densidade e um conjunto de regras (espaçamento mínimo, restrições de inclinação, faixa de altura), uma passagem de computação gera posições de instâncias para um chunk inteiro em menos de 1 ms. Modifique o mapa de densidade, e a vegetação será gerada novamente de forma instantânea.

Sistema de Entidades e Componentes (ECS)

Um mundo aberto com milhares de objetos precisa de um sistema eficiente de gerenciamento de entidades. O padrão ECS (popular em motores de jogos desde o DOTS da Unity e o Bevy) se adapta bem ao JavaScript.

bitECS é um ECS de alto desempenho para JavaScript que usa arrays tipados e operações bit a bit. As entidades são inteiros simples. Os componentes são arrays tipados contíguos (um para cada tipo de componente). Os sistemas percorrem os arrays sequencialmente, o que favorece o uso do cache mesmo em JavaScript.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

Em um mundo aberto, o ECS cuida de tudo: personagens dos jogadores, objetos posicionados, NPCs, partículas, gatilhos e elementos de cenário. Quando um chunk é descarregado, suas entidades são removidas do ECS. Quando um chunk é carregado, as entidades são adicionadas. O ECS não se importa com a organização espacial. Ele apenas processa os componentes.

Física

A física nos navegadores ficou surpreendentemente boa graças ao WebAssembly.

Rapier (Rust -> Wasm)

Rapier é um motor de física escrito em Rust que é compilado para WebAssembly. Ele processa corpos rígidos, colisores, juntas, controladores de personagem e raycasting. Seu desempenho fica entre 2 e 3 vezes abaixo do Bullet/PhysX nativo em cargas de trabalho típicas de jogos.

Em um mundo aberto, o Rapier cuida de:

• Controlador do personagem do jogador (caminhar sobre o terreno, subir degraus, deslizar em declives)
• Colisão entre objetos (objetos posicionados, projéteis)
• Raycasting para interações do jogador (clicar em um objeto para selecioná-lo)
• Volumes de gatilho (entrar em uma área, acionar um evento)

O Rapier é executado em um Web Worker, portanto a simulação de física não bloqueia a renderização. A cada quadro, você envia posições ao renderizador e recebe de volta os eventos de entrada.

Havok para Web (via Babylon.js)

Se você optar pelo Babylon.js, a física Havok já vem integrada como um módulo Wasm. Havok é o motor de física por trás da maioria dos jogos AAA (Half-Life 2, Skyrim, Breath of the Wild). A versão Wasm tem qualidade de produção e é otimizada para o grafo de cena do Babylon.

Colisão com o terreno

Motores de física precisam de geometria de colisão para o terreno. Gerar uma malha triangular em resolução máxima para todo o terreno visível seria caro. Em vez disso, gere campos de altura de colisão apenas para os chunks próximos ao jogador (os 3x3 ou 5x5 chunks mais próximos) e use colisões simplificadas para todo o resto. O colisor de campo de altura do Rapier foi projetado exatamente para esse caso de uso.

Áudio

O som transforma um espaço 3D, fazendo-o deixar de ser uma demonstração visual e se tornar um lugar. A Web Audio API oferece tudo o que é necessário para áudio espacial em um navegador.

O áudio espacial com HRTF (função de transferência relacionada à cabeça) posiciona os sons no espaço 3D. Uma cachoeira à sua esquerda parece estar à sua esquerda. Aproxime-se e ela fica mais alta. Passe para trás de um edifício e o som fica abafado (com processamento adicional).

As zonas de ambiente funcionam como o texture splatting para áudio. Defina regiões (floresta, caverna, litoral, cidade) e faça transições graduais entre paisagens sonoras ambientes à medida que o jogador se move entre elas. É assim que Skyrim faz suas florestas parecerem vivas. Sobreponha vento, pássaros, folhas farfalhando e animais distantes. Nada disso é complexo. Tudo é espacial.

O desempenho da Web Audio é bom o bastante para dezenas de fontes espaciais simultâneas. O gargalo costuma ser o tamanho dos recursos, não o processamento. Use Opus ou AAC para áudio comprimido, transmita faixas ambientes longas e pré-carregue efeitos sonoros curtos (passos, interações).

Água, clima e atmosfera

Todo mundo aberto memorável tem água e clima. Esses sistemas definem o clima visual e fazem o mundo parecer vivo. Também são surpreendentemente viáveis em um navegador.

Renderização de água

A água em 3D no navegador tem três níveis de complexidade, e você pode lançar primeiro o mais simples e aprimorá-lo depois.

Nível 1: plano reflexivo. Uma malha plana na altura da água com um material reflexivo/refrativo. Renderize a cena de cabeça para baixo em uma textura (reflexão planar), misture-a com uma tonalidade azul e adicione mapas de normais em movimento para simular as ondas. É isso que o shader de água básico de Skyrim faz. No Three.js, o exemplo Water do repositório oficial implementa isso. No Babylon.js, o WaterMaterial oferece isso pronto para uso. Custo: uma passagem extra de renderização para os reflexos (metade da resolução é suficiente), além da renderização da superfície da água. Em uma GPU intermediária, isso acrescenta de 2 a 3 ms por quadro.

Nível 2: reflexos no espaço da tela + efeitos baseados em profundidade. Em vez de uma passagem de renderização separada para os reflexos, obtenha amostras do framebuffer existente (SSR). Adicione absorção de cor baseada em profundidade (a água fica mais escura onde é mais profunda), espuma nas margens usando comparação de profundidade e cáusticas projetadas sobre o terreno submerso. É isso que The Witcher 3 usa. O SSR está disponível tanto na pilha de pós-processamento do Three.js quanto no pipeline de renderização do Babylon.js. Custo: de 1 a 2 ms para SSR e um custo insignificante para os efeitos de profundidade.

Nível 3: simulação de oceano com FFT. Para o oceano aberto, use uma Transformada Rápida de Fourier para simular espectros de ondas na GPU. O artigo "Simulating Ocean Water" (2001), de Jerry Tessendorf, é a base usada por todos os principais motores de jogos. A FFT é executada como um compute shader no WebGPU, gerando um mapa de deslocamento e um mapa de normais a cada quadro. O oceano resultante parece extremamente convincente. É isso que Sea of Thieves, Assassin's Creed Black Flag e Uncharted 4 usam. No WebGPU, um oceano FFT de 256x256 é executado em menos de 1 ms em GPUs para desktop.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

Para um mundo de criação, comece com o Nível 1 (plano reflexivo) e avance para o Nível 2 quando o renderizador estiver mais maduro. O Nível 3 só é necessário se o mundo tiver oceano aberto.

Sistemas climáticos

O clima em Skyrim e BotW é controlado por uma máquina de estados com transições. Ensolarado > Nublado > Chuva > Tempestade > Ensolarado. Cada estado altera vários sistemas simultaneamente: skybox, densidade da névoa, cor da luz ambiente, efeitos de partículas (chuva/neve), áudio (vento, chuva) e propriedades de jogabilidade (superfícies molhadas são escorregadias em BotW).

Para um mundo no navegador, o sistema climático tem três camadas:

Renderização do céu. Um shader de céu procedural é mais econômico e flexível do que texturas de skybox. Os modelos de céu Preetham ou Hosek-Wilkie calculam cores fisicamente plausíveis para o céu usando apenas a posição do sol. Adicione uma camada de nuvens usando ruído 3D que se move por um plano. O Babylon.js tem um material de céu procedural integrado. O Three.js tem o exemplo Sky. Ambos produzem resultados convincentes com um custo insignificante para a GPU (é um único quadrilátero em tela cheia).

Efeitos de partículas. A chuva é um sistema de partículas com milhares de quadriláteros finos caindo do alto. A neve é semelhante, mas tem trajetórias mais lentas e flutuantes. A névoa é uma passagem de pós-processamento que mistura a cena com uma cor de névoa com base na profundidade. Todos esses são efeitos WebGL comuns. O custo depende da quantidade de partículas: 10.000 partículas de chuva acrescentam aproximadamente 0,5 ms por quadro.

Resposta ambiental. Superfícies molhadas aumentam a reflexão especular. O acúmulo de neve adiciona branco às superfícies voltadas para cima. Poças aparecem em terrenos côncavos. Esses são truques de shader, não alterações de geometria. Um uniform de "umidade" altera a rugosidade do material. Um uniform de "cobertura de neve" mistura branco nas superfícies cujas normais apontam para cima. GTA V e The Witcher 3 usam exatamente essa abordagem.

Clima sincronizado. Em um mundo multijogador, o clima precisa ser consistente entre os clientes. A abordagem mais simples: o servidor transmite um estado climático (incluindo o progresso da transição) a 1 Hz. Os clientes interpolam localmente. Como o clima muda lentamente (uma transição de tempo aberto para chuva leva de 30 a 60 segundos), até mesmo uma atualização atrasada parece suave.

Perspectiva atmosférica

Esta é a técnica visual mais eficaz para fazer um mundo parecer grande, e seu custo é quase nulo. Objetos distantes parecem mais enevoados, azulados e com menos contraste devido à dispersão da luz na atmosfera. Todo mundo aberto usa isso.

Em um fragment shader, misture os pixels distantes com a cor da atmosfera com base na profundidade:

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW leva isso além com uma névoa de aspecto pictórico que faz a transição para uma distância em estilo aquarela. A cor da névoa muda de acordo com a hora do dia e o clima. Esse único efeito de shader contribui mais para a sensação de escala do que qualquer quantidade de detalhes no terreno.

Para um mundo no navegador com direção de arte estilizada, a perspectiva atmosférica é o primeiro efeito visual a implementar. Ela oculta transições de LOD (objetos distantes com menos detalhes parecem adequados através da névoa), reduz o surgimento repentino visível de conteúdo transmitido e faz as capturas de tela parecerem boas mesmo antes de o mundo estar totalmente povoado.

Sistemas de avatares

Os jogadores precisam de corpos. Em um mundo de criação, o avatar é a principal forma de expressão pessoal, além daquilo que você constrói. O sistema precisa ser flexível o bastante para permitir personalização e, ao mesmo tempo, manter os custos de renderização baixos o suficiente para mais de 200 jogadores visíveis.

Arquitetura de avatares

Malha base + camadas de personalização. Comece com uma malha humanoide base compartilhada (de 1.500 a 3.000 triângulos para o corpo). A personalização ocorre por meio de:

• Variações de cor/textura (tom de pele, cor do cabelo) por meio de alterações de uniforms. Sem geometria extra.
• Partes de malha intercambiáveis (estilos de cabelo, roupas, acessórios) que substituem seções da malha base. Cada parte é uma pequena malha separada (de 200 a 500 triângulos).
• Variações nas propriedades dos materiais (armadura metálica versus túnica de tecido) por meio de alterações nos parâmetros dos materiais.

É assim que Roblox, Fortnite e VRChat processam avatares. O custo base permanece constante independentemente da personalização.

Ready Player Me e Avaturn oferecem criação de avatares no navegador com saída em modelos glTF compatíveis com qualquer motor 3D. Eles processam escaneamento facial a partir de fotos, proporções corporais e roupas. Os modelos de saída são otimizados para renderização em tempo real (normalmente de 10 mil a 20 mil triângulos, com possibilidade de redução para 3 mil a 5 mil na renderização à distância).

Animação esquelética no navegador

Todo jogador visível precisa de animações: parado, andando, correndo, pulando e emotes. A animação esquelética movimenta uma malha por meio de um conjunto de transformações de ossos a cada quadro.

O skinning na GPU é obrigatório para obter bom desempenho. Tanto o Three.js quanto o Babylon.js realizam o skinning na GPU por padrão. As matrizes dos ossos são enviadas como um buffer uniforme ou textura, e o vertex shader aplica as transformações dos ossos. O custo para a CPU vem do cálculo das transformações dos ossos a partir do clipe de animação. Para um esqueleto de 60 ossos a 30 fps, isso representa aproximadamente 0,01 ms por personagem. Para 200 personagens: 2 ms no total. Aceitável.

A mesclagem de animações combina várias animações (andar + acenar, parado + olhar ao redor) usando pesos de mesclagem. Tanto o Three.js (AnimationMixer) quanto o Babylon.js (AnimationGroup) oferecem suporte a isso. A mesclagem acontece na CPU (interpolando as transformações dos ossos) antes de o resultado combinado ser enviado à GPU.

A animação instanciada é essencial para renderizar muitos personagens com eficiência. Em vez de renderizar cada personagem como uma malha separada, grave os quadros da animação em uma textura (textura de animação de vértices, ou VAT). Cada linha da textura armazena as transformações dos ossos de um quadro. Um compute shader ou vertex shader lê a linha correta com base no tempo de animação do personagem. Isso permite renderizar centenas de personagens com uma única chamada de desenho instanciada. The Witcher 3 e Assassin's Creed usam essa técnica para renderizar multidões.

No WebGPU, personagens animados instanciados têm esta aparência:

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

Para jogadores distantes (a mais de 50 metros), mude para impostores em billboard: um quadrilátero plano exibindo um sprite pré-renderizado do personagem a partir do ângulo de visão atual. É o mesmo truque que Skyrim usa para árvores distantes, aplicado a personagens. A transição é imperceptível à distância.

Cinemática inversa para interação

Quando um personagem pega um objeto, alcança a maçaneta de uma porta ou aponta para algo, a IK procedural faz a ação parecer natural. FABRIK (Cinemática Inversa por Alcance para Frente e para Trás) é um solucionador de IK simples e rápido que funciona bem em tempo real. Tanto o Three.js (por meio de CCDIKSolver) quanto o Babylon.js (por meio de BoneIKController) têm suporte integrado a IK.

Para um mundo de criação, a IK permite que os personagens interajam naturalmente com objetos posicionados: sentar em cadeiras colocadas pelos criadores, apoiar-se em corrimãos e pegar itens. As interações não precisam de animações específicas para cada objeto. O sistema de IK adapta a pose do personagem à posição do objeto.

Redes avançadas

A arquitetura básica (WebSocket + WebRTC) foi abordada anteriormente. Veja agora mais detalhes sobre protocolos, compressão e opções de transporte mais recentes.

Protocolos de mensagens binárias

JSON sobre WebSocket desperdiça 10 vezes mais largura de banda em comparação com a codificação binária. Em um mundo multijogador em tempo real, todas as mensagens devem ser binárias. FlatBuffers (do Google) é a melhor opção para redes de jogos. Ao contrário do Protocol Buffers, o FlatBuffers oferece acesso sem cópia aos dados serializados. Você não decodifica a mensagem em objetos JavaScript. Em vez disso, lê os campos diretamente do buffer. Isso elimina as alocações e a pressão sobre o GC que o Protocol Buffers criaria em um caminho crítico. O FlatBuffers tem um gerador de código JavaScript/TypeScript.

Uma atualização de posição de jogador em FlatBuffers:

// Esquema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes por atualização de jogador
// vs. JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = mais de 80 bytes

Para 200 jogadores a 20 Hz, a diferença é 200 * 17 * 20 = 68 KB/s (binário) contra 200 * 80 * 20 = 320 KB/s (JSON). O binário é 4,7 vezes menor e evita as alocações de JSON.parse no loop crítico.

MessagePack é mais simples que FlatBuffers (sem esquema nem geração de código), mas ainda é 30–50% menor que JSON. É um bom meio-termo se você quer usar dados binários sem precisar gerenciar esquemas.

Quantização de posição e compressão delta

As posições dos jogadores não precisam da precisão de um float de 32 bits. Se o seu mundo tiver 4 km x 4 km, um inteiro sem sinal de 16 bits oferece precisão de 6 cm (4000 m / 65536). Para a maioria dos jogos, isso é indistinguível da precisão total. Isso reduz pela metade o tamanho dos dados de posição.

A compressão delta envia apenas a diferença em relação ao último estado confirmado. Se um jogador se moveu 0,5 metro desde a última atualização, o delta é um número pequeno que pode ser bem compactado. Em conjunto com a codificação de comprimento variável (deltas menores usam menos bytes), atualizações de posição típicas com compressão delta ocupam de 3 a 6 bytes, em vez de 12.

A navegação estimada reduz a frequência das atualizações. Em vez de enviar a posição a 20 Hz, envie posição + velocidade. O cliente extrapola a posição entre as atualizações. Só envie uma correção quando a posição real divergir da posição prevista além de um limite. Isso pode reduzir em 60–80% a largura de banda das atualizações de posição para jogadores que se movem em linha reta (a maior parte dos movimentos).

RuneScape usa uma versão extrema disso: o movimento dos jogadores é baseado em blocos, portanto, um comando de movimento é apenas um bloco de destino. O cliente anima localmente o caminho percorrido. Para um mundo 3D contínuo, você usaria navegação estimada suave, mas o princípio é o mesmo.

WebTransport

WebTransport é um protocolo mais recente que pode substituir tanto o WebSocket quanto o WebRTC DataChannel em redes de jogos. Ele funciona sobre HTTP/3 (QUIC) e oferece:

• Streams ordenados e confiáveis (como WebSocket, mas multiplexados, de modo que uma interrupção em um stream não bloqueia os demais)
• Datagramas não confiáveis (como UDP, para atualizações de posição que ficam imediatamente obsoletas se houver atraso)
• Streams multiplexados (streams separados para chat, estado do mundo e posições, sem bloqueio de início de fila)

É exatamente disso que redes de jogos precisam. WebSocket oferece comunicação confiável e ordenada (mas o bloqueio de início de fila prejudica a latência das atualizações de posição). WebRTC DataChannel oferece comunicação não confiável (mas a configuração é complexa e exige ICE/STUN). WebTransport oferece ambas em uma única conexão.

Compatibilidade com navegadores: Chrome, Edge e Firefox já oferecem WebTransport há algum tempo, e o Safari 26.4 adicionou suporte em março de 2026. Essa mudança levou o WebTransport ao status de Baseline, o que significa que agora ele funciona em todos os principais navegadores, inclusive no iOS, onde todos os navegadores usam WebKit. Ainda vale a pena manter um fallback para WebSocket em versões mais antigas do Safari, mas o WebTransport já pode ser amplamente utilizado.

A Cloudflare oferece suporte a WebTransport por meio de Workers, o que se encaixa em nossa infraestrutura.

Gerenciamento de interesse em escala

O desafio de rede com mais de 200 jogadores não é a largura de banda por jogador. É o problema quadrático: se cada jogador envia atualizações a todos os demais, 200 jogadores significam 200 * 199 = 39.800 mensagens de atualização por tick. O servidor precisa filtrá-las.

O gerenciamento de Área de Interesse (AOI) significa que cada jogador recebe apenas atualizações sobre entidades dentro do seu alcance de visão. A implementação usa a mesma grade espacial do sistema de chunks: quando a posição de um jogador corresponde ao chunk (3, 7), ele recebe atualizações dos chunks (2-4, 6-8), uma vizinhança de 3x3. Entidades fora desse alcance não são enviadas.

Atualizações baseadas em prioridade dentro da AOI destinam mais largura de banda às entidades importantes. Um jogador correndo em sua direção recebe atualizações a 20 Hz. Um jogador parado a 200 metros de distância recebe atualizações a 2 Hz. Um NPC sem fazer nada recebe atualizações a 0,5 Hz. O servidor mantém uma fila de prioridade por cliente e aloca largura de banda de acordo com a relevância da entidade (distância, velocidade e potencial de interação).

Dormência. Entidades que não mudam de estado por N segundos entram em dormência e deixam completamente de gerar tráfego de rede. O cliente mantém o último estado conhecido até a chegada de um evento de reativação. Em um mundo de criadores no qual a maioria dos objetos posicionados é estática, a dormência elimina a maior parte do tráfego de rede potencial.

A taxa de ticks variável do Slither.io (5 Hz à distância contra 30 Hz nas proximidades) é uma versão simplificada disso. A “dilatação do tempo” do EVE Online é a versão extrema (quando há jogadores demais em uma área, o servidor reduz a taxa de ticks do jogo para manter a consistência). Para o nosso caso de uso, uma AOI baseada em prioridades e com dormência é o equilíbrio ideal.

Gaussian Splatting e tecnologias de renderização mais recentes

A renderização tradicional de malhas (triângulos + texturas) já não é a única opção para 3D no navegador. Várias técnicas mais recentes estão se tornando viáveis para produção.

Gaussian Splatting 3D

Gaussian Splatting 3D (SIGGRAPH 2023): reconstrução fotorrealista de cenas a partir de fotografias, renderizada em tempo real no navegador. Criadores poderiam escanear objetos do mundo real com um celular e posicioná-los diretamente no mundo.

O Gaussian Splatting 3D (3DGS) reconstrói cenas 3D a partir de fotografias, representando a cena como milhões de gaussianas 3D coloridas (elipsoides orientados e coloridos). O renderizador ordena e rasteriza esses splats em vez de triângulos.

Por que isso importa para um mundo de criadores:

• A captura por fotogrametria se torna trivial. Um criador tira 50 fotos de um objeto ou local do mundo real com o celular. O processamento no servidor (por meio de ferramentas como Nerfstudio ou gsplat) produz uma cena de Gaussian splats em poucos minutos. Essa cena é carregada no navegador e apresenta um visual fotorrealista de qualquer ângulo.
• A renderização no navegador está resolvida. Várias implementações de código aberto renderizam Gaussian splats em WebGL e WebGPU. O PlayCanvas tem renderização de splats integrada. A Luma AI tem um visualizador compatível com Three.js. gsplat.js é uma biblioteca independente. O desempenho é bom: de 1 a 3 milhões de splats são renderizados a 30–60 fps em GPUs para desktop.
• O formato dos dados é compacto. Uma cena de Gaussian splats de um cômodo pode ocupar de 10 a 30 MB compactada. Objetos individuais ocupam de 1 a 5 MB. Isso é comparável a assets de malha com texturas.

A desvantagem: cenas de splats são estáticas. Não é fácil animá-las ou modificá-las. Elas funcionam bem para a composição de detalhes ambientais (uma árvore fotorrealista, uma escultura capturada do mundo real ou a fachada digitalizada de um edifício), mas não para objetos de jogo interativos. A abordagem híbrida consiste em usar splats para detalhes ambientais e malhas tradicionais para objetos interativos.

Para um mundo de criadores: permita que os criadores capturem objetos reais por meio de fotos feitas com o celular, processe-os como Gaussian splats no servidor e permita que sejam posicionados no mundo. Isso preenche a lacuna entre assets gerados por IA e objetos do mundo real. Um criador poderia escanear suas próprias obras de arte, móveis ou construções e posicioná-los diretamente no mundo compartilhado.

De campos de radiância neural (NeRFs) a malhas

NeRFs representam cenas como redes neurais que produzem cor e densidade para qualquer ponto 3D. Eles geram uma qualidade visual extraordinária a partir de fotos, mas sua renderização é cara (uma passagem completa pela rede neural para cada pixel de cada quadro).

A abordagem prática para navegadores é treinar um NeRF a partir de fotos e depois extrair uma malha usando marching cubes no campo de densidade. O resultado é uma malha tradicional de triângulos com texturas pré-calculadas, que qualquer motor para navegador pode renderizar. Ferramentas como Instant-NGP, Nerfstudio e Neuralangelo automatizam esse pipeline. A qualidade não é tão alta quanto a renderização direta do NeRF, mas é compatível com pipelines de renderização padrão.

Esse é outro caminho para criadores levarem objetos do mundo real ao mundo no navegador sem precisar de habilidades de modelagem.

Mesh shaders e renderização no estilo Nanite

O sistema Nanite da UE5 renderiza bilhões de triângulos usando mesh shaders, renderização controlada pela GPU e geometria virtual (streaming de triângulos no nível de clusters, com base na cobertura da tela). O WebGPU ainda não oferece suporte a mesh shaders, mas o princípio subjacente (renderização controlada pela GPU com descarte baseado em computação e seleção de LOD) pode ser implementado.

Um compute shader do WebGPU pode:

1. Ler todas as caixas delimitadoras dos clusters de malha (grupos de aproximadamente 64 triângulos)
2. Testar cada cluster em relação ao frustum de visualização e ao buffer de oclusão
3. Selecionar o nível de LOD apropriado com base no tamanho no espaço da tela
4. Gravar os clusters visíveis em um buffer de desenho indireto
5. Uma única chamada de desenho indireto renderiza tudo

Essa abordagem de “geometria virtual” processa milhões de triângulos com custo constante de CPU (a CPU envia uma única chamada de desenho, independentemente da complexidade da cena). É assim que a renderização no navegador acabará processando grandes mundos abertos. A implementação é complexa, mas os componentes fundamentais já existem no WebGPU.

Técnicas de shader para mundos abertos estilizados

Uma direção de arte estilizada precisa de técnicas específicas de shader. Estas são as que geram o maior impacto visual por ciclo de GPU.

Animação de folhagem pelo vento

Árvores e grama balançando ao vento fazem o mundo parecer vivo. A técnica é simples: no vertex shader, desloque as posições dos vértices usando uma combinação de ondas senoidais baseadas na posição no mundo e no tempo.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

O heightFactor garante que a base da árvore permaneça fixa no chão, enquanto o topo é a parte que mais balança. Usar a posição no mundo na função senoidal faz com que árvores adjacentes balancem em fases ligeiramente diferentes, criando um efeito natural de ondas pela floresta. BotW, Skyrim e todos os mundos abertos com vegetação usam essa técnica.

Para a grama, aplica-se o mesmo princípio, mas com frequência mais alta e comprimento de onda mais curto. Lâminas de grama instanciadas pela GPU (milhares de quadriláteros finos), com deslocamentos aleatórios de fase por instância, produzem campos convincentes a um custo mínimo. Compute shaders do WebGPU podem gerar as posições e orientações das lâminas de grama a partir de um mapa de densidade, com o efeito do vento incorporado às transformações das instâncias em cada quadro.

Toon shading/Cel shading

Se a direção de arte for estilizada (e as evidências indicam que deve ser), o cel shading é a técnica central. A ideia é quantizar a iluminação em etapas discretas, em vez de usar gradientes suaves.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

Isso produz o visual clássico de dois ou três tons. Adicione uma passagem de contorno (renderize as faces traseiras levemente expandidas ou use um pós-processamento de detecção de bordas no espaço da tela) para obter um efeito de história em quadrinhos.

O sombreamento de BotW é mais elaborado que o cel shading puro. Ele usa um gradiente suave com uma pequena transição na borda da sombra, além de uma mudança de cores quentes para frias (as sombras têm tons azulados, enquanto as áreas iluminadas são quentes). Essa abordagem híbrida parece mais natural que o toon shading estrito, mas ainda é percebida como estilizada. Ela pode ser implementada com um shader personalizado em qualquer motor 3D para navegador.

Shader de água estilizada

A água em um mundo estilizado não precisa de uma simulação realista de ondas. Uma combinação de normal maps em movimento, detecção de espuma nas bordas e cores baseadas em profundidade produz resultados visualmente coerentes com uma direção de arte no estilo BotW.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

Isso oferece cores baseadas em profundidade (águas rasas são mais claras), espuma na linha da margem animada com ruído, e tudo é executado em uma única passagem de fragment shader.

Oclusão de ambiente no espaço da tela (SSAO)

SSAO escurece cantos, fendas e áreas onde superfícies se encontram. Isso adiciona profundidade e integra os objetos à cena sem a necessidade de uma iluminação global cara. Tanto o Three.js quanto o Babylon.js têm implementações integradas de SSAO.

Em um mundo estilizado, a SSAO é ainda mais importante do que na renderização realista, pois o sombreamento plano não mostra naturalmente as sombras de contato. Uma passagem leve de SSAO (metade da resolução é suficiente) adiciona as indicações de profundidade ausentes. Custo: 1–2 ms em GPUs para desktop.

Geração de mundos em mais detalhes

O artigo-base abordou terrenos procedurais em alto nível. Aqui estão os detalhes algorítmicos.

Funções de ruído para terrenos

Todo terreno procedural começa com ruído. A função de ruído produz valores pseudoaleatórios que variam suavemente no espaço. Combine várias oitavas (frequências) para obter resultados com aparência natural.

O ruído de Perlin é o clássico. O ruído simplex é mais rápido e tem menos artefatos direcionais. O OpenSimplex 2 é a variante moderna com bom desempenho em JavaScript. Para compute shaders do WebGPU, implementar ruído simplex em WGSL é simples (são cerca de 50 linhas de matemática).

O movimento browniano fracionário (fBm) combina oitavas de ruído:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

Com 6 a 8 oitavas, o fBm produz terrenos com formações montanhosas de grande escala, colinas de média escala e rugosidade em pequena escala, muito semelhantes a terrenos reais. O parâmetro de persistência controla a rugosidade do terreno (0,3 produz colinas suaves e onduladas; 0,7 produz montanhas escarpadas).

A distorção de domínio usa a saída de uma função de ruído como coordenadas de entrada de outra. Isso produz um terreno com aparência erodida e orgânica, em vez de uniformemente acidentada. Aplique de 2 a 3 camadas de distorção de domínio e o terreno começará a parecer moldado por processos geológicos.

Simulação de erosão hidráulica

Terrenos gerados com ruído bruto parecem papel amassado. Terrenos reais parecem papel amassado sobre o qual choveu por um milhão de anos. A simulação de erosão hidráulica transforma terrenos gerados por ruído em algo geologicamente plausível.

O algoritmo:

1. Solte uma partícula de água em uma posição aleatória do mapa de altura
2. A partícula flui encosta abaixo (seguindo o gradiente do terreno)
3. A cada passo, ela retira sedimentos do terreno com base na velocidade e na inclinação
4. Quando a partícula desacelera (terreno mais plano, formação de poças), ela deposita sedimentos
5. Repita o processo para 100.000 a 500.000 partículas

O resultado é um terreno com vales fluviais, leques aluviais, linhas de crista de aparência natural e encostas suaves com transições coerentes. O algoritmo é executado em um mapa de altura de 1024x1024 em cerca de 2 a 5 segundos em JavaScript, ou em menos de 100 ms em um shader de computação WebGPU.

A implementação de Sebastian Lague (disponível no GitHub) é a referência padrão para desenvolvedores de jogos. Ela produz terrenos comparáveis a resultados esculpidos manualmente. Para um mundo de criadores, executar a erosão em terrenos gerados por IA durante a etapa de processamento no servidor faria as paisagens geradas proceduralmente parecerem feitas à mão.

Atribuição de biomas

Mundos reais têm biomas: florestas, desertos, tundras e pântanos. A atribuição de biomas mapeia parâmetros climáticos para regiões do terreno.

A abordagem do Minecraft é instrutiva: defina os biomas em uma grade 2D usando os eixos de temperatura e umidade. A temperatura diminui com a altitude e a latitude. A umidade varia de acordo com a proximidade da água e a direção predominante dos ventos. Cada célula da grade recebe um bioma (floresta, deserto, tundra etc.), que determina as texturas do terreno, o tipo e a densidade da vegetação, o áudio ambiente e os padrões climáticos.

Em um mundo de criadores, os limites dos biomas devem poder ser pintados. O sistema gera biomas padrão com base nas propriedades do terreno, mas os criadores podem substituir essa atribuição pintando zonas de bioma em seus lotes. Essa abordagem híbrida dá ao mundo uma aparência natural por padrão, enquanto permite que os criadores expressem sua visão.

Wave Function Collapse para estruturas

Wave Function Collapse (WFC) gera estruturas (edifícios, masmorras e estradas) a partir de um conjunto de peças com restrições de adjacência. Dado um conjunto de peças modulares de construção e regras que definem quais peças podem se conectar, o WFC pode gerar vilas inteiras, plantas de castelos ou mapas de masmorras.

Para um mundo de criadores, o WFC permite:

• Vilas geradas automaticamente para preencher o mundo com conteúdo básico antes que os criadores o personalizem
• Construção assistida, em que um criador posiciona algumas peças e o WFC preenche as lacunas (como no Townscaper, mas com blocos de construção 3D)
• Geração de masmorras para experiências interativas que os criadores podem configurar (defina o tema, a dificuldade e o tamanho, e o WFC gera o layout)

Oskar Stalberg (criador de Townscaper e Bad North) demonstrou que a geração baseada em WFC parece mágica para os usuários. Eles posicionam alguns blocos e o sistema gera estruturas esteticamente coerentes ao redor. Esse é exatamente o princípio de "ferramentas simples, resultados ricos" que funciona bem em plataformas de criação.

Arquitetura de moderação de conteúdo

Em um mundo onde os criadores podem posicionar qualquer conteúdo 3D que outras pessoas veem, a moderação não é opcional. Ela é um componente central da infraestrutura.

Pipeline de triagem automatizada

Todo recurso que entra no mundo passa por um pipeline de várias etapas antes de se tornar visível para outros jogadores:

1. Análise de geometria. Examine a malha em busca de formas anatomicamente explícitas usando um classificador treinado. Isso detecta a maioria dos modelos 3D obviamente inadequados. Várias APIs comerciais (Azure Content Safety, Google Cloud Vision para 3D) fazem isso. O classificador é executado sobre a silhueta da malha vista de vários ângulos, o que exige pouco processamento.

2. Análise de texturas. Passe cada textura por uma API padrão de moderação de conteúdo de imagens (as mesmas usadas para fotos enviadas). Isso detecta imagens inadequadas aplicadas como texturas a geometrias que, por si só, seriam inofensivas.

3. Detecção de texto. Se o objeto contiver texto (na textura ou como uma malha de texto 3D), execute OCR e verifique-o em relação à política de conteúdo. Isso detecta discurso de ódio, insultos e outras violações baseadas em texto.

4. Aprovação automatizada. Se todas as verificações forem aprovadas, o recurso torna-se visível imediatamente. Se alguma verificação sinalizar o recurso, ele entra em uma fila de análise.

5. Análise humana. Os recursos sinalizados são analisados por um moderador. Em uma plataforma pequena, a própria equipe pode cuidar disso. Em grande escala, podem ser contratados serviços de moderação (os mesmos que moderam conteúdo em redes sociais).

Moderação espacial

Além dos recursos individuais, a disposição espacial dos objetos pode ser inadequada mesmo quando cada objeto isoladamente é aceitável. Isso é mais difícil de detectar automaticamente. A abordagem prática:

• Denúncias de jogadores. Qualquer jogador pode denunciar um local. A denúncia inclui uma captura de tela (feita automaticamente nas coordenadas denunciadas) e a conta do jogador que fez a denúncia. As denúncias acionam uma análise humana.
• Mapeamento de calor. Monitore quais áreas geram denúncias. Se o lote de um criador gerar denúncias com frequência, encaminhe-o para análise. Se for constatado que um criador viola repetidamente as regras, restrinja suas permissões de edição.
• Classificações de lotes. Como no Second Life, permita que os criadores classifiquem seus próprios lotes. A visualização padrão oculta lotes classificados acima de "Geral". Os jogadores podem optar por ver conteúdo adulto. Isso não impede violações, mas reduz a exposição.

Considerações sobre latência

Se a triagem automatizada levar de 5 a 10 segundos por recurso, haverá um atraso perceptível entre o criador posicionar um objeto e ele aparecer para outros jogadores. Opções:

• Exibição local otimista. O criador vê o objeto posicionado imediatamente. Outros jogadores o veem após a aprovação. Se o recurso for rejeitado, ele desaparece e o criador é notificado.
• Biblioteca de recursos pré-aprovados. A maioria dos posicionamentos usa recursos previamente examinados da biblioteca da plataforma (incluindo recursos gerados por IA e examinados durante a geração). Envios personalizados passam pela triagem. Isso significa que a maioria dos posicionamentos é instantânea.
• Aprovação acelerada baseada em reputação. Criadores com um histórico de conteúdo aprovado recebem aprovação automática para novos posicionamentos. Novos criadores ou criadores sinalizados passam pela triagem completa.

Desempenho 3D no navegador: números reais

Orçamentos teóricos são úteis. O desempenho real medido é ainda mais útil. Veja números reais de cenas 3D em navegadores executadas em hardware de produção.

Benchmarks de renderização

Cena Three.js com 10.000 objetos instanciados (árvores, pedras, cada um com 500 triângulos):

• MacBook Pro M1 (Chrome, WebGL2): 58-60fps
• Desktop com RTX 3060 (Chrome, WebGL2): 60fps fixos
• Notebook com Intel UHD 620 (Chrome, WebGL2): 25-35fps
• iPhone 13 (Safari, WebGL2): 30-40fps

Cena Three.js com 100.000 folhas de grama instanciadas (6 triângulos cada, 600 mil triângulos no total):

• MacBook M1: 55fps
• RTX 3060: 60fps
• Intel UHD 620: 12fps
• iPhone 13: 15fps

Terreno Babylon.js com 1 milhão de triângulos, 4 níveis de LOD e física Havok:

• MacBook M1 (WebGPU): 60fps
• MacBook M1 (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps
• RTX 3060 (WebGL2): 55fps

Cena de Gaussian splatting, 2 milhões de splats (via gsplat.js):

• MacBook M1 (WebGL2): 30fps
• RTX 3060 (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps

Medições de memória

Cena Three.js mínima (skybox, terreno, 100 objetos): 80-120 MB de memória da GPU, heap JS de 150-200 MB Babylon.js com física Havok: 200-300 MB de memória da GPU, heap JS de 250-350 MB (o Havok Wasm acrescenta cerca de 50 MB) Limites de memória das abas do navegador (medidos, não documentados):

• Chrome para desktop: normalmente trava perto de 4 GB
• Chrome para Android: normalmente trava perto de 1-1,5 GB
• Safari para iOS: normalmente trava perto de 1 GB
• Firefox para desktop: normalmente trava perto de 3-4 GB

Medições de rede

Latência de ida e volta do WebSocket (do navegador até a borda da Cloudflare):

• Mesmo continente: 10-30ms
• Entre continentes: 80-200ms
• Com Cloudflare Durable Objects: acrescente 5-10ms para a ativação do DO na primeira solicitação

Latência do WebRTC DataChannel (de navegador para navegador via TURN):

• Mesma cidade: 5-15ms
• Mesmo continente: 20-50ms
• Entre continentes: 100-250ms

A latência do WebTransport (HTTP/3 QUIC) é comparável à do WebSocket, mas sem bloqueio do início da fila, portanto a latência P99 é significativamente melhor (sem interrupções causadas pela perda de um único pacote).

Medições de tempo de carregamento

Cena Three.js vazia (apenas a biblioteca): 350ms até o primeiro quadro Cena Babylon.js vazia: 500ms até o primeiro quadro Modelo GLB de 1 MB via fetch + análise: 200-400ms em banda larga Textura KTX2, 1024x1024, Basis Universal: 50-100ms para decodificar na GPU Malha compactada com Draco, 50 mil triângulos: 30-80ms para decodificar em um Web Worker

Esses números confirmam que o orçamento de desempenho da seção de arquitetura é viável. Um desktop intermediário pode renderizar uma cena complexa de mundo aberto a 60fps. Dispositivos móveis são a limitação: seria necessário usar LOD agressivo e uma distância de visão menor para manter 30fps em celulares.

A stack completa

Reunindo tudo, esta é a arquitetura de um mundo aberto multijogador para criadores baseado em navegador:

Cliente (navegador)

Camada	Tecnologia	Função
Renderizador	Babylon.js (WebGPU + WebGL2 como fallback)	Renderização da cena, terreno, LOD, pós-processamento
Terreno	Sistema personalizado de mapas de altura + Babylon DynamicTerrain	Terreno transmitido por chunks com splatting
Física	Rapier (Wasm) ou Havok (via Babylon)	Controlador de personagem, colisão, raycasting
ECS	bitECS	Gerenciamento de entidades para todos os objetos do mundo
Rede	WebSocket + WebRTC DataChannel	Sincronização de estado, atualizações de posição, chat por voz
Estado	Yjs (CRDT)	Edição colaborativa do mundo, resolução de conflitos
Áudio	Web Audio API	Áudio espacial, ambientação, música
IU	Sobreposição HTML/CSS	HUD, inventário, chat, ferramentas de criação
Workers	Web Workers	Descompactação de recursos, física, geração de terreno

Servidor

Camada	Tecnologia	Função
Shards do mundo	Cloudflare Durable Objects	Estado autoritativo por chunk, endpoints WebSocket
Armazenamento de recursos	Cloudflare R2	Modelos GLB, texturas KTX2, mapas de altura, áudio
CDN de recursos	Cloudflare CDN (bucket público do R2)	Entrega de recursos do mundo armazenados em cache na borda
Geração por IA	Instâncias de GPU (Hetzner/Lambda/RunPod)	Geração de modelos 3D, terrenos e texturas
Pipeline de recursos	Cloudflare Queue + Workers	Geração de LOD, otimização de malhas, conversão de formatos
Autenticação	Auth0	Identidade e permissões dos criadores
Banco de dados	Cloudflare D1	Metadados do mundo, inventários dos criadores, permissões
Tempo real	Cloudflare Durable Objects + Pub/Sub	Presença de jogadores, chat, transmissão de eventos

Fluxo de dados

1. O jogador abre o mundo no navegador
2. O cliente se autentica e se conecta ao Durable Object mais próximo referente ao chunk de surgimento
3. O DO envia o estado atual do chunk (terreno + objetos + jogadores próximos)
4. O cliente começa a renderizar e solicita os chunks adjacentes ao R2/CDN
5. Conforme o jogador se move, o cliente se conecta aos DOs adjacentes e se desconecta dos mais distantes
6. O criador posiciona um objeto: o cliente envia a edição ao DO, que a valida e a transmite a todos os clientes conectados por meio de um delta CRDT
7. O DO persiste o estado do chunk no armazenamento a cada edição (com debounce)
8. Outros jogadores veem o novo objeto aparecer em 100-200ms

Orçamento de desempenho

Para uma experiência a 60fps em um desktop intermediário (RTX 3060 / Mac M1 / 16 GB de RAM):

Recurso	Orçamento	Observações
Chamadas de desenho	< 500 por quadro	Agrupamento, instanciamento, LOD
Triângulos	< 2 milhões por quadro	O LOD mantém esse número sob controle
Memória de texturas	< 512 MB	Compactação KTX2, streaming, agrupamento em atlas
Memória de geometria	< 256 MB	Buffers compartilhados, pooling, descarregamento agressivo
Heap JavaScript	< 512 MB	O ECS usa arrays tipados, não objetos
Rede	< 500 KB/s contínuos	Compactação de deltas, filtragem por relevância espacial
Carregamento inicial	< 10 MB, < 5 segundos	Carregamento progressivo, terreno primeiro
Carregamento de chunk	< 200 KB, < 200ms	Pré-carregamento de chunks adjacentes

Jogos de navegador bem-sucedidos e o que eles comprovam

Jogos de navegador não são um nicho. Eles constituem um dos maiores mercados de jogos. A Poki atende mais de 100 milhões de jogadores por mês. CrazyGames, Newgrounds e itch.io atendem outros milhões. Os jogos que fazem sucesso nos navegadores têm padrões arquitetônicos específicos que merecem ser estudados.

Jogos 3D de navegador disponíveis hoje

Hordes.io: mais de 200 jogadores em um MMO 3D persistente no navegador. WebGL personalizado, estilo low-poly, carrega em menos de 5 segundos. Criado por um único desenvolvedor.

**Hordes.io** é o MMO de navegador mais relevante. Criado por um desenvolvedor solo com renderização WebGL própria, ele coloca mais de 200 jogadores em um mundo 3D persistente com combate em tempo real, guildas, classes e PvP. O jogo inteiro carrega em menos de 5 segundos. O mundo é dividido em zonas com descarte agressivo. Os modelos dos jogadores são simples (low-poly com sombreamento plano), mas os efeitos de partículas e as animações fazem o combate parecer responsivo. Hordes.io prova três coisas: MMOs de navegador podem comportar centenas de jogadores simultâneos em uma única cena, um desenvolvedor solo pode criar um e gráficos estilizados têm melhor desempenho do que gráficos realistas em um navegador.

Krunker.io: 10 milhões de jogadores mensais, criado com Three.js, com um editor de mapas completo no navegador e um marketplace de conteúdo gerado por usuários.

Krunker.io atingiu um pico de mais de 10 milhões de jogadores mensais e foi adquirido pela FRVR. É um FPS de navegador com editor de mapas completo, modos de jogo personalizados, conteúdo gerado por usuários e um marketplace. Criado com Three.js, ele roda a mais de 60 fps mesmo em hardware de baixo desempenho graças ao estilo visual blocado e à otimização agressiva. O editor de fases é particularmente relevante. Os jogadores criam mapas usando um sistema de blocos semelhante a voxels, compartilham-nos no marketplace e outras pessoas jogam neles. Esse é o ciclo de criação de mundos em miniatura: criar algo, compartilhar e permitir que outras pessoas vivenciem a criação. Krunker provou que conteúdo 3D gerado por usuários pode funcionar em um navegador se as ferramentas de criação forem simples o bastante.

ev.io é um FPS de navegador criado com Babylon.js. Ele roda bem na maioria dos hardwares, oferece suporte a mapas personalizados e demonstra que o renderizador WebGL do Babylon consegue processar ação 3D acelerada em uma aba do navegador. O jogo usa compressão agressiva de texturas e ambientes low-poly para permanecer dentro dos limites de desempenho.

Shell Shockers (mais de 5 milhões de jogadores mensais) é um jogo de tiro 3D multijogador no qual você joga como ovos. Criado com Three.js, ele oferece multijogador em tempo real com detecção de acertos responsiva no navegador. O estilo visual cartunesco mantém os requisitos de assets mínimos, sem deixar de apresentar um acabamento refinado.

Townscaper: clique para posicionar construções e o sistema gera automaticamente ruas, arcos e escadas. Sem menus, sem objetivos. Vendeu mais de 1 milhão de cópias com base puramente na alegria de criar.

Townscaper não é um jogo de navegador, mas sua abordagem à construção de mundos é extremamente relevante. Os jogadores clicam para posicionar construções sobre uma superfície aquática. O jogo gera automaticamente detalhes arquitetônicos, ruas, arcos e escadas com base nos padrões de posicionamento. Sem menus, sem configurações, sem objetivos. Basta clicar e construir. Ele vendeu mais de 1 milhão de cópias. A lição: às vezes, as ferramentas criativas mais simples produzem as experiências mais envolventes. Se conseguirmos tornar o posicionamento de objetos no mundo tão imediato quanto em Townscaper, os criadores passarão horas construindo.

Experiências com A-Frame / 8th Wall. O A-Frame (criado com Three.js) viabiliza milhares de experiências 3D na web. O 8th Wall, a longeva plataforma de WebAR adquirida pela Niantic, demonstrou que experiências complexas de RA baseadas em câmera rodam em navegadores móveis sem plugins, embora a Niantic tenha anunciado no final de 2025 que está descontinuando gradualmente o serviço (as experiências hospedadas continuarão disponíveis até 2027). Não são jogos, mas demonstram que renderização 3D complexa com física e interação funciona em uma aba do navegador sem plugins. Muitas dessas experiências carregam em 2 a 3 segundos e rodam em celulares intermediários.

Vuntra City: um laboratório ativo de cidade procedural

Vuntra City é um projeto nativo em UE5, não um jogo de navegador, portanto não é uma referência direta de desempenho para nossa stack. Ainda assim, é um dos estudos de caso públicos mais úteis para nossa arquitetura de mundo aberto, pois os diários de desenvolvimento são excepcionalmente específicos sobre as decisões de projeto dos sistemas sob a pressão de uma produção real.

Uma conclusão importante é a política de detalhes baseada na velocidade. Nos vídeos sobre transporte e otimização, o deslocamento em alta velocidade ocorre acima dos telhados, enquanto o nível de detalhes do mundo diminui conforme a velocidade aumenta, evitando que o gerenciador de streaming fique sobrecarregado com a constante entrada e saída de interiores (transporte rápido, técnicas de otimização). Isso se encaixa perfeitamente em nosso plano para o navegador, no qual a velocidade deve controlar diretamente o raio de pré-carregamento, o alcance de ativação dos interiores e o orçamento de instanciação por quadro.

Outra conclusão é a separação rígida entre dados de topologia e objetos renderizados. A implementação de mapas e endereços usa um controlador de topologia global capaz de responder a consultas de localização e endereço em regiões não carregadas (mapas e endereços). Esse é exatamente o padrão de que precisamos para roteamento autoritativo no servidor, consulta de pontos de interesse e consultas em escala mundial que não devem depender do que um determinado cliente mantém atualmente na memória.

O trabalho com NPCs também é extremamente relevante. O sistema de um milhão de NPCs calcula globalmente um estado simplificado de agenda e só então simula comportamentos custosos no espaço adjacente ao jogador (um milhão de NPCs persistentes, bastidores). Para nós, isso reforça um modelo de simulação em duas camadas: estado distante barato e determinístico, comportamento próximo e rico dentro da AOI.

Por fim, o design de ambientes de Vuntra City reforça algo fácil de esquecer no planejamento técnico: o design de distribuição é design de conteúdo. O projeto evita posicionamento aleatório uniforme, usa ocorrências atípicas ponderadas para criar surpresa e estimula a descoberta por meio de mapas e endereços diegéticos, em vez de marcadores onipresentes no minimapa (ambientes procedurais não precisam ser entediantes, para onde vamos, não precisaremos de um minimapa).

Jogos de navegador que se tornaram gigantes

Agar.io (2015) provou que jogos multijogador de navegador podem alcançar milhões de pessoas. Em seu auge, tinha mais de 100.000 jogadores simultâneos distribuídos entre os servidores. O jogo é 2D e mecanicamente simples (crescer absorvendo células menores), mas sua arquitetura de rede comporta uma enorme quantidade de jogadores simultâneos por meio do particionamento espacial. Cada servidor executa uma região do mundo do jogo. Os jogadores recebem apenas atualizações sobre entidades dentro de seu campo de visão. Esse é o mesmo padrão de gerenciamento de interesse necessário para um mundo aberto 3D, apenas em 2D.

Slither.io aproveitou o sucesso de Agar.io e provou que o modelo é escalável. Chegou a 67 milhões de usuários ativos mensais em seu auge. O jogo usa WebSocket para sincronização de posição em tempo real e particionamento espacial para limitar o tráfego de rede. Um detalhe digno de nota: a detecção de colisões no servidor de Slither.io roda com uma taxa de ticks menor para jogadores distantes (5 Hz) do que para os próximos (30 Hz). Essa taxa de ticks variável conforme a distância pode ser aplicada a um mundo aberto 3D.

Surviv.io era um battle royale de navegador que alcançou 50 milhões de jogadores mensais antes de ser adquirido pela Kongregate. Ele executava uma partida completa de battle royale para 80 jogadores inteiramente no navegador, com física em rede em tempo real, ambientes destrutíveis e coleta de itens. O mapa era organizado proceduralmente a partir de modelos de construções previamente projetados, um padrão que poderíamos usar para estruturas posicionadas por criadores.

Zombs Royale executava um battle royale para 100 jogadores no navegador, com carregamento rápido e rede responsiva. Assim como Surviv.io, ele provou que grandes quantidades de jogadores em jogos de navegador em tempo real são comercialmente viáveis, não apenas tecnicamente possíveis.

O ponto em comum entre todos esses sucessos de navegador: eles carregam rapidamente (em menos de 5 segundos), funcionam em qualquer dispositivo, têm um estilo visual simples, mas consistente, e usam redes otimizadas para a jogabilidade específica (particionamento espacial, taxas de atualização variáveis e descarte agressivo do estado distante).

RuneScape: um MMO que migrou para o navegador

RuneScape: um MMO completo com mais de 20 anos de conteúdo rodando em uma aba do navegador. Protocolo binário próprio, streaming baseado em tiles e 2.000 jogadores simultâneos por servidor. A prova de que MMOs de navegador funcionam em grande escala.

RuneScape é o estudo de caso mais importante para um mundo aberto no navegador porque isso realmente aconteceu. A Jagex transferiu um MMO inteiro com 20 anos de conteúdo para o navegador.

RuneScape rodava originalmente como um applet Java. Quando os navegadores deixaram de oferecer suporte a Java, a Jagex refez o cliente em C++ e também lançou um cliente HTML5/WebGL totalmente funcional. Old School RuneScape (a versão retrô) agora roda inteiramente no navegador por meio de um cliente compilado com Emscripten para WebAssembly. O jogo comporta grandes mundos persistentes, multijogador em tempo real com centenas de jogadores por servidor, uma economia com um grande mercado funcional (casa de leilões) e 23 habilidades com sistemas profundos de progressão.

Detalhes técnicos importantes:

• O mundo é dividido em quadrados de mapa (regiões de 64x64 tiles). O cliente carrega uma grade de regiões de 13x13 ao redor do jogador (104x104 tiles visíveis). Regiões fora dessa grade são completamente descartadas.
• O terreno é baseado em tiles, com valores de altura em cada canto do tile. As sobreposições de terreno (caminhos, margens de água e transições de praia) usam um sistema de formas com 12 variações de rotação para cada forma. Isso é mais restrito do que um mapa de altura, mas é extremamente compacto e rápido para transmitir por streaming.
• O protocolo de rede é binário e próprio, sobre WebSocket. Cada tipo de pacote tem uma estrutura definida. As atualizações de posição dos jogadores usam 2 bytes para as coordenadas do quadrado do mapa e codificação de comprimento variável para o tipo de movimento. Eventos de chat, comércio e combate têm seus próprios formatos binários compactos. Todo o protocolo é altamente otimizado para consumir o mínimo de largura de banda.
• A renderização de objetos usa um sistema de modelos no qual o servidor envia um ID de modelo e o cliente renderiza o modelo em cache. A maioria dos modelos é carregada uma vez e reutilizada. Isso significa que o mundo é transmitido por streaming como metadados (qual modelo deve ser colocado em qual lugar), em vez de transmitir geometria.
• Cada instância de servidor comporta 2.000 jogadores simultâneos em todo o mundo do jogo. O mundo não é fragmentado espacialmente. Um único processo de servidor gerencia todos os jogadores, todos os NPCs e toda a lógica do jogo em um tick de 600 ms. Isso funciona porque a lógica por tick é simples: processar ações dos jogadores, atualizar a IA dos NPCs, resolver combates e transmitir alterações de estado.

O que RuneScape prova para nosso caso: um MMO completo com estado de mundo persistente, milhares de jogadores, sistemas de jogo complexos e uma economia real pode rodar em uma aba do navegador. O cliente baixa menos de 50 MB, carrega em poucos segundos e roda em notebooks. Se um MMO Java de 20 anos conseguiu fazer a transição, um mundo projetado especificamente para o navegador terá ainda menos restrições.

Onde a abordagem de RuneScape não se encaixa: a renderização de RuneScape é isométrica, com câmera fixa, e não 3D em primeira ou terceira pessoa. A fidelidade visual é baixa para os padrões modernos. Além disso, o mundo não pode ser editado por criadores. No entanto, a arquitetura de rede, o streaming baseado em tiles e a prova de que MMOs de navegador retêm jogadores por décadas são diretamente relevantes.

Habbo Hotel: espaços sociais que duraram 25 anos

Habbo Hotel foi lançado em 2000 e continua em operação. É um mundo social isométrico 2D no qual os usuários criam e decoram quartos, visitam os quartos de outras pessoas e socializam. Em seu auge, tinha 9 milhões de usuários mensais. Toda a experiência rodava em Flash (agora em HTML5, após a descontinuação do Flash).

Habbo é importante pela longevidade de sua comunidade de criadores. O sistema de quartos é, na prática, uma versão 2D do que estamos construindo: os usuários posicionam móveis em uma grade, personalizam o layout e convidam outras pessoas para visitar. O modelo econômico (os usuários compram móveis virtuais com dinheiro real) gerou mais de US$ 1 bilhão em receita ao longo de sua existência.

O que Habbo ensina:

• Espaços divididos em salas com interiores criados por usuários podem funcionar como plataforma social por décadas se as ferramentas de criação forem simples e os recursos sociais forem robustos.
• Uma economia de móveis virtuais sustenta o engajamento de longo prazo. Os usuários compram, trocam e colecionam itens. Os itens não têm utilidade na jogabilidade. São puramente formas de expressão pessoal e status.
• A moderação em espaços sociais exige investimento constante. Habbo passou por várias crises de moderação. Filtragem automatizada de conteúdo, moderadores humanos e denúncias da comunidade são a abordagem mínima viável.
• A transição do Flash para HTML5 (concluída por volta de 2020-2021) provou que um grande mundo social pode migrar sua tecnologia de renderização sem perder a comunidade. Os usuários se importam com seus quartos e amigos, não com a tecnologia subjacente.

Among Us e jogos sociais espaciais

Among Us não é um mundo aberto, mas seu sucesso revelou algo importante sobre espaços multijogador: os jogadores querem estar juntos em um lugar, não apenas participar juntos de um jogo. Os mods de chat por proximidade espacial que viralizaram mostraram que estar na mesma sala virtual com áudio direcional transforma o multijogador, deixando de ser apenas uma mecânica de jogo para se tornar uma experiência social. Recursos sociais espaciais que aprimoram um mundo de criadores:

• Chat de voz por proximidade, no qual o volume diminui com a distância. Aproxime-se de alguém para conversar. Afaste-se, e a voz da pessoa vai diminuindo. Isso cria grupos sociais naturais sem exigir o gerenciamento de canais de voz.
• Sistemas de emotes e gestos permitem que os jogadores se expressem sem usar a voz. Um aceno, uma dança, um gesto de apontar. São baratos de implementar (animações no avatar do jogador) e aumentam o engajamento social de forma desproporcional.
• Atividades compartilhadas que acontecem dentro do mundo (e não por meio de menus) transformam um espaço em um ponto de encontro. Se dois criadores podem se sentar a uma mesa virtual e observar modelos 3D juntos, o mundo passa a ter uma razão para existir além de exibir conteúdo estático.

Jogos de navegador que cresceram na Poki e na CrazyGames

Juntas, a Poki e a CrazyGames atendem a mais de 150 milhões de jogadores por mês. Os jogos com melhor desempenho nessas plataformas oferecem pistas sobre o que funciona especificamente no navegador.

Padrões de melhor desempenho em portais de jogos para navegador:

• Início instantâneo (menos de 3 segundos até ser possível interagir). Sem exigir login. Sem exigir tutorial. O jogo deve ser compreensível em até 5 segundos após o acesso.
• Flexibilidade de sessão. Os jogadores entram por 2 minutos ou por 2 horas. O jogo comporta ambos os casos. Para um mundo de criadores, isso significa que deve ser possível explorá-lo sem se comprometer com uma sessão. Andar, ver coisas interessantes e sair. Ou ficar e construir por horas.
• Compatibilidade com dispositivos móveis. Mais de 60% do tráfego da Poki vem de dispositivos móveis. Um mundo no navegador que só funciona em computadores perde a maioria dos visitantes em potencial.
• Recursos sociais que não exigem amigos. Placares, reações ao conteúdo de outros jogadores e recursos assíncronos (ver o que outros jogadores construíram sem precisar estar online ao mesmo tempo).

Os jogos 3D de maior sucesso nesses portais (como Shell Shockers, 1v1.LOL e Smash Karts) mantêm a contagem de polígonos baixa, as texturas simples e a taxa de quadros alta. Eles provam que os jogadores aceitam gráficos simples quando a experiência é fluida e responsiva.

Plataformas de criação baseadas no navegador

Hubs da Mozilla (agora mantido pela comunidade). Espaços 3D multiusuário no navegador, desenvolvidos com Three.js e A-Frame. Oferece chat de voz, avatares e objetos compartilhados. Não é um mundo aberto (baseia-se em salas), mas suas arquiteturas de rede e renderização são relevantes. A Mozilla tornou o projeto open source antes de encerrar o serviço hospedado, portanto todo o código-fonte está disponível para estudo. GitHub.

Hyperfy. Uma plataforma de metaverso baseada na web que roda inteiramente no navegador. Renderização com Three.js, modo multijogador, personalização de avatares e construção de mundos. Está mais próxima do nosso objetivo do que o Hubs porque enfatiza as ferramentas para criadores. Os mundos são carregados em uma aba do navegador sem exigir downloads. hyperfy.io.

Ethereal Engine (anteriormente XREngine). Engine open source para mundos multiusuário, desenvolvida com Three.js e bitECS. Oferece suporte a WebXR, áudio espacial e edição de mundos. Inclui arquitetura ECS, camada de rede e ferramentas de edição. É o projeto open source existente mais próximo do que estamos descrevendo. Vale estudá-lo para entender como integra bitECS ao Three.js no gerenciamento de entidades e como sua rede lida com o estado espacial. GitHub.

Dusk (anteriormente Rune). SDK multijogador para jogos web. Cuida da camada de rede para que os desenvolvedores possam se concentrar na jogabilidade. Sua abordagem de sincronização usa estado previsto com reconciliação do servidor, que é o modelo padrão para experiências multijogador responsivas. O SDK abstrai a complexidade do código de rede com rollback. Vale estudá-lo por sua experiência de desenvolvimento.

Niantic Studio. Um editor visual baseado no navegador e uma engine de jogos web (sucessor das ferramentas da 8th Wall) para criar experiências 3D e XR que outras pessoas podem visitar em um navegador. Ele demonstra que criadores sem conhecimento técnico podem desenvolver cenas 3D no navegador quando as ferramentas são acessíveis. (A Niantic separou seu trabalho geoespacial na Niantic Spatial e vendeu sua divisão de jogos, incluindo o Pokemon GO, para a Scopely em 2025.)

PlayCanvas Editor. Não é um jogo, mas o editor 3D baseado em nuvem da PlayCanvas mostra que ferramentas colaborativas de construção de mundos podem rodar no navegador. Vários membros da equipe editam a mesma cena simultaneamente. O editor comunica as alterações por meio de uma camada de sincronização em tempo real. Esse é o modelo de criação colaborativa de que precisaríamos, mas com nosso mundo como tela em vez de um editor de jogos.

Plataformas nativas de criação (lições para o navegador)

Essas plataformas rodam como aplicativos nativos, mas suas decisões de design relacionadas a ferramentas para criadores, persistência do mundo e dinâmicas sociais são diretamente aplicáveis.

Roblox: mais de 80 milhões de usuários diários, US$ 740 milhões pagos a criadores em 2023. A criação acontece dentro da engine. A descoberta é social. O modelo de negócios que prova que plataformas de criação podem se sustentar.

Roblox é a referência mais importante para um mundo de criadores. Mais de 80 milhões de usuários ativos diários. Os criadores desenvolvem experiências 3D completas (jogos, espaços sociais e lojas) que outros jogadores visitam. A plataforma cuida da hospedagem, rede, descoberta e monetização.

O que o Roblox faz bem:

• A criação acontece dentro da engine. O Roblox Studio é o mesmo ambiente que os jogadores vivenciam. Os criadores testam seu trabalho instantaneamente. Não há um ciclo de exportar, enviar e esperar. Em um mundo de navegador, o editor deve ser o próprio mundo.
• A programação é acessível. Lua (a linguagem de programação do Roblox) é simples o bastante para crianças aprenderem. Comportamentos complexos são possíveis, mas opcionais. A barreira de entrada é baixa e o potencial é alto.
• A descoberta é social. Você encontra experiências porque seus amigos estão jogando. A página inicial mostra experiências em alta. Em um mundo de navegador, o próprio mundo é a superfície de descoberta. Você explora e encontra coisas ao caminhar.
• A monetização funciona. Os criadores ganham dinheiro de verdade (o Roblox pagou US$ 740 milhões a criadores em 2023). Isso atrai um trabalho criativo sério. Sem incentivo econômico, as plataformas de criação viram projetos amadores que acabam desaparecendo.
• A engine de renderização do Roblox é proprietária e roda em um aplicativo nativo, não em um navegador. Mas os orçamentos de recursos por experiência são modestos para os padrões atuais (recomenda-se no máximo 100 MB). A maioria das experiências de sucesso no Roblox usa arte estilizada low-poly, o que está alinhado às limitações de renderização do navegador.

Fortnite Creative / UEFN (Unreal Editor for Fortnite). A Epic levou o editor completo da Unreal Engine aos criadores do Fortnite. O resultado é uma plataforma em que as pessoas constroem ilhas (mundos independentes) usando ferramentas profissionais. O Fortnite cuida da hospedagem, do modo multijogador e da distribuição.

Conclusões relevantes:

• Ferramentas profissionais atraem conteúdo profissional. O UEFN produz experiências visualmente impressionantes porque os criadores têm acesso a todos os recursos da UE5. A contrapartida é a complexidade. O UEFN tem uma curva de aprendizado acentuada.
• Instanciamento baseado em ilhas (cada criação é um mundo separado) evita os problemas de moderação e conflito de um único mundo compartilhado. Mas também significa que os criadores não descobrem naturalmente o trabalho uns dos outros pela exploração. Você visita ilhas por meio de menus, não caminhando.
• O modelo de negócios funciona. O programa de criadores do Fortnite paga com base no engajamento. Os principais criadores ganham milhões por ano. Novamente, o incentivo econômico impulsiona a qualidade.

Dreams (Media Molecule / PlayStation). Dreams ofereceu aos jogadores de console um conjunto completo de ferramentas de criação 3D (modelagem, animação, música, lógica e design de níveis) e uma plataforma para compartilhar criações. Em termos de profundidade das ferramentas, é a plataforma de criação mais ambiciosa já desenvolvida.

Conclusões relevantes:

• Modelagem baseada em escultura em vez de edição de polígonos. Os criadores moldam volumes suaves com ferramentas de mover, agarrar e suavizar, de forma semelhante ao ZBrush, porém mais intuitiva. A curva de aprendizado é suave. Essa abordagem se adapta bem à criação no navegador porque não exige compreender vértices e mapas UV.
• Tudo é um recurso compartilhado. Se alguém cria um modelo de árvore, qualquer pessoa pode usá-lo em sua própria criação (com atribuição). Isso cria um ecossistema criativo cumulativo no qual cada criação torna a plataforma mais valiosa.
• Dreams enfrentou dificuldades comerciais apesar dos elogios da crítica. O problema foi a distribuição: ele ficou restrito ao PlayStation, e as ferramentas de criação eram tão profundas que a maioria dos jogadores nunca deixou de apenas consumir conteúdo. A lição: as ferramentas de criação precisam ser simples o bastante para que a maioria dos usuários experimente usá-las, mesmo que apenas uma minoria se torne construtora séria.

Core (Manticore Games). Uma plataforma gratuita para criar e jogar jogos multijogador, desenvolvida com a Unreal Engine e um editor simplificado. O editor do Core roda como aplicativo nativo, mas sua filosofia é relevante. Modelos e scripts compartilhados pela comunidade permitem que iniciantes montem jogos com componentes prontos. Criadores avançados podem escrever scripts em Lua para criar comportamentos personalizados. O Core teve dificuldade para conquistar um grande público, em parte porque os jogos precisavam ser executados pelo inicializador do Core. Uma versão baseada no navegador não teria esse atrito.

VRChat e Rec Room são plataformas sociais nas quais criadores constroem espaços que outras pessoas visitam. O VRChat usa Unity e roda em PC/VR. O Rec Room roda em praticamente tudo, incluindo dispositivos móveis. Ambos provam que mundos 3D gerados por usuários podem sustentar grandes comunidades. O VRChat é tecnicamente mais impressionante (shaders personalizados e avatares complexos). O Rec Room é mais acessível (ferramentas de criação no próprio aplicativo, gráficos mais simples e suporte a mais plataformas). Para um mundo de navegador, a abordagem do Rec Room, com ferramentas simples de criação dentro do aplicativo, é mais aplicável do que o fluxo de trabalho do VRChat, baseado em ferramentas externas.

Second Life: lançado em 2003, ainda funciona com mais de 200 mil usuários diários. Inteiramente criado pelos usuários. Propriedade baseada em terrenos, economia virtual de cerca de US$ 500 milhões por ano. 20 anos de lições sobre persistência e moderação.

Second Life é o precursor de todos os mundos de criadores. Lançado em 2003, ainda conta com mais de 200 mil usuários ativos diários. O mundo inteiro é criado pelos usuários. Terrenos são comprados, vendidos e possuem proprietários. Os criadores vendem objetos, roupas e edifícios. A linguagem de programação do mundo (LSL) permite criar conteúdo interativo.

O que o Second Life ensina após mais de 20 anos:

• A persistência importa mais do que os gráficos. O visual do Second Life está ultrapassado, mas o mundo persiste. As criações permanecem onde foram colocadas. Relacionamentos e histórias se acumulam. É essa persistência que faz as pessoas voltarem.
• A economia impulsiona a criação. Estima-se que o PIB do Second Life seja de US$ 500 milhões por ano. Os criadores constroem porque podem vender. Sem incentivo econômico, o volume e a qualidade do conteúdo criado pelos usuários diminuem.
• Conteúdo gerado por usuários exige infraestrutura de moderação. O Second Life enfrenta desafios de moderação há 20 anos. Qualquer plataforma em que usuários possam colocar conteúdo arbitrário em um espaço compartilhado precisa de verificação automatizada, ferramentas de denúncia e análise humana.
• A organização espacial baseada em terrenos funciona. O Second Life divide seu mundo em lotes que pertencem aos usuários. Cada lote tem um limite de prims (objetos). Isso impede naturalmente que um único criador consuma todos os recursos. Para um mundo de navegador, a propriedade baseada em chunks, com orçamentos de objetos por chunk, é o padrão equivalente.

Análise comparativa: o que cada jogo nos ensina

Jogo	Principal lição	Tecnologia aplicável	Risco se ignorada
Skyrim	Streaming baseado em chunks com uma grade de células	Terreno com mapa de altura, níveis de LOD, separação entre interiores e exteriores	O mundo não cabe na memória do navegador
The Witcher 3	Composição do mundo em camadas por equipes separadas	Streaming sensível ao conteúdo, renderização com impostores	Os criadores não conseguem trabalhar de forma independente
Breath of the Wild	Regras sistêmicas superam conteúdo roteirizado	Sistema de interação entre materiais, jogabilidade orientada por física	O mundo parece estático e sem vida
GTA V	A vida cotidiana faz os mundos parecerem reais	Sistemas de comportamento de NPCs, tráfego, horário do dia	O mundo do criador parece um museu vazio
Elden Ring	Variação de densidade e reutilização de assets	Biblioteca de assets modulares, zonas esparsas e densas	Fica vazio demais ou caro demais para preencher
No Man's Sky	Geração procedural para a tela, conteúdo dos criadores para a alma	Terreno baseado em sementes, modelo de dados compacto para bases	Terreno infinito, mas entediante
Minecraft	Mundo totalmente editável, ferramentas simples, profundidade infinita	Streaming de chunks, compactação por paleta, protocolo de edição de blocos	Os criadores não conseguem remodelar o próprio mundo
Roblox	A criação ocorre dentro do motor, e a economia impulsiona a qualidade	Editor dentro do mundo, monetização para criadores	Ninguém cria porque não há incentivo
Krunker.io	UGC no navegador funciona em escala com ferramentas simples	Renderização com Three.js, editor baseado em voxels, marketplace	Ferramentas de criação complexas demais para criadores casuais
Hordes.io	Mais de 200 jogadores em 3D no navegador, viável para um único desenvolvedor	WebGL personalizado, descarte espacial, arte estilizada	Complexidade excessiva na camada multijogador
Vuntra City (referência nativa)	Streaming sensível à velocidade e simulação do mundo em dois níveis mantêm uma enorme cidade procedural coerente	Política de LOD vinculada à velocidade, camada de consulta topológica, simulação agendada à distância + comportamento em proximidade	O deslocamento em alta velocidade causa surgimento repentino de elementos e picos de simulação
Agar.io / Slither.io	O particionamento espacial permite concorrência em massa	Taxa de ticks variável conforme a distância, gerenciamento de relevância	A rede entra em colapso em grande escala
Second Life	Persistência e economia sustentam comunidades por 20 anos	Propriedade baseada em lotes, limites de objetos, marketplace	Não há retenção de longo prazo
Dreams	A criação baseada em escultura é mais intuitiva do que a edição de polígonos	Modelagem baseada em volumes, biblioteca compartilhada de assets	As ferramentas de criação parecem um programa de CAD
Fortnite Creative	Ferramentas profissionais atraem conteúdo profissional	Recursos completos de edição dentro da plataforma	O teto de qualidade do conteúdo é baixo demais
RuneScape	Um MMO completo funciona no navegador com Wasm e protocolos binários	Emscripten, protocolo WebSocket binário personalizado, streaming de tiles	Subestimar o que os navegadores conseguem processar
Habbo Hotel	A criação simples de salas sustenta uma comunidade há 25 anos	Posicionamento em grade, economia de mobília virtual	Complexidade excessiva nas ferramentas de criação

Os jogos mais relevantes para o nosso caso específico — baseado em navegador, voltado a criadores e multijogador — são Minecraft (mundo editável, dados compactos), Roblox (criação dentro do motor, economia), Krunker (UGC no navegador em escala) e Hordes.io (arquitetura de MMO no navegador). Os títulos AAA (Skyrim, BotW, The Witcher 3) ensinam renderização e streaming. Os sucessos de navegador (Agar.io, Slither.io, Surviv.io) ensinam redes em escala. As plataformas para criadores (Roblox, Dreams, Second Life) ensinam dinâmicas de comunidade. Vuntra City acrescenta uma referência atual, no nível da implementação, para streaming sensível à velocidade, navegação diegética e padrões de simulação de milhões de agentes em uma cidade procedural moderna.

Como Skyrim e The Witcher seriam em um navegador

Vamos ser concretos. Se você pegasse Whiterun, de Skyrim, e a reconstruísse para entrega via navegador:

Terreno: A área ao redor de Whiterun tem aproximadamente 2 km x 2 km. Com nosso tamanho de chunk (64 m), isso representa cerca de 32x32 = 1024 chunks. Com 2–4 KB para o mapa de altura de cada chunk, seriam 2–4 MB de dados de terreno. As texturas do terreno (grama, terra, rocha, neve), como tiles de um atlas KTX2, talvez acrescentassem outros 5 MB. Terreno total: menos de 10 MB para toda a região.

Estruturas: A própria Whiterun tem talvez 40–50 construções. Cada construção, como um GLB otimizado (3 níveis de LOD), poderia ter 200–500 KB no nível máximo de detalhes. Mas você só precisa do nível máximo para as 5–10 construções mais próximas. As demais usam LOD médio ou baixo (50–100 KB cada). Total de estruturas visíveis a qualquer momento: 2–5 MB.

Vegetação: As árvores e a grama ao redor de Whiterun em Skyrim usam instanciamento. Você precisaria de talvez 10 modelos únicos de árvores (200 KB cada no LOD máximo, 20 KB como impostores em billboard) e de um sistema de grama que gere lâminas na GPU a partir de um mapa de densidade. Total de assets de vegetação: 2–3 MB. Dados de instanciamento (posições, rotações, escalas) para uma área de 5x5 chunks: menos de 500 KB.

NPCs: Whiterun tem aproximadamente 70 NPCs com nome, além dos guardas. Cada avatar em qualidade média: 100–200 KB. Mas apenas 10–20 ficam visíveis a qualquer momento. Total de dados de renderização de NPCs: 2–4 MB.

Total geral para uma área do tamanho de Whiterun visível a qualquer momento: 15–25 MB. Isso é perfeitamente viável em um navegador. O carregamento inicial mostraria o terreno e as principais estruturas em 3–5 segundos com banda larga, e os detalhes seriam preenchidos ao longo dos segundos seguintes.

Novigrad, de The Witcher 3, é maior e mais densa, mas os mesmos princípios se aplicam. Seriam necessários LOD e streaming mais agressivos, mas o total de dados visíveis a cada momento ainda permaneceria dentro dos limites de memória do navegador.

O que construiríamos primeiro

Um mundo aberto completo é um projeto de vários anos. Este é o caminho para colocar rapidamente algo real nas mãos dos criadores:

Fase 1: Ilha compartilhada (3 meses). Um único chunk de terreno (ilha de 512x512 m) com terreno por mapa de altura, água, vegetação básica e ciclo de dia e noite. Multijogador via Durable Objects (até 50 usuários simultâneos). Os criadores podem posicionar assets 3D gerados por IA da biblioteca Cinevva que já possuem. Pense nisso como um diorama compartilhado.

Fase 2: Mundo expansível (3 meses). Streaming de chunks para um mundo de 4x4 km. Lotes pertencentes aos criadores, nos quais eles têm permissões de edição. Sistema de LOD para terrenos e objetos. Estado persistente do mundo. Até 200 usuários simultâneos distribuídos pelo mundo.

Fase 3: Mundo vivo (6 meses). Escultura de terreno assistida por IA. Vegetação e atmosfera procedurais. Sistema de missões e eventos para que os criadores possam desenvolver experiências interativas, não apenas cenas estáticas. Chat por voz. Personalização de avatares. O mundo se torna um destino, não uma demonstração.

Questões em aberto

Estilo artístico. Um estilo visual estilizado (low-poly, cel shading) é mais barato de renderizar e tolera melhor assets gerados por IA. O realismo exige assets de maior qualidade e mais orçamento de renderização. Skyrim funcionou apesar dos gráficos datados porque a direção de arte era consistente. BotW é belíssimo em hardware da classe de tablets porque o estilo cel shading disfarça a baixa contagem de polígonos. Minecraft usa texturas de 16x16 e é um dos jogos mais reconhecíveis de todos os tempos. Krunker.io e Hordes.io alcançaram sucesso no navegador com gráficos estilizados simples. As evidências favorecem de forma esmagadora uma direção estilizada para um mundo no navegador. Precisamos escolher cedo uma identidade visual específica e garantir a consistência entre os assets gerados por IA.

Persistência do mundo versus instâncias. Todos compartilham um único mundo (como em um MMO ou Second Life) ou cada criador recebe sua própria instância, que outros podem visitar (como servidores de Minecraft ou Ilhas do Fortnite)? A tecnologia oferece suporte a ambas as opções, mas as dinâmicas sociais são completamente diferentes. O mundo compartilhado e persistente do Second Life promove descobertas por acaso (você encontra o trabalho de outras pessoas enquanto caminha). As ilhas instanciadas do Fortnite exigem um menu ou sistema de portais para descoberta. Roblox usa uma abordagem baseada em hub: os jogos são separados, mas você navega e os descobre por meio de uma interface compartilhada. Uma solução híbrida poderia funcionar: um mundo principal compartilhado e persistente, no qual os criadores possuem lotes (como os lotes do Second Life), com a opção de entrar em experiências independentes por meio de portais.

Profundidade das ferramentas de criação. Dreams provou que ferramentas de criação profundas impressionam os críticos, mas intimidam os usuários. Townscaper provou que ferramentas mínimas podem vender um milhão de cópias. Roblox Studio fica no meio-termo: simples o bastante para crianças, profundo o bastante para profissionais. O editor de voxels do Krunker é ainda mais simples. Para um mundo no navegador, deveríamos começar com a simplicidade do Townscaper (posicione objetos, e eles se encaixam e se conectam) e adicionar profundidade ao longo do tempo. A experiência inicial de posicionar seu primeiro objeto no mundo deve levar menos de 30 segundos.

Economia. Roblox, Second Life e Fortnite Creative comprovam que o incentivo econômico é o que transforma um brinquedo em uma plataforma. Sem uma forma de os criadores ganharem dinheiro com seu trabalho, os mais talentosos criarão em outro lugar. Isso não precisa ser lançado no primeiro dia, mas a arquitetura deve oferecer suporte (propriedade de objetos, acompanhamento de visitas, atribuição aos criadores).

Dispositivos móveis. Ainda faltam anos para que o WebGPU em dispositivos móveis seja confiável. Uma experiência móvel precisaria ser uma versão reduzida: terreno mais simples, menos objetos e menor distância de visão. Vale a pena estudar a abordagem do Rec Room, que roda em todos os tipos de dispositivo com qualidade adaptativa. Outra opção é lançar um aplicativo nativo para dispositivos móveis e manter a experiência completa no navegador.

Moderação. Um mundo aberto no qual qualquer pessoa pode posicionar qualquer coisa é um pesadelo de moderação. O Second Life lida com isso há 20 anos. Cada asset posicionado precisa passar por uma análise automatizada de conteúdo antes de ficar visível para outras pessoas. Isso adiciona latência ao processo criativo, mas não é negociável. Também devemos considerar classificações de conteúdo por lote (como o sistema Geral/Moderado/Adulto do Second Life), para que os criadores possam escolher os limites do próprio conteúdo.

Interações sistêmicas. BotW e Minecraft demonstram que sistemas de interação baseados em materiais criam mundos exponencialmente mais interessantes do que o posicionamento de objetos estáticos. Se um criador posicionar uma ponte de madeira e outro criador iniciar um incêndio nas proximidades, a ponte deve queimar? Se alguém construir uma represa, a água deve se acumular atrás dela? Essas interações fazem o mundo parecer vivo, mas exigem regras consistentes de física e materiais em todo o conteúdo dos criadores. Decidir até onde ir com o design sistêmico é uma decisão arquitetural que precisa ser tomada cedo.

Principais conclusões

Mundos abertos 3D no navegador são viáveis hoje. Hordes.io executa mais de 200 jogadores em 3D em um navegador. Krunker.io teve 10 milhões de jogadores mensais com um editor completo de mapas 3D. Os jogos .io provaram que o multijogador no navegador alcança milhões de usuários. A tecnologia não é especulativa.

A renderização está pronta. Three.js e Babylon.js processam cenas 3D comparáveis às de jogos AAA do início da década de 2010. WebGPU viabiliza shaders de computação para terreno e vegetação. Motores de física em Wasm rodam com desempenho entre 2 e 3 vezes inferior ao nativo. Uma área do tamanho de Whiterun cabe em 15–25 MB de dados visíveis.

A infraestrutura de rede está pronta. Cloudflare Durable Objects oferece servidores autoritativos por chunk na borda da rede. CRDTs processam edição colaborativa sem conflitos. O particionamento espacial — comprovado por todos os jogos, de Agar.io a Skyrim — mantém o tráfego de rede gerenciável com centenas de jogadores simultâneos.

Os mundos abertos AAA (Skyrim, The Witcher 3, BotW, Elden Ring, Minecraft, No Man's Sky) não são apenas referências gráficas. São livros didáticos sobre streaming de chunks, gerenciamento de LOD, geração procedural, design sistêmico e composição de mundos. Cada técnica utilizada por eles tem um equivalente compatível com navegadores.

As plataformas para criadores (Roblox, Second Life, Fortnite Creative, Dreams) ensinam as lições sociais e econômicas. A criação deve acontecer dentro do mundo, não em uma ferramenta externa. O incentivo econômico impulsiona a qualidade. A persistência cria apego. Ferramentas simples alcançam mais criadores do que ferramentas poderosas.

O pipeline criativo é onde a Cinevva tem uma vantagem. Já geramos assets 3D, texturas e áudio. Conectar esse pipeline a um sistema de posicionamento no mundo é a peça que falta. O conteúdo gerado por IA preenche o mundo. A curadoria e a organização feitas pelos criadores lhe dão alma.

O resultado não seria Skyrim em um navegador. Seria algo mais próximo da interseção entre Minecraft (mundo editável), Roblox (economia de criadores) e BotW (interações sistêmicas), executado em uma aba do navegador com ferramentas de criação impulsionadas por IA. A tecnologia necessária para construí-lo existe. A questão é a execução.

Artigos científicos e referências acadêmicas

As técnicas deste guia não foram inventadas do zero. Elas se baseiam em décadas de pesquisa. Estes são os artigos mais importantes para cada subsistema, com observações sobre como se aplicam a um mundo aberto no navegador.

Geração e renderização de terrenos

"An Image Synthesizer" — Ken Perlin (SIGGRAPH 1985). DOI. O artigo que apresentou o ruído de Perlin. Todos os geradores procedurais de terreno de todos os jogos desde 1985 remontam a esse trabalho. A função de ruído produz a aleatoriedade suave que, quando combinada em oitavas (movimento browniano fracionário), gera mapas de altura com aparência natural. O ruído simplex (Perlin, 2001) é o sucessor mais rápido. Para nosso pipeline de terreno, esta é a base: a geração de mapas de altura com base em ruído é executada em um shader de computação WebGPU a velocidades interativas.

"Texturing and Modeling: A Procedural Approach" — Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3ª edição em 2003). O livro de referência sobre geração procedural. Os capítulos de Musgrave sobre modelagem de terrenos, incluindo terrenos multifractais com características semelhantes à erosão, são a base direta dos geradores de terreno dos jogos modernos. Os parâmetros de fBm (lacunaridade, persistência, contagem de oitavas) descritos aqui são os mesmos que disponibilizaríamos aos criadores para a personalização do terreno.

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" — Losasso e Hoppe (SIGGRAPH 2004). DOI. Este artigo resolveu como renderizar terrenos enormes em taxas interativas usando anéis concêntricos de LOD (clipmaps). A malha do terreno é um conjunto fixo de grades aninhadas centralizadas na câmera. Conforme a câmera se move, as grades se deslocam e são atualizadas. Essa é a técnica recomendada em nossa seção sobre terrenos para WebGL 2, e ela funciona porque a carga de trabalho da GPU é constante, independentemente do tamanho do mundo. A implementação original é anterior ao WebGL, mas pode ser mapeada diretamente para ele. "Simulação e Visualização Rápidas de Erosão Hidráulica na GPU" -- Mei, Decaudin, Hu (2007). PDF. Transferiu a erosão hidráulica de um processo offline limitado pela CPU para uma computação em tempo real na GPU. O modelo de simulação de águas rasas do artigo (tratando a água como um campo de altura e calculando o fluxo entre células da grade) é executado em um compute shader. Para nosso pipeline, a erosão por GPU no servidor pode transformar terrenos gerados por ruído em paisagens geologicamente plausíveis em menos de um segundo, fazendo com que terrenos gerados por IA pareçam esculpidos à mão.

"Renderização em Tempo Real de Planetas Gerados Proceduralmente" -- Abordagens híbridas apresentadas nas palestras da GDC sobre No Man's Sky e nas descrições de Sean Murray. Embora não seja um único artigo, a palestra da GDC 2017 "Building Worlds Using Maths", de Innes McKendrick (Hello Games), detalha como No Man's Sky gera terrenos em escala planetária usando funções de ruído empilhadas, representação por voxels com marching cubes e geração na GPU. É diretamente relevante para nossa abordagem de terreno procedural, especialmente para gerar elementos de terreno que mapas de altura não conseguem representar, como cavernas e arcos.

"C-DBLOD: LOD Híbrido para Renderização de Terreno" -- Filip Strugar (2014). Artigo. Um aprimoramento dos geometry clipmaps que adiciona seleção baseada em quadtree para melhorar a adaptabilidade ao redor da posição da câmera. A principal ideia: em vez de anéis concêntricos fixos, usar uma quadtree para selecionar blocos de terreno em diferentes resoluções. Isso lida melhor com terrenos irregulares, nos quais algumas áreas precisam de mais detalhes do que outras, do que clipmaps puros. Pode ser implementado em WebGL 2 com uma pequena travessia da quadtree na CPU.

Gaussian Splatting 3D e renderização neural

"3D Gaussian Splatting para Renderização em Tempo Real de Campos de Radiância" -- Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). Página do projeto. O artigo que deu início à revolução do Gaussian splatting. Uma cena é representada por milhões de Gaussianas 3D, cada uma com posição, covariância (forma), opacidade e coeficientes de cor de harmônicos esféricos. A renderização ordena os splats por profundidade e os rasteriza como Gaussianas 2D. A abordagem é de 100 a 1.000 vezes mais rápida de treinar do que NeRFs e renderiza em tempo real. Existem várias implementações em WebGL/WebGPU. Para nossa plataforma, isso permite que criadores capturem objetos do mundo real com fotos de celular e os coloquem no mundo do navegador.

"NeRF: Representação de Cenas como Campos de Radiância Neurais para Síntese de Vistas" -- Mildenhall et al. (ECCV 2020). Página do projeto. O artigo fundamental sobre representação neural de cenas. Uma rede neural mapeia coordenadas 3D para cor e densidade, permitindo a síntese fotorrealista de novos pontos de vista a partir de um conjunto de fotografias de entrada. Embora NeRFs sejam computacionalmente caros demais para renderização direta em um navegador — eles exigem a avaliação da rede por pixel —, o pipeline de extração de NeRF para malha, que treina um NeRF e depois executa marching cubes no campo de densidade, produz malhas texturizadas de alta qualidade a partir de fotos.

"Primitivas Gráficas Neurais Instantâneas com Codificação Hash Multirresolução" -- Müller, Evans, Schied, Keller (SIGGRAPH 2022). Página do projeto. Reduziu o treinamento de NeRFs de horas para segundos usando uma tabela hash multirresolução para codificação espacial. Isso tornou os NeRFs viáveis para uso em produção. A técnica de codificação hash também pode ser aplicada a outros dados espaciais em um mundo de navegador, permitindo consultas rápidas em grandes conjuntos de dados 3D.

"Neuralangelo: Reconstrução Neural de Superfícies em Alta Fidelidade" -- Li et al. (CVPR 2023). Página do projeto. Extrai malhas triangulares de alta qualidade de representações neurais usando codificação hash multirresolução e gradientes numéricos para estimar SDFs (funções de distância com sinal). As malhas resultantes podem ser usadas diretamente em engines 3D para navegador. Para nosso pipeline de assets, o Neuralangelo — ou ferramentas semelhantes, como NeuS2 — pode converter capturas NeRF em arquivos GLB prontos para a web, com geometria limpa e texturas pré-calculadas.

Rede multijogador e sincronização de estado

"Gerenciamento de Interesse em Jogos On-line Massivos para Múltiplos Jogadores" -- Boulanger, Kienzle, Verbrugge (2006). DOI. Uma análise abrangente de técnicas de gerenciamento de área de interesse (AOI) para MMOs. Abrange abordagens baseadas em grade, em aura e híbridas para filtrar atualizações de rede com base na relevância espacial. A abordagem baseada em grade, que corresponde ao nosso sistema de chunks, é a mais eficiente para mundos com densidade uniforme. A abordagem baseada em aura, com um raio de influência por entidade, funciona melhor para densidade variável. Nossa recomendação de uma AOI baseada em chunks, com taxas de atualização priorizadas dentro da AOI, deriva dessa pesquisa.

"Dead Reckoning: Ocultação de Latência para Jogos em Rede" -- Pantel and Wolf (2002). DOI. Formaliza o dead reckoning — a previsão das posições das entidades com base na última velocidade conhecida — para jogos em rede. O artigo quantifica a relação de compromisso: limiares de previsão mais altos reduzem a largura de banda, mas aumentam o erro de posição visível durante as correções. Para jogos de navegador com latência de 50 a 200 ms, um limiar de previsão de 0,5 a 1,0 metro mantém as correções imperceptíveis e reduz em 60% a 80% a largura de banda usada pelas atualizações de posição.

"Tipos de Dados Replicados Livres de Conflitos" -- Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. O artigo fundamental sobre CRDTs. Define CRDTs baseados em estado e em operações que convergem sem coordenação. Para nosso sistema de edição de mundos, os CRDTs relevantes são: LWW-Register (registrador em que a última gravação vence) para propriedades de objetos que têm um único valor, como posição, rotação e cor; e OR-Set (conjunto de remoção observada) para a coleção de objetos em um chunk, que lida com adições e remoções simultâneas sem conflitos. O Yjs implementa esses recursos com eficiência em JavaScript.

"Time Warp: Um Mecanismo para Simulação Distribuída" -- Jefferson (1985). DOI. O artigo original sobre simulação distribuída otimista. Embora o próprio Time Warp seja complexo demais para um jogo de navegador, sua ideia central — processar eventos de forma otimista e reverter caso chegue um conflito de outro nó — é a base da previsão moderna no cliente com reconciliação do servidor. É assim que todo jogo multijogador responsivo funciona: o cliente faz previsões localmente, envia ações ao servidor e corrige o estado se o servidor discordar.

"O Modelo de Rede da Engine TRIBES" -- Frohnmayer and Gift (GDC 1999). Uma das primeiras descrições práticas de redes cliente-servidor para jogos com gerenciamento de interesse, atualizações de estado priorizadas e controle do orçamento de largura de banda. O conceito de "gerenciador de fantasmas" — no qual o servidor mantém, para cada cliente, uma visão do que esse cliente conhece e envia apenas as diferenças em relação a essa visão — é exatamente o que nossa arquitetura de Durable Objects baseada em chunks implementa. Essa palestra da GDC é a precursora intelectual da maioria das redes modernas para jogos.

"Rede Multijogador da Source" -- Valve (2009). Documentação para desenvolvedores. A documentação da Valve sobre o modelo de rede da engine Source, usado em Half-Life 2, CS:GO e Team Fortress 2. Abrange previsão no cliente, interpolação de entidades, compensação de lag e o sistema de "snapshots", no qual o servidor envia o estado completo do mundo em intervalos regulares enquanto o cliente interpola entre os snapshots. Esse é o padrão de referência para redes com servidor autoritativo e se aplica diretamente à nossa arquitetura.

Geração procedural

"Síntese de Modelos: Um Algoritmo Geral de Modelagem Procedural" -- Merrell (2007). DOI. Um dos precursores do Wave Function Collapse. Gera estruturas 3D a partir de modelos de exemplo propagando restrições locais. O algoritmo garante consistência global ao colapsar iterativamente as células com menos possibilidades, usando uma heurística de entropia mínima. É assim que Townscaper e geradores semelhantes produzem estruturas coerentes a partir de entradas simples do usuário.

"WaveFunctionCollapse" -- Maxim Gumin (2016). GitHub. Não é um artigo tradicional, mas sim um projeto de código aberto influente, com ampla documentação. O algoritmo recebe uma pequena imagem de exemplo ou um conjunto de tiles e gera resultados maiores que são localmente semelhantes à entrada. Em um mundo criado por usuários, o WFC pode gerar plantas de edifícios, redes viárias, mapas de masmorras e detalhes de terreno a partir de um pequeno conjunto de regras definidas pelo criador. Existem várias implementações em JavaScript.

"Wave Function Collapse é Resolução de Restrições na Prática" -- Karth and Smith (FDG 2017). DOI. Uma análise acadêmica do WFC que esclarece sua relação com a satisfação de restrições e mostra como analisá-lo e ampliá-lo. É relevante para entender as limitações do WFC — ele pode ficar sem saída e exigir retrocesso — e como criar conjuntos de tiles que evitem esses problemas.

"Teorema da Superposição e Suas Implicações para a Geração Procedural de Conteúdo de Jogos" -- Sandhu et al. (2022). Explora o uso de conceitos de superposição inspirados na física quântica para a geração procedural de conteúdo. Embora seja especulativa, a estrutura matemática para manter vários estados possíveis antes de "colapsar" em uma configuração final é exatamente o modo como o WFC funciona e pode contribuir para sistemas de geração mais sofisticados.

Técnicas de renderização em tempo real

"Renderização em Tempo Real" -- Akenine-Möller, Haines, Hoffman (4ª edição, 2018). O livro-texto de referência. O Capítulo 19 (Estruturas de Aceleração), o Capítulo 20 (Sombreamento Eficiente) e o Capítulo 21 (Realidade Virtual e Aumentada) são particularmente relevantes. Os algoritmos de descarte por frustum, descarte por oclusão e LOD descritos nele são os mesmos implementados por Three.js, Babylon.js e todas as engines de jogos. Não é um artigo, mas é a referência definitiva.

"Uma Análise sobre a Pré-Computação de Campos de Radiância Neurais para Síntese de Vistas em Tempo Real" -- Reiser et al. (2023). DOI. Analisa métodos para converter NeRFs em formatos que podem ser renderizados em tempo real, como malhas, texturas e grades esparsas de voxels. É diretamente relevante para nosso pipeline de assets, no qual a captura neural processada no servidor precisa produzir um resultado renderizável no navegador.

"Correspondência On-line de Características Escalável e Precisa Usando 3D Gaussian Splatting" -- Vários grupos (2024-2025). Diversos artigos recentes exploram edição, composição e cenas dinâmicas com Gaussian splats. Isso é relevante porque mundos criados por usuários precisam combinar várias cenas de splats — os objetos capturados por cada criador — em uma única cena coerente. Métodos para editar splats, incluindo alteração de cor, deformação e composição, são áreas de pesquisa ativas.

"Ray Tracing Eficiente em Espaço de Tela na GPU" -- McGuire and Mara (JCGT 2014). DOI. O artigo por trás das reflexões em espaço de tela usadas em nossa seção sobre renderização de água. Traça raios pelo buffer de profundidade para produzir reflexos aproximados sem o custo do ray tracing completo. A variante de "traçado hierárquico", que usa um mipmap de profundidade mín-máx, é executada com eficiência no WebGL 2.

"Simulação da Água do Oceano" -- Jerry Tessendorf (2001). PDF. O artigo fundamental sobre simulação oceânica baseada em FFT. Descreve o espectro de Phillips — um modelo estatístico de ondas oceânicas — e como transformá-lo em um mapa de deslocamento espacial por meio da FFT inversa. É usado por todos os grandes jogos com oceanos realistas, como Sea of Thieves, Assassin's Creed e Uncharted. O cálculo da FFT se adapta perfeitamente aos compute shaders do WebGPU.

"Espalhamento Atmosférico Pré-Computado" -- Bruneton and Neyret (EGSR 2008). DOI. O artigo por trás da renderização fisicamente precisa do céu. Pré-calcula o espalhamento atmosférico em tabelas de consulta que um fragment shader consulta em tempo real. Produz, com base em princípios físicos, cores corretas do céu, perspectiva aérea — objetos distantes parecem azulados ou enevoados — e cores do nascer e do pôr do sol. As tabelas pré-calculadas são pequenas, com algumas centenas de KB, e o shader em tempo de execução tem baixo custo. Tanto o shader Sky do Three.js quanto o céu procedural do Babylon.js são versões simplificadas dessa abordagem.

"Volumes de Oclusão de Ambiente" -- McGuire (HPG 2010) e "Obscurecimento de Ambiente Escalável" -- McGuire, Mara, Luebke (HPG 2012). PDF. Os artigos por trás das implementações modernas de SSAO. O SAO é a variante mais comumente implementada em engines 3D para navegador porque é eficiente — uma amostra do buffer de profundidade por pixel — e produz sombras de contato plausíveis. O algoritmo coleta amostras do buffer de profundidade ao redor de cada pixel para estimar o quanto ele está "ocluído" pela geometria próxima. Tanto o Three.js quanto o Babylon.js implementam SSAO derivado de SAO.

Renderização e animação de multidões

"Renderização de Multidões na GPU" -- Dudash (2007) e apresentações posteriores na GDC/SIGGRAPH sobre renderização instanciada de multidões. A técnica central: pré-calcular os quadros de animação esquelética em texturas (Vertex Animation Textures) e então renderizar multidões como malhas instanciadas, nas quais cada instância lê as transformações de seus ossos da textura de animação com base no quadro atual. Isso desvincula a avaliação da animação das chamadas de desenho, permitindo que uma única chamada de desenho instanciada renderize centenas de personagens com animações distintas.

"Dinâmica Baseada em Posição" -- Müller et al. (2007). DOI. O artigo fundamental sobre PBD, que é a técnica usada pelas engines modernas de jogos para simular tecidos, cabelos e corpos moles. O Rapier, nossa engine de física Wasm recomendada, usa solucionadores derivados de PBD. Para a personalização de avatares, como capas, cabelos esvoaçantes e roupas soltas, o PBD oferece simulação responsiva nas taxas de quadros dos jogos. A implementação em Wasm mantém esse processamento fora da thread principal do JavaScript. "FABRIK: um solucionador rápido e iterativo para o problema de cinemática inversa" — Aristidou e Lasenby (2011). DOI. O artigo por trás do solucionador de IK recomendado em nossa seção sobre avatares. O FABRIK funciona alternando o alcance do efetuador final até a raiz e da raiz até o efetuador final, convergindo em 3 a 5 iterações. Ele é mais rápido do que a IK baseada em jacobianos, lida naturalmente com restrições de articulações e é simples de implementar (cerca de 50 linhas de código para o solucionador básico). As implementações de IK do Three.js e do Babylon.js são derivadas do FABRIK.

Mundos virtuais e ambientes colaborativos

"Jogos multijogador on-line massivos: uma visão geral do estado da arte" — Yahyavi e Kemme (2013). DOI. Uma análise abrangente da arquitetura de MMOs, cobrindo modelos cliente-servidor, abordagens ponto a ponto, gerenciamento de interesse, modelos de consistência, técnicas de escalabilidade e prevenção de trapaças. A taxonomia dos modelos de consistência (forte, eventual, causal) corresponde à nossa abordagem baseada em CRDTs (consistência eventual com ordenação causal por meio de relógios vetoriais).

"Uma arquitetura distribuída para aplicações interativas multijogador na Internet" — Diot e Gautier (1999). DOI. Uma pesquisa inicial sobre ambientes virtuais distribuídos que identificou a tensão central: a consistência forte exige coordenação (aumentando a latência), enquanto a consistência fraca permite maior responsividade, mas traz o risco de inconsistências visíveis. O artigo defende o "atraso local" (adiar a exibição local por um curto período para dar tempo de as atualizações remotas chegarem) como um meio-termo. Para edições no mundo (posicionamento de objetos), um atraso local de 100 a 200 ms é imperceptível e dá ao servidor tempo para fazer a validação.

"A grade do Second Life: a arquitetura de um mundo virtual de código aberto quase contemporâneo" — documentação técnica da Linden Lab e engenharia reversa feita pela comunidade. Embora não se trate de um único artigo, a análise técnica da arquitetura do Second Life está amplamente documentada. Os principais aprendizados: cada região de 256x256 m é executada em uma instância dedicada de servidor. Os objetos são armazenados como uma árvore de "primitivas" (formas básicas com transformações, texturas e scripts). O visualizador transmite sob demanda as descrições e texturas dos objetos. Esse modelo baseado em lotes e com persistência por objeto é a arquitetura existente mais próxima do que estamos construindo, e os mais de 20 anos de operação do Second Life comprovam que ela é escalável.

Gráficos para Web e desempenho no navegador

"WebGPU: uma API gráfica de alto desempenho para a Web" — W3C GPU for the Web Working Group (2023–em andamento). Especificação. A especificação formal do WebGPU. Não é um artigo de pesquisa, mas é o documento técnico definitivo para programação de GPU no navegador. A especificação de shaders de computação (Seção 23) é particularmente relevante para a geração de terrenos, a distribuição de vegetação e os sistemas de partículas descritos ao longo deste guia.

"WebAssembly: uma estrutura para executar código compilado no navegador" — Haas et al. (PLDI 2017). DOI. O artigo original sobre WebAssembly, escrito pelos fornecedores de navegadores. Demonstra que o Wasm alcança um desempenho até 2 vezes inferior ao nativo em cargas de trabalho computacionalmente intensivas. Isso valida nossa recomendação de mecanismos de física compilados para Wasm (Rapier, Havok) em mundos abertos no navegador. A análise de desempenho do artigo mostra que a sobrecarga vem principalmente da verificação de limites e das chamadas indiretas de funções, e não do próprio modelo de compilação.

"Não tão rápido: uma análise do desempenho do WebAssembly em comparação com código nativo" — Jangda et al. (USENIX ATC 2019). PDF. Uma avaliação rigorosa do desempenho do Wasm em comparação com o nativo. O estudo conclui que o Wasm é, em média, de 1,45 a 1,55 vez mais lento do que C nativo no conjunto de benchmarks SPEC CPU. Especificamente para a física de jogos (uso intenso de ponto flutuante e poucas chamadas ao sistema), a sobrecarga fica no limite inferior (~1,3 vez). Isso confirma que a física em Wasm no navegador é viável para cargas de trabalho de jogos em tempo real.

"Acelerando a Web com WebAssembly" — Rossberg et al. (2018). DOI. Descreve a justificativa do projeto e a semântica formal do WebAssembly. Um ponto particularmente relevante é a discussão das garantias de segurança de memória (Seção 3), que explica por que módulos Wasm podem compartilhar com segurança uma aba do navegador com JavaScript sem os riscos de segurança dos plug-ins nativos. É isso que torna segura a execução, no navegador, de mecanismos de física que tradicionalmente eram bibliotecas em C++.

Geração de conteúdo com IA

"Geração de texto para 3D com difusão bidirecional usando conhecimentos prévios 2D e 3D" — Vários grupos (2023–2025). Diversos artigos recentes (DreamFusion, Magic3D, ProlificDreamer, MVDream, Zero-1-to-3++) exploram a geração de recursos 3D a partir de prompts de texto usando modelos de difusão 2D como conhecimentos prévios para otimização 3D. A qualidade melhorou drasticamente do início de 2023 até 2025, passando de formas amorfas para malhas detalhadas e texturizadas. Em nossa plataforma, esses modelos (executados no lado do servidor em GPUs) são a etapa de "geração por IA" do pipeline de recursos dos criadores.

"DreamFusion: texto para 3D usando difusão 2D" — Poole et al. (ICLR 2023). Página do projeto. O artigo fundamental sobre Score Distillation Sampling (SDS), que usa um modelo de difusão 2D pré-treinado para orientar a otimização 3D. O principal insight: não são necessários dados de treinamento 3D se for possível avaliar, usando um modelo 2D existente, se as visualizações renderizadas de um objeto 3D correspondem a um prompt de texto. Isso abriu caminho para a geração de texto para 3D e serve de base para trabalhos posteriores (Magic3D, ProlificDreamer) que melhoraram a qualidade e a velocidade.

"LRM: grande modelo de reconstrução de imagem única para 3D" — Hong et al. (ICLR 2024). Página do projeto. Reconstrói um modelo 3D a partir de uma única imagem em 5 segundos usando uma única GPU. O modelo produz uma representação semelhante a NeRF que pode ser convertida em malha. Para um mundo criado por usuários, isso significa que um criador poderia tirar uma foto de qualquer objeto do mundo real e obter um modelo 3D em segundos. A velocidade torna seu uso viável como ferramenta interativa, em vez de um processo em lote.

"Geração procedural de conteúdo por meio de aprendizado de máquina (PCGML)" — Summerville et al. (2018). DOI. Uma análise do uso de aprendizado de máquina para a geração procedural de conteúdo em jogos. Abrange geração de níveis, itens, narrativas e mundos. Um ponto particularmente relevante é a discussão sobre "geração controlável", na qual designers definem parâmetros de alto nível e o modelo de ML preenche os detalhes. Esse é o paradigma da criação de mundos assistida por IA: os criadores definem a intenção ("transforme esta área em uma floresta assustadora") e a IA preenche a geometria, as texturas e a população.

Como esses artigos se conectam à nossa arquitetura

A pesquisa se relaciona com nossa arquitetura em camadas:

Pipeline de terreno: o ruído Perlin/simplex (Perlin 1985, 2001) gera o mapa de altura básico. A erosão hidráulica (Mei et al. 2007) adiciona realismo geológico. Geometry clipmaps (Losasso e Hoppe 2004) ou CDLOD (Strugar 2014) renderizam o terreno com eficiência no navegador. A dispersão atmosférica (Bruneton e Neyret 2008) faz com que o terreno distante tenha a aparência correta.

Pipeline de recursos: texto para 3D (DreamFusion et al.) e imagem para 3D (LRM) geram recursos no lado do servidor. Gaussian splatting (Kerbl et al. 2023) possibilita a captura por fotogrametria. Neuralangelo (Li et al. 2023) extrai malhas limpas de capturas neurais. Todas as saídas são processadas em GLB/KTX2 prontos para o navegador.

Renderização: SSAO (McGuire 2012) adiciona profundidade. Reflexos em espaço de tela (McGuire e Mara 2014) viabilizam a água. Oceano por FFT (Tessendorf 2001) simula a água. Texturas de animação de vértices (Dudash 2007) renderizam multidões. FABRIK (Aristidou e Lasenby 2011) controla a IK dos personagens.

Rede: o gerenciamento de interesse (Boulanger et al. 2006) filtra atualizações por relevância espacial. Dead reckoning (Pantel e Wolf 2002) reduz o uso de largura de banda. CRDTs (Shapiro et al. 2011) lidam com a edição colaborativa. A predição do cliente com reconciliação do servidor (Jefferson 1985, Valve Source Networking) proporciona responsividade.

Geração de mundos: WFC (Gumin 2016, Karth e Smith 2017) gera estruturas e layouts. PCGML (Summerville et al. 2018) fornece a estrutura para geração assistida por IA, na qual os criadores definem a intenção e os modelos preenchem os detalhes.

A pesquisa está madura. A maioria dessas técnicas tem sido usada há anos em jogos lançados. A inovação de trazê-las para um navegador não está nos algoritmos. Está no trabalho de engenharia necessário para fazê-las funcionar dentro das limitações de memória, GPU e rede dos navegadores, que é o que o restante deste guia aborda.

Leitura complementar

• Stack tecnológico para jogos Web em 2026 aborda os fundamentos de WebGL, WebGPU e WebAssembly
• Comparação de mecanismos de jogos Web compara mecanismos para distribuição no navegador
• Relatório técnico sobre Three.js + USDC sobre o carregamento de recursos 3D no navegador
• Modelos de IA generativa de código aberto de fronteira para o pipeline de geração por IA
• Design de jogos cooperativos sobre padrões de design multijogador que mantêm os jogadores engajados
• Geração de paisagens para mundos abertos no navegador — renderização de terreno, erosão e vegetação
• Noções básicas de multijogador com WebSocket — primeiros passos com redes multijogador no navegador
• Primeiros passos com WebGPU — a API de renderização para a próxima geração de 3D no navegador
• Carregamento de recursos por streaming — padrões de carregamento progressivo para grandes mundos 3D

Experimente agoraExperimente agora mesmo um mundo aberto no seu navegador

Uma frase entra, um mundo 3D explorável sai.

Criar de graça →É grátis, roda no seu navegador, nada para instalar.