Construir um jogo labirinto 3d não é tão simples quanto parece
A maioria das pessoas acha que basta criar um cubo com paredes e jogar uma câmera por dentro. Isso funciona no início, mas na hora de colocar o jogo em produção você vai descobrir que o problema real é outro: colisão, geração de caminhos e performance em navegadores móveis. Eu passei semanas com isso em um projeto interno.
jogo labirinto 3d — o básico
O conceito é simples. Você tem um espaço tridimensional delimitado por paredes, um jogador que se move com WASD ou toque na tela, e um ponto de chegada. A parte complicada fica nos detalhes de implementação. Usar Three.js com PointerLockControls para movimentação foi a minha escolha padrão em projetos recentes. O código leva cerca de 80 linhas para uma versão funcional básica. A geração procedural do labirinto merece atenção separada. O algoritmo mais confiável pra isso é a busca em profundidade (DFS) recursiva com backtracking. Ele gera labirintos solvíveis garantidos, ao contrário de outras abordagens que criam loops abertos ou áreas inacessíveis. Eu usei uma variantede DSF com pesos aleatórios nas paredes — isso evita labirintos muito regulares e monótonos visualmente.
Colisão com paredes em Three.js pode ser feita com Raycaster de forma bem eficiente. Dispare quatro raios a partir da posição do jogador — frente, trás, esquerda, direita — e verifique a distância até objetos com a tag "wall". Se a distância for menor que um threshold de 0,3 unidades, bloqueie o movimento naquela direção. Testei bounding box antes, mas a precisão era péssima em cantos. Raycasting resolve isso em 95% dos casos, sobra apenas a exceção dos cantos vivos.
O problema que ninguém conta sobre labirintos 3d
O edge case mais irritante que encontrei foi o "túnel Fantasma". Quando o jogador se move rápido demais próximo a uma parede, o raycast não detecta a colisão porque o teste de interseção pula o segmento inteiro. A solução prática é dividir o vetor de movimento em passos menores. Usei um sub-stepping de 8 passos por frame, o que aumentou o overhead de CPU em aproximadamente 3ms em um laptop intermediário. Valeu cada milissegundo. Outro problema comum: a câmera atravessa as paredes quando o jogador pressiona duas teclas ao mesmo tempo. A correção é simples mas fácil de esquecer. Primeiro normalize o vetor de direção, depois aplique a colisão em cada eixo separadamente. Movimento no eixo X com verificação de colisão, reset da posição se necessário, e só então o eixo Y. A ordem importa. Fazer os dois juntos gera comportamentos imprevisíveis.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Performance e otimizações
Se você está rodando isso em WebGL no navegador, cuidado com o número de objetos na cena. Labirintos com mais de 200 paredes individuais vão travar dispositivos móveis. A solução é usar geometria combinada. Merge todas as paredes em um único BufferGeometry antes de renderizar. O resultado é uma redução de draw calls de 200 para 1. A diferença entre 15 FPS e 60 FPS em um celular Android de gama média é absurda. Texturas também pesam. Use atlas de textura quando possível. Carregar 50 texturas individuais é um erro. Junte tudo em um arquivo único de 1024x1024 pixels e ajuste as coordenadas UV manualmente. O custo extra de configuração é compensado pela redução de requisições HTTP e cache do navegador.
Alternativas ao Three.js
Não recomendo Three.js para projetos que precisam carregar rapidamente em qualquer dispositivo. A biblioteca tem um bundle pesado mesmo em versão lite. A alternativa que costumo avaliar primeiro é o Babylon.js. Ele tem engine de física integrada, melhor controle de memória e um sistema de instanciamento mais maduro para lpede objetos repetidos como paredes. OThree.js ainda vence em quantidade de tutoriais e assets disponíveis, mas a decisão técnica fica com o Babylon para produção séria. Para quem quer algo ainda mais leve, existe o P5.js com uma camada 3D experimental. Funciona para protótipos rápidos mas não escala. Um labirinto 3d com iluminação dinâmica e múltiplas texturas vai quebrar a biblioteca em produção.
Onde encontrar código pronto
O GitHub tem vários repositórios de exemplo. A busca por "3d maze three.js" retorna resultados decentes. O projeto "maze-generator" do usuário tholman tem uma boa implementação de geração procedural. Para movimentação em primeira pessoa, o repositório "threejs-journey" da Bruno Simon tem exercícios práticos que cobrem raycasting de colisão. Ambos são gratuitos e servem como ponto de partida sólido. Se você quer algo mais completo, o A-Frame oferece uma abordagem baseada em Web Components. É mais declarativo e exige menos código boilerplate. O trade-off é que você perde flexibilidade para customizar comportamentos específicos de colisão e movimentação.
O que vai dar errado
A iluminação é onde a maioria dos projetos trava. Luzes point em WebGL são custosas. Um labirinto com dez luzes point pode cair para 30 FPS em hardware médio. Use sombras pré-calculadas ou lightmaps se o labirinto for estático. Se precisar de dynamic lighting, limite-se a uma luz point principal com sombras suaves em baja resolução — 512x512 é suficiente para um labirinto. O som ambiente também é negligenciado mas faz diferença na imersão. Ecoss em WebGL com Web Audio API é viável, mas a latência de áudio em alguns navegadores móveis pode ser problemática. Teste no Safari do iPhone antes de lançar. O Chrome Android geralmente funciona bem.
O caminho de saída às vezes não existe quando o algoritmo gera o labirinto. Isso parece impossível com DFS, mas acontece quando a lógica de verificação de visitados tem um bug sutil. Sempre valide o labirinto gerado com um solver antes de mostrar ao jogador. Um BFS simples de 20 linhas resolve essa validação em menos de 50ms.
