Acht Demos, null Code: Wofür das SDK da sein muss

Wenn du die Demos nicht beschreiben kannst, wirst du die falsche Engine bauen. Die acht kanonischen Demos von RakuAI sind die Spec - acht Wege zu beweisen, was deine KI tut, sobald sie in einem echten Raum sehen und handeln kann.

Ein Muster, das ich über drei frühere Unternehmen hinweg auf die harte Tour gelernt habe: Wenn du die Demos nicht beschreiben kannst, bevor du die Engine baust, wirst du die falsche Engine bauen. Die Demos sind die Spec. Die Engine muss jede einzelne davon liefern können. Alles andere (Architektur, APIs, Sprachbindungen, Hardware-Abstraktionen) ist nachgelagert zu dem, was die Demos brauchen.

Dieser Samstag ging in die Spezifikation der acht Demos, die mit dem SDK ausgeliefert werden, sobald das SDK ausliefert. Keine davon hat bisher Code. Alle sind detailliert genug spezifiziert, dass ein kompetenter Ingenieur (oder ein kompetenter Agent) morgen mit dem Bau anfangen könnte.

Warum acht

Drei Demos wären nicht genug. Zwanzig wären zu viele, um sie gut zu machen. Acht ist die Zahl, bei der jede Demo eine andere Fähigkeitskategorie beweist und die Suite als Ganzes die Bandbreite dessen demonstriert, was das SDK ermöglicht. Ein Studio, das sich die acht ansieht, sollte diejenige finden können, die zu seinem Produkt passt, und den Quellcode als funktionierendes Beispiel lesen können. Ein Partner, der sich die acht ansieht, sollte die Breite erkennen können.

Die acht Kategorien, auf die ich mich festlege:

1. Solo-Arena-Modus

Die Flaggschiff-Single-Player-AR-Demo. Simuliertes Multiplayer-Match mit Punktestand, Zeit und Zielen, die als HUD-Overlays gerendert werden. Bewegungsverfolgung. Gesten-Trigger. Der Nutzer befindet sich in einem echten Raum, bewegt sich, und virtueller Inhalt reagiert auf ihn.

Was das beweist: Die Engine kann ein Echtzeit-interaktives Erlebnis mit der Art von Latenz und Tracking-Qualität liefern, die AR geerdet wirken lässt statt draufgeklebt. Wenn diese Demo gut läuft, wird jede andere Demo leichter. Wenn nicht, spielt nichts anderes eine Rolle.

2. AR-Coaching und -Training

Ein Sport-Übungssimulator. QB-Wurfbewegung. Agility-Übungen. Echtzeit-Bewegungsfeedback, das über die tatsächliche Körperbewegung des Nutzers gelegt wird. Spielzugdiagramme im Raum sichtbar. Coaching-Audio. Sitzungsstatistiken.

Was das beweist: Die Engine kann Körperpose-Daten aufnehmen und daraus nützliches Echtzeitfeedback erzeugen. Der Anwendungsfall ist Sport, aber die zugrunde liegende Fähigkeit erstreckt sich auf Physiotherapie, Tanzunterricht, chirurgisches Training - überall dort, wo ein Experte einen Lernenden freihändig durch eine körperliche Aufgabe coachen muss.

3. HUD-Overlay-Designer

Ein entwicklerorientiertes Werkzeug. Eine Testszene mit konfigurierbaren HUD-Widgets. Drag-and-Drop-Platzierung. Vorschau des Layouts in verschiedenen Viewport-Größen. Export der Konfiguration in eine Datei, die andere Demos laden können.

Was das beweist: Das SDK hat eine echte Autoren-Story für die HUD-Ebene, nicht nur eine Runtime-Story. Studios, die ihre eigenen HUD-Konfigurationen bauen wollen, haben ein funktionierendes Werkzeug dafür. Das Exportformat wird zu einem Vertrag, den die übrigen Demos respektieren.

4. Streamer-Modus und POV-Recorder

Eine Demo für Content-Creator. Live-Kameraüberlagerungen. Fan-Chat-Blasen als AR-Inhalt eingeblendet. Gestengetriggerte visuelle Effekte (ein Feuerball, ein Jubel-Emote). Aufnahme-Overlays für Highlight-Reel-Erfassung. Killcam-artige Wiederholungen.

Was das beweist: Die Engine funktioniert für Live-Content-Produktion, nicht nur für Gameplay. Dieselben Grundeinheiten, die ein Multiplayer-Match steuern, steuern ein Stream-Overlay. Der Streaming-Anwendungsfall ist auch einer der schnellsten Wege zu Consumer-Sichtbarkeit, weil Streamer Nachfragegeneratoren sind.

5. Point-of-Service-Overlay

Eine kommerzielle Demo. Simuliertes Restaurant- oder Einzelhandelserlebnis. Blick- und Gestennavigation durch ein Menü. Treueangebote, kontextbezogen eingeblendet. Checkout-Ablauf. Der Nutzer trägt die Brille in einem echten Lokal, blickt auf ein echtes Menü, während virtueller Inhalt beides erweitert.

Was das beweist: Die Engine funktioniert für kommerzielle Anwendungen abseits von Gaming. Hier trifft die Partnerschafts-Pipeline auf das Produkt. Schnellrestaurants, Einzelhandelsketten, Hospitality-Venues. Die Ökonomie dieser Kategorie unterscheidet sich von Gaming, und die Engine muss sie als First-Class-Anwendungsfall unterstützen.

6. AR-Companion-HUD

Eine Zweitbildschirm-Demo. Der Nutzer spielt ein Konsolen- oder PC-Spiel auf einem Fernseher. Die Brille zeigt Begleitinformationen in AR neben dem Fernseher an. Minimap. Munitionszähler. Anzeigen für Online-Freunde. Verbindet sich mit dem bestehenden Spiel, ohne dass der Spieleentwickler irgendetwas integrieren muss.

Was das beweist: Die Engine integriert sich mit bestehendem Inhalt, statt zu verlangen, dass er portiert wird. Das ist die kontraintuitivste der acht Demos und wahrscheinlich die strategisch wichtigste. Ein Nutzer kann die Brille übernehmen, ohne darauf zu warten, dass die Spiele, die er bereits spielt, sie unterstützen.

7. AR-Zieltrainer

Eine Zielgalerie. Auftauchende Ziele in verschiedenen Entfernungen. Punkte-Overlays. Eye-Tracking oder Geste zur Zielerfassung. Der Nutzer übt Präzisionsschießen im AR-Raum mit Feedback.

Was das beweist: den Präzisions-Anwendungsfall. Ich erwarte, dass der Zieltrainer auf Events ausgestellt wird, weil er für ein nicht-technisches Publikum sofort verständlich ist. Er belastet auch das Tracking-Latenz-Budget stärker als jede andere Demo auf der Liste, was bedeutet: Wenn er gut läuft, ist die Latenz-Story der Engine echt.

8. Multiplayer-HUD-Sync

Zwei oder mehr Brillen-Geräte im selben Raum. Jeder Nutzer hat sein eigenes HUD, konfiguriert, um seine eigenen Informationen zu zeigen, aber mit Elementen, die über die Gruppe geteilt werden. Team-Farb-Namensschilder. Geteilte Zielmarker. Gruppen-Lebensbalken. Synchronisation über LAN oder Bluetooth. Kein Cloud-Roundtrip.

Was das beweist: Der Mehrbenutzer-Fall funktioniert ohne Cloud-Abhängigkeit. Das ist die Demo, die LAN-Party-Gaming-Cafés interessieren wird. Es ist auch die Demo, die die lokale Multiplayer-Story der Engine beweist, bevor irgendeine der Cloud-Multiplayer-Infrastrukturen existieren muss.

Was die Suite als Ganzes beweist

Jede Demo oben ist eine einzelne Fähigkeitskategorie. Die Suite zusammen beweist etwas Größeres.

Die Engine ist universell einsetzbar. Acht Demos, die dasselbe SDK und dieselbe Runtime teilen und acht sehr unterschiedliche Dinge tun, demonstrieren, dass die Engine kein Ein-Genre-Vertikalprodukt ist.

Das SDK ist echt. Ein Studio, das sich den Quellcode einer der acht Demos ansieht, kann ihn lesen und das SDK anhand eines funktionierenden Beispiels lernen. Das ist eine viel stärkere Onboarding-Story als „hier sind die API-Docs, viel Glück”.

Das HUD-Overlay-Modell ist die zugrunde liegende Grundeinheit. Alle acht Demos teilen ein HUD-gesteuertes Interaktionsmodell. Das sagt dem Engine-Team, was zuerst gebaut werden muss, und dem SDK-Team, was einfach gemacht werden muss.

Das Hardware-Ziel ist plausibel. Acht konkrete Demos, die konkrete Hardware-Fähigkeiten fordern (Bewegungsverfolgung, Eye-Tracking, Geste, Audio, Videoerfassung, LAN-Sync), geben den Hardware-Partnern konkrete Dinge, für die sie optimieren können.

Was als Nächstes kommt

Der nächste Samstag geht in die Ordnerstruktur für das SDK selbst. Mit den festgelegten Demos muss das SDK so organisiert werden, dass jede Demo ihr eigenes Zuhause hat, die gemeinsamen Module trennbar sind und die Docs alles auffindbar machen. Der Samstag danach geht in die API-Oberfläche, die alle acht Demos konsumieren.

Der Patentbestand, der dieses Produkt verankert, wartet seit mehr als einem Jahrzehnt darauf, dass die Hardware aufholt. Die Hardware holt auf. Die acht Demos oben sind die Wette darauf, wofür das Produkt da ist, sobald die Hardware ankommt.

Die Demos sind die Spec. Die Engine muss jede einzelne davon liefern. Morgen beginnt der Code nicht. Der Samstag danach beginnt der Code nicht. Der richtige Samstag, an dem der Code beginnt, ist der, an dem die Demos vollständig spezifiziert, das SDK vollständig entworfen und die Agenten, die es bauen werden, vollständig zusammengestellt sind.

Ich nehme mir die Zeit. Die Version, die ausgeliefert wird, ist die, die wusste, wofür sie da ist, bevor die erste Zeile davon geschrieben wurde.