エンティティとコンポーネントにメソッドを保存するのはなぜ悪い考えですか？（他のいくつかのエンティティシステムの質問と共に。）
これは私が答えたこの質問のフォローアップですが、これはより具体的なテーマに取り組んでいます。 この答えは、記事よりもエンティティシステムをよりよく理解するのに役立ちました。 エンティティシステムに関する（はい）記事を読みましたが、次のように伝えられました。 エンティティは単なるidとコンポーネントの配列です（記事では、コンポーネントにエンティティを保存することは物事を行う良い方法ではないと述べていますが、代替手段は提供していません）。 コンポーネントは、特定のエンティティで何ができるかを示すデータの断片です。 システムは「メソッド」であり、エンティティのデータの操作を実行します。 これは多くの状況で実際に実用的と思われますが、コンポーネントが単なるデータクラスであるという部分が気になります。たとえば、Entity SystemにVector2Dクラス（Position）を実装するにはどうすればよいですか？ Vector2Dクラスはデータを保持します：x座標とy座標ですが、その有用性に重要なメソッドもあり、クラスを2つの要素配列から区別します。：例の方法がありadd()、rotate(point, r, angle)、substract()、normalize()、および他のすべての標準的な、便利な、と（Vector2Dクラスのインスタンスである）の位置が持つべきであることが絶対に必要なメソッド。 コンポーネントが単なるデータホルダーである場合、これらのメソッドを持つことはできません！ おそらくポップアップする可能性のあるソリューションの1つは、システム内に実装することですが、それは非常に直感に反するようです。これらのメソッドは、私が今実行したいものであり、完全で使用可能な状態になっています。MovementSystemエンティティの位置の計算を実行するように指示する高価なメッセージセットを読み取るのを待ちたくありません！ そして、記事は非常にはっきりと述べているだけのシステムが持つべきすべての機能を、私は見つけることができるそのための唯一の説明は、「OOPを避けるため」でした。まず第一に、エンティティやコンポーネントでメソッドを使用することを控えるべき理由がわかりません。メモリのオーバーヘッドは実質的に同じであり、システムと組み合わせた場合、これらは非常に簡単に実装し、興味深い方法で組み合わせる必要があります。たとえば、システムは、実装自体を知っているエンティティ/コンポーネントにのみ基本的なロジックを提供できます。あなたが私に尋ねると-これは基本的にESとOOPの両方から利点を取ります。これは記事の著者によるとできないことですが、私にとっては良い習慣のようです。 このように考えてください。ゲームにはさまざまな種類の描画可能なオブジェクトがあります。昔ながらの画像、アニメーション（update()、getCurrentFrame()など）、これらのプリミティブ型の組み合わせ、およびそれらのすべては、単純に提供できるdraw()だけで、その後、エンティティのスプライトがどのように実装されるかを気にする必要はありませんレンダリングシステムに方法をインターフェース（描画）と位置について。そして、レンダリングとは関係のないアニメーション固有のメソッドを呼び出すアニメーションシステムのみが必要になります。 そして、もう1つだけ...コンポーネントの保存に関して、配列の代替物は本当にありますか？Entityクラス内の配列以外にコンポーネントを保存する場所は他にありません... たぶん、これはより良いアプローチです：コンポーネントをエンティティの単純なプロパティとして保存します。たとえば、位置コンポーネントはに接着されentity.positionます。 他の唯一の方法は、異なるエンティティを参照する、システム内にある種の奇妙なルックアップテーブルを持つことです。しかし、それは非常に非効率的で、単にコンポーネントをエンティティに格納するよりも開発が複雑に思えます。