Stingray で作業を開始すると、大量の「コンパイル」が発生することがあります。新しいプロジェクトを作成すると、エディタのコンパイルが完了するまでしばらく待たされる場合があります。エディタ内で作業しているときは、リソースがコンパイル中であることを示すメッセージが頻繁に表示されます。

ゲーム エンジンを初めて使用する方は、この動作を不可解に思うかもしれません。いったい何を、何のためにコンパイルしているのでしょうか。

この答えは、プロジェクトを構成するさまざまな種類のアセットが、どのようなステージ(作成された時点から、ランタイムにプロジェクトにロードされて、プロジェクト内で使用される時点まで)を経由して処理されるのかに関連しています。

このページでは、このパイプラインの仕組み、つまりゲームの各部を作成し、ビルドして、最終的なエクスペリエンスを実現する方法について詳細に説明します。

Stingray のプロジェクトで使用するコンテンツ要素の多くは、本来、テクスチャ アーティスト、モデラー、アニメータが Maya、Maya LT、3ds Max などの外部コンテンツ作成ツールを使用して作成したものです。この「ソース アート」段階では、Stingray では、これらのアセットのファイル形式、保管場所または共有方法などに関して要件はありません。ユーザの組織にとって最適なものを使用できます。

(Stingray の Asset Browser には FBX ファイルを使用して読み込んだ 3D アセットに対するショートカットが用意されており、そのソース アート ファイルを最初に作成した設計アプリケーションで開くことができます。プロジェクトでこの機能を利用する場合は、いくつか追加の環境設定があります。「Maya、Maya LT、3ds Max との相互運用性」を参照してください。)

最終的にゲームまたはインタラクティブなエクスペリエンス内で外部アセットを使用するには、Stingray がサポートするいずれかのファイル形式を使用して Stingray プロジェクトに外部アセットを読み込む必要があります。アセットを読み込むと、通常、プロジェクトのソース フォルダ内に新しいデータ リソースが作成されます。「アセットを読み込む」下のトピックも参照してください。

同様に、Stingray 編集ツールで作成したレベル、ユニット、およびシェーディング環境などのアセットもすべて、プロジェクトのソース フォルダに保存されます。

外部または Stingray で作成されたかどうかに関係なく、これらのソース アセットはそれぞれ、最大限の効率性よりも安定性、互換性、柔軟性を考慮して選択された「中間」形式で保存されます。たとえば、ほとんどの Stingray リソースは中間保存形式として人間が解読可能なプレーン テキストの SJSON 形式を使用しますが、一部、バイナリ形式(DDS テクスチャなど)も使用します。

一部のアセットでは、読み込んだデータ ファイルも保持され、外部ツールに戻ってアセットを微調整することができます。たとえば、読み込まれた FBX ファイルを Maya または 3ds Max で簡単に開いて読み込まれたファイルを編集し、ゲームのコンテキスト内でこれらの編集の結果を即座に確認することができます。詳細については、「Maya、Maya LT、3ds Max との相互運用性」を参照してください。

Stingray エンジンにリソースをロードして使用できるようにするには、ゲームが実行されるターゲット プラットフォームに固有のバイナリ形式にリソースをコンパイルする必要があります。このコンパイル手順は、特定のプラットフォームに合わせてデータを最適化し、ゲームの効率を最大限に高めます。

Stingray Editor に表示されるほとんどの項目は、実際はシーンの背後で実行される Stingray エンジンのインスタンスによって提供されています。このため、Stingray Editor での作業中に修正および作成されたリソースは、ソース マテリアルへの最新の変更に合わせて、コンパイル済みデータが最新の状態に維持されるように、Windows ではシーンの背後で常にコンパイルされています。他のターゲット プラットフォームでは、そのプラットフォームでゲームをプレイテストまたはデプロイするたびに、コンパイル済みデータが更新されます。

一般的には、ユーザがデータをコンパイルするたびに、Stingray はそのプラットフォームにおける最後のコンパイル後に追加または変更されたリソースのみをコンパイルする必要があります。この増分コンパイルは、ユーザが作業中にコンパイル手順を非常に迅速に実行できることを意味します。

既定では、各 Stingray プロジェクトは常に個別のフォルダにコンパイルされます。このフォルダはプロジェクトのソース フォルダと並んで配置されている、接尾辞 _data が付いたフォルダです。各ターゲット プラットフォームには、win32、android、ios などの独自のサブフォルダが用意されています。このプラットフォーム固有のコンパイル済みデータ フォルダには、ソース フォルダと同じすべてのリソースが含まれていますが、各コンパイル済みファイルには元の名前に英数字ハッシュを付加した名前が付けられ、data サブフォルダ内に保存されます。ゲームのマスター settings.ini ファイルなどのあらゆる .ini ファイルは、コンパイルまたは名前変更されません。

ゲーム用のコンパイル済みデータには、Stingray インストール フォルダからの「コア」リソースのコンパイル済みバージョンも含まれています。これには、Appkit を構成する Lua ファイルやその他の既定のコンテンツも含まれます。コア コンテンツの詳細については、「コア リソースを使用する」も参照してください。

コンパイル手順では、ターゲット プラットフォームで使用するためにリソースの準備を行いますが、個々のデータファイルをコンパイル済みフォルダから 1 つずつロードするには時間がかかります。これはオペレーティング システムがハード ディスクやゲームが格納されたゲーム DVD の多数の異なる場所から小さいファイルをロードする必要があるためです。さらに、ゲーム内のリソースの数が増えて、メモリ内にさまざまなリソースが存在する場合に、各リソースを個別にコントロールする面倒でエラーが発生しやすいプロセスを使用せずに、簡単にコントロールできるようにする必要があります。

これらの 2 つの問題を解決するには、リソース パッケージと呼ばれるバンドルにリソースを分割します。プロジェクトのソース フォルダ内のデータ リソース、およびその他のデータ リソースで、これらのパッケージを定義します。ターゲット プラットフォーム用にゲームのビルドをデプロイするときに、Stingray ではコンパイル済みデータをより大規模なチャンクにバンドル化します。各バンドルは定義したリソース パッケージの 1 つに対応します。ゲームプレイ コード内で、これらのバンドルがメモリからいつロードおよびロード解除されるかを指定します。各バンドルは 1 つのファイルであるため、それぞれがハード ドライブまたはゲーム DVD の連続したブロックに格納されます。このため、コンパイル済みデータを直接使用するよりも、バンドルははるかに迅速にロードできます。

リソース パッケージとバンドルの詳細については、「ランタイムでコンテンツをロードおよびロード解除する」を参照してください。

バンドル化は、作業中にバックグラウンドで実行される増分プロセスではありません。通常、これは Stingray Editor の Deployer パネルを使用して、ゲームをデプロイした場合にのみ発生します。「配置とビルド」も参照してください。

このイメージは、プロジェクト フォルダ、コンパイル済みデータ、バンドル済みデータのコンテンツ レイアウトを並べて比較したものです。コンパイル済みデータはプラットフォーム固有のもので、元のプロジェクト フォルダ内(およびここで表示されていないコア リソース フォルダ)の各リソースに対して、コンパイル済みデータ ファイルが含まれています。バンドル済みデータ フォルダでは、各ファイルは多数のコンパイル済みデータ ファイルが 1 つのファイルに統合されたバンドルであるため、データ ファイルの数がはるかに少なくなっています。