トグルしたりできます。シーン内の変更への反応シミュレーションビューには、ユーザーがシーンの状態を変更すると、シミュレーションプロセスが再開され、新しい状況設定がどのように機能するのかについてユーザーがすぐにフィードバックを得ることができるユーティリティーがあります。シーンの設定とテストにかかるイテレーション回数が改善します。フックすることによって、ユーザーがシーンに変更を加えたことを検出しています。フィールドを確認します。固有のコンポーネントに関する変更のみに反応するようにしています。パラメーターを何も受け取らないため、何が変更されたかを正確に知るのは困難です。含まれると考えられますが、それが保証されるのは、ロックされていないインスペクターを通じてオブジェクトが変更された場合のみです。任意のユーザーコードによって変更が行われる可能性も常にあります。コールバックによる応答のなかには、すぐに発生してほしくないものがあるケースも多いはずです。シミュレーションプロセスを再起動したくはありません。秒)を用意し、タイマーが終了したときにのみ応答をトリガーすることです。以下に、このパターンの実例を示します。対応する実装はこちらで確認できます。シーンについて、そのシーンに必要な実世界データの種類といった一定の情報をメタデータとして保存する必要があります。シーンに必要なメタデータを保存する方法はいくつかあり、それぞれに長所と短所があります。アセットを使用する長所シーンを開かなくてもメタデータにアクセスできる。エディター専用のメタデータをビルドから隔離しておくことができる(エディターのメタデータをランタイムのメタデータとは別のアセットとしている場合)。シーンと同じディレクトリーに保存している場合、見つけるのが簡単。確実にシーンと同期させる必要がある。*シーンの複製を確認し、メタデータも複製されるようにする必要がある。(新しいアセットが必要なシーンがあるほど)プロジェクトのサイズが大きくなる。アセットにすべてのシーンのメタデータを保存する長所シーンを開かなくてもメタデータにアクセスできる。エディター専用のメタデータをビルドから隔離しておくことができる(エディターのメタデータをランタイムのメタデータとは別のアセットとしている場合)。つのメタデータアセットでよい。確実にシーンと同期させる必要がある。*シーンの複製を確認し、メタデータも複製されるようにする必要がある。バージョン管理がより難しくなる。つのシーンに対する変更がマスターアセット全体に影響する。か所に保存されているため、シーンをさまざまなパッケージに分散させることができない。使用する長所シーンとの同期を維持するのが簡単。シーンを保存するとメタデータも保存される。シーンを複製するとメタデータも複製される。シーン内にメタデータがあるので見つけるのが簡単。短所シーンを開かないとメタデータにアクセスできない。ユーザー体験に悪影響を及ぼす可能性がある(「なぜこのオブジェクトがシーン内にあるのか?」)。ユースケースによっては、ヒエラルキー内のメタデータゲームオブジェクトまたはコンポーネントを非表示にして、メタデータの表示/編集用にカスタムウィンドウを用意してもよい。使用するアプローチを採用しました。使用するアプローチに変えました。いうのも、マスターアセットを使用するアプローチの短所が長所よりも大きかったからです(特に、マージの競合とメタデータの同期状態の維持)。固有のコンポーネントを必要としていたからでもあります。使うアプローチを採用する場合は、メタデータとシーンを同期させるタイミングに注意が必要です。シーンを保存していない状態でメタデータアセットをダーティーにすると、シーンの前にそのメタデータが保存されてしまう可能性があります。いうのも、プロジェクトを保存しても、開いているシーンが保存されるわけではないからです。シーンが保存されるまでメタデータアセットをダーティーにするタイミングを遅らせた場合には、シーンを保存するときに一緒にメタデータも保存する必要があります。使うと、所定のパスにシーンのパスが含まれるかどうかを確認し、含まれる場合はメタデータアセットをダーティーにして、返す文字列配列にそのパスを含めることができます。こちらに、その実行方法の例を示します。拡張を作成する際は、その拡張が他の拡張やユーザーコードとうまく連携するよう注意することが大切です。コンパイルするたびにユーザーが拡張を再コンパイルする必要がなくなります。ユーザーがコードの依存関係を定義するのも簡単になります。つの標準アセンブリがあります。ランタイムプレイヤーのビルドに含める必要のあるコードが存在すれば、それをすべて含みます。エディター専用拡張では、ランタイムアセンブリが必要ないこともあります。シーンオブジェクトに追加する必要があるコンポーネントは、ビルドに含めるかどうかにかかわらず、ランタイムに含める必要があります。ランタイムアセンブリは、エディターアセンブリを参照することはできません。フォルダーのスクリプトと同様です。コードを含める必要があります。エディターアセンブリの定義は、ターゲットプラットフォームをエディターだけにする必要があります。エディターアセンブリは、ほぼ確実にランタイムアセンブリを参照します。テスト拡張のテストだけを目的とするすべてのコードを含める必要があります。他のユーザーが拡張を変更できるようにするのでない限り、配布する際にこのフォルダーに拡張を含める必要はありませんが、パッケージによってはこのフォルダーが含まれていることがあります。つの異なるアセンブリが必要です。Extension.Tests.Editor(編集モード)Extension.Tests.Runtime(再生モード)ランタイムアセンブリの名前は、パッケージの名前です。いうような名前にする必要があります。拡張のコードの最上位名前空間は、アセンブリ定義のプレフィックスと一致する必要があります。ランタイムでエディターアセンブリのコードを使用する場合によっては、ランタイムアセンブリでエディターのコードの参照が必要になることもあります。含めることが禁じられているためにランタイムアセンブリ内に含める必要がある場合です。ディレクティブ内にいくつかの静的デリゲートフィールドを定義すると役立ちます。クラスがそれらのデリゲートに独自のメソッドを割り当てて、ランタイムアセンブリ内のそのクラス自体に対するアクセスを提供します。リポジトリで確認できます。ライフサイクルイベントと拡張性ユーザーのプロジェクトの他の側面と拡張を統合できるようにするために私たちが従っている重要なパターンがあります。それは、比較的小規模なシステムの重要な状態変化を知らせるためのイベントを提供することです。システムやオブジェクトに重要な変更が加えられた場合に発生するイベントは、一般的に、ライフサイクルイベントと呼ばれます。大切なのは、あなたのツールと統合するためにユーザーが行う必要があるであろう、あらゆることに対応することはできないと覚えておくことです。そのため、理想的にはイベントシグネチャは厳しくしすぎないようにしましょう。使用できるようにイベントを用意しています。シミュレーションに独自の機能を追加できます。しておくことで、ユーザー固有のユースケースに合わせてユーザーが行うであろうあらゆることについて、私たちが対処する必要がなくなりました(そもそも対処は不可能です)。それでいて、ユーザーは非常に柔軟に、必要な機能を実装できるのです。この場合、私たちが用意したのは非常にシンプルなライフサイクルです。作成イベントと破壊イベントを、引数なしでイベント関数に渡します。}}応答する必要がなくなったら、イベントのサブスクライブを解除することを忘れないでください。しないと、そのイベントを使用するオブジェクトが破壊された後も、そのイベントが発生する可能性があります。ライフサイクルイベントは、多くの場合、何らかの状態変更データをエンドユーザーに渡す必要があります。一連のコンポーネントが破壊または変更されたことを伝える必要があれば、次のようなイベントを用意します。まとめ私たちは、コミュニティの皆さんがエディターに追加するさまざまな面白い機能を楽しみにしています。開発者が開発者の成功を可能にするのを見るのはとても元気づけられるものです。未来を形作る手助けをすることであり、そのために、今後も知識を積極的に共有していく予定です。ニュースを受信し始めるには、あなたのメールアカウントにお送りしたリンクをクリックしてください。おっと...何らかの支障がありました。一度やり直してください。PolicyCookies。