Ocho demos, cero código: para qué tiene que servir el SDK

Si no puedes describir las demos, construirás el motor equivocado. Las ocho demos canónicas de RakuAI son la especificación: ocho formas de demostrar lo que hace tu IA una vez que puede ver y actuar en una habitación real.

Un patrón que he aprendido a las malas a lo largo de tres empresas anteriores: si no puedes describir las demos antes de construir el motor, construirás el motor equivocado. Las demos son la especificación. El motor tiene que entregar cada una de ellas. Todo lo demás (arquitectura, APIs, bindings de lenguaje, abstracciones de hardware) es consecuencia de lo que las demos necesitan hacer.

Este sábado se dedicó a especificar las ocho demos que se enviarán con el SDK cuando el SDK se lance. Ninguna de ellas tiene todavía código. Todas tienen especificaciones lo bastante detalladas como para que un ingeniero competente (o un agente competente) pudiera empezar a construirlas mañana.

Por qué ocho

Tres demos no serían suficientes. Veinte serían demasiadas para hacerlas bien. Ocho es el número en el que cada demo demuestra una categoría distinta de capacidad y el conjunto en su totalidad demuestra la superficie de lo que el SDK permite. Un estudio que mire las ocho debería poder encontrar la que se ajusta a su producto y leer el código fuente como un ejemplo funcional. Un socio que mire las ocho debería poder ver la amplitud.

Las ocho categorías que estoy fijando:

1. Modo arena en solitario

La demo insignia de RA para un solo jugador. Partida multijugador simulada con puntuación, tiempo y objetivos renderizados como superposiciones de HUD. Seguimiento de movimiento. Disparadores por gestos. El usuario está en una habitación real, moviéndose, con contenido virtual que reacciona a él.

Lo que esto demuestra: el motor puede impulsar una experiencia interactiva en tiempo real con el tipo de latencia y calidad de seguimiento que hace que la RA se sienta anclada en lugar de superpuesta. Si esta demo funciona bien, todas las demás demos se vuelven más fáciles. Si no, nada más importa.

2. Coaching y entrenamiento en RA

Un simulador de ejercicios deportivos. Movimiento de lanzamiento de quarterback. Ejercicios de agilidad. Retroalimentación de movimiento en tiempo real superpuesta sobre el movimiento corporal real del usuario. Diagramas de jugadas visibles en el espacio. Audio de coaching. Estadísticas de sesión.

Lo que esto demuestra: el motor puede ingerir datos de pose corporal y producir retroalimentación útil en tiempo real. El caso de uso son los deportes, pero la capacidad subyacente se extiende a la fisioterapia, la instrucción de danza, el entrenamiento quirúrgico, cualquier lugar donde un experto necesite guiar a un aprendiz a través de una tarea física con las manos libres.

3. Diseñador de superposiciones de HUD

Una herramienta orientada al desarrollador. Una escena de prueba con widgets de HUD configurables. Colocación por arrastrar y soltar. Vista previa del diseño en distintos tamaños de viewport. Exporta la configuración a un archivo que otras demos pueden cargar.

Lo que esto demuestra: el SDK tiene una historia de autoría real para la capa de HUD, no solo una historia de runtime. Los estudios que quieran construir sus propias configuraciones de HUD tienen una herramienta funcional para hacerlo. El formato de exportación se convierte en un contrato que el resto de las demos respetan.

4. Modo streamer y grabador POV

Una demo construida para creadores de contenido. Superposiciones de cámara en vivo. Burbujas de chat de fans mostradas como contenido de RA. Efectos visuales disparados por gestos (una bola de fuego, un emote de celebración). Superposiciones de grabación para capturar highlights. Repeticiones estilo killcam.

Lo que esto demuestra: el motor funciona para la producción de contenido en vivo, no solo para el juego. Las mismas primitivas que impulsan una partida multijugador impulsan una superposición de stream. El caso de uso de streaming es también una de las rutas más rápidas hacia la visibilidad de consumo, porque los streamers son generadores de demanda.

5. Superposición de punto de servicio

Una demo de nivel comercial. Experiencia simulada de restaurante o retail. Navegación por mirada y gestos a través de un menú. Ofertas de fidelización mostradas de forma contextual. Flujo de pago. El usuario lleva las gafas en un local real, mirando un menú real, con contenido virtual aumentando ambos.

Lo que esto demuestra: el motor funciona para aplicaciones comerciales que no son de videojuegos. Aquí es donde el pipeline de alianzas se encuentra con el producto. Restaurantes de servicio rápido, cadenas minoristas, locales de hostelería. La economía de esta categoría es distinta a la de los videojuegos, y el motor tiene que soportarla como un caso de uso de primera clase.

6. HUD complementario de RA

Una demo de segunda pantalla. El usuario está jugando un juego de consola o PC en un televisor. Las gafas muestran información complementaria en RA junto al televisor. Minimapa. Contador de munición. Indicadores de amigos en línea. Se conecta al juego existente sin necesidad de que el desarrollador del juego integre nada.

Lo que esto demuestra: el motor se integra con contenido existente en lugar de requerir que se porte. Esta es la más contraintuitiva de las ocho demos y probablemente la más importante estratégicamente. Un usuario puede adoptar las gafas sin esperar a que los juegos que ya juega las soporten.

7. Entrenador de puntería en RA

Una galería de blancos. Blancos emergentes a distancias variables. Superposiciones de puntuación. Seguimiento ocular o gestos para la adquisición de blancos. El usuario practica tiro de precisión en el espacio de RA con retroalimentación.

Lo que esto demuestra: el caso de uso de precisión. El entrenador de puntería es la demo que espero que se exhiba en eventos porque es inmediatamente legible para un público no técnico. También es la que más exige el presupuesto de latencia de seguimiento de toda la lista, lo que significa que si funciona bien, la historia de latencia del motor es real.

8. Sincronización de HUD multijugador

Dos o más dispositivos de gafas en la misma habitación. Cada usuario tiene su propio HUD, configurado para mostrar su propia información, pero con elementos compartidos entre el grupo. Placas de nombre por color de equipo. Marcadores de objetivo compartidos. Barras de salud de grupo. La sincronización ocurre por LAN o Bluetooth. Sin ida y vuelta a la nube.

Lo que esto demuestra: el caso multiusuario funciona sin depender de la nube. Esta es la demo que a los cibercafés de LAN party les importará. También es la demo que demuestra la historia de multijugador local del motor antes de que tenga que existir ninguna infraestructura de multijugador en la nube.

Lo que demuestra el conjunto en su totalidad

Cada demo anterior es una única categoría de capacidad. El conjunto demuestra algo más grande.

El motor es de propósito general. Ocho demos que comparten el mismo SDK y el mismo runtime, haciendo ocho cosas muy distintas, demuestran que el motor no es un producto vertical de un solo género.

El SDK es real. Un estudio que mire el código fuente de cualquiera de las ocho demos puede leerlo y aprender el SDK a partir de un ejemplo funcional. Esa es una historia de incorporación mucho más sólida que “aquí está la documentación de la API, buena suerte.”

El modelo de superposición de HUD es la primitiva subyacente. Las ocho demos comparten un modelo de interacción dirigido por HUD. Eso le dice al equipo de motor qué construir primero y le dice al equipo de SDK qué hacer fácil.

El objetivo de hardware es plausible. Ocho demos específicas que ejercitan capacidades de hardware específicas (seguimiento de movimiento, seguimiento ocular, gestos, audio, captura de video, sincronización LAN) le dan a los socios de hardware objetivos concretos para optimizar.

Qué sigue

El próximo sábado se dedica a la estructura de carpetas del SDK en sí. Con las demos ya fijadas, el SDK tiene que organizarse de modo que cada demo tenga su propio hogar, los módulos compartidos sean separables, y la documentación haga que todo sea localizable. El sábado siguiente se dedica a la superficie de API que consumen las ocho demos.

El patrimonio de patentes que ancla este producto ha estado esperando más de una década a que el hardware lo alcance. El hardware lo está alcanzando. Las ocho demos anteriores son la apuesta sobre para qué sirve el producto una vez que el hardware llegue.

Las demos son la especificación. El motor tiene que entregar cada una de ellas. Mañana no empieza el código. El sábado siguiente tampoco empieza el código. El sábado correcto para que empiece el código es aquel en el que las demos estén completamente especificadas, el SDK esté completamente diseñado, y los agentes que lo van a construir estén completamente ensamblados.

Me estoy tomando el tiempo. La versión que se lance será la que supo para qué servía antes de que se escribiera su primera línea.