ゲーム開発におけるクラス設計の正しいオブジェクト指向のアプローチは何ですか？

XNAを使用して、Windows 7 Phone用の2Dスプライトベースのゲームを開発しています。それに利用できるトレーニングとチュートリアルは非常に役立ちますが、私が直面する問題は、それぞれが異なる方法でクラス設計にアプローチし、コードが特に適切にファクタリングされていないことです。その結果、特定のクラスにどの責任を与えるべきかを十分に理解することは困難でした。

たとえば、自分BaseSprite自身を描画する方法、衝突をチェックする方法などを知っているベーススプライトクラスを持つことができます。その後AnimatedSprite、スプライトシートやExplodingSpriteクラスなどをナビゲートする方法を知っているクラスを持つことができます。この手法は、Windows 7 Phone Jumpstart Session 2資料のSpace Invadersの例で説明されています。

または、代わりに、ゲームの責任のレンダリングと実行の大部分をGameScreenクラスに配置することもできます。そのクラスとその派生クラスは、その責任の点でフォームまたはWebページのように動作します。スプライトクラスは、ロジックがはるかに少ない、より単純なコンテナです。

これは、Windows 7 Phone Training KitのAlien Spriteゲームおよびその他のゲーム状態マネージャーの例で使用されている手法です。

ゲーム開発におけるクラス設計の正しいオブジェクト指向のアプローチは何ですか？

Visual、Collision、Animation、Inputなどのコンポーネントを持つSpriteクラスを使用する、よりコンポーネント指向のアプローチを使用します。このアプローチでは、クラス階層が深くなりません（これは良いことです）。 。

コンポーネント指向設計の詳細については、こちらをご覧ください。

ゲームでは、コンポーネントパターンが一般的なソリューションです。

SOLID原則は、他の職業へとゲームコード設計に限り適用されます-私は開始点として、あなたの最初の例を使用すると思いますので、少なくともあなたは、最適化に来るまで。

BaseSpriteはメガクラスになる傾向があるように聞こえるので、さらに先に進みます。単一責任の原則では、衝突、レンダリング、およびナビゲーションはすべて、クラス階層内の個々のエントリではなく、コンポーネントによって処理される必要があります。これらすべてのコンポーネントの保持クラスは、それらの間のワールドポジションのプッシュのみを処理する必要があります。

最後のいくつかのプロジェクトでは、MVCスタイルのアプローチをより重視しました。

最初は、これが機能するかどうかはわかりませんでしたが、完全に機能しました。

モデル

データオブジェクト。純粋なデータのみ。動作もレンダリングもありません。

データ管理者。データオブジェクトの「リスト」を処理するだけです。（プーリングをサポートするように拡張することもできます。）

表示する

それらをレンダラーと呼びます。すべてのデータオブジェクトタイプにレンダラーがあります。マネージャーで呼び出されると、そのリスト内のすべてのオブジェクトをレンダリングします。

コントローラ

レンダラーと同じですが、動作を制御します。

例

ShipManagerにはShipsのリストがあります。ShipControllerは、状態に応じてShipsを移動します。ShipRendererは、状態に応じて船舶をレンダリングします。

なぜ

このようにして、ビューとロジックは厳密に分離されます。新しいプラットフォームへの移植が非常に簡単になります。XxxManager内のデータレイアウトの最適化も非常に簡単です。