RTSゲームユニットの構造

moveToやAttackアクションなどを複数回プログラムすることなく、多くの異なるユニットを作成する方法が欲しい

私の見方では、これを行うには2つの方法があります。

1. できること/できないことを指定するフラグを持つ単一の汎用ユニットクラス（その後、静的配列でインスタンスを作成し、必要に応じてそれらを取得します）
2. （Attack、Harvest、Patrol）のようなユニット固有のアクションの抽象メソッドを持つ抽象ユニットクラス。これらは、ユニットが実際に何も取得できない場合でも、すべてサブクラスで実装する必要があります。

これを行う最初の方法は最も簡単に思えますが、ほとんどのユニットで多くのコードが使用されないことになります。

2番目の方法も機能します。しかし、リソースを収穫できる2つの異なるユニットを使用することにした場合、2つの異なるクラスにまったく同じコードを使用することになります。これは正しい方法とは思えません。

これはこの問題への正しいアプローチですか？
AoEのようなゲームでは、すべてのユニットが、私が推測するもの、アクション/注文のリストのようなものを持っています。次に、そのアクションを必要とするすべてのユニットにそれを与えます。

はっきりしない（もっともらしい）場合、または探しているものに関する詳細情報が必要な場合は、コメントでお尋ねください。

一般的なアプローチは、ベースクラスの「ユニット」がすべてのユニットに共通する最も基本的な側面を実装するだけのコンポーネントベースのアプローチであり、各ユニットには実行できることを示す複数のコンポーネントオブジェクトのリストがあり、それがどうするか。

例えば、タンクは、コンポーネントかもしれないMobile、Destructible、Attackerだけで、不動のタレットDestructible、Attackerおよび収穫をMobile、Destructible、Harvester。これらのクラスには、これらの動作を実装するために必要なすべてのコードが含まれます。コンポーネント間の相互作用は、（Attackerのみが何であるか損傷する可能性がDestructible）他のユニットが、直接そのコンポーネントと相互作用し、必要な成分を有し、かつ場合、コンポーネントのチェックを有することによって実現することができます。

従来のクラス継承に対する利点は、能力を簡単に組み合わせることができることです。たとえば、歩兵の攻撃、輸送、飛行も可能なハーベスターが必要な場合は、必要なコンポーネントを追加するだけです。また、基本的なUnitクラスを肥大化させることなく、新しいコンポーネントの形で新しい機能を簡単に追加および削除できます。

エンジン全体がすでにコンポーネントベースであるため、Unityはそのようなアーキテクチャであなたをサポートします。したがって、これらのようなゲーム論理コンポーネントは、スクリプトの形式で追加できます。

多くのゲームでは、エンティティにコンポーネントベースのシステムを使用します。このシステムでは、エンティティのクラス（または同等のもの）の一部としてコーディングするのではなく、より一般的なユニットタイプに多数の動作と能力を追加できます。