Huit démos, zéro code : à quoi le SDK doit servir

Si vous ne pouvez pas décrire les démos, vous construirez le mauvais moteur. Les huit démos canoniques de RakuAI sont la spec - huit façons de prouver ce que fait votre IA une fois qu'elle peut voir et agir dans une vraie pièce.

Un schéma que j’ai appris à mes dépens à travers trois entreprises précédentes : si vous ne pouvez pas décrire les démos avant de construire le moteur, vous construirez le mauvais moteur. Les démos sont la spec. Le moteur doit les livrer chacune. Tout le reste (architecture, API, liaisons de langage, abstractions matérielles) découle de ce que les démos doivent faire.

Ce samedi a été consacré à spécifier les huit démos qui seront livrées avec le SDK quand le SDK sortira. Aucune d’entre elles n’a encore de code. Toutes ont des spécifications suffisamment détaillées pour qu’un ingénieur compétent (ou un agent compétent) puisse commencer à les construire dès demain.

Pourquoi huit

Trois démos ne suffiraient pas. Vingt seraient trop nombreuses pour bien faire. Huit est le nombre où chaque démo prouve une catégorie différente de capacité et où la suite dans son ensemble démontre la surface de ce que le SDK permet. Un studio qui regarde les huit devrait pouvoir trouver celle qui correspond à son produit et lire le code source comme un exemple fonctionnel. Un partenaire qui regarde les huit devrait pouvoir en voir l’étendue.

Les huit catégories que je verrouille :

1. Mode arène solo

La démo AR solo phare. Match multijoueur simulé avec score, temps et objectifs rendus sous forme de superpositions HUD. Suivi de mouvement. Déclencheurs gestuels. L’utilisateur est dans une vraie pièce, se déplaçant, avec du contenu virtuel réagissant à lui.

Ce que cela prouve : le moteur peut piloter une expérience interactive en temps réel avec le type de latence et de qualité de suivi qui fait que l’AR semble ancrée plutôt que plaquée. Si cette démo se joue bien, toutes les autres démos deviennent plus faciles. Si ce n’est pas le cas, rien d’autre n’a d’importance.

2. Coaching et entraînement AR

Un simulateur d’exercices sportifs. Mouvement de lancer de quarterback. Exercices d’agilité. Retour de mouvement en temps réel superposé au mouvement corporel réel de l’utilisateur. Diagrammes de jeu visibles dans l’espace. Audio de coaching. Statistiques de séance.

Ce que cela prouve : le moteur peut ingérer des données de pose corporelle et produire un retour utile en temps réel. Le cas d’usage est le sport, mais la capacité sous-jacente s’étend à la kinésithérapie, l’enseignement de la danse, la formation chirurgicale, partout où un expert doit coacher un apprenant à travers une tâche physique en gardant les mains libres.

3. Concepteur de superposition HUD

Un outil orienté développeur. Une scène de test avec des widgets HUD configurables. Placement par glisser-déposer. Aperçu de la mise en page dans différentes tailles de viewport. Export de la configuration vers un fichier que d’autres démos peuvent charger.

Ce que cela prouve : le SDK a une véritable histoire de création pour la couche HUD, pas seulement une histoire d’exécution. Les studios qui veulent construire leurs propres configurations HUD ont un outil fonctionnel pour le faire. Le format d’export devient un contrat que le reste des démos respecte.

4. Mode streamer et enregistreur POV

Une démo construite pour les créateurs de contenu. Superpositions caméra en direct. Bulles de chat des fans affichées comme contenu AR. Effets visuels déclenchés par gestes (une boule de feu, un emote de célébration). Superpositions d’enregistrement pour la capture de moments forts. Replays façon killcam.

Ce que cela prouve : le moteur fonctionne pour la production de contenu en direct, pas seulement pour le gameplay. Les mêmes primitives qui pilotent un match multijoueur pilotent une superposition de stream. Le cas d’usage streaming est aussi l’un des chemins les plus rapides vers la visibilité grand public, car les streamers sont des générateurs de demande.

5. Superposition point de vente

Une démo de qualité commerciale. Expérience simulée de restaurant ou de commerce de détail. Navigation par regard et geste à travers un menu. Offres de fidélité affichées de façon contextuelle. Parcours de paiement. L’utilisateur porte les lunettes dans un vrai lieu, regardant un vrai menu, avec du contenu virtuel augmentant les deux.

Ce que cela prouve : le moteur fonctionne pour des applications commerciales non liées au jeu. C’est là que le pipeline de partenariats rencontre le produit. Restaurants à service rapide, chaînes de commerce de détail, lieux d’hôtellerie. L’économie de cette catégorie est différente de celle du jeu, et le moteur doit la supporter comme un cas d’usage de premier ordre.

6. HUD compagnon AR

Une démo second écran. L’utilisateur joue à un jeu console ou PC sur une TV. Les lunettes affichent des informations compagnon en AR à côté de la TV. Mini-carte. Compteur de munitions. Indicateurs d’amis en ligne. Se connecte au jeu existant sans que le développeur du jeu ait besoin d’intégrer quoi que ce soit.

Ce que cela prouve : le moteur s’intègre au contenu existant plutôt que d’exiger qu’il soit porté. C’est la plus contre-intuitive des huit démos et probablement la plus importante stratégiquement. Un utilisateur peut adopter les lunettes sans attendre que les jeux auxquels il joue déjà les supportent.

7. Entraîneur de visée AR

Une galerie de cibles. Cibles surgissantes à distances variables. Superpositions de score. Suivi oculaire ou geste pour l’acquisition de cible. L’utilisateur s’entraîne au tir de précision dans l’espace AR avec du retour.

Ce que cela prouve : le cas d’usage précision. L’entraîneur de visée est la démo que je m’attends à voir exposée lors d’événements car elle est immédiatement lisible pour un public non technique. Elle sollicite aussi le budget de latence de suivi plus que toute autre démo de la liste, ce qui signifie que si elle se joue bien, l’histoire de latence du moteur est réelle.

8. Synchronisation HUD multijoueur

Deux appareils lunettes ou plus dans la même pièce. Chaque utilisateur a son propre HUD, configuré pour afficher ses propres informations, mais avec des éléments partagés au sein du groupe. Plaques nominatives par couleur d’équipe. Marqueurs d’objectifs partagés. Barres de vie de groupe. La synchronisation se fait via LAN ou Bluetooth. Aucun aller-retour cloud.

Ce que cela prouve : le cas multi-utilisateurs fonctionne sans dépendance cloud. C’est la démo dont se soucieront les cybercafés de LAN party. C’est aussi la démo qui prouve l’histoire multijoueur local du moteur avant même que l’infrastructure multijoueur cloud n’ait besoin d’exister.

Ce que la suite dans son ensemble prouve

Chaque démo ci-dessus est une catégorie unique de capacité. La suite ensemble prouve quelque chose de plus grand.

Le moteur est généraliste. Huit démos qui partagent le même SDK et le même runtime, faisant huit choses très différentes, démontrent que le moteur n’est pas un produit vertical mono-genre.

Le SDK est réel. Un studio qui regarde le source de n’importe laquelle des huit démos peut le lire et apprendre le SDK à partir d’un exemple fonctionnel. C’est une histoire d’intégration bien plus forte que « voici la doc API, bonne chance ».

Le modèle de superposition HUD est la primitive sous-jacente. Les huit démos partagent un modèle d’interaction piloté par le HUD. Cela dit à l’équipe moteur quoi construire en premier et dit à l’équipe SDK quoi rendre facile.

La cible matérielle est plausible. Huit démos spécifiques qui exercent des capacités matérielles spécifiques (suivi de mouvement, suivi oculaire, geste, audio, capture vidéo, synchro LAN) donnent aux partenaires matériels des choses précises à optimiser.

La suite

Le samedi prochain sera consacré à la structure de dossiers du SDK lui-même. Avec les démos verrouillées, le SDK doit être organisé de façon à ce que chaque démo ait sa propre maison, que les modules partagés soient séparables, et que la documentation rende tout cela trouvable. Le samedi suivant sera consacré à la surface API que les huit démos consomment toutes.

Le portefeuille de brevets qui ancre ce produit attend depuis plus d’une décennie que le matériel rattrape son retard. Le matériel rattrape son retard. Les huit démos ci-dessus sont le pari sur ce à quoi sert le produit une fois le matériel arrivé.

Les démos sont la spec. Le moteur doit les livrer chacune. Demain ne démarre pas le code. Le samedi suivant ne démarre pas le code non plus. Le bon samedi pour que le code démarre est celui où les démos sont entièrement spécifiées, le SDK entièrement conçu, et les agents qui vont le construire entièrement assemblés.

Je prends le temps. La version qui sortira sera celle qui savait à quoi elle servait avant que sa première ligne ne soit écrite.