XNAゲームでイベントを使用する必要がありますか？

画面にボタンを描画するボタンクラスを作成しました。それをクリックすると、何かが起こっているのを見たいです。WinFormでは、ボタンのOnClickイベントを使用します。XNAはどうですか？

OnClickイベントをボタンクラスに追加する必要がありますか？それは良い習慣ですか？それ以外の場合、ゲームループでイベントをどのように処理しますか？

eventゲームで使用することの唯一の理由は、イベントハンドラーにアタッチするデリゲートを作成すると、ガベージコレクションを引き起こす可能性のあるヒープオブジェクトが作成され、Xbox 360（およびおそらくWP7）でフレームレートの中断が発生する可能性があることです。それ）。

一般に、これは一度設定したゲームUIには関係ありません。

また、イベントハンドラーの呼び出しは、他のいくつかの利用可能なメソッドのごくわずかです。また、これはUIにはまったく関係ありません。（これは、マイクロ最適化された数を処理するためにのみ機能します）。

そのため、イベントハンドラーの割り当てをすべて無用に実行しない限りevent、ゲームでの使用の選択は、通常のアプリケーションでの使用の選択と変わりません。

ゲームUIのWinFormsのデザインをコピーすることは完全に問題ありません。

（イベントの1つの注意点を指摘する価値があるのは、ハンドラーを削除しないと、オブジェクトが意図せずに存続する可能性がある「非表示」の強い参照であることです。これは、ゲームと通常のアプリケーションの両方に関係します）

イベントを使用して、クリックやボタンインターフェイスとの他の相互作用などを処理することは完全に許容されます。これは、Button型をサブクラス化してカスタマイズされた動作を実装する方法よりも優れた方法です。

もう1つの一般的でない代替手段は、ボタンやその他のUI要素にスクリプトをアタッチすることですが、これはより複雑で（既に堅牢なスクリプトシステムが導入されていない限り）、必ずしも適切とは言えません。

また、入力を処理する別の方法を提供する「イミディエイトモードGUI」の概念を検討することもできます。

私がゲームエンジンで見た一般的なアプローチは3つありますが、XNAが3つすべてをサポートするかどうかはわかりませんが、ここでは次のようになっています。

1. ボタンクラスからクラスを継承し、CustomButtonクラスのOnClickFunctionをオーバーライドできます。利点は、ボタンが押されているかどうかを確認する必要がないことです。ボタンをクリックするたびに通知されますが、継承が過剰に使用される可能性があります。

2. OnClick関数を定義してOnClickEvent buttenクラスに渡すことができます（通常のc＃イベント処理と同様）。これには前のものと同じ利点があり、継承の使いすぎを心配する必要はありません。

3. このボタンがクリックされたかどうかをメインループでチェックする必要があります。このメソッドでは、実際のイベントではありません。したがって、欠点は、ボタン入力に基づいて何かを行う必要があるときはいつでも自分自身をチェックする必要があることですが、ボタンが実際にチェックされる場所を制御して有効にすることができるという利点があります。

私は.netイベントの使用をやめ、すべてのイベントと変更をバッファに保存し始めました：

public sealed class GameStateData
{
    public bool IsEmpty = true;
    public List<EventData> EventDatas = new List<EventData>();
    public List<ChangeData> ChangeDatas = new List<ChangeData>();
    ...//your additional data

    public void Reset()
    {
        IsEmpty = true;
        ManifoldDatas.Count = 0;
        ChangeDatas.Count = 0;
    }
}

public struct ChangeData
{
    public Node Sender;
    public short PropertyIndex; // predefined property index (f.e. (short)MyIndexEnum.Life)
    public object OldValue;
    public object NewValue;
    public object AdditionalData;
}

長所：

1. マルチスレッドのサポートで必要なのは、バッファーをスワップして、レンダリングスレッドですべてのイベントと変更を処理することだけです。
2. すべてのゲームステップの変更が保存されるため、ゲームロジックはイベントの組み合わせに基づくことができます。時間反転を実装することもできます。
3. 単一オブジェクトのサイズを増やすイベントフィールドを作成する必要はありません。ほとんどの場合、ゲームロジックは単一のまれなサブスクライバーのみを必要とします。
4. 追加のメモリ割り当てはほとんどありません（ボクシングのケースを除く）（重要なWP7、XBox、およびその他のマイクロフレームワーク）。
5. オブジェクトへの事前定義されたGameStateDataを処理するさまざまなイベントセットを持つことができます。

短所：

1. 必要なバッファーは3つ（ゲーム、スワップ、レンダリング）ですが、より多くのメモリを消費します。
2. 必要な機能を実装するために、最初に追加のコードを記述します。

ところで私は時々私は両方を使用します：イベントモデルとバッファモデル。