Oito Demos, Zero Código: Para Que o SDK Precisa Servir

Se você não consegue descrever as demos, vai construir o motor errado. As oito demos canônicas da RakuAI são a especificação - oito formas de provar o que a sua IA faz quando passa a ver e agir em um cômodo real.

Um padrão que aprendi da forma difícil ao longo de três empresas anteriores: se você não consegue descrever as demos antes de construir o motor, vai construir o motor errado. As demos são a especificação. O motor precisa entregar cada uma delas. Todo o resto (arquitetura, APIs, bindings de linguagem, abstrações de hardware) é consequência do que as demos precisam fazer.

Este sábado foi dedicado a especificar as oito demos que vão ser lançadas junto com o SDK quando o SDK for lançado. Nenhuma delas tem código ainda. Todas têm especificações detalhadas o suficiente para que um engenheiro competente (ou um agente competente) pudesse começar a construí-las amanhã.

Por que oito

Três demos não seriam suficientes. Vinte seriam demais para fazer bem. Oito é o número em que cada demo prova uma categoria diferente de capacidade e o conjunto como um todo demonstra a área de superfície do que o SDK viabiliza. Um estúdio olhando para as oito deve conseguir encontrar a que corresponde ao seu produto e ler o código-fonte como um exemplo funcional. Um parceiro olhando para as oito deve conseguir enxergar a amplitude.

As oito categorias que estou fechando:

1. Modo arena solo

A demo principal de RA para um jogador. Partida multiplayer simulada com pontuação, tempo e objetivos renderizados como overlays de HUD. Rastreamento de movimento. Gatilhos por gesto. O usuário está em um cômodo real, se movendo, com conteúdo virtual reagindo a ele.

O que isso prova: o motor consegue conduzir uma experiência interativa em tempo real com o tipo de latência e qualidade de rastreamento que faz a RA parecer ancorada em vez de simplesmente sobreposta. Se essa demo funcionar bem, todas as outras ficam mais fáceis. Se não funcionar, nada mais importa.

2. Coaching e treinamento em RA

Um simulador de exercícios esportivos. Movimento de arremesso de quarterback. Exercícios de agilidade. Feedback de movimento em tempo real sobreposto ao movimento real do corpo do usuário. Diagramas de jogadas visíveis no espaço. Áudio de coaching. Estatísticas de sessão.

O que isso prova: o motor consegue ingerir dados de pose corporal e produzir feedback útil em tempo real. O caso de uso é esportes, mas a capacidade subjacente se estende a fisioterapia, instrução de dança, treinamento cirúrgico, qualquer lugar onde um especialista precise orientar um aprendiz em uma tarefa física com as mãos livres.

3. Designer de overlay de HUD

Uma ferramenta voltada ao desenvolvedor. Uma cena de teste com widgets de HUD configuráveis. Posicionamento por arrastar e soltar. Pré-visualização do layout em diferentes tamanhos de viewport. Exportação da configuração para um arquivo que outras demos podem carregar.

O que isso prova: o SDK tem uma proposta real de autoria para a camada de HUD, não apenas uma proposta de runtime. Estúdios que querem construir suas próprias configurações de HUD têm uma ferramenta funcional para fazer isso. O formato de exportação se torna um contrato que o resto das demos respeita.

4. Modo streamer e gravador POV

Uma demo construída para criadores de conteúdo. Overlays de câmera ao vivo. Bolhas de chat dos fãs exibidas como conteúdo de RA. Efeitos visuais acionados por gesto (uma bola de fogo, um emote de comemoração). Overlays de gravação para captura de melhores momentos. Replays estilo killcam.

O que isso prova: o motor funciona para produção de conteúdo ao vivo, não só para jogabilidade. As mesmas primitivas que conduzem uma partida multiplayer conduzem um overlay de stream. O caso de uso de streaming também é um dos caminhos mais rápidos para visibilidade de consumidor, porque streamers são geradores de demanda.

5. Overlay de ponto de serviço

Uma demo de nível comercial. Experiência simulada de restaurante ou varejo. Navegação por olhar e gesto em um menu. Ofertas de fidelidade exibidas de forma contextual. Fluxo de checkout. O usuário está usando os óculos em um local real, olhando para um menu real, com conteúdo virtual aumentando ambos.

O que isso prova: o motor funciona para aplicações comerciais fora de jogos. É aqui que o pipeline de parcerias encontra o produto. Restaurantes de serviço rápido, redes de varejo, locais de hospitalidade. A economia dessa categoria é diferente da de jogos, e o motor precisa suportá-la como um caso de uso de primeira classe.

6. HUD companheiro de RA

Uma demo de segunda tela. O usuário está jogando um jogo de console ou PC em uma TV. Os óculos exibem informações complementares em RA ao lado da TV. Minimapa. Contador de munição. Indicadores de amigos on-line. Conecta-se ao jogo existente sem precisar que o desenvolvedor do jogo integre nada.

O que isso prova: o motor se integra a conteúdo existente em vez de exigir que ele seja portado. Esta é a mais contraintuitiva das oito demos e provavelmente a mais importante estrategicamente. Um usuário pode adotar os óculos sem esperar que os jogos que já joga passem a suportá-los.

7. Treinador de mira em RA

Uma galeria de alvos. Alvos que surgem a distâncias variadas. Overlays de pontuação. Rastreamento ocular ou gesto para aquisição de alvo. O usuário pratica tiro de precisão no espaço de RA com feedback.

O que isso prova: o caso de uso de precisão. O treinador de mira é a demo que espero ver exibida em eventos porque é imediatamente legível para um público não técnico. Ela também estressa o orçamento de latência de rastreamento mais do que qualquer outra demo da lista, o que significa que, se funcionar bem, a proposta de latência do motor é real.

8. Sincronização de HUD multiplayer

Dois ou mais dispositivos de óculos no mesmo cômodo. Cada usuário tem seu próprio HUD, configurado para mostrar suas próprias informações, mas com elementos compartilhados entre o grupo. Etiquetas de nome com cor de time. Marcadores de objetivo compartilhados. Barras de vida do grupo. A sincronização acontece via LAN ou Bluetooth. Sem ida e volta para a nuvem.

O que isso prova: o caso multiusuário funciona sem dependência de nuvem. Esta é a demo com que lan houses gamer vão se importar. É também a demo que prova a proposta de multiplayer local do motor antes que qualquer infraestrutura de multiplayer em nuvem precise existir.

O que o conjunto como um todo prova

Cada demo acima é uma única categoria de capacidade. O conjunto junto prova algo maior.

O motor é de propósito geral. Oito demos que compartilham o mesmo SDK e o mesmo runtime, fazendo oito coisas muito diferentes, demonstram que o motor não é um produto vertical de gênero único.

O SDK é real. Um estúdio olhando o código-fonte de qualquer uma das oito demos consegue lê-lo e aprender o SDK a partir de um exemplo funcional. Essa é uma proposta de onboarding muito mais forte do que “aqui estão os docs da API, boa sorte”.

O modelo de overlay de HUD é a primitiva subjacente. As oito demos compartilham um modelo de interação orientado por HUD. Isso diz ao time do motor o que construir primeiro e diz ao time do SDK o que tornar fácil.

O alvo de hardware é plausível. Oito demos específicas que exercitam capacidades de hardware específicas (rastreamento de movimento, rastreamento ocular, gesto, áudio, captura de vídeo, sincronização por LAN) dão aos parceiros de hardware coisas específicas para otimizar.

O que vem a seguir

O próximo sábado vai para a estrutura de pastas do SDK em si. Com as demos fechadas, o SDK precisa estar organizado de forma que cada demo tenha seu próprio lugar, os módulos compartilhados sejam separáveis, e a documentação torne tudo isso encontrável. O sábado depois desse vai para a superfície de API que as oito demos consomem.

O portfólio de patentes que sustenta este produto esperou mais de uma década para o hardware alcançar. O hardware está alcançando. As oito demos acima são a aposta sobre para que o produto serve quando o hardware chegar.

As demos são a especificação. O motor precisa entregar cada uma delas. Amanhã não começa o código. O sábado depois desse também não começa o código. O sábado certo para o código começar é aquele em que as demos estiverem totalmente especificadas, o SDK estiver totalmente projetado, e os agentes que vão construí-lo estiverem totalmente reunidos.

Estou me dando o tempo. A versão que for lançada vai ser a que sabia para que servia antes de sua primeira linha ser escrita.