見出し画像

Project Tiny のプロジェクト構造

npaka

以下の記事を参考にして書いてます。

・Anatomy of a Tiny Project

1. DOTSと従来のUnityプロジェクトの違い

DOTSと従来のUnityプロジェクトは非常に良く似ていますが、次の点が異なります。

(1) シーンは完全に変換可能なコンポーネントを含む「DOTS SubScene」で構成するか、最上位のシーンのGameObjectで「Convert to Entity」コンポーネントを使用する必要があります。

画像1

Entityに変換されないGameObjectは、オーサリング目的に使用できますが、プレイモードおよびビルド時には使用できません。

(2) ランタイムコードは、「Assembly Definition」を使用してアセンブリにコンパイルする必要があります。

画像2

(3) コードで使用できるのは「DOTS API」のみです。「UnityEngine API」はサポートされません。ロギングなど一部コード互換性を除いて、ほぼ例外はありません。

(4) ビルドおよび実行は、「Build Configuration」を使用して行う必要があります。

画像3

「TinyRacing」でこれらの要件を確認できます。

2. Scene と SubScene

「Project Tiny」は純粋なDOTSであるため、「GameObject」は「Entity」に変換する必要があります。DOTSの世界では、「GameObject」や「MonoBehaviour」は使用できません。

現在、「Project Tiny」のシーンは、1つ以上のSubSceneのみ保持しています。「SubScene」はビルド時に自動的に「Entity」に変換されます。

「TinyRacing」では、「Scenes/TinyRacing.scene」のシーンに1つの「SubScene」（DOTS Subscene）のみ保持しています。

3. GameObjectとBehavior

「GameObject変換オーサリングワークフロー」では、「DOTSランタイムデータ」が「GameObject」「MonoBehaviour」から作成されます。標準のBehaviorとアセットの一部には、変換コードが定義されています。「MeshRenderer」「MeshFilter」「Material」「Texture」などです。ただし、ゲームロジックは完全に「Component」と「System」で実装する必要があります。

4. Assembly Definition

「Project Tiny」は純粋なDOTSであるため、ゲームスクリプトを「Assembly Definition」を使用してアセンブリにコンパイルする必要があります。利用する「Assembly Definition」は、「Build Configuration → Root Assembly」にを指定する必要があります。

画像5

「Assembly Definition」は、コードが使用するクラスと型を含む全てのアセンブリを参照する必要があります。「Assembly Definition」のプロパティについては、「Assembly Definitionプロパティ」を参照してください。

「TinyRacing」では、「ルートアセンブリ」は「Scripts/TinyRacing」フォルダ内の「TinyRacing.asmdef」によって定義されます。

 5. Build Configuration

「Build Configuration」は、プロジェクトに含まれるアセットです。

画像4

複数の「Build Configuration」を定義してプロジェクトで保持したり、別の「Build Configuration」から設定を継承したりすることができます。

「TinyRacing」では、様々な「Build Configuration」が「BuildConfigurations」フォルダで定義されています。

6. DOTS .NET サブセット

「Project Tiny」のコードは、.NETのサブセットを使います。標準の.NETの多くは利用できません。利用できるもののリストを作成しました。これは、開発中のため確定されていません。

DOTS .NET サブセットの制限は、次のとおりです。

・ランタイムリフレクションはない（System.Reflectionなど）
・重い機能はない（例：System.Xml）
・非ジェネリックコレクションはない（List <T>は使用できますが、Listは使用できません）
・複雑なジェネリックコレクションの多くが欠落している
　・Unity.Collectionsの一部として、より効率的なコレクションが利用可能（NativeList、NativeSet、NativeHashMap、NativeMultiHashMap）。
・汎用のToString()およびEquals()はない
　・各タイプは、必要に応じてこれらの関数の独自のバージョンを明示的に定義する必要がある。

7. オーサリングとエディタオンリーコード

「GameObject変換オーサリングワークフロー」では、オーサリング時に、「GameObject」「MonoBehaviour」を使用します。これらは、変換システムを使用して「ECS」に変換されます。

独自の「Component」の場合、オーサリングMonoBehaviourおよびランタイムComponentを定義するには、次の3つの方法があります。

◎ [GenerateAuthoringComponent] 属性
「IComponentData」に、[GenerateAuthoringComponent]を付加することで、Componentのフィールドをオーサリングで編集できるMonoBehaviourが自動的に生成されます。

◎ IConvertGameObjectToEntityを実装するMonoBehaviour
このインターフェイスは、MonoBehaviourで呼び出されるConvert()を定義し、提供されたEntityManagerおよびEntityを使用して、必要なECSコンポーネントを作成する必要があります。

◎ GameObjectConversionSystem
これは最も低レベルで最も強力なメカニズムです。このシステムは変換時に実行され、元のUnityシーンデータとECS EntityManagerデータの両方を完全に表示します。

これら全てのアプローチで、実行時に使用されるIComponentDataは、DOTSランタイムビルドの一部としてビルドされるアセンブリで定義する必要があります。

IConvertGameObjectToEntityおよびGameObjectConversionSystemの場合、
MonoBehaviourまたは変換システムコードは、ルートアセンブリによって参照されない別のアセンブリに存在する必要があります。これが当てはまらない場合、ビルド時にコンパイルエラーが発生します。これらのアセンブリ名に「.Authoring」というサフィックスを追加することをお勧めします。

「TinyRacing」では、TinyRacingアセンブリで直接使用される「GenerateAuthoringComponent」と、いくつかのより複雑な変換コードを定義する個別の「TinyRacing.Authoring」アセンブリの組み合わせを確認できます。「カスタムGameObjectConversionSystem」を使用して、実行時に数値を表示するための手焼きのUIとテクスチャを処理します。

8. ランタイムとパッケージ

DOTSには、2つのランタイムが存在します。

◎ classic UnityEngine Playerランタイム
「Megacity」プロジェクトのように、DOTSコンポーネントを使用して「ハイブリッド」モードを有効にした「UnityEngine Playerランタイム」。

◎ new DOTSランタイム
DOTSランタイムに基づくTinyデモのように、現在「Project Tiny」のみが使用している「DOTランタイム」。

「new DOTSランタイム」は、必要なパッケージを組み立てて最終的に完全な製品を形成することによって構築されます。DOTSランタイムで構築された最初の製品は、「com.unity.tiny.all」下にグループ化された複数のパッケージで構成される「Project Tiny」です。

次に、追加のオプション機能がパッケージとしても利用可能です。たとえば、「com.unity.physics」は「DOTSランタイム」で機能しますが、「classic UnityEngine Playerランタイム」でも機能します。

将来的に、Unityのほとんどの新機能は、両方のランタイムをサポートする予定です。

【おまけ】 Assenbly Definitionの設定項目

「Assenbly Definition」の設定項目は、次のとおりです。

画像6

◎ Name
アセンブリ名（ファイル拡張子なし）はプロジェクト全体で一意である必要があります。特に複数のプロジェクトでアセンブリを使用する場合は、逆DNS命名スタイルの使用を検討してください。

【注意】Unityは、「Assembly Definition」に割り当てた名前を名前フィールドのデフォルト値として使用しますが、必要に応じて名前を変更できます。

◎ General

・Allow ‘unsafe’ code : アセンブリ内のスクリプトでC#/unsafeキーワードを使用した場合は、「unsafe」コードを許可するオプションを有効にします。
・Auto Referenced : 全ての定義済みアセンブリがこのプロジェクトアセンブリを参照するかどうかを指定します。
・Override References : 有効時には、このアセンブリが依存するプリコンパイル済みアセンブリを手動で指定します。
・No Engine References : 有効時には、Unityはアセンブリのコンパイル時にUnityEditorまたはUnityEngineへの参照を追加しません。

◎ Define Constraints
アセンブリをコンパイルまたは参照するために定義する「compiler #define directive」を指定します。

◎ Assembly Definition References
他のアセンブリへの参照を指定します。

・Use GUIDs : アセンブリ定義アセットへの参照をシリアル化する方法を指定します。有効時には、アセンブリ定義名ではなく、GUIDとして参照を保存しますGUIDを使用することをお勧めします。

◎ Assembly References
Override References有効時のみ表示されます。
この領域を使用して、このアセンブリが依存するプリコンパイル済みアセンブリへの参照を指定します。

◎ Platforms
アセンブリのプラットフォーム互換性を指定します。

◎ Version Defines
コンパイルに含めるパッケージとモジュールのバージョンを指定します。

【おまけ】 Build Configuration の設定項目

「Build Configuration」（Web(Wasm)）の設定項目は、次のとおりです。

画像7

◎ Dependencies
設定の継承を行う「Build Configuration」を指定します。

◎ General Settings
プロダクト名と会社名を指定します。

◎ Scene List
シーンの一覧を指定します。

◎ Tiny Rendering Settings
解像度などレンダリング関連の設定を行います。

◎ Dots Runtime Root Assembly
利用する「Assembly Definition」を指定します。

◎ Dots Runtime Burst Settings
Burstコンパイラの設定（今回は未使用）を行います。

◎ Screen Orientations
画面回転の設定を行います。

◎ Dots Runtime Build Profile
ビルド種別（今回はWeb(Wasm)）を指定します。

◎ Emscripten Settings
Emscriptenコンパイラの設定を行います。

◎ Suggested Componnets
出力先フォルダを指定します。


この記事が気に入ったらサポートをしてみませんか？