コンポーネントの動作をオーバーライドする

コンポーネントベースのエンティティシステムで動作のオーバーライドを実装する方法を考えていました。具体的な例として、エンティティには、ダメージ、回復、殺されるなどのヒースコンポーネントがあります。エンティティには、キャラクターが受けるダメージの量を制限する鎧コンポーネントもあります。

これまでにコンポーネントベースのシステムでこのような動作を実装したことはありますか？
どうやってやったの？

誰もこれまでにこれをしたことがないのなら、なぜそうだと思いますか？ コンポーネントの動作をオーバーライドすることに特に問題があることはありますか？

以下は私がそれがうまくいくと想像する方法の大まかなスケッチです。エンティティのコンポーネントは順序付けられています。最前線のユーザーは、最初にインターフェースのサービスを受ける機会を得ます。それがどのように行われるかについては詳しく説明しません。悪意のあるdynamic_castsを使用すると仮定します（実際は使用しませんが、RTTIがなくても最終的な効果は同じです）。

class IHealth
{
public:
   float get_health( void ) const = 0;
   void do_damage( float amount ) = 0;
};

class Health : public Component, public IHealth
{
public:
   void do_damage( float amount )
   {
      m_damage -= amount;
   }
private:
   float m_health;
};

class Armor : public Component, public IHealth
{
public:
   float get_health( void ) const
   {
      return next<IHealth>().get_health();
   }

   void do_damage( float amount )
   {
      next<IHealth>().do_damage( amount / 2 );
  }
};

entity.add( new Health( 100 ) );
entity.add( new Armor() );
assert( entity.get<IHealth>().get_health() == 100 );
entity.get<IHealth>().do_damage( 10 );
assert( entity.get<IHealth>().get_health() == 95 );

私がこれを行うことを提案している方法について特にナイーブなものはありますか？

あなたはそれを少し複雑にしすぎているか、十分に複雑にしていないと思います。

私が提案する方向性の1つは、ヘルスを取得してダメージインターフェースを実行することです。

したがって、おそらくアイデアとして、Armorコンポーネントは次のようになります。

class Armor : public Component, public IDamageReceiver
{
public:
   void do_damage( float amount )
   {
      // just assume that subtract_health isn't used in client code maybe
      this.get<IHealth>().subtract_health( amount / 2 ); 
   }
};

代わりに（そしておそらく私が何をするか）、コンポーネントを少し大きくして、特定のタイプの派生元である一般的な「エンティティ」基本クラスを用意することもできます。これにはヘルスとアーマーの両方の機能が含まれ、そこから特定のエンティティを実装できます。

あなたの考えは正しい場所にありますが、私はコンポーネントシステムを必要のない詳細レベルにしようとしていると思います。あなたが必要なのは、健康をまっすぐにする場合、健康と呼ばれるコンポーネントを作ると思います。ただし、鎧も含まれているヘルスコンポーネントが必要な場合は、一般的なヘルスのAPIに適合するCHealthAndArmorコンポーネントにして、他のコンポーネントと同じように使用できるようにします。ただし、鎧レベルを変更する方法も提供します完全にロード時間の値である場合、必要はありません。それは、その特定のヘルスコンポーネントの内部動作のみです。

正直なところ、（これと他の投稿から）懸念しているのは、コンポーネントを細かくレベル分けすることです。別のコンポーネント内でコンポーネントを継承またはカプセル化していることに気付いた場合は、何をしているのかを再検討する必要があります。一般に、コンポーネントベースのアーキテクチャでは、このような継承を回避しようとしています。

お役に立てれば

コンポーネントの要素が多すぎますOOP。ここで私がやっていることを見てください：

https://github.com/thelinuxlich/starwarrior_CSharp

そして、これは私がC＃に移植したEntity Systemフレームワークです：https : //github.com/thelinuxlich/artemis_CSharp

イベント駆動型コンポーネントシステムを使用していて、同じ問題がありました。基本的に、私はコンポーネント関数を他のコンポーネントイベントにサブスクライブします。1つのイベントで、x個の関数をサブスクライブすることができ、イベントはサブスクライブされた順序で発生します。イベントは、動的クラスであり、参照によって渡される1つのパラメーターも提供します。これはすべて、StatsコンポーネントとHealthコンポーネントを作成できることを意味します。私は両方のハートメッセージをサブスクライブしますが、Statsが最初にサブスクライブされるため、Statコンポーネントの鎧ステータスを使用し、パラメーターオブジェクト内にあるダメージ値を変更します。ヘルスコンポーネントはサブスクリプションリストの次であり、それが呼び出されるまでに、ダメージ値はすでに減少しています。

コンポーネントを扱うイベントの方法を十分に話すことができません。実際には、コンポーネントが互いにイベントを知らないコンポーネントを介して機能をつなぎ合わせることができます。ユーザーは、イベントサブスクリプションを設定して機能を構築するだけです。このシステムから決して振り返ることはありません。