ゲームデザインでのフレームごとの関数呼び出しとイベント駆動型メッセージング

伝統的なゲームデザインは、私はそれを知っているように、使用する多型と仮想関数を更新ゲームオブジェクトの状態に。言い換えると、ゲーム内のすべてのオブジェクトで、同じ一連の仮想関数が定期的（例：フレームごと）に呼び出されます。

最近、もう1つ、ゲームオブジェクトの状態を更新するためのイベント駆動型メッセージングシステムがあることを発見しました。ここでは、オブジェクトは通常フレームごとに更新されません。代わりに、非常に効率的なイベントメッセージングシステムが構築され、ゲームオブジェクトは有効なイベントメッセージを受信した後にのみ更新されます。

イベント駆動型ゲームアーキテクチャについては、Mike McShaffryによる「Game Coding Complete」で詳しく説明されています。

以下の質問について、親切にお願いできますか？

• 両方のアプローチの長所と短所は何ですか？
• どちらが他より優れているのですか？
• イベント駆動型ゲームデザインは、すべての分野で普遍的で優れていますか？したがって、モバイルプラットフォームでも使用することをお勧めしますか？
• どちらがより効率的で、どちらが開発が難しいですか？

明確にするために、私の質問はゲームデザインから完全に多態性を取り除くことについてではありません。私は単に、イベント駆動型メッセージングと仮想関数への通常の（フレームごとの）呼び出しを使用してゲームの状態を更新することの違いとメリットを理解したいと思っています。

例： この質問はここで少し論争を引き起こしたので、例を挙げましょう。MVCによると、ゲームエンジンは3つの主要な部分に分かれています。

1. アプリケーション層（ハードウェアおよびOS通信）
2. ゲームロジック
3. ゲームビュー

レーシングゲームでは、ゲームビューは画面をできるだけ速く、少なくとも30fpsでレンダリングする責任があります。ゲームビューもプレイヤーの入力をリッスンします。今これが起こります：

• プレーヤーが燃料ペダルを80％まで押した
• GameViewは「Car 2 Fuel Pedal Pressed to 80％」というメッセージを作成し、それをGame Logicに送信します。
• Game Logicはメッセージを取得し、評価し、新しい車の位置と動作を計算し、GameView用に次のメッセージを作成します： "Draw Car 2 Fuel Pedal Pressed 80％"、 "Car 2 Sound Acceleration"、 "Car 2 Coordinates X、Y" .. 。
• GameViewはメッセージを受信し、それに応じて処理します

私は必然的に発明の母であることを完全に信じています。必要が明確で明確でない限り、私は何もコーディングしたくない。イベントメッセージングシステムをセットアップしてプロジェクトを開始すると、間違っていると思います。インフラストラクチャを作成してテストし、プロジェクトのすべての要素を明確に定義し、機能するモジュールを用意して初めて、これらのモジュールを相互に接続する方法に集中できると思います。各モジュールの形状とニーズを理解する前にイベントメッセージングシステムを設計しようとするのは順不同です。

両方のアプローチの長所と短所は何ですか？

一部の人々は、インストールして使用する準備ができている優れたメッセージングシステムがあると主張するでしょう。おそらくこれは本当です。確かに、ニーズに合わせて特別に調整されたカスタムビルドソリューションのパフォーマンスは、汎用メッセージバスよりも優れています。大きな問題は、すでに構築されているものを使用するのではなく、メッセージングシステムの構築にどれだけの時間を費やすかです。明らかに、必要な機能セットを備えたある種のイベントシステムを見つけることができれば、それは非常に簡単な決定です。そのため、決定を下す前に、自分が必要なものを正確に理解していることを確認します。

どちらが他より優れているのですか？

ここでメモリとリソースについて話すことができます。リソースが限られているハードウェア向けに開発している場合、それを大幅に削減するイベントシステムを使用することは確かに問題です。しかし、実際には、問題はあなたが必要とするものに起因すると思います。これは、すでに述べたように、すべての部分がどのように見えるかを見るまでわからないものです。これらのシステムの構築に十分な経験があり、すべての要素がどのようになるかを事前に正確に把握している場合は、この質問にも事前に回答できます。経験したことがあれば、この質問をするつもりはないので、この経験はないと思います。

イベント駆動型ゲームデザインは、すべての分野で普遍的で優れていますか？したがって、モバイルプラットフォームでも使用することをお勧めしますか？

すべての分野で普遍的で優れていますか？そのようなかなり包括的な声明は簡単に拒否されます。オーバーヘッドを追加するものはすべて、ワークロードのシェアを運ぶ必要があります。デザインのオーバーヘッドを保証するのに十分なイベントを使用していない場合、それは間違ったデザインです。

どちらがより効率的で、どちらが開発が難しいですか？

効率は、その実装方法によって異なります。よく開発された伝統的なデザインは、イベントベースのシステムよりも優れています。これは、ピース間の通信をマイクロ管理して、非常に効率的にすることができるためです。もちろん、これはまた、それを完了するために必要な経験と時間の観点から設計することをより困難にし、より効率的にします。一方、この経験がないか、アプリケーションを適切に開発する時間がない場合は、ニーズに合ったイベントベースのデザインを使用する方が効率的です。イベントベースの構造に簡単に適合しないカスタムイベントのニーズがある場合、これはイベントベースの構造の設計を非常に困難にする可能性があります。特に、設計の効率を維持するためです。

ここでリンゴとオレンジを比較していると思います。ポリモーフィズムの代わりにメッセージングを使用することはありません。おそらく、緩やかに結合されたコンポーネントを接続するためのイベント/メッセージングが必要です。例えば。衝突が発生したときにエンティティからメッセージを送信したり、プレーヤーのスコアを更新したり、効果音をトリガーしたりできます。そのため、これらの個々のクラスは他のクラスを認識せず、メッセージを送信または処理するだけです。

しかし、あなたのゲームは、最も可能性の高い更新ループのどこかを持っているとしているとあなたは以来持っていること、更新ループを、簡単にだけでなく、すべてのフレームを更新する必要があるすべてのゲームのエンティティを更新するために使用することができます。ただし、これはメッセージングの使用を妨げません...

ゲームエンティティを追加/削除するような構造がある場合は、フレームごとに更新メッセージをディスパッチする代わりに、更新ループに含めることもできます。では、メッセージングを使用してゲームのさまざまなサブシステムを接続しているときに、ゲームエンティティでupdateを直接呼び出さないのはなぜですか？イベントのようなシステムのシグナル/スロットの概念（qtの例を参照）も気に入っています。

結論：より良いアプローチはなく、排他的でもありません。

これは、bummzackの回答に対するコメントとして始まりましたが、長くなりました。

実際に非同期にしない限り（新しいスレッドでイベントをディスパッチ）、オブジェクトはメモを同期的に取得します。イベントディスパッチャーがセル内のリンクリストを含む基本的なハッシュテーブルを使用すると想定すると、順序は、オブジェクトがそのセルに追加された順序になります。

さらに、何らかの理由で関数ポインターを使用することを決定しない限り、メッセージを取得する各オブジェクトはIEventListener（またはユーザーが呼び出すもの）を実装する必要があるため、仮想関数呼び出しを使用しています。イベントは、ポリモーフィズムを使用して構築する高レベルの抽象化です。

ゲーム内のさまざまなシステムを同期するために、ゲーム内のさまざまな出来事のメソッドのランドリーリストを呼び出さなければならない場合や、さまざまなオブジェクトやシステムの反応が原因で、その出来事を明確に定義できない場合、または必要な場合に、イベントを使用します。将来の出来事にもっと反応を加えるために。

それらは素晴らしいツールですが、ブムザックが言ったように、ポリモーフィズムとイベントが同じ問題を解決すると仮定しないでください。

どちらか一方を選ぶのはかなり間違っています。一部のオブジェクトはすべてのフレームを呼び出す必要があります。レンダリングしたいオブジェクトがある場合は、フレームごとにそのオブジェクトにレンダーコールを行う必要があります。イベントはこの変更を行うことができません。同じことが時間ベースの物理オブジェクトにも当てはまります。フレームごとに呼び出す必要があります。

ただし、オブジェクト管理オブジェクトやユーザー入力オブジェクトなどをフレームごとに呼び出すわけではありません。フレーム上のすべてのオブジェクトへの大量の仮想呼び出しはひどい考えです。

特定のオブジェクトに使用される設計は、それらのオブジェクトのニーズに基づく必要があり、システム全体のいくつかのイデオロギーに基づくべきではありません。

最初の文がより明確になるように編集しました。