1.1 O hardware, no que importa ao desenvolvedor

O Quest 3S, lançado em 2024, usa o mesmo processador e a mesma memória, com lentes e telas mais simples. Na prática, um jogo que roda bem no Quest 3 costuma rodar no 3S — mas teste nos dois, porque a nitidez e o campo de visão diferentes afetam a legibilidade de texto e UI.

1.2 Standalone, PC VR e o sistema

• Standalone: o jogo roda no próprio headset, que usa o Meta Horizon OS (baseado em Android). É o alvo desta apostila e o da maioria das vendas.
• PC VR via Link/Air Link: o jogo roda no PC e o headset funciona como tela. Muito útil para iterar durante o desenvolvimento (Play Mode direto no headset), mas o desempenho no PC não diz nada sobre o desempenho standalone.

1.3 VR, MR e o que muda no design

2.1 O conjunto de peças

• Unity 6 (ou a versão LTS que a Meta indicar como suportada) com o módulo Android Build Support.
• OpenXR como camada de XR, com o suporte da Meta para Quest ativado. O padrão OpenXR é o que permite, mais tarde, levar o jogo a outros headsets com menos retrabalho.
• Meta XR SDK (distribuído como pacote "All-in-One" ou em partes: Core, Interaction, Audio, Platform, entre outros). Traz recursos específicos do Quest — passthrough, compreensão de cena, rastreamento de mãos avançado — e os Building Blocks, componentes prontos arrastáveis para a cena.
• Alternativa multiplataforma para interação: o XR Interaction Toolkit da Unity (módulo 4).

2.2 Configurações que importam

2.3 O ciclo de iteração

1. Ative o modo de desenvolvedor no headset (exige uma conta de organização no painel de desenvolvedores da Meta).
2. Instale o Meta Quest Developer Hub (MQDH) no computador: instalar builds, ver logs, capturar vídeo, métricas de performance.
3. Para iterar em lógica e interação, use Link e o Play Mode: o editor roda no PC e o headset mostra. Rápido — mas não mede performance.
4. Para tudo o que envolve desempenho, build no headset (Build And Run). Faça isso cedo e com frequência: o dia em que o jogo deixa de rodar a 90 Hz é mais fácil de achar se você testou ontem.

// Primeiro script: saber em que modo de entrada o jogador está
using UnityEngine;
using UnityEngine.XR;

public class DiagnosticoXR : MonoBehaviour
{
    void Update()
    {
        var mao = InputDevices.GetDeviceAtXRNode(XRNode.RightHand);
        if (mao.TryGetFeatureValue(CommonUsages.triggerButton, out bool gatilho) && gatilho)
            Debug.Log($"Gatilho direito — {mao.name}");   // aparece no logcat / MQDH
    }
}

3.1 Por que dá enjoo

O enjoo em VR vem, sobretudo, de um conflito sensorial: os olhos veem movimento que o ouvido interno não sente (ou o contrário). Acelerar, virar suavemente, subir e descer, balançar a câmera — tudo o que move a visão sem mover o corpo aumenta o risco. A sensibilidade varia muito de pessoa para pessoa, e o que não incomoda o desenvolvedor, que joga horas por dia, pode derrubar um iniciante em minutos.

3.2 As regras que não se quebram

• Nunca mova ou gire a câmera sem ação do jogador. Sem cutscene que arrasta a visão, sem balanço de câmera ao andar, sem tremor de câmera em explosões.
• A cabeça do jogador manda na câmera. O rastreamento da cabeça nunca deve ser interrompido ou sobrescrito.
• Mantenha a taxa de quadros. Quadros perdidos fazem o mundo "tremer" contra o movimento da cabeça.
• Aceleração é pior que velocidade. Movimento constante incomoda menos do que acelerar e travar.

3.3 As técnicas de locomoção

4.1 Dois kits

4.2 As interações essenciais

• Pegar (grab): direto (mão no objeto) ou à distância. Decida se o objeto "pula" para a mão ou mantém o ponto de pegada — objetos grandes (uma espada) precisam de pontos de pegada definidos.
• Apertar (poke): botões e UI tocados com o dedo; exige feedback visual e sonoro, porque não há resistência física.
• Apontar (ray): um raio a partir da mão ou do controle, para UI distante e seleção.
• Usar (activate): o gatilho com um objeto na mão — disparar, acender, borrifar.

4.3 Desenhar para mãos

4.4 Háptica nos controles

Com controles, a háptica é uma das ferramentas mais baratas de sensação: um pulso curto ao tocar, uma vibração contínua fraca ao arrastar, um pulso forte ao acertar. Use pouco e com propósito — vibração constante vira ruído e gasta bateria dos controles.

5.1 As peças

O Mixed Reality Utility Kit (MRUK), parte do Meta XR SDK, reúne a compreensão de cena em ferramentas prontas: encontrar a maior parede livre, gerar pontos válidos no chão, verificar se um ponto está dentro da sala. É por onde começar.

5.2 Desenhar para uma sala desconhecida

• A sala é o nível — e cada jogador tem uma diferente. O jogo precisa funcionar num quarto de 2×2 m e numa sala de 6×5 m, com ou sem móveis.
• Posicionamento procedural: em vez de posições fixas, regras ("inimigos surgem a partir de paredes a pelo menos 1,5 m do jogador").
• Plano B: se o jogador não configurou a sala (ou ela é pequena demais), ofereça uma sala virtual padrão ou um modo que não dependa da geometria.
• Segurança: nunca incentive o jogador a correr em direção a paredes reais ou a subir em móveis.

6.1 O quadro tem prazo

Esse tempo é dividido entre CPU (lógica, física, preparar os desenhos) e GPU (desenhar), que trabalham em paralelo em quadros consecutivos. Se qualquer um dos dois passar do prazo, o quadro perde-se. E o sistema também precisa de uma fatia: nunca planeje usar 100% do tempo.

6.2 As técnicas próprias do Quest

• Renderização estéreo numa passagem (Single Pass Instanced / Multiview): obrigatória na prática — sem ela, a CPU prepara tudo duas vezes.
• Fixed Foveated Rendering (FFR): renderiza a periferia das lentes com menos resolução, onde a nitidez já é menor. Economiza GPU com pouca perda perceptível; ajustável em níveis.
• Application SpaceWarp (AppSW): o jogo renderiza na metade da taxa (por exemplo, 36 quadros para uma tela a 72 Hz) e o sistema sintetiza os quadros intermédios usando vetores de movimento. Quase dobra o orçamento de GPU, com o custo de artefatos em objetos muito rápidos e de ter de produzir os vetores de movimento. Exige Vulkan e URP compatível.
• Resolução dinâmica: reduz a resolução de renderização quando a GPU aperta, em vez de perder quadros.
• Níveis de CPU e GPU: o sistema permite pedir mais desempenho ao processador, ao custo de calor e bateria. Não é solução para um jogo pesado; é margem.

6.3 O que costuma custar caro

7.1 As ferramentas

7.2 O procedimento

1. Medir no headset, em build de release (o editor e o Development Build distorcem os números). Use o Development Build só quando precisar do Profiler.
2. CPU ou GPU? Compare os tempos com o orçamento. Se reduzir a resolução de renderização (ou ativar FFR agressivo) melhora o quadro, o problema é GPU; se não muda nada, é CPU.
3. Encontrar o culpado: Profiler para CPU (que sistema? que script?), Frame Debugger e RenderDoc para GPU (que desenhos? que shader?).
4. Picos, não só médias: uma média de 10 ms com picos de 25 ms a cada poucos segundos é pior do que parece — cada pico é um tropeço visível. Coleta de lixo (GC) e carregamentos síncronos são os suspeitos habituais.
5. Sessões longas: jogue 20–30 minutos e observe a temperatura. O headset reduz os níveis de desempenho quando aquece, e um jogo que roda bem aos 5 minutos pode falhar aos 25.

8.1 Áudio espacial

Em VR, o som não é acompanhamento — é orientação. Com áudio espacializado (o Meta XR Audio SDK oferece espacialização baseada em HRTF, entre outras opções), o jogador ouve de onde vem um inimigo, vira a cabeça e o encontra. Três cuidados: toda fonte importante deve ser uma fonte 3D posicionada no mundo (não um som "na cabeça"); a acústica do ambiente (reverberação coerente com o espaço) aumenta muito a presença; e o som é uma das formas mais eficazes de chamar a atenção para algo fora do campo de visão sem mover a câmera.

8.2 Onde colocar a interface

8.3 Texto legível

• Tamanho angular, não em pixels: o que importa é o ângulo que a letra ocupa no campo de visão. Texto pequeno em painéis distantes fica ilegível, e a resolução efetiva da lente é menor que a do celular.
• Distância confortável: painéis de leitura por volta de 1 a 2 metros, levemente abaixo da linha dos olhos e curvados em direção ao jogador se forem largos.
• Contraste alto e fontes simples: serifas finas e pesos leves tremem (aliasing) em VR.
• Pouco texto: ler em VR cansa mais do que numa tela. Prefira ícones, voz e demonstração.
• A UI de mundo em Unity costuma ser feita com Canvas em World Space; a discussão entre sistemas de UI está em Unity para Aplicações, módulo 3.

9.1 As camadas de um jogo online em VR

• Rede de jogo: sincronizar objetos, física e jogadores — bibliotecas como Netcode for GameObjects (Unity), Photon Fusion ou Normcore. A escolha depende do tipo de jogo (autoridade do servidor, número de jogadores, custo de servidores).
• Plataforma: identidade do usuário, amigos, convites, grupos e salas — o Platform SDK da Meta oferece essas funções integradas ao sistema.
• Voz: em VR, voz é o principal meio social; exige espacialização (a voz sai da boca do avatar) e ferramentas de moderação.
• Avatares: cabeça e mãos sincronizadas em alta frequência são o que faz a presença do outro parecer real — e o que mais consome banda.

9.2 MR colocalizada

Várias pessoas, cada uma com um Quest, na mesma sala física, vendo o mesmo tabuleiro sobre a mesma mesa real. O problema técnico é o alinhamento: cada headset tem o seu próprio sistema de coordenadas. As âncoras espaciais partilhadas (shared spatial anchors) e a descoberta de colocalização resolvem isso: um headset cria a âncora, os outros a recebem e passam a usar o mesmo referencial. A partir daí, a rede sincroniza o estado do jogo em relação à âncora.

10.1 O caminho até a loja

A distribuição oficial é a Meta Horizon Store. Em 2024 a Meta unificou a antiga App Lab (a porta de entrada com menos exigências) com a loja principal, e passou a haver mais de um nível de visibilidade dentro da mesma loja. Os detalhes — tipos de lançamento, acesso antecipado, critérios de destaque — mudam; confira o estado atual no painel de desenvolvedores antes de planejar o lançamento.

• Verificações técnicas (VRCs): antes de aprovar, a Meta verifica requisitos técnicos e de experiência — desempenho, comportamento ao pausar e ao retirar o headset, tratamento das permissões, entrada, conteúdo. Leia a lista inteira antes de começar a polir: alguns itens exigem decisões de arquitetura.
• Canais de teste: é possível distribuir versões para grupos de testadores antes do lançamento público — use-os para testar conforto com pessoas que não são da equipe.
• Página da loja: vídeo gravado no headset, classificação de conforto honesta, modos de jogo (sentado, em pé, room-scale) e requisitos de espaço.

O uso de OpenXR facilita, mais tarde, levar o jogo a outras plataformas (Steam para PC VR, outros headsets standalone), sempre com adaptações de entrada e de performance.

10.2 Quem contrata

10.3 Projetos de portfólio

1. Um jogo curto completo em VR, rodando a 72/90 Hz estáveis no headset, com opções de conforto — e um relatório de performance com os números medidos.
2. Um jogo de MR que usa a sala com regras de posicionamento e um plano B para salas pequenas.
3. Um estudo de interação com as mãos: três objetos com pegadas diferentes e botões com feedback sem háptica, documentado em vídeo.
4. Um caso de otimização: uma cena que começa fora do orçamento e termina dentro, com o antes/depois de cada técnica (módulo 6) e as medições.
5. Um protótipo colocalizado para dois headsets, se tiver acesso ao hardware — raro em portfólios e muito valorizado.

10.4 Fontes para continuar

• Documentação para desenvolvedores da Meta: guias de Unity, boas práticas de performance e de conforto, a lista de VRCs, as amostras oficiais (há projetos de exemplo de MR, interação e performance).
• Unity: manual do OpenXR e do XR Interaction Toolkit, e os guias de otimização para mobile/XR.
• Design: as diretrizes de design de VR da própria Meta; os textos e palestras de GDC sobre locomoção e conforto.
• Na Uniana: Spatial Computing, XR & WebXR, Realidade Aumentada, Game Design, Narrativa para Jogos, O Futuro das Experiências em RA e RV.