Stingray の拡張方法について検討する前に、Stingray エコシステム全体の設定方法を理解しておくと役立ちます。

Stingray は、プロジェクト、エンジン、エディタという、連携する 3 つの主要コンポーネントで構成されているとみなすことができます。

• プロジェクトは 3D オブジェクト、マテリアルとテクスチャ、レベル、Lua スクリプト、フロー グラフ、その他のコンテンツなど、さまざまな種類のアセットが集まったものです。一般に、ユーザとして Stingray を使用している場合、作業時間の大半は、プロジェクトへのアセットの取り込み、新しいアセットの作成、および作成したシーンとプレイヤーの相互作用方法や操作性の設定に費やされます。

• エンジンは本来、プロジェクト コンテンツのビューアまたは再生アプリを意味します。このアプリには、Stingray でサポートされているプラットフォームごとに異なるバージョンがあります。エンジンのジョブは、プロジェクトを構成するアセットをロードすることであったり、ユーザ入力の承諾、イベントの処理、シーンのレンダリングといったメインの更新ループを繰り返し実行することであったりします。

• エディタは、Windows 専用のオーサリングツールです。エンジン内でプロジェクトを実行するときに、プロジェクト コンテンツを作成し、希望する外観および動作が実現されるように設定することができます。

これらの 3 つの主要コンポーネントをそれぞれ拡張する Stingray の「プラグイン」を作成できます。詳細については、「Stingray の拡張方法」を参照してください。

上記の 3 つのコンポーネントの図には、3 つのコンポーネントの一般的な役割が概念的に正しく表されていますが、エディタ、プロジェクト コンテンツ、およびエンジン間の相互作用は実際はもっと複雑です。

• エディタは Windows エンジンの独自インスタンスを実行します。このエンジンで作業しているときにプロジェクト コンテンツがロードされ、このエンジンを使用してレベルやその他のアセットが統合ビューポートにレンダリングされることによって、シーンをプレビューできるようになります。

  

• エディタ内で使用するプロジェクト コンテンツは Asset Browser に一覧表示されますが、エディタの内部エンジンがロードおよびレンダリングするファイルと完全に同じではありません。コンテンツは、FBX ファイル、.png や .dds ファイルなどのイメージ形式、およびプレーンテキスト形式の SJSON ファイルといった未加工の形式で作成されますが、エンジンはこれらの未加工のアセットを、サポート対象プラットフォームごとに異なる最適化されたバイナリ データ形式にコンパイルする必要があります。この詳細については、アセット パイプラインに関するこのトピックを参照してください。

• データのコンパイル手順は、実際はエンジンによって実行されます。Windows バイナリの場合は、変更内容をアセットに保存するたびに、エディタがこのコンパイルを自動的にトリガします。その他のプラットフォームの場合は、該当するプラットフォームでプロジェクトを実行するとき、エディタでリモート デバイスをミラーリングするとき、または該当するプラットフォームのプロジェクトを配置するときに、データをコンパイルするようエディタからエンジンに要求されます。

• アセットに対する変更内容がディスクに保存され、Windows 固有のバイナリ形式にコンパイルされ、内部エンジンに再ロードされるまで、エディタが待機するとは限りません。このラウンドトリップ プロセスは変更を保存するときにシーンの背後で実行されますが、オブジェクトの移動やスライダの調整などの変更を行っている場合は、エディタ内で即時のフィードバックが必要になることがあります。エディタ ビューポート内でユーザが行っている作業内容について即時フィードバックを送信するために、エディタ内で実行されているエンジンはゲーム実行時と異なる方法でレベルをロードします。

  エディタは事前に記述された Lua スクリプトのフレームワークを使用して、レベルのアセットをエンジンにロードする方法や、エンジン ビューポート内でこれらのアセットを操作する方法をコントロールします。これらのすべてのスクリプトは core/editor_slave フォルダ内にあります。プラグインをエディタのビューポートと統合して、未保存の編集に関する即時フィードバックの提供などを行う必要がある場合は、状況に応じてこのスクリプト環境と統合する必要があります。

より全体的な図は次のようになります。

ただし、この図に示されているのは、Windows 専用のプロジェクト作成ワークフローおよびテスト ワークフローです。他のプラットフォームのテストやミラーリング、およびゲームの最終バンドルの配置に関するその他のワークフローは省略されています。

最後の注目すべき点は、Stingray 編集ツールが実際は上記のような単一の一体型エンティティでないことです。オートデスクでは、メインの Stingray エディタが十分な拡張性を備えていて、あらゆる種類のコンテンツ オーサリング ワークフローまたはツールのプラグインをサポートできるようになることを望んでいます。ところが、実際は、エンジンで認識されるコンテンツ生成機能を持つあらゆるものが、このコンテンツを未加工のソース フォルダに保存することによって、「エディタ」として機能する可能性があります。

たとえば、Unit Editor や Texture Manager など、Stingray に付属している他の編集ツールを独立したアプリケーションとして使用することができます。また、お気に入りのテキスト エディタを使用して、Lua スクリプトの作成、およびレベルやユニットなどの未加工の SJSON コンテンツの編集を行うことができます。プラグインによって新しい種類のデータ形式に関するランタイム サポートが追加された場合は、別の独自ツールを使用してプロジェクト ソース フォルダ内にこのデータを作成し、このフォルダ内で管理することができます。

Stingray ツール(通常はメインの Stingray エディタ、Unit Editor など)を使用するか、またはコマンド ラインで適切なフラグを指定してエンジンを呼び出すことにより、追加または変更したすべてのアセットが最終的にターゲット プラットフォーム用にコンパイルされることを確認する必要があります。エンジン コマンドライン リファレンスを参照してください。

ただし、この SDK ガイドのコンテキスト内で「エディタ」の拡張について説明している場合は、メイン Stingray エディタ内で実行されるプラグインを記述することを意味しています。