「ゲームオブジェクト」-およびコンポーネントベースのデザイン

私は過去3〜4年間、趣味のプロジェクトに取り組んでいます。シンプルな2Dおよび3Dゲーム。しかし最近、より大きなプロジェクトを始めました。ここ数か月間、私はすべてのゲームオブジェクトのベースとなるゲームオブジェクトクラスを設計しようとしていました。何度も試行錯誤を繰り返した後、グーグルに目を向けると、すぐにいくつかのGDC PDFおよびPowerPointが示されました。そして今、私はコンポーネントベースのゲームオブジェクトを把握しようとしています。

エンジンはゲームオブジェクトを作成し、その後、健康、物理学、ネットワークなどの処理を行うさまざまなコンポーネントをアタッチすることを理解しています。しかし、私が理解していないのは、コンポーネントXがYがオブジェクトの状態を変更したかどうかを知る方法です。健全性はHealthComponentによって制御されているため、PhysicsComponentはプレーヤーが生きているかどうかをどのように知るのでしょうか。そして、HealthComponentはどのようにして「プレイヤーが死んだアニメーション」を再生しますか？

私はそれが次のようなものであると感じていました（HealthComponent内）：

if(Health < 0) {
   AnimationComponent.PlayAnimation("played-died-animation")
}

しかし、もう一度、HealthComponentは、どのように接続されているゲームオブジェクトにAnimationComponentが接続されていることを知るのでしょうか？私がここで見る唯一の解決策は

1. AnimationComponentがアタッチされているかどうかを確認してください（コンポーネントコード内またはエンジン側）

2. コンポーネントには他のコンポーネントが必要ですが、それはコンポーネント設計全体と戦うようです。

3. HealthWithAnimationComponent、HealthNoAnimationComponentなどのように書きます。これもコンポーネント設計のアイデア全体と戦うようです。

すべての例に、ひどい問題があります。正常性コンポーネントは、エンティティの死に応答する必要がある可能性のあるすべてのコンポーネントタイプについて知る必要があります。したがって、どのシナリオも適切ではありません。エンティティにはヘルスコンポーネントがあります。アニメーションコンポーネントがあります。他の人に依存したり、他の人について知りません。彼らはメッセージングシステムを介して通信します。

正常性コンポーネントは、エンティティが「死亡」したことを検出すると、「死亡」メッセージを送信します。適切なアニメーションを再生してこのメ​​ッセージに応答するのは、アニメーションコンポーネントの責任です。

正常性コンポーネントは、メッセージをアニメーションコンポーネントに直接送信しません。たぶんそれはそのエンティティのすべてのコンポーネント、おそらくシステム全体にブロードキャストします。おそらく、アニメーションコンポーネントは、「私が死んだ」メッセージに関心があることをメッセージングシステムに知らせる必要があります。メッセージングシステムを実装するには多くの方法があります。どのように実装しても、重要なのは、ヘルスコンポーネントとアニメーションコンポーネントが他のコンポーネントが存在するかどうかを知る必要がないことです。新しいコンポーネントを追加しても、適切なメッセージを送信するために既存のコンポーネントを変更する必要はありません。

方法アルテミスは、問題を解決には、コンポーネント内の処理をしないことです。コンポーネントには、必要なデータのみが含まれます。システムは複数のコンポーネントタイプを読み取り、必要な処理を実行します。

したがって、あなたの場合、HealthComponent（およびその他）を読み取り、キューを適切なアニメーションで再生するRenderSystemがあります。この方法でデータを関数から分離すると、依存関係を適切に管理しやすくなります。

あなたのコードでは、オブジェクトが状態を変更したかどうかを知る方法（私はそれらを使用し、おそらく他のいくつかの方法が存在する）があります：

1. メッセージを送る。
2. コンポーネントからデータを直接読み取ります。

1）AnimationComponentがアタッチされているかどうかを確認します（コンポーネントコード内またはエンジン側）

これには、1。GameObjectのHasComponent関数、または2.コンポーネントをアタッチするときに、何らかの構築関数の依存関係を確認できます。

2）コンポーネントには他のコンポーネントが必要ですが、それはコンポーネント設計全体と戦うようです。

私が読んだいくつかの記事では、Idealシステムコンポーネントは相互に依存していませんが、実際にはそうではありません。

3）HealthWithAnimationComponent、HealthNoAnimationComponentなどのように記述します。これもコンポーネント設計のアイデア全体と戦うようです。

そのようなコンポーネントを記述するのは悪い考えです。私のアプリでは、最も独立したHealthコンポーネントを作成しました。現在、特定のイベント（「ヒット」、「修復」など）についてサブスクライバーに通知するObserverパターンについて考えています。そのため、AnimationComponentはアニメーションをいつ再生するかを自ら決定する必要があります。

しかし、CBESに関する記事を読んだときは感銘を受けたので、CBESを使用してその新しい可能性を発見したとき、私は今とても幸せです。

マイケル、パトリックヒューズ、ブレッキのようなものです。問題を単純に回避することを回避する解決策は、そもそも問題を引き起こすイデオロギーを放棄することです。

OODが少なく、関数型プログラミングに似ています。コンポーネントベースの設計を試し始めたとき、私はこの問題を将来見つけました。私はもう少しグーグルで検索しましたが、「Functive Reactive Programming」が解決策であることがわかりました。

現在、私のコンポーネントは、現在の状態を記述する変数とフィールドのコレクションにすぎません。次に、それらに関連するすべてのコンポーネントを更新する「システム」クラスがたくさんあります。リアクティブ部分は、システムを適切に定義された順序で実行することにより実現されます。これにより、システムが処理および更新を行うために次に並んでいるもの、および読み取りおよび更新しようとしているコンポーネントおよびエンティティーが常に最新のデータで動作することが保証されます。

ただし、ある意味では、問題が再び動いたと主張することもできます。システムを実行する必要がある順序が単純でない場合はどうでしょうか？循環的な関係があり、if-elseとswitchステートメントの混乱をじっと見つめる前の時間の問題がある場合はどうでしょうか。暗黙のメッセージング形式ですよね？一見、小さなリスクだと思います。通常、物事は順番に処理されます。プレイヤー入力->エンティティ位置->衝突検出->ゲームロジック->レンダリング->最初からやり直してください。その場合、それぞれに1つのシステムがあり、各システムにupdate（）メソッドを提供してから、それらをゲームループで順番に実行します。