エンティティ-コンポーネント-システム設計パターン-実装とサンプルゲーム

この記事では、Entity-Component-System（ ECS ）設計パターンについて説明します。 インターネットでこのトピックに関する多くの情報を見つけることができますので、私は説明に深く入りませんが、私自身の実装についてもっと話します。

パート1：C ++でのEntity-Component-Systemテンプレートの実装

やり直しましょう。 ECS実装の完全なソースコードは、 githubリポジトリにあります。

主にゲームで使用されるEntity-Component-Systemは、一般的なソフトウェアアーキテクチャの設計において非常に高い柔軟性を提供する設計パターンです^[1] 。 Unity、Epic、Crytekなどの大企業は、このテンプレートをフレームワークで使用して、開発者が独自のソフトウェアを開発できる非常に機能豊富なツールを提供しています。 これらの投稿^[2,3,4,5]で、このトピックに関するより広範な議論を読むことができます。

これらの記事を研究すると、それらすべてに共通の目標があることに気付くでしょう：エンティティ（エンティティ）、コンポーネント（コンポーネント）、システム（システム）間のさまざまな問題とタスクの分散。 これらは、このテンプレートの3つの基本概念であり、かなり自由に接続されています。 エンティティは通常、一意の識別子を作成し、単一の要素の存在に関する情報を環境に提供し、多くのコンポーネントを組み合わせた一種のルートオブジェクトとして機能するために使用されます。 コンポーネントは、複雑なロジックを持たないコンテナオブジェクトにすぎません。 理想的には、それらはプレーンオールドデータオブジェクト（POD）を持つオブジェクトです。 各タイプのコンポーネントをエンティティにアタッチして、プロパティのようなものを与えることができます。 「Health-Component」をエンティティにアタッチすると、エンティティが致命的になり、メモリ内の通常の整数値または小数値であるhealthが与えられます。

私が出会ったほとんどの記事は、エンティティとコンポーネントの使用に関して互いに一貫していますが、システムに関する意見は異なります。 一部の人々は、コンポーネントのみがシステムに知られていると信じています。 さらに、各タイプのコンポーネントには独自のシステムが必要であると言う人もいます。たとえば、「Collision-Components」の場合は「Collision-System」、「Health-Components」-「Health-System」などです。 このアプローチは非常に厳密であり、さまざまなコンポーネントの相互作用を考慮していません。 それほど厳密ではないアプローチは、異なるシステムが認識すべきコンポーネントを処理することです。 たとえば、物理システムは衝突コンポーネントとリジッドボディコンポーネントについて知っている必要があります。どちらも物理のシミュレーションに必要な情報を含んでいる可能性が高いためです。 私の謙虚な意見では、 システムは「閉じられた環境」です。 つまり、エンティティまたはコンポーネントのいずれも所有していません。 独立したディスパッチャオブジェクトを介してそれらにアクセスし、エンティティとコンポーネントのライフサイクルを順番に制御します。

これは興味深い質問を提起します：エンティティ、コンポーネント、およびシステムは、互いに多少独立している場合、どのように情報を交換しますか？ 答えは異なる場合があり、実装によって異なります。 私の実装では、答えはイベントソース^[6]です。 イベントは「イベントマネージャー」を通じて配信され、イベントに興味がある人はマネージャーが送信した情報を受け取ることができます。 エンティティ、システム、またはコンポーネントでさえ、「位置が変わった」または「プレイヤーが死亡した」など、報告する必要がある重要な状態の変化がある場合、「イベントディスパッチャー」に情報を送信できます。 彼はイベントに合格し、このイベントにサブスクライブしているすべての人がそれについて知っています。 したがって、すべてを相互に接続できます。

導入は私が計画したよりも長かったようです。 ちなみに、C ++ 11で記述されたコードの研究を掘り下げる前に、私のアーキテクチャの基本的な特徴の概要を説明します。

• メモリ効率 -エンティティ、コンポーネント、システム、およびイベントのオブジェクトをすばやく作成および削除するために、標準の動的メモリ管理に頼ることはできません。 もちろん、この場合の解決策は、独自のメモリアロケータです。
• ロギング -何が起こっているかを追跡するために、ロギングにlog4cplus ^[7]を使用しました。
• スケーラビリティ -システムメモリを除き、上限を指定せずに新しいタイプのエンティティ、コンポーネント、システム、およびイベントを簡単に実装できます。
• 柔軟性 -エンティティ、コンポーネント、およびシステム間に依存関係はありません（もちろん、エンティティとコンポーネントには一種の依存関係がありますが、相互のポインタのロジックは含まれていません）
• オブジェクトの単純な検索/それらへのアクセス -特定のタイプのすべてのコンポーネントを反復するためのEntityIdまたはコンポーネントのイテレーターを介したエンティティオブジェクトとそのコンポーネントの単純な取得
• 実行制御 -システムには優先順位があり、相互に依存できるため、実行からトポロジカルな順序を確立できます
• 使いやすさ -ライブラリは他のソフトウェアで簡単に使用でき、インクルードするだけで十分です。

以下の画像は、Entity-Component-System実装の一般的なアーキテクチャを示しています。


図01：ECSアーキテクチャ図（ ECS.dll ）。

ご覧のとおり、この図には4つの異なる色の領域があります。 各エリアは、モジュール化されたアーキテクチャを表しています。 一番下-実際、一番上の図では、上下が逆になっています-メモリ管理とジャーナリングがあります（黄色の領域）。 これらの第1レベルのモジュールは、非常に低いレベルのタスクで機能します。 これらは、Entity-Component-System（青色の領域）およびイベントソース（赤色の領域）で第2レベルのモジュールを使用します。 これらのモジュールは、主にオブジェクト管理タスクを処理します。 それらの上には、第3レベルのモジュールECS_Engine（緑色の領域）があります。 最上位エンジンのこのグローバルオブジェクトは、第2レベルのすべてのモジュールを制御し、初期化と破棄に関与します。 さて、これは簡潔で非常に抽象的なレビューでしたが、今度はアーキテクチャをさらに詳しく見てみましょう。

メモリマネージャー

メモリマネージャから始めましょう。 その実装は、 gamedev.netで見つけた記事^[8]に基づいています。 この考え方は、動的メモリの割り当てと解放を最小限に抑えることです。 したがって、 mallocを使用してアプリケーションを起動する場合にのみ、大きなメモリ領域が割り当てられます。 このメモリは、1つ以上のアロケーターによって制御されます。 ディスペンサーには多くのタイプ^[9] （線形、スタック、フリーリスト）があり、それぞれに長所と短所があります（ここでは考慮しません）。 ただし、内部で異なる動作をするという事実にもかかわらず、すべてに共通のオープンインターフェイスがあります。

class Allocator { public: virtual void* allocate(size_t size) = 0; virtual void free(void* p) = 0; }; 

上記のコードスニペットは不完全ですが、各ディストリビュータが提供する必要がある2つの主な一般的な方法を示しています。

1. allocate-特定のバイト数を割り当て、この領域のメモリアドレスを返します
2. free-指定されたアドレスで以前に割り当てられたメモリ領域を解放します。

そうは言っても、たとえば次のように、いくつかのディストリビューターをチェーンにまとめるなど、興味深いことを行うことができます。


図02：アロケーターによって制御されるメモリ。

ご覧のとおり、1つのアロケーターはそのメモリー領域を制御でき、別の（親）アロケーターから制御します。次に、別の（親）アロケーターは別のアロケーターからメモリを取得できます。 このようにして、さまざまなメモリ管理戦略を構築できます。

ECSを実装するために、1 GBのシステムメモリの初期割り当て領域を取得するルートスタックディスペンサーを作成しました。 第2レベルのモジュールは、ルートアロケーターから必要な量のメモリを割り当て、アプリケーションの完了後にのみ解放します。


図03：可能なグローバルメモリ割り当て。

図03は、第2レベルのモジュール間でメモリを割り当てる方法を示しています。 「Global-Memory-User A」はエンティティマネージャ、 「Global-Memory-User B」はコンポーネントマネージャ、 「Global-Memory-User C」はマネージャです。システム。

ロギング

log4cplus ^[7]を使用しただけなので、ログについてはあまり話しません。これはすべての作業を行います。 Log4cplus :: Loggerオブジェクトと、「LogInfo（）」、「LogWarning（）」などの単純なロギング呼び出しを渡すラッパーメソッドを定義する基本クラスLoggerを設定するだけでした。

エンティティマネージャー、IEntity、エンティティ<T>

それでは、アーキテクチャの「肉」についてお話しましょう。図01の青色の領域です。すべてのディスパッチオブジェクトとそれらに対応するクラスの構造が似ていることに気付くでしょう。 たとえば、 EntityManager 、 IEntity、およびEntity <T>クラスを見てください。 EntityMangerクラスは、実行時にすべてのエンティティオブジェクトを管理する必要があります。 彼のタスクには、既存のエンティティオブジェクトの作成、削除、アクセスが含まれます。 IEntityは、オブジェクト識別子や（静的）型の識別子など、エンティティオブジェクトの最も単純な特性を提供するインターフェイスクラスです。 プログラムの初期化後に変更されないため、静的です。 このクラス識別子は、アプリケーションが起動するたびに一定であり、ソースコードが変更された場合にのみ変更できます。

 class IEntity { //  ! EntityId m_Id; public: IEntity(); virtual ~IEntity(); virtual const EntityTypeId GetStaticEntityTypeID() const = 0; inline const EntityId GetEntityID() const { return this->m_Id; } }; 

タイプ識別子は、特定のエンティティクラスごとに異なる整数値です。 これにより、実行時にIEntityオブジェクトのタイプを確認できます。 リストの最後にありますが、重要ではありませんが、 エンティティ <T>テンプレートクラスです。

 template<class T> class Entity : public IEntity { //  ! void operator delete(void*) = delete; void operator delete[](void*) = delete; public: static const EntityTypeId STATIC_ENTITY_TYPE_ID; Entity() {} virtual ~Entity() {} virtual const EntityTypeId GetStaticEntityTypeID() const override { return STATIC_ENTITY_TYPE_ID; } }; //      template const EntityTypeId Entity::STATIC_ENTITY_TYPE_ID = util::Internal::FamilyTypeID::Get(); 

このクラスの主な目的は、特定のエンティティクラスのタイプの一意の識別子を初期化することです。 ここでは、2つの事実を利用しました。まず、静的変数の定数^[10]の初期化。 第二に、テンプレートクラスの動作の性質による。 Entity <T>テンプレートクラスの各バージョンには、独自の静的変数STATIC_ENTITY_TYPE_IDがあります。 これは、すべての動的初期化が完了する前に初期化されることが保証されています。 フラグメント「 util :: Internal :: FamilyTypeID :: Get（） 」は、タイプカウンターメカニズムのようなものを実装するために使用されます。 別のTで呼び出されるたびにカウンターをインクリメントしますが、1つのTで再度呼び出されると常に同じ値を返します。 このテンプレートに独自の名前があるかどうかはわかりませんが、非常に便利です。 この時点で、deleteおよびdelete []演算子も削除しました。 したがって、誤ってそれらを呼び出すことができなくなりました。 さらに、これのおかげで（コンパイラが十分に賢い場合）、エンティティオブジェクトにnewまたはnew []演算子を使用しようとすると、反対の演算子はもう存在しないため、警告が発行されます。 EntityManagerクラスがすべてのタスクを処理するため、これらの演算子は使用しないでください。 それで、私たちがすでに学んだことを要約します。 ディスパッチャクラスは、オブジェクトの作成、削除、アクセスなどの最も単純な機能を提供します。 インターフェイスクラスは、最もルートの基本クラスとして使用され、一意のオブジェクト識別子とタイプ識別子を提供します。 テンプレートクラスは、タイプ識別子の正しい初期化を保証し、削除/削除[]演算子を排除します。 ディスパッチャクラスの同じテンプレート、インターフェイス、およびテンプレートが、コンポーネント、システム、およびイベントに使用されます。 これらのグループの唯一の重要な違いは、ディスパッチャクラスがオブジェクトを保存してアクセスする方法です。

最初にEntityManagerクラスを見てみましょう。 図04は、アイテムを保存するための一般的な構造を示しています。


図04：EntityManagerクラスとそのオブジェクトのストレージの抽象図。

新しいエンティティオブジェクトを作成するときは、 EntityManager :: CreateEntity < T >メソッド（引数...）を使用する必要があります。 この一般的なメソッドは最初に、作成される特定のエンティティのタイプであるテンプレートパラメーターを受け取ります。 次に、このメソッドは、コンストラクターTに渡されるオプションのパラメーター（パラメーターがない場合があります）を受け取ります。 これらのパラメーターの転送は、可変数の引数を持つテンプレートを介して実行されます^[11] 。 作成中に、次のアクションが内部で発生します。

1. タイプTのエンティティオブジェクトのObjectPool ^[12]が判明します。 このプールが存在しない場合、新しいプールが作成されます
2. メモリはこのプールから割り当てられます。 オブジェクトTを保存するのに必要なだけ正確に
3. ディスパッチャーからTコンストラクターを呼び出す前に、新しいEntityIdが取得されます。 以前にメモリが割り当てられたこの識別子は、ルックアップテーブルに保存されます。 このようにして、目的の識別子を持つエンティティインスタンスを検索できます
4. 次に、入力として渡された引数を使用してC ++ new演算子^[13]が呼び出され、 Tの新しいインスタンスが作成されます
5. 最後に、メソッドはエンティティの識別子を返します。

エンティティオブジェクトの新しいインスタンスを作成したら、一意のオブジェクト識別子（ EntityId ）およびEntityManager :: GetEntity（EntityId id）を使用してアクセスできます。 エンティティオブジェクトのインスタンスを破棄するには、 EntityManager :: DestroyEntity（EntityId id）メソッドを呼び出します。

ComponentManagerクラスは同じように機能し、さらに別の拡張機能があります。 あらゆる種類のオブジェクトを格納するためのオブジェクトのプールに加えて、コンポーネントを所有するエンティティオブジェクトにコンポーネントをバインドするための追加のメカニズムを提供する必要があります。 この制限は、検索の第2段階につながります。最初に、指定されたEntityIdを持つエンティティが存在するかどうかを確認し、存在する場合は、コンポーネントのリストを検索して特定のタイプのコンポーネントがこのエンティティにアタッチされているかどうかを確認します


図05：Component-Managerオブジェクトのストレージ図。

ComponentManager :: CreateComponent <T>メソッド（EntityId id、引数...）を使用すると、特定のコンポーネントをエンティティに追加できます。 ComponentManager :: GetComponent <T>（EntityId id）を使用して、エンティティのコンポーネントにアクセスできます。Tは、アクセスするコンポーネントのタイプを決定します。 コンポーネントが欠落している場合、 nullptrが返されます。 エンティティからコンポーネントを削除するには、 ComponentManager :: RemoveComponent <T>（EntityId id）メソッドを使用する必要があります。 しかし、待って、他に何かがあります。 コンポーネントにアクセスする別の方法は、 ComponentIterator <T>を使用することです。 したがって、特定のタイプTのすべての既存のコンポーネントに対して反復できます。これは、たとえば、物理システムなどのシステムがすべての固体のコンポーネントに重力を適用する必要がある場合に便利です。

SystemManagerクラスには、システムを保存してアクセスするための特別な追加機能はありません。 システムを保存するには、タイプ識別子をキーとして単純なメモリ割り当てが使用されます。

EventManagerクラスは、メモリ領域を管理する線形アロケーターを使用します。 このメモリはイベントバッファとして使用されます。 イベントはこのバッファに保存され、後で送信されます。 イベントを送信すると、バッファがクリアされ、新しいイベントをそこに保存できます。 これは少なくともフレームごとに1回発生します。


図06：改訂されたECSアーキテクチャ図

うまくいけば、私のECSフレームワークがどのように機能するかについてのアイデアが得られました。 そうでない場合は、心配しないで、図06を見て、簡単に繰り返します。 ご覧のとおり、 EntityIdは非常に重要です。EntityIdを使用して、エンティティオブジェクトとそのすべてのコンポーネントの特定のインスタンスにアクセスするためです。 すべてのコンポーネントは所有者を知っています。つまり、コンポーネントオブジェクトを持っているので、このコンポーネントの指定された所有者識別子でEntityManagerクラスを照会することで、エンティティを簡単に取得できます。 エンティティを渡すために、ポインタを直接渡すことはありませんが、 EntityIdと組み合わせてイベントを使用します。 EntityDiedなどの特定のイベントを作成できます。このイベント（単純なデータ構造を持つオブジェクトである必要があります）には、タイプEntityIdの要素があります。 エンティティ、コンポーネント、またはシステムである可能性があるすべてのイベントレシーバー（ IEventListener ）に通知するために、 EventManager :: SendEvent <EntityDied>（entityId）を使用します。 一方、イベントレシーバーは、渡されたEntityIdを使用して、EntityManagerクラスでエンティティオブジェクトを取得したり、ComponentManagerクラスでこのエンティティの特定のコンポーネントを取得したりできます。 この循環パスの理由は簡単です。アプリケーションの実行中はいつでも、何らかのロジックを使用してエンティティまたはそのコンポーネントの1つを削除できます。 追加のクリーニング手順でコードを乱雑にしないため、 EntityIdを使用します 。 ディスパッチャがこのEntityIdに対してnullptrを返す場合、エンティティまたはコンポーネントがもう存在しないことがわかります。 ちなみに、赤い四角は図01の同じ部分に対応しており、ECSの境界を示しています。

エンジンオブジェクト

物事をもう少し便利にするために、エンジンオブジェクトを作成しました。 エンジンオブジェクトは、クライアントソフトウェアの簡単な統合と使用を提供します。 クライアント側では、ヘッダーファイル「ECS / ECS.h」を追加して、 ECS :: Initialize（）メソッドを呼び出します。 これで、エンジンの静的グローバルオブジェクトが初期化され（ ECS :: ECS_Engine ）、クライアント側で使用してディスパッチャークラスにアクセスできます。 さらに、メッセージを送信するためのSendEvent <T>メソッドと、すべてのイベントを自動的に送信し、すべてのシステムを更新するUpdateメソッドを提供します。 ECS :: Terminate（）は、メインプログラムを終了する前に呼び出す必要があります。 これにより、受信したすべてのリソースが解放されます。 以下のコードスニペットは、グローバルエンジンオブジェクトの最も簡単な使用方法を示しています。

 #include <ECS/ECS.h> int main(int argc,char* argv[]) { //    'ECS_Engine' ECS::Initialize(); const float DELTA_TIME_STEP = 1.0f / 60.0f; // 60  bool bQuit = false; //      while(bQuit == false) { //   ,     , //      ... ECS::ECS_Engine->(DELTA_TIME_STEP); /* ECS::ECS_Engine->GetEntityManager()->...; ECS::ECS_Engine->GetComponentManager()->...; ECS::ECS_Engine->GetSystemManager()->...; ECS::ECS_Engine->SendEvent<T>(...); */ //   ... } //    'ECS_Engine' ECS::Terminate(); return 0; } 

おわりに

この記事のこの部分で説明する「エンティティコンポーネントシステム」アーキテクチャは完全に機能し、すぐに使用できます。 しかし、いつものように、常に改善のための考えがあります。 ここに私の頭に浮かんだアイデアのほんの一部です：

• アーキテクチャをスレッドセーフにする
• トポロジーの順序を考慮して、各システムまたはシステムのグループをスレッドで実行します。
• イベントソーシングとメモリ管理をリファクタリングして、モジュールとして使用します。
• 連載
• プロファイリング
• ...

ECSの動作を確認できるように、デモを準備しました。


BountyHunterデモはECSを広範囲に使用し、このテンプレートの威力を実証します。 投稿の後半では、彼についてお話します。

参照資料

^[1] https://en.wikipedia.org/wiki/Entity-component-system

^[2] http://gameprogrammingpatterns.com/component.html

^[3] https://www.gamedev.net/articles/programming/general-and-gameplay-programming/understanding-component-entity-systems-r3013/

^[4] https://github.com/junkdog/artemis-odb/wiki/Introduction-to-Entity-Systems

^[5] http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf

^[6] https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

^[7] https://sourceforge.net/p/log4cplus/wiki/Home/

^[8] https://www.gamedev.net/articles/programming/general-and-gameplay-programming/c-custom-memory-allocation-r3010/

^[9] https://github.com/mtrebi/memory-allocatorshttps://www.gamedev.net/articles/programming/general-and-gameplay-programming/c-custom-memory-allocation-r3010/

^[10] http://en.cppreference.com/w/cpp/language/constant_initialization

^[11] https://en.wikipedia.org/wiki/Variadic_template

^[12] http://gameprogrammingpatterns.com/object-pool.html

^[13] http://en.cppreference.com/w/cpp/language/new

パート2：BountyHunterゲーム

次に、実際にアーキテクチャを使用してゲームを作成する方法を示します。 私のゲームはそれほど複雑に見えませんが、 UnityやUnrealなどの大きくて複雑なゲームエンジンの代わりに、私の実装を使用して独自のゲームを作成することにした場合は、私の作者に言及できます。 ECSの機能を実証するには、このようなゲームで十分でした。 その規則を理解していない場合は、次の図が役立ちます。


図01：ゲームBountyHunterの目的とルール。 目標：各プレイヤーは、できるだけ早く自分の物資を補充しようとします。 ルール：1.ゲームには時間制限があります。 時間が経過すると、ゲームは終了します。 2.獲物に関して、コレクターはそれを拾います。 3.ピッカーは限られた量の略奪品を運ぶことができます。 制限に達すると、コレクターは獲物を収集できなくなり、獲物に触れると破壊されます。 4.コレクターが彼または敵の補給品に触れると、収集されたすべての獲物が補給品に投棄され、コレクターは再び獲物を収集できます。 5.コレクターの衝突で、彼らは破壊され、しばらくして、彼らは供給の時点で生まれ変わります。 収集された生産は失われます。 6.獲物は世界の中央部のランダムな地点に現れ、その生涯の間、または収集されるまで存在します。 7.コレクターが世界の境界線を越えると、画面の反対側から表示されます。

左の画像は、ビデオで見たゲームのより抽象的な概要であるため、見慣れたものに見えます。 ルールは十分に明確であり、それ自体が語っています。 ご覧のとおり、ゲームの世界にはさまざまな種類のエンティティが存在します。 あなたはおそらく彼らが実際に何で構成されているのか疑問に思っていますか？ もちろん、コンポーネントの。 一部のタイプのコンポーネントはすべてのエンティティに共通ですが、他のタイプは他のエンティティに固有です。 下の写真を見てください。


図02：エンティティとそのコンポーネント。

この図を見ると、エンティティとそのコンポーネントの関係が簡単にわかります（図にすべてが表示されているわけではありません！）。 すべてのゲームエンティティにはTransform-Componentがあります 。 ゲームエンティティは世界のどこかに配置する必要があるため、エンティティの位置、回転、およびスケールを記述する変換があります。 これは、エンティティに接続されている唯一のコンポーネントである場合があります。 たとえば、カメラオブジェクトはより多くのコンポーネントを必要としますが、 Material-Componentは必要ありません。これは、プレーヤーには表示されないためです（ポストエフェクトを使用する場合は当てはまらない可能性があります）。 一方、エンティティオブジェクトBounty （プロダクション）およびCollector （コレクター）は表示される必要があるため、表示するにはMaterial-Componentが必要です。 また、ゲームの他のオブジェクトと衝突する可能性があるため、物理的な形状を記述する衝突コンポーネントがそれらにアタッチされます。 別のコンポーネントがBountyエンティティに接続されます-Lifetime-Component 。 このコンポーネントは、 バウンティオブジェクトの残りの寿命を決定し、その寿命が終了すると、生産が破壊されます。

それでは、次は何ですか？ 独自のコンポーネントセットを使用してこれらのさまざまなエンティティをすべて作成したので、ゲーム自体は完了しませんでした。 また、それぞれの管理方法を知っている人も必要です。 もちろん、私はシステムについて話している。 システムは素晴らしいもので、ゲームロジック全体を小さな要素に分離するために使用できます。 各要素は、ゲームの独自の側面で機能します。 プレイヤーによって入力されたすべてのデータを処理する入力システムを持っている場合もあれば、持っている場合もあります。 Render-System 。すべての形状と色を画面に転送します。 ゲームの死んだオブジェクトの復活のための復活システム 。 さて、あなたはアイデアを得ると思います。 以下の図は、 BountyHunterのすべての特定のエンティティタイプ、コンポーネント、およびシステムの完全なクラス図を示しています。


図03：ECS BountyHunterクラス図（画像をクリックして拡大）。

エンティティ、コンポーネント、およびシステム（ECS）がありますが、イベントがありません！ システムとエンティティがデータを交換できるように、38個のイベントのコレクションを作成しました。

  GameInitializedEvent GameRestartedEvent GameStartedEvent 
 GamePausedEvent GameResumedEvent GameoverEvent GameQuitEvent 
 PauseGameEvent ResumeGameEvent RestartGameEvent QuitGameEvent 
 LeftButtonDownEvent LeftButtonUpEvent LeftButtonPressedEvent 
 RightButtonDownEvent RightButtonUpEvent RightButtonPressedEvent
 KeyDownEvent KeyUpEvent KeyPressedEvent ToggleFullscreenEvent
 EnterFullscreenModeEvent StashFull EnterWindowModeEvent 
 GameObjectCreated GameObjectDestroyed PlayerLeft GameObjectSpawned
 GameObjectKilled CameraCreated、CameraDestroyed ToggleDebugDrawEvent
 WindowMinimizedEvent WindowRestoredEvent WindowResizedEvent 
 PlayerJoined CollisionBeginEvent CollisionEndEvent 

そして、まだBountyHunterを実装するために必要なことがたくさんあります。

• 一般的なアプリケーションフレームワーク -プレーヤーの入力を受け取り、メインアプリケーションウィンドウを設定するためのSDL2 。
• グラフィックス -このアプリケーションウィンドウにレンダリングできるように、独自のOpenGLレンダラーを使用しました。
• math-線形代数にはglmを使用しました。
• 衝突認識 -彼女のために私はbox2d物理学を使用しました 。
• ステートマシン -単純なAIおよびゲームの状態に使用されます。

もちろん、これらすべてのメカニズムを検討するつもりはありません。それらは私自身の記事に値するので、後で書くかもしれません。しかし、まだそれらについて知りたい場合は、私はあなたを煩わせず、このリンクを提供します。私が言及したすべての特性を研究したので、これはあなた自身のゲームエンジンにとって良いスタートであると決めることができます。プロトタイプを完成させたかったからといって、実際には実装していない項目がリストにいくつかあります。

• エンティティ、コンポーネント、システムなどを管理するためのエディター
• ゲームの保存 -エンティティとそのコンポーネントをORMライブラリ（たとえばcodesynthesis）を使用してデータベースに保存します
• リプレイの再生 -実行時にイベントを記録し、後で再生します
• GUI — GUI- (, librocket )
• — (, , ..)
• —

あなたがどれだけクールかを証明できるように、これらのポイントをタスクとして残しておきます。

また、ECSの使用方法を示すコードを示す必要があります。バウンティのゲームエンティティを覚えていますか？獲物は、世界の中心にランダムに作成された小さな黄色、大きな赤、中間の正方形です。以下は、バウンティエンティティクラス定義コードのスニペットです。

 // Bounty.h class Bounty : public GameObject<Bounty> { private: //   TransformComponent* m_ThisTransform; RigidbodyComponent* m_ThisRigidbody; CollisionComponent2D* m_ThisCollision; MaterialComponent* m_ThisMaterial; LifetimeComponent* m_ThisLifetime; //   bounty float m_Value; public: Bounty(GameObjectId spawnId); virtual ~Bounty(); virtual void OnEnable() override; virtual void OnDisable() override; inline float GetBounty() const { return this->m_Value; } //  OnEnable,      void ShuffleBounty(); }; 

コードは非常にシンプルで簡単です。 Iから得られた新たなゲームエンティティ作成ゲームオブジェクト< T >（由来するECSエンティティ:: < T >）クラス自体（にバウンティとして）T。 ECSはこの特定のエンティティタイプを認識し、（静的）タイプの一意の識別子が作成されます。また、便利なメソッドAddComponent < U >、GetComponent < U >、RemoveComponent < U >へのアクセスも取得します。すぐに表示するコンポーネントに加えて、もう1つのプロパティ、生産の価値があります。BountyComponentのように、このプロパティを個別のコンポーネントに分離しなかった理由が正確ではないため、正確には覚えていません。代わりに、戦利品プロパティをバウンティクラスのメンバーにし、頭に灰を振りかけました。しかし、実際には、このテンプレートの非常に高い柔軟性しか示していませんよね？より正確には、そのコンポーネント...

  // Bounty.cpp Bounty::Bounty(GameObjectId spawnId) { Shape shape = ShapeGenerator::CreateShape<QuadShape>(); AddComponent<ShapeComponent>(shape); AddComponent<RespawnComponent>(BOUNTY_RESPAWNTIME, spawnId, true); //    this->m_ThisTransform = GetComponent<TransformComponent>(); this->m_ThisMaterial = AddComponent<MaterialComponent>(MaterialGenerator::CreateMaterial<defaultmaterial>()); this->m_ThisRigidbody = AddComponent<RigidbodyComponent>(0.0f, 0.0f, 0.0f, 0.0f, 0.0001f); this->m_ThisCollision = AddComponent<CollisionComponent2d>(shape, this->m_ThisTransform->AsTransform()->GetScale(), CollisionCategory::Bounty_Category, CollisionMask::Bounty_Collision); this->m_ThisLifetime = AddComponent<LifetimeComponent>(BOUNTY_MIN_LIFETIME, BOUNTY_MAX_LIFETIME); } //   ... 

コンストラクターを使用して、Bountyエンティティーに必要なすべてのコンポーネントをアタッチしました。このアプローチはオブジェクトの調達を作成し、柔軟性がないことに注意してください。つまり、常に同じコンポーネントがアタッチされたバウンティオブジェクトを取得します。これは私のゲームにとって十分な解決策ですが、より複雑なものにとっては間違いであることが判明する場合があります。この場合、変更可能なエンティティオブジェクトを作成する「ファクトリー」テンプレートを実装する必要があります。

上記のコードからわかるように、かなりの数のコンポーネントがBountyエンティティにアタッチされています。我々は持っているShapeComponentとMaterialComponentを視覚的に表示するため。RigidbodyComponentおよびCollisionComponent2D物理的挙動と衝突に対する反応。RespawnComponent。これにより、Bountyが死後に生まれ変わる機会を得ることができます。最後になりましたが、重要なことは、エンティティの存在を特定の期間に結び付けるLifetimeComponentです。TransformComponentは、GameObject < T >から取得したエンティティに自動的にバインドされます。以上です。ゲームに新しいエンティティを追加しました。

ここで、これらすべてのコンポーネントの使用方法を学びたい場合があります。 2つの例を示します。最初はRigidbodyComponentです。このコンポーネントには、摩擦、密度、線形減衰などの物理的特性に関する情報が含まれています。さらに、box2d物理をゲームに埋め込むために使用されるアダプタークラスとして使用されます。RigidbodyComponentは、物理的にシミュレートされたボディ（box2dが所有）の変換とエンティティのTransformComponent（ゲームが所有）の同期に使用されるため、非常に重要です。この同期プロセスはPhysicsSystemによって実行されます。

 // PhysicsEngine.h class PhysicsSystem : public ECS::System<PhysicsSystem>, public b2ContactListener { public: PhysicsSystem(); virtual ~PhysicsSystem(); virtual void PreUpdate(float dt) override; virtual void Update(float dt) override; virtual void PostUpdate(float dt) override; //      box2d     virtual void BeginContact(b2Contact* contact) override; virtual void EndContact(b2Contact* contact) override; }; // class PhysicsSystem 

 // PhysicsEngine.cpp void PhysicsSystem::PreUpdate(float dt) { //       TransformComponent for (auto RB = ECS::ECS_Engine->GetComponentManager()->begin<RigidbodyComponent>(); RB != ECS::ECS_Engine->GetComponentManager()->end<RigidbodyComponent>(); ++RB) { if ((RB->m_Box2DBody->IsAwake() == true) && (RB->m_Box2DBody->IsActive() == true)) { TransformComponent* TFC = ECS::ECS_Engine->GetComponentManager()->GetComponent<TransformComponent>(RB->GetOwner()); const b2Vec2& pos = RB->m_Box2DBody->GetPosition(); const float rot = RB->m_Box2DBody->GetAngle(); TFC->SetTransform(glm::translate(glm::mat4(1.0f), Position(pos.x, pos.y, 0.0f)) * glm::yawPitchRoll(0.0f, 0.0f, rot) * glm::scale(TFC->AsTransform()->GetScale())); } } } //   ... 

上記の実装から、3つの異なる更新関数に気付くことができます。システムを更新する場合、すべてのシステムのすべてのPreUpdateメソッドが最初に呼び出され、次にUpdateが呼び出され、その後PostUpdateメソッドが呼び出されます。PhysicsSystemはシステムに関連するすべてのTransformComponentの前に呼び出されるため、上記のコードは変換の同期を提供します。ここで、ComponentIteratorの動作も確認できます。むしろそれがあるかどうかを世界に各エンティティを要求するよりも、RigidbodyComponent、我々が求めるComponentManagerを私達提供ComponentIteratorのタイプRigidbodyComponentを。RigidbodyComponentを受け取ったら、エンティティ識別子を簡単に取得し、もう一度ComponentManagerにこの識別子のTransformComponentを提供するように依頼できます。

私が約束したように、2番目の例を見てみましょう。RespawnComponentは、死後に生まれ変わる必要があるエンティティに使用されます。このコンポーネントには、エンティティの再生成の動作をカスタマイズするために使用できる5つのプロパティがあります。死後のエンティティの自動リバイバルを選択し、リバイバルの位置と方向だけでなく、再生成されるまでの時間を設定できます。リバイバルロジック自体はRespawnSystemに実装されています。

 // RespawnSystem.h class RespawnSystem : public ECS::System<RespawnSystem>, protected ECS::Event::IEventListener { private: // ...   Spawns m_Spawns; RespawnQueue m_RespawnQueue; //    void OnGameObjectKilled(const GameObjectKilled* event); public: RespawnSystem(); virtual ~RespawnSystem(); virtual void Update(float dt) override; //  ... }; // class RespawnSystem 

 // RespawnSystem.cpp // :   ! voidRespawnSystem::OnGameObjectKilled(const GameObjectKilled * event) { // ,      RespawnComponent* entityRespawnComponent = ECS::ECS_Engine->GetComponentManager()->GetComponent<RespawnComponent>(event->m_EntityID); if(entityRespawnComponent == nullptr || (entityRespawnComponent->IsActive() == false) || (entityRespawnComponent->m_AutoRespawn == false)) return; AddToRespawnQeueue(event->m_EntityID, entityRespawnComponent); } void RespawnSystem::Update(float dt) { foreach(spawnable in this->m_RespawnQueue) { spawnable.m_RemainingDeathTime -= dt; if(spawnable.m_RemainingDeathTime <= 0.0f) { DoSpawn(spawnable); RemoveFromSpawnQueue(spawnable); } } } 

上記のコードは不完全ですが、コードの重要な行のアイデアを提供します。RespawnSystemは含まれており、すべての更新実体識別子を自分でRespawnComponent。システムがGameObjectKilledイベントを受信すると、新しいエンティティがキューに入れられます。システムは、殺されたエンティティが再生成する能力を持っているかどうか、つまりRespawnComponentがアタッチされているかどうかをチェックします。そうである場合、エンティティは再生のためにキューに入れられ、そうでない場合は無視されます。フレームごとに呼び出されるRespawnSystem更新メソッドでは、システムは初期RespawnComponentの再スポーン時間を短縮しますキューに入れられたエンティティ。スポーン時間がゼロに短縮されると、エンティティは生まれ変わり、スポーンキューから削除されます。

この記事はかなり短いものでした。しかし、彼女がECSの世界ですべてがどのように機能するかについて大まかな考えを与えてくれたと思います。投稿を終える前に、私自身の経験を皆さんと共有したいと思います。 ECSでの作業は大きな喜びです。サードパーティのライブラリの助けを借りても、ゲームに新しい機能を追加するのは驚くほど簡単です。新しい機能をゲームに接続する新しいコンポーネントとシステムを追加したばかりで、停止したという感覚はまったくありませんでした。ゲームロジック全体を複数のシステムに分割することは直感的であり、ECSを使用する際に問題を引き起こすことはありません。ポインターのすべての「スパゲッティ依存関係」を取り除いたため、コードははるかに理解しやすく、サポートしやすくなりました。イベントソーシングは、システム/エンティティ間でデータを交換するための非常に強力で便利な手法ですが、両刃のブレードであり、時間の経過とともに問題を引き起こす可能性があります。イベントをトリガーするための条件について話している。 UnityまたはUnreal Engineエディターを使用したことがある場合は、そのようなエディターの実装に満足するでしょう。これらのエディターは、これらのすべてのコード行を手動で記述するよりも、新しいECSオブジェクトを作成する時間がはるかに短いため、生産性が大幅に向上します。しかし、エンティティ、コンポーネント、システム、およびイベントのオブジェクトの強力な基盤を作成する場合、それらを組み合わせて、それらに基づいて定性的なものを作成するのは簡単な作業になります。これらのコード行をすべて手動で記述するよりも。しかし、エンティティ、コンポーネント、システム、およびイベントのオブジェクトの強力な基盤を作成する場合、それらを組み合わせて、それらに基づいて定性的なものを作成するのは簡単な作業になります。これらのコード行をすべて手動で記述するよりも。しかし、エンティティ、コンポーネント、システム、イベントのオブジェクトの強力な基盤を作成する場合、それらを組み合わせて、それらに基づいて定性的なものを作成するのは簡単な作業になります。