デスクトップ アプリを起動する 1 つのコマンド + ノード エディターが参加

「起動」と「プラグイン」の両方を簡単に

この日のスルーラインは 2 つの「シンプル化」です。 1 つは「起動」を簡単にすることです。デスクトップ上で Studio 全体を実行するということは、各サービスを起動するための一連のコマンドを記憶することを意味していました。これで、コマンド 1 つで実行できるようになりました。もう 1 つは、「プラグイン」を簡単にすることです。起動ロジックのハードコーディングが必要だったプラットフォームに新しいツールを追加します。現在は「マニフェストによる自動検出」になっています。規則に従っているプラ​​グインをドロップすると、認識されて起動されます。一連のチャットエクスペリエンスの磨き上げと内部エンジンのスリム化により、この日の作業全体は、「使用する」と「拡張する」の両方の道をより平らに舗装し、一般の人にとっては起動しやすく、開発者にとっては統合が容易になります。

デスクトップ アプリを開くための 1 つのコマンド

この日、デスクトップ側には 1 つのコマンドでランチャーが追加されました。1 つのコマンドで開発モードを開始し、パッケージをビルドし、アプリを直接開くか、すべてをシャットダウンします。ドキュメントでは、ブラウザー開発、デスクトップ開発、パッケージ化されたデスクトップ アプリの 3 つの実行方法と、それぞれに適したものについて説明しています。 Studio 全体をデスクトップ上で実行するには、各サービスを開始するために一連のコマンドを記憶して入力する必要があり、何か問題が発生した場合に回復するのが困難でした。 1 行でデスクトップ側全体が表示されるようになりました。その下では、開始/停止が「プロセス グループ」に移動されました。サービスのグループは一緒に開始され、終了時に一緒にクリーンアップされます。これは、ウィンドウを閉じるとバックグラウンドに山積みの「ゾンビ プロセス」が残り、ポートとメモリを静かに保持してマシンを停止させるという長年の問題を直接解決します。起動バーを平らにすることは、より多くの人が自分のコンピューターにインストールして毎日使用するための前提条件です。

ノードエディターがストアに加わり、プラグインは分離されます

この日、プラグインの起動が「ハードコードされたロジックの山」から「マニフェストによる自動検出」に変更されました。マニフェスト宣言がドロップインされたスタンドアロン プラグインは、システムによって自動的に認識され、起動されます。プラグインごとにメイン プログラムの起動コードを編集する必要はありません。この一般的なメカニズムを使用して、完全なビジュアル ノード エディター (「3D ローポリ」および「シーン ジェネレーター」ワークベンチをもたらす) がプラグイン全体として結合されました。分離の問題も同時に解決されました。各プラグインには独自の分離されたプロジェクト ルートがあるため、複数のワークベンチが 1 つのプロジェクトを共有し、クロストークによって間違った場所を編集することがなくなりました。開発中、プラグインはデフォルトでホットリロードするため、1 行の変更がすぐに有効になります。重要性: 「サードパーティ ツールの統合方法」を 1 回限りのハードコーディングから、再利用可能で自動検出可能で相互に分離された標準に変えることで、将来のツールをクリーンかつプラグ アンド プレイにする「プラグイン エコシステム」への重要なステップとなります。

よりスムーズなチャット + プレビュー読み込みウォッチドッグ

この日、会話パネルには一連の日常的なスムーズなインタラクションが追加されました。つまり、現在のモデルをオンザフライで切り替える、履歴をセグメント単位で再生する (長いストリップを苦労してスクロールする代わりに)、トップバーに一般的なアクションの新しいエントリが表示され、予算の残量が一目でわかるコンテキスト使用リングが表示されます。プレビューには「初期読み込みウォッチドッグ」が追加されました。読み込み後に最初のフレームが表示されるのが遅い場合は、白い画面で待たされるのではなく、画像が実際にレンダリングされるまで自動的に再読み込みされ、再試行されます。この種の「時々読み込まれないため、手動で更新する必要がある」という問題は最も忍耐力を消耗しますが、これを自動化することでエクスペリエンスがはるかにスムーズになります。バックエンドはまた、いくつかのチャットのハングを修正し、選択したモデルで会話が確実に実行されるようにしました。個々には小さいですが、これらを組み合わせることで、その日の最高周波数のサーフェスが「使いやすい」ものから「応答性の高い」ものへと磨き上げられます。

ECS の大幅なスリム化: 概念が減り、高速化、把握が容易になります。

この日、エンジンはその中核、つまりゲームの世界を記述する「エンティティ コンポーネント システム」（ECS）に対して大規模な「スリム化」を行った。これにより、いくつかの面倒な概念が削除または統合されました。個別の「コンポーネントの登録」ステップが不要になり、「ローカル変換」と「ワールド変換」が分割されていない 1 つのセットに統合され、各ワールド独自のコンポーネントの番号付けが 1 つのグローバルに統一された識別子に折りたたまれ、いくつかの冗長なローカル キャッシュが削除され、資産登録と混合されるべきではなかった責任が個別に管理されるようになりました。この背後には、プロジェクト全体を貫く設計原則があります。コードの品質の尺度は行数ではなく、「単一の箇所を理解するためにどれだけ多くの概念を保持する必要があるか」です。つまり、概念が減り、人間とそれを読み取る AI の両方でのエラーが少なくなります。このスリム化はユーザー側ではまったく目に見えませんが、エンジンがさらに大きくなるにつれて「分解可能、高速、変更可能」を維持できるかどうかを直接決定します。コアの概念的ノイズを継続的にカットすることが、このエンジンを長期にわたって健全に進化させるための内部作業です。

この日が意味するもの

その日のアイテムはそれぞれが自分の隅に気を配っているように見えますが、内部では摩擦を減らすという 1 つの追求を共有しています。ワンコマンド ランチャーは「起動」の手間を削減し、マニフェスト自動検出は「プラグイン」の手間をカットし、チャット ポリッシュとプレビュー ウォッチドッグは「日常使用」の手間をカットし、ECS スリムダウンは「コードの読み取りと変更」の手間をカットします。プラットフォームがより多くの人に使用され、より多くのツールで拡張され、長期的に維持されるためには、通常、重要なのは、いくつかの目を見張るような大きな機能ではなく、これらの目立たない摩擦を 1 つずつ滑らかにすることです。摩擦が少なければ少ないほどハードルは低くなり、喜んで参加し、滞在し、貢献する人が増えます。この日は「すべてを少しでもスムーズにする」という地味だが根本的な事柄を一気にいくつか進めた。