8つのデモ、コードはゼロ：SDKが果たすべき役割

デモを言葉で説明できないなら、間違ったエンジンを作ることになる。RakuAIの8つの代表的デモが仕様そのものだ - あなたのAIが実際の部屋を見て、そこで行動できるようになったとき、何ができるのかを証明する8つの方法。

これまで3社で痛い目に遭いながら学んだパターンがある。エンジンを作る前にデモを言葉で説明できないなら、間違ったエンジンを作ることになる、というものだ。デモこそが仕様である。エンジンはそのすべてを実現しなければならない。それ以外のもの(アーキテクチャ、API、言語バインディング、ハードウェア抽象化層)は、デモが必要とするものから逆算して決まる。

この土曜日は、SDKが出荷される際に同梱される8つのデモの仕様策定に費やした。どれもまだコードは一行もない。だがすべてが、有能なエンジニア(あるいは有能なエージェント)なら明日にでも着手できるほど詳細に仕様化されている。

なぜ8つなのか

3つでは足りない。20では多すぎてうまく作り込めない。8という数は、それぞれのデモが異なるカテゴリの能力を証明し、かつスイート全体としてSDKが可能にすることの広がりを示せる数だ。8つを見たスタジオは、自社の製品に対応するものを見つけ、そのソースコードを動くサンプルとして読めるはずだ。8つを見たパートナーは、その幅広さを見て取れるはずだ。

固めに入っている8つのカテゴリは以下の通り。

1. ソロアリーナモード

フラッグシップとなるシングルプレイヤーARデモ。スコア、時間、目標をHUDオーバーレイとして描画する、シミュレートされたマルチプレイヤーマッチ。モーショントラッキング。ジェスチャートリガー。ユーザーは実際の部屋の中で動き回り、仮想コンテンツがそれに反応する。

これが証明すること。ARが後付けではなく地に足のついたものに感じられるほどのレイテンシとトラッキング品質で、エンジンがリアルタイムのインタラクティブ体験を駆動できること。このデモがうまく動けば、他のすべてのデモが楽になる。うまく動かなければ、他の何も意味を持たない。

2. ARコーチングとトレーニング

スポーツドリルのシミュレーター。クォーターバックの投球フォーム。アジリティドリル。ユーザーの実際の身体の動きに重ねてリアルタイムの動作フィードバックを表示する。空間上に見えるプレイダイアグラム。コーチングの音声。セッションの統計。

これが証明すること。エンジンが身体姿勢データを取り込み、実用的なリアルタイムフィードバックを生成できること。ユースケースはスポーツだが、その根底にある能力は理学療法、ダンス指導、外科手術のトレーニングなど、専門家が両手を空けたまま学習者に身体的な作業を指導する必要がある場面すべてに広がる。

3. HUDオーバーレイデザイナー

開発者向けのツール。設定可能なHUDウィジェットを備えたテストシーン。ドラッグ&ドロップによる配置。異なるビューポートサイズでのレイアウトプレビュー。設定を、他のデモが読み込めるファイルにエクスポートできる。

これが証明すること。SDKがランタイムの物語だけでなく、HUDレイヤーに関する本物の制作ワークフローの物語を持っていること。独自のHUD設定を作りたいスタジオは、それを実現する実働ツールを手にできる。エクスポート形式は、他のデモすべてが従う契約になる。

4. 配信者モードとPOVレコーダー

コンテンツクリエイター向けに作られたデモ。ライブカメラオーバーレイ。ファンチャットの吹き出しをARコンテンツとして表示。ジェスチャーでトリガーされるビジュアルエフェクト(火の玉、祝福のエモート)。ハイライトリール収録用の録画オーバーレイ。キルカム風のリプレイ。

これが証明すること。エンジンがゲームプレイだけでなく、ライブのコンテンツ制作にも通用すること。マルチプレイヤーマッチを駆動するのと同じプリミティブが、配信オーバーレイも駆動する。配信ユースケースは、配信者自体が需要創出者であるため、コンシューマーへの認知拡大への最速ルートの一つでもある。

5. 店頭サービスオーバーレイ

商業グレードのデモ。シミュレートされたレストランや小売の体験。視線とジェスチャーによるメニューのナビゲーション。文脈に応じて表示されるロイヤルティ特典。チェックアウトフロー。ユーザーは実際の店舗でグラスを装着し、実際のメニューを見ながら、それを仮想コンテンツが拡張する。

これが証明すること。エンジンがゲーム以外の商業アプリケーションで通用すること。ここがパートナーシップのパイプラインと製品が交差する場所だ。クイックサービスレストラン、小売チェーン、ホスピタリティ施設。このカテゴリの経済性はゲームとは異なり、エンジンはそれをファーストクラスのユースケースとしてサポートしなければならない。

6. ARコンパニオンHUD

セカンドスクリーンのデモ。ユーザーはテレビでコンソールやPCのゲームをプレイしている。グラスはテレビの隣にARでコンパニオン情報を表示する。ミニマップ。弾薬カウンター。フレンドのオンライン状況表示。ゲーム側の開発者に何も統合してもらう必要なく、既存のゲームに接続する。

これが証明すること。エンジンが既存のコンテンツを移植させるのではなく、それと統合できること。これは8つのデモの中で最も直感に反するものであり、おそらく戦略的に最も重要なものでもある。ユーザーは、すでに遊んでいるゲームがグラスに対応するのを待つことなく、グラスを導入できる。

7. ARエイムトレーナー

ターゲットギャラリー。さまざまな距離にポップアップするターゲット。スコアリングのオーバーレイ。ターゲット捕捉のためのアイトラッキングまたはジェスチャー。ユーザーはAR空間で精密射撃をフィードバック付きで練習する。

これが証明すること。精度が求められるユースケース。エイムトレーナーは、非技術者の観客にもすぐに理解してもらえるため、イベントで展示されることになると予想しているデモだ。リストの中でも他のどのデモよりトラッキングのレイテンシ予算に負荷をかけるため、これがうまく動けば、エンジンのレイテンシに関する主張は本物だということになる。

8. マルチプレイヤーHUD同期

同じ部屋にいる2台以上のグラスデバイス。各ユーザーは自分専用の情報を表示するよう設定された自分のHUDを持ちつつ、グループ全体で共有される要素もある。チームカラーのネームプレート。共有される目標マーカー。グループの体力バー。同期はLANまたはBluetooth経由で行われる。クラウドへの往復通信はない。

これが証明すること。クラウド依存なしにマルチユーザーのケースが成立すること。これはLANパーティー型のゲーミングカフェが関心を持つデモだ。また、クラウド型マルチプレイヤーのインフラが存在する前に、エンジンのローカルマルチプレイヤーの物語を証明するデモでもある。

スイート全体として証明すること

上記の各デモは単一のカテゴリの能力を示す。スイート全体としては、それより大きな何かを証明する。

エンジンは汎用的である。 同じSDKと同じランタイムを共有しながら、8つの非常に異なることを行う8つのデモは、エンジンが単一ジャンルの垂直特化型製品ではないことを実証する。

SDKは本物である。 8つのデモのいずれかのソースを見たスタジオは、それを読んで動くサンプルからSDKを学べる。それは「APIドキュメントはこちらです、健闘を祈ります」よりもはるかに強力なオンボーディングの物語だ。

HUDオーバーレイモデルが根底のプリミティブである。 8つのデモすべてがHUD駆動のインタラクションモデルを共有している。それはエンジンチームに何を最初に作るべきかを教え、SDKチームに何を簡単にすべきかを教える。

ハードウェアターゲットは現実的である。 特定のハードウェア能力(モーショントラッキング、アイトラッキング、ジェスチャー、音声、映像キャプチャ、LAN同期)を動かす8つの具体的なデモは、ハードウェアパートナーに最適化すべき具体的な対象を与える。

次にやること

次の土曜日はSDK自体のフォルダ構成に取り組む。デモが固まったので、SDKは各デモが自分の居場所を持ち、共有モジュールが分離可能で、ドキュメントがそのすべてを見つけやすくするように整理されなければならない。その次の土曜日は、8つのデモすべてが消費するAPI表面に取り組む。

この製品を支える特許ポートフォリオは、ハードウェアが追いつくのを10年以上待ってきた。ハードウェアは追いついてきている。上記の8つのデモは、ハードウェアが到着したときに製品が何のためにあるかという賭けだ。

デモこそが仕様である。エンジンはそのすべてを実現しなければならない。明日はコードを書き始める日ではない。その次の土曜日もコードを書き始める日ではない。コードを書き始めるのにふさわしい土曜日は、デモが完全に仕様化され、SDKが完全に設計され、それを構築するエージェントが完全に揃った、その日だ。

私は時間をかけている。出荷されるバージョンは、最初の1行が書かれる前に、自分が何のためにあるかを知っていたバージョンになる。