プロジェクトのキックオフ

初日がレンダリングの基礎から始まる理由

これは、プラットフォームの公開記録の 1 日目です。 「チャットするとゲームが表示される」プラットフォームの場合、根本的に重要なことが 1 つ当てはまります。それは、ブラウザーが 3D を真に安定してレンダリングする必要があるということです。したがって、初日は派手なインターフェースを積み上げることではありませんでした。最も難しい部分であるレンダリング基盤に全力を注ぎ、既製の汎用ライブラリをラップするのではなく、ブラウザの次世代グラフィックス機能 (WebGPU) 上に直接レンダリング パイプラインを社内で構築します。その道は最初は難しく、遅くなります。他の人がパッケージ化した多くの詳細を自分自身で歩き、落とし穴を 1 つずつ埋めなければなりません。しかし、画質、パフォーマンス、機能が上流ライブラリのトレードオフによって抑制されるのではなく、後になって私たち自身の手に残るかどうかは、それが決定します。今日の成果物は、「ブラウザで最初のピクセルを正しく照らす」という 1 つの大きなことの実際には異なる側面です。この最も過小評価され、最も妥協しにくいものを最初にしっかりと確立することが、「会話によってゲームを生成する」というその後の夢に足場を与えることになります。

動作するシェーダー パイプライン: WGSL + シェーダー コンパイル シム + 簡素化された PBR

レンダリングの中核はシェーダーです。これは、GPU に「各ピクセルを何色にするか」を指示する小さなプログラムです。この日は、シェーダー パイプライン全体を配線しました。ブラウザー グラフィックス標準のシェーダー言語 (WGSL) で記述され、シェーダー ソースを適切な GPU 実行可能形式に変換するコンパイル シムと組み合わせられ、さらに簡略化された物理ベース シェーディング (PBR) 実装も行われました。 「物理ベース」とは、材料が現実世界のルールに従って光に反応することを意味します。金属は金属のように、プラスチックはプラスチックのように見え、色付きの紙の切り抜きではありません。この簡素化された PBR は、無駄のないリソース バインディング構造 (バインド グループが 3 つだけ) を意図的に使用して、イメージの信頼性を維持しながら軽量性を維持し、理解しやすく、拡張しやすくしています。コンパイル シムは特に重要です。WebGPU は高レベルのシェーダー ソースを直接消費しないため、その間に低レベルの形式への変換ステップが必要になります。ブラウザ内でそれを解決することで、「シェーダーを作成してすぐに結果を確認する」ことが可能になります。この日から、エンジンは単に三角形に色を付けるだけではなくなりました。これは、ライティングされマテリアルを備えたオブジェクトをレンダリングします。これは、「描画できる」から「正しく描画できる」までの重要な最初のステップであり、その後に続くすべてのより豊かなマテリアルとライティングの適切な出発点となります。

レンダリング デバイス レイヤがエンドツーエンドで引き継がれる

シェーダーを実行するには、GPU リソースの要求、キャンバス サーフェスの管理、各フレームの描画コマンドの整理、GPU への送信など、すべてを処理する下に「レンダリング デバイス レイヤー」が必要です。この日はそのレイヤーを最初から最後まで完全に引き継ぎ、初期セットアップからフレームごとに安定して生成するまで、チェーン全体を段階的に検証し、一連のマイルストーンをすべて達成しました。プレイヤーはこのレイヤーを見ることはありませんが、すべてのレンダリングの管理者です。これがソリッドである場合、その上のゲームもソリッドです。穴があると、最も美しいエフェクトでもランダムにブラックアウトしたりクラッシュしたりします。レンダリングの問題の多くは、表面上はエフェクトが壊れているように見えますが、実際の根本はこのレイヤーが整理されていないことにあります。それを段階的に検証可能にすることは、長期的な利益ももたらします。将来のフレームに問題が発生した場合、黒い画面を無力に見つめるのではなく、これらのマイルストーンを遡ってどのリンクが壊れたかを特定することができます。まず頑丈にすることで、今後のあらゆるレンダリング機能に信頼できる軌道を築きます。

最初のクロス環境のハードル: GPU メモリのライフサイクル ホットフィックス

さまざまな環境で WebGPU を実行すると、GPU メモリ バッファーは「使用可能なとき、いつ返却するか」に関する厳密なライフサイクル ルールに従います。タイミングがずれると、読みかけのダーティデータが発生したり、完全にクラッシュしたりすることになります。この日は、「マップされた読み取り/書き込み」段階でのバッファーのライフサイクルをホットフィックスし、2 つのまったく異なる環境でのルールに従うようにしました。1 つは個別の GPU を使用せず、レンダリングが純粋にソフトウェアでシミュレートされる環境で、もう 1 つはブラウザーがマシンのネイティブ グラフィックスを直接呼び出す環境です。同じコードが両方のパスで正しく動作するためには、GPU メモリの割り当てと返却のタイミングが正確に行われる必要があります。このような修正は「目に見える新機能」を提供するものではありませんが、エンジンが「私のマシン上で時々動作するおもちゃ」であるか、「別のマシンや別の環境でも動作するベース」であるかを決定するのはまさにそれらです。社内レンダラーのコストの大部分は、環境間の不確実性を一度に 1 つずつ解決するという大変な作業に費やされます。それぞれが接続されると、プラットフォームが確実にカバーできるデバイスの範囲が広がります。

安全な同時実行性: エージェントごとのライフサイクル ロック

プラットフォームのもう一方の側は、あなたとチャットして仕事を行うエージェントです。このプラットフォームは最初から「同時に働くエージェントのチーム」、つまり一度に 1 人のアシスタントと話すのではなく、リードがタスクを配り、サブエージェントがそれぞれ担当することを想定しています。しかし、複数のエージェントが同時に実行されると、古典的な「競合状態」が発生します。つまり、2 つのアクションが順序が保証されずにほぼ同時に同じエージェントの状態に影響を及ぼし、断続的な破損やハングが発生します。この日は、各エージェントのライフサイクル管理を専用の「非同期ロック」コンポーネントに抽出しました。同じエージェント上の操作 (開始、停止、切り替え) は、そのロックを通じてキューにシリアル化され、常に 1 つのアクションのみがその状態に影響することが保証されます。これにより、多数のエージェントを実行してもお互いに踏みにじる必要がなくなり、動作が予測可能になります。 「マルチエージェントのコラボレーション」を中核的な約束として扱うプラットフォームにとって、このロックは、ブループリントをデモ内でのみ実行するのではなく、実際に着陸させるための重要な部分です。

より頑丈な端末: ペーストがクラッシュしない + コラボレーション ガイダンス

同時実行の安全性を超えて、チャット エージェントには 2 つの「日常的な」修正が加えられました。まず、ターミナル入力です。古い「2 回目の貼り付けがフリーズする」バグが修正され、コマンド ラインに長い要件テキストを貼り付けることがより弾力的になりました。セットアップのブロック全体または長い仕様を貼り付けると、固まることはありません。 2 つ目は、コラボレーション コミュニケーションです。エージェントが互いにメッセージを送信するために使用するツールには、使用シナリオと返信ガイダンスが具体化されているため、「誰が、いつ、どのようにメッセージを送信するか」が構造化され、複数エージェントのコラボレーション中のコミュニケーションが場当たり的ではなくなります。 「使いにくく感じない」ための重要な詳細は次のとおりです。要件を貼り付けるときにクラッシュしたり、共同作業中におしゃべりになったりするアシスタントは、どんなに賢くても信頼できません。この荒削りな部分を一つ一つ滑らかにしてこそ、本物の仕事にふさわしいものになるのです。

無駄なキャッシュなし: 新しいメッセージを追加する動的なリマインダー

大規模なモデルと通信する場合、時間とコストを節約するために、前もって安定したコンテキストを「キャッシュ」できます。ただし、毎回最前部を書き直すと、そのキャッシュが無効になり、完全な再計算が強制されます。この日は、「動的なリマインダー」（モデルに渡される会話を変更する一時的な情報）を「先頭の書き換え」から「最後に新しいメッセージを追加」に変更し、プレフィックス キャッシュを保持しました。ダイレクトな感触: 応答が速くなり、長時間の会話でもコストが削減されます。このような最適化自体は小規模に見えますが、AI との長時間のやり取りを中心に構築されたプラットフォームでは、スムーズさと支出に実質的な違いが生じます。会話が長くなればなるほど、この早期の適切な判断がより効果的になります。また、プロジェクト全体を貫く姿勢も明らかにしています。つまり、「モデルと対話する方法」を、思い付きでまとめたプロンプトではなく、真に磨きをかける価値のあるエンジニアリングとして扱うということです。

この日が意味するもの

初日の作品をまとめて見ると、どれも意図的に「自慢するための機能」ではないことがわかります。きれいなホームページや派手なデモはありません。これらは、レンダリング、エンジン、同時実行性、会話という 4 つのスルーラインのそれぞれの最初の基礎です。その背後には、明確な判断があります。「チャットによるゲームの生成」が最終的に機能するかどうかは、その日にトリックをデモできるかどうかではなく、基礎が十分に難しいかどうか、つまり、ブラウザーで描画可能、どの環境でも安定している、エージェントが戦わない、お金を無駄にしない長い会話ができるかどうかにかかっています。これら 4 つのファンデーションを一度に注ぐと、毎日その上に着実に重ねていくことができます。これは、この変更履歴が将来の開発のために残しておきたい最初のモデルでもあります。最も困難で、あまり魅力的でなく、最も妥協しにくいものを最初に正しく設定します。