エンティティ通信はどのように機能しますか？

2つのユーザーケースがあります。

1. どのようにメッセージをentity_A送信しtake-damageますentity_Bか？
2. のHPをどのようにentity_A照会しますentity_Bか？

これまでに遭遇したことがあります：

• メッセージキュー
  1. entity_Atake-damageメッセージを作成し、それをentity_Bのメッセージキューに投稿します。
  2. entity_Aquery-hpメッセージを作成してに投稿しentity_Bます。 entity_B代わりに、response-hpメッセージを作成してに投稿しentity_Aます。
• パブリッシュ/サブスクライブ
  1. entity_Btake-damageメッセージをサブスクライブします（おそらく、何らかのプリエンプティブフィルタリングを使用して、関連するメッセージのみが配信されます）。 を参照entity_Aするtake-damageメッセージを生成しますentity_B。
  2. entity_Aupdate-hpメッセージをサブスクライブします（フィルタリングされる可能性があります）。すべてのフレームがメッセージをentity_Bブロードキャストしupdate-hpます。
• 信号/スロット
  1. ???
  2. entity_Aupdate-hpスロットをentity_Bのupdate-hp信号に接続します。

もっと良いものはありますか？これらの通信方式がゲームエンジンのエンティティシステムにどのように結び付くのかを正しく理解していますか？

良い質問！あなたが尋ねた特定の質問に進む前に、シンプルさの力を過小評価しないでください。Tenpnは正しい。これらのアプローチでやろうとしているのは、関数呼び出しを延期するか、呼び出し元を呼び出し先から切り離すエレガントな方法を見つけることだけです。これらの問題のいくつかを軽減する驚くほど直感的な方法としてコルーチンをお勧めできますが、それは少し話題から外れています。場合によっては、関数を呼び出して、エンティティAがエンティティBに直接結合されているという事実をそのまま使用したほうがよい場合があります。

とはいえ、私はシグナル/スロットモデルと単純なメッセージパッシングを組み合わせて使用​​し、満足しています。私は非常にタイトなスケジュールを持っていたかなり成功したiPhoneタイトルのためにC ++とLuaでそれを使用しました。

シグナル/スロットの場合、エンティティAにエンティティBがしたことに応答して何かをさせたい場合（たとえば、何かが死んだときにドアのロックを解除する）、エンティティAがエンティティBの死亡イベントに直接サブスクライブする場合があります。または、エンティティAがエンティティグループのそれぞれにサブスクライブし、発生した各イベントでカウンターをインクリメントし、それらのNが死亡した後にドアをロック解除する可能性があります。また、「エンティティのグループ」と「それらのN」は、通常、レベルデータで定義されたデザイナーです。（余談ですが、WaitForMultiple（ "Dying"、entA、entB、entC）; door.Unlock（）;など、コルーチンが本当に輝くことができる領域の1つです。

しかし、C ++コードと密接に関連する反応、または本質的にはかないゲームイベント（損傷の処理、武器のリロード、デバッグ、プレイヤー主導のロケーションベースのAIフィードバック）に関しては、面倒になる可能性があります。これは、メッセージの受け渡しがギャップを埋めることができる場所です。基本的に、「このエリアのすべてのエンティティに3秒でダメージを与えるように伝える」、「物理学を完成させて誰が撃ったかを把握したら、このスクリプト関数を実行するように指示する」などです。パブリッシュ/サブスクライブまたはシグナル/スロットを使用してうまく行う方法を理解することは困難です。

これは簡単に過剰になります（tenpnの例に対して）。また、多くのアクションがある場合は、非効率的な肥大化になる可能性があります。しかし、欠点にも関わらず、この「メッセージとイベント」アプローチは、スクリプト化されたゲームコード（Luaなど）と非常によく一致します。スクリプトコードは、C ++コードをまったく気にせずに、独自のメッセージとイベントを定義して対応できます。また、スクリプトコードは、レベルの変更、サウンドの再生、TakeDamageメッセージが与えるダメージの量を武器に設定させるなど、C ++コードをトリガーするメッセージを簡単に送信できます。luabindを常にあざける必要がなかったので、時間を大幅に節約できました。そして、あまり多くはなかったので、すべてのluabindコードを1か所に保管することができました。適切に結合すると、

また、ユースケース＃2での私の経験では、別の方向のイベントとして処理する方が良いということです。エンティティのヘルスが何であるかを尋ねる代わりに、ヘルスが大幅に変化するたびにイベントを発生させ、メッセージを送信します。

ところで、インターフェイスに関しては、EventHost、EventClient、MessageClientの3つをすべて実装することになりました。EventHostsはスロットを作成し、EventClientsはスロットにサブスクライブ/接続し、MessageClientsはデリゲートをメッセージに関連付けます。MessageClientのデリゲートターゲットは、必ずしも関連付けを所有するオブジェクトと同じである必要はないことに注意してください。つまり、MessageClientsは、メッセージを他のオブジェクトに転送するためだけに存在できます。FWIW、ホスト/クライアントの比phorは一種の不適切です。Source / Sinkはより良い概念かもしれません。

申し訳ありませんが、私はちょっとそこを取り乱しました。それが私の最初の答えです:)私はそれが理にかなったことを望みます。

// in entity_a's code:
entity_b->takeDamage();

あなたはコマーシャルゲームがそれをどのように行うか尋ねました。;）

より深刻な答え：

黒板がよく使われるのを見てきました。単純なバージョンは、エンティティのHPのようなもので更新されたストラットにすぎず、エンティティはクエリを実行できます。

黒板は、このエンティティの世界観（Bの黒板にそのHPを尋ねる）、またはエンティティの世界観（Aが黒板に問い合わせてAのHPを確認する）のいずれかです。

フレーム内の同期点でのみ黒板を更新する場合は、後から任意のスレッドからそれらを読み取ることができるため、マルチスレッドの実装は非常に簡単になります。

より高度な黒板は、文字列を値にマッピングするハッシュテーブルのようなものです。これは保守性が高くなりますが、明らかに実行時のコストがかかります。

黒板は伝統的に一方向の通信にすぎません-損傷によるディッシングを処理しません。

私はこの問題を少し研究し、素晴らしい解決策を見ました。

基本的にはサブシステムがすべてです。これは、tenpnが言及した黒板のアイデアに似ています。

エンティティはコンポーネントで構成されていますが、プロパティバッグにすぎません。エンティティ自体に動作は実装されていません。

たとえば、エンティティにはHealthコンポーネントとDamageコンポーネントがあります。

次に、MessageManagerと3つのサブシステム、ActionSystem、DamageSystem、HealthSystemがあります。ある時点で、ActionSystemはゲームワールドで計算を行い、イベントを生成します。

HIT, source=entity_A target=entity_B power=5

このイベントは、MessageManagerに公開されます。ある時点で、MessageManagerは保留中のメッセージを調べて、DamageSystemがHITメッセージをサブスクライブしたことを検出します。これで、MessageManagerはHITメッセージをDamageSystemに配信します。DamageSystemは、Damageコンポーネントを持つエンティティのリストを調べ、ヒットパワーまたは両方のエンティティのその他の状態などに応じてダメージポイントを計算し、イベントを発行します。

DAMAGE, source=entity_A target=entity_B amount=7

HealthSystemはDAMAGEメッセージをサブスクライブしており、MessageManagerがDAMAGEメッセージをHealthSystemに発行すると、HealthSystemはエンティティentity_Aとentity_Bの両方にHealthコンポーネントでアクセスできるため、HealthSystemが計算を実行できますMessageManagerへ）。

このようなゲームエンジンでは、メッセージの形式がすべてのコンポーネントとサブシステム間の唯一のカップリングです。サブシステムとエンティティは完全に独立しており、互いに気付きません。

実際のゲームエンジンがこのアイデアを実装しているかどうかはわかりませんが、かなり堅実でクリーンなようです。いつか自分の趣味レベルのゲームエンジンに自分で実装したいと思っています。

次のようなグローバルメッセージキューを用意してください。

messageQueue.push_back(shared_ptr<Event>(new DamageEvent(entityB, 10, entityA)));

と：

DamageEvent(Entity* toDamage, uint amount, Entity* damageDealer);

そして、ゲームループ/イベント処理の最後に：

while(!messageQueue.empty())
{
    Event e = messageQueue.front();
    messageQueue.pop_front();
    e.Execute();
}

これがコマンドパターンだと思います。そして、派生物が何かを定義して実行する、Execute()純粋な仮想in Eventです。だからここに：

DamageEvent::Execute() 
{
    toDamage->takeDamage(amount); // Or of course, you could now have entityA get points, or a recognition of damage, or anything.
}

ゲームがシングルプレーヤーの場合は、ターゲットオブジェクトメソッドを使用します（tenpnの推奨どおり）。

マルチプレイヤー（正確にはマルチクライアント）である（またはサポートしたい）場合は、コマンドキューを使用します。

• クライアント1でAがBにダメージを与えた場合、ダメージイベントをキューに入れるだけです。
• ネットワーク経由でコマンドキューを同期する
• 両側でキューに入れられたコマンドを処理します。

私は言うだろう：ダメージからの即時のフィードバックを明示的に必要としない限り、どちらも使用しないでください。

損傷を受けるエンティティ/コンポーネント/何でも、イベントをローカルイベントキューまたは損傷イベントを保持する同等レベルのシステムにプッシュする必要があります。

エンティティaからイベントを要求し、それをエンティティbに渡す両方のエンティティへのアクセスを備えたオーバーレイシステムが必要です。どこからでも何でも使用してイベントをいつでも渡すことができる一般的なイベントシステムを作成しないことにより、コードを常にデバッグしやすくし、パフォーマンスを測定しやすくし、理解しやすく読みやすくする明示的なデータフローを作成します一般的に、より適切に設計されたシステムにつながります。

電話をかけるだけです。query-hpに続くrequest-hpを実行しないでください。そのモデルに従えば、あなたは怪我の世界に入ります。

Mono Continuationsもご覧ください。NPCにとって理想的だと思います。

では、同じupdate（）サイクルでプレーヤーAとBがお互いにヒットしようとするとどうなりますか？プレーヤー1のUpdate（）が、サイクル1のプレーヤーBのUpdate（）の前に発生したと仮定します（または、ティック、またはそれを呼び出すもの）。私が考えることができる2つのシナリオがあります：

1. メッセージによる即時処理：

   • プレーヤーA.Update（）は、プレーヤーがBをヒットすることを望んでいることを確認し、プレーヤーBは損傷を通知するメッセージを取得します。
   • プレイヤーB.HandleMessage（）はプレイヤーBのヒットポイントを更新します（彼は死にます）
   • プレーヤーB.Update（）は、プレーヤーBが死亡したことを確認します。プレーヤーAを攻撃することはできません。

これは不公平です。プレイヤーAとBはお互いにヒットするはずです。そのエンティティ/ゲームオブジェクトが後でupdate（）を取得したという理由だけで、プレイヤーBはAにヒットする前に死亡しました。

1. メッセージのキューイング

   • プレーヤーA.Update（）は、プレーヤーがBをヒットすることを望み、プレーヤーBが損傷を通知するメッセージを取得し、それをキューに格納します
   • プレーヤーA.Update（）はキューをチェックしますが、空です
   • プレイヤーB.Update（）は最初に動きをチェックし、プレイヤーBもダメージを与えてプレイヤーAにメッセージを送信します
   • プレーヤーB.Update（）もキュー内のメッセージを処理し、プレーヤーAからのダメージを処理します
   • 新しいサイクル（2）：プレーヤーAはヘルスポーションを飲みたいため、プレーヤーA.Update（）が呼び出され、移動が処理されます
   • プレーヤーA.Update（）はメッセージキューをチェックし、プレーヤーBからのダメージを処理します

繰り返しますが、これは不公平です。プレイヤーAは、同じターン/サイクル/ティックでヒットポイントを取ることになっています！