ビルドとランタイムのアーキテクチャが具体化

「枠が描ける」から「建築が形になる」へ

1 日目に「ブラウザでピクセルを正しく描画できるか」という答えがあれば、この日は次の質問、つまり画像がどこから来たのかという質問に答えます。ゲーム内で実際に動くのは ECS (Entity – Component – System) と呼ばれるワールド モデルです。すべてのキャラクター、プロップ、カメラは「エンティティ」であり、その位置、外観、動作は「コンポーネント」と「システム」によって決定されます。レンダリングはあってもワールド モデルがない場合、エンジンは単なる描画ツールです。ワールド モデルはあるがレンダリングがない場合、世界は見えないままになります。この日のスルーラインはこれら 2 つの部分を接続し、それとともに全体的なビルドおよびランタイム アーキテクチャ、フロントエンド シェル、およびいくつかの基本的なエージェント機能を確立します。これにより、「会話によるゲームの生成」チェーンのすべてのリンクが形成され始めます。

ECS↔レンダーブリッジ: 世界とスクリーンを繋ぐ

この日最も重要なステップは、ECS 世界とレンダラーの間のブリッジの最初の実用バージョンを作成することでした。それが解決することは単純に聞こえますが、まったく基本的なものです。世界には、位置、方向、メッシュ、マテリアルなどのコンポーネントを運ぶ「エンティティ」があります。レンダラーは、それを画面上のどこに、どのような形式で描画するかをどのようにして知るのでしょうか?ブリッジはその変換チャネルであり、各フレームでワールド モデルの状態をレンダラーが理解できる描画コマンドに変換します。これを使用すると、描画コードを手書きしなくても、動くオブジェクトをワールドに配置すると、実際に画面上に表示され、動きます。これは、エンジンが「2 つの無関係なサブシステム」から「回転する 1 つの全体」に移行する転換点です。 「物体を置くとそれが画面に現れる」というその後のすべての経験は、この日につながった橋に遡ります。

二重実装ベンチマーク: パフォーマンスの基準

エンジンのクリティカル パスには、何かを実装するための方法が複数あることがよくあり、それぞれに独自の速度とトレードオフがあります。この日は、「デュアル実装ベンチマーク」プローブを構築しました。同じことを 2 つの異なる方法で実行し、実際のコストを並べて測定します。重要なのは 1 回のレースでどちらが勝ったかではありませんが、そのパフォーマンスはもはや推測に頼ることはありません。「このように書いたほうが速いかもしれない」という予感は、その場で同じ尺度で測定できるため、実際には遅くなる賢明に見える決定を避けることができます。長期的に進化し、あらゆる種類のデバイスで実行されることを目的としたエンジンにとって、最初に「パフォーマンスを客観的に比較する方法」を確立することは、将来のあらゆる最適化に審判を割り当てるようなものであり、速いか遅いかには証拠が必要です。

Studio フロントエンド シェルの誕生

この日、画期的な出来事も起こりました。Studio のフロントエンド シェルが最初の大まかな形状を取得しました。それまでは、すべての機能がエンジンとコマンドライン側に存在していました。しかし、エンド ユーザーが実際に直面しているのは、開いてチャットし、右側の画像を見ることができる Web インターフェイスです。この日立ち上がった最初のシェルは、チャット パネル、プレビュー ウィンドウ、および今後のさまざまなワークベンチの「骨格の出発点」です。今のところは裸ですが、重要なのは、製品が「機能の山」から「使える形」に向かって収束し始めることです。一方では、これまで以上に堅固なエンジン基盤が構築され、もう一方では、インターフェイスが形になり始めています。今後数週間で、この 2 つがスタジオに統合されます。

エージェントはコマンド システムを成長させます: ドラフト + /コンテキスト

この日、チャット エージェントは「普通の会話からコマンドへ」という一歩を踏み出しました。コマンド システムの設計草案が提出され、最初に /context コマンドの仕様が確定しました。コマンド システムは、「AI とのコラボレーション」に、予測可能で再利用可能な一連のショートカットを提供します。頻繁なアクションを毎回回りくどい文章で説明するのではなく、1 つのコマンドで正確にトリガーされます。最初に指定する /context コマンドは、長いセッションで最も重要なこと、つまり「モデルが現在どのコンテキストを保持しているか」を正確に扱います。コマンド システムの形状とその最初のコマンドを最初に決定することは、それぞれが独自の方法で記述されて衝突するのではなく、後のコマンドが同じ標準に基づいて拡張できることを意味します。

よりスマートな自動締固め: ツール別、アイドルギャップ別

AI との長時間のやりとりにより、蓄積されたコンテキストがますます長くなり、応答が遅くなり、コストが増加します。しかし、粗雑な圧縮では有用な情報が失われます。この日は、コンテキスト圧縮に 2 つの賢明な点を追加しました。1 つは、コンテキスト圧縮を「ツールごと」に扱うことです。ツールごとに重要な結果が異なるため、画一的なものではなく、何をトリミングし、何を保持するかをツールごとに決定できます。 2 つ目は、「アイドル ギャップによって」トリガーします。結果を待っていないときにウィンドウで圧縮を実行し、最も迅速な応答が必要なときではなく、気付かない瞬間にコストを非表示にします。これらを組み合わせることで、長時間のセッションでもできるだけ邪魔をせずにスリム化を続けることができます。この「モデル コンテキストの管理方法」を注意深く説明することは、まさにこのプラットフォームが最初から物事を実際のエンジニアリングとして扱う点にあります。

ツールとターミナルの堅牢性: フェッチ、キー、イベント バス

この日は、毎日の使用が横道に逸れにくくするための詳細もまとめて整理しました。 Web フェッチ ツールの両モードの安定性が向上しました。ディープ モードのエラー メッセージはより具体的で診断が容易になりました。一方、ダイレクト モードは独自に追加のコンポーネントをインストールすることが禁止され、その動作がより制御しやすくなりました。ターミナル内のカーソル移動 (行の開始/終了) がより明確なキー ルーティングに移動されたため、フォーカスとキーストロークがより正確に揃います。イベント バスは、オブザーバーのエラーが新たなエラーを引き起こし、雪だるま式に発生する自己増幅ループを修正しました。一度エラーが発生すると、ログは瞬時に爆発的に増加するため、ソースでエラーを遮断することが重要です。これらはどれも派手な新機能ではありません。 「ゴツゴツしない使い心地」を少しずつ削り出す作業です。

インストールと起動が簡単になりました

目標は「ローカルで数分で実行する」ことなので、インストールと起動のパスが不安定であってはなりません。この日は、起動フローをモジュールに再編成し、新しいパッケージ マネージャー バージョンとの互換性を持たせ、「ランタイムが見つからない場合のフォールバックとしての自動インストール」を追加し、クリーンアップ スクリプトを同じ規則に合わせました。非プロの開発者を含む、より多くの人に始めてもらいたいプラットフォームにとって、「クローンを作成してから画像を見るまで」の道のりがスムーズであればあるほど、ハードルは低くなります。早期にその道を切り開くことで、後で不快な可能性のある一連の面倒な作業を試みようとするすべての人を救うことができます。