継承と構成

私はC＃でお金を稼ぎます。一般的には、その言語で、インターフェイスを使用してすべてを高い天国に切り離します。これはエンタープライズコードでは十分に役立ちましたが、C＃でゲームを作成する際には、基本クラスのデフォルトの動作を定義できるため、継承に向かう傾向があります。でも、かつて「継承よりも作曲を好む」と言っていた建築神に背を向けているように、私はこれを行うのは汚い気がします。私はそれが白黒ではないことを知っていますが、もう少し作業してインターフェイスを使用して、ほぼ同じことを達成できると感じています。

他の人は何をしますか？継承はゲームに適したアプローチですか、または一部のインターフェイスでリファクタリングする必要がありますか？

ゲームでの継承は、実際に実行できる最悪のことの1つです（特にエンティティに関して）。理由についてはこちらをお読みください。継承を介した合成は、ゲームで長い道のりを歩みます。エンジンの他の領域に関しては、それは本当に重要ではありません。たとえば、ある種の外部ネットワークサービスを呼び出している場合、1つの汎用タイプのサービスをたとえばに継承できます。HTTPServiceとSocketService-慣れ親しんだエンタープライズアプリと同じです。

ゲームが本当に単純でない限り、コンポーネントベースのエンティティ（CBE）アーキテクチャを使用する必要があります。一般的な考え方は、エンティティの場合、継承されるのではなく一般的に構成されている理由は、特定のエンティティがどの機能を持つかを実行時まで知ることができないためです。。たとえば、プレイヤーの船をスペースシューターに乗せます。ゲームプレイのある時点まで、プレイヤーがどの武器、防具、システム（つまりコンポーネント）を拾い、購入、売却、損失、破壊したかなどはわかりません。したがって、これをモデル化する唯一の現実的な方法はオブジェクトの構成を通じて。このシナリオのプラス面は、敵の種類を見るたびに常に同じ敵ではなく、同じ方法で構築された完全にカスタマイズ可能な敵を持つこともできることです。したがって、CBEを使用すると、火星の貨物船が表示され、「あれは小さなレーザーしか持っていないので、それを降ろします」と思うかもしれません。ワームホール銃。サプライズサプライズ！

コンポーネント化は、ロジックの暗黙的な結合を除去することであり、それは良いことです。

ドイツ語を話す人のための興味深い本：http : //www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1? ie=UTF8&qid=1314875533&sr =8-1

どのアーキテクチャをいつ、なぜ使用するかについて詳しくは、https： //stackoverflow.com/questions/1901251/component-based-game-engine-designをご覧ください。

自分の場合、プロジェクトのサイズと、コードを拡張または再利用する可能性に応じて、アーキテクチャを決定します。コードを再び使用する機会がないマイクロプロジェクトのアーキテクチャに何時間も投資するのはなぜですか？同時に、プロジェクトを終了させることができます。

コンポジションとコンポーネントコンポーネントはかっこいいものですが、ほとんどのプロジェクト/アーキテクチャでは、コンポジションもその機能を実行します（コンポーネントベースのオーバーヘッドなし）。それはあなたのコンポーネントシステムがその構成が提供できないものに依存します。

たとえば、プレイヤーの船をスペースシューターに乗せます。ゲームプレイのある時点まで、プレイヤーがどの武器、防具、システム（つまりコンポーネント）を拾い、購入、売却、損失、破壊したかなどはわかりません。したがって、これをモデル化する唯一の現実的な方法はオブジェクトの構成を通じて。

昔もコンポーネントなしですべてが可能だった