VR/AR no Desenvolvimento de Jogos: Iniciando no Metaverso

VR e AR saíram do laboratório e estão na sala das pessoas. Meta Quest 3, Apple Vision Pro e PlayStation VR2 deixaram o headset autônomo bom o suficiente pra valer a pena desenvolver pra ele. E aqui tem uma janela que indie aproveita: a base de catálogo ainda é pequena perto de mobile ou PC, a concorrência é menor, e o público que comprou um headset está faminto por coisa nova.

Eu não vou te vender metaverso como revolução inevitável. Boa parte do hype de "mercado de bilhões" é chute de consultoria. O que eu posso te mostrar é o que de fato muda quando você desenvolve pra um jogo que a pessoa joga com o corpo, e por onde começar sem queimar seis meses no caminho errado.

O que é XR e o que isso muda pra você

XR (Extended Reality) é o guarda-chuva que junta:

• VR (realidade virtual): você troca o mundo real por um mundo inteiro renderizado. Headset fechado, tracking de cabeça e mãos.
• AR (realidade aumentada): você sobrepõe conteúdo digital ao mundo real. Hoje roda principalmente no celular (ARCore no Android, ARKit no iOS).
• MR (realidade mista): o meio-termo, com passthrough colorido. O Quest 3 e o Vision Pro fazem isso: você vê a sala e objetos virtuais ancorados nela.

A diferença prática pra quem programa: em jogo de tela plana você controla a câmera. Em VR, quem controla a câmera é o pescoço do jogador. Você perde o recurso mais usado de game design (enquadrar a cena) e ganha um problema novo (a pessoa pode passar mal). É isso que muda tudo.

Hardware: onde o público está

Não precisa decorar especificação. Precisa entender em qual aparelho faz sentido publicar.

Headsets autônomos (standalone) são o centro de gravidade hoje. Rodam sozinhos, sem PC, com chip de celular dentro. O Meta Quest 3 é o aparelho que mais importa: é o mais vendido, tem passthrough colorido e hand tracking, e a loja dele é onde o indie consegue receita real. O Pico 4 é o concorrente direto, mais forte na Ásia e Europa.

VR de PC (Valve Index, HTC Vive) entrega gráfico melhor e roda pelo SteamVR, mas atinge um público menor e mais técnico. O Apple Vision Pro é caro e ainda nichado, com foco em produtividade e MR, não em jogo casual.

AR no celular é o caminho de menor atrito pra começar. Todo iPhone recente roda ARKit, e centenas de milhões de Androids rodam ARCore. Você não precisa comprar hardware nenhum pra testar AR: o aparelho no seu bolso já serve.

Conselho prático: se você vai começar em VR, mire no Quest 3 (e teste no Quest 2, que ainda tem base grande). Se quer mexer com AR, use o próprio celular. Comprar headset caro antes de ter um protótipo na mão é otimizar a parte errada.

A regra número um do VR: não enjoar o jogador

Motion sickness não é detalhe de polimento. É o motivo número um de alguém tirar o headset e dar nota baixa. O cérebro espera que, se a imagem se move, o corpo também se moveu. Quando você desloca a câmera e o ouvido interno não sente nada, o estômago reclama.

Você combate isso com decisões de design, não com mágica:

• Mantenha o framerate. No Quest a meta é 72 ou 90 FPS travados. Queda de frame em VR não é "engasgo", é desconforto físico. Esse é o requisito mais inegociável da plataforma.
• Não tire o controle da câmera do jogador. Cutscene que mexe a cabeça da pessoa à força é caminho garantido pro enjoo. Deixe ela olhar pra onde quiser.
• Cuidado com aceleração. Movimento em velocidade constante incomoda menos que acelerar e frear.

Locomoção: como o jogador anda

A forma como o jogador se move é a maior decisão de conforto que você toma. As opções mais comuns:

• Teleporte: o jogador aponta, some por um instante e reaparece no destino. É a forma mais confortável e a mais usada em jogos pra público amplo. Como não existe movimento contínuo, quase não dá enjoo.
• Locomoção suave (smooth): o jogador desliza com o analógico, como num FPS. Imersivo, mas é o que mais enjoa. Quase sempre vem com opções de conforto ligadas.
• Movimento físico (room-scale): a pessoa anda de verdade no espaço dela. Zero enjoo, mas limitado ao tamanho da sala.

O teleporte resolve o problema cortando a câmera por um instante. A ideia é simples: faça um fade rápido pra preto, mova o jogador, e volte. O corte esconde o deslocamento que o cérebro não sentiu.

public class VRLocomotion : MonoBehaviour
{
    public Transform player;        // o XR Origin / rig do jogador
    public CanvasGroup fadeOverlay; // overlay preto na frente da câmera

    public void TeleportPlayer(Vector3 destination)
    {
        StartCoroutine(TeleportRoutine(destination));
    }

    private IEnumerator TeleportRoutine(Vector3 destination)
    {
        yield return Fade(0f, 1f, 0.1f); // escurece
        player.position = destination;   // move com a tela preta
        yield return Fade(1f, 0f, 0.1f); // clareia no destino
    }

    private IEnumerator Fade(float from, float to, float duration)
    {
        float t = 0f;
        while (t < duration)
        {
            t += Time.deltaTime;
            fadeOverlay.alpha = Mathf.Lerp(from, to, t / duration);
            yield return null;
        }
        fadeOverlay.alpha = to;
    }
}

Vinheta de conforto

Quando você precisa usar locomoção suave (porque o jogo pede), a ferramenta clássica é a vinheta: você escurece a borda da visão durante o movimento, estreitando o campo de visão. Reduzir a periferia diminui a sensação de movimento que enjoa, sem tirar o que o jogador está olhando no centro.

A lógica é: quanto mais rápido o jogador se move (em linha reta ou girando), mais fecha a vinheta. Quando ele para, a vinheta abre de novo. O Unity XR Interaction Toolkit já traz um componente de vinheta de túnel pronto (Tunneling Vignette), então na prática você raramente escreve isso do zero. O importante é entender o porquê: a periferia é onde mora a sensação de movimento, então você esconde ela durante o deslocamento.

Interação com as mãos

Pegar, jogar, apertar. Em VR a mão é o mouse, o teclado e o joystick ao mesmo tempo. E a primeira coisa que o jogador faz ao entrar no seu jogo é tentar pegar tudo que vê.

Você quase nunca vai escrever o sistema de "grab" na unha. Tanto o XR Interaction Toolkit (Unity) quanto frameworks como o XR Interaction do OpenXR já trazem componentes prontos: você marca um objeto como "agarrável" (XRGrabInteractable) e um interactor na mão cuida do resto, inclusive de calcular a velocidade do arremesso quando você solta.

Os conceitos que valem entender por baixo desses componentes:

• Detecção de agarre costuma usar uma esfera de overlap na palma da mão. O motor pega todos os colliders dentro de um raio e escolhe o mais próximo. Em código cru, isso é um Physics.OverlapSphere.
• Vínculo físico: quando você agarra um objeto com física, ele precisa seguir a mão sem atravessar parede. A forma robusta é juntar os dois rigidbodies com um joint, em vez de só parentear o transform (parentear ignora colisão e fica esquisito).
• Arremesso: ao soltar, você copia a velocidade linear e angular da mão pro rigidbody do objeto. Sem isso, tudo que você joga cai no chão de pé, morto. É justamente a velocidade da mão no instante de soltar que faz o arremesso parecer real.
• Haptics: um pulso curto de vibração no controle no momento do agarre faz uma diferença enorme na sensação. É barato de implementar e o jogador sente na hora.

Se você está aprendendo, monte com os componentes do XR Toolkit primeiro. Só desça pro OverlapSphere e joints na mão quando precisar de um comportamento que o componente padrão não dá.

Interface dentro do jogo

Menu em VR não é uma tela colada na frente dos olhos. Isso enjoa e fica feio. A interface vive no espaço, como um objeto 3D que o jogador olha e alcança.

Algumas regras que se pagam:

• Distância confortável: posicione o painel a mais ou menos um braço de distância (de 1 a 2 metros). Perto demais força os olhos a vesgar; longe demais fica ilegível.
• Um pouco abaixo da linha dos olhos: ninguém gosta de ler com a cabeça inclinada pra cima.
• Billboard quando fizer sentido: painéis pequenos que sempre giram pra encarar o jogador são mais fáceis de ler. Mas não abuse: parede e mesa fixas no mundo ancoram melhor a pessoa.
• Alvos grandes: mão tremendo e tracking imperfeito significam que botão pequeno é frustrante. Faça os alvos generosos.

Pra clicar à distância, o padrão é o laser pointer: um raio sai do controle, você faz raycast contra a UI, e o ponto onde o raio bate vira o "cursor". Quando o jogador aperta o gatilho, você dispara o clique no elemento que o raio está tocando. Aqui também o XR Toolkit já entrega isso pronto com o ray interactor e o XRInteractorLineVisual. Entender a ideia (raycast a partir do controle, ponto de impacto vira cursor) é o que te deixa customizar quando precisar.

Desenvolvimento AR: o mundo real vira cenário

Em AR o desafio é o contrário do VR. Você não constrói o mundo, você entende o mundo que já existe e ancora coisas nele. O celular usa a câmera e os sensores pra montar um mapa do ambiente em tempo real.

No Unity, a camada que abstrai ARCore e ARKit é o AR Foundation: você escreve uma vez e roda nos dois sistemas.

Detecção de superfície e posicionamento

O bloco mais básico de AR é "colocar um objeto numa superfície real". O fluxo é: o AR Foundation detecta planos (chão, mesa, parede), o jogador toca na tela, você faz um raycast da posição do toque contra esses planos detectados, e instancia o objeto onde o raio acerta.

using System.Collections.Generic;
using UnityEngine;
using UnityEngine.XR.ARFoundation;
using UnityEngine.XR.ARSubsystems;

[RequireComponent(typeof(ARRaycastManager))]
public class ARPlacement : MonoBehaviour
{
    public GameObject objectToPlace;

    private ARRaycastManager raycastManager;
    private readonly List<ARRaycastHit> hits = new List<ARRaycastHit>();
    private GameObject spawnedObject;

    void Awake()
    {
        raycastManager = GetComponent<ARRaycastManager>();
    }

    void Update()
    {
        if (Input.touchCount == 0)
            return;

        Touch touch = Input.GetTouch(0);
        if (touch.phase != TouchPhase.Began)
            return;

        // raycast do toque contra os planos detectados
        if (raycastManager.Raycast(touch.position, hits, TrackableType.PlaneWithinPolygon))
        {
            Pose hitPose = hits[0].pose;

            if (spawnedObject == null)
                spawnedObject = Instantiate(objectToPlace, hitPose.position, hitPose.rotation);
            else
                spawnedObject.transform.SetPositionAndRotation(hitPose.position, hitPose.rotation);
        }
    }
}

Esse é o "hello world" do AR. A partir dele você troca o cubo por um personagem, adiciona escala por pinça, e tem a base de um jogo de mesa em realidade aumentada.

Image tracking e oclusão

Dois recursos que valem conhecer:

• Image tracking: você registra imagens de referência (uma carta, um pôster, uma embalagem) e o AR Foundation avisa quando a câmera as reconhece, com posição e rotação. É a base de carta colecionável que "ganha vida" e de manual interativo. O ARTrackedImageManager dispara um evento quando uma imagem entra, atualiza ou some, e você liga ou desliga o conteúdo conforme o estado de tracking.
• Oclusão: por padrão, objeto de AR aparece por cima de tudo, inclusive na frente da sua mão ou de uma parede que deveria escondê-lo. Isso quebra a ilusão na hora. Os aparelhos mais novos estimam profundidade e permitem que o real esconda o virtual de forma correta. Ligar oclusão é o que faz a diferença entre "adesivo flutuando" e "objeto que está mesmo na sua sala".

Não tente ligar tudo no primeiro projeto. Plane detection e posicionamento já entregam algo divertido. Oclusão e image tracking você adiciona depois.

Otimização: o orçamento mais apertado que você já viu

Aqui mora o choque de realidade. Você está renderizando duas câmeras (uma por olho) a 72 ou 90 frames por segundo, num chip de celular preso à cabeça da pessoa. O orçamento de performance é brutal, e perder frame não é estético, é físico.

A meta no Quest é simples de lembrar: 72 ou 90 FPS travados, sempre. Se você não bate isso de forma consistente, o jogo passa mal antes do jogador.

As alavancas que mais rendem em VR mobile:

• Foveated rendering: renderiza a borda da imagem em resolução menor, já que a visão periférica não distingue detalhe. No Quest isso é uma chamada da SDK da Meta (foveation fixa ou dinâmica) e costuma dar fôlego de GPU quase de graça. É das primeiras coisas a ligar.
• Reduzir draw calls: cada objeto desenhado custa, e o custo dobra porque são dois olhos. Static batching pra cenário parado, GPU instancing pra objetos repetidos, e atlas de textura pra juntar materiais. Menos chamadas de desenho é quase sempre o maior ganho.
• LODs agressivos: troque modelos por versões mais simples conforme se afastam. Em VR você pode ser mais agressivo que em jogo de tela plana, porque o jogador raramente cola o olho no que está longe.
• Shaders baratos: iluminação física completa em tudo é luxo que o Quest não banca. Use materiais simples, asse iluminação no lightmap quando der, e reserve o caro pro que está no centro da cena.

Se você vem de PC ou console, o ajuste mental é esse: em VR mobile você projeta o jogo a partir do orçamento de performance, não otimiza no fim. A arte, o escopo e as mecânicas precisam caber nos 11 milissegundos por frame desde o começo.

Frameworks e SDKs: por onde começar

O caminho mais curto e portátil hoje:

• Unity + XR Interaction Toolkit + OpenXR. O OpenXR é o padrão aberto que faz seu jogo rodar em Quest, SteamVR e outros sem reescrever a camada de entrada. O XR Interaction Toolkit dá os componentes de locomoção, agarre e UI prontos. É a combinação mais documentada pra quem está começando.
• Unity + AR Foundation pro lado AR, abstraindo ARCore e ARKit de uma vez só.
• Unreal Engine 5 é opção forte pra VR de PC com gráfico pesado, mas para Quest e mobile a maturidade de tooling e a quantidade de material do Unity costumam facilitar a vida de quem está aprendendo.

Não saia colecionando SDK. Instale o pacote de OpenXR e o XR Interaction Toolkit, monte um rig de jogador, e bote uma mão pra pegar um cubo. Esse loop simples já te ensina mais do que qualquer comparativo de hardware.

Monetização: como esses jogos ganham dinheiro

Os modelos que aparecem com mais frequência em VR:

• Premium (pago de uma vez): o jogador compra e joga. Beat Saber e Half-Life: Alyx são os exemplos clássicos. Funciona quando você tem produção polida e algo que justifique o preço. É o modelo mais direto pra quem está vendendo um jogo de verdade, não um serviço.
• Assinatura: comum em fitness e apps de exercício em VR, onde conteúdo novo toda semana justifica a mensalidade. Receita recorrente, mas exige que você nunca pare de produzir.
• Free-to-play social: o jogo é grátis e a receita vem de itens, cosméticos e economia de criadores. VRChat e Rec Room vivem disso. É o modelo mais difícil pra indie solo, porque depende de massa de gente online.

Sobre distribuição: a Meta Store (Quest) é o canal com maior chance de receita pra indie de VR hoje, com o split padrão de plataforma. O SteamVR tem público mais técnico e tolerância a preço maior, mas a descoberta é mais difícil no meio de tanto catálogo. Comece mirando uma loja só. Espalhar pra três plataformas antes de validar o jogo é desperdício de energia.

Estudos de caso: o que dá pra aprender

Dois jogos que vale destrinchar, não pelos números de receita (que viram lenda de internet rápido), mas pelas decisões de design.

Beat Saber: gameplay simples e polida até o último frame. Você corta blocos no ritmo da música, e é só isso. A lição não é "música vende", é que uma mecânica simples, executada com obsessão por feel e performance, ganha de um conceito complexo mal executado. Em VR, a sensação física do movimento importa mais que profundidade de sistema.

Gorilla Tag: a locomoção é o jogo. Você não anda com analógico, você "empurra" o chão e as paredes balançando os braços, como um gorila. Isso elimina o enjoo (o movimento é físico, casa com o corpo) e vira a coisa mais divertida do jogo de quebra. É o melhor exemplo de uma ideia que eu repito sempre: em VR, transformar a limitação (movimento enjoa) em mecânica (mexa o corpo de verdade) é onde mora o ouro.

Olhe pra esses dois e tire o padrão: nenhum venceu por gráfico ou por escopo gigante. Venceram por uma ideia central afiada que só faz sentido em VR.

Roadmap: do zero ao primeiro jogo XR

Um caminho realista, sem prometer prazo mágico. Cada etapa termina com algo que funciona na mão.

Etapa 1: fundamentos. Instale Unity com os pacotes XR. Faça o jogador entrar numa cena, olhar em volta com a cabeça e teleportar. Esse é o seu "hello world" de VR. Em AR, coloque um cubo numa superfície real pelo celular.

Etapa 2: interação. Faça o jogador pegar, soltar e arremessar objetos com as mãos. Adicione haptics no agarre. Monte uma UI no espaço com um botão que faz alguma coisa.

Etapa 3: um loop de jogo. Junte tudo num mini-jogo com começo, objetivo e fim. Não precisa ser bonito. Precisa rodar a 72 FPS no Quest e ser jogável do início ao fim.

Etapa 4: polimento e performance. Agora você briga pelo framerate: foveated rendering, batching, LODs. É aqui que o protótipo vira algo que outra pessoa consegue jogar sem passar mal.

Repare que escolher entre VR, AR e MR vem depois de você ter feito o básico nas duas pontas. Decidir o foco antes de ter mexido em ambos é decidir no escuro.

Por que vale entrar agora

Não é porque "o metaverso é o futuro". É por uma razão mais concreta: o catálogo de VR ainda é pequeno o suficiente pra um jogo bom ser notado. Em mobile você compete com milhões de apps. Numa loja de Quest, um jogo com uma ideia afiada e performance sólida ainda consegue aparecer.

A barreira de VR e AR quase nunca é técnica. As ferramentas são gratuitas, o material existe, e o aparelho de teste pode ser o celular no seu bolso. A barreira é design: entender que jogar com o corpo muda as regras, respeitar o orçamento de performance desde o primeiro dia, e ter uma ideia central que só faz sentido em XR.

Se isso te interessa, não fique escolhendo entre seis SDKs. Abre o Unity, faz um jogador olhar em volta e teleportar, e bota uma mão pra pegar um cubo. Esse primeiro protótipo na mão te ensina mais sobre VR do que um mês de leitura. O resto você descobre construindo.