Jevでリアルタイムゲームを操作する時に起きること
Jevの大きな特徴の一つは、一般的な生成LLMより短い応答時間で型付き判断を返すことである。TypeSafe AIは70〜500ms程度を掲げており、公式Doomデモや第三者のMOBA、レース、スマブラ系、五目並べなどでリアルタイム操作が試されている。
ただし、モデルが速いことと、ゲームを上手くリアルタイム操作できることは別問題である。
Doom：10 query/sでも、画像ではなく構造化state
TypeSafe公式のDoomデモでは10 query/s程度を使い、コストは約7ドル/時と説明されている。ただし入力は画面画像ではなく、ゲーム状態を構造化したテキスト/データである。公式自身も「非AIのDoom botの方が上手くプレイできる」と明記しており、目的は最強botではなく、異なる表現のstateへ反応し、指示に従う高速判断を見せることだった。
この条件は重要である。位置、敵、武器、healthなどを既にゲーム内部から取り出せるなら、視覚認識の問題は除かれている。
ミニMOBA：マクロとミクロは出るが、協調が崩れる
mizchi氏はLoLを簡略化したMOBAをJevに操作させ、split pushのようなマクロ戦術やtower diveのようなミクロ行動が観察されたと報告している。一方、集団戦で誰がtankするかという協調では失敗があった。
この結果は、1エージェントの局所意思決定と、複数エージェントが役割を共有して将来行動を整合させる問題が異なることを示す。
レースゲーム：上位LLM＋Jevでも時間軸がずれる
ぷらむらいす氏のレースゲーム実験では、通常LLMに大方針を決めさせ、Jevへその場の操作を任せる構成を試したが、良い感触ではなかったと報告されている。
問題は主に次の3点だった。
- 必要情報をstateへどう圧縮するか
- API応答中にも車が進み続けること
- 上位LLMの計画更新がゲーム進行に追いつかないこと
またChoiceを「加速 / 減速 / 左 / 右」のように排他的に作ると「減速しながら左へ曲がる」が表現できない。速度操作と操舵を別Questionに分けることはできるが、同一リクエスト内の各Questionは独立評価なので、回答同士が自動で協調するわけではない。
スマブラ系：4キャラクター同時操作のデモ
Mau Baron氏はJevに4キャラクターすべてを操作させる対戦デモを公開し、1試合で22M token超、費用は「数セント」と報告している。これは定量的な棋力評価ではなく、大量の低コスト判断を連続実行できることを示すデモとして見るべきである。
遅延予算でゲームを分類する
Jevをリアルタイムゲームへ使うなら、まずゲーム側の意思決定周期を決める方がよい。
- 数百ms〜数秒に1回でよい: RTSのマクロ、RPG、ターン制、NPC判断などは相性が良い。
- 100〜500ms: MOBAの高水準action、低速レース操作などはstate設計次第。
- 16ms前後を要求する60fpsアクション: クラウドJevを毎frame呼ぶ設計は現実的でない。
日本からの第三者実測では500〜600ms程度、米国側環境ではより短い例も報告されており、モデル時間だけでなくネットワークRTTも含めて設計する必要がある。
したがって、アクションゲームでは Jevが毎frameのcontrollerになるより、「数百msごとの高水準方針を選び、ローカルの決定論的controllerが数十fpsで追従する」 分業の方が自然である。
関連: JevをゼロショットゲームAIとして見る / JevをゲームAIで多段利用する設計