XNAを使用したゲームアーキテクチャに関する質問

だから私はついにXNAで遊んで、2Dゲームを作ることをいじっていました（iOSで開発した友人からたくさんのアート資産があります）

多くのことは簡単に実行できるように見えますが、ほとんどの文学（たとえば、私が買った本）は2Dにあまり注意を払っていないので、私はたくさんのものに困惑しています。

私は、以下の質問についての明確化またはより多くの情報を指摘されていることを本当に感謝します：

1. ゲームサービスのポイントは何ですか？他のGameComponentがオブジェクトを取得できるようにオブジェクトをサービスとして登録するイディオム全体を理解していますが、これを単純に公開または静的にするだけではどうでしょうか？たとえば、私の本では、Game.csクラスにSpriteBatchオブジェクトを登録することを推奨しています。とにかくGameのインスタンスは1つだけ（シングルトン）でなければならないので、これを単純にパブリック/静的にするのがどのように好ましいのかわかりません。

2. GameComponentまたはRenderableGameComponentから継承する必要がある場合、私は混乱しています。私はすべてのエンティティが単一のマネージャーによって作成/所有され、他の事柄についても同じになるように、マネージャー/コントローラーの設計に従うことを試みています。現在、各Manager / ControllerにGameComponentを継承させていますが、GameオブジェクトがすべてのManagerを所有し、それらの更新を手動で呼び出して描画することで、これをどのように解決できますか？

3. ContentLoad（）の前に Initializeが呼び出されることに気付きました。Initializeでエンティティ（スプライト、プレーヤーなど）の一部を作成したいので、この迷惑を見つけましたが、それらをロードすることはできません。読み込むための呼び出しがまだ行われていないため、SpriteSheetsまたはTextures。私はおそらく間違って初期化していますか、または人々はContentLoadのさらに下のテクスチャを割り当てるだけですか？

それらは本当に理解していないという私の最大の「WTF」のようです

あなたの質問への答えは単純です：何でも動作します。理想的には、シンプルで機能することを行います。多くの場合、組み込みのアーキテクチャを使用するのは簡単ではありません。なぜなら、あなたが見つけているように、あなたが望むようにゲームを構築するにはフープを飛び越えなければならないからです。

質問1に答えるために、「サービスを使用する理由」という質問に対する私の答えを紹介します。。簡単な答えは、自己完結型のゲームでは決して遭遇しないカップリング（バージョン管理、依存関係、拡張性）の問題を回避する良い方法だということです。ほとんどの場合、メンバーを作成するだけでpublic（そしてstatic、急いでいる場合は、場合によってはさらに）、より興味深い問題を心配する方が簡単です。

2番目の質問に答えるために、「ゲームオブジェクトのすべてのインスタンスにDrawableGameComponentを使用することの短所は何ですか？」という質問に対する私の答えを紹介します。ゲームアーキテクチャに関する私の考えと同様に。簡単な答えは：GameComponent独自のクラスを作成し、自分DrawやUpdate自分のようなメソッドを呼び出すだけで使用してもメリットはありません。GameComponent目的のアーキテクチャと完全に一致する場合は、必ず使用しますが、ほとんどの場合は一致しません。

サービスとコンポーネントの使用は、サードパーティが使用するライブラリを構築している場合にのみ本当に興味深いものになります。XNA自体がこれを行います-それは持っているIGraphicsDeviceServiceとGamerServicesComponent、例えば。これらは、ゲームの開発時に通常は遭遇しない特定のデカップリング要件を満たします。

最後に、3番目の質問に対する答えは非常に簡単ですLoadContent。ゲームエンティティをで作成するだけです。について特に特別なことは何もありませんInitialize。

Microsoft.Xna.Framework.Gameアセンブリ全体がオプションであることを指摘する価値があります。それは非常に有用な出発点を提供します-しかし、決して物事を行うための「正しい方法」と見なされるべきではありません。

最初の質問では、実際の答えが本当に分からないことを認めなければなりません。シングルトンが一般に悪いデザインパターンである理由と同じ理由によると思います。このリンクからの引用を紹介します。

最初に考えた（およびサービスを導入した理由の1つ）ことは、ゲーム全体でGraphicsDevice参照を使用できるようにすることでした。当初は、GameがGraphicsDeviceを所有し、Game.GraphicsDeviceなどのプロパティを介して公開していました。これの問題は、これによりGraphicsDeviceがゲームに緊密にバインドされ、他の誰かがデバイス（レンダラーなど）を「所有」することを許可せず、ゲームの新しいバージョンを出荷せずに将来更新されたGraphicsDeviceを使用することを防ぐことでしたt下位互換性がある。

2番目の質問では、コンポーネントベースのコンポーネントを使用している場合は、このようなコンポーネントを使用する方が便利だと思います代わりのアプローチを使用すると、リスト持っているかのように、Sprite代わりにAの自分自身を描画して更新する方法を知っているだろうコンポーネントをすべてのスプライトを更新および描画する方法を知っているマネージャー。私は同意しますが、同じように聞こえますが、コンポーネント指向のデザインが好きです。なぜなら、オブジェクト指向のアプローチが本当に好きだからです。

3番目の質問については、はい、LoadContentメソッドでコンテンツ（アセット、フォントなど）の任意の形式を読み込む必要があります。初期化に関しては、通常、Initialize関数内でPlayerオブジェクトを作成してから、そのコンテンツをLoadContent内にロードします。または、必要に応じてLoadContent内ですべて実行することもできます。