エンジン アセット システム v1 + ディープ チャットの洗練

1 日に 4 つのトラック: その日のパノラマ

この日はこれまでで最も密度の高い日で、真夜中から翌朝まで 4 つのトラックが同時に実行され、機能が次々と実行され、厳格な 7 ステップの閉ループの下で修正が行われ、チャット パネルは「決して終了しない」定常状態の磨きに入り、バックエンドの安全性の確保とインターフェイスは 1 つずつテストで縮小し、さらにインターフェイスのホットリロードを自動的に引き出す終了リファクタリングでした。混乱なく 1 日にこれだけの内容を詰め込むには、次の 2 つのことが重要でした。各トラックには明確な境界線と許容基準があったこと、そして変更が基礎に近づくほど、検証可能性が高まることです。以下ではテーマごとに分けていますが、それらが 1 日でかみ合って前進したことを思い出してください。

エンジン アセット システム v1: ハンドルによるゲーム コンテンツの参照

この日のエンジンの最も重要な納品は、資産システムの最初のバージョンでした。それ以前は、モデル、テクスチャ、シーンなどの「ゲーム コンテンツ」を管理するための統一された方法がありませんでした。アセット システムは、アセットに正式なアイデンティティを与えました。すべてのアセットは、巨大な生データを渡すのではなく、軽量の「ハンドル」を通じて参照される構造化オブジェクトです。ハンドルは図書館の請求番号のようなものです。ハンドルを握ると、本全体を持ち歩かなくても、本を取り出すことができます。チェーンを検証するためにサンプル ルーム シーンが構築されました。重要性: モデル、テクスチャ、シーンをロードするための 1 つのエントリ ポイントで、ゲーム コンテンツを構造化された方法で参照、共有、再利用できるようになりました。これは、後のすべての「モデルをインポートし、アセットをシーンに配置する」機能の真の開始点です。

ピクセルパリティのベンチマーク: レンダリング品質は静かに後退することはありません

社内のレンダラーが最も恐れているのは、単一の間違ったフレームではなく、「誰も気付かないうちに静かに悪化すること」です。1 つ変更すると、一部のフレームがリファレンスと数ピクセル異なり、目には見えないものの、時間の経過とともに消えていきます。この日は、「ピクセルパリティ」の基準を提起しました。つまり、エンジンのレンダリングされたフレームを基準とピクセルごとに比較し、その差がしきい値を超えた瞬間に、継続的統合が赤色になり、変更がトランクにマージされるのをブロックします。これは、「レンダリングが正しいかどうか」を手や感覚で観察するものから、コミットごとに実行される自動で客観的なゲートに変えます。長期的に画質を進化させるエンジンにとって、このゲートは品質を安定させるための前提条件であり、これを使用することで、恐れることなくレンダリングを大胆に変更できます。

サンドボックスの視覚的検証: エージェントに画像が正しいかどうかを「確認」させます。

AI にゲームを編集させると、避けられない問題が自動的に発生します。AI が変更を加えた後、その絵が実際に正しいかどうやって判断するのでしょうか。コードエラーかどうかだけを確認すると、成功したと思っていても「コードはクラッシュしていないのに画面が真っ暗」になってしまいがちです。この日はサンドボックス内に視覚的な検証の仕組みを構築し、「映像の制作」と「映像の確認」という2つの役割を意図的に分離し、一方がゲームを実行してフレームをキャプチャし、もう一方がキャプチャされたフレームを判断しました。役割を分離すると、検証の信頼性が高まります。「編集し、スクリーンショットを撮り、問題ないと宣言します」という自己認証の罠がなくなりました。このステップは、エージェントが「コードを書ける」状態から「その出力に責任がある」状態に移行するための鍵となります。エージェントは単にコードを投げ渡すだけでなく、ループを閉じて「私が作ったものが実際にどのようなものであるか」を確認できるようになります。

インスタンス化レンダリング + 多数のオブジェクト: 試金石としてのブロック ゲーム

この日はまた、「落ちているブロックをクリアする」ミニゲームのデモで、エンジンの多オブジェクト機能を叩き込みました。このようなゲームでは、画面上に一度に多数の同一のブロックが表示されるため、それぞれのブロックに対して個別の描画コマンドを発行すると、コストが急速に増加します。このため、エンジンは「インスタンス化描画」を追加しました。1 回の送信で同じオブジェクトの大きなバッチが描画され、反復コストが償却されます。多数のオブジェクトのレンダリング パスが整理されたため、「多数のエンティティが一緒に表示される」処理が高速かつ安定して実行されます。抽象的なテストではなく、本当にプレイ可能なミニゲームを使用して検証すること自体が規律です。実際のゲームをスムーズに実行させることは、孤立したスニペットを渡すよりもはるかに説得力があります。

~100 のチャット磨きパス: コスト、期間、複数のプロバイダー

この日、チャットパネルは「決して完成しない」定常状態の磨きをかけ、いくつかの実用的なことに焦点を当てて百数回の小さな反復を行った。 1 つ目: 各ターンの実際のコストと期間を、適切な精度でセント、ダイム、ドルなどの適切な金額形式で表示し、コストが一目でわかるようにします。 2 つ: 「どのコーディング バックエンドを使用するか」の切り替え可能なセレクター: 会話を 1 つに固定でき、選択は記憶され、タブ間で同期され、上下のキーボード選択をサポートし、選択したものが使用できない場合は警告します。 3 つ目: 不安を引き起こす「モデルが長時間黙って考えている」状態を慎重に処理すること。経過秒数を表示し、しきい値を超えた切り替えを示唆し、「完了したが出力が表示されない」ことを示すプレースホルダー メモを表示します。各パスで 1 つのことに触れ、自己テストし、メモを記録しました。このトラックは、ユーザーが毎日最も長く見つめる表面であるため、100 回のパスを獲得します。どんなに強力な機能があっても、苦労して読み取って不確かに感じられれば、信頼はありません。

バックエンドの安全性と契約の強化: ホワイトリスト、トラバーサル防御、多くのテスト

エージェントは実際にマシン上のファイルの読み書きを行うため、バックエンドは「アクセスすべきもののみにアクセスできる」ようにする必要があります。この日は、ファイルとパスの安全性に関する大規模な防御とテストが行​​われました。ホワイトリストを使用してアクセス可能なパスを制限し、「ディレクトリ トラバーサル」のオーバーリーチに対する防御を追加し、ファイルを書き込むときに既存のディレクトリを上書きすることを拒否し、外部応答でユーザーのホーム パスを編集します (マシンの実際のパスが漏洩しないように)。その間、バックエンドのインターフェイス コントラクトはテストごとに固定され、どの入力が何を返すか、エッジ ケースがどのように処理されるか、すべてがテストによって保護され、単体テストの数はその日マイルストーンを超えました。これらはいずれも「目に見える新機能」ではありませんが、ファイル編集 AI を自分のプロジェクトに導入する勇気があるかどうかを決定します。明確な境界、予測可能な動作、およびテストによって検出されたリグレッションが存在する場合にのみ、真の安心感が得られます。

終了リファクタリング: インターフェースのホットリロードを独立させる

早い時間に入り、この日は構造的なリファクタリングで終了しました。インターフェイスのホットリロード メカニズムを独立させ、途中で各パーツを所定の位置に配置しました。ユーザーのゲーム データはインスタンス独自のディレクトリに移動され、エンジン ソースは統合されたビルドの場所に抽出され、環境設定はリポジトリ ルートに引き上げられ、落とし穴が発生しやすいネストされたディレクトリのレイアウトが修正されました。このようなリファクタリングでは、ユーザー側にはほとんど変化がありませんが、「コードを編集し、インターフェイスが即座にホットリロードされる」エクスペリエンスがよりクリーンになり、相互干渉が起こりにくくなります。基礎が明確であればあるほど、後の構築が速くなります。これを 1 日の終わりに行うのは、まさに、非常に多くの新しいものが導入された後、ツリー全体を再調整するために 1 回の統合が必要になったためです。

この日が意味するもの

これまでの日々が「会話によって実行可能な何かを構築できる」ことを証明したとすれば、この日は「それが長期にわたって確実に実行できるか」の基礎を築きました。アセット システムにより、コンテンツが構造的に管理されます。ピクセルパリティベンチマークとサンドボックス視覚検証により、「画像が正しいかどうか」を客観的に判断できます。バックエンドの安全性とテストにより、「AI に動作させる」ことが信頼できるものになります。チャットの洗練度は人々に毎日使いたくなるものです。そして、クロージングリファクタリングにより、エンジニアリングの観点からすべてがクリーンに保たれます。これらを組み合わせると、スタンスが明らかになります。つまり、素早く前に突き進みながらも、あらゆるステップで検証、回帰、回顧できる確かな痕跡を残します。それはまさにこのログが将来の開発のために残したいモデルです。スピードと厳密さはどちらか一方ではなく、同じ日に達成できる 2 つのものです。