1

私はマルチスレッドのゲーム構造を書くことに手を出しています。以下に基本的な構造を示します。EventManager、LogicManager、およびRendererはすべてスレッドです。それらは、スレッド間ですべての共有リソースを処理するユニバーサルGamestateクラスから読み取り/書き込みを行います。私が理解していることから、Gamestateは技術的にはシングルトンでなければなりません。あれは正しいですか？また、C ++を除いて、http：//www.oodesign.com/singleton-pattern.html#early-singletonで説明されているように、「初期初期化シングルトン」として実装する方法も知りたいです。私はC++静的にあまり精通していないので、その結果、「プライベート静的シングルトンインスタンス=新しいシングルトン（）;」をどこに置くべきかわかりません。C++の行。回避策で同じ効果が得られることは承知していますが、

int main(){
    Gamestate gs;
    EventManager em(&gs);
    LogicManager lm(&gs);
    Renderer renderer(&gs);

    lm.start();
    renderer.start();
    em.eventLoop();

    return 0;
}
4

2 に答える 2

1

@juanchopanzaと@Dietmarがコメントしたように、ゲームの状態をシングルトンにする理由は実際にはありません。

さらに、私はそれが1つであってはならないいくつかの理由を考えることができます：

  1. ユニットテストはシングルトンによって非常に困難になります。シングルトンをモックすることは、インターフェースよりもはるかに困難です。

  2. ある日、ゲームを拡張したいとしますか？たとえば、ある日、サーバーでゲームロジックを実行し、プレーヤーにクライアントを実行させたい場合はどうでしょうか（マルチプレーヤーを考えてください）。このような場合、プロセスに複数のゲーム状態を設定し、シングルトンで不必要に制限することができます。

  3. シリアル化してマシン間で送信したり、ファイルから保存してロードしたりするなど、ゲームの状態を処理する場合は、ゲームの状態をシングルトンにすることでさらに困難になります。標準のシリアル化フレームワークを使用するのは面倒になります。

  4. シングルトンに依存性を注入することは困難です。ゲームの状態を初期化するためにいくつかのコンポーネントまたはデータが必要な場合はどうなりますか？その場合、一貫性のない状態であっても、一部のスレッドがゲーム状態インスタンスにアクセスする可能性がある期間があります。

私はおそらくもっと多くの理由を考えることができました。とにかく、私のアドバイスは、すべてのコンポーネントのインターフェイスを定義し、各コンポーネントに、依存するコンポーネントをコンストラクターパラメーターとしてインターフェイスとして受け取るようにすることです。

これにより、十分に分離されたクラスを作成しやすくなり、クラスが肥大化するのを防ぎ、優れた単体テストを実行できます。

次に、制御の反転を使用して、ゲーム初期化コード内のすべてのコンポーネントを自動的に魔法のように結び付けることができます。

于 2012-12-07T08:21:31.847 に答える
1

グローバルなゲーム状態オブジェクトが絶対に必要な場合は、グローバルにします。それをグローバル（スマート）ポインターとして宣言し、最初に手動で初期化mainし、最後に手動で破棄します。これを行うことによってあなたは

  1. マルチスレッドの問題を回避する
  2. シングルトンが初期化および破棄される順序を完全に制御します
  3. 単体テスト用のモックオブジェクトの注入を簡単にします

他の人が指摘しているように、シングルトンはアンチパターンであるという点で過大評価されています。避ける。

于 2012-12-07T08:42:47.257 に答える