「Unityで3時間でゲームを作成する方法」、「夕方にカウンターストライクを行う」などのマニュアルはいくつありますか？ 低いエントリーしきい値は、間違いなくUnityの主なプラスとマイナスです。 実際、「アセット」を投げ、いくつかの単純な「スクリプト」を追加し、それらを青い電気テープで包むと、どういうわけか機能します。 しかし、プロジェクトが複雑な動作ロジックであるゲームメカニクスで大きくなりすぎた場合、このアプローチの問題は雪だるまのように増加します。 新しいメカニズムの導入には、多くの場所でコードを書き直し、ロジックコンポーネントへのリンクが壊れているため、プレハブを絶えずチェックしてやり直す必要があります。もちろん、これらすべての最適化とテストは必要です。 もちろん、アーキテクチャは最初に考え出すことができますが、実際にはこれは常に達成不可能な目標です-設計ドキュメントは頻繁に変更され、一部は破棄され、まったく新しいものが追加され、古い動作ロジックとは関係ありません。 Unityのコンポーネントは、コードを分離されたブロックに分解するという形での正しい方向への一歩ですが、実装機能では必要な柔軟性、そして最も重要なパフォーマンスを達成することはできません。 開発者は独自のフレームワークとバイクを考案しますが、ほとんどの場合、ECS（エンティティコンポーネントシステム）に焦点を当てます。 ECSは、Unityコンポーネントモデルのアイデアを継続するソリューションの1つですが、現在のコードを大幅に変更することなく、柔軟性を高め、リファクタリングを大幅に簡素化し、新しい機能でアプリケーションをさらに拡張します。

ECSとは

ECSはEntity Component Systemデザインテンプレートであり、Elastic Cloud Storageと混同しないでください:)。 簡単に言えば、つまり、「 エンティティ 」はプロパティを持たないが、「コンポーネント」のリポジトリとして機能するコンテナオブジェクトです。 「 コンポーネント 」は、ゲームオブジェクトまたはイベントのあらゆる種類のプロパティを定義するデータブロックです。 コンテナにグループ化されたこのデータはすべて、特定の実行メソッドを持つ「 システム 」-「純粋」クラスの形式でのみ存在するロジックによって処理されます。 このパターンは「エンジン」に依存せず、さまざまな方法で実装できます。 すべての「エンティティ」、「システム」、および「コンポーネント」はどこかに保存し、何らかの方法で初期化する必要があります。これらはすべて、特定の「エンジン」に対する各ECSソリューションの実装の機能です。

待ってください、と言いますが、Unityではそうです！ 実際、Unityでは、 「 Essence 」はGameObjectであり、 「 Component 」と「 System 」はMonoBehaviourの相続人です。 しかし、これがUnityコンポーネントシステムとECSの主な違いです。ECSのロジックはデータから分離する必要があります 。 これにより、データを壊すことなく、ロジックを非常に柔軟に変更できます（削除/追加も可能）。 もう1つのボーナスは、データが各システムの「ストリーム」によって処理され、「エンジン」での実装に関係なく、MonoBehaviourの場合、「ネイティブ」部分との相互作用が多く、パフォーマンスの一部を使い果たすことです。 Unityの公式ブログでMonoBehaviourの相続人からメソッドを呼び出す内部デバイスの機能について読むことができます： Update（）への10000呼び出し

ECS操作の例

デザイナーからのタスク：「プレイヤーがポイントXに到達したら、プレイヤーを移動させて次のレベルをロードする必要があります」。

タスクを「システム」ごとに1つのサブタスクに分割します。

• UserInputSystem-ユーザー入力。
• MovePlayerSystem-入力に基づいてプレーヤーを移動します。
• CheckPointSystem-プレーヤーがポイントに到達したことを確認します。
• LoadLevelSystem-適切なタイミングでレベルをロードします。

コンポーネントを定義します。

• UserInputEvent-データに関するユーザー入力の存在に関するイベント。 はい、イベントもコンポーネントです！
• プレーヤー - プレーヤーの現在の位置と彼の速度のストレージ。
• CheckPoint-マップ上の相互作用点。
• LoadLevelEvent-新しいレベルをロードする必要性に関するイベント。

そして、これがどのように大まかに動作するかです：

• シーンがロードされ、すべてのシステムが上記のシーケンスで初期化されます。 はい、システムの処理順序は複雑な動きなしで制御できます-これはもう一つの素晴らしいボーナスです。
• Playerエンティティ（ Playerコンポーネントを追加）とコントロールポイントのエンティティ（ CheckPointコンポーネントを追加）が作成されます。
• ここで、処理システムのメインサイクルが開始されます-基本的にMonoBehaviour.Updateメソッドに類似しています。
• UserInputSystemは、標準のUnity-apiを介したユーザー入力を検証し、 UserInputEventコンポーネントと入力データ（存在する場合）を持つ新しいエンティティを作成します。
• MovePlayerSystemは、 UserInputEventコンポーネントを持つエンティティがあるかどうか、およびPlayerコンポーネントを持つエンティティがあるかどうかを確認します。 ユーザー入力がある場合、見つかったすべての「プレーヤー」を（受信したデータであっても）処理し、 UserInputEventコンポーネントを持つエンティティを完全に削除します。 はい、非常に高速に動作し、ガベージコレクターは動作しません-すべてが内部プールに送られ、その後再利用されます。
• CheckPointSystemは、 CheckPointコンポーネントを持つエンティティがあるかどうか、およびPlayerコンポーネントを持つエンティティがあるかどうかを確認します。 それとそれの両方がある場合-サイクルで各プレイヤーとポイント間の距離をチェックします。 「プレーヤー」の1つがトリガーするのに十分近い場合、 LoadLevelEventコンポーネントを使用して新しいエンティティを作成します。
• LoadLevelSystemは、 LoadLevelEventコンポーネントを持つエンティティがあるかどうかを確認し、存在する場合は新しいシーンをロードします。 このようなコンポーネントを持つすべてのエンティティは、この前に削除されます。
• 処理システムのメインサイクルを繰り返します。

UPD： josinSbazin がこのテストタスクの実装を行いました 。

10行の1つの「MonoBehaviour」クラスと比較すると、コードが複雑すぎるように見えますが、最初は次のとおりです。

• 入力を他のロジックから分離できます。 キーボード入力モデルをマウス、コントローラー、タッチスクリーンに変更することができ、残りのコードは壊れません。
• 現在の方法を壊すことなく、プレーヤーの処理動作を新しい方法で拡張できます。 たとえば、1つ以上のシステムを追加し、特定のエンティティのPlayerコンポーネントで速度パラメーターを変更することにより、マップに減速/加速ゾーンを追加できます。
• 設計者が要求したように、1つだけでなく、マップ上に任意の数のコントロールポイントを配置できます。
• 複数のプレーヤーを1つの方法で制御することもできます。 BinaryLandのように、ゲームメカニクスの一部になることもあります。

ECS機能

上記の例に基づいて、Unityコンポーネントモデルに関するECSの主な機能を推測できます。

長所

• 柔軟性とスケーラビリティ（新しいシステムの追加、古いシステムとコンポーネントの削除）。
• メモリの効率的な使用（実装の特性。「MonoBehavior」とは異なり、「純粋な」C＃クラスのインスタンスを好きなように再利用できます）。
• オブジェクトへの簡単なアクセス（特定のコンポーネントを持つエンティティの選択（フィルタリング）は、速度とメモリ割り当てを失うことなくECSコアによって実行されます-これはまさにUnityコンポーネントシステムに欠けているものです）。
• ロジックとデータの明確な分離。
• テストが簡単（テスト環境の再現が簡単）。
• Unityなしでサーバーでロジックを使用する機能（「エンジン」自体に依存しない）。

短所

• より多くのコード
• Unity自体のイベントについては、「MonoBehavior」ラッパーを介して何らかの方法でそれらをECS環境に投入する必要があります。

Unityで長い間働いていて、ECSを使用したことがない多くの人にとって、最初はこのアプローチに慣れるのは難しいでしょう。 しかしすぐに、コンポーネント/システムを「考え」始め、「MonoBehavior」に基づいて強力に接続されたコンポーネントを使用するよりも、すべてがすばやく簡単に収集されます。

Unityの組み込みECSソリューション

Unityの開発者でさえ、アプリケーションシステムのパフォーマンスを改善するためにコンポーネントシステムの何かを変更する時だと気づきました。 約1年前、独自のECSおよびC＃ジョブシステムの開発が進行中であることが発表されました。 そして今、2018.1バージョンでは、 プレビューステータスであっても 、将来的にどうなるかをすでに大まかに想像できます 。

標準のUnity ECSでは、まだ明確なものはありません。 開発者は、限られた範囲のタスクにのみ適しているとは書いていませんが、他のECSソリューションからコピーした結果として質問が発生した場合、「ECSを誤って使用している」というスタイルで答えます。 つまり 実際、これは「多目的」ソリューションではなく、かなり奇妙です。 リリースはありませんでしたが、数回変更される可能性があり、参照型（たとえば、文字列）の転送に問題があるため、現在の状態の通常のECSで何か大きなことをすることはお勧めできません。

Unityの代替ECSソリューション

ECSパターンは昨日発明されたものではなく、 https：//github.comでUnityのバージョンを含むその実装の多くを見つけることができます。 比較的新鮮で更新された：

• エンティタス
• レオックス
• BrokenBricksECS
• Svelto.ECS

最初の2つのオプションのみを扱いました。

Entitasは最も人気があり、大規模なコミュニティソリューションでサポートされています（最初のソリューションであるため）。 それは十分に高速であり、ECSオブジェクトを視覚化するUnityエディターとの統合があり、カスタムコンポーネントの上に便利なAPIでラッパーを作成するためのコード生成があります。 過去1年間、コードジェネレーターは独立したプロジェクトに分かれて有料になったため、これはかなりマイナスです。 もう1つのかなり重要なマイナス点（特にモバイルプラットフォームの場合）は、各エンティティのすべての可能なコンポーネントオプションにメモリが割り当てられることです。これはあまり良くありません。 しかし、一般的には、適切で、十分に文書化されており、実際のプロジェクトですぐに使用できます。 サイズ：0.5mb + 3mbエディターのサポート。

Entitasを使用した例はたくさんありますが、プロジェクトは長い間存在し、 推進されてきました。 ソースを含む例から、 Match 1を確認できます 。

Entitasの全体的なパフォーマンスは、次のように推定されます。

LeoECSをよく知っているのは、新しいゲームをやっているからです。 コンパクトで、外部アセンブリの形式で閉じたコードを含まず、Unity 2017からのアセンブリ定義をサポートし、メモリ使用量がより最適化され、GCがほぼゼロ（プライマリプールセットのみ）、依存関係なし、オプションのインラインサポートを備えたC＃v3.5 FW4.6。 すばらしい点：属性マークアップによるDI、ECSオブジェクトを視覚化するUnityエディターとの統合、uGUIイベントの既製のバインディング。 サイズ：18kb + 16kbエディターサポート。

ソースの既製の例として、古典的なゲーム「Snake」を見ることができます 。

EntitasとLeoECSの速度の比較 ：結果は非常に近く、両方向にわずかなマージンがあります。

おわりに

私はこの問題の専門家ではありません（最近、UnityをECSと組み合わせて使用​​し始めたばかりです）。そのため、主にそれぞれのスクリプトを使用してアセットからUnityゲームを「収集」する人と観察と考えを共有することにしました。 はい、動作します。 そんな感じでした。 しかし、サポートやさらなる開発を必要とせずにプロトタイプや1回限りのゲームを作成していない場合は、10回考えてみてください。それを理解して、すべてやり直す必要があります。

ECSを使用して、リファクタリングプロセスも楽しんでいます:)新しい機能がゲームに簡単に追加され、古い機能が変更されます-すべてを十分にプレイした後、新しい猛烈なメカニックを追加するか、古いものを削除することを決めたデザイナーとの苦痛と衝突なしに、すべてが機能します。