デスクトップ アプリの登場 + 共有ゲーム ライブラリ

「ブラウザタブ」から「実際のアプリケーション」へ

これまで、Studio はブラウザー タブ内に存在していました。つまり、Studio の存在はそのタブに依存していました。タブを閉じたり、更新したり、ブラウザーをクラッシュさせたりすると、進行中のすべての作業がタブに依存していました。その日の見出しは、これをスタンドアロンのネイティブ デスクトップ アプリにし、初めて「独自のウィンドウ、独自のプロセス」を提供するというものでした。これに関連して、他のラインはプラットフォームをより成熟した製品に近づけました。複数のゲームがコンテンツを共有し、エージェントがより直接的に機能を呼び出し、エンジンがオーディオとマルチパス レンダリングを追加し、リポジトリがスリム化されました。 「ブラウザで実行できる」から「アプリケーションとして長期間開いたままにできる」にアップグレードしたことは、今日の最も記憶に値する変革です。

デスクトップ アプリ: フロント ウィンドウを閉じても、エージェントは死なない

この日は、デスクトップ アプリの完全なシェルを立ち上げました。Studio は初めて、単なるブラウザー タブではなく、ネイティブ デスクトップ ウィンドウとして開くことができました。これには、プロセス キープアライブ (ウィンドウを超えてバックグラウンド サービスを存続させる)、ウィンドウ管理、およびデスクトップ ビルドをパッケージ化する際の正しいアセット ルート解決が付属していました。これにより、初期の「ブラウザを閉じてもエージェントは存続する」機能がついに実際のデスクトップ エントリに追加されました。キープアライブは以前はブラウザ内にありましたが、ネイティブ ウィンドウを使用することで、実際のアプリケーションとして長期間開いたままにすることができます。エージェントに手動で作業させ、フロント インターフェイスを閉じると、エージェントはバックグラウンドで実行され続けます。進捗状況を確認したい場合はウィンドウを開いてください。 「アプリケーション」として独立できる形式は、「デモ プロジェクト」から「日常ツール」への重要な飛躍です。

複数のゲームが 1 つのライブラリを共有する

複数のゲームが 1 つのゲーム ライブラリを共有できるようになりました。共通のアセットとコンポーネントを共有ライブラリに配置すると、各ゲームがそれらを参照するための独自の「インデックス」を保持します。マテリアルをすべてのゲームにコピーする必要はありません。複数の作品を長期的に育成するクリエイターにとって、これは、重複したコピーをあちこちに散在させるのではなく、シリーズまたはいくつかのプロトタイプが同じリソースをきれいに再利用できることを意味します。これには思慮深い最適化が含まれています。開発中、1 つのゲームでアセットを変更すると、ワークスペース全体を最初から再スキャンするのではなく、「現在作業しているゲーム」のリソースのみが再スキャンされます。多くのゲームでは、それが「すぐに有効になる」か「毎回しばらく待つ」かの違いです。共有とローカル再スキャンを併用すると、「1 人で多くのゲームを管理」することがスペース効率よく、よりスムーズになります。

エージェントはチャット内でホワイトリストに基づいてホスト ツールを呼び出します

この日は、型定義から実行時まで「ホワイトリスト」チャネルを配線しました。エージェントはマニフェストで「どのホスト ツールを呼び出すことが許可されているか」を宣言でき、「ホスト ツール ブリッジ」は宣言されたツールを会話ツール リストに挿入します。古い、ハードコードされたツール キットは途中で廃止されました。具体的には: ストーリーを担当するエージェントは、一連のナラティブ関連ツールをホワイトリストに宣言しているため、別のキットを経由することなく、きめ細かいナラティブ ツールのセット全体をチャット内で直接呼び出して、プロットを調整できます。その値は「明示的な承認、直接呼び出し」です。各エージェントが使用できるものはマニフェストに詳しく記載されており、安全かつ制御可能であり、「エージェントに必要な機能を装備する」ことは宣言的で保守可能なものになります。これが、「誰でも設定でき、それぞれが得意分野を持った」エージェントシステムの基本です。

エンジン: マルチパス レンダー パイプライン + オーディオ + 切り替え可能な AA

この日はエンジンにいくつかの部品が充填されました。レンダリングの抽象化は「マルチパス」パイプラインに成長しました。多くの高度な視覚効果 (特に後処理) は基本的に「複数のステップでレイヤーを重ねて」計算され、適切なマルチパス構造を使用すると、そのようなエフェクトは詰め込まれたものではなく、すっきりとした方法で構築されます。 アンチエイリアスは実行時に切り替え可能になり、オンとオフの比較が容易になり、調整中に一目瞭然になりました。このエンジンはオーディオ デモも構築し、「ゲームでサウンドを生成できる」ことをエンドツーエンドで検証しました (サウンド システムは以前に統合されており、この日は可聴サンプルを入手しました)。物理学により、「アイドル」バグが修正されました。以前は一部のオブジェクトが力が加わっていない状態で所定の位置に固定されていましたが、現在は落下し、衝突し、適切に移動します。これらを組み合わせることで、エンジンの 3 つのエクスペリエンス ライン (ビジュアル、サウンド、物理) がすべて強化され、「真に完全なゲームを作成できる」というさらなるレベルが確立されます。

リポジトリのスリム化: コードベースからバイナリを取得する

この日、エンジンは「リポジトリのスリム化」も行いました。つまり、かさばるバイナリ アセット (サンプル マテリアル、ベースライン イメージ、ビルド アーティファクトなど) をコード リポジトリから削除し、それらを専用のリソース リポジトリに移動するかオンデマンドで再構築し、バイナリを誤ってコードベースに戻さないように継続的統合チェックを確立します。これはユーザーには見えませんが、最前線の開発エクスペリエンスを真に向上させます。小さいリポジトリはより速くクローンを作成し、よりクリーンな履歴を持ち、日々の動作が軽く感じられます。長期的に進化し、オープンソース化され、より多くの人が開始するためにクローンを作成することを意図したプロジェクトにとって、「コードベース内のコードのみ」は維持する価値のある規律です。これは、新人 (または CI マシン) がどれくらい待つか、最初にプロジェクトをプルダウンするときにどれくらいのスペースが必要かに直接影響します。この長期的な負担を早期に解決することは、将来のすべての協力者に対する親切です。

この日が意味するもの

この日のテーマは、プラットフォームを「ブラウザ上で動作するもの」から「所有して長期的に使用できるアプリケーション」に成長させること。デスクトップ シェルは、独自のウィンドウとプロセスを提供しました。共有ゲーム ライブラリを使用すると、その中で複数の作品を育成できます。ホワイトリスト ツール チャネルにより、エージェント システムの構成と制御がより容易になります。エンジンのオーディオとマルチパス レンダリングとリポジトリのスリム化により、それぞれ「構築可能」と「長期実行」という目的が強化されます。これらの異なる目的を持った変更は、成熟度の 1 つの指標を示しています。これは、もはや「会話でゲームが作れる」ことを実証する単なるプロジェクトではなく、コンピューターにインストールして毎日起動し、長期的に使用できるツールです。それが「アプリケーション」として自立できるようになった瞬間、製品のアイデンティティは変わります。